> Brooks' No Silver Bullet

Just because a person can create code or "results" much faster now, it doesn't say anything about productivity. Don't mistake dev productivity for economic productivity.

> Kernighan's Law, which says debugging is twice as hard as writing the code

Debugging is such a vague term in these matters. An AI may be decent to figure out their error they introduced into their code after it runs its own tests. But a production bug, i.e. reported from a user, can be very hard for AIs due to their utter lack of context.

> Dijkstra on the foolishness of programming in natural language. > ... > Lehman’s Law, which states that as a system's complexity increases as it evolves, unless work is done to maintain or reduce it.

No clue what the argument is here, "people believe otherwise" isn't.

> Also, ultimately Jevons Paradox

Actually relevant tech people confirm the paradox in the long run. Companies slash jobs now because they tend consolidate in chaotic times.

It's not, in Germany we have separation of powers.

> The action the government took was not a "good" action by any moral standard.

Morals aren't binary. Morals have context.

Your perspective is cut off. In the real world Bob is supposed to produce outcomes that work. If he moves on into the industry and keeps producing hallucinated, skewed, manipulated nonsense, then he will fall flat instantly. If he manages to survive unnoticed, he will become CEO. The latter rather unlikely.

In a living codebase you spent long stretches to learn how it works. It's like reading a book that doesn't match your taste, but you eventually need to understand and edit it, so you push through. That process is extremely valuable, you will get familiar with the codebase, you map it out in your head, you imagine big red alerts on the problematic stuff. Over time you become more and more efficient editing and refactoring the code.

The short term state of AI is pretty much outlined by you. You get a high level bug or task, you rephrase it into proper technical instructions and let a coding agent fill in the code. Yell a few times. Fix problems by hand.

But you are already "detached" from the codebase, you have to learn it the hard way. Each time your agent is too stupid. You are less efficient, at least in this phase. But your overall understanding of the codebase will degrade over time. Once the serious data corruption hits the company, it will take weeks to figure it out.

I think this psychological detachment can potentially play out really bad for the whole industry. If we get stuck for too long in this weird phase, the whole tech talent pool might implode. (Is anyone working on plumbing LLMs?)

what the hell?

Also many great innovations or discoveries have outlived extreme opposition. The problem isn't people saying no, the problem is having non-sociopathic people being reluctant hearing no.

I think the article doesn't try to figure it out, but frames the word as an self sufficient concept that is ultimately good. But it's not. A child could have the idea to see what happens if it touches a hotplate. It is certainly a personal lesson, but just because it's an "idea" it's not something that you should always explore.

How does the human intervention work out? Do you use a mix of spec and audit editing to get into the ready to generate state? How high is the success/error rate if you generate from tasks to code, do LLMs forget/mess up things or does it feel better?

The spec driven approach is potentially better for writing things from scratch, do you have any plans for existing code?