More builder than coder

As of October 2026. For everyone who develops software and wonders how much of it will still be their job in five years. No swan song, no sugarcoating.

For many of us, programming was never just a job. It was the thing we were really good at. Our self-worth hung on it, our standing in the team and, not least, our salary.

That very craft is now done by a machine in seconds — at least large parts of it. Anyone who doesn't feel uneasy about that isn't looking closely.

The short answer up front: software development isn't disappearing, but it is shifting. Away from writing code, towards describing, reviewing and taking responsibility. This shift doesn't hit everyone equally, and it demands more than new tools: a different understanding of ourselves.

This piece tries to do both. Not to play down the problems — and still to show a path that works.

I'm not writing this from the outside: I've been a passionate software developer and architect for decades. And I haven't programmed for several months now — at least not in the classic sense. Fortunately, I've found that what a valued colleague once said about themselves applies to me too: I'm more builder than coder.

What's really changing right now

The tools have arrived, and the gains are real — but smaller and more unevenly distributed than the advertising promises. And the job market is hitting the youngest first.

Usage is exploding, enthusiasm isn't. In Stack Overflow's developer survey, the share of AI users rose from 44 percent (2023) to 62 and then 79 percent (2025). A pulse survey in April 2026 shows almost twice as much agent use as a year earlier: 59 instead of 31 percent. At the same time, positive sentiment fell from 72 to just under 60 percent, and the share who see AI as a threat to their own job rose from 12 to 15 percent (Stack Overflow, Sept. 2026).

Perceived productivity is a poor metric. The cleanest study to date comes from METR: 16 experienced open-source developers, 246 real tasks in projects they had known for years. With AI they took 19 percent longer — and afterwards estimated they had been 20 percent faster (METR, July 2025).

That result is now outdated, and instructively so. The follow-up study with tools from late 2025 shows signs of a speed-up, but can hardly be evaluated: too many developers simply no longer wanted to work without AI and avoided the study or certain tasks (METR, Feb. 2026). That says more about where things stand than any percentage.

AI amplifies what's already there. Google's 2025 DORA report describes AI as an amplifier: it makes good teams better and weak teams worse, faster. Without a solid foundation of tests, small changes and clear processes, throughput goes up, but stability suffers (DORA 2025).

In the job market, entry-level developers are hit first. In the US, employment of software developers aged 22 to 25 was around 20 percent below its late-2022 peak in September 2025; older colleagues held steady or gained (Stanford Digital Economy Lab). How much of that is really down to AI remains disputed: the turn in interest rates, the post-pandemic correction and remote work all play a part, and the overall effect on employment has so far been small (SIEPR, July 2026).

Germany looks similar, only quieter. Bitkom, the German digital industry association, counts 79,000 open IT positions, down from 149,000 in 2023 — mainly a consequence of the economy. Only 10 percent of companies using AI in IT have cut individual positions as a result. But 55 percent expect classic entry-level tasks to disappear, and 74 percent expect steering and controlling AI to become more important (Bitkom, Sept. 2026).

The picture in one sentence: no mass extinction of developer jobs, but a shift that begins at the entry door and works its way up from there.

The fears — and what's behind them

Being afraid doesn't make you backward. Most developers' worries are a sober assessment of the situation, and some of them are simply justified.

“I'm becoming redundant.” That's not entirely unfounded. If one person with agents can do what used to take three, teams get planned smaller and positions never get advertised in the first place. According to Bitkom, 35 percent of companies that are cutting jobs or expect to are replacing open IT positions with AI — and in 47 percent of these cases the cuts hit experienced professionals, not just beginners. The data doesn't show across-the-board job losses; what it does show very clearly is that experience alone is no longer protection.

“There's no ladder left for beginners.” This is probably the most justified worry. The tasks juniors used to learn on — small bugs, forms, standard interfaces — are now done by the machine. In an experiment by Anthropic (itself an AI vendor), developers who learned a new library with AI help scored 17 percent lower on the comprehension test that followed; the biggest gap was in debugging (Anthropic, Jan. 2026). Anyone who doesn't train juniors today will have no seniors in ten years — that isn't a problem for the beginners, but for the whole industry.

“I'm losing my craft.” Experienced people notice it too: if all you do is nod things through, you lose practice. In Stack Overflow's 2025 survey, around 20 percent said AI had made them less confident in their own problem-solving; 16 percent found it hard to understand how or why the generated code works. What AI does to us describes the mechanism behind this in detail.

“I'm losing what I used to enjoy.” This worry is the one most often smiled at, and yet it is the most human. Many people became developers because they love writing code: the flow, the tinkering, the elegant solution. Anyone who instead spends all day reviewing AI-generated code quickly feels demoted to proofreader — and is allowed to grieve that.

