待翻譯：Notes from the AI Coding Transition

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

Notes from the AI Coding Transition 05 Aug, 2026 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! February 7, Nolan Lawson: We mourn our craft 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. February 9, Margaret Storey: How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt 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. February 15, Simon Willison: Deep Blue 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. February 15, Tom Wojcik: Finding the Right Amount of AI 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. February 25, Ivan Turkovic: AI Made Writing Code Easier. It Made Being an Engineer Harder. 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. February 27, Carson Gross: Yes, and... Computer programming is, fundamentally, about two things: Problem-solving using computers Learning to control complexity while solving these problems 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. March 11, Xe Iaso: I don't know if I like working at higher levels of abstraction 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. March 15, Colin Brek: Adapting to AI: Reflections on Productivity 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. March 25, Mario Zechner: Thoughts on slowing the fuck down 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. March 27, Matheus Lima, “Good Taste” Is Just Experience 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. May 1, Sid Sundharam: Agentic Coding is Burning Me Out 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. May 6, Simon Willison: Vibe coding and agentic engineering are getting closer than I’d like 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. May 27, Vardan Torosyan: What to do when AI is quietly making you worse 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 [truncated for AI cost control]