6 ms·

Uncle Bob: It's Over

62 points by lopespm 5mo ago

monkpit 5mo ago
It’s hard to give up, but likely necessary. That doesn’t mean quality has to suffer, we can still gate with deterministic quality tooling where it matters. But yeah, at some scale it stops mattering how human readable the code is, as long as AI can effectively and efficiently (token-wise) make edits or add features.
- nine_k 5mo ago
  The point is not human readability, but good structure. Spaghetti code is as bad for an LLM as for a human, because structural complexity and the amount of coupling are fundamental limits, not human-specific.
  - renticulous 5mo ago
    Amazing tweet. https://x.com/stevesi/status/2050325415793951124 https://x.com/stevesi/status/2050325415793951124 Here's how history rhymes with this logic. The development of compilers v writing assembly language was not without a very similar "controversy" — that is, are the new tools more efficient or less efficient. The first compilers were measured relative to hand-tuned assembly language efficiency. The existing world of compute was very much "compute bound" and inefficient code was being chased out of every system. The introduction of the first compilers generally delivered code "within 10-30%" as efficient as standard professional assembly. This "benchmark" was enough for almost a generation of Fortran programmers to dismiss the capabilities of compilers. Also worth noting, early compilers (all through the 1980s) routinely had bugs that generated incorrect code. Debugging a compiler is a nightmare (personal experience). This only provided more "ammo." With the arrival of COBOL the debate started to shift. COBOL generated decidedly "bloated" code so there was no way to win the efficiency argument. But what people started to realize was that a "modern" programming language made it possible to deliver vastly more software and for many more people to work on the same code (ASM notorious for being challenging for multiple engineers on the same portion of code). So the metric slowly started to move from "as good as hand tuned assembler" to "able to write bigger, more sophisticated code in less time with more people). Computers gained timesharing, more memory, and faster CPUs which made the efficiency argument far less compelling (only to repeat with the first 8K or 64K PCs). This entire transition is capped off with a description in Fred Brooks "Mythical Man Month" book, one of the seminal books in the field of programming and standard issue book sitting in my office waiting for me on my first day at Microsoft. (See full book free here https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...) It is very early. I was not a programmer when the above happened though I did join the professional ranks while many still held these beliefs. For example, I interned writing COBOL on mainframes while PCs were using C and Pascal which were buggy and viewed as inefficient on processor/space-constrained PCs. The debate would continue with C++, garbage collection, interpreted v compiled (Visual Basic) and more. As a fairly consistent observation over decades, every new tool is viewed through a lens (at first) by experienced programmers over what is worse while new programmers use the tool and operate in a new context (eg "more software" or "bigger projects"). The excerpt below shows this debate as captured in 1972.
    - lelanthran 5mo ago
      > Also worth noting, early compilers (all through the 1980s) routinely had bugs that generated incorrect code. Incorrect. They had bugs that generated incorrect code. They didn't routinely have bugs that generated incorrect code :-/ And the bugs they had were reproducible.
      - renticulous 5mo ago
        Didn't someone say LLMs memorize Harry Potter books? You can't have it both ways.
        lelanthran 5mo ago
        > Didn't someone say LLMs memorize Harry Potter books? You can't have it both ways. What both ways? You can't consistently get it to output Harry Potter verbatim. That's my point - not reproducible.
        renticulous 5mo ago
        There are many ways to write a forloop. Why do you need exact reproducibility for achieving a task?
        customguy 5mo ago
        Not "exact reproducibility", but simple reproducibility at all. You need that to fix bugs, improve things and reason about them.
        lelanthran 5mo ago
        > There are many ways to write a forloop. Why do you need exact reproducibility for achieving a task? Didn't you just claim above, with the Harry Potter angle, that it is reproducible?
  - monkpit 5mo ago
    That’s where the tooling comes in!
duped 5mo ago
I fully believe AI can write better code faster than Robert C. Martin.
GiorgioG 5mo ago
Clean Architecture and Uncle Bob can take a hike.
- Applejinx 5mo ago
  This. Uncle Bob was already over, and now he seems to be hitting the skids REAL bad. Just listening to him is tough: this guy's bad news, I didn't realize he was this bad off.
