https://xcancel.com/unclebobmartin/status/2080257779395154409?s=20

The author of clean code (who makes his living consulting on how to write software) has pivoted to AI in a spectacular tweet about how to set up automated software development just in time to make his living consulting about how to set up automated software development.

This is the guy that thinks optionals are too complicated? https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...

I keep posting this but it keeps being relevant. I had an agent implement a feature completely backwards. It wrote a whole bunch of tests proving the correctness of the implementation. All the tests passed.

The really interesting thing to me is that formal verification wouldn't have helped there either -- it would have just written a mathematical proof of the correctness of the backwards feature.

Ironically from my experience seeing AI code a lot, it probably follows his clean code verbosity beautifully

This is the dude who ushered in the age of nonsensical boilerplate-ridden OOP code where you need to go down a bajillion of abstraction layers to see the actually implementation. Makes sense that he doesn't care about the bajillion lines of code AI produces as long as it looks good (on the surface).

I read the post slightly differently.

LLM code past a few pages is really unreadable. A workflow of LLM writes code, human reads/checks/corrects is IME very unproductive and frustrating, and you're usually better off writing by hand (YMMV).

If you want to reap some productivity improvements, it can't rely on you reading, grokkong and accepting the LLM code line by line. You just kind of need to suck it in.

So the best you can do is to indeed, constrain it heavily, maybe write the interface, then have the LLM write tests, then have it write the code.

I'm not saying I like the approach, but I agree manually verifying LLM code is very frustrating and unproductive.

We're asking the wrong questions. What we should be asking is:

"What kind of software do you have agents writing without human supervision?"

Does he read his tests and constraints? You’d need lots of tests to have that kind of confidence (SQLite has 500+ lines of tests per line of code), at which point it’s not a lot of additional work to just read the code.

Right now there is about a 95% chance that when I manually review an agent's code I find nothing that needs changing.

I find it plausible that an extra agentic review pass and more testing can bring this number up to the point that one never needs to review code again. AI writes pretty good code nowadays.

(You still need to be diligent and decide the architecture during the planning, and read the gotchas and "things to note" that the agent will spit out at the end of implementation if it had to diverge from the plan.)

But does he read all those tests to know if they're right? Or does he just ask the LLM if the test it created were good?

As a general advice, if you do the opposite of clean code, you'll probably be happier and have a better product.

Well, he knows where is toast is buttered

Focusing on the surrounding other than the code itself is not good strategy or behavior.

Giving up reviewing code is not strategy, but because:

Review AI code line by line is like watch movies frame by frame, and is impossible, very difficult, terribly boring, or abandoned sooner or later.

From my perspective, the primary end-user selling point of LLM assistants is not having to read or write anymore.

I think a lot of the "AI Addicts" are masking illiteracy, which is why they cling so passionately to the technology.

So the next edition of clean code will be called “clean test code”?

My current code base has more tests than runtime code. This sounds far more thorough than that. If you limit the possible productivity improvement to a small portion of total effort, it's inherently also going to be a small improvement.

Which, is fine, but not what most people are hoping for with these tools.

Well, Uncle Bob has always been a hack so this isn't too surprising

So no human in the loop then? Sounds like a recipe for tech debt…

the expensive bugs are usually gaps in the spec itself

When my nephew went into computer science, I had to warn him about the bracelet cult people

maybe the definition of 'clean code' in the agentic era should be changed to 'the code that complies to the specs, the design constraints and the exhaustive scenario test suite';

this is definitely a better outcome since all the human effort now shifts to spec, design, test scenarios tailored to the domain - as it should be.

having seen my share of human slop through decades (mine included), finally it's a relief to not have to deal with devs that don't have high standards, and the endless arguments/politics that ensue.

with llm it's just a text file away from compliance.

> I’m significantly older than you. I started coding in the late 60s.

Any opinion that starts with such a blatant appeal to authority can safely be ignored.

[flagged]

[flagged]

[flagged]

[flagged]

Robert Martin, the author of Clean Code, is a caustic dick defending a book full of spurious commandments. I don't put any stock in his takes.

>My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity.

When you start getting good results from agents you soon realize you are the bottleneck.

Automating the verification of the code is the way to go, otherwise it's just not worth it. It takes longer to read and understand code than to write code, so why bother with agents if you are going to manually review it all anyway?

One thing I miss after ditching Copilot (it got too expensive) was how I could trivially ask for features to be written by one model and verified by another. Have Opus write it and GPT or Gemini verify it.

I figured they were entirely separate models and therefore unlikely to hallucinate in the same way, so it gave me a quick sense of confidence.

Currently I use claude code (different models but all variants of the same) so I have them do planning, review of the plan, implementation, review of the implementation, and unit tests. It's fine, but copilot felt easier.