HI version is available. Content is displayed in original English for accuracy.
https://xcancel.com/unclebobmartin/status/2080257779395154409?s=20
HI version is available. Content is displayed in original English for accuracy.
Discussion Sentiment
Analyzed from 1400 words in the discussion.
Trending Topics
Discussion (41 Comments)Read Original on HackerNews
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.
I haven’t seen it do that in quite a while, but it was an interesting failure mode!
I like optionals, but I see his point too.
But at the end of the day, he's a guy with a long career in programming, which makes him significantly better than the median, but it doesn't make him three sigma above.
In this case, he's got a pretty good short- to medium-term argument that if you have a robust testing and verification suite, AI code that passes it all is a terrific outcome.
I'm really not convinced about long-term. Possibly, AI ends up writing even better in the future and we never have to worry about human maintainability.
But it's also possible AI is at/near its limit, and we'll always need human maintainers. In which case, incomprehensible vibe coding might be a problem.
This does not require a new language feature every time there is a bug, as he asserts. It requires language features to let you be descriptive in your type definitions so that invalid program states don't exist by definition. You literally cannot write one down. It's the same idea as saying you can't assign a Monkey to an int64. Scala's ZIO also shows that in fact you can type-infer whether a given path will produce errors or nulls, so you don't need to have perfect knowledge up front or go back and change tons of code if that changes. Errors can automatically propagate, and you need to handle them once, somewhere. Checked exceptions were a fantastic idea; you just need to let the compiler infer them everywhere.
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.
If you want even greater fun, launch claude and codex in the same working tree and make them fight it out in real time.
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.)
Then if you're not paying attention, one mistake asserted confidently in tests, docs, code comments, and commits can send the codebase in a completely wrong direction, which the subsequent agent picks up on without you noticing.
Which, is fine, but not what most people are hoping for with these tools.
I think a lot of the "AI Addicts" are masking illiteracy, which is why they cling so passionately to the technology.
Do you think that we're going to use less RAM with AI produced code?
and suddenly things work again, it's magic!
Any opinion that starts with such a blatant appeal to authority can safely be ignored.
Robert Martin started coding in the late 60s and then became an author and a software design consultant - his statement defines the start date of his relevant experience but doesn't speak to the end date of that experience or the density of his experience. He has a wealth of experience but not in a field that's relevant to his comment.
I think an appeal to authority is a good basis for extending a bit of extra trust to statements - but you should always verify things yourself.
> Started programming in 1983. Old?
I took that sentence as asking if he was old because he couldn’t trust AI and uncle bob brought up that he was much older and trusted the AI output because he trusted his constraints and test harnesses
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.