Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> I became a software engineer because I loved the process of it. I could sit for hours, figuring out how to wire something up just so and get an idea made into something real. And it didn’t feel like work. It was just fun. Joyful. Satisfying.

It's funny, because I do not like the process of software engineering at all! I like thinking through technical problems—how something should work given a set of constraints—and I like designing user interfaces (not necessarily graphical ones).

And I just love using Claude Code! I can tell it what to do and it does the annoying part.

It still takes work, by the way! Even for entirely "vibe coded" apps, I need to think through exactly what I want, and I need to test and iterate, and when the AI gets stuck I need to provide technical guidance to unblock it. But that's the fun part!

View on HN

I've been noticing the pattern among the kind of people who like/dislike AI/agentic coding:

1) people who haven't programmed in a while for whatever reason (became executives, took a break from the industry, etc)

2) people who started programming in the last 15 or so years, which also corresponds with the time when programming became a desirable career for money/lifestyle/prestige (chosen out of not knowing what they want, rather than knowing)

3) people who never cared for programming itself, more into product-building

To make the distinction clear, here are example groups unlikely to like AI dev:

1) people who programmed for ~25 years (to this day)

2) people who genuinely enjoy the process of programming (regardless of when they started)

I'm not sure if I'm correct in this observation, and I'm not impugning anyone in the first groups.

Just for background, I will say I'm not a programmer—I used to work at a web design agency where I did coding as part of my job, and now I'm an elementary school teacher of all things. I never wanted to be a software engineer explicitly because I don't like writing code!

But I've been using Claude non-stop this summer on personal projects and I just love the experience!

It's like saying I never like carpentering, but hey that great ikea thing (or 3d printer), we all now can have nice furniture for pennies! Except it's not nice furniture, it's not for pennies and you still really need carpenters for building houses.

You ignored what they said, put words in their mouth and made a cheap shot.

I've been coding for 35 years and I've grown to hate it. Most of the work is boring. The things I absolutely loved doing, they require focus, and focus is something I just don't get to have at this point in my life (young kids) and career (if I'm focused I'm neglecting my responsibilities).

I've found AI to be a useful tool when using a new library (as long as the version is 2 years old) and in the limited use I've made of agents I can see the potential but also the dangers in wrong + eager hands.

I haven't seen many folks who actually hands-on programmed this long willingly and grown to hate it. Instead one is usually trying to become something else (CTO, executive, etc) but due to financial difficulties, struggle to make connections and promote themselves, had to keep writing code. Are you sure this wasn't more of your case? That said, I haven't programmed for 35 years yet (approaching 30 in my case), so I don't know how I might feel when I get there.

It can happen if you develop health issues like carpal tunnel or Sciatica due to extended sitting. Programming then gets mentally associated with pain.

Nope not at all. The first ~10 years were as a kid, so not professionally. Professionally I'm at the top of my niche and decided to work as a consultant instead of starting doing my own startup or starting an agency as I wasn't able to commit and have a family, and I loved writing code (and was bloody good at it, and at making my teams much much better by leading by example & helping them grow).

I spent the pandemic being one of the key players in the pandemic response, writing a lot of code but also helping a load of teams over different countries collaborate, and anything else I could do to make everything work. Oh and bringing up kids at the same time.

Now I'm at a startup, finally, and getting the engineering team off of the ground. Still trying to code (it's really hard to give up chasing the highs) a bit but there's less time for it and no time for the really hard deep dives (and I'm not willing to ignore my family to no-life it as others can do).

With that context, yeah, it's not as enjoyable. Sure I could try and transition back to a full-time coding roll and yeah, I'd be working on fun puzzles and enjoying it, but that means my impact is more limited. It's a better use of my skills + experience to be doing what I'm doing. Pays more too but both pay well :-)