abbadadda 5mo ago
I thought this was about Uncle Bob being “canceled.”
- Kwpolska 5mo ago
  Which is long overdue.
  - an0malous 5mo ago
    What did he do?
    - 2ndorderthought 5mo ago
      Wealthy white dude edging towards senility taking a liking to bathrobe social media shorts. Take a guess. It's going to involve a political party and a lot of weird public takes unrelated to software.
      - amarant 5mo ago
        White men are not allowed to grow old? How come? Doesn't really seem fair, I'm gonna be a old white man some day, ain't really that much I can do about it...(Well, I suppose sex changes are a thing now, but really?)
        2ndorderthought 5mo ago
        Of course they are. I'm only stating a trend so people can infer.
        wizzwizz4 5mo ago
        Are you going to be wealthy, with your head buried in the firehose of an algorithmic feed? Those are things you can do something about. Alternatively, you could take a crack at deconstructing whiteness. Depending how young you currently are, you might be able to make a dent by the time you're an old man. That's trickier though, because it involves serious social reform. Or if sociology isn't your deal, maybe you could become a biologist, and cure old age?
RobRivera 5mo ago
That's just, like, his opinion man
- runarberg 5mo ago
  His opinions were never really good to begin with, he was just excellent at marketing them as good opinions. It comes as no surprise to me that the guy who has bad opinions about software architecture, has worse opinions about vibe coding.
  - deleted 5mo ago
    [deleted]
- Bridged7756 5mo ago
  He's an idol, didn't you know? Much like his software architecture takes, they'll be taken as gospel.
- livinglist 5mo ago
  Personally I have never been a fan of clean code architecture…to each their own I guess
adriand 5mo ago
Kind of a great video! I enjoyed it. His point about testing coverage and generating mutations to ensure the tests fail resonated. I get concerned sometimes that the AI is writing tests not to ensure the logic is correct, but to ensure the tests pass against the code it already wrote. Any other ideas on this? Is there a code review step or CI checkpoint that would decrease the likelihood of that?
- ozlikethewizard 5mo ago
  To be fair the overwhelming majority of tests I've seen in the wild written by humans have been the same. Not a lot of good material for AI to learn from.
relativeadv 5mo ago
"Forty years later, in September of 2018, I started working on this version of Space War. It's an animated GUI driven system with a frame rate of 30fps. It is written entirely in Clojure and uses the Quil shim for the Processing GUI framework." - Robert Martin https://blog.cleancoder.com/uncle-bob/2021/11/28/Spacewar.html https://blog.cleancoder.com/uncle-bob/2021/11/28/Spacewar.ht...
tgma 5mo ago
For all LLM flaws, if it kills the whole Agile/SCRUM/whatever grift, it will have been worth it. The damage these guys have done to software industry at large is unfathomable.
- whstl 5mo ago
  Hot take, but the bureaucracy of Scrum, the Figmafication of design and the disdain of PMs for iterative deliveries generates more work and waste than AIs are able to save.
MeetingsBrowser 5mo ago
The craziest thing about AI is you can just try it yourself and check if the claims are true. I use Claude code and codex daily. They have become an integral part of my workflow. There is no task that takes me a day that they can complete in five minutes. Even with the lightning fast progress being made, it looks like LLMs are a decade or more away from being that good. If AI can do your job for you, you should be the first to know. Just try it and see!
- qudat 5mo ago
  Fundamentally it cannot be much better than how well we can write the spec and then validate the results. It’s always gonna be a multi shot process. And it can already write code good enough. That’s no longer the bottleneck. Further, Qwen 27b is such an incredible masterpiece for coding and it can run on consumer hardware today. Anthropic/OpenAI are gonna give up on coding models very soon. There’s not gonna be any money in it when you can run your own local model for significantly cheaper. Qwen27b is not SOTA but the value is insane. You can basically use it for small tasks and then route harder problems to opus or sonnet and boom you’ve said a lot of money.
- soupspaces 5mo ago
  [dead]
- 2ndorderthought 5mo ago
  Super trivial to hand verify 350kloc changes for sure.
  - qayxc 5mo ago
    Quis custodiet ipsos custodes?
- Aeolun 5mo ago
  > There is no task that takes me a day that they can complete in five minutes. Five minutes is pushing it, but 15 minutes? Absolutely.