“I'm liable for code I didn't write.” Right, and that's not going to change. AI output is often almost right, and “almost right” is the most expensive category in software. Even in a future where AI does most of the programming, three quarters of Stack Overflow's respondents would ask a human when they don't trust the machine's answer. Responsibility doesn't move to the AI; it concentrates on whoever presses “Merge”.

“I can't keep up anymore.” Every month a new model, a new tool, a new workflow. According to Bitkom, 61 percent of companies expect IT professionals to come under more pressure to keep training. The feeling of constantly running behind isn't imagination, but the realistic perception of a market that is turning faster than ever before.

None of these worries will go away with a bit of encouragement. But for each of them there's an answer that amounts to more than “just learn prompting”.

What's not true — on either side

The debate suffers from both camps telling stories that are too simple. If you want to find your bearings, you should know both.

What the hype side gets wrong:

• “Soon nobody will need developers.” The data doesn't show that. In the US, job postings for software developers recently grew even faster than for other occupations, and firms that rolled out AI broadly went on to hire more people rather than fewer (SIEPR). For many layoffs attributed to AI, even economists disagree on whether AI is the reason or merely the most convenient explanation.
• “With AI, everyone is ten times more productive.” Typing faster doesn't mean shipping faster. The bottleneck moves from writing to reviewing, testing and coordinating — and anyone who doesn't keep up there mainly produces bugs faster.
• “Prompting is the new core skill.” Prompt tricks go stale with every model. What remains is the ability to describe and delimit a problem so clearly that a human or a machine can solve it. That used to be called requirements analysis.

What the defensive side gets wrong:

• “It's hype, and it'll pass.” When experienced developers avoid a paid study because they'd have to do half their tasks without AI, this is no flash in the pan.
• “AI code is fundamentally garbage.” AI code is as good as the context, the guidelines and the review around it. Bad code mostly comes about where people were already working without tests and a clear architecture before.
• “I'm too experienced to change now.” The opposite is true: judgment, a feel for architecture and domain knowledge are exactly what you need to steer AI and assess its results. Experience isn't ballast here but capital — if you use it instead of defending it.
• “If I don't use it, it doesn't affect me.” The market moves regardless. According to Bitkom, 63 percent of companies expect AI skills to be needed in all IT jobs in future.

Roles in transition: from writing to taking responsibility

For a long time, code was the scarce commodity. Now it's cheap — what's scarce is clarity, judgment and someone who stands behind the result.

Clarity means: what exactly is to be built, for whom, under what constraints? Judgment means: is it correct, secure, maintainable, and does it fit the whole? Responsibility means: who explains to the customer why it doesn't work? According to Bitkom, three quarters of companies expect precisely this steering and control of AI to become more important for IT professionals.

A picture helps: if you used to be a bricklayer, you're more likely to become a site manager. But a good site manager has to be able to lay bricks — otherwise they won't notice when the wall goes crooked. So the craft doesn't disappear; it moves from doing to judging.

Every role is affected differently:

Role	What shrinks	What grows
Beginner	Routine tasks as a practice ground	Being able to read, debug and explain code; understanding rather than just accepting
Developer	Boilerplate, standard logic, looking things up	Breaking down tasks, providing context, reviewing results, tests as specification
Senior / architect	Implementing things yourself	Setting guardrails (architecture, conventions, rules for agents), reviews, mentoring
Test / QA	Writing test cases by hand	Test strategy, acceptance criteria, checking the checks
Team lead / product owner	Estimating in person-days	Precise requirements, prioritization, faster decisions

The hardest part isn't in any table: self-image. “I am what I program” no longer holds up. A sturdier version: “I make sure software gets built that solves a real problem — and I can explain why it's right.”

Part of this is that domain knowledge becomes more valuable than framework knowledge. An AI knows every .NET API, but not the quirks of energy billing or the unwritten rules in the customer's organization. Whoever understands the domain they're building for is hard to replace.

Personal growth: more than a new tool

The shift is half a technical project and half a personal one. The second half is almost always underestimated.

Acknowledge an ending. The organizational consultant William Bridges distinguished between change, which comes from outside, and the inner transition that everyone has to go through themselves. Every transition begins with an ending, followed by an uncertain neutral zone, and only then a new beginning. Anyone who pretends nothing is changing stays stuck in the neutral zone the longest. It helps to admit honestly what you're going to miss.

Re-anchor your self-worth. If you measure your worth by the amount of code you've written yourself, you lose to every machine. More durable are yardsticks an AI can't meet: the problem solved, the good decision, the trust of customers and colleagues.

