Coding Was Never the Job

TL;DR: The "coder" job — the person whose primary value is translating intent into syntax — is being automated away. But software development isn't dying. It's evolving into what it always should have been: designing systems, understanding businesses, engineering context, and exercising judgment. The roles of tomorrow are already emerging. Some companies are already hiring for them.

In my previous article, I argued that the SDLC is dead. That the ceremony, the process, the human gates — most of it was always waste. AI agents just made it impossible to pretend otherwise.

But killing the process raises an obvious question: if AI writes the code, runs the tests, generates the docs, and deploys to production — what's left for humans to do?

The numbers should wake you up: junior developer hiring in Big Tech has collapsed 73% in a single year. The "coder" job is disappearing in real time. But the answer to what's left isn't "nothing." It's "everything that actually mattered all along." We just couldn't see it because we were too busy typing semicolons.

Coding was never the job

Here's the thing nobody wants to say out loud: coding was always a translation layer. A lossy, slow, error-prone translation layer between what you meant and what the machine did.

You had a business rule in your head. You translated it into a programming language. The compiler translated it into machine code. At every step, fidelity was lost. Every bug was a translation error. Every code review was a check on whether the translation was accurate. The entire industry built ceremonies around managing the risk of this translation going wrong.

AI agents short-circuit the entire chain. You describe what you want. The agent produces working code. Not pseudo-code, not a draft — working, tested, deployable code. The translation layer that defined a generation of careers is being compressed to near-zero.

Andrej Karpathy recently built an open-source tool that scores every job in America on AI exposure, using data from all 342 Bureau of Labor Statistics occupations. Software developers score 8-9 out of 10. That's higher than nurses, physicians, and retail workers. The work product is digital, the job can be done from a home office, and the core activity — writing code — is exactly what LLMs are best at.

"The profession is being dramatically refactored."
— Andrej Karpathy

But here's the nuance that most people miss: that 8-9 score covers the entire "Software Developers" BLS category — coding and engineering lumped together. My argument is that the coding part of that score drives the exposure. The engineering part — deciding what to build, why, and how the pieces fit together — is precisely what AI cannot do. The coder is exposed. The engineer is not.

Strip away the coding, and what's left is what senior engineers have always known mattered most: understanding the domain, designing the architecture, making product decisions, and exercising judgment. That's what software development was always supposed to be. We just buried it under ten layers of syntax, frameworks, and process.

What my team looks like today

I'm not theorizing. My team is already moving this way — honestly, not completely there yet.

Most of my developers own the full chain: product understanding, code, tests, documentation, and release. They don't hand off to a QA team. They don't ask DevOps to configure the pipeline. They do it all — with AI agents handling the implementation layer.

But I'll be honest: we still have a dedicated PO for interoperability. In healthcare, interoperability — HL7, HPRIM, FHIR, the protocols that connect hospital systems — is such a deep and critical domain that it still requires a specialist who lives and breathes those standards. The business complexity is massive. What we're actively working on is simplifying the analysis layer by structuring all that business context so agents can help more. The role isn't gone yet — it's evolving.

Here's how we handle a feature request today. It comes in — from a user, from field feedback, from a spotted anomaly. The developer picks it up directly. They understand the business need, discuss the edge cases with the PO, describe the solution to the agent with the right architectural context, review the output, validate the tests, and push to production. One person. One morning. Same traceability.

In the old world, that same request went through a PO who writes a story, a developer who implements it, a reviewer who checks it, a QA who validates it, and a release manager who ships it. Five roles. Three weeks minimum. The need was the same. Only the ceremony changed.

My three interns and one apprentice — all final-year engineering students — work the same way. They don't specialize in "Java" or "Angular." They specialize in understanding the problem. The agent handles the rest. They progress faster than any junior I've seen in 14 years because they spend their cognitive energy on the domain, not on syntax battles.

This is not the future. This is a Tuesday.

The great merge

The most visible sign of this transformation is the convergence of roles. The walls between developer, product owner, designer, QA, and DevOps are collapsing. Not because the skills don't matter — but because one person can now own the full spectrum. This trend is already concrete in the US — and almost invisible in France, where job postings on APEC and Welcome to the Jungle still read like 2019. That gap is the opportunity.

Product Engineer — the most concrete new role