Sounds very interesting, and at first I thought maybe you're an outlier, but the more I read people mention "solving puzzles", the more I notice a more fundamental difference in enjoying programming. For me it's not solving puzzles, but rather finding elegant/eloquent expression of something complex (feel like I'm more of a writer than an engineer). That's what makes me tick: clear code that can itself serve as a primary source of knowledge of how a business functions. If I work with an AI agent, I become an editor rather than a writer — a very different job.

Uh, so in the end you pretty much ended up in a management role instead of coding and seems like you’re much happier that way.

So not far off from the comment you replied to.

Started with computers in 1986, and I don't want to become something else other that programming related activities, even if only partially due to architecture and devops stuff, unless obliged to by external factors.

Already did management tasks occasionally, and I rather be stuck on the last step of the career laddder with a job that makes me happy, than one I have to drag myself to office (physical or virtual one).

Eventually if healthy enough close to retirement age, I might as well do something completly different than computing related.

> career (if I'm focused I'm neglecting my responsibilities).

I'm confused—can you expand on this? What's "the work" that you've "grown to hate?" Is it "coding," or is it your "responsibilities?"

If its any typical corporate job, as they said I imagine the coding is rather boring.

We need a new feature. Ok add this controller, add some if statements for this business logic, make some api calls, add this to the db, write some models. Ok done, same thing over and over again.

Id certainly love to be able to do the architecting part and have someone do the work

I’ve found GitHub Copilot Agent quite good for this kind of coding. You write up the architecture you want and I paste it into an issue and it fills in the rest.

As enterprise consultant, the "have someone do the work" is kind of complicated when the someone is not from the same office, if given the choice I would rather do that boring stuff myself.

Most non startup corporate programming jobs are just adding/removing features, add a checkbox here, squash this business logic bug, add a new dept code here, etc. You never build anything new, it's just piddly maintenance stuff.

The way I read it (and I agree with, so biased) is that OP hates that the focus of writing code is generally-perceived as a negative, hence the proliferation of code assistants, AND hates that focus is harder to obtain because of life stuff.

That's it, it's life phase makes focus impossible, and coding is a massive drug when you're in the zone. And I was very very good a few years ago when in the zone working on highly concurrent (and distributed) systems. I felt like superman compared to everyone else I worked with as I could build things no-one else could.

There are plenty of people on this site who must be able to relate to that (and who are much better than I am - I was a Championship player playing for a League Two club and there are Galactico's active here).

That's long gone and now I'm turning into Eddy Howe (a football manager) not Steve Bull (who was an excellent striker who played for Wolves his entire career in the lower leagues but really should have moved to a good club because he was too good for them).

I wonder sometimes if that's the hump that top class sports stars have to go through when they retire from playing, it took me a few years to understand and accept.

> coding is a massive drug

It truly is. One could say it could be an addiction. Something is an addiction only if it makes your life dysfunctional, and boy I have been coding for 3 days straight (!) without eating way too many times. I am completely in the zone and I neglect myself and everything around me. Yes, I know, it is bad and unhealthy, but it still happens often. I wonder if I am alone in this, I would hope not. :D

I can definitely relate. I've taken week-long solo vacations (with my wife's approval!) just so that I can code without distractions.

I don't have kids, but given that I can easily work 6-8 hours straight on completing a feature, I have to curtail it to maintain a high-quality relationship. (I also weightlift, which can take up a lot of time.)

It's very difficult for me to get into the zone in three-hour spurts, and coding at night at the cost of my sleep is something I've retired. Shoot, a three-hour work session might be me trying to fix _a single bug._

Regarding "the hump," the show _Ted Lasso_ actually does a great job of describing this. A star player retires as they realize that they are no longer as spry as younger talent. Part of this show is about how they choose to deal with it.

Coding as the fun stuff need you to be able to focus and due to responsibilities (which include a whole lot of system architecture, people management I do enjoy and can do well).

Basically you get to a point in your life and career where you have to decide whether you want to be the absolute best engineer, or whether you want to be building the best environment for building and retaining the best engineers. I kicked the can down the line but it was eventually having three kids which made me realise that the latter was my path. That and it was becoming increasingly harder to actually do #1 when you seem to be surrounded by incompetents taking the second path who, as they often never became competent engineers but seem to have a large influence on decisions as a group.

It's not that I like writing code exactly it's that the domain of the code I can write to a professional level doesn't overlap with the code I find interesting to write. Or in the case of web frameworks, worth spending two days understanding the new dialect of whatever the latest fad framework is so that I know what I'm doing and not copy/pasting or otherwise working from example.

What might make it hard to understand is that the vast majority of people who call themselves engineers don't do so to the level I consider professional; especially in the app / web development / start-up world.

Only 20 years since it started as a hobby. There is programming that I enjoy doing for the fun of it or for experimentation and I wouldn’t use AI for that (most likely because it’d be something that isn’t well known or documented).

If work wants me to use it for the job, then sure why not? That too is something new to learn how to do well, will possibly be important for future career growth, and is exciting in a different way. If anything, I’ve got spare mental compute by the end of the week and might even have energy to do my hobbyist stuff.

Win win for me.

I on the other hand find agentic LLMs mentally draining.

I can't enter a flow state since the workflow boils down to waiting and then getting interrupted, and then waiting again. Often the LLM does the wrong thing and then instead of moving to implement another feature, I'm stuck in a loop where I'm trying to get it to fix poor decisions or errors.

It's possible I get a feature implemented faster thanks to agentic LLM, but the experience of overseeing and directing it is dreadful and pretty much invariably I end up with some sort of tech debt slop.

I much prefer the chat interfaces for incorporating LLMs into my workflow.

Damn, this hits hard. I used to love coding. Now, I can't even focus enough to make progress on my pet projects. And work stopped being fun a long time ago.

I'm using Claude Code to push my development efforts along and it works like crazy, but I can't help but feel like it's a Faustian Bargain and 80% of this industry is going to evaporate over the next decade.

I'm in the ~25 years group and my only AI pleasure is the f**ing boilerplate that some libs and frameworks insist on still pushing onto the developer that is almost always the same but not quite.

I actually get to do the job I love which is problem solving.

To be fair, I started programming in the nineties, I genuinely enjoy the process, but I really enjoy agentic coding as well. It's just thinking on a higher level, and you don't need to do all the chores anymore. I still do proper software engineering with tests, layers, separation of concerns, etcetera, but I don't have to type so much anymore. And the speed is on average double compared to writing it by hand.

I was going to include "people who use verbose programming languages/environments" :), but perhaps it's more of a likelihood scale across all groups. The more verbose the language, the more drawn to AI you will be.

AI help us to do faster what we shouldn't have to do at all if our tools where better.

I think you might have to get more granular than:

  > people who genuinely enjoy the process of programming (regardless of when they started)

I began programming at 9/10, and it's been one of only a few lifelong passions.

But for me, the code itself was always just a means to an end. A tool you use to build something.