Allow yourself to be a beginner again. For experienced people, this is the most uncomfortable part. New ways of working feel slower and clumsier for the first few weeks — that's normal and no proof that they're no good.

Speak and write clearly. If you can describe a task cleanly to an AI, you can do it for a colleague too: name the goal, state your assumptions, define acceptance criteria. The same goes for conversations with business departments. Asking the right questions becomes the core task — and that's communication, not technology.

Judge and push back. An AI always sounds convinced. Telling a fast, friendly, self-assured answer “That's wrong” takes self-confidence (more on this in Convincingly wrong). And with managers who now expect three times as much, it takes the courage to make realistic commitments.

Pass it on. Experience doesn't become worthless; it becomes a teaching task. Explaining why you reject a seemingly working solution is perhaps the most valuable knowledge a senior can pass on today.

Find your own pace. Nobody has to master every tool on release day. If you reinvent yourself every week, you'll burn out. Better: learn one tool thoroughly, check calmly what's worth it — and deliberately keep doing some things yourself, not out of nostalgia, but to keep your judgment sharp.

The shift in practice

The way into AI-assisted development doesn't lead through courses but through real work — in small, verifiable steps.

1. Start small and real. No demo apps, but a manageable task from your own day-to-day work: tests for existing code, a migration script, missing documentation.
2. Move from autocomplete to agents. Chat and code suggestions are a start. The way you work only changes when an agent reads files, runs commands and runs tests on its own — with clear guardrails.
3. Write down the context. Architecture, conventions, prohibitions and domain terms belong in a project file the agent reads every time it starts (such as AGENTS.md, CLAUDE.md or copilot-instructions.md). Why this makes such a difference is explained in When a model runs out of context.
4. Have it plan first, then build. Have a plan presented to you and correct it before any code is written. A wrong plan costs two minutes, wrong code two hours.
5. Make tests the specification. Without tests, agent work is gambling. By all means have tests generated — but review them yourself, because they are the contract.
6. Read every diff like a new colleague's. The most important rule of all: don't merge anything you can't explain.
7. When learning, ask instead of delegating. If you're learning something new, ask for explanations and pose conceptual questions instead of pulling finished code. That very behavior separated the participants in the Anthropic experiment who learned a lot from those who retained little. Many tools have dedicated learning or explanation modes for this.
8. Practice deliberately without AI. Regularly hunt down a bug yourself, design a module yourself. That keeps alive exactly the skill you need for reviewing.
9. Measure instead of going by feel. The METR study showed how far feeling and reality can diverge. For a few tasks, note down time, rework and errors — with and without AI.

If you're just starting out: Don't show that you can generate code; show that you understand it. Reading code, debugging, justifying a decision — that sets you apart from everyone who just fires off prompts. And find a domain that genuinely interests you.

If you've been at it a long time: Your experience is the lever, not the obstacle. Use it to build guardrails, assess results and support beginners — and allow yourself to be a beginner with the tools for a while.

For teams and leaders

Whether the shift succeeds is rarely decided by the tool, but by the organization around it. Those with leadership responsibility carry the larger share here.

• Formulate a clear stance. Which tools are allowed, what data may go in, who is liable for what? Lack of clarity produces either shadow AI or standstill. Among the foundations DORA names for successful AI adoption is precisely this clearly communicated stance.
• Foundation before speed. Tests, small changes, fast feedback from the pipeline: what was good practice without AI becomes vital with AI. Otherwise AI mainly amplifies existing weaknesses.
• Plan for review capacity. The bottleneck moves from writing to reviewing. If you don't plan for that, you get more code and less quality.
• Keep hiring beginners — and train them differently. A training plan instead of a replacement plan: juniors explain in reviews what the agent built, deliberately solve tasks without AI and work closely with experienced colleagues. Anyone who saws off the bottom rungs of the career ladder will, in a few years, have no one left who can assess AI results.
• Don't spend the gains right away. If you convert every hour gained directly into more tickets or fewer heads, you take away the team's time to learn — and get fear instead of engagement.
• Talk about the fear. Open conversations about worries achieve more than usage rates on a dashboard. Psychological safety is the precondition for people reporting the AI's mistakes instead of covering them up.
• Redefine career paths. What does “senior” mean in a team with agents? What should count is judgment, the quality of decisions and the ability to make others better — not the number of commits.

Conclusion

The answer to “What will become of us?” is: things will be different, and harder for some than for others. Beginners carry the greatest risk, experienced people the greatest temptation to simply carry on as before. Both are solvable, but not by themselves.

Software will still be needed, probably more than ever. What's needed are people who understand what should be built, can judge whether it's right, and stand behind it. That's not a demotion from craftsman to proofreader, but the step from doing to taking responsibility — if you take it consciously.