- 5mo ago
doginasuit 5mo ago
There are probably some respectable workflows that involve an LLM writing most of the code, but AI is still terrible at understanding some critical parts of the problem. You still have to tell it what to write and how it should work or there are high odds that you'll get a hot mess. And there still needs to be a human that understands everything there and how to debug it. For me, the most enjoyable path there is to write it myself, because I would rather be involved in writing the code than only involved in reading it. It might not be the fastest path there, but it gets the job done for the foreseeable future. I could end up like the Amish who choose not to use technology that was developed after a certain point, from what I can tell they do alright.
- tonyarkles 5mo ago
  > but AI is still terrible at understanding some critical parts of the problem I agree to some extent with regards to writing new code. One piece where I have been perpetually impressed is at asking it to put together a plausible explanation of how something weird has happened. I have been blown away, multiple times, by Codex and Claude’s ability to take a prompt like “When I did X, I expected Y to happen but instead observed Z. Put together an explanation for how that could happen, including the individual lines of code that can lead to ending up in that state.” In one notable case, it traced through a pretty complex sensor fusion -> computational geometry problem and identified a particular calculation far upstream that could go negative in certain circumstances, which would lead to a function far downstream generating a polygon with incorrect winding order (clockwise instead of CCW). In another, it identified a variable that was being initialized to 0 instead of initialized to (a specific runtime value that it should’ve been initialized to during a state transition). The downstream effect, minutes later, would be pathological behaviour that would happen exactly once per boot. In both cases I was provided with a specific causal chain of events with individual source files and line numbers so that I could verify the plausibility of the explanation myself.
  - doginasuit 5mo ago
    That is how I use it too, for explanations and suggestions when I run into something unexpected. It is incredible in the back seat. I don't mean to completely dismiss their utility. I realized recently that I was having more fun coding than I ever remember. It is a strange feeling to go along with vibe out there that software developers are becoming obsolete.
daviding 5mo ago
English is the new programming language.
- benatkin 5mo ago
  I'm not sure I agree, but I can see it used as an open-ended interview question. "Is English the new programming language?" It would be a good test if someone gravitates towards pedantry (AIs can speak another common language just as well!) or if they actually get into the difference between prompting and programming, or whether it's at its core an LLM or just an AI based on transformer architecture. Extra points for having it be part of an async interview and interviewees using an LLM to write the answer, and interviewers using LLMs to grade them.
LaGrange 5mo ago
I'm an AI skeptic, but I do think that _he_ will be out-coded by AI, no problem.
perrygeo 5mo ago
I tend to agree with his point. But I found myself laughing at the style; just ranting about software like a cartoon villain in his bathrobe. No fucks given.
mrcartmeneses 5mo ago
Uncle Bob full of shit? Colour me purple!
julionc 5mo ago
"It is unavoidable. It is your destiny. You, like your father, are now mine."
HumblyTossed 5mo ago
He helped enshitify the industry - empowering midlings to cry about "clean code" instead of actually learning to produce a great product. No thanks, Bob.
OldSchool 5mo ago
More "bad news" and from the man who helped create and then promote Agile to dilute the value of software developers by forcing software development out of the control freak's nightmare where it started: seemingly esoteric, non-understandable by management, and make sure the next generation of developers knows their place. That's Agile's insidious purpose as far I am concerned. As for AI-written code, I wouldn't fly on a plane controlled by AI-designed and AI-tested code, but much of development is busy work, not problem solving or design. AI excels at turning a protocol spec into a parser for example. I'll take that any day. AI excels at finding stuff, particularly non-code, thesis-level ideas for algorithms and also at about the same level, what's been shown not to work when solving a non-deterministic problem. If we're lucky, AI will fill in after exposing who is only doing busy work and who is creating.
- znort_ 5mo ago
  i had to laugh at his announcement that "otoh ai will give you the power to get all that coverage and cyclomatic complexity stats done in minutes, which you know doesn't really mean that the code is going to work". also, his prediction assumes that ai will be able to learn from its own code going forward. will it also create its new programming languages and tools? but it's a funny rant.
- HeavyStorm 5mo ago
  That's a conspiracy theory if I ever heard one.
- mvdtnz 5mo ago
  Your claim is that software developer value has been diluted in the past 20 years? Have you ever compared software developer salaries to the jobs with similar skill levels?
  - OldSchool 5mo ago
    I will suggest that for sure it was way easier to get an engineering job in the 80's, 90's, even 00's. Offering one resume and getting one interview and one job offer soon after wasn't uncommon. I was an employer for a decade in the 90s and I didn't think to haze any candidates or demand huge amounts of their time on speculation: I wanted honest people who were great problem solvers; you know them when you meet them. The first clue is they know about a lot of things outside of the field you are working in as well, this shows up as a very visibly and broadly capable person, making them notably self-reliant. Everyone I hired got up to speed and stayed until well after we were acquired. As for my opinion on Agile: creating a management system to corral people without these skills doesn't magically create these skills for you in the aggregate; it might be more robust to the influence of one individual but that is a side effect of the real goal of hiring from a much broader pool, and ensuring that nobody is overly critical at the cost of headcount and ironically, agility in the business world to quickly follow opportunities.
