6 ms·

This sounds right to me: > Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the sam

by simonw 8mo ago

This sounds right to me: > Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical. Helps explain why some people are delighted to have AI write code for them while others are unhappy that the part they enjoyed so much has been greatly reduced. Similar note from Kellan (a clear member of the make-it-go group) in https://laughingmeme.org/2026/02/09/code-has-always-been-the-easy-part.html https://laughingmeme.org/2026/02/09/code-has-always-been-the... : > That feeling of loss though can be hard to understand emotionally for people my age who entered tech because we were addicted to feeling of agency it gave us. The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful.

rudedogg 8mo ago
I think the real divide is over quality and standards. We all have different thresholds for what is acceptable, and our roles as engineers typically reflect that preference. I can grind on a single piece of code for hours, iterating over and over until I like the way it works, the parameter names, etc. Other people do not see the value in that whatsoever, and something that works is good enough. We both are valuable in different ways. Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. There’s also some effort requires in honing your skill using them. The “default” output is average quality, but with some coaxing higher quality output is easily attained. I’m happy people are skeptical though, there are a lot of things that do require deep thought, connecting ideas in new ways, etc., and LLMs aren’t good at that in my experience.
- enraged_camel 8mo ago
  I think this is a false dichotomy because which approach is acceptable depends heavily on context, and good engineers recognize this and are capable of adapting. Sometimes you need something to be extremely robust and fool-proof, and iterating for hours/days/weeks and even months might make sense. Things that are related to security or money are good examples. Other times, it's much more preferable to put something in front of users that works so that they start getting value from it quickly and provide feedback that can inform the iterative improvements. And sometimes you don't need to iterate at all. Good enough is good enough. Ship it and forget about it. I don't buy that AI users favor any particular approach. You can use AI to ship fast, or you can use it to test, critique, refactor and optimize your code to hell and back until it meets the required quality and standards.
  - kaffekaka 8mo ago
    Yes, it is a false dichotomy but describes a useful spectrum. People fall on different parts of the spectrum and it varies between situations and over time as well. It can remind one that it is normal to feel different from other people and different from what one felt yesterday.
- allenu 8mo ago
  > I think the real divide is over quality and standards. I think there are multiple dimensions that people fall on regarding the issue and it's leading to a divide based on where everyone falls on those dimensions. Quality and standards are probably in there but I think risk-tolerance/aversion could be behind some how you look at quality and standards. If you're high on risk-taking, you might be more likely to forego verifying all LLM-generated code, whereas if you're very risk-averse, you're going to want to go over every line of code to make sure it works just right for fear of anything blowing up. Desire for control is probably related, too. If you desire more control in how something is achieved, you probably aren't going to like a machine doing a lot of the thinking for you.
  - bandrami 8mo ago
    This. My aversion to LLMs is much more that I have low risk tolerance and the tails of the distribution are not well-known at this point. I'm more than happy to let others step on the land mines for me and see if there's better understanding in a year or two.
    - XenophileJKO 8mo ago
      I think there is more to it than that. I am a high quality/craftsmanship person. I like coding and puzzling. I am highly skilled in functional leaning object oriented deconstruction and systems design. I'm also pretty risk averse. I also have always believed that you should always be "sharpening your axe". For things like Java delelopment or things where I couldn't use a concise syntax would make extensive use of dynamic templating in my IDE. Want a builder pattern, bam, auto-generated. Now when LLMs came out they really took this to another level. I'm still working on the problems.. even when I'm not writing the lines of code. I'm decomposing the problems.. I'm looking at (or now debating with the AI) what is the best algorithm for something. It is incredibly powerful.. and I still care about the structure.. I still care about the "flow" of the code.. how the seams line up. I still care about how extensible and flexible it is for extension (based on where I think the business or problem is going). At the same time.. I definately can tell you, I don't like migrating projects from Tensorflow v.X to Tenserflow v.Y.
- bigstrat2003 8mo ago
  > Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. People have been saying this every year for the last 3 years. It hasn't been true before, and it isn't true now. The models haven't actually gotten smarter, they still don't actually understand a thing, and they still routinely make basic syntax and logic errors. Yes, even (insert your model of choice here). The truth is that there just isn't any juice to squeeze in this tech. There are a lot of people eagerly trying to get on board the hype train, but the tech doesn't work and there's no sign in sight that it ever will.
  - domlebo70 8mo ago
    Maybe I'm solving different problems to you, but I don't think I've seen a single "idiot moment" from Claude Code this entire week. I've had to massage things to get them more aligned with how I want things, but I don't recall any basic syntax or logic errors.
    - smackeyacky 8mo ago
      I saw a few (Claude Sonnet 4.6), easily fixed. The biggest difference I’ve noticed is that when you say it has screwed up it much less likely to go down a hallucination path and can be dragged back. Having said that, I’ve changed the way I work too: more focused chunks of work with tight descriptions and sample data and it’s like having a 2nd brain.
      - domlebo70 8mo ago
        Very good way to describe it. I am enjoying Opus a lot.
    - coffeebeqn 8mo ago
      With the better harness in Claude code and the >4.5 model and a somewhat thought out workflow we’ve definitely arrived at a point where I find it very helpful. The less you can rely on one-shot and more give meaningful context and a well defined testable goal the better it is. It honestly does make me worry how much better can it get and will some percentage of devs become obsolete. It requires less hand holding than many people I’ve worked with and the results come out 100x faster
