In my opinion this is another case where people look at it as a technical problem when it's actually a people problem. If someone does it once, they get a stern message about it. If it happens twice, it gets rejected and sent to their manager. Regardless of how you authored a pull request, you are signing off on it with your name. If it's garbage, then you're responsible.

> whereas good senior engineers often remove as much code as they add

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

> 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.

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!

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

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).

> LLM-written ones are almost entirely additive

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)

   fn foo(bar) // Never called
   fn foo_with_frobnitz(bar)

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.

> 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'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"

I'd say it depends on how coding assistants are used, when on autopilot I'd agree, as they don't really take the time to reflect on the work they've done before going on with the next feature of the spec. But in a collaborative process that's of course different as you are pointing out things you want to have implemented in a different way. But I get your point, most PR's you'd flag as AI generated slop are the ones where someone just ran them on autopilot and was somewhat satisfied with the outcome, while treating the resulting code as blackbox

Within the past 2 months, as I've started to use AI more, I've had this trajectory:

  1. only using AI for small things, very impressed by it
  2. giving AI bigger tasks and figuring out how to use it well for those bigger tasks
  3. full-agentic mode where AI just does its thing and I review the code at the end
  4. realising that I still need to think through all the code and that AI is not the shortcut I was hoping it to be (e.g. where I can give it a high-level plan and be reasonably satisfied with the final code)
  5. going back to giving AI small tasks

Big-picture coding is in my hands, but AI is good at filling in the logic for functions and helping out with other small things.

The worst thing for me is that I am actually good at LLM-based coding

My coworkers that are in love with this new world are producing complete AI slop and still take ages to complete tasks. Meanwhile I can finally play my strength as I actually know software architecture, can ask the LLM to consider important corner case and so on.

Plus, I am naturally good at context management. Being neurodivergent has given me decades of practice in working with entities that have a different way of thinking that me own. I have more mechanical empathy for the LLM because I don't confuse it for a human. My coworkers meanwhile get super frustrated that the LLM can not read their mind.

That said, LLMs are getting better. My advantage will not last. And the more AI slop gets produced the more we need LLMs to cope with all the AI slop in our code bases. A vicious cycle. No one will actually know what the code does. Soon my job will mostly consist of praying to the machine gods.

Configuring editors, dot files, and dev environments consistently adds value by giving you familiarity with your working environment, honing your skills with your tools, and creating a more productive space tailored to your needs.

Who else becomes the go to person for modifying build scripts?

The amount of people I know who have no idea how to work with Git after decades in the field using it is pretty amazing. It's not helpful for everyone else when you're the one they're delegating their merge conflict bullshit too cause they've never bothered to learn anything about the tools they're using.

Careful with the “doesn’t add value” talk. If you follow it far enough to its logical end, you get to “Existence doesn’t add value”

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.

> 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.

The point of most jobs in the world is to "solve problems". So why did you pick software over those?

> but it doesn’t add value

Sad to see people reduce themselves willingly to cogs inside business machine.

> To solve problems. Coding is the means to an end, not the end itself.

solving problems is an outcome of programming, not the purpose of programming

These are my thoughts exactly. Whenever I use agents to assist me in creating a simple program for myself, I carefully guide it through everything I want created, with me usually writing pages and pages of detailed plaintext instructions and specifications when it comes to the backends of things, I then modify it and design a user interface.

I very much enjoy the end product and I also enjoy designing (not necessarily programming) a program that fits my needs, but rarely implementing, as I have issues focusing on things.

> coding is the means to an end

...

> doesn't add value

What about intrinsic value? So many programmers on HN seem to just want to be MBAs in their heart of hearts

A chef who sharpens his knives should stop because it doesn't add value

A contractor who prefers a specific brand of tool is wrong because the tool is a means to an end

This is what you sound like. Just because you don't understand the value of a craftsman picking and maintaining their tools doesn't mean the value isn't real.

I got a few paragraphs into this piece before rolling my eyes and putting it down.

I consider myself an engineer — a problem solver. Like you said, code is just the means to solve the problems put before me.

I’m just as content if solving the problem turns out to be a process change or user education instead of a code commit.

I have no fetish for my terminal window or IDE.

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.

I started around the same time. No unit tests but we did have code reviews because of ISO 9001 requirements. That meant printing out the diffs on the laser printer and corralling 3 people into a meeting room to pour over them and then have them literally sign off on the change. This was for an RTOS that ran big industrial controls in things like steel plants and offshore oil rigs.

Project management was a 40 foot Gantt chart printed out on laser printer paper and taped to the wall. The sweet sound of waterfall.

> 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.

100% agreed. It’s just full of business assholes and vibe coder script kiddies now. Everything has turned to shit.

Try game dev. It's still like that today.

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.

I can think of few truer identity crises than having a craft you have spent years honing and perfecting automated away.

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.

Subdivisions is my favourite song of all time and I thought about Rush as well while reading that line.

This comes up whenever _anything_ is automated: "this is the end of programming as a career!" I heard this about Rational Rose in the 90's, and Visual Basic in the 80's.

I don't think I'm sticking my head in the sand - an advanced enough intelligence could absolutely take over programming tasks - but I also think that such an intelligence would be able to take over _every_ thought-related task. And that may not be a bad thing! Although the nature of our economy would have to change quite a bit to accommodate it.