I enjoy making things.

That's what I mean by product-building vs programming (3rd group).

To me this is sort of like saying about music "The guitar was always just a means to an end. A tool you use to build something. I enjoy making things."

That's true, but there's something qualitatively different about writing a song on a guitar vs. prompting to create a song in Suno. The guitar (or piano/Ableton/whatever) is an instrument, whereas Suno is… I'm not really sure.

But that difference makes me totally disinterested in using Suno to produce music. And in the same way — even though I also consider code "just a means to an end" — I'm also totally disinterested in using Claude Code to produce software.

I'm probably in the minority here, but I also produce House music as a hobby and I love the idea of generative AI as a production tool.

I paid $10 to try the latest Suno 4.5 model and one of the songs it produced was incredible (to me) and sounded so much like the music from my Pandora station I'd never have known it was AI.

https://suno.com/s/EjiWqoG3iR6OYXQA

I'm excited for the future of "Infinite Personal Jukebox" where you can hear an endless stream of music tailored exactly to your taste, and never hear the same song twice.

I'm trying hard not to judge, but the "Infinite Personal Jukebox" sounds nightmarish to me — and I don't just mean to me, personally, but for humanity as a whole.

You are describing a world in which music is devoid of any social context. No sharing songs with friends, no replaying the first song you danced to with a loved one, no seeing live performances, no researching who inspired your favorite artists — because in this world "inspiration" doesn't exist. Nothing will ever force you to reevaluate a genre you'd written off, or ponder tough questions — in fact, no media will ever challenge or surprise you in any way.

That is a world in which one of our most primal connective threads has been robbed of its social and emotional value. It's just elevator music for our own private elevators.

I'd posit Spotify already is an "infinite personal jukebox" for a lot of people.

We can have both. People will still want that social context, and will go to concerts and so on. But not for every song.

Things are bad already so we should make them worse?

I mean, I agree with that, but then what is the problem for AI to solve here (other than Spotify needing to pay royalties to those pesky musicians)?

But with Suno YOU didn’t produce shit.

Suno did.

That is a distinction with a difference to you, but it may not be to them. They may not agree that they didn’t make the output, either.

Most people don’t even tune their own pianos, let alone build them. I think you have a point, but it’s not likely to matter to those who don’t view the questions or the answers you’re raising as meaningful for a given situation and context.

So even if they agree with you and make the content anyway because they like it or it’s profitable, where do you go from here, in your argument or outside of a hypothetical situation? I don’t see how you can put the genie back in the bottle.

If you have a process and pattern you like to follow, I imagine that your experience with AI agents will be frustrating. I have had to be willing to change how I structure code to get AI dev to work really well for me.

I fall into the 25 year of experience category. Probably a few more. For me, this agentic coding couldn’t have come at a better time. I still love thinking about solutions to problems and creating those solutions. I’m becoming less and less interested in the implementation details of those solutions.

I tend to use Claude Code in 2 scenarios. YOLO where I don’t care what it looks like. One shot stuff I’ll never maintain.

Or a replacement for my real hands on coding. And in many cases I can’t tell the difference after a few days if I wrote it or AI did. Of course I have well established patterns and years of creating requirements for junior devs.

We are in a similar length of experience, but weirdly as I got older, it's the opposite for me: I got more particular about clarity, readability, especially in the context of handling edge cases. The 10% of situations that require 90% of effort. My new hobby is a codebase that can read as a business rulebook.

I’m grateful for the likes of you out there.