oytis 5mo ago
That gotta be a joke right? It's like running agents to write agent ochestrators to write orchestrators for orchestrators just for clean code
cmiles74 5mo ago
I don't have a lot of patience for Bob. That being said I have to agree with him on test coverage (that's as far as I made it through his monologue). IMHO, that is something that I 100% am okay letting the LLM tooling write and manage. I used to argue about whether or not we needed a test that verified that the value of a constant didn't change, and if 100% coverage was really that important. Now I don't care, I just let Claude write the test and keep it up-to-date.
andrewl 5mo ago
That was a bizarre performance.
k3vinw 5mo ago
Gives me a whole new perspective to the phrase clean code.
bdangubic 5mo ago
spent a 30-year lustrous SWE career avoiding reading and listening anything this dude says, probably among the smartest things I’ve ever done
recursivedoubts 5mo ago
"it can chop up all your functions into tiny functions..." And now you just played yourself, by creating a morass of tiny functions. Well tested (CRAP says so!) And impossible to understand how they compose together. AI will happily return the next token and ruin your codebase, if you ask it.
- cmiles74 5mo ago
  Creating functions that are only used once, in one place, and are pretty small is on of those things I give a harder look at during PR review.
janpeuker 5mo ago
Yes I get the irony but also let's not forget that it's over for the Code that Uncle Bob likes. Which is bad, verbose, dogmatic, unreadable, elitist code [1] with "discipline" [2] and a dash of sexism. And that has luckily been over for a _long_ time before LLMs. 1) https://qntm.org/clean https://qntm.org/clean 2) https://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotTheAnswer.html https://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotTh...
aleyan 5mo ago
Over on reddit and over here as well people seems to be reacting to the title of the video or the first 5 seconds or just the author. On the original x[1] post however, the top replies are about the subject matter, which is about having agents write tests and refactor code. And speaking of agents writing tests, I have an ask. The tests agents love to write are in a lot of ways like human written tests, perfunctory and smelly. They are there to check coverage or prompt checkbox, but they barely stress the system under test. I often find that the tests are faking and mocking so many inputs, methods, and side effects, that they aren't testing anything at all. Asking the agent to write the tests first so that they the underlying implementation is more testable has yielded no results. What has worked for people to get agents to write more testable implementations and better tests? PS. Reacting to Uncle Bob, I found metric driven agentic refactors just push complexity to outside the scope of the metric. I am finding I need to actively guide the agents for the refactors to actually improve things without increasing the entropy of the codebase. [1] https://x.com/unclebobmartin/status/2046206145597972849 https://x.com/unclebobmartin/status/2046206145597972849
- silexia 5mo ago
  X is fantastic, especially with Community Notes informing you of all the false propaganda the other platforms, including HN, are rife with.
k3vinw 5mo ago
I’m not so sure. I had a recent experience where Kiro was convinced there was a defect in the testing library when I asked it to refactor some existing project code. However this conclusion made no sense as we had similar scenarios across our project that worked flawlessly. After intervening I determined the root cause was a combination of an async issue with the production code and some incorrect mocking that was covering up the async issue. It never occurred to the AI agent to do some simple cross examination before essentially throwing in the towel?
- Fire-Dragon-DoL 5mo ago
  I think uncle bob meant you are not going to type the code anymore, not that you stop coding. I would argue your example is exactly the reason why you need to supervise AI
  - k3vinw 5mo ago
    Fair point. I’m still learning how best to take advantage of Ai. And to be honest, a statically typed language would have caught the issue with the wrong return type before the AI tool.
KevinMS 5mo ago
Shouldn't we first find out how much it actually costs before we reach these conclusions?
vga1 5mo ago
Using LLMs is so obviously great from my point-of-view and when I read about the skepticism, some of which even seems scientifically proven, I get a funny deja vu feeling. I started using Linux back when most people were super excited about Windows 98. This is what it kinda feels like now. I'm forced to conclude that either I'm having the worst cognitive dissonance of my life or perhaps I'm just that much better at using LLMs.
rstuart4133 5mo ago
He made a lot of assertions beyond the one in the headline: "Tests force better structured code" and "Mutation testing makes the LLM produce code with fewer bugs" are two examples. Most sounded plausible. But the delivery style of a monologue of rapid fire assertions made the entire thing very hard to accept. A little bit of hard evidence would be nice. In fact it would be more than nice. Firm anchors in the form of published results of real experiments on how you can make LLMs produce different styles of code would be golden right now. I'm sure I'm not the only one flailing around looking for good ways to use these newfangled tools.

