> Coding is the means to an end, not the end itself.
> That may be fun for you, but it doesn’t add value
I'm not disagreeing with you per se, but those statements are subjective, not an objective truth. Lots of people fundamentally enjoy the process of coding, and would keep doing it even in a hypothetical world with no problems left to solve, or if they had UBI.
I think the author makes a decent point with regards to 'problem solving' and better tools and how LLM's somehow feel different. Fortran is a better tool, but you can still reproducibly trace things back to assembly code through the compiler.
LLM's feel like a non-deterministic compiler that transforms English into code of some sort.
> To solve problems. Coding is the means to an end, not the end itself.
100% this. I think a lot of the people who are angry at AI coding for them are "code calligraphers" who care more about the form of the thing they're making than the problem that it solves. I can't see how someone's who's primarily solution focused would shed a tear at AI coding for them.
> Coding is the means to an end, not the end itself.
For the early MIT hackers, and for many of us still today, it absolutely is.
It's also not about the input mechanisms, which have changed over the years. Solving problems, turning complexity into simplicity, cool hacks, that's what the hacker ethos is about. It's not about driving "value".
I suppose you also feel that there's no value in learning a musical instrument either.
I think "Identity Crisis" is a bit over dramatic, but I for the most part agree with the sentiment. I have written something in the same vane, but still different enough that I would love to comment it but its just way more efficient to point to my post. I hope that is OK: https://handmadeoasis.com/ai-and-software-engineering-the-co...
I liked your emphasis on individual diversity, and an attendant need to explore, select, adapt, and integrate tooling. With associated self-awareness. Pushing that further, your "categories" seem more like exemplars/prototypes/archetypes/user-stories, helpful discussion points in a high-dimensional space of blended blobs. And as you illustrate, it branches not just on the individual, but also on what they are up to. And not just on work vs hobby, but on context and task.
It'd be neat to have a big user story catalog/map, which tracks what various services are able to help with.
I was a kid in NE43 instead of TFA's Building 26 across the street - with Lisp Machines and 1980s MIT AI's "Programmer's Apprentice" dreams. I years ago gave up on ever having a "this... doesn't suck" dev env, on being able to "dance code". We've had such a badly crippling research and industrial policy, and profession... "not in my lifetime" I thought. Knock on wood, I'm so happy for this chance at being wrong. And also, for "let's just imagine for a moment, ignoring the utterly absurd resources it would take to create, science education content that wasn't a wretched disaster... what might that look like?" - here too it's LLMs, or no chance at all.
That is a very thoughtful piece. Thank you for posting it. I especially like the idea of that new mode of programming (or problem solving, whatever you call it) when people very much enjoy getting an LLM to do what they want.
This is both new and old, because it's the same joy (or dopamine hit) of making a machine do your bidding. Honing your prompts is not that different to honing your shell scripts. I think many people overlook this aspect.
> Creative puzzle-solving is left to the machines, and we become mere operators disassociated from our craft.
For me, at least, this has not been the case. If I leave the creative puzzle-solving to the machine, it's gonna get creative alright, and create me a mess to clean up. Whether this will be true in the future, hard to say. But, for now, I am happy to let the machines write all the React code I don't feel like writing while I think about other things.
Additionally, as an aside, I already don't think coding is always a craft. I think we want it to be one because it gives us the aura of craftspeople. We want to imagine ourselves as bent over a hunk of marble, carving a masterpiece in our own way, in our time. And for some of us, that is true. For most programmers in human history though, they were already slinging slop before anybody had coined the term. Where is the inherent dignity and human spirit on display in the internal admin tool at a second tier insurance company? Certainly, there is business value there, but it doesn't require a Michalengo to make something that takes in a pdf and spits out a slightly changed pdf.
Most code is already industrial code, which is precisely the opposite of code as craft. We are dissociated from the code we write, the company owns it, not us, which is by definition the opposite of a craftsmen and craft mode of production. I think AI is putting a finer, sharper point on this, but it was already there and has been since the beginning of the field.
Thank you, author. This essay made my day. It resonates with my thinking of last months. I tried to use AI at work, but most of times I regrettably scratched whatever it did and did stuff on my own. So many points I agree with. Delegating thinking to AI is the worst thing I can do to my career. AI at best is mediocre text generator.
So funny to read how people attack author using non-related to the essay’s message criticism.
John Von Neumann famously questioned the value of compilers. Eventually we get the keyboard kids that have dominated computing since the early 70's in some form or another whether in a forward thinking way like Dan Ingalls or in an idealic way like the gcc/Free Software crowd. In parallel to this you have people like Laurel, Sutherland, Nelson who live in lateral thinking land.
The real issue is that we've been in-store for a big paradigm shift in how we interact with computers for decades at this point. SketchPad let us do competent, constraints based mathematics with images. Video games and the Logo language demonstrate the potential for programming using, "kinetics." In the future we won't code with symbols we'll dance our intent into and through the machine.
When I started programming for Corporate™ back 1995, it was a wildly different career than what it has become. Say what you want about the lunatics running the asylum, but we liked it that way. Engineering knew their audience, knew the tech stack, knew what was going on in "the industry", ultimately called the shots.
Your code was your private sandbox. Want to rewrite it every other release? Go for it. Like to put your curly braces on a new line? Like TABs (good for you)? Go for it. It's your code, you own it. (You break it, you fix it.)
No unit tests (we called that parameter checking). No code reviews (well, nothing formal — often, time was spent in co-workers offices talking over approaches, white-boarding API… Often if a bug was discovered or known, you just fixed it. There may have been a formal process beginning, but to the lunatics, that was optional.
You can imagine how management felt — having to essentially just trust the devs to deliver.
In the end management won, of course.
When I am asked if I am sorry that I left Apple, I have to tell people, no. I miss working at Apple in the 90's, but that Apple was never coming back. And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.
> And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.
I don't think the industry will return to it, but I suspect there will be isolated environments for cowboys. When I was at WhatsApp (2011-2019), we were pretty far on the cowboy side of the spectrum... although I suspect it's different now.
IMHO, what's appropriate depends on how expensive errors are to detect before production, and how expensive errors are when detected after production. I lean into reducing the cost to fix errors rather than trying to detect errors earlier. OTOH, I do try not to make embarrassing errors, so I try to test for things that are reasonable to test for.
Back when I started in the late 2000s you had much clearer lines around your career path and speciality.
There was a difference between a sysadmin and a programmer. Now, I’m expected to be my own sysadmin-ops guy while also delivering features. While I worked on my systems chops for fun on the side, I purposely avoided it on the work side, I don’t usually enjoy how bad vendor documentation, training, etc. can be in the real world of Corporate America.
Unfortunately, the problem with cowboy coding is that it takes one idiot in the team to ruin it for everyone. As company grows, there are more and more idiots by pure chance, which means you need bigger and bigger walls to contain the blast radius. If you have a team of trustworrthy engineers then cowboy coding is extremely efficient, but it simply doesn't scale, especially considering how difficult it is to evaluate the quality of given candidate when hiring.
I believe that cowboy coding might still be practiced in small companies, or in small corporate pockets, where the number of engineers doesn't need to scale.
The IT world is waiting for a revolution. Only in order to blame that revolution for the mistakes of a few powerful people.
I would not be surprised if all this revolutionary sentiment is manufactured. That thing about "Luddites" (not a thing that will stick by the way), this nostalgic stuff, all of it.
We need to be much smarter than that and not fall for such obvious traps.
An identity is a target on your back. We don't need one. We don't need to unite to a cause, we're already amongst one of the most united kinds of workers there is, and we don't need a galvanizing identity to do it.
Ignoring LLMs for a second, some code I write is done in sort of full-craft full-diligence mode, where I am only committing something where I am very proud of it's structure and of every line of code. I know it inside and out, I have reasons for every decision, major or minor, and I don't know of any ways to make it better. Not only is the code excellent, I've also produced a person (me) who is an expert in that code.
Most code is not like that. Most code I want to get something done, and so I achieve something quite a bit below that bar. But some things I get to write in that way, and it is very rewarding to do so. It's my favorite code to write by a mile.
Back to LLMs - I find it is both easier than ever and harder than ever to write code in that mode. Easier than ever because, if I can actually get and stay in that mode psychologically, I can get the result I want faster, and the bar is higher. Even though I am able to write MUCH better code than an LLM is, I can write even better code with LLM assistance.
But it is harder than ever to get into that mode and stay in that mode. It is so easy to just skim LLM-generated code, and it looks good and it works. But it's bad code, maybe just a little bit at first, but it gets worse and worse the more you let through. Heck, sometimes it just starts out as not-excellent code, but every time you accept it without enough diligence the next output is worse. And by the time you notice it's often too late, you've slopped yourself, while also failing to produce an expert in the code that's been written.
I also agree with comments on this thread stating that problem solving should be the focus and not the code.
However my view is that our ability to solve problems which require a specific type of deep thought will diminish over time as we allow for AI to do more of this type of thinking.
Purely asking for a feature is not “problem solving”.
I think you can enjoy both aspects - both the problem solving and the craft. There will be people who agree that of course from a rational perspective solving the problem is what matters, but for them personally the "fun" is gone. Generally people that identify themselves as "programmers" as the article does would be the people who enjoy problem solving/tinkering/building.
OK, but if you can't find out how to use new tools well, how good are you really as a craftsperson?
"We've always done it this way" is the path of calcification, not of a vibrant craft. And there are certainly many ways you can use LLMs to craft better things, without slop and vibecoding.
Some people code to talk and don't want anything said for them. That's okay. Photography and paintings landed in different places with different purposes.
But all of Programming isn't the same thing. We just need new names for different types of programmers. I'm sure there were farmers that lamented the advent of machines because of how it threatened their identity, their connection to the land, etc....
but I want to personally thank the farmers who just got after growing food for the rest of us.
> Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence.
As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.
The problem rather is that you still have to stay somewhat agreeable while calling out the bullshit. If you were "socially allowed" to treat colleagues like
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
as they really deserve, the problem would disappear really fast.
So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).
I'm working on the second project handed to me that was vibe-coded. What annoys me assuming it runs is the high number of READMEs which I'm not even sure which one to use/if applicable.
They are usually verbose/include things like "how to run a virtual env for python"
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.
You have two options: Burn out because you need to correct every stupid line of code, or... Start to not give a damn about quality of code and live a happy life while getting paid.
The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.
I feel like I went through this stage ahead of time, a decade ago, when I was junior dev, and was starting my days by: first reviewing the work of a senior dev who was cramming out code and breaking things at the speed of light (without LLMs); and then leaving a few dozen comments on pull requests of the offshore team. By midday I had enough for the day.
Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
After you made your colleagues upset submitting crappy code for review, you start to pay attention.
> LLM-written ones are almost entirely additive,
Unless you noticed that code has to be removed, and you instruct the LLM to do so.
I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.
I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn:
fn foo(bar)
And then I say, no, I actually wanted you to "foo with a frobnitz", so now we get:
fn foo(bar) // Never called
fn foo_with_frobnitz(bar)
This is a broader issue about how where we place blame when LLMs are involved. Humans seem to want to parrot the work and take credit when it’s correct while deflecting blame when it’s wrong. With a few well placed lawsuits this paradigm will shift imho
I think this is why I've been feeling less productive overall lately. Partly due to the fact that more code is expected to be produced more quickly, and partly because using an agent or something puts me into the wrong frame of mind where I don't really have the full context of what I've written and why, and the amount of quality work I can produce is necessarily qualified by how much I can reliably review, line-by-line, over whatever period of time.
I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.
I am probably too old school:
Unless properly documented (the "whats" and especially the "whys") and provided with a test harness (plus the test cases, including all fringe cases btw.) just reject it straight away.
And in the case it is provided and you have a hard time understanding it, reject it as well with the comment that, the "demi-god" (author) should provide documentation which mere mortals can follow.
That principle can be applied to both LLM slop and handcrafted rubbish.
Eventually most people will get it.
How are these "engineers" maintaining jobs? How is pushing code generated by someone/something else that hasn't even as much as been looked at before acceptable in any realm?
Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.
To be honest I already reached that identity crisis even before LLMs.
Nowadays many enterprise projects have become placing SaaS products together, via low code/no code integrations.
A SaaS product for the CMS, another one for assets, another for ecommerce and payments, another for sending emails, another for marketing, some edge product for hosting the frontend, finally some no code tools to integrate everything, or some serverless code hosted somewhere.
Welcome to MACH architecture.
Agents now made this even less about programming, as the integrations can be orchestrated via agents, instead of low code/no code/serverless.
I'm in the opposite camp. Programming has never been fun to me, and LLMs are a godsend to deal with all the parts I don't care for. LLMs have accelerated my learning speed and productivity, and believe it or not, programming even started to become fun and engaging!
I think in a few years, we will realize that LLMs have impacted our lives in a deeply negative way. The relatively small improvements LLMs bring to my life will be vastly outweighted by the negatives.
If LLM abilities stagnate around the current level it's not even out of the question that LLMs will negatively impact productivity simply because of all of the AI slop we'll have to deal with.
Hmmm. Interesting prediction. I think even on social media, the consensus is still shaky, and social media is an unalloyed bad IMHO. I think personal cars impacted our lives in a deeply negative way but most people disagree. There is really no consensus on LLMs right now, I think if they stagnate this is where the discourse will stagnate also.
More likely, like other tools, it will be possible to point to clear harms and clear benefits, and people will disagree about the overall impact.
Let's be clear about one thing, though. LLMs are simply tools, which can be used for good or for bad. It's specific people who do and promote the latter - top management of tech companies, for example. It's those people who are creating the negatives in my life and who tank quality for the sake of "productivity". Point the finger and say it out loud. They shouldn't be able to hide behind the tech.
As an aside, I've been using copilot code review before handing off any of my code to colleagues. It's a bit pedantic, but it generally catches all the most stupid things I've done so that the final code review tends to be pretty smooth.
I hate to suggest that the fix to LLM slop is more LLMs, but in this case it's working for me. My coworkers also seem to appreciate the gesture.
I agree that LLMs are great for a cursory review, but crucially, when you ask copilot to review your code, you actually read and think about everything copilot tells you in the response. The biggest issues arise because people will blindly submit AI-generated code without reading or thinking about it.
Great read, unlike technologies of the past that automated away the dangerous/boring/repetitive/soul-sucking jobs, LLM's are an assault on our thinking.
Social media already reduced our attention spans to that of goldfish, open offices made any sort of deep meaningful work impossible.
People have long talked about how reading code is far more important than writing code when working as a professional SWE. LLMs have only increased the relative importance of code review. If you're not doing a detailed code review of every line your LLM generates (just like you should have always been doing while reviewing human-generated code), you're doing a bad job. Sure, it's less fun, but that's not the point. You're a professional.
78 comments
[ 325 ms ] story [ 465 ms ] threadWhen SQL was born, some people said, "It's English! We won't need programmers anymore!"
Now we have AI prompting, and some people are saying, "It's English! We won't need programmers anymore!"
Really?
To solve problems. Coding is the means to an end, not the end itself.
> careful configuration of our editor, tinkering with dot files, and dev environments
That may be fun for you, but it doesn’t add value. It’s accidental complexity that I am happy to delegate.
Sad to see people reduce themselves willingly to cogs inside business machine.
solving problems is an outcome of programming, not the purpose of programming
I'm not disagreeing with you per se, but those statements are subjective, not an objective truth. Lots of people fundamentally enjoy the process of coding, and would keep doing it even in a hypothetical world with no problems left to solve, or if they had UBI.
LLM's feel like a non-deterministic compiler that transforms English into code of some sort.
100% this. I think a lot of the people who are angry at AI coding for them are "code calligraphers" who care more about the form of the thing they're making than the problem that it solves. I can't see how someone's who's primarily solution focused would shed a tear at AI coding for them.
For the early MIT hackers, and for many of us still today, it absolutely is.
It's also not about the input mechanisms, which have changed over the years. Solving problems, turning complexity into simplicity, cool hacks, that's what the hacker ethos is about. It's not about driving "value".
I suppose you also feel that there's no value in learning a musical instrument either.
It'd be neat to have a big user story catalog/map, which tracks what various services are able to help with.
I was a kid in NE43 instead of TFA's Building 26 across the street - with Lisp Machines and 1980s MIT AI's "Programmer's Apprentice" dreams. I years ago gave up on ever having a "this... doesn't suck" dev env, on being able to "dance code". We've had such a badly crippling research and industrial policy, and profession... "not in my lifetime" I thought. Knock on wood, I'm so happy for this chance at being wrong. And also, for "let's just imagine for a moment, ignoring the utterly absurd resources it would take to create, science education content that wasn't a wretched disaster... what might that look like?" - here too it's LLMs, or no chance at all.
This is both new and old, because it's the same joy (or dopamine hit) of making a machine do your bidding. Honing your prompts is not that different to honing your shell scripts. I think many people overlook this aspect.
Maybe it is
I really enjoy programming and like the author said, it's my hobby.
On some level I kind of resent the fact that I don't really get to do my hobby for work any more. It's something fundamentally different now.
For me, at least, this has not been the case. If I leave the creative puzzle-solving to the machine, it's gonna get creative alright, and create me a mess to clean up. Whether this will be true in the future, hard to say. But, for now, I am happy to let the machines write all the React code I don't feel like writing while I think about other things.
Additionally, as an aside, I already don't think coding is always a craft. I think we want it to be one because it gives us the aura of craftspeople. We want to imagine ourselves as bent over a hunk of marble, carving a masterpiece in our own way, in our time. And for some of us, that is true. For most programmers in human history though, they were already slinging slop before anybody had coined the term. Where is the inherent dignity and human spirit on display in the internal admin tool at a second tier insurance company? Certainly, there is business value there, but it doesn't require a Michalengo to make something that takes in a pdf and spits out a slightly changed pdf.
Most code is already industrial code, which is precisely the opposite of code as craft. We are dissociated from the code we write, the company owns it, not us, which is by definition the opposite of a craftsmen and craft mode of production. I think AI is putting a finer, sharper point on this, but it was already there and has been since the beginning of the field.
So funny to read how people attack author using non-related to the essay’s message criticism.
You could say that about programming languages in general. "Why are we leaving all the direct binary programming for the compilers?"
The real issue is that we've been in-store for a big paradigm shift in how we interact with computers for decades at this point. SketchPad let us do competent, constraints based mathematics with images. Video games and the Logo language demonstrate the potential for programming using, "kinetics." In the future we won't code with symbols we'll dance our intent into and through the machine.
https://www.youtube.com/watch?v=6orsmFndx_o http://www.squeakland.org/tutorials/ https://vimeo.com/27344103
When I started programming for Corporate™ back 1995, it was a wildly different career than what it has become. Say what you want about the lunatics running the asylum, but we liked it that way. Engineering knew their audience, knew the tech stack, knew what was going on in "the industry", ultimately called the shots.
Your code was your private sandbox. Want to rewrite it every other release? Go for it. Like to put your curly braces on a new line? Like TABs (good for you)? Go for it. It's your code, you own it. (You break it, you fix it.)
No unit tests (we called that parameter checking). No code reviews (well, nothing formal — often, time was spent in co-workers offices talking over approaches, white-boarding API… Often if a bug was discovered or known, you just fixed it. There may have been a formal process beginning, but to the lunatics, that was optional.
You can imagine how management felt — having to essentially just trust the devs to deliver.
In the end management won, of course.
When I am asked if I am sorry that I left Apple, I have to tell people, no. I miss working at Apple in the 90's, but that Apple was never coming back. And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.
I don't think the industry will return to it, but I suspect there will be isolated environments for cowboys. When I was at WhatsApp (2011-2019), we were pretty far on the cowboy side of the spectrum... although I suspect it's different now.
IMHO, what's appropriate depends on how expensive errors are to detect before production, and how expensive errors are when detected after production. I lean into reducing the cost to fix errors rather than trying to detect errors earlier. OTOH, I do try not to make embarrassing errors, so I try to test for things that are reasonable to test for.
There was a difference between a sysadmin and a programmer. Now, I’m expected to be my own sysadmin-ops guy while also delivering features. While I worked on my systems chops for fun on the side, I purposely avoided it on the work side, I don’t usually enjoy how bad vendor documentation, training, etc. can be in the real world of Corporate America.
I believe that cowboy coding might still be practiced in small companies, or in small corporate pockets, where the number of engineers doesn't need to scale.
The IT world is waiting for a revolution. Only in order to blame that revolution for the mistakes of a few powerful people.
I would not be surprised if all this revolutionary sentiment is manufactured. That thing about "Luddites" (not a thing that will stick by the way), this nostalgic stuff, all of it.
We need to be much smarter than that and not fall for such obvious traps.
An identity is a target on your back. We don't need one. We don't need to unite to a cause, we're already amongst one of the most united kinds of workers there is, and we don't need a galvanizing identity to do it.
Most code is not like that. Most code I want to get something done, and so I achieve something quite a bit below that bar. But some things I get to write in that way, and it is very rewarding to do so. It's my favorite code to write by a mile.
Back to LLMs - I find it is both easier than ever and harder than ever to write code in that mode. Easier than ever because, if I can actually get and stay in that mode psychologically, I can get the result I want faster, and the bar is higher. Even though I am able to write MUCH better code than an LLM is, I can write even better code with LLM assistance.
But it is harder than ever to get into that mode and stay in that mode. It is so easy to just skim LLM-generated code, and it looks good and it works. But it's bad code, maybe just a little bit at first, but it gets worse and worse the more you let through. Heck, sometimes it just starts out as not-excellent code, but every time you accept it without enough diligence the next output is worse. And by the time you notice it's often too late, you've slopped yourself, while also failing to produce an expert in the code that's been written.
I also agree with comments on this thread stating that problem solving should be the focus and not the code.
However my view is that our ability to solve problems which require a specific type of deep thought will diminish over time as we allow for AI to do more of this type of thinking.
Purely asking for a feature is not “problem solving”.
"We've always done it this way" is the path of calcification, not of a vibrant craft. And there are certainly many ways you can use LLMs to craft better things, without slop and vibecoding.
But all of Programming isn't the same thing. We just need new names for different types of programmers. I'm sure there were farmers that lamented the advent of machines because of how it threatened their identity, their connection to the land, etc....
but I want to personally thank the farmers who just got after growing food for the rest of us.
> Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence.
As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
as they really deserve, the problem would disappear really fast.
So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).
They are usually verbose/include things like "how to run a virtual env for python"
Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.
The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.
Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!
After you made your colleagues upset submitting crappy code for review, you start to pay attention.
> LLM-written ones are almost entirely additive,
Unless you noticed that code has to be removed, and you instruct the LLM to do so.
I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.
I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn:
And then I say, no, I actually wanted you to "foo with a frobnitz", so now we get:I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.
That principle can be applied to both LLM slop and handcrafted rubbish. Eventually most people will get it.
Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.
Nowadays many enterprise projects have become placing SaaS products together, via low code/no code integrations.
A SaaS product for the CMS, another one for assets, another for ecommerce and payments, another for sending emails, another for marketing, some edge product for hosting the frontend, finally some no code tools to integrate everything, or some serverless code hosted somewhere.
Welcome to MACH architecture.
Agents now made this even less about programming, as the integrations can be orchestrated via agents, instead of low code/no code/serverless.
I will never, ever go back to the time before.
If LLM abilities stagnate around the current level it's not even out of the question that LLMs will negatively impact productivity simply because of all of the AI slop we'll have to deal with.
More likely, like other tools, it will be possible to point to clear harms and clear benefits, and people will disagree about the overall impact.
I hate to suggest that the fix to LLM slop is more LLMs, but in this case it's working for me. My coworkers also seem to appreciate the gesture.
I forwarded your article to my son the dev, since your post captured the magic of being a programmer so well.
And yes Levy’s book Hackers is most excellent.
Social media already reduced our attention spans to that of goldfish, open offices made any sort of deep meaningful work impossible.
I hope this madness dies before it devours us.