I might be wrong: Doug Hofstadter, who is way, way smarter than me, once predicted that no machine would ever beat a human at chess unless it was the type of machine that said "I'm bored of chess now, I would prefer to talk about poetry". Maybe coding can be distilled to a set of heuristics the way chess programs have (I don't think so, but maybe).

Whether we're right or wrong, there's not much we can do about it except continue to learn.

Probably too late.

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.

It’s fascinating idea, though, to invert the process and have devs develop and LLMs do the code reviews. Might be more productive in the long run.

> This process has been affecting most of the world's workers for the past several centuries.

It has also been responsible for predicting revolutions which never failed to materialize. 3D printing would make some kind of manufacturing obsolete, computers would make about half the world's jobs obsolete, etc etc.

Hand coding can be the knitting to the loom, or it can be industrialized plastic injection molding to 3D printing. How do you know? That distinction is not a detail--it's the whole point.

It's survivorship bias to only look at horses, cars, calculators, and whatever other real job market shifting technologies occurred in the past and assume that's how it always happens. You have to include all predictions which never panned out.

As human beings we just tend no to do that.

[EDIT: this being Pedantry News let me get ahead of an inevitable reply: 3D printing is used industrially, and it does have tremendous value. It enabled new ways of working, it grew the economy, and in some cases yes it even replaced processes which used to depend on injection molding. But by and large, the original predictions of "out with the old, in with the new" did not pan out. It was not the automobile to the horse and buggy. It was mostly additive, complementary, and turned out to have different use cases. That's the distinction.]

I think there is only a very narrow band where LLMs are good enough at producing software that "hand-coding" is genuinely dead but at the same time bad enough that (expensive) humans still need to be paid to be in the loop.

This is so funny to me.

Hand-coding is no longer "the future"?

Did an AI write your post or did you "hand write it"?

Code needs to be simple and maintainable and do what it needs to do. Auto complete wasn't a huge time saver because writing code wasn't the bottleneck then and it definitely is not the bottleneck now. How much you rely on an LLM won't necessarily change the quality or speed of what you produce. Specially if you pretend you're just doing "superior prompting with no hand coding involved".

LLMs are awesome but the IDE didn't replace the console text editor, even if it's popular.

I started writing code in basic on a beige box. My first code on windows was a vb6 window that looked like the AOL login screen and used open email relays to send me passwords.

I've written a ton of code in my life and while I've been a successful startup CTO, I've always stayed in IC level roles (I'm in one right now in addition to hobby coding) outside of that, data structures and pipelines, keep it simple, all that stuff that makes a thing work and maintainable.

But here is the thing, writing code isn't my identity, being a programmer, vim vs emacs, mechanical keyboard, RTFM noob, pure functions, serverless, leetcode, cargo culting, complexity merchants, resume driven dev, early semantic css lunacy, these are thing outside of me.

I have explored all of these things, had them be part of my life for better or worse, but they aren't who I am.

I am a guy born with a bunch of heart defects who is happy to be here and trying new stuff, I want to explore in space and abstraction through the short slice of time I've got.

I want to figure stuff out and make things and sometimes that's with a keyboard and sometimes that's with a hammer.

I think there are a lot of societal status issues (devs were mostly low social status until The Social Network came out) and personal identity issues.

I've seen that for 40 years, anything tied to a persons identity is basically a thing they can't be honest about, can't update their priors on, can't reason about.

And people who feel secure and appreciated don't give much grace to those who don't, a lot of callous people out there, in the dev community too.

I don't know why people are so fast to narrow the scope of who they are.

Humans emit meaning like stars emit photons.

The natural world would go on without us, but as far as we have empirically observed we make the maximally complex, multi modally coherent meaning of the universe.

We are each like a unique write head in the random walk of giving the universe meaning.

There are a ton of issues from a network resilience and maximizing the random meaning generation walk where Ai and consolidation are extremely dangerous, I think as far as new stuff in the pipeline it's between Ai and artificial wombs that have the greatest risks for narrowing the scope of human discovery and unique meaning expansion to a catastrophic point.

But so many of these arguments are just post-hoc rationalizations to poorly justify what at root is this loss of self identity, we were always in the business of automating jobs out from under people, this is very weak tea and crocodile tears.

The simple fact is, all our tools should allow us to have materially more comfortable and free lives, the Ai isn't the problem, it's the fact that devs didn't understand that tech is best when empowering people to think and connect better and have more freedom and self determination with their time.

If that isn't happening it's not the codes fault, it's the network architecture of our current human power structures fault.

The problem I have with this argument is that it actually is English this time.

COBOL and SQL aren't English, they're formal languages with keywords that look like English. LLMs work with informal language in a way that computers have never been able to before.

Every time they have been closer to being right.

The thing is... All those people were right. We no longer need the kinds of people we used to call programmers. There exists a new job, only semi related, that now goes by the name programmer. I don't know how many of the original programming professionals managed to make the transition to this new progression.

The article itself is very skeptical of AI, so I highly doubt that's the case.

Also in the footer: "Everything on this website—emdash and all—is created by a human."

I'm seeing this reaction a lot from younger people (say, roughly under 25). And it's a shame this new suspicion has now translated into a prohibition on the use of dashes.

Ironically, I love using em dashes in my writing, but if I ever have to AI generate an email or summary or something, I will remove it for this exact reason.

Whenever I see these takes, I'm thinking of Idiocracy - a world built on very simple rules, like yours.

I published a book once (way before LLMs came along). My publisher insisted that I replace parenthetical inserts with em dashes. Humans do use them.

That says more about your lack of writing skills and understanding of grammar than AI.