I'm not sure this is my experience so far. What I'm noticing is that my awesome developers have embraced AI as an accelerator, particularly for research and system design, small targeted coding activities with guardrails. My below average developers are having difficulty integrating AI at all in their workflow. If this trend continues the chasm between great and mediocre devs will widen dramatically.
AI is a floor raiser, not a ceiling raiser
161–170 of 218 posts
Re: AI is a floor raiser, not a ceiling raiser
#162Earlier quoted context omitted.
It's super obvious even if you try and use something like agent mode for coding, it starts off well but drifts off more and more. I've even had it try and do totally irrelevant things like indent some code using various Claude models.
My favourite example is something that happens quite often even with Opus, where I ask it to change a piece of code, and it does. Then I ask it to write a test for that code, it dutifully writes one. Next, I tell it to run the test, and of course, the test fails. I ask it to fix the test, it tries, but the test fails again. We repeat this dance a couple of times, and then it seemingly forgets the original request ent…
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Claude, probably
Re: AI is a floor raiser, not a ceiling raiser
#163Earlier quoted context omitted.
Yeah, the graphs make some really big assumptions that don't seem to be backed up anywhere except AI maximalist head canon. There's also a gap in addressing vibe coded "side projects" that get deployed online as a business. Is the code base super large and complex? No. Is AI capable of taking input from a novice and making something "good enough" in this space? Also no.
The later remarks are very strong assumptions underestimating the power AI tools offer. AI tools are great at unblocking and helping their users explore beyond their own understanding. The tokens in are limited to the users' comprehension, but the tokens out are generated from a vast collection of greater comprehension. For the novice, it's great at unblocking and expanding capabilities. "Good enough" results from no…
> For large and complex codebases, unfortunately the effects of tech debt (read: objectively subpar practices) translate into context rot at development time. A properly architected and documented codebase that adheres to common well structured patterns can easily be broken down into small easily digestible contexts. i.e. a fragmented codebase does not scale well with LLMs, because the fragmentation is seeding the context for the model. The model reflects and acts as an amplifier to what it's fed.
It seems like you're claiming complex codebases are hard for LLMs because of human skill issues. IME it's rather the opposite - an LLM makes it easier for a human to ramp up on what a messy codebase is actually doing, in a standard request/response model or in terms of looking at one call path (however messy) at a time. The models are well trained on such things and are much faster at deciphering what all the random branches and nested bits and pieces do.
But complex codebases actually usually arise because of changing business requirements, changing market conditions, and iteration on features and offerings. Execution quality of this varies but a "properly architected and documented codebase" is rare in any industry with (a) competitive pressure and (b) tolerance for occasional bugs. LLMs do not make the need to serve those varied business goals go away, nor do they remove the competitive pressure to move rapidly vs gardening your codebase.
And if you're working in an area with extreme quality requirements that have forced you into doing more internal maintenance and better codebase hygiene then you find yourself with very different problems with unleashing LLMs into that code. Most of your time was never spent writing new features anyway, and LLM-driven insight into rare or complex bugs, interactions, and performance still appears quite hit or miss. Sometimes it saves me a bunch of time. Sometimes it goes in entirely wrong directions. Asking it to make major changes, vs just investigate/explain things, has an even lower hit rate.
Re: AI is a floor raiser, not a ceiling raiser
#164AI is chairs.
I feel like nobody remembers that facebook ad (Facebook is chairs), but it's seared into my own memory.
Re: AI is a floor raiser, not a ceiling raiser
#165Earlier quoted context omitted.
Oo, the "pets vs. livestock" analogy really works better than the "craftsmen vs. slop-slinger" arguments. Because using an LLM doesn't mean you devalue well-crafted or understandable results. But it does indicate a significant shift in how you view the code itself. It is more about the emotional attachment to code vs. code as a means to an end.
I don't think it's exactly emotional attachment. It's the likelihood that I'm going to get an escalated support ticket caused by this particular piece of slop/artisanally-crafted functionality.
In my world that isn't inherently a bad thing. Granted, I belong to the YAGNI crowd of software engineers who put business before tech architecture. I should probably mention that I don't think this means you should skip on safety and quality where necessariy, but I do preach that the point of software is to serve the business as fast as possible. I do this to the extend where I actually think that our BI people who are most certainly not capable programmers are good at building programs. They mostly need oversight on external dependencies, but it's actually amazing what they can produce in a very short amount of time.
Obviously their software sucks, and eventually parts of it always escalates into a support ticket which reaches my colleagues and me. It's almost always some form of performance issue, this is in part because we have monthly sessions where they can bring issues they simply can't get to work to us. Anyway, I see that as a good thing. It means their software is serving the business and now we need to deal with the issues to make it work even better. Sometimes that is because their code is shit, most times it's because they've reached an actual bottleneck and we need to replace part of their Python with a C/Zig library.
The important part of this is that many of these bottlenecks appear in areas that many software enginering teams that I have known wouldn't necessarily have predicted. Mean while a lot of the areas that traditional "best practices" call for better software architecture for, work fine for entire software lifecycles being absolutely horrible AI slop.
I think that is where the emotional attachment is meant to fit in. Being fine with all the slop that never actually matters during a piece of softwares lifecycle.
Re: AI is a floor raiser, not a ceiling raiser
#166Since agents are good only at greenfield projects, the logical conclusion is that existing codebases have to be prepared such that new features are (opinionated) greenfield projects - let all the wiring dangle out of the wall so the intern just has to plug in the appliance. All the rest has to be done by humans, or the intern will rip open the wall to hang a picture.
They’re not. They’re good at many things and bad at many things. The more I use them the more I’m confused about which is which.
They are called slot machines for a reason.
Re: AI is a floor raiser, not a ceiling raiser
#167Re: AI is a floor raiser, not a ceiling raiser
#168The blog post has a bunch of charts, which gives it a veneer of objectivity and rigor, but in reality it's just all vibes and conjecture. Meanwhile recent empirical studies actually point in the opposite direction, showing that AI use increases inequality, not decrease it. https://www.economist.com/content-assets/images/20250215_FNC... https://www.economist.com/finance-and-economics/2025/02/13/h...
[dead]
Re: AI is a floor raiser, not a ceiling raiser
#169The blog post has a bunch of charts, which gives it a veneer of objectivity and rigor, but in reality it's just all vibes and conjecture. Meanwhile recent empirical studies actually point in the opposite direction, showing that AI use increases inequality, not decrease it. https://www.economist.com/content-assets/images/20250215_FNC... https://www.economist.com/finance-and-economics/2025/02/13/h...
Yup. As a retired mathematician who craves the productivity of an obsessed 28 year old, I've been all in on AI in 2025. I'm now on Claude's $200/month Max plan in order to use Claude Code Opus 4 without restraint. I still hit limits, usually when I run parallel sessions to review a 57 file legacy code base. For a time I refused to talk with anybody or read anything about AI, because it was all noise that didn't match…
> Now I spend most of my time coding with AI, and it responds very well to my "fingers farther apart" far reaching analogies for what I'm trying to focus on.
If you made analogies based on Warhammer 40k or species of mosquitoes it would have reacted exactly the same.
Re: AI is a floor raiser, not a ceiling raiser
#170Earlier quoted context omitted.
Of course AI increases inequality. It's automated ladder pulling technology. To become good at something you have to work through the lower rungs and acquire skill. AI does all those lower level jobs, puts the people who need those jobs for experience on the street, and robs us of future experts. The people who benefit the most are those who are already up on top of the ladder investing billions to make the ladder ra…
Whether ladder raising is benefitting people now or later or by how much - I don't know. But I share your concerns that: AI doing the lesser tasks of [whatever] -> less(no?) humans will do those tasks -> less(no?) experienced humans to further the state of the art -> automation-but-stagnation. But tragedy of the commons says I have to teach my kid to use AI!
You could just teach them to be gardeners or carpenters