Reflections on Software Engineering in the Age of AI

Software Engineering in the Age of AI

June 28, 2026

For those of you who don’t know, when I’m not writing novels, I spend my days as a software engineer, writing code. The software industry these days relies heavily on artificial intelligence. Because it has studied trillions of lines of publicly accessible source code, because code solves problems with testable right and wrong solutions, and because code is structured specifically to be understood by computers, AI has gotten very good at writing code.

Before programmers started using AI, a typical workflow looked like this:

Someone asks you to add a feature to an existing program.

You write up a formal definition of that feature describing what it should (and should not) do, how users can access it and how to test that it’s working correctly.

You spend time researching which data structures, algorithms, code libraries and external services might serve best to implement this feature.

You write the code to build the new feature, the tests to make sure it works as expected, and the documentation telling users how to use it and telling other engineers what they’ll need to know to maintain and debug it.

You create a “pull request,” asking other engineers in your organization to review and comment on your new code, and ultimately to approve it for use in the product.

Now that AI can consistently produce pretty good code, the software developer’s workflow looks like this:

You write a prompt asking AI to create the new feature.

You review what the AI wrote, making changes as you see fit or asking the AI agent to make those changes for you.

You either merge the new code into the existing codebase yourself, or you create a pull request for someone else to review and merge it.

In the old workflow, the creative process happened mostly in your mind. In the new process, you supervise the creative process that unfolds inside the AI’s internal machinations. You’ve put some effort into creating a concise, thoughtful, accurate prompt to get the AI started on its work, but you haven’t done any of the hard thinking you would normally do in writing the code yourself. When you get code back from the AI, you’re essentially acting as an editor because, while AI can write code, it cannot always see the big picture of your project the way you can, and you need to make sure this new code won’t cause problems.

AI does not know whether the code it just added violates some legal requirement to which your product is subject. It does not know if the request it makes to an external system is going to take ten milliseconds or ten minutes to fulfill. It does not know whether the actions of its code will conflict with some new feature that you know your teammates will be adding three weeks from now. It does not know whether the function it just wrote might introduce a new security problem when interacting with another function you wrote last month that handles sensitive information.

A senior developer does know these things, and this is why he or she needs to vet and often correct the AI code that appears to “just work.” To a senior developer, AI is a competent, fast-working junior or mid-level developer that, when properly directed, produces mostly solid work but lacks the institutional knowledge and the deep and broad systems-level knowledge that you have developed over the past twenty years.

Now, let’s back up for a second and make an analogy. Let’s say you’re a writer of historical novels. What does your workflow look like? Probably something like this:

You picture a scene in which two statesmen are arguing outside St. Paul’s Cathedral in London in 1760. You consider what you need to know to write this scene accurately, including clothing, the atmosphere on the street and the political situation.

You crack open a number of books and start taking notes on the following, among other things:

Based on their socioeconomic positions and their roles in society, what would your characters be wearing?

Who else is on the street with them? Vendors? Cabbies in horse-drawn carriages? What did those look like? Were the chimney sweeps out at that time of day? What about prostitutes and law officers?

Who are the primary political figures about whom your characters argue, and what are their positions at the moment?

What historical events from recent weeks or months are relevant, and how will they influence your characters’ argument?

You go back to your writing, weaving the historical facts into a scene that you spin from imagination.

The novelist and the software developer have a lot in common here. In reality, the novelist will have done much of her historical research before she begins writing, just as the software developer already knows from years of prior work which data structures and algorithms and which types of caches and databases will be suitable for the new feature he’s about to write.

What both workers have in common is a deep feeling of engagement with the material they’re creating. They are entirely immersed in their work, to the point where they often lose track of time. In both novel writing and software development, it’s common for me and many of my peers to check the clock, dive into a problem, and then look at the clock ten minutes later to discover that four hours have passed.

This is the state of “optimal experience” that psychologist Mihaly Csikszentmihalyi described in his bestselling 1990 book, Flow. Writers, software developers, painters, musicians and all other creative types enter this state when time and circumstances permit. Many software engineers work after hours at home precisely because the lack of meetings and other interruptions outside normal business hours permit them to enter this state.