62 points by lopespm 5mo ago

It’s hard to give up, but likely necessary. That doesn’t mean quality has to suffer, we can still gate with deterministic quality tooling where it matters. But yeah, at some scale it stops mattering how human readable the code is, as long as AI can effectively and efficiently (token-wise) make edits or add features.

nine_k 5mo ago
The point is not human readability, but good structure. Spaghetti code is as bad for an LLM as for a human, because structural complexity and the amount of coupling are fundamental limits, not human-specific.
- renticulous 5mo ago
  Amazing tweet. https://x.com/stevesi/status/2050325415793951124 https://x.com/stevesi/status/2050325415793951124 Here's how history rhymes with this logic. The development of compilers v writing assembly language was not without a very similar "controversy" — that is, are the new tools more efficient or less efficient. The first compilers were measured relative to hand-tuned assembly language efficiency. The existing world of compute was very much "compute bound" and inefficient code was being chased out of every system. The introduction of the first compilers generally delivered code "within 10-30%" as efficient as standard professional assembly. This "benchmark" was enough for almost a generation of Fortran programmers to dismiss the capabilities of compilers. Also worth noting, early compilers (all through the 1980s) routinely had bugs that generated incorrect code. Debugging a compiler is a nightmare (personal experience). This only provided more "ammo." With the arrival of COBOL the debate started to shift. COBOL generated decidedly "bloated" code so there was no way to win the efficiency argument. But what people started to realize was that a "modern" programming language made it possible to deliver vastly more software and for many more people to work on the same code (ASM notorious for being challenging for multiple engineers on the same portion of code). So the metric slowly started to move from "as good as hand tuned assembler" to "able to write bigger, more sophisticated code in less time with more people). Computers gained timesharing, more memory, and faster CPUs which made the efficiency argument far less compelling (only to repeat with the first 8K or 64K PCs). This entire transition is capped off with a description in Fred Brooks "Mythical Man Month" book, one of the seminal books in the field of programming and standard issue book sitting in my office waiting for me on my first day at Microsoft. (See full book free here https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...) It is very early. I was not a programmer when the above happened though I did join the professional ranks while many still held these beliefs. For example, I interned writing COBOL on mainframes while PCs were using C and Pascal which were buggy and viewed as inefficient on processor/space-constrained PCs. The debate would continue with C++, garbage collection, interpreted v compiled (Visual Basic) and more. As a fairly consistent observation over decades, every new tool is viewed through a lens (at first) by experienced programmers over what is worse while new programmers use the tool and operate in a new context (eg "more software" or "bigger projects"). The excerpt below shows this debate as captured in 1972.
  - lelanthran 5mo ago
    > Also worth noting, early compilers (all through the 1980s) routinely had bugs that generated incorrect code. Incorrect. They had bugs that generated incorrect code. They didn't routinely have bugs that generated incorrect code :-/ And the bugs they had were reproducible.
    - renticulous 5mo ago
      Didn't someone say LLMs memorize Harry Potter books? You can't have it both ways.
      - lelanthran 5mo ago
        > Didn't someone say LLMs memorize Harry Potter books? You can't have it both ways. What both ways? You can't consistently get it to output Harry Potter verbatim. That's my point - not reproducible.
        renticulous 5mo ago
        There are many ways to write a forloop. Why do you need exact reproducibility for achieving a task?
        customguy 5mo ago
        Not "exact reproducibility", but simple reproducibility at all. You need that to fix bugs, improve things and reason about them.
        lelanthran 5mo ago
        > There are many ways to write a forloop. Why do you need exact reproducibility for achieving a task? Didn't you just claim above, with the Harry Potter angle, that it is reproducible?
- monkpit 5mo ago
  That’s where the tooling comes in!

duped 5mo ago

I fully believe AI can write better code faster than Robert C. Martin.

GiorgioG 5mo ago

Clean Architecture and Uncle Bob can take a hike.

Applejinx 5mo ago
This. Uncle Bob was already over, and now he seems to be hitting the skids REAL bad. Just listening to him is tough: this guy's bad news, I didn't realize he was this bad off.

abbadadda 5mo ago

I thought this was about Uncle Bob being “canceled.”