qsort 8mo ago
I think the argument is "a bit too nice," it isn't a binary, motivations are complicated and sometimes both feelings coexist. If I reflect for a moment about why I personally got into tech, I can find at least a few different reasons: - because I like solving problems. It's sad that the specific types of problems I used to do are gone, but it's exciting that there are new ones. - because I like using my skills to help other people. It's sad that one specific way I could do that is now less effective, but it's exciting that I can use my knowledge in new ways. - because I like doing something where I can personally make a difference. Again, it cuts both ways. I'm sure most people would cite similar examples.
magicalist 8mo ago
Eh, it also feels like a classic "maybe we somehow have enough perspective on this watershed moment while it's happening to explain it with a simplistic dichotomy". Even this piece interrogates the feeling of "loss" and teases out multiple aspects to it, but settles on a tl;dr of "yep, dichotomy". There's more axes here too, where that feeling can depend on what you're building, who you're building it with, time and position in your career, etc etc. (I'll admit, though, that this also smells to me a bit too much like introvert/extrovert, or INTP/INTJ/etc so maybe I'm being reflexively rejective)
adriand 8mo ago
I feel zero sense of sadness about how things used to be. I feel like the change that sucked the most was when software engineering went from something that nerds did because they were passionate about programming, to techbros who were just in it for the money. We lost the idealism of the web a long time ago and the current swamp with apex reptiles like Zuckerberg is what we have now. It became all about the bottom line a long time ago. The two emotions I personally feel are fear and excitement. Fear that the machines will soon replace me. Excitement about the things I can build now and the opportunities I’m racing towards. I can’t say it’s the most enjoyable experience. The combo is hellish on sleep. But the excitement balances things out a bit. Maybe I’d feel a sense of sadness if I didn’t feel such urgency to try and ride this tsunami instead of being totally swept away by it.
- dinkumthinkum 8mo ago
  I see developers talking about this idea of intense and unimaginable excitement about AI. It seems orgasmic for them, like something the hardest drugs couldn't fulfill them. I find it very strange. What exactly is so exciting? I'm not disagreeing but when you say "opportunities I'm racing towards," what does that mean? This idea of "racing towards" sounds so frenetic, I struggle to know what that could mean? What I see people doing with AI is making slop and CRUD apps and maybe some employee replacement systems or something but I don't see this transcendental experience that people are describing. I could see a mortgage collapse or something like that, maybe that's what is so exciting? I don't know.
  - k32k 8mo ago
    I think those comments are signalling something much deeper about the individual.
    - kaffekaka 8mo ago
      Signalling what? Please expand.
      - 8mo ago
sublinear 8mo ago
The divide was never invisible and there has always been at least three camps. The "make-it-go" people couldn't make anything go back then either. They build ridiculous unmaintainable code with or without AI. Since they are cowboys that don't know what they're doing, they play the blame game and kiss a ton of ass. The "craft-lovers" got in the way just as much with their endless yak shaving. They now embrace AI because they were just using "craft" as an excuse for why they didn't know what they were doing. They might be slightly more productive now only because they can argue with themselves instead of the rest of the team. The more experienced and pragmatic people have always been forced to pick up the slack. If they have a say, they will keep scope narrow for the other two groups so they don't cause much damage. Their use of AI is largely limited to google searches like it always was.
- saulapremium 8mo ago
  Let me guess: you happen to be one of these lone pragmatists in the sea of incompetent ass-kissers and yak-shavers who use AI for writing code?
  - sublinear 8mo ago
    I'm saying the majority of devs are neither ass-kissers nor yak-shavers.
hungryhobbit 8mo ago
I strongly disagree. There's always been two camps ... on everything! Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices. But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will vary between different humans. What makes AI different to me is the fear. Nobody decided not to use emacs because they were afraid it was going to take their job ... but a huge portion of the anti-AI crowd is motivated by irrational fear, related to that concern.
- deleted 8mo ago
  [deleted]
- yoyohello13 8mo ago
  It doesn’t help that the CEOs of these companies are hyping up the fear. It’s no wonder people are afraid when the people making the products are spouting prophecies of doom.
- monknomo 8mo ago
  what about the fear is irrational?
