A summary about AI and software engineering has been going around. Its argument, in short: AI has made writing code cheap, so the hard part of the job has moved to validating and curating what AI produces; this removes the easy tasks through which junior developers used to learn; and the profession is splitting into “product engineers” who ship fast and “scaling engineers” who keep systems standing.
I think it is mostly right, but a few of its points go too far. This post summarises the argument, then looks at where I agree, where I would push back, and what I would practise as a developer today.
1. The Argument in Brief
The centre of gravity has moved. Programming skill used to mean mastering syntax, algorithms, memory management and frameworks. With AI, code becomes a commodity, and the questions that matter are different: Is this code safe, without hidden bugs? Does its architecture fit the existing system? Does it actually solve the user’s problem? Writing is no longer the bottleneck; understanding the context is.
A talent pipeline problem. Businesses want efficiency, so basic tasks go to AI. But those tasks (fixing small bugs, building simple CRUD pages) were how juniors built their instincts for debugging and data flow. Companies now want juniors who arrive with product sense and architectural judgement on day one, which normally takes years of exactly that experience. If nobody gets the experience, there will be fewer seniors later.
Two new kinds of developer:
| Product engineer | Scaling / systems engineer | |
|---|---|---|
| Focus | speed, validating the market | resilience, efficiency, scalability |
| How | AI and no-code tools to build an MVP as fast as possible | reviewing code, optimising queries, designing cloud infrastructure |
| Mindset | ”ship it and see if users want it" | "what happens with a million concurrent users?” |
The conclusion: being a “code monkey” is no longer worth much. A developer’s value comes from domain knowledge and business sense, the ability to review and debug AI-generated code when it fails in production, and adaptability without losing critical thinking.
2. Where the Argument Goes Too Far
The central claim holds: when code is cheap, the expensive part is knowing whether it is right. The most dangerous mistakes are the silent ones: code that runs without an error, produces plausible numbers, and is wrong. Catching them needs domain knowledge and a habit of checking against known answers. But three points in the summary go further than I would.
”Writing code is no longer the challenge”
Reviewing code is a skill built by writing it. You notice a memory leak in AI-generated code because you once caused one and spent an evening finding it. You suspect the sign of a formula because you have derived it yourself, and you distrust a suspiciously low loss because you have seen a model collapse. Fundamentals do not lose their value; their role changes from producing code to checking it. Someone who skips them will be fast until the first problem that has no error message.
Product engineers and scaling engineers
This is a spectrum, not two camps. A product engineer who never thinks about failure modes ships an MVP that cannot grow; a systems engineer who never ships builds infrastructure for users who never arrive. Strong engineers tend to move along that spectrum depending on the phase of the product; the split says more about job titles than about skills.
The junior crisis is real, but not fate
The old first rungs of the ladder are gone. But the lessons they taught are not obsolete, and other tasks can teach them:
Reviewing AI-generated code teaches how data flows, if the reviewer has to explain it. Writing tests that catch the AI’s mistakes teaches what can break. Building known-answer checks (cases where the correct result is known in advance) teaches how to verify, which is arguably the most durable skill of all. What is missing is not the possibility of learning but the design: few organisations have deliberately rebuilt the path from beginner to senior around these tasks. That is an organisational problem, and organisations can fix it.
3. What I Would Practise
- Build things from scratch once, before using the library. Write attention, RANSAC, a training loop or a homography estimator by hand at least once. Not to use it in production, but so that you can tell when the library’s answer is wrong. Most posts on this blog do exactly that.
- Always have a way to check. Before trusting a result, ask what answer is known: a synthetic case, a simpler method, a limit where the formula is exact, a second implementation. Make that a habit, not an afterthought.
- Learn the domain, not only the tools. Camera geometry, statistics of experiments, the business rules of your product: these become commodities far more slowly than syntax does.
- Read AI output as if a confident colleague wrote it. Usually right, sometimes wrong in ways that look right. Review, do not rubber-stamp.
4. Common Claims, Checked
| Claim | Verdict |
|---|---|
| ”AI has made writing code cheap.” | Largely, yes. The cost has moved to reviewing, testing and verifying what is written. |
| ”So knowing how to code no longer matters.” | It matters differently. The ability to review and debug comes from having written and debugged code yourself. |
| ”AI-generated code fails loudly when it is wrong.” | Often it does not. Code that runs, passes a quick look and produces plausible output is the real risk. |
| ”A good metric means a good result.” | Not necessarily: a metric can be an artefact of how it is measured, and a lower training loss can even mean a broken model. Check against a known answer. |
| ”Developers are splitting into product and scaling engineers.” | As job descriptions, perhaps. As skills, it is a spectrum, and the best engineers move along it. |
| ”Juniors can no longer learn on the job.” | The old first tasks are gone; new ones (reviewing, testing AI output, building checks) can teach the same lessons, if organisations design for it. |
Closing
The value of a developer is moving from being able to write to being able to judge. But judgement is still built from experience of writing, failing and finding out why. The path from beginner to expert has not disappeared; it has to be walked more deliberately than before.