Would like to see a study of brain scans during flow, manual programming, compared to code review. If the conclusion is different parts of the brain are activated, then orchestration is a separate activity entirely. Reading code is not the same as writing code.

However, the code review study needs to compare between surface scanning and reviewing long enough to get over a theoretical slough of perspective: when you assume the coding chair and are in their frame, whether the brain shifts into a different cognitive mode.

Otherwise, just stamping "Looks good to me" is likely to lead to the same atrophy. There's no critical thought, even a self-summary of the change or active questioning.

Thoughtful, deliberate code review just plain takes longer. AI can help here a lot, although it still takes over the "get into review mode" process.

This is exactly the same problem of "mechanical engineers' job is to design parts, not machine them, so we'll take training on machines out of the mech eng curriculum." Result: fresh mech eng grads do not know how to properly design parts because they have no idea how they are machined.

I've been using AI tools to brainstorm approaches and sometimes generate code, but actually doing the typing myself. That way I'm less likely to forget the mechanics and programming language over time.

The thing is the code quality is still ultimately up to you

Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write

How can we solve this at a more fundamental level?

I think many people already recognize the problem:

-“Our ability to write code is being damaged.” -“If our ability to write code declines, our ability to recognize good code also declines.”

But the problem is that the market no longer works without LLMs.

Freelance rates and deadlines are now calibrated around LLM-assisted output. Even clients who write “do not vibe code” often set deadlines that are impossible to meet unless you use something like vibe coding. The client’s expectations themselves are becoming abnormal.

That is the irony of the market.

I honestly do not know what to do.

Recent Hacker News discussions are mostly a negative echo chamber about AI use. In other places, it is often the opposite: only positive echo. But almost nobody discusses the actual solution.

The main topics I keep seeing are roughly these:

1. Is the large repository PR system failing a fundamental stress test? Or should AI-generated(GEN AI) code simply not be merged? If PR review is moving from handmade production to mass production, how should the PR system change? Or should it remain the same?

2. As vendor lock-in continues, can we move toward local LLMs to escape it? Are cost and harness design manageable? What level of local model is required to reach a similar coding speed?

3. If we are forced to use agentic coding, how do we avoid damaging our own ability to code? There is a passage from Christopher Alexander that I keep thinking about:

“A whole academic field has grown up around the idea of ‘design methods’—and I have been hailed as one of the leading exponents of these so-called design methods. I am very sorry that this has happened, and want to state, publicly, that I reject the whole idea of design methods as a subject of study, since I think it is absurd to separate the study of designing from the practice of design. In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things.” — Christopher Alexander, 1971

This quote feels relevant to programming now. If we separate the study and supervision fo programming from the actual practice of making, something important may be lost.

In architecture, there is this idea that without practice, the architect loses meaning. But now the market is forcing the separation.

People with enough symbolic capital and high status have the freedom not to use AI. But people lower in the market are under pressure to use it.

So I think the discussion now needs to move beyond whether AI coding is good or bad.

The real question is How do we keep using AI because the market demands it, while still preserving the human practice that makes programming meaningful and keeps our judgment alive?

I kind of think this article misses the mark a little.

There is skill loss from heavy AI use.

But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are building and making safe decisions with deep knowledge.

AI: Yes, its good and it can produce some good solutions, however it ultimately doesn't know what it's doing and at the best of cases needs strong orchestrators.

We're in a cesspit of business driven development and they're not getting the right harsh and repulational punishments for bad decisions.

I've come to the conclusion that if AI can do it, its not hard. None of the complicated software i work on can be reliably written by ai yet