AI and the software developer: the end of writing code, not of the engineer

I have not been around for a while, and I am sorry for that. The last few weeks were eaten up by private matters that simply had to be dealt with. It did not turn out badly, though: along the way I came up with a few thoughts that would not leave me alone, and over the past week I gathered a lot of material and data to check whether they hold up. Today I am back with them.

The topic is close to my heart, because by training and first love I am a software developer. For years I wrote code across different projects, most recently in banking, where a single bug can cost a great deal. Today I work with AI agents every day, so I see this change from both sides: as someone who wrote code by hand, and as someone who now delegates it to a machine and takes responsibility for what comes out. The question I hear more and more often is: will artificial intelligence take developers' jobs? My short answer: it will take away the way they have worked so far, but not the profession itself. To show this, I will start with history, because developers are not the first people technology has forced to change.

Professions that survived technological revolutions but changed beyond recognition

Farmer and gardener

In the past the work relied on physical strength: ploughing with horses or oxen, sowing by hand, harvesting with a sickle and a scythe, and farming employed most of society. Today a farmer is often an operator of advanced machinery, a data analyst and a manager. They use GPS-guided tractors, drones to monitor crops, automatic irrigation and software that analyses soil composition and weather forecasts.

Architect, designer, structural engineer

In the past the whole design process happened on a drawing board. Architects spent hundreds of hours drawing plans by hand in ink on tracing paper, with a compass, a ruler and a slide rule, and a single mistake often meant redrawing the whole sheet. Today the work has moved entirely into the digital world (CAD, BIM, 3D visualisation). An architect builds digital twins of buildings, simulates energy use and structural loads, and increasingly uses AI for early concepts.

Doctor, especially surgeon and diagnostician

In the past diagnosis relied mainly on the patient interview, physical examination (stethoscope, palpation) and basic lab tests, and operations required large incisions and direct contact between the surgeon's hands and the patient's organs. Today doctors have MRI, CT scans and DNA sequencing at hand. Surgeons increasingly operate minimally invasively with robots (for example the da Vinci system): they steer precise arms from a console while looking at a 3D image, instead of holding a scalpel.

Miner

In the past it meant digging with a pickaxe and shovel in extremely dangerous conditions, with the ore moved in carts pushed by hand or pulled by horses. Today a miner is often an operator of mining machines, drilling rigs and remote control systems. More and more of the work moves to air-conditioned control rooms on the surface, from where machines working underground are supervised.

Accountant and auditor

In the past it meant tediously writing every transaction into huge paper ledgers, adding up columns of figures by hand and binders full of invoices. Today the work is about checking and analysing data generated automatically by ERP systems and accounting software. The accountant stopped being a "number cruncher" and became a tax adviser and financial analyst.

Car mechanic

In the past it was purely mechanical work: spanners, hammers, replacing parts, tuning the carburettor "by ear" and checking the oil level. Today cars are computers on wheels. A mechanic spends as much time at a diagnostic computer plugged into the OBD-II port as with a spanner in hand, and needs to understand electronics, software and the high-voltage systems of electric cars.

Translator

In the past there were paper dictionaries, encyclopaedias and a typewriter, and every word meant leafing through heavy volumes. Today translators rarely start from scratch. They work in the post-editing of machine translation model (PEMT): they use CAT tools and language models, and focus on proofreading, cultural nuance, style and context themselves.

Librarian and archivist

In the past it was card catalogues, shelving books, lending by hand and searching for documents in archives. Today it is digital databases, electronic archiving, digitising collections and e-books, and on top of that the role of a guide to reliable sources on the internet (information literacy).

Surveyor and cartographer

In the past it was fieldwork with a theodolite, a measuring tape and a plane table, followed by drawing maps by hand from painstaking trigonometric calculations. Today measurements are taken with GNSS receivers accurate to the millimetre, 3D laser scanners and photogrammetry drones, and maps are produced in GIS systems.

Journalist and reporter

In the past it was a notebook, phone booths, a typewriter and copy sent by telegraph or courier to the printing house. Today it is multimedia content (text, video, podcasts), real-time work on social media, SEO data analysis and tools for checking whether recordings and photos are authentic (fact-checking).

What do all these changes have in common? A shift from physical strength and tedious, repetitive work to supervision, analysis and operating advanced tools. In almost every case the revolution did not abolish the profession. It freed people from routine and moved their responsibility up to the level of management and decisions.