Kwpolska 5mo ago
Which is long overdue.
- an0malous 5mo ago
  What did he do?
  - 2ndorderthought 5mo ago
    Wealthy white dude edging towards senility taking a liking to bathrobe social media shorts. Take a guess. It's going to involve a political party and a lot of weird public takes unrelated to software.
    - amarant 5mo ago
      White men are not allowed to grow old? How come? Doesn't really seem fair, I'm gonna be a old white man some day, ain't really that much I can do about it...(Well, I suppose sex changes are a thing now, but really?)
      - 2ndorderthought 5mo ago
        Of course they are. I'm only stating a trend so people can infer.
      - wizzwizz4 5mo ago
        Are you going to be wealthy, with your head buried in the firehose of an algorithmic feed? Those are things you can do something about. Alternatively, you could take a crack at deconstructing whiteness. Depending how young you currently are, you might be able to make a dent by the time you're an old man. That's trickier though, because it involves serious social reform. Or if sociology isn't your deal, maybe you could become a biologist, and cure old age?

RobRivera 5mo ago

That's just, like, his opinion man

runarberg 5mo ago
His opinions were never really good to begin with, he was just excellent at marketing them as good opinions. It comes as no surprise to me that the guy who has bad opinions about software architecture, has worse opinions about vibe coding.
- deleted 5mo ago
  [deleted]
Bridged7756 5mo ago
He's an idol, didn't you know? Much like his software architecture takes, they'll be taken as gospel.
livinglist 5mo ago
Personally I have never been a fan of clean code architecture…to each their own I guess

adriand 5mo ago

Kind of a great video! I enjoyed it. His point about testing coverage and generating mutations to ensure the tests fail resonated. I get concerned sometimes that the AI is writing tests not to ensure the logic is correct, but to ensure the tests pass against the code it already wrote. Any other ideas on this? Is there a code review step or CI checkpoint that would decrease the likelihood of that?

ozlikethewizard 5mo ago
To be fair the overwhelming majority of tests I've seen in the wild written by humans have been the same. Not a lot of good material for AI to learn from.

relativeadv 5mo ago

"Forty years later, in September of 2018, I started working on this version of Space War. It's an animated GUI driven system with a frame rate of 30fps. It is written entirely in Clojure and uses the Quil shim for the Processing GUI framework." - Robert Martin https://blog.cleancoder.com/uncle-bob/2021/11/28/Spacewar.html https://blog.cleancoder.com/uncle-bob/2021/11/28/Spacewar.ht...

tgma 5mo ago

For all LLM flaws, if it kills the whole Agile/SCRUM/whatever grift, it will have been worth it. The damage these guys have done to software industry at large is unfathomable.

whstl 5mo ago
Hot take, but the bureaucracy of Scrum, the Figmafication of design and the disdain of PMs for iterative deliveries generates more work and waste than AIs are able to save.

MeetingsBrowser 5mo ago

The craziest thing about AI is you can just try it yourself and check if the claims are true. I use Claude code and codex daily. They have become an integral part of my workflow. There is no task that takes me a day that they can complete in five minutes. Even with the lightning fast progress being made, it looks like LLMs are a decade or more away from being that good. If AI can do your job for you, you should be the first to know. Just try it and see!

qudat 5mo ago
Fundamentally it cannot be much better than how well we can write the spec and then validate the results. It’s always gonna be a multi shot process. And it can already write code good enough. That’s no longer the bottleneck. Further, Qwen 27b is such an incredible masterpiece for coding and it can run on consumer hardware today. Anthropic/OpenAI are gonna give up on coding models very soon. There’s not gonna be any money in it when you can run your own local model for significantly cheaper. Qwen27b is not SOTA but the value is insane. You can basically use it for small tasks and then route harder problems to opus or sonnet and boom you’ve said a lot of money.
soupspaces 5mo ago
[dead]
2ndorderthought 5mo ago
Super trivial to hand verify 350kloc changes for sure.
- qayxc 5mo ago
  Quis custodiet ipsos custodes?
Aeolun 5mo ago
> There is no task that takes me a day that they can complete in five minutes. Five minutes is pushing it, but 15 minutes? Absolutely.
5mo ago

doginasuit 5mo ago

There are probably some respectable workflows that involve an LLM writing most of the code, but AI is still terrible at understanding some critical parts of the problem. You still have to tell it what to write and how it should work or there are high odds that you'll get a hot mess. And there still needs to be a human that understands everything there and how to debug it. For me, the most enjoyable path there is to write it myself, because I would rather be involved in writing the code than only involved in reading it. It might not be the fastest path there, but it gets the job done for the foreseeable future. I could end up like the Amish who choose not to use technology that was developed after a certain point, from what I can tell they do alright.