This is already showing up on job boards — around 3-5% of engineering postings in the US, and starting to appear in French scale-ups. A single person combining product vision, technical fluency, and domain expertise — previously split across PM, PO, and developer. Andrew Ng noted that teams are flipping ratios from 1 PM per 4 engineers to the equivalent of 2 PMs per 1 engineer, as AI compresses the implementation gap.

"Reflexive AI usage is now a baseline expectation."
— Tobi Lütke, CEO of Shopify

Shopify calls these people "spiky generalists" — deep in one area, but defaulting to the highest-impact work rather than staying in a prescribed role. When an agent can generate any UI component or backend endpoint, the value shifts from implementation to product judgment — understanding users, designing interfaces, making prioritization calls. The designer + frontend developer merge follows naturally.

Context Engineer — the role that doesn't exist on French job boards yet

This is what I do every day, and it's the role I'm most excited about — even though as of March 2026, you won't find a single "Context Engineer" posting on a French job site. The title exists at EY in New York. MIT Technology Review named the arc from "vibe coding to context engineering" as the defining shift of 2025. But in France? Zero. That lag is exactly the problem this article is about.

A Context Engineer doesn't write code — they design the information architecture that makes AI agents effective. Architecture decisions, business rules, domain constraints, all structured so the agent has exactly what it needs. It's not prompt engineering — it's systems thinking applied to AI. The companies that create this role first will have a massive advantage.

Software Orchestrator / Agentic Engineer — the most conceptual, and the furthest out

"The 'Software Engineer' title could vanish by 2026."
— Boris Cherny, creator of Claude Code at Anthropic

Cherny predicts it will be replaced by "Software Orchestrator" — someone who manages swarms of agents rather than writing code. Andrej Karpathy calls it "agentic engineering" — the evolution beyond vibe coding, where you design and manage AI workflows rather than chatting with a model. This is the limit case of role convergence — and the one that sounds most like science fiction. But managing agents toward goals, reviewing their outputs, designing their workflows? This is what I do at 9am on a Tuesday.

The end of standalone QA

If your architecture isn't testable, your QA team is compensating for the architecture. That's the uncomfortable truth behind the QA role as it exists in most organizations. When business rules are well-defined and the system is designed for testability, automated verification was always the right answer — even before AI. AI just made the gap impossible to ignore.

Agents generate comprehensive test suites alongside the code. They cover edge cases systematically. They run in seconds. The scripted manual QA workflow — follow a test plan, click through screens, fill bug reports — has no future. Google and Meta have already eliminated traditional QA roles in favor of SDETs (Software Development Engineers in Test).

What survives — and this matters — is the domain expert who notices when something feels wrong even when all tests pass. Exploratory testing, clinical workflow validation, the person who knows the system deeply enough to spot anomalies: that's judgment, and it's irreplaceable. But it's a skill embedded in every team member, not a separate role sitting behind a handoff.

The skills that actually matter

If you're a software professional wondering what to invest in, here's my honest take:

Domain expertise is the new moat. The person who understands why a workflow has seven states instead of three, why two database tables can't be merged even though they look identical, or why a business rule was implemented that way ten years ago — that person is irreplaceable. No agent has that knowledge. No model was trained on it. It lives in your head, and it's what makes the difference between code that works and code that works in the real world.

Architectural thinking is the new seniority marker. Clean Architecture, hexagonal boundaries, dependency inversion, system decomposition — these aren't abstract concepts anymore. They're the structure that makes AI agents effective. A well-architected system is one where agents can operate autonomously within clear boundaries. A poorly-architected system is one where every agent output needs manual review because nobody trusts where the code ends up.

Context engineering is the new core skill. The ability to structure domain knowledge, constraints, and decisions in a format that agents can consume. This is not prompt engineering. Prompt engineering is asking the right question. Context engineering is building the entire knowledge system that makes every question produce the right answer. It's the highest-leverage skill in software development right now.

Product vision is the new differentiator. When implementation is near-free, the bottleneck shifts entirely to knowing what to build. Understanding user needs, market dynamics, business constraints — and translating that into intent that agents can execute. The developer who also thinks like a product owner is worth ten who just "write code."

Judgment is the last line of defense. Knowing when the agent is wrong. Knowing when the test covers the obvious case but misses the critical one. Knowing when to ship and when to stop. This comes from experience, from scars, from having been wrong before. No shortcut. No model replacement.