The pace of the AI revolution compared with earlier shifts

Professions have changed at different speeds throughout history, but the current revolution has a few features we have not seen before.

How long did such changes usually take?

In earlier revolutions, a full transformation of a profession took, very roughly, decades or even generations. The first and second industrial revolutions (farming, mining) took roughly 50–100 years, from the 19th century to the mid-20th. Why so long? Heavy infrastructure had to be built (railways, electrification), machinery had to be physically replaced, and a generational change had to happen in villages and mines.

Computerisation and digitisation (architecture, accounting, surveying) took about 15–25 years, from the late 1980s to the mid-2000s. It went faster because it relied on software and personal computers, but it was held back by hardware costs, the need to teach staff to use a computer from scratch and adapting systems.

Do AI and programming fit this pattern?

Yes, the mechanism is exactly the same, only the scale is completely different. AI is not abolishing software engineering. It is shifting its goal and level of abstraction. A developer's job stops being about writing (authoring) code and starts being about architecture, specifying requirements, verification and orchestrating AI agents. Repetitive work, such as simple CRUD functions, basic unit tests, boilerplate and the first skeleton of the code, is being taken over by autonomous agents and AI assistants, so the code typist loses out to the system architect. What counts now is critical judgment, deep domain understanding, security, auditing generated code and the ability to ask the right questions.

What the data says: AI is passing the human level

You can see this trend clearly in data from independent research groups. Our World in Data, in "Test scores of AI systems relative to human performance", collects AI results in various tests (language understanding, maths, medical and legal exams) and scales them against human performance as the baseline (0). Just over a decade ago the curves sat deep below the line. In recent years most classic tests have been beaten: the lines have crossed the human level and keep climbing.

Epoch AI, in its Epoch Capabilities Index (ECI), shows an index of models' general capabilities and charts of the compute used to train them. Compute (FLOP) grows according to predictable scaling laws, and the general capabilities of models grow with it. The Stanford AI Index Report, in turn, compares how AI handles visual reasoning, competition maths and programming against human experts. It shows the breakthrough moments when the Transformer architecture and data scaling broke through old bottlenecks.

Materials I used:

• Our World in Data: Test scores of AI systems relative to human performance
• Epoch AI: Epoch Capabilities Index
• Stanford HAI: AI Index Report

Cheaper tokens: acceleration or an explosion of demand?

The falling cost of a token (the cost of inference) matters enormously for the IT market, but its effect is not one-dimensional. You might think that much cheaper artificial intelligence would replace developers straight away. In reality it sets off two opposing effects.

Effect one: acceleration, meaning more automation

When tokens are as cheap as tap water, companies stop rationing them, and the architecture of the tools themselves changes. When tokens were expensive, a developer sent a short query and waited for the answer. When they are cheap, several agents work in the background at once: they talk to each other, write code, compile it, run tests, catch bugs and correct each other in long loops. A single problem can use up millions of tokens in a few minutes.

Low costs also let agents work in the background (background execution), end to end. Overnight, an agent can review an entire repository on its own, update outdated libraries, fill in missing documentation and prepare ready-made pull requests. As a result, demand for external developers (outsourcing and software houses) shrinks. Projects that used to mean hiring an agency for six months (simple business apps, admin panels, API integrations) can now be done in-house in a few days with agentic tools.

Effect two: the Jevons paradox, meaning an explosion of demand

Economics has the well-known Jevons paradox: when a resource becomes more efficient and cheaper to use, total consumption goes up instead of down. The same is happening with code. Hundreds of thousands of ideas for apps, modules, improvements and experiments that used to end up in the bin, because hiring developers was too expensive (the ROI did not add up), suddenly cross the profitability threshold.

Every company starts building its own software, integrations and automations, because the cost of producing them has dropped sharply. The amount of software in the world is growing exponentially, and someone has to verify, deploy, secure and maintain all that generated code, so developers become more like conductors. Infrastructure complexity grows too: small systems are giving way to hugely complex solutions, because more can be built in the same amount of time.

What does this mean in practice? Acceleration, but of whom and of what?

A cheaper token does not speed up the disappearance of the developer profession. It speeds up the end of the way developers have worked so far.

