Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by lilerjee
  • Well, he knows where is toast is buttered
    by a34729t
  • 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?
    by jubilanti
  • 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.)

    by 2001zhaozhao
  • Well, Uncle Bob has always been a hack so this isn't too surprising
    by bluefirebrand
  • 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.
    by remywang
  • 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.

    by rich_sasha
  • 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).
    by anvuong
  • Yeah, if I were him, I too would be thrilled with not having to review another AbstractSingletonProxyFactoryBean.
    by ryandvm
  • Ironically from my experience seeing AI code a lot, it probably follows his clean code verbosity beautifully
    by rpunkfu
  • 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.

    by andai
  • Wait, did you let the same agent write the tests that wrote the implementation? Or was it that the plan was the wrong way round, and both the generator of code and the generator of the tests followed that same incorrect plan?

    Also, what were your mechanisms for reviewing the plan against the described business outcome? Anything else you could have done there to catch the backwardness?

    And finally, did you run any of it across models from different foundation labs? I'll often run important stuff generated by codex across Anthropic, grok, and Gemini with an opus or fable judge...

    by peterbell_nyc
  • What do you mean by "completely backwards"?
    by simonw
  • A few models ago it was not unusual to find that Claude had written tests whose assertions looked correct, but were so thoroughly mocked out that they ran no real code at all — a Potemkin test.

    I haven’t seen it do that in quite a while, but it was an interesting failure mode!

    by wrs
  • This is the guy that thinks optionals are too complicated? https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...
    by daaaaaaan
  • Interesting read. To his defense: the argument is not that Optionals are too complicated, but that it’s a wrong path for language design — instead programmers have to test their code properly.

    I like optionals, but I see his point too.

    by reliabilityguy
  • 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.
    by jvanderbot
  • "How does Uncle Bob code today? Find out in Clean Vibe, the long-awaited sequel to the legendary Clean Code - coming soon from Prentice Hall!"
    by rob74