In 2022, GitHub Copilot launched and dazzled developers with intelligent code completion. Just two years later, Claude 3.5 Sonnet and GPT o1 arrived, capable of building entire features across multiple files. The pace of this evolution raised a question I haven’t been able to shake: will the job we call “programmer” still exist in three years?
A year and a half later, the picture is becoming clearer. Code generation by AI is no longer a prediction — it’s an observable reality. Yet the work of solving real-world problems with software isn’t going away. If anything, it’s becoming more important than ever. What’s changing is how that work gets done.
The real question is: once the change is complete, what’s left for humans to do?
To answer that, we need to think from first principles — not about what AI currently lacks, but about which capabilities are structurally resistant to the way AI learns and improves.
Where AI Hits a Wall
When people discuss AI capabilities, they tend to focus on the impressive list of things it has already mastered. But if you want to understand the future of a profession, the more useful exercise is identifying AI’s structural limitations. I see two that are fundamental.
1. Value Judgments
AI can enumerate options. It can analyze trade-offs. It can even simulate what a particular type of decision-maker might choose. But there is one thing it cannot do: own the consequences of a choice.
In any scenario involving real stakes — financial loss, safety risk, erosion of user trust — a human must ultimately sign off and accept responsibility. This isn’t a technical constraint. It’s a question of accountability. AI makes a powerful advisor, but it cannot be the one in command.
More fundamentally, many critical decisions require making trade-offs under incomplete information: which requirements to prioritize, which to cut, whose interests to weight more heavily. These judgments have no objectively correct answer — only choices that are relatively better in this specific context, at this specific moment.
2. Domains Without Verifiable Feedback
There’s an often-overlooked reason why AI has improved so rapidly at programming: code comes with a built-in verification loop. Whether the code compiles, whether the tests pass, whether performance meets the bar — all of this can be checked automatically. This gives AI a tight feedback cycle for rapid iteration.
Many domains of work don’t have this luxury:
- Verification cycles are extremely long — you might not know if an architectural decision was right for years; a product direction might take quarters to validate through market feedback.
- Decision context is unobservable — critical information lives not in documents but on whiteboards in meeting rooms, in stakeholders’ unspoken concerns, in competitors’ unreleased products. AI cannot see this information, and therefore cannot learn to reason about it.
- No “correct answers” exist as training signals — if what counts as good or bad in a domain is itself contested, high-quality training data simply cannot be constructed, and AI’s capability ceiling gets locked in place.
Combining these two constraints yields a useful framework for reasoning about AI’s boundaries:
The more easily a task’s output can be automatically verified, and the more observable its decision context, the sooner AI will master it. The reverse is equally true.
Applying the Framework to Software Development
With this framework in hand, let’s look at the three layers of the software development value chain.
Layer 1: Coding — Already Solved
Function-level, file-level code generation is something AI can already do reliably. This was predictable — code has compilers, test suites, and clear correctness criteria. It’s AI’s ideal battleground.
Today’s AI coding tools handle the vast majority of routine programming tasks, and they’re only getting better. This layer of work will be almost entirely automated within a year or two.
Layer 2: Software Design — Being Solved
Cross-file, cross-module architectural design is the current bottleneck. Good software design is fundamentally about context partitioning — drawing boundaries so that each module can be understood, modified, and tested in relative isolation. Clean architecture doesn’t just make code easier for humans to reason about; it also makes AI agents more reliable and efficient, because each task requires less context to get right. Conversely, poor design forces both humans and AI to hold an unwieldy amount of the system in mind at once — and this is where today’s AI agents still struggle.
But it is solvable in principle, and the reason traces directly back to our framework: software design quality can be measured — we’ve just been missing the right metric.
This is exactly what my research on Context Footprint (CF) aims to address. CF provides a computable measure of design quality — specifically, it quantifies the volume of context one must understand to reason correctly about a given module. The better the design, the smaller the context each local change requires.
With a quantifiable design quality metric, software architecture gains the same kind of automated verification loop that code already has: AI can generate design proposals, measure their quality via CF, and optimize iteratively — just as it currently optimizes code by running tests.
I believe that within one to two years, as theories like CF are toolified and integrated into AI development workflows, architectural-level software design will be largely automated as well.
Layer 3: Problem Definition and Requirements — Human Territory
Once AI takes over coding and design, development speed ceases to be a bottleneck, and technical debt stops being a concern — agents can refactor or rewrite at will. The real challenge shifts to the interface between software and human social systems.
In Nexus, Yuval Noah Harari makes a penetrating observation: for human organizations to operate at scale, they must reduce complex reality into manageable processes and rules — and reduction inevitably means ignoring certain information. This is the essence of what he calls bureaucratization: not a matter of capturing too much or too little, but the fact that formalization itself demands that you decide what matters and what can be left out. The simplification is necessary, but the cost of what gets discarded is real and unavoidable.
Software systems work the same way. A software system is, at its core, a formalization of a business process. Every act of formalization is an act of simplification, and every simplification requires a human value judgment:
- When a business process is encoded into software, which information must be captured and which can be ignored? Every omission is a bet — a bet that what you’re leaving out won’t turn out to be critical down the road.
- A user says “I need an approval workflow,” but the real issue might be a breakdown of trust within the organization. Should you build a system to enforce control, or address the trust deficit itself?
- Two departments interpret and use the same data differently. Whose perspective should the system encode as canonical? This isn’t a technical question — it’s an organizational-political one.
These problems share a common signature: long verification cycles, largely unobservable decision context, and answers that shift with people, timing, and circumstances. They sit squarely on the far side of AI’s capability boundary.
AI is by no means useless at this layer — it can gather information, organize options, analyze trade-offs, and draft proposals. But the final call must rest with a human, because only a human can access the context that never made it into any document, and only a human can be held accountable for the consequences.
The Programmer Won’t Disappear — But the Role Will Transform
So, back to the original question: what will programmers do a few years from now?
My answer: stop writing code, and start defining problems and making choices.
The software practitioner of the future — likely no longer called a “programmer” — will be a hybrid: part product manager understanding business and users, part architect understanding the capabilities and limits of technical systems, part domain expert with deep knowledge of how a specific industry actually works.
Their core competency will no longer be “writing elegant code.” It will be navigating the complex, ambiguous, contradiction-filled real world to find the right problems, make the right trade-offs, and translate them into precise specifications that AI can understand and execute.
Code will be written, tested, maintained, and evolved by agents. But deciding what to build and why — that, for the foreseeable future, remains a human job.
This is both a challenge and an opportunity. For those who have treated coding as the entirety of their work, the transition will be painful. But for those who have always been good at understanding problems, communicating requirements, and exercising judgment, AI will become an extraordinarily powerful amplifier — enabling one person to accomplish what used to take an entire team.
The future belongs to those who understand both people and machines.