The people pushed out of the market fastest are code typists and those doing routine tasks. Anyone who has made a living translating Jira tickets into simple CRUD code without a deeper understanding of the architecture is being replaced by agents fastest. The same goes for low-end outsourcing: the model of hiring hundreds of juniors and mid-level developers in cheaper countries to write repetitive modules is rapidly losing its point.

Those who gain are seniors and system architects, meaning engineers with good judgment. Cheap tokens hand them an almost free army of virtual juniors. A developer with strong decision-making skills becomes several times more productive and can ship on their own a product that used to need a whole team. Product engineers gain too: developers who talk directly to the business and use cheap agents to test market hypotheses in no time.

So falling token prices act as a catalyst: there is more and more software, and it is getting denser. They do not reduce the need for engineering thinking, but writing code itself is becoming an almost free resource, like data transfer or disk space. "Replacing the classic developer" is therefore only speeding up for manual tasks. Engineers are becoming supervisors, auditors and architects of systems many times larger and more complex than before.

Is the change faster this time?

Yes, decisively. I believe it is the fastest transformation of a profession in history. Earlier revolutions took decades, while the change in software engineering is happening within literally 2–5 years.

Why is it moving so fast? First, there are no physical barriers. New models and coding agents reach people over the internet in seconds, at almost no distribution cost, and nobody has to build factories or wait for machines to be delivered. Second, the revolution is happening on developers' home turf: AI tools are born in the digital world, exactly where they already work. Developers were the first profession to bring code assistants and language-model agents straight into their daily work (the IDE, the terminal). Third, capability is growing exponentially. In programming tasks, models went from suggesting single lines to solving whole tasks and bugs on their own in under 2–3 years. You can see it in tests where a model gets a real bug from a real project and has to fix it by itself.

For the job market this means a higher entry threshold. Traditional junior roles, where you learned the trade by writing simple code, have shrunk a lot, and young engineers have to work at a higher level of abstraction from day one. Productivity is multiplied as well: instead of building a five-person team to write a module, a senior with good agentic tools delivers the same product in a fraction of the time, acting as a technical director for AI.

Hiring a developer today

How are the requirements changing in practice, both in terms of skills and the hiring process itself?

How has the engineer's "stack" changed?

The traditional stack came down to a language, a framework and a database. Today it moves one level up:

Why testing how well you "assemble code" is losing its point

You still come across hiring processes built on LeetCode-style tasks (invert a binary tree) or writing CRUD code live. They are losing their point for three reasons.

First, a model will write it in 3 seconds. A routine method or algorithm takes a language model a moment, so measuring a developer by how fast they write a for loop tests a skill we have fully delegated to the machine. Second, it gives a false signal about competence. Someone can remember every method in C# or Python and still fail at infrastructure design, security or business logic. And the other way round. Third, the most expensive mistakes happen elsewhere. In the age of AI, the costly errors are not syntax errors (AI writes syntactically correct code), but poor specifications, misunderstanding the business domain and hallucinations in tricky edge cases.

What could a modern job interview look like?

Instead of syntax tests and live coding, hiring is moving towards testing engineering judgment.

The first format is live coding with AI, a kind of pair programming with an agent. The candidate gets a non-trivial task and full access to the AI tools they use every day. What is assessed is how they phrase tasks for the AI, whether they blindly trust generated code or read and test it right away, how quickly they spot mistakes and whether they can get the model out of a loop when it gets stuck.

The second is code review and audit. The candidate gets a piece of complex AI-generated code with hidden, non-trivial bugs (for example a race condition, a memory leak, a missing business edge case, an OWASP vulnerability). This tests critical thinking, knowledge of good practice and the ability to read and understand someone else's or generated code.

The third is system design on a real example, a conversation about the architecture of a specific system. How do you design the data flow, how do you handle an outage of an external API, how do you achieve eventual consistency? It tests systems imagination, technological maturity and understanding of trade-offs (performance, cost, maintainability).

The traditional approach to hiring is a leftover from the days when a human was the "compiler and writer". Today a developer becomes the CTO of their own working environment. What matters most is not whether you can write the loop yourself, but whether you know what exactly needs to be built, why it should be built that way, and whether what the AI handed back is secure, efficient and production-ready.

Who is today's developer?

Since AI has taken over a large part of writing code itself, it seems natural for the human role to shift towards requirements analysis (Business Analyst), product management (Product Owner) and testing and audit (Quality Assurance).