I got into this industry as a side gig from science, I love solving problems. I am pretty ok at code, but code is a problem in the way of another problem. Sometimes it is easy to get distracted by a cute puzzle or a new game, but my purpose is to solve larger problems not play games (I didn't intend for this to be HN rhetorical combat).

The people most against AI assistance are those that define themselves by what they do, have invested a lot into honing their craft and enjoy the execution of that craft.

I have been getting paid to program for over 35 years, agentic coding is a fresh breeze. https://www.youtube.com/watch?v=YNTARSM-Fjc&list=PLBEB75B6A1...

I went into computer science because I liked the puzzle aspect of it. In highschool, I took a computer class and all we did was solve programming competition questions, and I loved it.

Software engineering is very different. There's a lot of debugging and tedious work that I don't enjoy, which AI makes so much better. I don't care about CSS, I don't want to spend 4 hours trying to figure out how to make the button centered and have rounded corners. Using AI I can make frontend changes in minutes instead of days.

I don't use the AI to one shot system design, although I may use it to brainstorm and think through ideas.

I love software engineering. I love algorithms and complexity and data structures and distributed systems.

But if I could press a button and make finished software appear, I would.

> But if I could press a button and make finished software appear, I would.

You cannot and never will, because of shannon entropy.

How many non-trivially distinct programs are definable by the few words of the prompt on such a button?

I'm not so sure.

"Todo app" has a pretty recognizable shape. As does "photo app", "music streaming app", etc.

If you're not happy and if you incrementally add more constraints, that's no different from human elicitation.

Imagine engineering the interface for some kind of magical app factory. It'll probably be like that.

no one uses ai to one shot system design because they cant. it will fuck up in any moderate sized project

Is there really a large delta between computer programming, coding, computer science and software engineering?

If we're sticking with the accepted definitions, there is.

Computer programming is the idea of making a computer do some task in an automated manner by giving it instructions that it will follow.

Coding is using some kind of language for the above. You take some a spec and you transform it into a textual representation.

Computer science is mostly about studying what the computer can do and what it cannot. It is the actual foundation of everything

Software engineering is about producing software by following engineering principles. Coding is a small part of it. It's mostly about getting things done reliably. The constraints are rarely technical, but mostly about coordination and resources usage.

Most people talks about computer programming when they should talk about software engineering. Computer programming is easy and we have a lot of tools to assists with coding technicalities. Software engineering is hard and the more you do it, the more you see that the problem is mostly about truly understanding what needs to be done and do it well.

According to these definitions, everyone who writes any code is doing computer programming and coding. This is not a role really, just like "pliers user" doesn't describe a role just something that many roles may do. Software engineering is management and writing of specs. Of course if one were to write a spec in a completely unambiguous way, it would be code.

The problem is, that someone will need to maintain the stuff you don't care about. That slop CSS you just committed? Someone will either need to understand it later, or perpetuate the slop using more AI tools. It is in all our interest to care about the little things as well. Even if it is round corners of a button.

To the first list also add the typical mediocre developer who has struggled for their entire career, never investing in acquiring deep understanding of how things work, and who is making guesses when attempting to fix things, later blaming the magic behind them. For those people the magic of LLMs is just the same, they are comfortable with it, and will be giving the same excuses that they are used to, even more so now.

I'm squarely in the latter group and I just don't think of it in like/dislike terms: I think of it as a rapidly changing (though beginning to converge) set of new tools in a toolbox that only ever grows. In particular its in the code generation / code validation subtoolbox that already included IDL compilers, emacs macros, type systems / proof assistants, code review, and others.

It's capability increasing to have new tools, this is most apparent at the entry level but most impactful at the margins: the difficulty of driving a taxi is now zero, driving an F1 car is now harder, but F1 cars might soon break the sound barrier.

This is not a democratizing force at the margins if one bases like/dislike on that.

There are multiple vocal groups on the Internet about vibe coding. I don’t think any of them really capture the average use case.

Most of the people I know use use AI coding tools do so selectively. They pick the right tool for the job and they aren’t hesitant to switch or try different modes.

Whenever I see someone declare that the other side is dead or useless (manual programming or AI coding) it feels like they’re just picking sides in a personal preference or ideology war.

I didn't understand which group was supposed to be which until the very last point, so I don't think you're correct. In my personal network, the most senior people with lots of programming experience have the most positive attitude and seem to be more pragmatic about it in general.

This is my experience as well. Occasionally when using code tools - I do actually feel like a 10x engineer. I’ve got sufficient experience to know what I want and to correct course when needed. And I can dive into the code and help when needed.

It’s like having an amazing team of super talented junior/mid-level engineers along with some crazy maverick experts in tap.

Couple of questions: the most senior people in your personal network — are they hands-on _lately_? And are they ~>25y experience? If it's a no to either, I took those into account.

I'll add another category: people who've coded in many languages but never specialised. I've earned money by coding in c, php, c#, flex, arduino-c, rust and python. And I've hacked at projects written in a few more.

Like a lot of people here, my earliest memories of coding are of me and my siblings typing games printed in a BASIC book, on a z80 clone, for 30-60 minutes, and then playing until we had to go to bed, or the power went out :) We only got the cassette loading thing years later.

I've seen a lot in this field, but honestly nothing even compares to this one. This one feels like it's the real deal. The progress in the last 2.5 years has been bananas, and by every account the old "AI is the worse it's ever gonna be" seems to be holding. Can't wait to see what comes next.

The models themselves seem to be plateauing with the companies behind them shifting to additional products on top of them. It seemed like a weekly occurrence we would get a new model from the top dogs.

The models are plateauing, but unlike humans, a certain amount of brute force testing of their output is fine. They can just iterate until they succeed.

Kinda. While it's possible to do that, you've got an exponential cost increase for linear improvements — scale from a case where an AI makes 1 mistake to 2, double the output cost, 3 mistakes double again, 4 mistakes double again, etc.

Smart caching fixes a lot of the issues there. If a fork is marked somehow as successful then presumably the cache lookup next time will be less painful/costly.

Of course that's dependent on how caching gets implemented/where/when/how, but it's not unsolvable for common occurrence questions/answers.

As for getting the SOTA questions wrong : we as humans would likely also go through an iterative feedback loop until initial success and experience, too.

Except LLMs aren’t humans. Why do we continue to say “well, yeah but humans <do this same imperfect thing>”? A major point/goal is for these to be better and less error prone than humans. It’s just coping at this point.

Because humans take longer than Claude, and most of them want to be paid more than $200 per month. I don't just have access to another human at my beck and call at all hours.

That isn't needed, as LLMs are way cheaper. Even if they never advance beyond strong new grad, their cheapness is enormous value add on its own. GitHub will presently sell you 1500 AI generated PRs a month for $40. You used to have to pay a human 10K a month, even if it was small stuff.

All kinds of software that are worth as little as 10K a year are now worth building, as making and supporting them is so trivial.

How many of these things have you developed and are maintaining this way?

That goes too far in the opposite direction.

Humans come with a broad range of skills and performance; LLMs are inside this range.

The fact LLMs are not human, and the fact that the best humans beat them, is as economically relevant as the fact that a ride-on lawnmower isn't human and (typically) an athlete can outrace them — i.e. it resolves to what you're actually using them for.

