When AI Writes the Code, What Do Programmers Do?

AI's Rapid Progress in Coding

By the end of 2025, most new code will be written by large language models rather than typed by humans.

It might feel surreal or even unsettling to imagine AI doing the bulk of coding. After all, writing code has long been the core of a software engineer’s job. Fortunately, history shows that when one part of a job becomes automated, the human role usually shifts rather than disappears.

Just as the industrial revolution automated a lot of manual labor, AI is automating aspects of intellectual labor.

Engineers as Editors of Code

In an age where AI writes the first draft of code, software engineers increasingly resemble editors at a newspaper. What does an editor do? They don’t write every article themselves. Editors review and refine the work of reporters. They correct mistakes, improve clarity, ensure consistency with the broader narrative, and decide if a piece is ready to publish. In a world where AIs generate code, engineers will play a similar editorial role: reviewing and critiquing the code that machines produce, and shaping it to fit the product vision and quality standards.

Think about a junior reporter covering a complex story. The reporter drafts the article, but a seasoned editor checks the facts, polishes the language, and might even rewrite sections to make the story work. In our case, the AI is like that tireless junior reporter churning out drafts (in code form) at all hours. The software engineer becomes the seasoned editor who has the broader context – they know the users’ needs, the product requirements, the constraints of the system, the subtle bugs to watch out for. They read the AI’s code and ask: “Does this solve the right problem? Is it efficient and secure? What edge cases did the AI miss?” This review process is critical. Just as even the best reporters need an editor’s oversight, even the most advanced coding AI will need a human in the loop to catch misunderstandings and ensure the solution is exactly what’s needed.

We can extend the analogy further. An editor might toss back a draft with comments: “This section needs more explanation,” or “Verify this claim.” Likewise, an engineer will prompt the AI to refine the code: “Handle the case where the input is null,” or “This function is too slow with large data; optimize it.” The interaction between human and AI becomes iterative. The engineer’s job starts to look less like typing out every semicolon and more like guiding the AI, giving it high-level instructions, and guiding the output.

In essence, the creative control and final responsibility stay with the human, much as an editor ultimately approves an article for publication.

Engineers as Partners

Another useful comparison is to think of software engineers as analogous to partners at a law firm. In big law firms, senior partners don’t spend their days doing routine legal research or drafting basic contracts from scratch. They have junior associates for the heavy lifting of generating initial drafts and pulling up relevant case law. The partner’s value is in judgment and experience. They review the associates’ work, make high-level strategic decisions, and handle the nuanced parts of a case that require human expertise. Crucially, the partner is accountable for the final result delivered to the client.

In the near future, AI coding assistants will be like an army of eager junior associates. They can write the first draft of a pull request in moments. But they are, after all, junior. They lack the understanding of the broader business context and exactly what the client needs. So the human engineer – like the partner – must review the AI’s work carefully. Does the code follow the intent of the feature? Is it reliable in production? Are there legal, ethical, or security implications the AI wouldn’t know about? The engineer’s role becomes one of high-level guidance and responsibility.

This might sound like engineers will “just be supervising” and not creating anything, but supervision is an active, creative process. The partner in a law firm often substantially rewrites parts of a brief, maybe even adds whole new arguments the junior never thought of. The insightful parts – the tricky logic, the novel approach, the integration of components – still rely on human creativity.

This Has Happened Before (and It's a Good Thing)

If all this sounds like a radical transformation of programming, it is – but it’s also part of a familiar pattern in technology. We’ve been increasing the abstraction level of programming for decades, letting machines handle more of the low-level work so humans can focus on higher-level design. Think about the evolution from assembly language to high-level programming languages. In the 1950s, writing software meant hand-crafting thousands of lines of assembly or even machine code. Then came languages like Fortran and C: suddenly a compiler took over the dirty work of translating human-friendly commands into machine instructions. Most of the actual code running on the machine was now written by a program (the compiler), not by a person. There were probably assembly programmers in 1955 who felt their skillset was being threatened by these new “automatic coding” tools. And indeed, the day of manually managing CPU registers for every operation did pass. But those same programmers weren’t out of a job – they were simply writing in Fortran instead, thinking more about algorithms and less about bits. The compiler didn’t remove the need for programmers; it removed the need for a certain kind of programming. The net effect was overwhelmingly positive: software got more powerful and programmers became more productive.

We see similar stories in other fields. The introduction of spreadsheets like VisiCalc and Excel in the 1980s automated a lot of manual arithmetic that accountants used to do with ledgers and calculators. Many feared accountants would become obsolete when anyone could use a spreadsheet. What happened instead? Accounting and finance work exploded in scale and complexity because spreadsheets made it so much easier. Accountants didn’t disappear; they shifted to more analytical tasks (and there are more accountants now doing more interesting work). The spreadsheet handled the drudge work of computation, freeing humans to do analysis and advising.

Crucially, in all these cases – from compilers to spreadsheets – the overall demand for the work actually increased. Perfectly consistent with Jevons Paradox, when it became easier to produce code or financial models, people didn’t stop wanting them; they wanted more.

Software eating the world means there’s an unending appetite for new programs. If AI helps us code faster, we'll just attempt projects that were previously infeasible. It will likely even increase the demand for good engineers as we launch more ambitious initiatives.

The New Role of Engineers

If you’re a programmer today, you’re not watching the role disappear—you’re watching it grow up. It’s moving up the value chain. It might feel strange at first to have AI writing so much code, just like it felt strange the first time you used a framework that did in seconds what would have taken you hours. But after that adjustment, you probably didn’t want to go back. I suspect that a few years from now we’ll look back on manually writing all the boilerplate and say, “Can you believe we used to do it that way?”