- g-b-r 8mo ago
  A huge portion of the pro-AI crowd is motivated by irrational hype and delusion. LLMs are not a tool like an editor or an IDE, they make up code in an unpredictable way; I can't see how anyone who enjoyed software development could like that.
  - cableshaft 8mo ago
    Pretty much anyone who's not you, will make code in an unpredictable way. I review other people's code and I go 'really, you decided to do it that way?' quite often, especially with coders with less years of experience than me. That's kind of how this is starting to feel to me, like I'm turning more into a project manager that has to review code from a team of juniors, when it comes to A.I. Although those juniors are now starting to show that they're more capable than even I am, especially when it comes to speed.
ehnto 8mo ago
It's not a pure dichotomy though. I have always been both, and slowly mixing in agentic coding for work has left me some new headspace to do "trad" programming on side projects at home. I love the exciting ideation phase, I love putting together the puzzle that makes the product work, and I also take pride in the craft.
- kaffekaka 8mo ago
  I agree with this. Using agents at work has increased the possibility of me having energy left to code by hand at home. So much coding at work is not fulfilling, it is boilerplate and I do not learn anything from writing the Xth variation of the same thing. Yes, those things should have been automated long ago, but they weren't, and now with coding agents much of them are.
suzzer99 8mo ago
Enjoying something and getting satisfaction out of it are two different things. I don't enjoy the act of coding. But I enjoy the feeling when I figure something out. I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. I'm not sure I'll get either of those from claude.
- cableshaft 8mo ago
  > I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. Yeah, this is a concern. I remember when I took a break from coding to work as a video game producer for a couple of years and I felt like my ability to code was atrophying and that drove me nuts. Now I'm not so sure. There's just so much dumb garbage that's accumulated around coding nowadays, especially with web dev. So much time just gluing together or puzzling out how to get APIs or libraries to works and play nice together. It's not like back in the days where it was relatively simple with PHP and HTML, when I first started. Much less you could do back then, sure, but expectations were a lot lower back then as well. I might just content myself with doing Sudoku or playing/designing board games to help keep that brain plasticity going, and stop fighting so hard to understand all this junk. Or finally figure out how to get half-decent at shader math or something, at least that seems less trivial and ephemeral.
  - XorNot 8mo ago
    Everytime I've had to do any any webdev, I've usually just been frustrated by the fact that there's a vision of how powerful any particular architecture should be, and then all the confusion and boilerplate to try and get it there. And then it changes every 6 months or goes in circles - and I suppose now we just gave up and are letting LLMs YOLO code out the door with whatever works. Like I remember learning all about Redux Sagas, and then suddenly the whole concept is gone, but also I'm not actually particularly clear on what replaced it (might be time to go back to that well since I need to write a web interface soon again).
  - suzzer99 8mo ago
    My mom used to play Sudoku as part of her recommended therapy to stave off cognitive decline. Now she just plays solitaire on the iPad for hours on end, which I know isn't burning any new neural pathways. I'm afraid my inherent laziness will lead to something like that if I don't have to do it for my job.
appreciatorBus 8mo ago
> nobody got into it because programming in Perl was somehow aesthetically delightful. To this day I remember being delighted by Perl on a regular basis. I wasn't concerned with the aesthetics of it, though I was aware it was considered inscrutable and that I could read & write it filled me with pride. So yea, programming Perl was delightful.
- sonofhans 8mo ago
  Yes, this is what I thought, too. I did program in Perl because it was beautiful. No other computer language compares so favorably with human language, including in its ambiguity. Not everyone considers this a good feature :)
lmorchard 8mo ago
> The web was objectively awful as a technology I, for one, remember when I could crash Netscape Navigator by using CSS too hard (i.e. at all) or trying to make a thing move 10px with DHTML. But I kept trying to make browser to thing.
forgetfreeman 8mo ago
"The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable." Definitely not. Based on my observations from a career as an open source and agency developer it was obvious at a glance which of these camps any given developer lived in by their code quality. With few exceptions make-it-go types tended to produce brittle, hacky, short-sighted work that had a tendency to produce as many or more problems than it solved, and on more than one occasion I've seen developers of this stripe lose commit access to FOSS projects as a result of the low quality of their contributions. "nobody got into it because programming in Perl was somehow aesthetically delightful." Compared to trying to get stuff accomplished in C Perl was an absolute dream to work with and many devs I knew gravitated to web development specifically for their love of the added flexibility and expressiveness that Perl gave them compared to other commonly used languages at the time. Fortunately for us all language design and tooling progressed.
- thedevilslawyer 8mo ago
  Generalize much? How would you feel if code-as-craft people were called out to be anti-social nerds who spent times on umpteenth rewrite and refactor, didn't care what impact that had on the actual user they were building for?
  - forgetfreeman 8mo ago
    I'd thank you for the laugh and assume you worked in project management, marketing, or some other low info industry segment. I've worked with hundreds of developers over my career and the only time I've brushed up against anyone who even approximates what you are describing would be in HN comment threads. The craft-oriented women and men I've had the pleasure of working with have without exception held user experience and the future sanity of other developers interacting with the code they wrote as core requirements, every project, every line of code. Getting it right the first time tends to cut down significantly on refactoring.
dale_glass 8mo ago
> The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful. As an old school Perl coder, not true. Lots of people had a taste for Perl. TIMTOWTDI was sold as an actual advantage. Perl caters to things almost nobody else does, like the way you have a negative "if" in "unless" and placing conditions after the code. So you can do things like: frobnicate() unless ($skip_frobnicating); Which is sure, identical function-wise to: if (!$skip_frobnicating) frobnicate(); But is arguably a bit nicer to read. The first way you're laying out the normal flow of the program first of all, and then tacking on a "we can skip this if we're in a rare special mode" afterwards. Used judiciously I do think there's a certain something in it. The bigger problem with Perl IMO is that it started as a great idea and didn't evolve far enough -- a bunch of things had to be tacked on, and everyone tacked on them slightly differently for no real benefit, resulting in codebases that can be terribly fragile for no good reason and no benefit.
camgunz 8mo ago
I think SWEs are genuinely pretty shocked and awed that codegen models can code at all, let alone code well. My guess is a lot of the agita around this is that people thought "I can code therefore I'm smart/special/etc." and then a machine comes by that can do pretty equivalent work and they're entirely unmoored. I sympathize with that, and I don't mean to dismiss it, but that's not what I feel. I really dislike this "doer vs. maker" binary stuff that comes up every now and again, as though everyone who thinks codegen models aren't perfect doesn't want to make anything. I really want to make things--good things--and I dislike the current hype wave behind codegen models because they often make it harder for me to make good things. I've used Claude Code to build a few big things at work; I ask it questions ("where does this happen", "we have problem X, give me 3 potential causes", etc); I have it review things before I post PRs; our code review bot finds real heisenbugs. I have mixed success with all of this, but even so I find it overall useful. I'd be irritated if some place I worked, current or present, told me I couldn't use Claude Code or the like. That said, I've not gotten it to be useful in: - building entire, complex features in brownfield projects - solving systemic bugs - system design/evolution - feature/product design and planning - replacing senior engineer code review It will confidently tell you it's done these things, but when you actually force yourself through the mental slog of reviewing its output, you'll realize it's failed (you also have to be an expert to perform this analysis). Now, maybe it fails in an acceptable way; maybe only slight revision is required; maybe it one-shots the change and verifying success isn't a big mental slog. Those are the good cases. More annoying are the times it fails totally and obviously, but the real nightmares are when it fails totally, yet imperceptibly. It also sometimes can do (some of) these things! But it's inconsistent, such that its successes largely serve to lower your guard against its failures. And the mental slog is real. The artifacts you have to produce/review/ensure the model adheres to are ponderous. The code generated is ponderous. Code review is even more tedious because there's no human mind behind the code, so you can't build a mental model of the author. Getting a codegen model to revise its work or take a different approach is very hit or miss. Revising the code yourself requires reading thousands and thousands of lines of generated code--again with no human behind it--and building a mental model of what's happening before you can effectively work, and that process is time-consuming and exhausting. I'm also concerned about the second-order effects. Because switching into the often-required deep mental focus is very difficult (borderline painful), I've seen many, many people reach for LLMs in those moments instead, first a little, then entirely. I've watched people copy/paste API docs into Gemini prompts to explain them. I've watched people unable to find syntax errors in code and paste it into ChatGPT to fix it. I'm confident I'm not the only person who's observed this, and it's a little maddening it's not getting more play. --- I'm not saying SWEs don't fail in similar ways. I've approved--and authored--human PRs that had insidious flaws with real consequences. I've been asked to "review" PRs pre-ChatGPT that were 10x the size they needed to be. I've seen people plagiarize code, or just copy/paste Stack Overflow constantly. The difference is we build process around these risks, everything from coding patterns, PR size limits, type systems, firing people, borderline ludicrous amounts of unit tests, CI/CD, design docs, staging environments, red/green deploys, QA lists, etc. I hate all of it! It's a constant reminder of my flaws and it slows down mean time to dopamine squirt of released code. I'd be the first person to give all this shit the axe. I would love to point Claude at the crushingly long list of PRs I have to review. But I can't, because it still has huge, huge flaws. Code review bots miss obvious problems, and they don't have enough context/knowledge about the system/bug/feature to perform a sufficiently comprehensive review. It would be a net time waste because we'd then have to fix a bug in prod or revise an already-deployed feature/fix--things I like even less than code review, if you can believe it. These models cannot adequately replace humans in other parts of the SDLC. But, because pesky things like design and code review cap codegen models' velocity, our industry is "rethinking" it all, with no consideration of the models' flaws; "rethinking" here meaning "we're considering having an LLM handle all our code review, or not doing it at all". The only way to describe that is reckless disregard. It's unprofessional and unethical. So, I think my grief isn't about "the craft". I don't think that's gone and I don't think I'd care if it were. My grief is about the humiliation of our profession, the annihilation of our standards and the betrayal of any representation we made to our users--indeed to ourselves. We deserve software systems that do what they say they do, and up until recently I really thought we were working hard to get there. I don't think that anymore; like many other things in our era (community, truth, curiosity, generosity, trust, learning, rationality, practice, compassion) it has retreated in the face of some flavor of self-interested, shallow grift. I really don't know how or why this happened, but regardless of the cause we truly are in a dark time.

by simonw 8mo ago

rudedogg 8mo ago

I think the real divide is over quality and standards. We all have different thresholds for what is acceptable, and our roles as engineers typically reflect that preference. I can grind on a single piece of code for hours, iterating over and over until I like the way it works, the parameter names, etc. Other people do not see the value in that whatsoever, and something that works is good enough. We both are valuable in different ways. Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. There’s also some effort requires in honing your skill using them. The “default” output is average quality, but with some coaxing higher quality output is easily attained. I’m happy people are skeptical though, there are a lot of things that do require deep thought, connecting ideas in new ways, etc., and LLMs aren’t good at that in my experience.

enraged_camel 8mo ago
I think this is a false dichotomy because which approach is acceptable depends heavily on context, and good engineers recognize this and are capable of adapting. Sometimes you need something to be extremely robust and fool-proof, and iterating for hours/days/weeks and even months might make sense. Things that are related to security or money are good examples. Other times, it's much more preferable to put something in front of users that works so that they start getting value from it quickly and provide feedback that can inform the iterative improvements. And sometimes you don't need to iterate at all. Good enough is good enough. Ship it and forget about it. I don't buy that AI users favor any particular approach. You can use AI to ship fast, or you can use it to test, critique, refactor and optimize your code to hell and back until it meets the required quality and standards.
- kaffekaka 8mo ago
  Yes, it is a false dichotomy but describes a useful spectrum. People fall on different parts of the spectrum and it varies between situations and over time as well. It can remind one that it is normal to feel different from other people and different from what one felt yesterday.
allenu 8mo ago
> I think the real divide is over quality and standards. I think there are multiple dimensions that people fall on regarding the issue and it's leading to a divide based on where everyone falls on those dimensions. Quality and standards are probably in there but I think risk-tolerance/aversion could be behind some how you look at quality and standards. If you're high on risk-taking, you might be more likely to forego verifying all LLM-generated code, whereas if you're very risk-averse, you're going to want to go over every line of code to make sure it works just right for fear of anything blowing up. Desire for control is probably related, too. If you desire more control in how something is achieved, you probably aren't going to like a machine doing a lot of the thinking for you.
- bandrami 8mo ago
  This. My aversion to LLMs is much more that I have low risk tolerance and the tails of the distribution are not well-known at this point. I'm more than happy to let others step on the land mines for me and see if there's better understanding in a year or two.
  - XenophileJKO 8mo ago
    I think there is more to it than that. I am a high quality/craftsmanship person. I like coding and puzzling. I am highly skilled in functional leaning object oriented deconstruction and systems design. I'm also pretty risk averse. I also have always believed that you should always be "sharpening your axe". For things like Java delelopment or things where I couldn't use a concise syntax would make extensive use of dynamic templating in my IDE. Want a builder pattern, bam, auto-generated. Now when LLMs came out they really took this to another level. I'm still working on the problems.. even when I'm not writing the lines of code. I'm decomposing the problems.. I'm looking at (or now debating with the AI) what is the best algorithm for something. It is incredibly powerful.. and I still care about the structure.. I still care about the "flow" of the code.. how the seams line up. I still care about how extensible and flexible it is for extension (based on where I think the business or problem is going). At the same time.. I definately can tell you, I don't like migrating projects from Tensorflow v.X to Tenserflow v.Y.
bigstrat2003 8mo ago
> Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. People have been saying this every year for the last 3 years. It hasn't been true before, and it isn't true now. The models haven't actually gotten smarter, they still don't actually understand a thing, and they still routinely make basic syntax and logic errors. Yes, even (insert your model of choice here). The truth is that there just isn't any juice to squeeze in this tech. There are a lot of people eagerly trying to get on board the hype train, but the tech doesn't work and there's no sign in sight that it ever will.
- domlebo70 8mo ago
  Maybe I'm solving different problems to you, but I don't think I've seen a single "idiot moment" from Claude Code this entire week. I've had to massage things to get them more aligned with how I want things, but I don't recall any basic syntax or logic errors.
  - smackeyacky 8mo ago
    I saw a few (Claude Sonnet 4.6), easily fixed. The biggest difference I’ve noticed is that when you say it has screwed up it much less likely to go down a hallucination path and can be dragged back. Having said that, I’ve changed the way I work too: more focused chunks of work with tight descriptions and sample data and it’s like having a 2nd brain.
    - domlebo70 8mo ago
      Very good way to describe it. I am enjoying Opus a lot.
  - coffeebeqn 8mo ago
    With the better harness in Claude code and the >4.5 model and a somewhat thought out workflow we’ve definitely arrived at a point where I find it very helpful. The less you can rely on one-shot and more give meaningful context and a well defined testable goal the better it is. It honestly does make me worry how much better can it get and will some percentage of devs become obsolete. It requires less hand holding than many people I’ve worked with and the results come out 100x faster

qsort 8mo ago

I think the argument is "a bit too nice," it isn't a binary, motivations are complicated and sometimes both feelings coexist. If I reflect for a moment about why I personally got into tech, I can find at least a few different reasons: - because I like solving problems. It's sad that the specific types of problems I used to do are gone, but it's exciting that there are new ones. - because I like using my skills to help other people. It's sad that one specific way I could do that is now less effective, but it's exciting that I can use my knowledge in new ways. - because I like doing something where I can personally make a difference. Again, it cuts both ways. I'm sure most people would cite similar examples.

magicalist 8mo ago

Eh, it also feels like a classic "maybe we somehow have enough perspective on this watershed moment while it's happening to explain it with a simplistic dichotomy". Even this piece interrogates the feeling of "loss" and teases out multiple aspects to it, but settles on a tl;dr of "yep, dichotomy". There's more axes here too, where that feeling can depend on what you're building, who you're building it with, time and position in your career, etc etc. (I'll admit, though, that this also smells to me a bit too much like introvert/extrovert, or INTP/INTJ/etc so maybe I'm being reflexively rejective)

adriand 8mo ago

I feel zero sense of sadness about how things used to be. I feel like the change that sucked the most was when software engineering went from something that nerds did because they were passionate about programming, to techbros who were just in it for the money. We lost the idealism of the web a long time ago and the current swamp with apex reptiles like Zuckerberg is what we have now. It became all about the bottom line a long time ago. The two emotions I personally feel are fear and excitement. Fear that the machines will soon replace me. Excitement about the things I can build now and the opportunities I’m racing towards. I can’t say it’s the most enjoyable experience. The combo is hellish on sleep. But the excitement balances things out a bit. Maybe I’d feel a sense of sadness if I didn’t feel such urgency to try and ride this tsunami instead of being totally swept away by it.

dinkumthinkum 8mo ago
I see developers talking about this idea of intense and unimaginable excitement about AI. It seems orgasmic for them, like something the hardest drugs couldn't fulfill them. I find it very strange. What exactly is so exciting? I'm not disagreeing but when you say "opportunities I'm racing towards," what does that mean? This idea of "racing towards" sounds so frenetic, I struggle to know what that could mean? What I see people doing with AI is making slop and CRUD apps and maybe some employee replacement systems or something but I don't see this transcendental experience that people are describing. I could see a mortgage collapse or something like that, maybe that's what is so exciting? I don't know.
- k32k 8mo ago
  I think those comments are signalling something much deeper about the individual.
  - kaffekaka 8mo ago
    Signalling what? Please expand.
    - 8mo ago

sublinear 8mo ago

The divide was never invisible and there has always been at least three camps. The "make-it-go" people couldn't make anything go back then either. They build ridiculous unmaintainable code with or without AI. Since they are cowboys that don't know what they're doing, they play the blame game and kiss a ton of ass. The "craft-lovers" got in the way just as much with their endless yak shaving. They now embrace AI because they were just using "craft" as an excuse for why they didn't know what they were doing. They might be slightly more productive now only because they can argue with themselves instead of the rest of the team. The more experienced and pragmatic people have always been forced to pick up the slack. If they have a say, they will keep scope narrow for the other two groups so they don't cause much damage. Their use of AI is largely limited to google searches like it always was.

saulapremium 8mo ago
Let me guess: you happen to be one of these lone pragmatists in the sea of incompetent ass-kissers and yak-shavers who use AI for writing code?
- sublinear 8mo ago
  I'm saying the majority of devs are neither ass-kissers nor yak-shavers.

hungryhobbit 8mo ago

I strongly disagree. There's always been two camps ... on everything! Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices. But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will vary between different humans. What makes AI different to me is the fear. Nobody decided not to use emacs because they were afraid it was going to take their job ... but a huge portion of the anti-AI crowd is motivated by irrational fear, related to that concern.

deleted 8mo ago
[deleted]
yoyohello13 8mo ago
It doesn’t help that the CEOs of these companies are hyping up the fear. It’s no wonder people are afraid when the people making the products are spouting prophecies of doom.
monknomo 8mo ago
what about the fear is irrational?
g-b-r 8mo ago
A huge portion of the pro-AI crowd is motivated by irrational hype and delusion. LLMs are not a tool like an editor or an IDE, they make up code in an unpredictable way; I can't see how anyone who enjoyed software development could like that.
- cableshaft 8mo ago
  Pretty much anyone who's not you, will make code in an unpredictable way. I review other people's code and I go 'really, you decided to do it that way?' quite often, especially with coders with less years of experience than me. That's kind of how this is starting to feel to me, like I'm turning more into a project manager that has to review code from a team of juniors, when it comes to A.I. Although those juniors are now starting to show that they're more capable than even I am, especially when it comes to speed.

ehnto 8mo ago

It's not a pure dichotomy though. I have always been both, and slowly mixing in agentic coding for work has left me some new headspace to do "trad" programming on side projects at home. I love the exciting ideation phase, I love putting together the puzzle that makes the product work, and I also take pride in the craft.

kaffekaka 8mo ago
I agree with this. Using agents at work has increased the possibility of me having energy left to code by hand at home. So much coding at work is not fulfilling, it is boilerplate and I do not learn anything from writing the Xth variation of the same thing. Yes, those things should have been automated long ago, but they weren't, and now with coding agents much of them are.

suzzer99 8mo ago

Enjoying something and getting satisfaction out of it are two different things. I don't enjoy the act of coding. But I enjoy the feeling when I figure something out. I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. I'm not sure I'll get either of those from claude.

cableshaft 8mo ago
> I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. Yeah, this is a concern. I remember when I took a break from coding to work as a video game producer for a couple of years and I felt like my ability to code was atrophying and that drove me nuts. Now I'm not so sure. There's just so much dumb garbage that's accumulated around coding nowadays, especially with web dev. So much time just gluing together or puzzling out how to get APIs or libraries to works and play nice together. It's not like back in the days where it was relatively simple with PHP and HTML, when I first started. Much less you could do back then, sure, but expectations were a lot lower back then as well. I might just content myself with doing Sudoku or playing/designing board games to help keep that brain plasticity going, and stop fighting so hard to understand all this junk. Or finally figure out how to get half-decent at shader math or something, at least that seems less trivial and ephemeral.
- XorNot 8mo ago
  Everytime I've had to do any any webdev, I've usually just been frustrated by the fact that there's a vision of how powerful any particular architecture should be, and then all the confusion and boilerplate to try and get it there. And then it changes every 6 months or goes in circles - and I suppose now we just gave up and are letting LLMs YOLO code out the door with whatever works. Like I remember learning all about Redux Sagas, and then suddenly the whole concept is gone, but also I'm not actually particularly clear on what replaced it (might be time to go back to that well since I need to write a web interface soon again).
- suzzer99 8mo ago
  My mom used to play Sudoku as part of her recommended therapy to stave off cognitive decline. Now she just plays solitaire on the iPad for hours on end, which I know isn't burning any new neural pathways. I'm afraid my inherent laziness will lead to something like that if I don't have to do it for my job.

appreciatorBus 8mo ago

> nobody got into it because programming in Perl was somehow aesthetically delightful. To this day I remember being delighted by Perl on a regular basis. I wasn't concerned with the aesthetics of it, though I was aware it was considered inscrutable and that I could read & write it filled me with pride. So yea, programming Perl was delightful.

sonofhans 8mo ago
Yes, this is what I thought, too. I did program in Perl because it was beautiful. No other computer language compares so favorably with human language, including in its ambiguity. Not everyone considers this a good feature :)

lmorchard 8mo ago

> The web was objectively awful as a technology I, for one, remember when I could crash Netscape Navigator by using CSS too hard (i.e. at all) or trying to make a thing move 10px with DHTML. But I kept trying to make browser to thing.

forgetfreeman 8mo ago

"The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable." Definitely not. Based on my observations from a career as an open source and agency developer it was obvious at a glance which of these camps any given developer lived in by their code quality. With few exceptions make-it-go types tended to produce brittle, hacky, short-sighted work that had a tendency to produce as many or more problems than it solved, and on more than one occasion I've seen developers of this stripe lose commit access to FOSS projects as a result of the low quality of their contributions. "nobody got into it because programming in Perl was somehow aesthetically delightful." Compared to trying to get stuff accomplished in C Perl was an absolute dream to work with and many devs I knew gravitated to web development specifically for their love of the added flexibility and expressiveness that Perl gave them compared to other commonly used languages at the time. Fortunately for us all language design and tooling progressed.

thedevilslawyer 8mo ago
Generalize much? How would you feel if code-as-craft people were called out to be anti-social nerds who spent times on umpteenth rewrite and refactor, didn't care what impact that had on the actual user they were building for?
- forgetfreeman 8mo ago
  I'd thank you for the laugh and assume you worked in project management, marketing, or some other low info industry segment. I've worked with hundreds of developers over my career and the only time I've brushed up against anyone who even approximates what you are describing would be in HN comment threads. The craft-oriented women and men I've had the pleasure of working with have without exception held user experience and the future sanity of other developers interacting with the code they wrote as core requirements, every project, every line of code. Getting it right the first time tends to cut down significantly on refactoring.

dale_glass 8mo ago

> The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful. As an old school Perl coder, not true. Lots of people had a taste for Perl. TIMTOWTDI was sold as an actual advantage. Perl caters to things almost nobody else does, like the way you have a negative "if" in "unless" and placing conditions after the code. So you can do things like: frobnicate() unless ($skip_frobnicating); Which is sure, identical function-wise to: if (!$skip_frobnicating) frobnicate(); But is arguably a bit nicer to read. The first way you're laying out the normal flow of the program first of all, and then tacking on a "we can skip this if we're in a rare special mode" afterwards. Used judiciously I do think there's a certain something in it. The bigger problem with Perl IMO is that it started as a great idea and didn't evolve far enough -- a bunch of things had to be tacked on, and everyone tacked on them slightly differently for no real benefit, resulting in codebases that can be terribly fragile for no good reason and no benefit.

camgunz 8mo ago

I think SWEs are genuinely pretty shocked and awed that codegen models can code at all, let alone code well. My guess is a lot of the agita around this is that people thought "I can code therefore I'm smart/special/etc." and then a machine comes by that can do pretty equivalent work and they're entirely unmoored. I sympathize with that, and I don't mean to dismiss it, but that's not what I feel. I really dislike this "doer vs. maker" binary stuff that comes up every now and again, as though everyone who thinks codegen models aren't perfect doesn't want to make anything. I really want to make things--good things--and I dislike the current hype wave behind codegen models because they often make it harder for me to make good things. I've used Claude Code to build a few big things at work; I ask it questions ("where does this happen", "we have problem X, give me 3 potential causes", etc); I have it review things before I post PRs; our code review bot finds real heisenbugs. I have mixed success with all of this, but even so I find it overall useful. I'd be irritated if some place I worked, current or present, told me I couldn't use Claude Code or the like. That said, I've not gotten it to be useful in: - building entire, complex features in brownfield projects - solving systemic bugs - system design/evolution - feature/product design and planning - replacing senior engineer code review It will confidently tell you it's done these things, but when you actually force yourself through the mental slog of reviewing its output, you'll realize it's failed (you also have to be an expert to perform this analysis). Now, maybe it fails in an acceptable way; maybe only slight revision is required; maybe it one-shots the change and verifying success isn't a big mental slog. Those are the good cases. More annoying are the times it fails totally and obviously, but the real nightmares are when it fails totally, yet imperceptibly. It also sometimes can do (some of) these things! But it's inconsistent, such that its successes largely serve to lower your guard against its failures. And the mental slog is real. The artifacts you have to produce/review/ensure the model adheres to are ponderous. The code generated is ponderous. Code review is even more tedious because there's no human mind behind the code, so you can't build a mental model of the author. Getting a codegen model to revise its work or take a different approach is very hit or miss. Revising the code yourself requires reading thousands and thousands of lines of generated code--again with no human behind it--and building a mental model of what's happening before you can effectively work, and that process is time-consuming and exhausting. I'm also concerned about the second-order effects. Because switching into the often-required deep mental focus is very difficult (borderline painful), I've seen many, many people reach for LLMs in those moments instead, first a little, then entirely. I've watched people copy/paste API docs into Gemini prompts to explain them. I've watched people unable to find syntax errors in code and paste it into ChatGPT to fix it. I'm confident I'm not the only person who's observed this, and it's a little maddening it's not getting more play. --- I'm not saying SWEs don't fail in similar ways. I've approved--and authored--human PRs that had insidious flaws with real consequences. I've been asked to "review" PRs pre-ChatGPT that were 10x the size they needed to be. I've seen people plagiarize code, or just copy/paste Stack Overflow constantly. The difference is we build process around these risks, everything from coding patterns, PR size limits, type systems, firing people, borderline ludicrous amounts of unit tests, CI/CD, design docs, staging environments, red/green deploys, QA lists, etc. I hate all of it! It's a constant reminder of my flaws and it slows down mean time to dopamine squirt of released code. I'd be the first person to give all this shit the axe. I would love to point Claude at the crushingly long list of PRs I have to review. But I can't, because it still has huge, huge flaws. Code review bots miss obvious problems, and they don't have enough context/knowledge about the system/bug/feature to perform a sufficiently comprehensive review. It would be a net time waste because we'd then have to fix a bug in prod or revise an already-deployed feature/fix--things I like even less than code review, if you can believe it. These models cannot adequately replace humans in other parts of the SDLC. But, because pesky things like design and code review cap codegen models' velocity, our industry is "rethinking" it all, with no consideration of the models' flaws; "rethinking" here meaning "we're considering having an LLM handle all our code review, or not doing it at all". The only way to describe that is reckless disregard. It's unprofessional and unethical. So, I think my grief isn't about "the craft". I don't think that's gone and I don't think I'd care if it were. My grief is about the humiliation of our profession, the annihilation of our standards and the betrayal of any representation we made to our users--indeed to ourselves. We deserve software systems that do what they say they do, and up until recently I really thought we were working hard to get there. I don't think that anymore; like many other things in our era (community, truth, curiosity, generosity, trust, learning, rationality, practice, compassion) it has retreated in the face of some flavor of self-interested, shallow grift. I really don't know how or why this happened, but regardless of the cause we truly are in a dark time.