One important nuance: none of this means understanding code no longer matters. You cannot supervise an AI that writes code if you cannot read code. The ability to evaluate what you can no longer efficiently produce yourself — that's a durable, asymmetric advantage. Coding isn't the job. But understanding code is still the foundation.

What to do about it

For individuals:

Stop investing in language expertise. "5 years of Java" is a depreciating asset. Invest in domain knowledge, architectural patterns, and learning to work with AI agents effectively. This week: list three business rules in your current project that only you know, and aren't documented anywhere. That's your moat. Start writing it down.
Learn to think in products, not features. Understand the full chain from user need to production. Don't wait for a PO to tell you what to build. This week: attend a user demo or support call and note three things the ticket didn't capture.
Build your context engineering skills. Practice structuring knowledge for agents. Start with an Architecture Decision Record (ADR) for your current project's three biggest constraints. Build a domain glossary. Write a constraint document that an agent can consume. This is the new literacy.
Develop domain depth. Pick an industry. Learn it deeply. The intersection of tech fluency and domain expertise is where the highest value lives.

For organizations:

Rewrite your job descriptions. Replace "5 years of Spring Boot" with "deep understanding of healthcare workflows" or "experience designing systems that evolve over decades." Instead of asking candidates to implement a sort algorithm, ask them to decompose a real business workflow into bounded contexts.
Merge roles deliberately. Don't wait for it to happen organically. Create Product Engineer roles. Give developers product ownership. Let your best people operate across the full spectrum. In France, this means working with HR, the CSE, and the syntec classification grid — it's a 3-5 year transformation, not a quarterly OKR. Start with new hires and voluntary reclassifications.
Invest in testable architecture over standalone QA. The money you spend on a separate QA team is better spent on architectural fitness functions, automated verification, and CI/CD pipelines. Embed quality judgment in every team member rather than isolating it in a handoff.
Invest in context infrastructure. Document your domain knowledge, architecture decisions, and business rules in agent-consumable formats. This is the highest-ROI investment in 2026.

A word for the experienced developer reading this with a knot in your stomach. If you have 8 years of Java and you're wondering if your career is over — it's not. Your domain knowledge, your understanding of why things were built the way they were, your instinct for what will break — that's exactly what survives. The transition doesn't start with learning a new title. It starts with naming what you already know that isn't code: the business rules, the architectural decisions, the domain quirks that live in your head and nowhere else. That knowledge is your moat. Start documenting it.

And a word of honesty about the next generation. My interns progress fast. But if junior hiring collapses 73%, how do the next interns get in? Domain expertise comes from working inside a domain — you can't develop it from the outside. The ladder my team is climbing is being pulled up behind them. I don't have a solution to that. But I refuse to pretend it isn't happening. If you're in a position to hire juniors, do it. Give them real problems, real context, real stakes. The industry needs them more than ever — even if the job descriptions haven't caught up yet.

"The knowledge and skill of being a software developer has been commoditised. If everyone can be a software developer, what does that mean if your identity function is that you're a software developer?"
— Geoffrey Huntley

Conclusion

Coding was never the job. The person whose primary value was translating business intent into programming language syntax — that role is being automated. Fast. Andrej Karpathy scored it 8-9 out of 10 on AI exposure. The market agrees: junior developer hiring in Big Tech has collapsed 73% in a year.

But software development? Software development is finally being born. Freed from the weight of syntax, it's becoming what it always should have been: understanding problems, designing solutions, engineering context, and exercising judgment. The roles are merging. The walls are falling. The person who can think about the product, design the architecture, engineer the context, and validate the output — that person doesn't just survive. They thrive.

My team already works this way. Every person owns the full chain. The interns learn faster than any junior I've ever seen. The quality is higher because the cognitive energy goes to the domain, not to debugging semicolons.

This is not a prediction. This is a Tuesday at my office.

Coding Was Never the Job

Coding was never the job

What my team looks like today

The great merge

Product Engineer — the most concrete new role

Context Engineer — the role that doesn't exist on French job boards yet

Software Orchestrator / Agentic Engineer — the most conceptual, and the furthest out

The end of standalone QA

The skills that actually matter

What to do about it

Conclusion

Sources

Related Posts

What if we compared our timeline to the films of our childhood?

The Skill Was Real. The Seat Wasn't.

Quality Isn't Read. It's Executed.