Now, let’s put the historical novelist in the position of the software developer. She gets a call from her publisher saying they’ve found a way for her to bring four books to market each year instead of one book every two years. They’ve recruited a bunch of top-notch high school and college students who can each crank out five pages a day of competent writing for dirt cheap. The publisher wants the historical novels to maintain the original writer’s level of excellence, or to at least be close, so they’re retaining her services as an editor.

The novelist’s job is now to edit the work of the students, each of whom has been carefully prompted to write pages that should, with a little work, be stitched together into coherent chapters.

Anyone who has ever graded the work of high school and college kids knows that this is generally not rewarding work. If you’ve ever had to grade a hundred papers in a week, you know what a grind that is.

The novelist, like the software engineer, is no longer deeply engaged in her work. Editing is not creating. You do not give yourself over to your imagination. You do not immerse your mind and feelings in the process of invention. Instead, you’re rooting out problems, trying to clean up clumsy wording and redundant descriptions instead. The flow state is gone. You are now a cog in a larger process that doesn’t really value your creativity or your need to exercise it.

Worse still–and I have felt this personally after months of reviewing AI-generated code–your skills drop off sharply. When a new issue arises–a feature to be implemented, or a tricky bug to fix–the idea of wasting several hours on it feels insulting. Why should I dig through all that code when Claude can locate the bug in five minutes and start drafting a fix?

Why indeed? Why should you or I invest mental energy in something we used to actually like doing, something that now feels like a chore, when the bot can do it for us?

Months of working with AI have made me noticeably lazier and stupider, at least when it comes to coding. (I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.)

I’ve also become more impatient at work, particularly when I get emails from coworkers that are clearly AI-written. The emails often ask me to review longer documents that were also written by AI. That always leaves me thinking, “If you couldn’t be bothered to write this, why should I bother reading it?”

I do use AI to answer basic questions. Want to know how Amazon’s managed databases compare to the offerings from Microsoft and Digital Ocean? Claude’s chatbot is a good place to get a high-level overview. From there, you can go to the sources to get more detail.

But I think that creative people choosing to hand over their most imaginative, flow-state thinking to an army of bots will be a mistake in the long run. Those AI bots got all their knowledge from us–from our code, our white papers, our poems and novels and news stories, our biographies and all the Stack Overflow answers that thousands of people spent decades writing from hard-won knowledge.

The bots ate up all the data, which used to be free, and now they sell it back to us. No one answers questions on Stack Overflow anymore because people take their questions to Claude and ChatGPT. The publicly available knowledge that used to accumulate in free-to-use services like Stack Overflow is drying up, leaving the AI bots less to feed on for answers to future technical questions.

The software companies fired all their junior developers because the AI bots are cheaper, as long as you have skilled senior developers to manage them. But with no junior developers in the pipeline, learning the hard way how to solve the truly complex, broad and deep problems–problems whose scope is simply too large for AI to handle–where will tomorrow’s senior developers come from? Who will be qualified to manage the bots in five years?

The complex, broad and deep problems I speak of are too big to fit into AI’s “context windows” which describe the full scope of questions to be answered. You cannot now and may never be able to feed into AI a full understanding of every law that governs your product across a hundred different countries, every nuance of every related codebase with which your product must interact, every business rule embedded in the millions of lines of code that make up your product. A team of developers and managers can understand and apply this legal and institutional knowledge. It takes work, naturally, and is expensive. Complexity always is.

But what happens when we resign all this work to the bots? What person anywhere will have the knowledge to verify that the work the bots are producing is correct?

A few years ago, I read an article, which I can no longer locate [1], about how the US Navy convinced Congress to fund the construction of an aircraft carrier that the Navy didn’t immediately need. “Why should we pay for that?” asked the senators and representatives.

The Navy replied, “Because the skills required to build an aircraft carrier were so hard won over so many decades that if we don’t build one now, we’ll forget how to do it in ten years.”

The Navy wanted the old hands, the engineers and craftsmen who had built the world-class ships no other country could match, to pass down to the younger generation the skills they would need to build what no one else on earth could build. The only way to do that was by actually doing it, to actually put the team through every step of designing and assembling the ship.

Congress funded the project because, despite all our complaints about their inefficiency, partisan bickering, and general

[truncated for AI cost control]