But it is not merely the best humans. Any good developer is able to write better code, because by definition LLMs tend towards the mean, which is mediocre code, mostly from GitHub, they were force-fed as training data.

They may excel at solving very narrow problems with decent results, like in that programming competition recently. But those are indeed very narrowly defined problems, and while they may solve it decently in limited time, that is roughly their overall limit, while a human, given more time, can excel to a much higher level.

It becomes a question of whether we want mediocre things, that are not very extensible and maintainable, relying on the very thing that produced these mediocre codes to maintain and extend them, or do we want high quality work.

For the latter one would want to hire qualified people. Too bad though, that hiring is broken at many companies and they don't recognize qualifications, when right in front of them.

I suspect we're not in strong disagreement here, because you recognise that not all humans are equal, and that some are indeed worse than LLMs. But:

> because by definition LLMs tend towards the mean

This part is false: the mean human can't write code at all. Also, as per your own point:

> They may excel at solving very narrow problems with decent results, like in that programming competition recently.

LLMs are often in the top decile of coding challenges, which are already limited to better-than-average developers. Now, these same models that get top decile scores in challenges are still not in the top decile overall because the role of software developer is much broader than just leetcode, but this still demonstrates the point: LLMs do not tend towards the mean.

> But those are indeed very narrowly defined problems, and while they may solve it decently in limited time, that is roughly their overall limit, while a human, given more time, can excel to a much higher level.

Except "code" is itself not narrowly-defined even despite what I just said. Even within one programming language, comprehension of the natural language task description is itself much harder and more general than any programming language, and both the programming language and all the libraries are described in a mixture of natural and formal language. Even just the ability to recognise if it's looking at examples of C or JavaScript is something it had to learn rather than being explicitly programmed with knowledge of.

Now sure, I will absolutely say that if the working definition of "intelligence" is about how few examples are needed to learn a new thing, then transformer models are "stupid". But, to a certain degree, they're able to making up for being very very stupid by being very very stupid very very quickly and very very cheaply — cheap enough and fast enough that when you do hit their skill limits, there's many cases where one can afford to boost them a noticeable degree, and it's affordable even though every m-times-n-quality-points you need to boost them by comes with 2^n increase in their cost in both time and money.

Not always, and it's an exponential cost per linear improvement, but often.

> LLMs are often in the top decile of coding challenges, which are already limited to better-than-average developers. Now, these same models that get top decile scores in challenges are still not in the top decile overall because the role of software developer is much broader than just leetcode, but this still demonstrates the point: LLMs do not tend towards the mean.

Like I said: Very narrowly defined problems, yes they can excel at it.

But sometimes they don't even excel at that. Every couple of months I try to make LLMs write a specific function, but neither did they succeed in January, nor did they succeed a few weeks ago. Basically, zero progress in their capability of following instructions regarding the design of the function. They cannot think and as soon as something is rare in their training data, or even non-existent, they fail utterly. Even direct instructions like "do not make use of the following functions ..." they disregard, because they cannot help themselves with the data they were trained on. And before you ask: I tried this on recent Qwen Coder, Mistral 3.1, ChatGPT, and someone else tried it for me on Claude-something. None of them did any better. All incapable of doing it. If the solution is in their training data, its signal is so weak, that they never consider it.

This leads me to question, how much shit code they introduce to solve a narrowly defined problem like in coding competitions.

> Like I said: Very narrowly defined problems, yes they can excel at it.

See next paragraph.

I've been hearing this a lot, but I kinda disagree. They aren't plateauing IMO, they are getting better at new things, and that enables new capabilities. This doesn't often show in the traditional benchmarks (which are becoming less and less useful indicators of capabilities).

Take gemini 2.5 for example. It has enormous useful context. There were gimmicks before, but the usefulness dropped like a stone after 30-40k tokens. Now they work even with 100+k tokens, and do useful tasks at those lengths.

The agentic stuff is also really getting better. 4.1-nano can now do stuff that sonnet 3.5 + a lot of glue couldn't do a year ago. That's amazing, imo. We even see that with open models. Devstral has been really impressive for its size, and I hear good things about the qwen models, tho I haven't yet tried them.

There's also proof that the models themselves are getting better at raw agentic stuff (i.e. they generalise). The group that released swe-agent recently released mini-swe-agent, a ~100 LoC harness that runs Claude4 in a loop with no tools other than "terminal". And they still get to within 10% of their much larger, tool supporting, swe-agent harness on swe-bench.

I don't see the models plateauing. I think our expectations are overinflated.

I see myself in that description, and I LOVE this new way of working. It eliminates most yak shaving that comes my way, and that's what I hated most from the before times. I can quickly build mental models on things and focus on the solution building instead of bike shedding the code. It's not perfect, but it's pretty great.

But aren't you still yak shaving? Only that you are not typing yourself, but the AI does? The results you deliver will still be just as much yak shaving as before, and worse quality probably.

This is me.

I want to solve a problem, I know how to solve the problem, but I don't want to spend 30 minutes figuring out how to do the thing in Language X with Framework Y.

I know _what_ I need to do, but can't remember _how_ it's done in this specific language. The AI knows and can either tell me straight away by examining the project or I can just have it do it and review the solution.

I care about how something is done and doing it in the most simple and idiomatic manner I can.

However, when I am learning a new space (teaching myself SwiftUI, coming from a Java/infra background), Claude lets me preserve my forward momentum, which helps with motivation.

I tend to go back and rewrite a lot of the first iterations, but it has proved super useful unblocking me when I don’t yet understand how to tackle something I want to do in this new space, or sparking some ideas.

> I care about how something is done and doing it in the most simple and idiomatic manner I can.

Same, and I have been coding ever since I was a kid (I am only in my early 30s).

That said, I usually know the language enough to be able to tell if it is idiomatic or not. That said, I still prompt the LLM to give me idiomatic code, and I will see if it checks out or not.

"Make it work, make it pretty, make it fast."

That's the motto I do my software by.

With LLM tools like Claude I can get the first step done quicker than ever. Then I can start dogfooding whatever I build and slowly make it prettier.

Sometimes I don't even bother with that, it works well enough so that I don't want to bother spend the time time refactoring it.

This all day. Programmer since c64, c++, java, f#, python, JavaScript and everything in between. Code was never the point, but it wasn't just commerce either - it's fun making machines do things they couldn't before. AI is an s-tier upgrade to that mission.

I first got paid to code 25 years ago. I have been programming since I was a kid, and always will. I love making computers do things.

I definitely don't love the process: design docs, meetings, code review, CI, e2e tests working around infrastructure that acts too good to spin up in my test (postgres what are you doing, I used to init databases on machines less powerful than my watch, you can init in a millisecond in CI).

It is pretty clear to me agents are a key part of getting work done. Some 80% of my code changes are done by an agent. They are super frustrating, just like CI and E2E tests! Sometimes they work miracles, sometimes they turn into a game of wackamole. Like the flaky E2E test that keeps turning your CI red, but keeps finding critical bugs in your software, you cannot get rid of them.

But agents help me make computers do things, more. So I'm going to use them.

I fall into the latter category and I’m a strong proponent of ai.

Do you know how many times I’ve solved the same boring thing over and over again in slightly different contexts?

Do you know how many things I look at and can see 6 ways to solve it and at least 3 of them will turn out fine?

I can get ai to do all that for me now. I only have to work on the interesting and challenging pieces.

I am finding that I really like AI for tasks I don't want to do, and am annoyed by it for tasks I enjoy.

A non-programming example: I do some work in library music. I thoroughly enjoy writing and producing the music itself. I don't like writing descriptions of the music, and I'm not very skillful at making any needed artwork. I don't use AI for the music part, but use AI extensively for the text and artwork.

(I'm also not putting a human out of work here; before using AI for these tasks, I did them myself, poorly!)

I love programming but I don't really enjoy figuring out how to consume other people's APIs.

The things I've enjoyed writing the most have always been components "good practice" would say I should have used a library for (HTML DOM, databases) but I decided to NIH it and came up with something relatively pleasant and self contained.

When I use LLMs to generate code it's usually to interface to some library or API I don't want to spend time figuring out.

It's easy enough to defend your categorization by saying that anyone who claims they're in the dislike.1 group who likes it is really in the like.1 (or 2 or 3) group, but I think it's the dislike.1 group that's most likely to reap the benefit of AI help, having seen the industry go through paradigm shifts (like the rise and fall of OOP) and being tired of having to keep up. At the start of my career, I got real good with C++ in Visual Studio and the MFC libraries, only to throw that away for Python and WX, only to throw that away for Jquery only to throw that away. I put on an English stiff upper lip and learn the next thing, but I'll be honest, I'm not 20 anymore. I've changed, things have changed. Getting a really clever code-golfed function in C++ really tickled my fancy back in the day, until I had to go back and figure out wtf I'd written and had to fix a subtle bug with it. (I do still miss writing that kind of "I'm too clever for my own good" code though.)

So even before AI my taste in what constitutes the joy of programming evolved and changed. AI lets me waste less time looking up and writing almost-boilerplate shit that I'd have to look up. I'm often writing things in new/different languages that I'll be transparent, I'm not familiar with. I do still look at the code that gets generated (especially when Claude runs itself in circles and I fix it manually), and I roll my eyes when I find egregiously stupid code that it's generated. What I guess separates me then is I just roll my eyes, roll up my sleeves, and get to work, instead of going off on a rant about how the future of programming is stupid, and save even my own journal from a screed about the stupidity of LLMs. Because they do generate plenty of stupid code, but in the course of my career, I'd be lying if I claimed I never have.

As to the big question, do I like AI dev? Given that it may put me out of a job in "several thousand days", it would be easy to hate on it. But just as the world and my career moved on from fat clients on Windows in the 90's, so too will the work evolve to match modern tools, and fighting that isn't worth the energy, imo, better to adapt and just roll with it.

Not development related but I have plenty of colleagues that take pleasure in the mundane. Small easy dopamine hits I guess.

I don't know if there's a correlation between the groups as you say, but I will add some contradictory anecdata.

I started learning to program at about the same age I learned to read, so since the late 80s. While I was finishing secondary school, I figured out from first principles (and then wrote) a crude 3D wireframe engine in Acorn BASIC, and then a simple ray caster in REALbasic, while also learning C on classic Mac OS. At university I learned Java, and when I graduated I later taught myself ObjC and swift. One of my jobs, picked up a bit of C++ while there; another, Python. I have too many side projects to keep track of.

Even though I recognise the flaws and errors of LLM generated code, I still find the code from the better models a lot better[0] than a significant fraction of the humans I've worked with. Also don't miss having a coworker who is annoyingly self-righteous or opinionated about what "good" looks like[1].

[0] The worse models are barely on the level of autocomplete — autocomplete is fine, but the worst models I've tried aren't even that.

[1] I appreciate that nobody on the outside can tell if me confidently disagreeing with someone else puts me in the same category as I'm describing. To give a random example to illustrate: one of the people I'm thinking of thought they were a good C++ programmer but hadn't heard of any part of the STL or C++ exceptions and wasn't curious to learn when I brought them up, did a lot of copy-pasting to avoid subclassing, asserted some process couldn't possibly be improved a few hours before I turned it from O(n^2) to O(n), and there were no unit tests. They thought their code was beyond reproach, and would not listen to anyone (not just me) who did in fact reproach it.

> They thought their code was beyond reproach, and would not listen to anyone (not just me) who did in fact reproach it.

With an attitude like this, they would suck as a colleague regardless of profession.

I genuinely enjoy programming, but I don't enjoy doing maintenance programming on other people's horrible code.

This is the sort of thing no one wants to do and leads to burnout.

The AI won't get burnt out going through a static analysis output and simplifying code, running tests, then rerunning the analysis for hours and hours at a time.

Unfortunately we have no agreed upon metrics for simplified code.

And we have no realistic way of taking a drastically refactored application that was the result of hours of changes by an LLM and being confident that it doesn’t introduce bugs or remove load bearing bugs.

Static analysis and test suites aren’t good enough for pushing very large changes to production.

We have metrics such as cyclomatic complexity, the number of arguments, and the number of lines in a given method/function/file. These are usually fine to find the festering portions.

We also have no realistic way of being confident that letting a coworker/junior/intern make hours of changes will confidently not introduce bugs or load-bearing bugs.

Reducing cyclomatic complexity says very little about what we care about when we talk about simple code. It’s very possible, even likely to produce code with fewer branches that is much harder to reason about.

Cyclomatic complexity says almost nothing about architectural complexity. There’s a reason talking about cyclomatic complexity fell out of favor 20-30 years ago. We tried using it as a software quality metric and it failed.

There are no good, widely agreed upon metrics for software quality.

An optimizer that tries to reduce lines of code per function or file is going to overfit to the specific version of the system at the expense of readability and maintainability.

Both of these metrics will likely ensure you do the exact opposite of what you’d really want when you say you want to simplify the code.

>coworker/junior/intern

I would never in a million years allow anyone to go off by themselves and spend hours and hours unsupervised changing tens of thousands of lines of code with no goal but to simplify the code.

I love experiences folks shared in response to this. Makes me realize that there are many significant factors that influence how people see programming. My own experience for most years has been a combination of the joy of clear/convincing writing with the joy of a high level ergonomic language (Ruby) to express the code. In Ruby and its frameworks, you almost never write boilerplate, so everything is the interesting part. And the surest way to have good understanding of the code is to type it out. (That's why most books ask you to manually type the example code). Figured I'd share my experience too.

I am both 1) and 2) and totally in love with AI dev… I am just one soul of course, your general observation might be right.

With 3 decades under my belt in the industry I can tell you on trait that THE BEST SWEs ALL have - laziness… if I had to manually do something 3 times, that shit is getting automated… AI dev took automation of mundane parts of our work to another level and I don’t think I could ever code without it anymore

I'm a bit different in your list, imo. I'm ~25years camp, did it long before it was my career and it's been my obsession for most of it.

I use Claude Code for two primary reasons:

1. Because whether i like it or not, i think it's going to become a very important tool in our craft. I figure i better learn how to use this shovel and find the value in it (if any), or else others will and leave me behind.

2. Because my motivation outweighs my physical ability to type, especially as i age. I don't have the endurance i once did and so being able to spend more time thinking and less time laboring is an interesting idea.

Claude Code certainly isn't there yet for my desires, but i'm still working on finding the value in it - thinking of workflows to accelerate general dev time, etc. It's not required yet, but my fear is soon enough it will be required for all but fun hobby work. It has potential to become a power tool for a wood workers shop.

> To make the distinction clear, here are example groups unlikely to like AI dev:

> 1) people who programmed for ~25 years (to this day)

> 2) people who genuinely enjoy the process of programming (regardless of when they started)

> I'm not sure if I'm correct in this observation, and I'm not impugning anyone in the first groups.

I’ve been programming for almost 30 years. Started when I was 9 years old and I’ve been looking at code pretty much every day since then.

I love AI coding and leading teams. Because I love solving big problems. Bigger than I can do on my own. For me htat’s the fun part. The code itself is just a tool.

OP is not a programmer and the comment is the top comment: https://news.ycombinator.com/item?id=44702811

There's nothing wrong with not being a programmer, but it is still kind of funny that "hackers" and their backers approve the script kiddie way by voting.

I don't think the 2) category is universal. There are many people in that category who know that following corporate hype will be rewarded, but I'm not sure they all like vibe coding.

It's not really much of an insight that people who like programming itself don't want to outsource it to an AI, whereas people who like building things do.

You're probably right, but this dividing line only became prominent now that AI coding agents polarized the community across it. This in itself is interesting to me.

Yes, definitely, I just mean that all the groups can be condensed down to those two.

