Notes from the AI Coding Transition
Like many other software engineers, my coding workflow has changed dramatically since the start of 2026. And like many others, I've felt some mix of awe, grief, frenetic productivity, atrophying skills, and understanding less while shipping more. In this moment where the field is undergoing this rapid shift, I've found it helpful to read others' takes on their processes, what they're doing to keep their brains engaged, and their genuinely mixed feelings. Before writing up my own thoughts, I went back through the relevant essays and blog posts from the last ~7 months to find the ones that resonated with me the most. Below are the posts that I especially liked and lines that stuck out from them, either because they gave me some idea about how I might want to use AI or just because they had a particularly incisive description of our field's situation. (Quotes are exact and the bold text is my added emphasis.) If you've read others that you thought were particularly on point, please send them my way! I didn’t ask for the role of a programmer to be reduced to that of a glorified TSA agent , reviewing code to make sure the AI didn’t smuggle something dangerous into production. If you would like to grieve, I invite you to grieve with me. We are the last of our kind, and those who follow us won’t understand our sorrow. Our craft, as we have practiced it, will end up like some blacksmith’s tool in an archeological dig, a curio for future generations. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it. Peter Naur reminded us some decades ago that a program is more than its source code. Rather a program is a theory that lives in the minds of the developer(s) capturing what the program does, how developer intentions are implemented, and how the program can be changed over time. Cognitive debt tends not to announce itself through failing builds or subtle bugs after deployment, but rather shows up through a silent loss of shared theory. As generative and agentic AI accelerate development, protecting that shared theory of what the software does and how it can change may matter more for long-term software health than any single metric of speed or output. the sense of psychological ennui leading into existential dread that many software developers are feeling Simon: All of the chess players and the Go players went through this a decade ago and they have come out stronger. The Shen-Tamkin study identified six distinct AI interaction patterns among developers. Three led to poor learning: full delegation, progressive reliance, and outsourcing debugging to AI. Three preserved learning even with full AI access: asking for explanations, posing conceptual questions, and writing code independently while using AI for clarification. The differentiator wasn’t whether developers used AI, it was whether they stayed cognitively engaged. metrics don’t capture what’s happening underneath. The mental fatigue of reviewing code you didn’t write all day. The boredom of babysitting an agent instead of solving problems . The slow, invisible erosion of the hard skills that made you good at this job in the first place. You stop holding the architecture in your head because the agent handles it. You stop thinking through edge cases because the tests pass. You stop wanting to dig deep because it’s easier to prompt and approve. There’s no spark in you anymore. Here is something that gets lost in all the excitement about AI productivity: most software engineers became engineers because they love writing code. Not managing code. Not reviewing code. Not supervising systems that produce code. Writing it. The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended . That is what drew most of us to this profession. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day. this is different because it is not asking engineers to learn a new way of doing what they do. It is asking them to stop doing the thing that made them engineers in the first place and become something else entirely. a mid-level backend engineer is now expected to understand product strategy, review AI-generated frontend code they did not write, think about deployment infrastructure, consider security implications of code they cannot fully trace, and maintain a big-picture architectural awareness that used to be someone else’s job. That is not empowerment. That is scope creep without a corresponding increase in compensation, authority, or time . From my experience building and scaling teams in fintech and high-traffic platforms, I can tell you that role expansion without clear boundaries always leads to the same outcome: people try to do everything, nothing gets done with the depth it requires, and burnout follows. Now the only limit is your cognitive endurance. And most people do not know their cognitive limits until they have already blown past them. Set explicit boundaries around role scope. If you are asking engineers to take on product thinking, planning, and risk assessment in addition to their technical work, name it. Define it. Compensate for it. Do not let it happen silently and then wonder why your team is burned out. talk about what you are experiencing. The isolation of feeling like you are the only one struggling with this transition is one of the most damaging aspects of the current moment. You are not the only one. Computer programming is, fundamentally, about two things: I have a hard time imagining a future where knowing how to solve problems with computers and how to control the complexity of those solutions is less valuable than it is today, so I think it will continue to be a viable career even with the advent of AI tools. I try not to use LLMs to generate full solutions that I am going to need to support. Whenever I have Claude do something for me, I feel nothing about the results. It feels like something happens around me, not through me. the default output has no soul. It's correct. It's competent. It's fine . And "fine" is the enemy of everything I care about as a writer and an engineer. find it hard to believe that supervising a set of agents is going to lead to an optimal flow experience, because we are more passive, it doesn’t stretch our abilities in the same way, and it requires far less concentration. Will we find flow elsewhere? Solving problems and delivering value will always be rewarding, but I wonder if the optimal flow experience offered by programming has, for the most part, disappeared forever, and many of us will simply find less enjoyment at work. You realize you can no longer trust the codebase. Worse, you realize that the gazillions of unit, snapshot, and e2e tests you had your clankers write are equally untrustworthy. The only thing that's still a reliable measure of "does this work" is manually testing the product. Congrats, you fucked yourself (and your company). You let them run free, and they are merchants of complexity. They have seen many bad architectural decisions in their training data and throughout their RL training. You have told them to architect your application. Guess what the result is? An immense amount of complexity, an amalgam of terrible cargo cult "industry best practices", that you didn't rein in before it was too late. All of this compounds into an unrecoverable mess of complexity. The exact same mess you find in human-made enterprise codebases. Those arrive at that state because the pain is distributed over a massive amount of people. The individual suffering doesn't pass the threshold of "I need to fix this". The individual might not even have the means to fix things. And organizations have super high pain tolerance. But human-made enterprise codebases take years to get there. The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it. With agents and a team of 2 humans, you can get to that complexity within weeks. And I would like to suggest that slowing the fuck down is the way to go. Give yourself time to think about what you're actually building and why. Give yourself an opportunity to say, fuck no, we don't need this. Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code. When people say “taste,” what they actually mean is experience. Pattern recognition built up over years of doing the work. But calling it “taste” instead of “experience” does something subtle and harmful: it makes a learnable skill sound like a gift . Doing tasks manually naturally builds up the context required for the decisions involved later because you have time to process everything along the way and construct your mental model of the project's structure. This process requires more attention and context switching, along with way more decisions per hour. Making constant architectural, big-picture decisions while overseeing the work of a cracked junior dev is fundamentally harder than executing standard programming tasks yourself. Decision fatigue is, in my opinion, the next invisible friction point for developers. The problem is that as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff. But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production? There’s an element of the normalization of deviance here—every time a model turns out to have written the right code without me monitoring it closely there’s a risk that I’ll trust it at the wrong moment in the future and get burned. When you stop fighting with hard problems directly, the mental models fade. You stop building intuition. You start pattern-matching on outputs instead of reasoning from first principles. And the worst part –> you don’t notice it happening. The code still ships. The PR still merges. Everything looks fine until the incident at 2am where you genuinely cannot reason about what the system is doing because you never really had to learn it. There’s a good analogy here from aviation. Pilots trained heavily on autopilot gradually lose the ability to fly manually and this isn’t theoretical, it’s contributed to real crashes. I think judgment is built from a specific loop: you form a view, you commit to it, you see what happens, and you update. That cycle, repeated enough times, is what builds calibration. The problem with AI is that it short-circuits the first step. You skip forming your own view and go straight to evaluating someone else’s. Do that enough and the muscle atrophies and again, not dramatically, just quietly. You become a better reviewer and a worse thinker. I did the software engineering equivalent of forwarding an email with “thoughts?” and then going to lunch . The job is the part where your fucking brain has to be in the room. You paste the issue into the machine before reading it. You accept the explanation before forming your own. You create a PR before even understanding what the problem you’re fixing is (!). You request a PR review before reading the diff. You merge because the checks passed and the reviewer approved it and the whole thing smells like progress. here’s the new hard rule I’m following after this “incident”: if I still can’t explain the change, I can’t ship it . No exceptions. many software engineers labor under a delusion that their job is to be excellent at their craft. Of course, wanting to be an excellent programmer is not a delusion; it is a completely legitimate value to hold, and a legitimate purpose to pursue. It’s just not what you’re paid to do at work. Your job , unfortunately, is producing shareholder value . This delusion has been punctured by the end of ZIRP , and again more recently by the rise of AI coding. Today, the ownership mindset defines the role. Although unintuitive, limiting the amount of work that runs in parallel is actually producing better outcomes and outputs. I believe the idea of WIP limits must be emphasised more strongly than before. moving from building features in parallel to building a single feature end-to-end faster. But for me, prolonged use becomes insidious. It's easy to become lazy and hand over thinking to the machine in looking for the next hit of cognitive offload when coding becomes even a smidge difficult. Why type your search and read half a short blog post to understand the problem when the same keystrokes give you the (possible) answer right there and then. When you ask a person to do something, you don’t expect them back in five minutes saying it’s done and ready for the next task. With an agent, that’s exactly what happens. Done. Next. Done. Next. There’s no breathing space. There’s always a next thing to think about. The work used to have a rhythm to it. You’d struggle, you’d get stuck, you’d finally figure it out, and there was this moment of joy when it clicked. Hours in the code, and then done. Figuring it out was the whole reward. That’s what AI can quietly take from me. Not the joy itself, but the sense that the thing was mine, which is where the joy was coming from all along. It hands me the finished thing, the finished thing works, and somewhere in there, I stop being the person who made it and become the person who approved it. AI didn’t take the joy out of coding, I gave it away. a quieter admission: the work isn’t teaching me much anymore, and it’s stopped being fun. That’s a description of becoming a manager . What AI did was give every engineer a small team of tireless, fast, occasionally-wrong direct reports. And with the team came the manager’s problem. The discomfort engineers are feeling right now isn’t an AI problem. It’s a delegation problem, and delegation is the oldest unsolved problem in our discipline. The good news: it’s not unsolved because nobody tried. Managers have been failing at it and slowly adapting for decades. What is in your control is small and it is everything: where you point your attention, what standard you hold, what you decide not to do, and whether you’re honest about which is which. The whole reason “there is too much” feels like drowning is that we keep trying to exert control over the size of the ocean. You can’t. You can only decide where to swim. I want to be able to explain what the system does without first having to ask a clanker to explain it to me. Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. If each iteration adds another small defense, the system slowly becomes less understandable while appearing more robust. we may no longer understand the whole system in the same way. We treat it, we monitor it, we stabilize it, but we do not necessarily comprehend it. Some domains will punish sloppiness and demand trust and responsibility, but a lot of software lives in a world where raw speed, quick experimentation, and vast coverage matter enormously. Better visualizations of changes or orchestration or agents will not restore our understanding. Either we need to find clever ways to jolt the human back into the loop and make the changes of the loops legible long term, or we need to find better ways to compose these ever more complex systems. 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. 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? 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. The feature gets delivered, but I do not really feel like I built it. Maybe this is just another evolution of our profession and in a few years it will feel completely normal. Or maybe one day we will realize that somewhere along the way we stopped programming and nobody really noticed. “I’m not sure I can do my daily job without Claude” The cost was never writing the code. The cost was owning it. A fix you cannot judge, in code nobody on your team understands, is not maintenance; it’s another spin of the roulette wheel . And when the bug comes back wearing a different hat, who do you escalate to? Your vibe-coded grid has no changelog, no support contract, and no team whose reputation depends on it. AI makes touching the code cheap; it does not make answering for it cheap. we are yet to see “mind blowing” software being churned out showing that it is still hard to build great software purely with agents. Coding using models can take you from 0 to 1 very fast. But what about 1 to 10, 10 to 100? In sufficiently large codebases, everyone operates with an incorrect theory of the program . Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about. our field is evolving in an incredible and painful (but also joyful) direction if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. large software projects have never been limited only by how quickly an individual can produce code. They are limited by how well people can coordinate their understanding of the system they are changing. The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. Before agents, some of this shared understanding was maintained by friction....Some of it was the process by which your understanding became mine, and by which both of us discovered whether we still agreed about how the system worked. The most important skill in prompting is expertise in the domain you’re prompting for. A good illustration of this is Terence Tao’s conversation with ChatGPT about the recently-discovered counterexample to the Jacobian Conjecture. This is not the same ChatGPT I talk to! I couldn’t get to where Tao gets , even with unlimited tokens to burn. There’s a lot to learn about good prompting from Tao’s conversation. Here are a few observations: So why does software keep getting worse across the board? The bar for “user experience” has kept rising, but everything has become increasingly fragile. LLMs are useful for producing code that meets easily and objectively verifiable acceptance criteria which you provide explicitly I've found this simple instruction to vastly improve LLMs' output: " Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this." Problem-solving using computers Learning to control complexity while solving these problems Write before you look. Before opening a tool, before asking the model, write down what you think. Not a design doc necessarily, just your current understanding of the problem, your instinct about the solution, where you think the tricky part is. Even a few sentences. This forces you to articulate your reasoning rather than pattern-match on someone else’s output. It’s also surprisingly useful as a diagnostic: if you can’t write anything, you probably don’t understand the problem well enough to evaluate any answer. Form a view before reading the suggestion. When reviewing AI-generated code or design, read it critically with your own opinion already in hand. What would you have done? Where does this differ? Why might the model have gone this direction and is it right? This sounds small but it’s the difference between passive consumption and active evaluation. One builds judgment, the other just builds familiarity with AI output. Separate ownership from authorship....You can own code you didn’t write. You cannot own code you refuse to understand. Those are different statements, and the gap between them is the whole job. Decide what you must understand deeply - then triage the rest without guilt. The discomfort is the job, not a bug in it. Acting on incomplete information, sitting with the unease of not-fully-knowing, and committing anyway - that is judgment. Managers don’t feel more certain than you; they’ve made peace with feeling uncertain and moving regardless.... Keep something you understand deeply.... Track what you’re learning, not just what you’re shipping.... Tao’s messages are very short and to-the-point. He doesn’t respond point-by-point to the model, just to the gist The model outputs are much more concise than when I try and talk to GPT-5.6 Sol about mathematics. By signalling expertise, Tao shunts the model into “talking-to-mathematicians” mode, not “explaining-to-amateurs” mode Tao pushes back when the model’s responses look wrong, but he doesn’t directly contradict; instead, he says things like “this looks more complex than I was hoping for” Tao makes several leaps and suggestions himself. He almost never takes the model’s advice about where to go next
Design
Business
Mobile
AI
Go
Security
Cloud
Media
Culture
Programming
CSS
Gaming
Open Source
Writing
Python
HTML
Career
JSON
