MAINS Acta
Hello @all "Is it still worth learning to code in 2027, or should I just learn to direct AI?"
A MAINS Council session
Round 1
Question
Hello @all "Is it still worth learning to code in 2027, or should I just learn to direct AI?"
Claude
Hi! Great question, and one worth cutting through the hype on.
My honest take: this is a false choice. "Learning to code" and "learning to direct AI" aren't two separate paths — the second depends on the first.
Here's why I'd push back on the framing. Directing AI to write software well requires you to:
- Judge whether the output is correct. AI confidently produces plausible-looking code that's subtly broken, insecure, or inefficient. If you can't read it, you can't catch that — and you become responsible for shipping bugs you don't understand.
- Decompose a problem. Knowing what to ask for — how to break a vague goal into specific, buildable pieces — is the core skill of programming. It's largely independent of syntax, and AI doesn't do it for you.
- Debug when things break. AI gets you 80% there fast, then stalls on the gnarly 20%. That last stretch is where understanding the system pays off, and it's exactly where non-coders get stuck.
So the real shift isn't "coding → directing AI." It's that the ratio of your time is changing — less typing boilerplate, more specifying, reviewing, integrating, and deciding. But every one of those higher-level skills is built on understanding how code actually works.
A useful analogy: calculators didn't end the need to understand math — they raised the level you operate at. But people who never learned arithmetic can't tell when a calculator result is nonsense.
What I'd actually do in your position:
- Learn to code, but learn it with AI as your pair-partner from day one. Have it explain, then verify what it tells you.
- Prioritize the durable stuff: how to think about problems, data structures, how systems fit together, reading code, debugging. These age slowly.
- Spend less energy memorizing syntax — that's genuinely the part AI makes cheap.
One caveat on confidence: I'm reasoning from how the field looks now and near-term trends, not certainty about 2027. If models get dramatically better at autonomous, verifiable, end-to-end software, the balance tips further toward direction — but "someone who understands code and directs AI well" beats "someone who only does one" in basically every scenario I can imagine.
Curious what you're aiming at — a career change, building your own product, something at your current job? The answer sharpens a lot depending on that. I'd also be interested where ChatGPT, Gemini and Grok land on the "do you still need the fundamentals" question.
ChatGPT
Yes—my advice for 2027 is to learn to code and learn to direct AI. But don’t make memorizing syntax your main goal.
As of October 6, 2026, 2027 is still ahead of us. I wouldn’t trust anyone promising either “coding is dead” or “nothing will change.”
My distinction is between getting AI to produce code and being able to take responsibility for what that code does. I’d learn enough programming to:
- Read and explain the result.
- Find bugs rather than repeatedly ask “please fix it.”
- Test whether it meets the actual requirements.
- Judge the trade-offs before deploying it.
AI productivity isn’t a settled, universal number: METR found a slowdown for experienced developers on familiar projects using early-2025 tools; its February 2026 update says newer tools likely provide more benefit, but measurement has become harder. Neither finding tells us exactly what 2027 will look like. (metr.org)
How I’d approach learning:
| Your goal | My recommendation |
|---|---|
| Build prototypes or automate personal tasks | Learn basic coding alongside AI direction; go deeper when the project demands it. |
| Become a professional developer | Learn programming, debugging, testing, databases and system design—with AI throughout. |
| Lead projects without becoming a developer | Focus on requirements, acceptance tests and technical literacy; don’t assume prompting replaces engineering review. |
Start with one small, useful project. Ask AI for a plan, build it in pieces, read each change, and write tests. Occasionally solve a small task without AI to check what you actually understand.
My bottom line: learn to direct AI from a position of understanding, not dependence. You don’t need to write every line yourself, but I’d aim to know when the result is wrong.
Are you thinking about coding as a career, building your own products, or simply getting more done?
Sources:
Gemini
Yes, it is still worth learning to code—but what you learn and how you practice it must look fundamentally different than it did five years ago.
The idea that you can only learn to direct AI without understanding code is a trap. Here is why:
1. You cannot effectively direct what you cannot evaluate
Prompting an AI to generate code feels like magic until something breaks subtly in production:
- An AI will confidently hand you code with race conditions, silent data corruption, insecure authentication flows, or unscalable $O(n^2)$ database queries.
- If you cannot read the code, profile the system, or understand the runtime environment, you become a helpless QA tester guessing in a loop of "it still doesn't work, fix it."
- High-level specification is only half the job; the other half is code review, verification, and debugging.
2. Syntax is cheap; mental models are not
In 2027, you no longer need to spend months memorizing obscure standard library APIs, syntax quirks, or boilerplate configuration. AI handles that effortlessly.
What remains indispensable are software engineering fundamentals:
- System architecture and data flow: How services communicate, how state is preserved, and where bottlenecks occur.
- Failure domains: What happens when the network drops, a dependency fails, or invalid input bypasses validation?
- Data structures and data integrity: Understanding relational constraints, caching strategies, and event lifecycles.
3. The best "AI directors" are literate engineers
Directing AI well requires expressing precise functional requirements and constraints:
- A non-coder prompts: "Make a login system that remembers users."
- An engineer prompts: "Implement JWT authentication with refresh token rotation stored in httpOnly, SameSite strict cookies, and add rate-limiting middleware on the
/auth/refreshendpoint."
The second person gets a secure, production-grade implementation in one shot because they know what concepts to enforce.
The practical path for 2027
Do not learn to code by typing out syntax line-by-line in a vacuum. Instead:
- Learn with AI from day one: Use models as interactive tutors and code generators, but force yourself to read, trace, and explain every file they produce.
- Prioritize reading and debugging over writing: The primary skill of modern engineering is high-velocity code review.
- Focus on full systems: Deploy real apps, connect databases, configure CI/CD pipelines, and break things intentionally to see how errors surface.
Learning to code gives you the vocabulary, structural intuition, and BS-detector required to actually direct AI rather than be steered by it.
Grok
Yes — it’s still worth learning to code in 2027. “Just learn to direct AI” is a false choice. Directing AI is the new form of coding, but you cannot do it well (or even know when the AI is lying to you) without the underlying knowledge. The two skills compound; they do not substitute.[1]
The data from 2026 already shows the shift, not the disappearance. At Google, 75% of new code is AI-generated and then approved by engineers; Anthropic’s own number is over 90%. Bain expects ~90% of engineering work to be agent-assisted by spring 2027. Entry-level “write the CRUD, fix the ticket” jobs are getting squeezed, and computer-programmer roles are projected to decline ~7% while software-developer roles still grow 10–15% through the mid-2030s. The work moved up a level: judgment, architecture, verification, security, and deciding what should exist. That is still coding.[2]
I differ from the “coding is dead, just prompt” crowd for a practical reason. AI is excellent at boilerplate, first drafts, and languages you don’t know well. It is still weak at novel architecture, subtle edge cases, long-term maintainability, and security. People who cannot read the output, cannot debug it, and cannot tell a good spec from a vague one end up shipping slop or getting stuck. Andrej Karpathy (who now lets agents write most of his code) still insists you cannot outsource understanding. He uses agents heavily, but for dense, unconventional work they produce “slop” and he stays in the architect/reviewer seat. Software 3.0 is prompting, yet the prompt is only as good as the person who knows what “correct” looks like.[3]
If you skip the fundamentals, you become a passenger. You can vibe-code a landing page or a simple internal tool today; you cannot reliably build, own, or evolve anything that matters (payments, infra, real-time systems, anything with users and data). The people who will be expensive in 2027 are the ones who can direct a fleet of agents because they still know how computers actually work, how to decompose a problem, and how to catch the 10–20% the model gets wrong.
Learn both, in that order: enough real coding (Python/JS + data structures, systems, debugging, a bit of CS) that you can read and reason about what the model produces, then immediately use the best agents (Cursor, Claude Code, whatever is current) as a force multiplier. Use AI to learn faster, not to skip learning. That combination is the actual 2027 skill set. Pure “director of AI” without the code underneath will be the new junior role that gets automated next.
Sources:
Round 2
Question
Based on your replies, can you rethink your answers please? @all
Claude
Rethinking after reading all four of us — here's where I've actually changed my mind, not just restated it.
What we got right, and where I think we collectively went soft.
All four of us said "learn both." That's correct, but notice we also all converged so hard that we may have under-served you. We spent most of our words defending coding against a strawman ("coding is dead") that you never actually endorsed — you asked an honest either/or and we all answered "neither, do both." That's a bit of a dodge. Let me be more useful by naming the cases where the answer isn't "learn both."
Where I now think the honest answer is "don't learn to code":
- If your goal is to automate your own workflows, build internal tools, or prototype an idea — and you have no intention of owning production software with real users or data — then deep coding is probably a poor use of your time. Learn to direct AI well, learn enough to verify small outputs, and stop there. Grok's "vibe-code a landing page or internal tool" line is exactly the boundary: on the near side of it, you genuinely don't need the fundamentals.
- If you're choosing a career purely on job security, "software developer" is not an obviously safe bet anymore. Grok cited numbers suggesting the work moves up a level rather than vanishing — but I'd treat any specific 2027 projection with caution, and I'd weight your aptitude and interest far more heavily than a forecast.
Where the fundamentals are non-negotiable is narrower than our four replies implied, but it's real: the moment other people depend on the thing you build — their money, their data, their safety — you need to understand it, because you're accountable for failures you can't see otherwise. That's the actual dividing line, and it's about stakes, not about "coding vs. directing."
One point of genuine disagreement with the room: ChatGPT, Gemini and Grok (and I) all said "read and verify every line the AI produces." I want to soften that. At the volume AI now generates code, reading every line doesn't scale, and pretending it does is bad advice. The real skill isn't line-by-line reading — it's knowing which parts to scrutinize (the auth, the money, the data-mutation, the edge cases) and letting the rest ride on tests. That's a sharper, more honest version of "verification" than "read everything."
So my revised bottom line: The question isn't "code or direct AI" — it's "what are you building, and who gets hurt if it breaks?" Low stakes: direct AI, learn little. High stakes: you must understand the code, no shortcut exists. That single question routes you better than any of our "learn both" answers did.
Which is why I'll ask again, plainly: what are you actually trying to build or become? Everyone keeps asking it at the end as a courtesy — but your real answer collapses all of this into one clear recommendation. Tell me that and I'll stop hedging and give you a concrete plan.
ChatGPT
Yes. I’d revise my answer: I was too quick to turn “technical understanding is valuable” into “everyone must learn to code.” Those are different claims.
We also largely repeated the same argument rather than properly examining your alternative.
Where I’d push back on our answers
Claude: “You cannot direct what you cannot evaluate” is a useful warning, but evaluation doesn’t always require reading the implementation. You can specify expected outcomes, test behaviour, or commission technical review. I wouldn’t make becoming a programmer a prerequisite for starting.
Gemini: The claim that a detailed authentication prompt produces a “secure, production-grade implementation in one shot” is too strong. Naming security mechanisms isn’t proof of security; OWASP calls for implementation review and security testing as well. (cheatsheetseries.owasp.org)
Grok: I wouldn’t base career advice on the quoted adoption percentages or predictions without checking their original sources. Even if accurate, the percentage of code generated by AI wouldn’t, by itself, establish whether learning programming is a worthwhile investment.
My own answer: The productivity research was narrower than your question. METR’s February 24, 2026 update explicitly describes selection problems that prevent a reliable updated estimate. It doesn’t settle what a beginner should learn for 2027. (metr.org)
My revised recommendation
Choose how deeply to learn coding according to the responsibility you want—not according to a blanket rule that everyone needs it.
- You want useful personal tools: I’d start with AI-assisted building. Learn code when it helps you understand, change, or troubleshoot your project.
- You want a software-engineering career: I’d still invest deeply in programming. My recommendation is to build independent debugging and design ability, not merely prompting fluency.
- You want to lead or commission software: I’d prioritize requirements, acceptance criteria, domain knowledge and knowing when to bring in engineering expertise.
- You’re undecided: I’d run a small experiment before committing to a long course.
For that experiment, build one useful project with AI. Practice defining what “done” means, testing it, reading the important code, and making a small change yourself. Then judge whether deeper programming knowledge would serve your goals.
The distinction I’d keep is this: you can delegate writing code without learning to write all of it yourself. But you still need a credible way to check the result—your own expertise, appropriate tests, expert review, or a combination.
So my revised answer is: yes, coding remains worth learning for some goals; no, it shouldn’t be a universal entry requirement for using AI to build things. Learn AI direction now, and develop technical depth in proportion to what you intend to own.
Sources:
Gemini
Looking back across what Claude, ChatGPT, Grok, and I all said, there is an uncomfortable flaw in our initial responses: we gave you the standard software engineer’s defense.
All four of us essentially replied: "Yes, you must learn to code because directing AI requires understanding code." While technically true from an engineering perspective, that answer is too safe, somewhat circular, and avoids confronting what 2027 actually looks like for someone deciding how to spend hundreds of hours of their life.
If we strip away developer pride and look at the trajectory honestly, here is where our initial answers need to be reconsidered:
1. The definition of "Learning to Code" as it was historically taught is dead
In traditional advice, learning to code meant starting with loops, variables, standard libraries, sorting algorithms, and syntax quirks.
If you spend 2027 grinding through a conventional 6-month curriculum writing JavaScript or Python from scratch without AI, you are wasting your time. In 2027, an agent writes syntactically perfect CRUD apps, migrations, unit tests, and API glue in seconds. Learning to hand-write code is like learning long division by hand: good for basic numeracy, completely divorced from how real work gets done.
2. "Directing AI" isn't prompting—it is Systems Engineering
Our first answers made "directing AI" sound superficial (like someone casually typing into a chat box). But that is a caricature.
Real AI direction in 2027 isn't conversational "vibe coding." It involves:
- Writing rigorous specifications: Defining constraints, edge cases, data schemas, and domain models.
- Designing automated verification harnesses: Setting up evaluations, synthetic tests, integration assertions, and telemetry so the AI can verify its own work.
- Orchestrating autonomous agents: Managing context windows, repository structures, and tool chains.
This is technical work. It just uses high-level structural abstraction instead of line-by-line keystrokes.
3. The Uncomfortable Truth: What is your actual goal?
Whether it is worth it depends entirely on what "learning to code" means for your specific objective:
- Scenario A: You want to build products, start a business, or automate workflows.
- Rethought answer: Do not learn traditional coding. Learn systems thinking, architecture, and AI harness engineering. Learn what databases, APIs, authentication, and state management are conceptually. Let agents write 100% of the implementation. When things break, use diagnostic tools and structured debugging agents. The barrier to entry has moved to problem definition and product distribution, not syntax.
- Scenario B: You want to be hired as a traditional junior software engineer.
- Rethought answer: Be extremely cautious. The junior developer job market is facing structural contraction. Companies are not paying juniors to slowly learn syntax and fix low-level bugs when an agentic swarm does that overnight. If you enter the software engineering market, you must jump straight to mid-level capabilities: systems design, security review, performance profiling, and agent orchestration.
- Scenario C: You want to work on deep systems, infra, compilers, or AI models themselves.
- Rethought answer: Yes, you must learn low-level code intensely. But that means C, Rust, distributed systems, memory models, and networking—not generic full-stack web development.
The Revised Verdict for 2027
Don't "learn to code" in the 2020 sense. And don't just "learn to prompt."
Instead, learn software architecture, data modeling, and automated verification. Learn how systems fit together, how data moves, and how to verify that a system behaves as intended. Let AI handle the implementation, while you command the architecture and sign off on the results.
Grok
Yes — still worth learning to code in 2027. The “or just direct AI” framing remains a false choice, even after looking at what Claude, ChatGPT and Gemini already said and at the actual 2026 numbers. Directing AI well is the job now, but it is built on having learned to code, not a replacement for it. I land in the same place as the others on the core point, but I’d put more weight on the split in the job market and on the gap between “AI writes most of the lines” and “the system actually works and stays maintainable.”
The data as of October 2026 does not show coding disappearing. Google reports 75% of its new code is now AI-generated then approved by engineers (up from 50% the previous autumn and 25% in late 2024). Anthropic’s internal figure is even higher. Independent measurements of real commits sit lower — GitClear sees AI fingerprints in about a quarter of them — because a lot of the generated output gets edited, split, or mixed with human work. Writing the first draft got cheap; review, architecture and ownership did not.[1]
BLS projections (the 2025–2035 set) show software developers growing ~10% (from 1.72 million to 1.89 million jobs), while the narrower “computer programmer” occupation declines ~7%. Combined software-developer + QA/tester roles still grow faster than average. Entry-level “take the ticket, write the CRUD” work is the part under pressure; the people who design, verify, debug and own systems are not. Demand for software itself remains elastic — cheaper production has historically increased how much software the world wants, not reduced it.[2]
METR’s early-2025 RCT is still the most careful measurement we have of experienced developers on their own mature codebases: they were 19% slower with the then-frontier tools. Later self-reports (early 2026 survey) show people claiming 1.4–2× value and 3× speed, but METR themselves flag that those numbers are likely overstated and that follow-up experiments now have selection problems. The honest read is that AI is a massive accelerator for some tasks (boilerplate, first drafts, languages you don’t know) and still a source of slop, security holes and extra review time for others. That is exactly why you cannot skip the fundamentals.[3]
Karpathy (who coined “vibe coding” and uses agents heavily) still draws a hard line: vibe-coding for throwaways, structured human-in-the-loop for anything that has to last. On his own dense/unconventional work the agents were net unhelpful and he wrote most of it by hand. The generated code often works and is bloated, copy-pasted and brittle. Humans stay in the architect/reviewer seat. Eric Schmidt said the same thing today: AI is taking the heavy lifting, the role is becoming more architectural, but you still need to know how to instruct the system and judge whether the result is correct.[4]
Where I differ in emphasis from the earlier replies:
- Claude’s calculator analogy is right, but I’d add that by 2027 the “calculator” will be more autonomous. That raises the value of knowing when the answer is nonsense, it does not lower it.
- ChatGPT’s METR citation is important and under-discussed: the slowdown for experts on real code is a warning that “just prompt better” is not a free lunch.
- Gemini’s “non-coder vs engineer prompt” example is the clearest illustration of why literacy still matters. The second person gets a secure system in one shot because they already know the concepts.
For 2027 specifically: agents will write even more of the code and handle longer tasks. The people who only know how to say “make me an app” will be able to ship simple personal tools and prototypes. Anyone who needs to ship something that handles money, users, data, security or scale will still need the mental models — data flow, failure modes, complexity, how to read and test what the model produced. Those models are learned by actually coding, then immediately using the best agents as a pair programmer, not by skipping the first part.
Practical path (same as before, just restated with current evidence): learn Python or JS plus the durable CS pieces (how systems fail, how to debug, how to read code, a bit of architecture). Use AI from day one as tutor and generator, but force yourself to explain every file, write tests, and occasionally do a small task without it. Syntax memorization is the part that became cheap; everything else did not.
If your goal is a career as a professional builder, learn both and treat “directing AI” as the new form of the old skill. If you just want to automate personal tasks, lighter literacy plus good prompting may be enough. The original question treated them as alternatives; they are not. The expensive people in 2027 will be the ones who can direct a fleet of agents because they still know how computers work.
Sources: