I remain because I remain hopeful the pendulum will swing the other way someday.

What works for me: write the spec in a markdown file before handing it to the agent. Predict what it'll produce before reading the output. When it surprises you, figure out why before accepting. Keeps you engaged enough to actually build mental models.

The management pressure angle in this thread is real. If your org measures velocity in lines shipped, AI tools will optimize for that metric and comprehension dies quietly.

Could've outsourced a long time ago to humans, if I wanted to deal with reading code most of the time instead of writing it.

I see no reason to regret that our skills in coding C++/Java/* will decline or athrophy at some point in time. This will mean that we just don't need them anymore.

If the three good patterns are adhered to, these AI tools can help us become more knowledgeable, productive.

We get to retain our cognitive abilities and the desire to pursue code development as a means to solving hard problems.

Adopting the anti-patterns, on the other hand, could lead to over-reliance on AI, anxiety when the tools go down (this happens! ), the atrophy of ability to debug and the yearning for immediate gratification and quick fixes.

Most insidiously, when code inevitably fails in production on cases the developer should have reasoned about and covered, they have no option but to toss it back to the AI tool, thereby, creating a vicious cycle of anxiety, helplessness and cognitive decay.

1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.

2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.

3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.

I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.

I've used AI tools in the past for maths I didn't understand or errors I couldn't make sense of, and wrote the bulk myself, but now we have as mentioned, opus/sonnet 4.5- which work great.

As part of this, I had to integrate two new apis- nornally, when I write an API wrapper I end up learning a lot about how the API feels, what leads to what and how it smells, etc. This time? I just asked Claude to read it's docs, then gave suggestions about how I wanted it to be laid out. As a result? I have no idea how these apis feel, their models, etc. If I want to interact with them, I ask Claude how I do a thing with the library it made.

Mind you, the library is good. I looked over everything, it's fairly thin and it's exactly how I would write it, as I suggested it do. But I have no deep understanding, much less an understanding of how it got integrated in.

Like, normally when I integrate something in I learn a bit about the codebase I'm integrating it into. Do that enough times, and I understand the codebase at depth, how things plug in. This time? Nada.

It's.... Deeply uncomfortable, to know so little but still be able to do so much. It doesn't matter if I get it to explain it, that's just information that washes off when I move onto the next thing. The reflexive memory isn't built.

All of which is to say, I agree with the article.

But I've noticed something similar to what you describe. When Claude writes a solution for me, I understand it about 70% of the time. That other 30% used to bother me and I'd dig in. Lately I catch myself just accepting it and moving on. The velocity is addictive but you're right that something is being traded away.

The cost I've started noticing most: I'm worse at holding the full architecture of my own app in my head than I should be 8 months in. I can describe what each piece does but I couldn't rebuild it from scratch without help. Not sure the version of me who learned without AI would have that problem.

Still wouldn't trade the tradeoff = I have a live production app that wouldn't exist otherwise. But it's an honest cost worth naming.

Have we really reached the limit of how much we can reliably automate these things via good old metaprogramming and/or generator scripts, without resorting to using unreliable and expensive statistical models via imprecise natural language?

> Refusing to use AI out of principle is as irrational as adopting it out of hype.

I'm not sure about this. For some people, holding consistently to a principle may be as satisfying, or even necessary, as the dopamine hit of creation mentioned in the article.

We had 1 week sprints and our PO had sometimes trouble to prepare enough work for the next sprint. We had 4 week sprints and we often ended up pulling tickets from the next sprint. There was often a mismatch in pace. (Quite funny, the time we had found a balance, management ordered all teams to have the same sprint lengths. They couldn't deal with all the asynchronous, overlapping sprint starts/ends. They choose to forfeit our productivity for theirs.)

So productivity isn't all about coders, it's also about owners / managers / shareholders supplying work. This kind of work is much about communication with several involved parties and researching usecases and features in a very specific context. LLMs can help with parts of it, but at one point there will be a flood of excessive, unverified generic reports and LLMs that again condense them with all the inaccuracies, that managers/owners may drown in a fuzzy mess of LLM bureaucracy. Nuances and importance will get lost in excess.

We often had rather large stories that simply had a small set of bulletpoints, because we already communicated everything in person and they were just reminders for the most important stuff. The importance here is that this reflected the teams agency how we solve things. An LLM can probably not at all provide that currently, as they are always excessive and try to add "helpful" details. They simply cannot pick up social norms and agreements, and prompting them correctly is in my opinion very hard or too time consuming.

LLM assisted coding or vibe coding is all the hype. But I have the feeling that the big realization sets in once all supporting processes are convoluted with AI noise, the peers that used to collaborate are detached and social conflicts and misunderstandings escalate.

IMO, that’s what we should do as software engineers. The idea of letting AI "do the thinking" for you is a bad idea. Sure, it can trivially write a sort function for you. Let it! But you still need to understand how that sort function works. If having the tool was a substitute for understanding the fundamentals, anyone with access to Catia, etc. could design a working airplane.

Claude will, when given a task off the beaten track, churn through tokens for a while, then produce a completely incorrect answer. (Most recent anecdote: fixing a barostat in an MD sim)

Specifically: How does Spotify, a music streaming service, improve due to AI agents producing code all night? What is improving or being fixed which needs that much abstract code and problem solving? I am guessing the AI code is just building more messy architecture on top of the messy architecture which is causing so much work to be generated.

cognitive debt is a real problem in my domain (embedded software) because AI simply can’t debug the symptom when the reasons for the bug aren’t in code, and a stack trace may not exist. finding the REALLY hard bugs requires in depth systems understanding and the ability to connect things you’ve seen around the codebase together - and the fix usually isn’t adding code, which means the patchwork fixes Claude likes to do only makes things worse.

that said, it’s made writing harnesses and supporting tools WAY easier and faster, and my workflow is better for it. Searching the git history for the why of things is also made way easier; helping me to reason more effectively

Apply this directly to fully agentic coding. If you stop writing code and only review AI output, your ability to reason about code atrophies. Slowly, invisibly, but inevitably. You can’t deeply review what you can no longer deeply understand.

I think this argument is flawed. On every team I've worked with we've always had the opinion that junior developers learn a lot about coding by reading and reviewing code written by other people, especially people more senior to them. Reviewing output doesn't weaken your skills, it improves them. Reviewing code in a large codebase forces you to explore and understand the paths that data takes. It pushes you to build an accurate mental model more than writing new code does, because that's usually isolated to a small, encapsulated domain where you only really need to care about the inputs and outputs (hopefully!).

The author is absolutely correct if you take 'review' to be 'click the accept button and move on', but if you're actually reviewing the code that your AI generates, and understanding it, and thinking about how to move forwards and prompt it to build the thing you really want, then AI only really removes the last type-the-code step. All of the architecture and process steps should be coming from you (maybe from a conversation with the AI during the planning step, but still, not just letting the AI do whatever it fancies.)

There are two ways to write software: either it obviously has no errors or there are no obvious errors in it.

LLMs tend to generate the latter. Because that’s what’s in the training data: all the code that was rushed to production with a promise it would be fixed later. And humans are notoriously bad at catching these kinds of errors.

It feels bad using tools like this because it turns you into a reverse centaur. You’re there because the tool cannot be held accountable. You’re the last mile delivery driver shipping the code. You didn’t participate in its construction and you take all the responsibility for it.

Only there are studies which demonstrate how small of an impact code review has on code quality. And that after reading a few hundred lines of code in an hour the effect disappears. Current AI processes aren’t equipped to handle this.

Whatever we’re doing it’s heading in the opposite direction of engineering.

If you're working on a personal project or trying to learn something new, by all means write the code yourself. That's still the best way to do it. But your life should not necessarily revolve around work, and sometimes there is nothing wrong wih caring more about the end product than the process.

For instance I was thinking of AI coding where the developer is writing the application interface, files, design, and the AI in the background is reading them and translating them to the programming language of choice.

This way the developer is writing the whole thing out by hand, it would be as if one is writing fluid pseudo code, but the abstractions would be there, the way they are interacting with each other is there, the human is thinking if the abstractions and when to use them. Whereas the AI is out of the view, simply translating the fluid pseudo code to a rigid programming language.

Perhaps the above isn't really it, but I strongly feel something needs to change in the way we currently work, because it really creates a chasm between the developer and the outputted code not only in terms of the actual implementation but the mental abstractions it's supposed to reflect

I would suggest leaving the keyboard, going outside and getting some real highs. Perhaps also leave behind all your technology and try to experience a non-connected life.

What is the world coming to when folks get a high from prompting a complex algorithm.

Oh well, it probably proves that “human intelligence” isn’t that complex. It seems fairly simple to simulate.

I agree that reducing engineers’ careers to code review will lead to burnout (amongst other problems).

But I think the reason we’re headed in this direction is precisely because creating with AI /can/ deliver “the dopamine of creation”.

It doesn’t deliver that hit for everyone - but it does for the half of engineers who are more excited about building new things than the act of coding.

Teams build more and ship faster because it’s so much easier to do that with AI - and it’s fun - and that leads to increased review load.

I guess it reminds me of someone switching from a manual labor job to a desk job: you become at risk of physical issues from being more sedentary, but you can exercise after work or even some people have things like standing desks and such to keep active during the job

So there can be real risks but there should be ways to manage them

The mismatch in time horizons between employers and developers will be so vexing.

At any given time, the profit-maximizing strategy for each employer is to have engineers ship features as quickly as possible. For each employee, it is rational to retain and strengthen skills by avoiding some amount of cognitive offloading.

Most insidiously, the temptation of cognitive offloading for the employee aligns with the profit-maximizing strategy of the employer.

Will the ability to review code (which is important now) become important in the future? Is it necessary to have a pipeline to nurture seniors?

Wouldn't it be more important to define clear requirements, verify that the resulting code operates properly within various guardrails, and clearly communicate the designed value, than to be able to review code?

I'd like to point out though, that you also learn by AI producing bad outcomes you are responsible for, and building intuition how it might fail through practice... You also might experience more lessons than you would have if you would have coded manually.

And for blogging too, it seems.

I don’t know how I will be able to build intuition for code I don’t write just “understand”

Are developers some kind of special creature? or must they simply learn to deal with the complexity of juggling multiple projects, like every other desk job in 2026.

Even when it's not slop, the verbosity of poorly edited AI-generated content is a micro-agression against readers. The prompter expects readers to read what they couldn't be bothered to properly edit.

Pushing AI-slop code without review, and without explicit warnings is a macro-agression against your colleagues, collaborators, and future agents. You are expecting everybody around you to maintain/ refactor, what you couldn't be botherered to review.

Yea but for how long? Go back and read any code you wrote a year ago and realize it could have been AI that wrote it.

The challenge is that the competitive and economic pressures make this moot.

A person, entering the field via AI driven development, will have none of the qualms about skill, seniority, understanding the codebase, or craftsmanship. Those arguments are handwringing by the previous generation of engineers. Their focus is solely on the outcome and value produced from the input prompt. That aligns closer to how businesses see their codebase: something they have to prompt their engineers to produce in order to generate business value.

Similarly, new AI driven companies focused on delivering value at speed and lower costs will have none of the baggage of the legacy code companies with engineers stuck debating these questions. These new gen companies will be focused on delivering value, doing so at quicker speeds and lower costs, raising the level of competition for existing incumbents.

Will existing businesses be willing to spend money to purchase services from these new gen companies of AI developed products? Seems like it.

There are real problems with these AI developed codebases. They tend to collect baggage and start to feel like a house of cards. A big open question is whether AI models will continue to improve in order to patch all the vibe-holes being generated. Seems like they will improve.

Copied to save you a click:

> I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency". Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Like if I had stated certain design goals recently it would adhere to them, but after a few iterations it would forget again and go back to its original approach, or mix the two, or whatever. Eventually it was easier just to quit fighting it and let it do things the way it wanted.

> What I've seen is that after the initial dopamine rush of being able to do things that would have taken much longer manually, a few iterations of this kind of interaction has slowly led to a disillusionment of the whole project, as AI keeps pushing it in a direction I didn't want.

> I think this is especially true if you're trying to experiment with new approaches to things. LLMs are, by definition, biased by what was in their training data. You can shock them out of it momentarily, whish is awesome for a few rounds, but over time the gravitational pull of what's already in their latent space becomes inescapable. (I picture it as working like a giant Sierpinski triangle).

> I want to say the end result is very akin to doom scrolling. Doom tabbing? It's like, yeah I could be more creative with just a tad more effort, but the AI is already running and the bar to seeing what the AI will do next is so low, so....

[1] https://news.ycombinator.com/item?id=46784594

Output from AGIs used by experienced engineers tends to be vastly different quality than output from these leaders who are too disconnected from the slaughtering.

> Software used to be deterministic

Ah, someone fortunate enough to have never coded a heisenbug or trip over UB of various causes.

I've written plenty of well structured, well thought out mostly-deterministic software, then spent hours or days figuring what oversight summoned the gremlins.

(There is one low priority bug I've occasionally returned to over the last two-three years in case experience and back-burner musing may result in insight. Nope. Use gcc, no bug, use clang, bug, always, regardless of O level, debug level, etc. Everything else, all of it far more complex, works 100% reliably, it's just that one display update that fails.)

(It occurs to me that that is a bad example, because it IS deterministic, but none of us can pinpoint the "determiner".)

https://www.npr.org/2025/07/18/g-s1177-78041/what-to-do-when...

My principles have nothing to do with whether or not AI is giving me extra productivity though. Even if AI made me 5000x more productive I still wouldn't want to use it out of principle. I think it is a deeply immoral technology that shouldn't exist

I also think that people who research and build AI are deeply immoral people who should be tried for crimes against humanity

Because I have no doubt in my mind that AI is leading us towards crimes against humanity. We are going to be culled the moment we are not useful anymore.

Almost like someone never ever learned what the core of code development is....

This is why I use zettelkatsen as my own coding AI....long term results are far better than using AI to pretend to code.

Currently I am working on a code base that is rapidly evolving for customer fit and is hoped to be around for a while. Going over recent decisions about what abstractions to focus on and what to cut it really seems like LLM tools would have been a waste for any aspect of this work. This is not a situation where some existing process needs to be encoded, and every choice about naming and structure ends up making a big difference as changes trigger refactors.

And this piece focuses on the early adopter point of view. Sure there were problems at first, but then whatsit tool thing version whatever came out and now roses are growing out of the rocks. For a large fraction of what is done with coding that makes sense, but there should always be attention to the rough parts and the gap that forms where capabilities fall off. Even a small amount of modesty can go a long way, but the conversation keeps starting off from every developer, all development, the change is now or else, and I for one am not buying that, especially not with actual money which is what these services will be charging soon in order to pay their trillion dollar debt service.

What we’re working with -—unfortunately—-are vibes. It really seems as though AI coding will have this effect on people. Morally, it seems like it ought to have this effect on people. We should not be allowed to be at ease without some sort of cost. And if we can luridly suggest that you don’t pay with money all the better.

This allows for the piece to perform its function, even when it doesn’t fully commit to it. A work in the genre can say all sorts of nuanced things about agentic coding, while still keeping the core premise that those who resist or position themselves strategically will be the winners.

That’s possible! It’s entirely possible that we will see some skill atrophy that is broken down by AI usage AND materially impacts outcomes that matter. We for sure do not know whether or not that is the case. I suspect it is because we don’t ask what these predictions cost you, which is nothing.

If we look at the starting point for most people on this stuff, it’s basically last fall. The author points this out, but the necessary conclusion one was draw from this is that we don’t have enough information to tell what the cost will be. It may like moving to programming languages from assembly or moving to assembly from bespoke instructions—-fundamentally very little was lost in those transitions, despite there being a lot of carping about it. It could be like the introduction of the tablet in American schools, where what we lose is nearly everything. We really do not know. It might be prudent to be cautious in this situation, but we ought to respect the fact that this caution might be born out of an old paradigm.

If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding?

The act of writing code by hand seems to be on a trajectory of irrelevance, so as long as I maintain my ability to reason about code (both by continuing to read it and instruct tools to write it), what’s the issue?

Edit to add: the vast majority of the code I’ve worked on in my career was not written by me. A significant portion of it was not written by someone still employed by my employer. I think that’s true for a lot of us, and we all made it work. And we made it work without modern coding assistants helping out. I think we’ll be fine.