tonyarkles 5mo ago
> but AI is still terrible at understanding some critical parts of the problem I agree to some extent with regards to writing new code. One piece where I have been perpetually impressed is at asking it to put together a plausible explanation of how something weird has happened. I have been blown away, multiple times, by Codex and Claude’s ability to take a prompt like “When I did X, I expected Y to happen but instead observed Z. Put together an explanation for how that could happen, including the individual lines of code that can lead to ending up in that state.” In one notable case, it traced through a pretty complex sensor fusion -> computational geometry problem and identified a particular calculation far upstream that could go negative in certain circumstances, which would lead to a function far downstream generating a polygon with incorrect winding order (clockwise instead of CCW). In another, it identified a variable that was being initialized to 0 instead of initialized to (a specific runtime value that it should’ve been initialized to during a state transition). The downstream effect, minutes later, would be pathological behaviour that would happen exactly once per boot. In both cases I was provided with a specific causal chain of events with individual source files and line numbers so that I could verify the plausibility of the explanation myself.
- doginasuit 5mo ago
  That is how I use it too, for explanations and suggestions when I run into something unexpected. It is incredible in the back seat. I don't mean to completely dismiss their utility. I realized recently that I was having more fun coding than I ever remember. It is a strange feeling to go along with vibe out there that software developers are becoming obsolete.

daviding 5mo ago

English is the new programming language.

benatkin 5mo ago
I'm not sure I agree, but I can see it used as an open-ended interview question. "Is English the new programming language?" It would be a good test if someone gravitates towards pedantry (AIs can speak another common language just as well!) or if they actually get into the difference between prompting and programming, or whether it's at its core an LLM or just an AI based on transformer architecture. Extra points for having it be part of an async interview and interviewees using an LLM to write the answer, and interviewers using LLMs to grade them.

LaGrange 5mo ago

I'm an AI skeptic, but I do think that _he_ will be out-coded by AI, no problem.

perrygeo 5mo ago

I tend to agree with his point. But I found myself laughing at the style; just ranting about software like a cartoon villain in his bathrobe. No fucks given.

mrcartmeneses 5mo ago

Uncle Bob full of shit? Colour me purple!

julionc 5mo ago

"It is unavoidable. It is your destiny. You, like your father, are now mine."

HumblyTossed 5mo ago

He helped enshitify the industry - empowering midlings to cry about "clean code" instead of actually learning to produce a great product. No thanks, Bob.

OldSchool 5mo ago

More "bad news" and from the man who helped create and then promote Agile to dilute the value of software developers by forcing software development out of the control freak's nightmare where it started: seemingly esoteric, non-understandable by management, and make sure the next generation of developers knows their place. That's Agile's insidious purpose as far I am concerned. As for AI-written code, I wouldn't fly on a plane controlled by AI-designed and AI-tested code, but much of development is busy work, not problem solving or design. AI excels at turning a protocol spec into a parser for example. I'll take that any day. AI excels at finding stuff, particularly non-code, thesis-level ideas for algorithms and also at about the same level, what's been shown not to work when solving a non-deterministic problem. If we're lucky, AI will fill in after exposing who is only doing busy work and who is creating.

znort_ 5mo ago
i had to laugh at his announcement that "otoh ai will give you the power to get all that coverage and cyclomatic complexity stats done in minutes, which you know doesn't really mean that the code is going to work". also, his prediction assumes that ai will be able to learn from its own code going forward. will it also create its new programming languages and tools? but it's a funny rant.
HeavyStorm 5mo ago
That's a conspiracy theory if I ever heard one.
mvdtnz 5mo ago
Your claim is that software developer value has been diluted in the past 20 years? Have you ever compared software developer salaries to the jobs with similar skill levels?
- OldSchool 5mo ago
  I will suggest that for sure it was way easier to get an engineering job in the 80's, 90's, even 00's. Offering one resume and getting one interview and one job offer soon after wasn't uncommon. I was an employer for a decade in the 90s and I didn't think to haze any candidates or demand huge amounts of their time on speculation: I wanted honest people who were great problem solvers; you know them when you meet them. The first clue is they know about a lot of things outside of the field you are working in as well, this shows up as a very visibly and broadly capable person, making them notably self-reliant. Everyone I hired got up to speed and stayed until well after we were acquired. As for my opinion on Agile: creating a management system to corral people without these skills doesn't magically create these skills for you in the aggregate; it might be more robust to the influence of one individual but that is a side effect of the real goal of hiring from a much broader pool, and ensuring that nobody is overly critical at the cost of headcount and ironically, agility in the business world to quickly follow opportunities.

