For most of my working life, I've made my living in two crafts that look very different on the surface. By day, I'm a software engineer writing code. By night, I write novels. One builds systems out of logic; the other builds worlds out of language. Underneath, they share the same essential thing: both are acts of creation that demand long, uninterrupted hours of deep, focused thinking, the kind of work that pulls you into what psychologist Mihaly Csikszentmihalyi called "flow."
That state is getting harder for me to reach, and the reason is that the nature of my work has changed. Over the past year, as my software team has leaned harder on AI coding assistants, my relationship with code has shifted from authorship to supervision. I still review code, approve pull requests, and ship features. But the design and the building now happen inside the model. I am the editor of work I did not write.
This is a piece about what gets lost when we hand over creative work to AI, why the short-term productivity gains are likely to be paid back many times over, and why creative people should think very carefully before they outsource the part of their work that actually matters.
Why AI Is So Good at Writing Code
The software industry today runs on artificial intelligence, and for good reason. AI has been trained on trillions of lines of publicly available source code. Code is unusual among human artifacts because it solves problems with testable right and wrong answers, and because it is written in a structure explicitly designed to be parsed by machines. Given those conditions, AI has become remarkably good at producing code that works.
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: what it should do, what it should not do, how users will access it, and how to test that it works.
- You research which data structures, algorithms, libraries, and external services are best suited to implement it.
- You write the code, the tests, and the documentation that explains to users how to use the feature and to other engineers how to maintain it.
- You create a "pull request," asking your peers to review, critique, and ultimately approve your work for inclusion in the product.
Now that AI can consistently produce competent code, the workflow has collapsed into something much shorter:
- You write a prompt asking the AI to create the new feature.
- You review what it produced, making changes or asking the AI to make them for you.
- You either merge the new code into the codebase yourself or open a pull request for someone else to review.
Three steps instead of five. Hours of work reduced to minutes. On paper, this looks like pure productivity gain. In practice, something important has been lost.
The Editor, Not the Author
In the old workflow, the creative process lived mostly in your own head. In the new workflow, you supervise a creative process that unfolds inside the AI's internals. You put real effort into crafting a precise, thoughtful prompt to get the model started, but you skip the hard thinking that used to come with writing the code yourself. When the code comes back, you are essentially acting as an editor.
This is not a small thing. AI can write code, but it cannot see the big picture of your project the way a human engineer can. You need to make sure the new code will not quietly break something else.
AI does not know whether the code it just wrote violates a legal requirement your product is subject to. It does not know whether a request it makes to an external system will take ten milliseconds or ten minutes to come back. It does not know whether the new feature will conflict with something your teammates are planning to ship three weeks from now. It does not know whether the function it just wrote might open a security hole when combined with another function you wrote last month that handles sensitive data.
A senior engineer does know these things, and that is exactly why senior engineers now spend their days reviewing and correcting AI code that appears to "just work." To a senior developer, AI behaves like a competent, fast-working junior or mid-level engineer. When properly directed, it produces mostly solid output, but it lacks the institutional knowledge and the deep, broad, systems-level understanding that takes decades to build.
A Novelist's Parallel
To see what is really at stake, it helps to switch professions for a moment. Imagine you are a writer of historical novels. Your typical workflow looks something like this:
- You picture a scene: two statesmen arguing outside St. Paul's Cathedral in London, 1760. You consider what you need to know to write it well, including clothing, the street atmosphere, and the political situation.
- You open a stack of books and start taking notes. What would your characters be wearing, given their positions in society? Who else is on the street, vendors, cabbies in horse-drawn carriages, chimney sweeps, perhaps a few law officers and people of the night? Who are the political figures they are arguing about, and what are their current positions? What recent events would shape the argument?
- You return to your writing, weaving the historical facts into a scene spun from your own imagination.
The novelist and the software engineer have a lot in common here. The novelist will, in reality, have done much of her historical research long before she starts writing the scene, just as the software engineer already knows from years of prior work which data structures, algorithms, caches, and databases will suit the new feature. What both workers share is a deep engagement with the material. They get so absorbed in the work that they lose track of time. It is common to glance at the clock, dive into a problem, and look up to discover that four hours have passed in what felt like ten minutes.
This is the state Csikszentmihalyi described in his 1990 book Flow, and it is the reason many software engineers prefer to work in the evenings at home, where the absence of meetings and interruptions finally lets them enter it.
Now let us put the historical novelist in the position of the software engineer. Her publisher calls with exciting news. They have found a way for her to bring four books to market each year instead of one every two years. They have recruited a batch of talented high school and college students who can each crank out five pages a day of competent prose for very little money. To preserve the original writer's standard of quality, the publisher is keeping her on, but as an editor.
Her new job is to edit the work of the students, each of whom has been carefully prompted to write pages that, with a little work, can be stitched into coherent chapters.
Anyone who has ever had to grade a hundred high school or college papers in a week knows exactly what kind of work this is. It is grinding. It is thankless. It is, in the most literal sense, not creative.
The novelist is no longer deeply engaged in her work. Editing is not creating. You do not lose yourself in imagination. You do not pour your mind and feelings into invention. You root out problems and clean up clumsy, redundant prose. The flow state is gone. You are now a cog in a larger process that does not really value your creativity or your need to exercise it.
The Cost of Letting the Bots Do It
Worse, and I say this from direct experience after months of reviewing AI-generated code, your own skills erode quickly. When a new problem comes up, a feature to implement, a tricky bug to fix, the idea of spending several hours on it feels insulting. Why should I dig through the code when Claude can locate the bug in five minutes and start drafting a fix?
Why indeed? Why should any of us invest mental energy in something we used to genuinely enjoy, something that now feels like a chore, when a bot will do it for us?
Months of working with AI have made me noticeably lazier and less sharp, at least when it comes to coding. I do not use AI when I write, for exactly the reason that writing is itself 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 I get in shape.
I have also become more impatient at work, especially when I get emails that are clearly AI-generated, often asking me to review longer documents that were also written by AI. My honest reaction, every time, is some version of: "If you could not be bothered to write this, why should I bother reading it?"
I do still use AI for basic factual questions. Want to know how Amazon's managed databases compare to Microsoft's or Digital Ocean's? Claude is a perfectly good place to get a high-level overview, after which you can go to the primary sources for detail. That is a useful, limited role for the technology.
But I think that creative people choosing to hand their most imaginative, flow-state work over to an army of bots will turn out to be a long-term mistake. Those 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 expertise.
The bots ate up all that data, which used to be free, and now they sell it back to us. No one answers questions on Stack Overflow anymore, because everyone takes their questions to Claude and ChatGPT instead. The publicly available knowledge that used to accumulate in free, community-run services is drying up, leaving the bots less to feed on for the technical questions of the future.
The Pipeline Problem
The software industry has fired most of its junior developers because AI is cheaper, as long as you have skilled senior developers to manage the bots. But without juniors in the pipeline, where will tomorrow's senior developers learn the hard way how to solve the truly complex, broad, and deep problems, the kind whose scope is simply too large for AI to handle? Who will be qualified to manage the bots in five years?
The problems I am talking about are too big to fit inside AI's "context windows," the technical term for the full scope of information a model can consider at once. You cannot now and may never be able to feed into an AI a full understanding of every law that governs your product across a hundred countries, every nuance of every related codebase your product must interact with, every business rule embedded in the millions of lines that make up your product. A team of experienced developers and managers can absorb and apply that legal and institutional knowledge. It takes work, and it is expensive. Complexity always is.
But what happens when we hand all of that work to the bots? What person anywhere will have the knowledge to verify that the work the bots are producing is actually correct?
The Navy's Lesson
A few years ago, I read an article, which I can no longer locate, about how the US Navy convinced Congress to fund the construction of an aircraft carrier the Navy did not immediately need. The senators and representatives asked, reasonably: "Why should we pay for that?"
The Navy's answer was: "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, by putting the team through every step of designing and assembling the ship.
Congress funded the project because, for all our complaints about their inefficiency and partisan bickering, they had more foresight than most of our corporations. Instead of looking at the next earnings report, they were looking decades into the future.
Companies in the software industry, from the largest corporations to the smallest startups, are offloading creative work to bots because the short-term payoff is enormous. Why pay ten developers to ship one product per year when you can pay four people to ship ten products with the help of Claude or Codex?
For managers and investors, this looks like an obvious win. The bill will come due soon enough. The cost of maintaining millions of lines of AI-generated code is enormous, especially when no one fully understands it because no one actually wrote it. Fixing bugs, adding features, and integrating new technologies into existing codebases is hard work. That work, too, will be handed to the bots, and in the long run, society will come to rely on systems that people did not create and people do not understand.
The Plastic That Will Outlast Us
As for me, a once-creative developer who used to block out uninterrupted hours each day to sink into the flow state, the process of software development is no longer so rewarding. I am no longer so deeply immersed in my work. I do not learn on the job the way I once did. I respond to the bot's suggestions and pull requests the same way most people answer their email and Slack queues. My job is to react, not to create.
As I wind down my career in software engineering, I think often of the artisans of the mid-twentieth century, the woodworkers and metal craftsmen who watched the rise of plastic manufacturing undercut their work in ways from which they could not and would not recover. Sure, the toys and tools the craftsmen made showed a level of dedication that the factory-produced plastic versions could never match. But so what? To the public, a good-enough plastic toy was good enough. And if it broke in six months, it was so cheap they could just buy another.
Those millions of plastic products now pollute our oceans. The Great Pacific Garbage Patch is now three times the size of France.
This is where our internet is going, as AI, in the process of doing other useful work, cranks out the digital equivalent of a million tons of plastic debris each day.
Find It
And while computer programming, once a creative endeavor, has been reduced to the task of minding the bots, remember that in your free time, your mind is still free, and you may turn its energies to whatever you please. I still write as often as I can, and every time I emerge from that flow state, I feel like I have come back with something new from the depths of my own mind. Ideas that were once only vaguely felt become more clearly articulated, and each becomes a step toward something higher, toward thoughts I could not have articulated, or even begun to think, without the practice of writing.
When choosing what to do with your time, choose wisely. Your library has more books than you could ever read. Your friends and family have hearts and desires the bots can never fathom. Your mind, once you remove the noise of the world at large, is still capable of imagination, creativity, and flow.
Find it.
References
[1] For related reporting on the Navy's shipbuilding skills problem, see Defense News, "The US Navy is at risk of losing vital shipbuilding skills," https://www.defensenews.com/opinion/2024/11/08/the-us-navy-is-at-risk-of-losing-vital-shipbuilding-skills/. The Rand Corporation has also published papers on the atrophy of critical engineering skills.
[2] https://en.wikipedia.org/wiki/Great_Pacific_Garbage_Patch