We are already seeing the rise of product engineers: developers who move close to the business and the user and treat AI as their workforce. Fully replacing the developer with a mix of QA, BA and PO has both concrete advantages and huge, quiet traps. Here are the arguments for and against the claim that today's developer is mainly a combination of these three roles.

For: the developer is smoothly evolving into BA, PO and QA

The bottleneck moves from "how to build it" to "what and why", and this is where the BA and PO role comes in. When the cost of generating template code, an interface or a database structure drops almost to zero, developer capacity stops being the bottleneck. Precise business thinking becomes the bottleneck instead. A developer has to think like a BA and PO, because AI needs a precise specification and domain knowledge (context) so it does not build a nice-looking but commercially useless system. They can also talk to a client and, within a quarter of an hour and with the help of agents, put together a working prototype to test a hypothesis (rapid prototyping).

The role also becomes defensive and audit-driven, which is the QA role. Code from language models is produced quickly, but its quality is uneven and it carries a risk of hallucinations (subtle security holes, mishandled edge states). That is why developers now spend much more time reading and auditing code written by AI, checking extreme business cases (edge cases) and designing regression, integration and performance tests. Instead of an author (writer), they become the chief quality controller and reviewer.

Finally, technology barriers are blurring. A traditional developer spent years mastering the nuances of one syntax or framework. Today, with universal AI tools, they easily jump between technologies. Their value is no longer defined by knowing a library by heart, but by understanding user needs (PO) and caring about reliability (QA).

Against: deep engineering knowledge matters more than ever

The first counterargument is the illusion of "code without a developer": technical debt and architecture. A developer who drops engineering fundamentals for the BA and PO roles alone will quickly fall into a trap. AI writes code that is locally consistent, but without an architect's firm hand the project turns over time into a so-called Big Ball of Mud. Eventual consistency, query optimisation under load, memory management, stateless microservices or network security all require deep programming knowledge. Agents are great at writing pieces of code, but they rarely manage to keep a whole repository of millions of lines consistent over the long term.

The second is the trust paradox: who checks the checker? If a developer loses the ability to write code on their own and to understand the fundamentals (how a framework works under the hood, pointers, multithreading), they also lose the ability to act as QA for the AI. To catch a subtle AI-generated bug (for example a race condition under heavy load), you need a great deal of hands-on experience. A developer without hard skills becomes just an uncritical rubber stamp for whatever comes out of the model.

The third: engineering is about solving hard problems, not just CRUD. About 80% of a developer's work consisted of repetitive tasks, which AI is taking over. The remaining 20% are unique, extremely hard challenges: performance, distributed systems, custom algorithms, integrations with old legacy systems. In these areas AI still fails or gives wrong answers. Business will not pay an engineer to be a weaker PO, but it will pay to solve the problem the automation failed at.

How I work with AI myself

Since I am writing about how this job is changing, it is only fair to show what it looks like for me. I treat an AI agent like a very fast and very self-confident junior: it does a lot, but I am the one accountable for the result. My rules are simple:

• Specification first, code second. Before the agent writes a line, I describe the goal, the constraints and the project context. The better the brief, the fewer the fixes.
• Small steps, each one checked. Tests, a build and a preview after every change, before I move on.
• I read every change. Code I do not understand does not go any further, even if it works.
• I keep the decisions. Architecture, security and whatever reaches people are my responsibility, not the model's.

This way AI makes me several times faster instead of piling up debt that someone will be paying off a year from now. In my view, that is what separates an engineer who uses AI from someone who just copies its answers.

So who is the developer becoming?

The modern developer does not stop being a developer. They move up to the level of technical director (CTO, tech lead) of a small part of the system. This is how, by my estimates, the split of their time is changing. The developer of the past mostly wrote code (about 80%) and did basic QA and BA on the side (about 20%). Today's engineer spends about 30% of their time on BA and PO, another 30% on architecture and system design, 30% on QA and auditing the AI's work, and what is left for deep coding and debugging is about 10%.

A developer does not become a pure QA, BA or PO, because none of these roles in their traditional form has enough technical competence to judge whether the architecture is right and the solution is secure.

And you: if you write code, how much of your day is writing today, and how much is reading and checking what the AI wrote? Let me know under the post, I would love to compare it with my estimates.