oytis 5mo ago

That gotta be a joke right? It's like running agents to write agent ochestrators to write orchestrators for orchestrators just for clean code

cmiles74 5mo ago

I don't have a lot of patience for Bob. That being said I have to agree with him on test coverage (that's as far as I made it through his monologue). IMHO, that is something that I 100% am okay letting the LLM tooling write and manage. I used to argue about whether or not we needed a test that verified that the value of a constant didn't change, and if 100% coverage was really that important. Now I don't care, I just let Claude write the test and keep it up-to-date.

andrewl 5mo ago

That was a bizarre performance.

k3vinw 5mo ago

Gives me a whole new perspective to the phrase clean code.

bdangubic 5mo ago

spent a 30-year lustrous SWE career avoiding reading and listening anything this dude says, probably among the smartest things I’ve ever done

recursivedoubts 5mo ago

"it can chop up all your functions into tiny functions..." And now you just played yourself, by creating a morass of tiny functions. Well tested (CRAP says so!) And impossible to understand how they compose together. AI will happily return the next token and ruin your codebase, if you ask it.

cmiles74 5mo ago
Creating functions that are only used once, in one place, and are pretty small is on of those things I give a harder look at during PR review.

janpeuker 5mo ago

Yes I get the irony but also let's not forget that it's over for the Code that Uncle Bob likes. Which is bad, verbose, dogmatic, unreadable, elitist code [1] with "discipline" [2] and a dash of sexism. And that has luckily been over for a _long_ time before LLMs. 1) https://qntm.org/clean https://qntm.org/clean 2) https://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotTheAnswer.html https://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotTh...

aleyan 5mo ago

Over on reddit and over here as well people seems to be reacting to the title of the video or the first 5 seconds or just the author. On the original x[1] post however, the top replies are about the subject matter, which is about having agents write tests and refactor code. And speaking of agents writing tests, I have an ask. The tests agents love to write are in a lot of ways like human written tests, perfunctory and smelly. They are there to check coverage or prompt checkbox, but they barely stress the system under test. I often find that the tests are faking and mocking so many inputs, methods, and side effects, that they aren't testing anything at all. Asking the agent to write the tests first so that they the underlying implementation is more testable has yielded no results. What has worked for people to get agents to write more testable implementations and better tests? PS. Reacting to Uncle Bob, I found metric driven agentic refactors just push complexity to outside the scope of the metric. I am finding I need to actively guide the agents for the refactors to actually improve things without increasing the entropy of the codebase. [1] https://x.com/unclebobmartin/status/2046206145597972849 https://x.com/unclebobmartin/status/2046206145597972849

silexia 5mo ago
X is fantastic, especially with Community Notes informing you of all the false propaganda the other platforms, including HN, are rife with.

k3vinw 5mo ago

I’m not so sure. I had a recent experience where Kiro was convinced there was a defect in the testing library when I asked it to refactor some existing project code. However this conclusion made no sense as we had similar scenarios across our project that worked flawlessly. After intervening I determined the root cause was a combination of an async issue with the production code and some incorrect mocking that was covering up the async issue. It never occurred to the AI agent to do some simple cross examination before essentially throwing in the towel?

Fire-Dragon-DoL 5mo ago
I think uncle bob meant you are not going to type the code anymore, not that you stop coding. I would argue your example is exactly the reason why you need to supervise AI
- k3vinw 5mo ago
  Fair point. I’m still learning how best to take advantage of Ai. And to be honest, a statically typed language would have caught the issue with the wrong return type before the AI tool.

KevinMS 5mo ago

Shouldn't we first find out how much it actually costs before we reach these conclusions?

vga1 5mo ago

Using LLMs is so obviously great from my point-of-view and when I read about the skepticism, some of which even seems scientifically proven, I get a funny deja vu feeling. I started using Linux back when most people were super excited about Windows 98. This is what it kinda feels like now. I'm forced to conclude that either I'm having the worst cognitive dissonance of my life or perhaps I'm just that much better at using LLMs.

rstuart4133 5mo ago

He made a lot of assertions beyond the one in the headline: "Tests force better structured code" and "Mutation testing makes the LLM produce code with fewer bugs" are two examples. Most sounded plausible. But the delivery style of a monologue of rapid fire assertions made the entire thing very hard to accept. A little bit of hard evidence would be nice. In fact it would be more than nice. Firm anchors in the form of published results of real experiments on how you can make LLMs produce different styles of code would be golden right now. I'm sure I'm not the only one flailing around looking for good ways to use these newfangled tools.