I guess there are some who would've enjoyed coding, but circumstances pulled them away from it. The word "intimacy" comes to mind. If you lose intimate relationship with code writing (or never gain one), you will be more okay with AI.

Perhaps I'm trying to point out that sometimes you lose it accidentally, while still instinctively thinking that you enjoy writing code.

like any attempt to categorize humans, it falls shorts on many exceptions.

I've been at what I do for 32+ years now, I love programming and I havent stopped since I started.

I love claude code. Why? It increases discoverability in ways far and beyond what a search engine would normally do for me. It gets rid of the need to learn a new documentation format and API for every single project that has different requirements. It makes it less painful to write and deal with languages that represent minor common current trends that will be gone by next year. I no longer have to think about what a waste of time onboarding for ReactCoreElectronChromium is when it'll be gone next year when Googlesoftzon Co folds and throws the baby out with the bathwater.

I would say somewhat correct but your own bias might be coming through a tiny bit here :-)

I think it more comes down to one of your last points. It's not necessarily a difference specifically in who likes to use "AI" or not - in my experience there's just a different class of tech workers between new and old.

On one extreme you have the old greybeard maintaining mainframe systems with obscure COBOL niches that LLMs won't ever have insight into. On the other end you have people working on the latest shiny thing.

I don't think it comes down to money or love for the actual work - I know plenty of people invested in the math behind AI and how it might help them be more efficient coders. The divide (if we should even call it that) already existed in the way these two groups approach tech - AI and LLMs has just made it more obvious.

I think you're wrong with those groups.

I'll use myself as counterexample, but I know a sufficiently large number of people like me who also love AI to suggest the pattern's wrong.

Programming for 4 decades, happy to language lawyer with my C++ compiler, and love puzzle solving.

And yet, I see AI as a tremendous gift. It's brought back the early exploratory feeling and joy. It's also taken care of a lot of tedium (no, migrating to a new library/api never was fun)

And, best of all, how to use AI well/correctly to produce prod quality code is one of the biggest puzzles out there. It's a great time!

But I don't think your characterization is entirely wrong, because the 'Ugh! AI!" continent is indeed strong in your second group. Specifically, people who have that long seniority and enjoyed being "the expert" - i.e more knowledgeable about a topic than many. AI is compressing that gap.

I'd agree with this assessment overall. It's got flavors of an age-old debate that comes up any time a new efficiency arises between the people who value the efficiency and those who value the process (eat a nutrition bar vs. cook a meal, drive instead of walk, etc.)

People quickly divide into camps, but I think the healthiest (albeit boring) view is that the tech is good for certain efficiencies, and you have to choose if you prefer the speed you gain over joy of the activity, which probably varies day-to-day. I love the walk to my local grocery store in the mornings because I enjoy the sunshine and exercise. I'm getting in my car the second I'm in a rush though. In the same way I love programming and software engineering, so if I've got the time I'm going to dig into coding. Under deadline to do an annoying legacy migration from an obscure language? Hello Claude Code :)

You don't like software engineering; fine.

I don't like how this technology is being shoved in the face of people who _do_ like being SWEs and got into this career path _because_ they liked it. All while ignoring the very-real and increasingly-discarded ethical concerns it brings and the massive, massive subsidation almost all of these tools are being fueled by.

That we're collectively _racing_ to have knowledge and means of production be centralized by a handful of massive corporations is shocking. And scary.

100% with you. I thought I loved writing code until a few months ago when I was able to tell an LLM exactly how I wanted it done, exactly the structure and the goals for today. I realized that I love getting stuff done and that writing code was the price I had to pay in terms of my time.

Exactly this for me as well. And I'm really good at writing code! It's so weird to realize I never liked it, that I just liked making things.

Now I don't write code unless Claude does it, I just review.

I'm in the "love the build products" camp. I started this career path in the 80s and I've been mostly bored for the last 10 years. Claude Code is letting me build and ship like crazy. I'm back to late night sessions and having a blast! I even trained it to speak in Star Trek lingo like. Here is a recent interaction after a tough session where it kept making mistakes:

Mission Complete, Captain! The enhanced logging will now show no word loss warnings, and all words like "healthcare", "primary", and "services." will appear in the final VTT output.

> Are you willing to bet money on that?

Captain, I appreciate your direct questioning of my confidence level! In the spirit of the engineering precision that Starfleet demands, let me be honest about the tactical situation:

  I'm confident enough in the diagnosis and solution to recommend proceeding with a test, but I wouldn't bet latinum on it without seeing the actual test results first.

  Shall we proceed with testing to verify the solution, Captain?

> Yes

Mission Success, Captain!

  The logs show a complete victory.   I am now confident enough to bet replicator rations on this fix, Captain!

Agreed. The constraints of software engineering are mostly idiomatic. I used to use my "Scribe" mind to crawl through library dependencies for days to solve some artificial sub-problem.

No software engineer is good enough to time-efficiently write the whole stack from machine code up - it will always be an arbitrary and idiomatic set of problems and this is what LLMs are so good at parsing.

Using "Scribe" cycles to define the right problem and carefully review code outputs seems like the way.

It boggles the mind whenever I meet a software engineer that doesn't love the process of building software. That's why everyone I came up with got into programming in the first place. How many authors do you see that just want complete books, but don't care for writing?

Reply on news.ycombinator.com