> 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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
It can happen if you develop health issues like carpal tunnel or Sciatica due to extended sitting. Programming then gets mentally associated with pain.
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.
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.
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.
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 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.
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.
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.
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.
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.
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 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 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.
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.
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'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 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.
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 :)
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.
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.
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 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 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 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 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.
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'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'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.
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!)
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'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.
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.
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.
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.
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 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.
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?
For me the fun part of coding is having visions of products or systems I'd like to exist, and writing code only as a means to an end.
Claude Code (AI coding agents/assistants) are perhaps the best thing to happen to my programming career. Up until this point, the constraint going from vision to reality has always been the tedious process of typing out code and unit tests or spending time tweaking the structure/algorithm of some unimportant subset of the system. At a high level, it's the mental labor of making thousands of small (but necessary) decisions.
Now, I work alongside Claude to fast track the manifestation of my vision. It completely automates away the small exhaustive decision making (what should I name this variable, where should I put this function, I can refactor this function in a better way, etc). Further, sometimes it comes up with ideas that are even better than what I had in my head initially, resulting in a higher quality output than I could have achieved on my own. It has an amazing breadth of knowledge about programming, it is always available, and it never gives up.
With AI in general, I have questions around the social implications of such a system. But, without a doubt, it's delivering extreme value to the world of software, and will only continue the acceleration of demand for new software.
The cost of software will also go down, even though net more opportunities will be uncovered. I'm excited to see software revolutionize the under represented fields, such as schools, trades, government, finance, etc. We don't need another delivery app, despite how lucrative they can be.
I see AI-accelerated codegen as doing all of the boring shit I hated:
do while error == true;
Write code
Run code
Read error
Attempt to fix error
Run code
Read error
Search Google for error
Attempt to fix error
Run code
Read error
done
---
Claude does all of this for me now, allowing me to concentrate on the end goal, not the minutiae. It hasn't at all changed my workflow; it just does all of the horribly mundane parts of it for me.
I like it and I recommend it to those who are willing to admit that their jobs aren't all sunshine and roses until the product is shipped and we can sit back and get to work on the next nightmare.
If you enjoy being a custodian no one is going to chastise you for that. As you have stated there are many nightmares to clean up and all teams need a person who wants to do the clean up.
This will keep you out of the bleeding edge feature/product space because you lack a honed skill in actually developing the app. Your skill is now to talk to an LLM and fix nightmare code, not work on new stuff that needs expertise.
I think writing code was never slow. Or atleast never the slowest part of the overall process.
Vibe coding might be fast, but thats only if you wish to pretend that coders deploy to production directly within minutes of writing code without product discussions, automated builds, CI/CD, code review, production testing, UAT, regression testing, security testing etc.
In reality when you factor in all these things, which are absolutely necessary if you don't want you product to break every new release and lose users permanently. You have to do the same drills as you always did.
To that end, unless you are building something very large, coding velocity is largely irrelevant.
I would also argue that the OPs comment describes “hacking” not “writing code”.
They could escape that loop by employing software development skillsets, for example TDD or perhaps using the debugger instead of pounding away at a compiler.
Usually when people pound at a compiler it’s because they don’t know what they’re doing or how software even works.
And by handing over all the small decisions and things like writing unit tests, you are opting in to mediocre code quality (or worse) and you no longer get the full experience of using your code, for example when writing unit tests yourself. Or when in other cases where you call your own procedures from your own code. When writing a test becomes difficult it is often (not always) an indication of bad code quality.
It will also lead to you being less familiar with the code in general.
It may be, that all of those are OK in your scenario or use case.
It's like the Blank Page Problem for writers. It's really hard to start.
But if you have a shitty page of text, you can edit it to make it better.
With LLM tools I can get from idea to (shitty) proof-of-concept solution really fast. Then I can start dogfooding it and improve and rewrite.
But sometimes the shitty solution is enough for my purposes. It works and doesn't actively break shit. My problem was solved and I don't need to optimise the silly TUI yt-dlp wrapper it just made me.
For me the problem with the vision is that stuff I’d like to exist is so far above the capabilities of AI (rather complex games) that I don’t even want to try it. And for stuff that I build and use they are pointless because they don’t accelerate me much.
I found it great to write bash scripts, automation, ffmpeg command lines, OCR, refactoring… it’s a great autocomplete.
Working in a large team I realized that even relying too much of other people’s work is making me understand the technology less and I need to catch up.
Even if you're working on a large complex system like that, I believe coding agents are still useful at at least taking highly specific prompts/instructions you write and doing the writing for you. Then doing other tedious tangential work like generating unit tests over a pure function, adding comments, generating documentation, etc that all increase the quality of the codebase without requiring toil on your part.
With especially novel or complex projects, you'd probably not expect to use the agent to do much of the scaffolding or architecting, and more of the tedium.
Not to impede your overall point, but have you not encountered a situation where Claude gives up? I definitely have, it'll say something like "Given X, Y and Z, your options are [a bunch of things that do not literally but might as well amount to 'go outside and touch grass']."
I've been experimenting lately with just interfacing with Claude Code through the GitHub action and issues.
I sit on the beach and talk to it through the GitHub iOS app. I set the timeout to 4 hours and let it just work. It comes back to me later with something and I take a look. By the time I get home, I might tweak a few things here or there manually (particularly if it's about aesthetics), and merge.
I agree and do experience that. Perhaps to clarify, I mean that it (unlike humans), is always down to code alongside you. It will never complain, get sick, have a life event. etc.
I didn't become a software developer so I could write the same SQL queries, the same plumbing code, the same boilerplate beginnings of programs, the same repetitive error handling, the same string formatting, the same report generation, the same HTML templating, and the same thread cancellation logic. I also didn't become a programmer so I could gratify myself by yak-shaving elegant helpers for those SQL queries, plumbing, boilerplates, error handlers, formatting, reports, templates, and cancellations.
Bloggers have been kidding themselves for decades about how invigorating programming is, how intellectually demanding it is, how high the IQ demands are, like they're Max von Sydow playing chess with Death on the beach every time they write another fucking unit test. Guess what: a lot of the work programmers do, maybe even most of it, is rote. It should be automated. Doing it all by hand is part of why software is so unreliable.
You have a limited amount of electrical charge in your brain for doing interesting work every day. If you spend it on the rote stuff, you're not going to have it to do actually interesting algorithmic work.
I worked on visual studio at Microsoft 20 years ago, and once had the opportunity to go to a trade show to represent the company.
While I was manning a booth, this software developer came up to me and said VS had gotten too good at code generation to automate data access, and we should cut it out because that was the vast majority of what he did. I thought he was joking, but no, he was totally serious.
I said something to him about how those tools were saving him from having to do boring, repetitive work so that he could focus on higher value, more interesting development, instead, but he wasn’t having it.
I think about him quite often, especially these days. I wonder if he’s still programming, and what he thinks about LLMs
I think I partially agree, your first paragraph is exactly how I feel. Boilerplate and trivial stuff absolutely should be automated. It's also true that people have been pushing a narrative where programming is some dark art and you should use Methodology X or Theory Y. Bro, chill, you're writing a website.
On the other hand software development in the high sense, i.e. producing solutions for actual problems that real people have, is certainly intellectually demanding and also something that allows for several standard deviations in skill level. It's fashionable to claim we all have bullshit jobs, but I don't think that's a fair description at all.
> "producing solutions for actual problems that real people have, is certainly intellectually demanding and also something that allows for several standard deviations in skill level"
Absolutely agreed, but I think the idea is that coding tools (or languages, or libraries, or frameworks) frees us to do the actually hard, skill-intensive bits of this, because the thing that's intellectually demanding isn't marshaling and unmarshaling JSON.
This is exactly why we moved from Assembly code to higher level languages and then to using frameworks.
Nobody is paying you to make a CRUD web app in Assembly, they're paying you to solve a problem.
You're not getting any extra points for using plain vi(m) with no autocomplete to write a Java application. Making stuff the hard way is just stupid performative crap.
LLMs are just the next iteration of autocomplete -> intellisense -> language servers.
Now instead of autocompleting a method or property, they can autocomplete full unit tests and functions by looking at the patterns across the codebase.
+1, and also to add: this isn't even a new phenomenon. My hot take is that AI coding is only the latest in a trend that has been running in the industry for literally decades. The technology itself might be novel but what it's doing is very, very old!
You used to have to write tons of real code to stand up something as simple as a backend endpoint. Now a lot of this stuff is literally declarative config files.
Ditto frontends. You used to have to imperative manage all kinds of weird bullshit, but over the last decade we've gradually moved to... declarative, reactive patterns that let the some underlying framework handle the busywork.
We also created... declarative config files to ensure consistent deploys every time. You know, instead of ssh'ing into production machines to install stuff.
We used to handle null pointers, too, and tore our hair out because a single missed check caused your whole process to go poof. Now... it's built into the language and it is physically impossible to pull of a null pointer dereference. Awesome!
We've been "putting ourselves out of work" for going on decades now, getting rid of more boilerplate, more repetitive and error-prone logic, etc etc. We did it with programming languages, libraries, and frameworks. All in the service of focusing on the bits we actually care about and that matter to us.
This is only the latest in a long line of things software engineers did to put themselves out of work. The method of doing it is very new, the ends are not. And like every other thing that came before it, I highly doubt this one will actually succeed in putting us out of work.
Me neither, that's why I write higher level abstractions or use libraries and languages other people have written. I don't get how you were writing so much boring stuff manually before LLMs. What do you do?
I'm not the OP, but from what he said I can tell you two things:
1. He is using computers to solve other peoples problems, and they are similar problems so all the code looks the same, and
2. He is NOT using computers to solve his own problems. Every top notch software engineer I've met does not write the same code more than a few times, because doing repetitive stuff is something a computer should be doing.
It’s the standard response anytime someone claims they get productivity boosts from ai. Either you are inexperienced or bad at your job.
On a board that would deride any other no true Scotsman take, this one happens on every ai discussion.
It’s no longer worth engaging with. I’m now just posting basic statements like “I’ve been programming professionally for 25 years and I find ai to be extremely helpful”. That way there is at least someone claiming the opposite. But you aren’t going to convince anyone as they already shut that door with their statements.
For what is worth, it had nothing to do with whether he uses AI. I'm north of 60yo, started on punched cards and paper tape and have been programming ever since. My experience suggests if you aren't keeping up by using AI now there is a good chance you won't be a relevant software engineer in a decades time.
The bit that triggered my response is this:
> Guess what: a lot of the work programmers do, maybe even most of it, is rote.
Yes, I know a lot of programmers who do that. In fact it seems most programmers I see in the industry do that. Many of them are very good at it, in the sense that a good brick layer will be content to devote his lifetime to laying bricks in a straight line and will be far more reliable and conscientious at it than I could every be. However, that personality type is unlikely to become a top engineer or architect. To be good at those jobs you need to get bored in a couple of years at most. You have to be internally driven to try new things, and experiment with new ideas.
When such a person is confronted with the prospect of a lifetime of churning out code that almost follows a template (and I daresay could easily be produced by today's LLM's) he doesn't sit still and do it. He finds something more interesting to do. Since he's a computer programmer and the task is well suited a computer doing it, he probably take up a skunk works project of churning out the repetitive parts of that code, so he didn't have to do it. It's far more fun, saves time in the long run, and if he is a good software engineer in the long run the systems it produces will be more reliable, and use less code than something programmer code have produced by churning out the same stuff every day for years.
Going by the OP's comment, he hasn't done that, despite apparently being bored shitless with what he does do. There is a solution, but it isn't the LLM's he suggests. All using LLM's change is the language are giving to the "compiler". The end result is still him creating the same CRUD app using the same platforms, libraries and tools his is using now.
There are lots and lots of us who have gone down the road of generalizing code and have decided the outcomes, for the business that pays for the software, are worse. Frequently it devolves into code that is hard to reason about, architecture that is overblown for purpose or that does something just about, but not exactly, what you want it to do.
But more importantly, by dismissing the comment that way, you’ve made an implicit claim. You are claiming to be able to judge a persons capability or the challenges they are working on off of a couple hn comments. Thats bad engineering and anti-social behavior.
Imagine telling someone that learning to touch type was the sign of a bad software engineer because you don’t type that much because your libraries are all named with single letters. Thats what these arguments sound like to me.
> But more importantly, by dismissing the comment that way, you’ve made an implicit claim. You are claiming to be able to judge a persons capability or the challenges they are working on off of a couple hn comments. Thats bad engineering and anti-social behavior.
Somewhat true. But it did make me smile, because it reads very much like the pot telling kettle he's black.
But only somewhat. @tptacek also said this:
> Bloggers have been kidding themselves for decades about how invigorating programming is, how intellectually demanding it is, how high the IQ demands are, like they're Max von Sydow playing chess with Death on the beach every time they write another fucking unit test. Guess what: a lot of the work programmers do, maybe even most of it, is rote. It should be automated. Doing it all by hand is part of why software is so unreliable.
Seriously?
As I said, I've been programmer for decades now. He's coming from the perspective that the code dribbling off my fingertips without too much thought is "programming". It is, of course, in the same sense that the brush strokes of Van Gogh are what constitutes "painting". But the painting created by Van Gogh consisted of thousands if not millions brush strokes, all placed with precision, purpose and a great deal of thought. If placing the loaded brush on canvas is all there was to painting, all our houses would be adorned with Van Gogh's. He says we should all be using LLM's, but the idea that brush strokes placed by an LLM would produce same outcome is laughable. You might well use a painting LLM to paint 1000's of houses, but never a single Van Gogh.
To the people who delight in creating new and unique computer systems from code, the puzzle to be solved is arranging the code in just the right way to create their personal Van Gogh's. An immutable object here, a touch of recursion there, combined with an atomic compare and swap and in some truly heroic cases an FPGA thrown into the mix to get some extreme parallelism - crafting these in just the right mix is the challenge of programming. Overcoming that challenge is what makes it invigorating. Not writing the "fucking unit tests" as tptacek puts it, which is almost universally disliked. Although now I look back on it, it is almost therapeutic - it's like going for a jog; it's downtime, when you get review what you've done, and ponder your next moves while pounding the keyboard.
It's a shame, and somewhat insulting to see tptacek treat these efforts many find enjoyable with so much derision. But I've spared with tptacek here, when said similar things before. Again, he confidently said something completely wrong headed, and I could not let it go. Some things don't change I guess. As a fellow at a Linux meetup said to me a long time ago, "you wrote all those words because someone was wrong on the internet???".
I agree; I think there's a huge veil of perception thing happening here like. I've worked directly with dozens of coders and indirectly with hundreds, and like, no one does their job like I do? It's like we all show up to the job site, you have a drill, another person has a hammer, and I have a feather duster and a bottle of glue, and we all have the exact same job. No wonder what makes the drill person more productive doesn't do shit for the feather duster/glue person.
I massively agree. Huge amounts of coding isn’t wild new inventions, it’s not unknowable work like so many seem to suggest when asked to estimate time. Frankly it’s not even conceptually hard, it’s just that computers are fast and accurate and dumb so you need to be annoyingly precise. Imagine if a human refuses to read a manual because a comma should have been a semicolon. Plenty of people are smart enough to do it, but lack either the knowledge about this or the desire to deal with it.
Most of this work should go away. Much of the rest of it should be achievable by the domain experts themselves at a fraction of the cost.
If you made all this work go away with a new functional programming language, like if finally someone contrived the perfect type system where you could just declaratively lay out all the rote bits and evaluate them to the imperative steps you wanted taken, everyone would be thrilled. There would be people going around dunking on all the developers who didn't use that language.
The LLMs are still generating all that rote shit, that at some point must be maintained and read and understood. Potentially at a higher rate than any human could.
A lot of what AI coders are being praised for could be accomplished just as well with some good Lisp macros with much less technical debt.
I understand what you're saying. But in the programming environments I work in, the rote stuff that LLMs are automating is marginally better than the rote stuff I would write given the same parameters. Obviously, we could all do better if only we were writing the right Lisp macros. ;)
Programming is about not doing all of these things. You have a powerful machine that is quite good at doing those things. You just have to notice those patterns and then build the tool that will be doing those kind of works. And the most simple one is a snippet generator and editors macros. Then you have project generators, and code reuse thingies from the programming language.
I agree with this take, insofar as I interpret it as "we do a lot of bullshit that doesn't matter". Like, do you remember people arguing Rails vs Django, or even worse Rails vs Sinatra? I do and did, and my meager defense is that I was young and naive. The list of "I can't believe we spent any time building/doing any of that" is just so, so long. I mean, how many times are we gonna reimplement node ffs.
I always thought programming as being a touch more like two imbecile brothers outsmarting Max Von Sydow's plan to control the world with tainted beer and hockey arena organs.
If before I did a thing in 60 minutes and now Claude Code does it in 5 minutes I will not spend 55 minutes reviewing that code.
I will maybe spend 5-10 minutes reviewing and refining the code with the help of Claude Code and then the rest of the time I will go for another feature/bugfix.
Worth adding that sometimes I will spend an ~equivalent amount of time doing something in Claude Code, but the result is better.
Case in point recently I was working on a mobile app where I had to check for a whole litany of user permissions and present UI to the user if any particular permission was missing, including instructions on how to rectify it.
Super annoying to do manually, but Claude Code was not only able to exhaustively enumerate all possible combos of missing permissions, but also automatically create the UIs for each edge case. I reviewed all of it for accuracy, which took some time.
I probably would've missed some of the more obscure edge cases on my own.
Overall maybe not much faster than doing it myself, but I'm pretty sure the results were substantially better.
I spend a fraction of the time verifying LLM production of rote code --- which I do in fact do, I'm not a vibe coder --- than I would writing it. I don't understand why people always expect this to be a mic drop rebuttal.
Do you feel like you end up with as clear of a mental model reviewing it as you do if you wrote it?
I'm still trying to figure out the answer to that question for myself. Maybe the answer is, "Probably not, and it probably doesn't matter" but I'm still trying to figure out what kind of downstream effects that may have later on my judgment.
Yes, of course I do. It's rote stuff. To the balance of time we're accruing to me dealing with generated code, add "stripping off all the comments", "fixing variable names to be like I like them", etc. My fingerprints are still all over everything. And it's still radically faster than doing this all by hand.
Mental expenditure on programming is also not linear through a task; it takes much more energy to get started than to do the back half. Ever stared at an empty function for a minute trying to come up with the right variable name, or choosing which value to compute first? LLMs are geniuses at just getting things started.
My job pays well and I create real stuff but most of the work is honestly just slop. So maybe I should use AI to save myself the effort..I could salvage more free time for myself that way..
On Friday I was converting a constrained solver from python to another language, and ran into some difficulty with subsituting an optimzer that's a few lines of easily written Scipy; but barely being supported in another language. One AI tool found this out and fully re-implemented the solver using a custom linear algebra library it wrote from scratch. But another AI tool was really struggling with getting the right syntax to be compatible with the common existing optimization libaries, and I felt like I was repeatedly putting queries (read: $) into the software equivalent of a slot machine that was constantly apologizing for not giving a testable answer while eating tens of dollars in direct costs waiting for the "jackpot" of working code.
The feedback loop of "maybe the next time it'll be right" turned into a few hundred queries resulting in finding the LLM's attempts were a ~20 node cycle of things it tried and didn't work, and now you're out a couple dollars and hours of engineering time.
With mathematical things you can always write comprehensive and complete unit tests to check the AIs work.
TDD (and exhaustive unit tests in general) are a good idea with LLMs anyway. Just either tell it not to touch test, or in Claude's case you can use Hooks to _actually_ prevent it from editing any test file.
Then shove it at the problem and it'll iterate a solution until the tests pass. It's like the Excel formula solver, but for code :D
You could, and hope that you understand the problem domain and numerical analysis enough to hit all the hard cases. And then you’d have expanded your codebase with lots of tests that are relevant to a linear algebra library and not to what you’re trying to do.
Or you could use existing linear algebra libraries which are highly optimized, highly tested, and have a well-understood api that’s easier to review.
And then get back to the legit hard stuff, like maybe worrying if your linear solver needs preconditioning and how to best to that. Or any of the many numerical problems people tend to face when doing this kind of work.
I’m not sure why you’d give the llm a pass on reinventing the wheel here when you definitely wouldn’t with any other dev.
I'm curious why you think it doesn't work, when there are plenty of people saying it does.
There are limitations at the moment, and I don't see many people disputing that, but it must be doing something right, and its abilities are improving every day. It's learning.
Sometimes I get the feeling a lot of antis painted themselves into a corner early on, and will die on this hill despite constant improvements in the technology.
I have seen similar things many times in my career. There was a time when everyone were very skeptical of high level languages, writing everything in assembler come hell or high water, for example.
At some point it is going to single shot an entire OS or refactor a multi-million line codebase. Will that be enough to convince you?
From my perspective I like to be prepared, so I'm doing what I have always done.. understand and gain experience with these new tools. I much prefer that than missing the boat.
And, it's quite fun and better than you might imagine as long as you put a bit of effort in.
I'd rather work with a human. Even with our flaws, it's still better than constantly being lied to by a tin can. If a junior kept delivering broken results as much as the "AI" does, they wouldn't be on my team that long.
I think much like how we're still figuring out how to use and manage social media to minimize the downsides and maximize its utility, we're gonna have to do the same with AI. I find it incredibly powerful for certain things and incredibly frustrating for others. Begging the AI to one shot some project feels like the wrong way to use it, it's better as a scalpel. Or as a learning device, or a more advanced rubber ducky.
IMHO the root of the issue is that "AI" is being anthropomorphised, or oversold as actually "intelligent".
If there's anything I've learned about software, "intelligent" usually means "we've thrown a lot of intelligent people at the problem, and made the solution even more complicated".
Machine learning is not software, but probably should be approached as such. It's a program that takes some input and transforms it into some output. But I suppose if society really cared about physical or mental health, we wouldn't have had cigarettes or slot machines.
A helpful, and snarky, critique of the majestic rhetoric around “cloud computing” was to mentally replace “cloud” with “someone else’s computer”.
When thinking through a claim of what AI can do, you can do the same. “AI” -> “just some guy”. If that doesn’t feel fair, try “AI” -> “some well-read, eager-to-please intern”.
Was all that snark, the cloud to ass" string replacement firefox extension; was it actually helpful? We're still trying to sell the masses (and ourselves) on the benefits of self-hosting, and the cost of cloud hosting vs on-prem has never really been answered. Don't get me wrong, a trawl through my comments here will find I don't always manage to hold my tongue when I'm feeling snarky, so I very much understand the desire, but at the end of the day, what has that actually helped? My friends who were Unix and Linux sysadmins who didn't manage to upskill are still out of a job when their employers moved the servers they were babysitting into the cloud, and my data is still swimming around somewhere in Facebook and Google's data centers.
Sure let's call the AI names,
behind its back and to its face if we're feeling particularly bold, but is that actually going to amount to anything?
I think we're starting to have a conversation about what healthy social media usage looks like and its place in life. Maybe it's just my algorithm but I see a lot of content about moderation and a shift back towards being genuine. I fully understand the irony here btw.
Hopefully it doesn't take 2 decades of AI usage to have that conversation tho.
I never allow ai to write code, certainly not unsupervised. I like to write some code and then have claude check my work. Not just for bugs, but for architecture and style as well.
I let it write boilerplate, or other low impact stuff like html/css. It worked nicely converting Svelte components from Svelte 4 to 5 for example. And AI autocomplete has been a genuine productivity win although not without the occasional subtle bug. But I can't imagine trusting it for an entire codebase. If you're letting the AI write your code you're not thinking about it deeply enough to critique it imo. Which is fine for CSS or whatever but not most code.
It's such a great tool for learning, double checking your work, figuring out syntax or console commands, writing one-off bash scripts etc.
Can we collectively stop upvoting low quality 300 words random opinions about llm based dev? As a professional in the field I find the qualify of what's posted on HN really super low in this area, compared to posts eg related to cloud infrastructure or software engineering. There are better posts and sources than that.
The post may not have a ton of meat, but it resonates and seems ripe for discussion. It’s quite timely as we all try to figure out how and when to use these tools.
Your comment doesn’t add much. Where’s the substance to your critique?
For instance this one is a great, valuable read about AI and developers productivity: https://news.ycombinator.com/item?id=44526912
Post that are just opinions doesn't really fuel discussions as they don't bring enough raw material to build on. Some opinions are still worthy because they are original, but here I see nothing new.
I have been programming since 1978 and thoroughly enjoy it.
Nothing more satisfying to me than thinking about nifty algorithms, how to wring out every last drop of performance from a system, or more recently train AI models or build agentic systems. From object models to back end, graphics to communications protocols, I love it all.
But that said, I am getting on a bit now and don't particularly enjoy all the typing. When AI rolled around back in 2022 I threw myself into seeing how far I could push it. Copy pasting code back and forth between the chat window and the editor. It was a very interesting experience that felt fresh, even if the results were not amazing.
Now I am a hundred percent using Claude Code with a mixture of other models in the mix. It's amazing.
Yesterday I worked with CC on a CLAP plugin for Bitwig written in C and C++. It did really well - with buffer management, worker threads and proper lock-free data structures and synchronization. It even hand rolled its own WebSocket client! I was totally blown away.
Sure, it needs some encouragement and help here and there, and having a lot of experience for this kind of stuff is important right now for success, but I can definitely see it won't be that way for much longer.
I'm just so happy I can finally get round to all these projects I have had on the back burner all these years.
The productivity is incredible, and things mostly just work. It really brings me a lot of joy and makes me happy.
That’s a good way to put it. I hadn’t realized how gamified it has become. I originally felt like Claude and I were a team, but it goes off the rails so much that I find myself pulling the lever with increasing febrility. Fortunately I’m old enough to know when to quit but I’ve seen a friend just disappear into coaxing Claude for hours instead of writing code himself. I wonder if he’s got Claude gambling addiction
The irony is I alt-tabbed to HN to read this article after starting Claude Code on an implementation pass.
My usage of Claude Code sounds different to a lot of ways I hear people using it. I write medium detail task breakdowns with strict requirements and then get Claude to refine them. I review every single line of code methodically, attempting to catch every instance Claude missed a custom rule. I frequently need to fix up broken implementations, or propose complete refactors.
It is a totally different experience to any other dev experience I have had previously. Despite the effort that I have to put in, it gets the job done. A lot of the code written is better than equivalent code from junior engineers I have worked with in the past (or at worst, no worse).
Any code that chatgpt or claude ever gave me was overly verbose and highly inefficient in the best case, and riddled with subtle or not so subtle bugs in the worst case. Before the average junior dev will even discover those bugs his grasp on the codebase will have fallen so far behind that he won't stand a chance to redeem the project.
Software quality is taking a nosedive.
Our industry is vibecoding itself off the cliff.
My experience with AI seems to be totally different than for most people.
As an example, the other day asks chatgpt to write a configuration file for SQL fluff that formatted the code as an example that I provided.
It proceeded to invent all the SQL fluff rules. And the ones that were actual rules were useless for the actual format that I wanted.
I get it, SQLFluff rules are really confusing, but that's why I asked for help. I know how to code python I don't need AI to write code that then I will need to review
I think that's a very common experience when you try to make it write niche stuff. It just makes everything up wholesale. If you on the other hand wanted to write a react app ...
But then I may as well have the AI say no, I don't know how to do that, here are some useful resources. Instead of misleading me and making me waste my time figuring out why the code doesn't work
We might get there at some point. But it's not natural for this technology. It wasn't trained to recognize what it does and doesn't know. But I'm hopeful. It was terrible at doing math as well and it's getting significantly better with just more effort.
It might be hard to tune it though so that AI won't claim that it doesn't know something when it does, by error, or just because it doesn't like you.
It's not uncommon for a student to say they don't know something they actually do when they are questioned.
Or, you know, there are different ways of using these tools. Slapping something into ChatGPT is one way, though maybe not the most efficient way of getting value out of these tools.
Using an agentic coding assistant would be the first step (there are many, Cline, Claude Code, Gemini CLI and various others) as those can traverse the code base, execute tests, run queries or web search and feed the outputs back into itself to validate correctness of whatever the agent has created/done.
You won't need to set up this stuff for an hour every time, you set it up once and then you just give it commands.
The skill ceiling is deceptive, it feels very low at first (after all, it's just natural language, right?) but getting an intuition for where these tools work best and where they break down, how to task them, what to include in the instructions, it takes a bit of using them first.
That said, if you're a code maximalist, if you get most enjoyment out of hand crafting code or of you don't feel comfortable communicating effectively or delegating work, then maybe these tools aren't for you.
At this point in time I'm also pretty much over proselytizing anyone, I get a TON of value out of this stuff, but everbody has to find their own workflows.
Who says these tools don't make any mistakes? Don't put words in my mouth or project your own fallacies. Nothing in the world is perfect, but there is absolutely useful stuff to be had.
You heavily imply it in every comment you write. You've literally started debating my comment where I say that everyone runs into AI bullshit. You literally keep debating me when I point out that despite all the progress AI bullshit remains.
Your literal answer to "It's not different from most people. Everyone runs into AI bullshit." was literally "Or, you know, there are different ways of using these tools."
> Nothing in the world is perfect, but there is absolutely useful stuff to be had.
Says the person claiming I put words in his mouth or projecting my fallacies. Where exactly did I say this stuff wasn't useful? Literally nowehere.
> Keep your head in the sand though
Someone recently told me: "Don't put words in my mouth or project your own fallacies. "
That headline really resonates as I spent many years in Las Vegas. LLMs in general have very slot machine like qualities. WHen they “pay off” they are great.
Oh great, together we are two datapoints that reinforce the OP's hypothesis. I have a strong distaste for gambling in all forms and I don't enjoy using opaque, unreliable text generators either.
There are many ways to describe LLMs and coding assistants. The slot machine is a pretty good one.
I also compare "AI" to using a Ouija Board. It's not meant for getting real answers or truth. The game is to select the next letter in a word to create a sequence of words. It's an entertainment prop, and LLMs should be treated similarly.
I have also compared "Artificial Intelligence" to artificial flavors. Beaver anus is used as artificial vanilla flavoring (that is a real thing that happens), and "AI"/LLMs are the digital equivalent. Real vanilla tastes so much better, even if it is more expensive. I have no doubt that code written by real humans works much better than AI slop code. Having tried the various "AI" coding assistants, and I am not at all impressed with what it creates. Half the time if I ask for "vanilla", it will tell me "banana".
Right? I hope that at some point the weights system will become clear enough that one could bias against wrong answers. Just “telling” it that is wrong biases for the current token cache and doesn’t back propagate to the model. Of course back propagating user input would be very exploitable so I don’t see that happening.
I started writing software in 2001 - I loved problem solving, or the act of creating the perfect snowflakes of SOLID code, the most beautifully optimized database query or the most developer friendly SDK libraries - probably stemming my experience joining projects where the code base was trash. But parts of the job do feel like repetitive drudgery... which is where I think AI comes in beautifully.
What I've learned so far is that AI is only as good as the average developer who writes code and is only as effective as the codebase is approachable... unless you let the AI contribute to the architecture at the ground floor it will get just as confused and write just as much spaghetti code as a human coder will.
Like other professions before us... this is a moment where software engineers must adapt or perish. It was a battle to overcome the stubborn mindset of being unchanged in my ways (and adopt AI)... but the writing is on the wall. And now I'm building and refining the very same AI tools that do the jobs of data analysts and software engineers.
My worry is we're going to have a generation of engineers that have not built up the necessary critical thinking/pattern matching skills needed to weigh tradeoffs and bring in context to ask the right questions and interpret the answers.
Sure we can segment this into code generation models and code review models but are engineers really going to want to be questioned by a code review tool on "what are you trying to do?" or are they just going to merge and pull the slot lever again?
my time coding with Claude has been the most joyful experience in my 25 years of coding.
I have delivered many pet projects I always wanted to build and now focus in the operation of them.
no moment in my coding life has been this productive and enlightening. pretty often I sit down to read how the ai solved the issue and learn new techniques and tools.
studying a paper, discussing it with Opus, back and forth, taking notes, make Opus check my notes. it improved a lot my studying sessions too.
I respect the different experiences each of us get from this. for fairness I share mine
It's nice that you have all those wonderful experiences with LLMs. But for once in your life, could you show us the code? Because you look like yet another cheerleader that have nothing to show, and it's annoying.
Sure. I'll show something. I'm working on an app to help teach myself french. I work at a busy startup so I only have a few hours to spare here and there, but I've managed to make an app that works very well for me, mainly because of the help I receive from Claude Code. I can't make the github repo public because it contains some copyright material [^1]. but maybe I'll make a censored version public if there's interest. It's at https://yap.town .
[^1]: to be clear, nothing in the frontend is copyrighted. I use some copyrighted works to figure out how common various words are, which I need because I wanted the app to teach the most common words first.
Edit: the site uses the FileSystemWritableFileStream API, so Safari/iOS users will need Safari 26.
You touch upon an interesting phenomenon that is quite pervasive throughout the world of software development, and possibly many other fields as well.
To avoid heated discussions, allow me to illustrate the concept with why enterprise software is mainly built with Java, whereas most blog posts are about writing backends with TypeScript, Python, or Rust. The reason for this is at least twofold:
1. Professional programmers don't get paid to write blog posts, and typically want to spend their free time doing other things. Hobbyists do have the time, but they typically do not see the added value of a boring language such as Java, because they don't work in teams.
2. When something is already known, it is boring for people to read about, and therefore less interesting to write about. When something is new, many people write about it, but it's hard to tell who is right and who is wrong.
Given that good writing, and the additional marketing to find the respective audience, take energy, it is not strange that we find weirdly biased opinions when reading blog posts and forums on the internet. I typically find it better to discuss matters with people I know and trust, or to experiment a bit by myself.
The same might happen now with reporting on AI assisted coding.
Edit: might as well just have said "visibility bias" and "novelty bias" if I had consulted an LLM before commenting.
As someone who has been using Java for enterprise software for over 25 years, but who likes to program his pet projects in Python, let me give you another reason:
3. Python has a very fast feedback loop. You type, run and see the result immediately. This is great for small projects and prototypes.
Java needs much more work, not just for the compiling but it also needs more boilerplate. This is fine for enterprise projects which typically are very large and prefer stability over speed of development. But at home I don't have the time or the patience for that.
I'm very into tight cadence and have a lot of options to choose from, doing most of my "pets" in Racket, Elixir, Picolisp and p5js, but I still sometimes generate a Maven project and start hacking in a unit test because libraries and performance are excellent and sometimes it requires less effort to brute a problem with imperative mutations.
Pharo is an alternative but documentation and libraries just aren't as good, and maybe never will be.
Here's an example, from a session from yesterday and today, buyer beware naturally I'm still testing and refining it: https://github.com/rdaum/tature
I'll now go through this, remove the excessive comments and flowery language, add more tests, put it through its paces. But it did me a service by getting the pieces in place to start.
This is the new "Source?" comment (which, funny enough, still works).
But I don't think the code matters as much as the intention. The comment is all about exploration and learning. If you treat your LLM like a Wikipedia dive, you will come out the other end with newfound knowledge. If you only want it to achieve a discrete goal, it may or may not do so, but you will have no way to know which.
I have had similar experiences to OP. All of these apps (mostly maths learning, but also the bus one) were coded using a mix of copilot and Gemini CLI:
https://rupertlinacre.com/
I'm probably capable of building all of them by hand, but with a 6yo I'd have never had the time. He loves the games, his mental arithmetic has come on amazingly now he does it 'for fun'.
Much of this built out of a frustration that most maths resources online are trying to sell you something, full of ads, or poor quality. Just a simple zoomable numberline is hard to find
In both these examples, I leaned on Claude to set up the boilerplate, the GUI, etc, which gave me more mental budget for playing with the challenging aspects of the problem. For example, the tabu graph layout is inspired by several papers, but I was able to iterate really quickly with claude on new ideas from my own creative imagination with the problem. A few of them actually turned out really well.
Sometimes I'll admit that I do treat Claude like a slot machine, just shooting for luck. But in the end that's more trouble than it's worth.
The most fruitful approach is to maintain a solid understanding of what's happening and guide it the whole way. Ask it to prove that it's doing what it says it's doing by writing tests and using debug statements. Channel it toward double checking its own work. Challenge it.
Another thing that worked really well the other day was to use Claude to rewrite some old JavaScript libraries I hand wrote a few years ago in rust. Those kinds of things aren't slot machine problems. Claude code nails that kind of thing consistently.
I took an existing MIT licensed prefix tree crate and had Claude+Gemini rewrite it to support immutable quickly comparable views. In about one day's work. I scoured the prefix tree libraries available in rust, as well as the various existing immutable collections libraries and found that nothing like this existed. This implementation has decently comprehensive tests and benchmarks.
I used vibe kanban like a slot machine and ended up with a messy MCP server that doesn't really do anything useful that I can tell. Mostly because I didn't have a clear vision when I went into it.
> I have delivered many pet projects I always wanted to build and now focus in the operation of them.
> pretty often I sit down to read how the ai solved the issue and learn new techniques and tools.
I have very similar experiences, but very often I wonder if I couldn't just have gone to an open source project on the same topic (e.g. building a toy parser) and read the source code there, instead of letting a code generator AI reproduce it for me. Because that happy feeling is very similar to early moments in my developer career, when I read through open source standard libraries and learned a lot from it.
I started using Claude AI, ChatGPT, and DeepSeek for helping me to develop Windows applications using Delphi Pascal a few months ago. I absolutely love it. I learned Pascal when I was 16 (high school) and throughout college. I have never been a professional programmer in my life. I'm getting old. I want to start getting back into programming. AI has helped me tremendously. AI has helped me to develop many special procedures and functions which I could not figure out by myself anymore. I am a Vice President at a company that sells computer networking equipment. Still need to keep my day job. By the way, Claude AI is the best so far when it comes to Pascal. ChatGPT is disappointing, maybe it's better in other programming languages. DeepSeek depends, it's average.
> 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.
That's why developers are poorly paid and viewed as disposable cogs. It feels "easy" to many people and so they internally think it is immoral to get paid and corporations ruthlessly prey on that feeling.
Reality is that development is hard and requires immense mental work, constant upskilling and is not something you can switch off after 5pm and think of something else. Your brain is constantly at work.
That work also is creating millions and billions that gets extracted from developers and flow to the greedy hands of the rich, who now control all the means of production (think of cloud services, regulation - try starting your own forum today, anything with user generated content etc.).
TIL someone thinks a £60k dev job in London means you’re not being exploited - because you can afford a Tesco meal deal and a flatshare in Zone 4. Never mind your code prints money for people you’ll never meet, or that your “reward” is a Jira ticket and a perf review.
Developers went from garage-tinkerers to the backbone of the modern economy - and somehow ended up as overworked, disposable employees in open-plan office farms. The owners changed, the IDEs got fancier, but the deal stayed the same: build the machine, never own it.
You upskill constantly just to not fall behind. You work nights “for the launch.” You get gaslit into thinking stock options in a private company are equity. Then you’re laid off via email - while the founders post yacht selfies.
And the worst part? Most of you still believe you’re lucky. That’s the grift: teach engineers to think they’re “not like other workers” - then extract surplus value just like any other industry has done since the 19th century.
Developers are poorly paid - not because the salary is low, but because the upside is stolen. You created the wealth, they captured it.
The tool is insanely powerful, but Anthropic needs to build a more interactive structure into the tool. Just "accept this diff or not" is not ideal.
If you prompt it correctly and rigidly, and review everything it does large or small, it's a 10x tool for grinding through some very hard problems very quickly.
But it can very easily lead you into overconfidence and bloat. And it can "cheat" without you even realizing it.
Claude Code is best used as an augmentation, not automation tool. And it's best that the tool makers and investors realize that and stop pretending they're going to replace programmers with things like this.
They only work well when combined with a skilled programmer who can properly direct and sift through the results. What they do allow is the ability to focus on higher level thinking and problems and let the tool help you get there.
I completely agree when using synchronous tools like Windsurf and Cursor. This is why I much prefer the async workflow most of the time. Here you get a chance to think about how the AI should be constrained in order to have the highest probability of a "one shot" PR or at least something that would only require a few edits. I spend a lot of time on the AGENTS.md file and as well as thinking a lot about the prompt that I am going to use. I sometime converse with ChatGPT a little on the prompt as the feedback loop is very fast. Then, just send it and wait ~5 minutes for completion.
I still use synchronous tools sometime for UI and other things were it is hard to specify up front and iteration is required. But realistically, I use async 50:1 over sync.
Lovable, I feel, works at a higher abstraction layer. The unpredictability of whether my prompt will generate something delightful in that initial design creates an addictive slot machine dynamic. But would these tools lose their magic if the results became completely deterministic?
Companies will rationally stop paying for slot machines that pay out $0.90 for every $1 wagered, but they’ll happily pay for slot machines that pay out $5 for every $1 wagered.
Which will be the case is the interesting question.
At this point I am doubtful about calling companies rational actors in many many cases. So probably they play both machines. And it is somewhat luck which they hit and some maybe have rational leaders.
> But would these tools lose their magic if the results became completely deterministic?
No. They would become extremely useful and more magical. Because instead of weird incantations and shamanic rituals of "just one more .rules file, bro, I swear" you could create useful reproducible working tools.
Except an LLM is not and never will be deterministic, by its very design that is not how it operates. It would need to be a fundamentally different tech from the ground up.
Am I the only one who doesn't find CC makes me faster? I mean, it could, if I let it, but that means not reading or understanding what it's writing. Basically I just don't really believe anyone is writing software of the same quality in less time. But I can totally see how you can write software of lower quality in a fraction of the time.
The interesting thing is going to be how this all holds up in a year or five. I suspect it's going to be a lot of rewriting the same old shit with LLMs again and again because the software they've already made is unmaintainable.
I didn't get into software to labour like a factory worker day in, day out. I like to solve problems and see them deliver value over years and even decades, like an engineer.
> AI coding tools supercharge this, allowing you to bring whole machineries to life by waving your hands around, offloading the understanding for much longer
I guess you could use them like that, but you'll do much better if you try to get an understanding of the problem beforehand. This way you can divide the problem into subtasks with reasonably clear description, that Claude will be able to handle without getting lost and without needing too many corrections.
Also, you'll still need to understand pretty much every task that Claude has implemented. It frequently makes mistakes or does things in a suboptimal way.
When you use AI properly it's a great tool, it's like an IDE on steroids. But it won't take away the need to use your brains.
Love it or hate it, at the very least you can grant it this: Claude Code can mitigate some of the cost of Yak Shaving [1]. You need this digression/distraction feature, even though it's not the main attraction. Testing/infrastructure etc -- whatever it is, let's just have the automaton do the tedium.
Actually the model I like to use is a Pacinko machine. Where you can visualize all of the options that are available, while internal cursor just randomly bounces from pin to pin.
You definitely need to be careful of the addition mechanics of CC, but is it still a slot machine if there are loads of steps you can take to improve your odds of success? For instance, only allowing it to code within a feedback loop of some kind. I find the author's premise that the skill here is just "knowing which model to use" way too reductive. Seems like an entirely different beast to gambling, where the odds are fixed by the house.
Yes, the gamification is why some people like it. It is another addiction. Most proponents and bloggers are tied to "AI" money though, directly or indirectly.
I've seen little organic praise from high profile programmers. There aren't many, and once you search they all at least work on a commercial "AI" application.
Simon Willison[1] of Django Framework founder[2] fame is a pretty big AI programming proponent at his blog. He's pretty high profile, as far as real-world programmers (as in, not executives and not promoters) go.
You could argue, he makes money off of AI with his newsletter and whatnot, so he does stand to gain something, but it's a lot less than the executives and investors who've filled the news.
> AI coding tools supercharge this, allowing you to bring whole machineries to life by waving your hands around, offloading the understanding for much longer, but if you want it all to actually work, you'll need to dive into the details eventually.
The answer to this is nuanced. You can summon ~30k LoC codebases using CC without much fanfare. Will it work? Maybe, in some of the ways you were thinking -- it will be a simulacrum of the thing you had in your mind.
If something is not working, you need to know the precise language to direct CC (and _if you know this language_, you can use CC like a chisel). If you don't know this language, you're stuck -- but you'd also be stuck if you were writing the thing _by hand_.
In contrast to _writing the thing by hand_, you can ask CC to explain what's going on. What systems are involved here, is there a single source of truth, explain the pipeline to me ...
It's not black and white in the way I experienced this paragraph. The "details" you need to know vary across a broad spectrum, and excellent wizards can navigate throughout the spectrum, and know the meta-strategies to use CC (or whatever agentic system) to unstick themselves in the parts of the spectrum they don't know.
(lots of that latter skill set correlate with being a good programmer in the first place)
Many of my colleagues who haven't used CC as much seem to get stuck in a "one track" frame of mind about what it can and cannot do -- without realizing that they don't know the meta-strategies ... or that they're describing just one particular workflow. It's a programmable programming tool, don't put it into a box.
I read this entire post before realizing you weren't referring to `cc`, the C compiler. It actually kinda works with this interpretation, particularly the "if you know this language" part.
I'm a 72 year old dev. Ai and Claude specifically are great because I can't focus on code like I used to. Ai has extended my viability for a few years.
I compared vibe coding to gambling in one of my recent blog posts and thought that metaphor was slightly uncharitable, but I didn't expect "slot machine" to actually now be the term of art.
In other words: code assistants are going to wipe out software engineering (and adjacent roles) as a lucrative career path for generations to come...but not before our generation retires and "gets ours."
Claude works best for context based pattern matching. I specifically use claude for tasks which are simply replicating the logic with minor contextual differences. I can’t even imagine Claude writing whole features by itself.
One unpopular opinion I hold is that in recent times programming became a lot more about integrating libraries and frameworks vs writing your own thing. This was fine because if someone open sourced it, why repeat the same work. That ended up in cases where a lot of work was modifying the libraries to your use case.
With vibe coding, I suspect this is a group that has adapted to it really well (alongside hobby coders and non coders). The thrill comes from problem solving, and when you can try out the solution quickly and validate, it is just addictive. The other side is how open source frameworks have increased, and there are a lot of oss libraries for just about everything. (A personal experience is implementing Cmd bar (like linear) in react when i was just learning. It took me a week or so, and then i just inserted an oss thing for comparison. It was super smooth, but i did not know the assumptions. In production, i will prefer that, and dont always have time to learn and implement from scratch). We see this with langchain etc in LLMs too, and other agentic frameworks as well. The shift is not towards less code but getting the thing to work faster. Claude code accelerates that exponentially as well.
Unpopular opinion would be that if the project is not much more than a bunch of libraries/tools/techs integrated together than the need for its existence is questionable. Diversity there breaks "one way of doing things" and makes it harder to learn actual tech that makes it work.
i meant in a way that programming is always synthesis. (to my brain) combining stuff from multiple places is good, but not great synthesis you can do on your own. Many developer feel there is not much of a difference between the two. No comment on whether there is a need for the existence.
One of the reasons a lot of things look like gambling is that a lot of things look like gambling. Hunting, gathering, and other baseline pre-civilization survival activities look like gambling. Dating looks like gambling. Reproduction even looks like gambling with each offspring, as a product of genetic recombination, being a dice roll. Investing, of course, looks like gambling.
It's why we get so addicted to gambling. We're built for it because a lot of legitimate real things look like gambling.
Anyone else kind of lose the high of solving a difficult problem since LLMs became the workflow?
You still have to really guide the AI, none of this is automatic. Yet I no longer feel the mega joys I once felt hand building something and watching it work correctly. The thrill is gone! Don't know if this is good or bad yet. I don't miss the plumbing bullshit. I do miss the joy.
This is a common argument against AI generation and I dislike it because people derive their joy from different things. Some engineers get their joy from the process of creation, others get their joy from the final result. Neither way is inherently better or more morally correct than the other.
I have just fought 4 days with Claude 4 Sonnet because it generates too much garbage for my usage, and I am considering stopping the AI usage altogether. No matter what system prompt, rules et. all you give, they don't want to do as I said, but instead do something which compiles (Rust) but is not performant or is extremely verbose and includes all kinds of unnecessary things. They have too much assumptions that some function is used/not used in async context, or it is okay to clone, or whatever. Is the Opus really that big leap?
The degree of after-the-fact ad hoc justifications for using these tools makes my brain hurt. "I'm in meetings all day anyway" …wtf?! So yay for the machines taking over our skillsets and hard-earned craft so we can attend more meetings*? Sure sounds like a hellscape to me!
* How 'bout I deploy my "digital twin" to attend the meetings for me. That'll show 'em!
It is just another tool. Novel and powerful, but a tool nonetheless.
You cannot write everything using LLMs, you cannot maintain hodgepodge LLM codebases, but also you might want a break from writing scaffolding code or simple functions.
in the sense that if I have to change the shape of a complex static object or do anything tedious, it can just do it. What exactly would you say I have to learn from tasks like that?
There’s a reason intermittent rewards are so intoxicating to naturally evolved brains: exploiting systems that give intermittent rewards is a great resource acquisition strategy.
> 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!
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.
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.
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.
"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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
> 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
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.
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.
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.
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.
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.
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 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.
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.
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.
It can happen if you develop health issues like carpal tunnel or Sciatica due to extended sitting. Programming then gets mentally associated with pain.
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.
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.
no one uses ai to one shot system design because they cant. it will fuck up in any moderate sized project
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.
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.
I think you might have to get more granular than:
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.
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.
That's what I mean by product-building vs programming (3rd group).
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.
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 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 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 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.
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.
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'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 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.
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 :)
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.
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 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 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 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 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 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 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...
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'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.
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.
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!)
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 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.
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.
Not development related but I have plenty of colleagues that take pleasure in the mundane. Small easy dopamine hits I guess.
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.
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.
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:
> YesMission Success, 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?
For me the fun part of coding is having visions of products or systems I'd like to exist, and writing code only as a means to an end.
Claude Code (AI coding agents/assistants) are perhaps the best thing to happen to my programming career. Up until this point, the constraint going from vision to reality has always been the tedious process of typing out code and unit tests or spending time tweaking the structure/algorithm of some unimportant subset of the system. At a high level, it's the mental labor of making thousands of small (but necessary) decisions.
Now, I work alongside Claude to fast track the manifestation of my vision. It completely automates away the small exhaustive decision making (what should I name this variable, where should I put this function, I can refactor this function in a better way, etc). Further, sometimes it comes up with ideas that are even better than what I had in my head initially, resulting in a higher quality output than I could have achieved on my own. It has an amazing breadth of knowledge about programming, it is always available, and it never gives up.
With AI in general, I have questions around the social implications of such a system. But, without a doubt, it's delivering extreme value to the world of software, and will only continue the acceleration of demand for new software.
The cost of software will also go down, even though net more opportunities will be uncovered. I'm excited to see software revolutionize the under represented fields, such as schools, trades, government, finance, etc. We don't need another delivery app, despite how lucrative they can be.
I see AI-accelerated codegen as doing all of the boring shit I hated:
do while error == true;
Write code
Run code
Read error
Attempt to fix error
Run code
Read error
Search Google for error
Attempt to fix error
Run code
Read error
done
---
Claude does all of this for me now, allowing me to concentrate on the end goal, not the minutiae. It hasn't at all changed my workflow; it just does all of the horribly mundane parts of it for me.
I like it and I recommend it to those who are willing to admit that their jobs aren't all sunshine and roses until the product is shipped and we can sit back and get to work on the next nightmare.
If you enjoy being a custodian no one is going to chastise you for that. As you have stated there are many nightmares to clean up and all teams need a person who wants to do the clean up.
This will keep you out of the bleeding edge feature/product space because you lack a honed skill in actually developing the app. Your skill is now to talk to an LLM and fix nightmare code, not work on new stuff that needs expertise.
Just food for thought.
I think writing code was never slow. Or atleast never the slowest part of the overall process.
Vibe coding might be fast, but thats only if you wish to pretend that coders deploy to production directly within minutes of writing code without product discussions, automated builds, CI/CD, code review, production testing, UAT, regression testing, security testing etc.
In reality when you factor in all these things, which are absolutely necessary if you don't want you product to break every new release and lose users permanently. You have to do the same drills as you always did.
To that end, unless you are building something very large, coding velocity is largely irrelevant.
I would also argue that the OPs comment describes “hacking” not “writing code”.
They could escape that loop by employing software development skillsets, for example TDD or perhaps using the debugger instead of pounding away at a compiler.
Usually when people pound at a compiler it’s because they don’t know what they’re doing or how software even works.
And by handing over all the small decisions and things like writing unit tests, you are opting in to mediocre code quality (or worse) and you no longer get the full experience of using your code, for example when writing unit tests yourself. Or when in other cases where you call your own procedures from your own code. When writing a test becomes difficult it is often (not always) an indication of bad code quality. It will also lead to you being less familiar with the code in general.
It may be, that all of those are OK in your scenario or use case.
It's like the Blank Page Problem for writers. It's really hard to start.
But if you have a shitty page of text, you can edit it to make it better.
With LLM tools I can get from idea to (shitty) proof-of-concept solution really fast. Then I can start dogfooding it and improve and rewrite.
But sometimes the shitty solution is enough for my purposes. It works and doesn't actively break shit. My problem was solved and I don't need to optimise the silly TUI yt-dlp wrapper it just made me.
For me the problem with the vision is that stuff I’d like to exist is so far above the capabilities of AI (rather complex games) that I don’t even want to try it. And for stuff that I build and use they are pointless because they don’t accelerate me much.
I found it great to write bash scripts, automation, ffmpeg command lines, OCR, refactoring… it’s a great autocomplete.
Working in a large team I realized that even relying too much of other people’s work is making me understand the technology less and I need to catch up.
Even if you're working on a large complex system like that, I believe coding agents are still useful at at least taking highly specific prompts/instructions you write and doing the writing for you. Then doing other tedious tangential work like generating unit tests over a pure function, adding comments, generating documentation, etc that all increase the quality of the codebase without requiring toil on your part.
With especially novel or complex projects, you'd probably not expect to use the agent to do much of the scaffolding or architecting, and more of the tedium.
> the fun part of coding is having visions of products or systems I'd like to exist, and writing code only as a means to an end.
Perhaps you mean "the fun part of building computer systems", because it sounds like you don't enjoy writing code.
It’s still cans of snakes all the way down though when it comes debugging time.
> and it never gives up.
Not to impede your overall point, but have you not encountered a situation where Claude gives up? I definitely have, it'll say something like "Given X, Y and Z, your options are [a bunch of things that do not literally but might as well amount to 'go outside and touch grass']."
I've been experimenting lately with just interfacing with Claude Code through the GitHub action and issues.
I sit on the beach and talk to it through the GitHub iOS app. I set the timeout to 4 hours and let it just work. It comes back to me later with something and I take a look. By the time I get home, I might tweak a few things here or there manually (particularly if it's about aesthetics), and merge.
I agree and do experience that. Perhaps to clarify, I mean that it (unlike humans), is always down to code alongside you. It will never complain, get sick, have a life event. etc.
It can (and does) "get sick" in the sense that anthropic services go down, anthropic rate limits, gets overloaded, etc.
I didn't become a software developer so I could write the same SQL queries, the same plumbing code, the same boilerplate beginnings of programs, the same repetitive error handling, the same string formatting, the same report generation, the same HTML templating, and the same thread cancellation logic. I also didn't become a programmer so I could gratify myself by yak-shaving elegant helpers for those SQL queries, plumbing, boilerplates, error handlers, formatting, reports, templates, and cancellations.
Bloggers have been kidding themselves for decades about how invigorating programming is, how intellectually demanding it is, how high the IQ demands are, like they're Max von Sydow playing chess with Death on the beach every time they write another fucking unit test. Guess what: a lot of the work programmers do, maybe even most of it, is rote. It should be automated. Doing it all by hand is part of why software is so unreliable.
You have a limited amount of electrical charge in your brain for doing interesting work every day. If you spend it on the rote stuff, you're not going to have it to do actually interesting algorithmic work.
I worked on visual studio at Microsoft 20 years ago, and once had the opportunity to go to a trade show to represent the company.
While I was manning a booth, this software developer came up to me and said VS had gotten too good at code generation to automate data access, and we should cut it out because that was the vast majority of what he did. I thought he was joking, but no, he was totally serious.
I said something to him about how those tools were saving him from having to do boring, repetitive work so that he could focus on higher value, more interesting development, instead, but he wasn’t having it.
I think about him quite often, especially these days. I wonder if he’s still programming, and what he thinks about LLMs
I think I partially agree, your first paragraph is exactly how I feel. Boilerplate and trivial stuff absolutely should be automated. It's also true that people have been pushing a narrative where programming is some dark art and you should use Methodology X or Theory Y. Bro, chill, you're writing a website.
On the other hand software development in the high sense, i.e. producing solutions for actual problems that real people have, is certainly intellectually demanding and also something that allows for several standard deviations in skill level. It's fashionable to claim we all have bullshit jobs, but I don't think that's a fair description at all.
> "producing solutions for actual problems that real people have, is certainly intellectually demanding and also something that allows for several standard deviations in skill level"
Absolutely agreed, but I think the idea is that coding tools (or languages, or libraries, or frameworks) frees us to do the actually hard, skill-intensive bits of this, because the thing that's intellectually demanding isn't marshaling and unmarshaling JSON.
This is exactly why we moved from Assembly code to higher level languages and then to using frameworks.
Nobody is paying you to make a CRUD web app in Assembly, they're paying you to solve a problem.
You're not getting any extra points for using plain vi(m) with no autocomplete to write a Java application. Making stuff the hard way is just stupid performative crap.
LLMs are just the next iteration of autocomplete -> intellisense -> language servers.
Now instead of autocompleting a method or property, they can autocomplete full unit tests and functions by looking at the patterns across the codebase.
+1, and also to add: this isn't even a new phenomenon. My hot take is that AI coding is only the latest in a trend that has been running in the industry for literally decades. The technology itself might be novel but what it's doing is very, very old!
You used to have to write tons of real code to stand up something as simple as a backend endpoint. Now a lot of this stuff is literally declarative config files.
Ditto frontends. You used to have to imperative manage all kinds of weird bullshit, but over the last decade we've gradually moved to... declarative, reactive patterns that let the some underlying framework handle the busywork.
We also created... declarative config files to ensure consistent deploys every time. You know, instead of ssh'ing into production machines to install stuff.
We used to handle null pointers, too, and tore our hair out because a single missed check caused your whole process to go poof. Now... it's built into the language and it is physically impossible to pull of a null pointer dereference. Awesome!
We've been "putting ourselves out of work" for going on decades now, getting rid of more boilerplate, more repetitive and error-prone logic, etc etc. We did it with programming languages, libraries, and frameworks. All in the service of focusing on the bits we actually care about and that matter to us.
This is only the latest in a long line of things software engineers did to put themselves out of work. The method of doing it is very new, the ends are not. And like every other thing that came before it, I highly doubt this one will actually succeed in putting us out of work.
Me neither, that's why I write higher level abstractions or use libraries and languages other people have written. I don't get how you were writing so much boring stuff manually before LLMs. What do you do?
I'm not the OP, but from what he said I can tell you two things:
1. He is using computers to solve other peoples problems, and they are similar problems so all the code looks the same, and
2. He is NOT using computers to solve his own problems. Every top notch software engineer I've met does not write the same code more than a few times, because doing repetitive stuff is something a computer should be doing.
What a weird set of claims to make. I like how you worked backwards from "couldn't be a top not software engineer", whatever that means.
It’s the standard response anytime someone claims they get productivity boosts from ai. Either you are inexperienced or bad at your job.
On a board that would deride any other no true Scotsman take, this one happens on every ai discussion.
It’s no longer worth engaging with. I’m now just posting basic statements like “I’ve been programming professionally for 25 years and I find ai to be extremely helpful”. That way there is at least someone claiming the opposite. But you aren’t going to convince anyone as they already shut that door with their statements.
For what is worth, it had nothing to do with whether he uses AI. I'm north of 60yo, started on punched cards and paper tape and have been programming ever since. My experience suggests if you aren't keeping up by using AI now there is a good chance you won't be a relevant software engineer in a decades time.
The bit that triggered my response is this:
> Guess what: a lot of the work programmers do, maybe even most of it, is rote.
Yes, I know a lot of programmers who do that. In fact it seems most programmers I see in the industry do that. Many of them are very good at it, in the sense that a good brick layer will be content to devote his lifetime to laying bricks in a straight line and will be far more reliable and conscientious at it than I could every be. However, that personality type is unlikely to become a top engineer or architect. To be good at those jobs you need to get bored in a couple of years at most. You have to be internally driven to try new things, and experiment with new ideas.
When such a person is confronted with the prospect of a lifetime of churning out code that almost follows a template (and I daresay could easily be produced by today's LLM's) he doesn't sit still and do it. He finds something more interesting to do. Since he's a computer programmer and the task is well suited a computer doing it, he probably take up a skunk works project of churning out the repetitive parts of that code, so he didn't have to do it. It's far more fun, saves time in the long run, and if he is a good software engineer in the long run the systems it produces will be more reliable, and use less code than something programmer code have produced by churning out the same stuff every day for years.
Going by the OP's comment, he hasn't done that, despite apparently being bored shitless with what he does do. There is a solution, but it isn't the LLM's he suggests. All using LLM's change is the language are giving to the "compiler". The end result is still him creating the same CRUD app using the same platforms, libraries and tools his is using now.
There are lots and lots of us who have gone down the road of generalizing code and have decided the outcomes, for the business that pays for the software, are worse. Frequently it devolves into code that is hard to reason about, architecture that is overblown for purpose or that does something just about, but not exactly, what you want it to do.
But more importantly, by dismissing the comment that way, you’ve made an implicit claim. You are claiming to be able to judge a persons capability or the challenges they are working on off of a couple hn comments. Thats bad engineering and anti-social behavior.
Imagine telling someone that learning to touch type was the sign of a bad software engineer because you don’t type that much because your libraries are all named with single letters. Thats what these arguments sound like to me.
> But more importantly, by dismissing the comment that way, you’ve made an implicit claim. You are claiming to be able to judge a persons capability or the challenges they are working on off of a couple hn comments. Thats bad engineering and anti-social behavior.
Somewhat true. But it did make me smile, because it reads very much like the pot telling kettle he's black.
But only somewhat. @tptacek also said this:
> Bloggers have been kidding themselves for decades about how invigorating programming is, how intellectually demanding it is, how high the IQ demands are, like they're Max von Sydow playing chess with Death on the beach every time they write another fucking unit test. Guess what: a lot of the work programmers do, maybe even most of it, is rote. It should be automated. Doing it all by hand is part of why software is so unreliable.
Seriously?
As I said, I've been programmer for decades now. He's coming from the perspective that the code dribbling off my fingertips without too much thought is "programming". It is, of course, in the same sense that the brush strokes of Van Gogh are what constitutes "painting". But the painting created by Van Gogh consisted of thousands if not millions brush strokes, all placed with precision, purpose and a great deal of thought. If placing the loaded brush on canvas is all there was to painting, all our houses would be adorned with Van Gogh's. He says we should all be using LLM's, but the idea that brush strokes placed by an LLM would produce same outcome is laughable. You might well use a painting LLM to paint 1000's of houses, but never a single Van Gogh.
To the people who delight in creating new and unique computer systems from code, the puzzle to be solved is arranging the code in just the right way to create their personal Van Gogh's. An immutable object here, a touch of recursion there, combined with an atomic compare and swap and in some truly heroic cases an FPGA thrown into the mix to get some extreme parallelism - crafting these in just the right mix is the challenge of programming. Overcoming that challenge is what makes it invigorating. Not writing the "fucking unit tests" as tptacek puts it, which is almost universally disliked. Although now I look back on it, it is almost therapeutic - it's like going for a jog; it's downtime, when you get review what you've done, and ponder your next moves while pounding the keyboard.
It's a shame, and somewhat insulting to see tptacek treat these efforts many find enjoyable with so much derision. But I've spared with tptacek here, when said similar things before. Again, he confidently said something completely wrong headed, and I could not let it go. Some things don't change I guess. As a fellow at a Linux meetup said to me a long time ago, "you wrote all those words because someone was wrong on the internet???".
I've been shipping software since we had to write it in C, send it out to be burned onto CDs, put in boxes, and put on shelves.
I agree; I think there's a huge veil of perception thing happening here like. I've worked directly with dozens of coders and indirectly with hundreds, and like, no one does their job like I do? It's like we all show up to the job site, you have a drill, another person has a hammer, and I have a feather duster and a bottle of glue, and we all have the exact same job. No wonder what makes the drill person more productive doesn't do shit for the feather duster/glue person.
I massively agree. Huge amounts of coding isn’t wild new inventions, it’s not unknowable work like so many seem to suggest when asked to estimate time. Frankly it’s not even conceptually hard, it’s just that computers are fast and accurate and dumb so you need to be annoyingly precise. Imagine if a human refuses to read a manual because a comma should have been a semicolon. Plenty of people are smart enough to do it, but lack either the knowledge about this or the desire to deal with it.
Most of this work should go away. Much of the rest of it should be achievable by the domain experts themselves at a fraction of the cost.
If you made all this work go away with a new functional programming language, like if finally someone contrived the perfect type system where you could just declaratively lay out all the rote bits and evaluate them to the imperative steps you wanted taken, everyone would be thrilled. There would be people going around dunking on all the developers who didn't use that language.
Instead, it's the opposite.
But that’s the problem.
The LLMs are still generating all that rote shit, that at some point must be maintained and read and understood. Potentially at a higher rate than any human could.
A lot of what AI coders are being praised for could be accomplished just as well with some good Lisp macros with much less technical debt.
I understand what you're saying. But in the programming environments I work in, the rote stuff that LLMs are automating is marginally better than the rote stuff I would write given the same parameters. Obviously, we could all do better if only we were writing the right Lisp macros. ;)
Programming is about not doing all of these things. You have a powerful machine that is quite good at doing those things. You just have to notice those patterns and then build the tool that will be doing those kind of works. And the most simple one is a snippet generator and editors macros. Then you have project generators, and code reuse thingies from the programming language.
I agree with this take, insofar as I interpret it as "we do a lot of bullshit that doesn't matter". Like, do you remember people arguing Rails vs Django, or even worse Rails vs Sinatra? I do and did, and my meager defense is that I was young and naive. The list of "I can't believe we spent any time building/doing any of that" is just so, so long. I mean, how many times are we gonna reimplement node ffs.
I always thought programming as being a touch more like two imbecile brothers outsmarting Max Von Sydow's plan to control the world with tainted beer and hockey arena organs.
Holy shit, I completely forget he was in that. What a get.
And now you spend the same time verifying/reviewing AI output?
If before I did a thing in 60 minutes and now Claude Code does it in 5 minutes I will not spend 55 minutes reviewing that code.
I will maybe spend 5-10 minutes reviewing and refining the code with the help of Claude Code and then the rest of the time I will go for another feature/bugfix.
Worth adding that sometimes I will spend an ~equivalent amount of time doing something in Claude Code, but the result is better.
Case in point recently I was working on a mobile app where I had to check for a whole litany of user permissions and present UI to the user if any particular permission was missing, including instructions on how to rectify it.
Super annoying to do manually, but Claude Code was not only able to exhaustively enumerate all possible combos of missing permissions, but also automatically create the UIs for each edge case. I reviewed all of it for accuracy, which took some time.
I probably would've missed some of the more obscure edge cases on my own.
Overall maybe not much faster than doing it myself, but I'm pretty sure the results were substantially better.
I spend a fraction of the time verifying LLM production of rote code --- which I do in fact do, I'm not a vibe coder --- than I would writing it. I don't understand why people always expect this to be a mic drop rebuttal.
Do you feel like you end up with as clear of a mental model reviewing it as you do if you wrote it?
I'm still trying to figure out the answer to that question for myself. Maybe the answer is, "Probably not, and it probably doesn't matter" but I'm still trying to figure out what kind of downstream effects that may have later on my judgment.
Yes, of course I do. It's rote stuff. To the balance of time we're accruing to me dealing with generated code, add "stripping off all the comments", "fixing variable names to be like I like them", etc. My fingerprints are still all over everything. And it's still radically faster than doing this all by hand.
Mental expenditure on programming is also not linear through a task; it takes much more energy to get started than to do the back half. Ever stared at an empty function for a minute trying to come up with the right variable name, or choosing which value to compute first? LLMs are geniuses at just getting things started.
My job pays well and I create real stuff but most of the work is honestly just slop. So maybe I should use AI to save myself the effort..I could salvage more free time for myself that way..
On Friday I was converting a constrained solver from python to another language, and ran into some difficulty with subsituting an optimzer that's a few lines of easily written Scipy; but barely being supported in another language. One AI tool found this out and fully re-implemented the solver using a custom linear algebra library it wrote from scratch. But another AI tool was really struggling with getting the right syntax to be compatible with the common existing optimization libaries, and I felt like I was repeatedly putting queries (read: $) into the software equivalent of a slot machine that was constantly apologizing for not giving a testable answer while eating tens of dollars in direct costs waiting for the "jackpot" of working code.
The feedback loop of "maybe the next time it'll be right" turned into a few hundred queries resulting in finding the LLM's attempts were a ~20 node cycle of things it tried and didn't work, and now you're out a couple dollars and hours of engineering time.
> One AI tool found this out and fully re-implemented the solver using a custom linear algebra library it wrote from scratch.
So slow, untested, and likely buggy, especially as the inputs become less well-conditioned?
If this was a jr dev writing code I’d ask why they didn’t use <insert language-relevant LAPACK equivalent>.
Neither llm outcome seems very ideal to me, tbh.
With mathematical things you can always write comprehensive and complete unit tests to check the AIs work.
TDD (and exhaustive unit tests in general) are a good idea with LLMs anyway. Just either tell it not to touch test, or in Claude's case you can use Hooks to _actually_ prevent it from editing any test file.
Then shove it at the problem and it'll iterate a solution until the tests pass. It's like the Excel formula solver, but for code :D
You could, and hope that you understand the problem domain and numerical analysis enough to hit all the hard cases. And then you’d have expanded your codebase with lots of tests that are relevant to a linear algebra library and not to what you’re trying to do.
Or you could use existing linear algebra libraries which are highly optimized, highly tested, and have a well-understood api that’s easier to review.
And then get back to the legit hard stuff, like maybe worrying if your linear solver needs preconditioning and how to best to that. Or any of the many numerical problems people tend to face when doing this kind of work.
I’m not sure why you’d give the llm a pass on reinventing the wheel here when you definitely wouldn’t with any other dev.
I think we all understand this we just don't think it works.
I'm curious why you think it doesn't work, when there are plenty of people saying it does.
There are limitations at the moment, and I don't see many people disputing that, but it must be doing something right, and its abilities are improving every day. It's learning.
Sometimes I get the feeling a lot of antis painted themselves into a corner early on, and will die on this hill despite constant improvements in the technology.
I have seen similar things many times in my career. There was a time when everyone were very skeptical of high level languages, writing everything in assembler come hell or high water, for example.
At some point it is going to single shot an entire OS or refactor a multi-million line codebase. Will that be enough to convince you?
From my perspective I like to be prepared, so I'm doing what I have always done.. understand and gain experience with these new tools. I much prefer that than missing the boat.
And, it's quite fun and better than you might imagine as long as you put a bit of effort in.
> From my perspective I like to be prepared
The same you that thinks has proved P = NP with ChatGPT?
A very relatable experience. But not all that different from how humans work when in unfamiliar domains.
I'd rather work with a human. Even with our flaws, it's still better than constantly being lied to by a tin can. If a junior kept delivering broken results as much as the "AI" does, they wouldn't be on my team that long.
Except... Completely different
I think much like how we're still figuring out how to use and manage social media to minimize the downsides and maximize its utility, we're gonna have to do the same with AI. I find it incredibly powerful for certain things and incredibly frustrating for others. Begging the AI to one shot some project feels like the wrong way to use it, it's better as a scalpel. Or as a learning device, or a more advanced rubber ducky.
IMHO the root of the issue is that "AI" is being anthropomorphised, or oversold as actually "intelligent".
If there's anything I've learned about software, "intelligent" usually means "we've thrown a lot of intelligent people at the problem, and made the solution even more complicated".
Machine learning is not software, but probably should be approached as such. It's a program that takes some input and transforms it into some output. But I suppose if society really cared about physical or mental health, we wouldn't have had cigarettes or slot machines.
A helpful, and snarky, critique of the majestic rhetoric around “cloud computing” was to mentally replace “cloud” with “someone else’s computer”.
When thinking through a claim of what AI can do, you can do the same. “AI” -> “just some guy”. If that doesn’t feel fair, try “AI” -> “some well-read, eager-to-please intern”.
Was all that snark, the cloud to ass" string replacement firefox extension; was it actually helpful? We're still trying to sell the masses (and ourselves) on the benefits of self-hosting, and the cost of cloud hosting vs on-prem has never really been answered. Don't get me wrong, a trawl through my comments here will find I don't always manage to hold my tongue when I'm feeling snarky, so I very much understand the desire, but at the end of the day, what has that actually helped? My friends who were Unix and Linux sysadmins who didn't manage to upskill are still out of a job when their employers moved the servers they were babysitting into the cloud, and my data is still swimming around somewhere in Facebook and Google's data centers.
Sure let's call the AI names, behind its back and to its face if we're feeling particularly bold, but is that actually going to amount to anything?
> we're still figuring out how to use and manage social media to minimize the downsides and maximize its utility
Considering the state of today's social media landscape and people's relationship to it, this fills me with dread.
I think we're starting to have a conversation about what healthy social media usage looks like and its place in life. Maybe it's just my algorithm but I see a lot of content about moderation and a shift back towards being genuine. I fully understand the irony here btw.
Hopefully it doesn't take 2 decades of AI usage to have that conversation tho.
> Maybe it's just my algorithm but I see a lot of content about moderation
I'm not sure if this is supposed to be ironic but it gave me a good chuckle nonetheless.
There's also a lot of talk about drinking more moderately down at my local bar.
To be fair, those seem like natural places to have these conversations.
Fwiw I'm seeing a lot of people on social media talking about drinking less too. So I had to unfollow them.
I never allow ai to write code, certainly not unsupervised. I like to write some code and then have claude check my work. Not just for bugs, but for architecture and style as well.
I let it write boilerplate, or other low impact stuff like html/css. It worked nicely converting Svelte components from Svelte 4 to 5 for example. And AI autocomplete has been a genuine productivity win although not without the occasional subtle bug. But I can't imagine trusting it for an entire codebase. If you're letting the AI write your code you're not thinking about it deeply enough to critique it imo. Which is fine for CSS or whatever but not most code.
It's such a great tool for learning, double checking your work, figuring out syntax or console commands, writing one-off bash scripts etc.
I stopped using copilot because it kept writing really bad c++. It's great at python and Javascript. This was a year or so ago so maybe its better now
I used it to learn C++ but that was for basic stuff. Even I could tell when it started to go off the rails.
I wonder if some of the disconnect between the AI coding fans and skeptics is just the language they're writing.
Nope, I write Javascript every day and none of the AI coding assistants is really that good. It churns out more crap than gold.
But muh cashing in on the tulip mania.
Can we collectively stop upvoting low quality 300 words random opinions about llm based dev? As a professional in the field I find the qualify of what's posted on HN really super low in this area, compared to posts eg related to cloud infrastructure or software engineering. There are better posts and sources than that.
People don't upvote low quality 300 words random opinions. People upvote funny and catchy headlines.
If you're asking whether we can collectively stop upvoting such headlines, the answer is probably no.
The post may not have a ton of meat, but it resonates and seems ripe for discussion. It’s quite timely as we all try to figure out how and when to use these tools.
Your comment doesn’t add much. Where’s the substance to your critique?
For instance this one is a great, valuable read about AI and developers productivity: https://news.ycombinator.com/item?id=44526912 Post that are just opinions doesn't really fuel discussions as they don't bring enough raw material to build on. Some opinions are still worthy because they are original, but here I see nothing new.
There are several topics like this on the front page every day, since many months back now, and the comments are all the same. It’s enough.
I have been programming since 1978 and thoroughly enjoy it.
Nothing more satisfying to me than thinking about nifty algorithms, how to wring out every last drop of performance from a system, or more recently train AI models or build agentic systems. From object models to back end, graphics to communications protocols, I love it all.
But that said, I am getting on a bit now and don't particularly enjoy all the typing. When AI rolled around back in 2022 I threw myself into seeing how far I could push it. Copy pasting code back and forth between the chat window and the editor. It was a very interesting experience that felt fresh, even if the results were not amazing.
Now I am a hundred percent using Claude Code with a mixture of other models in the mix. It's amazing.
Yesterday I worked with CC on a CLAP plugin for Bitwig written in C and C++. It did really well - with buffer management, worker threads and proper lock-free data structures and synchronization. It even hand rolled its own WebSocket client! I was totally blown away.
Sure, it needs some encouragement and help here and there, and having a lot of experience for this kind of stuff is important right now for success, but I can definitely see it won't be that way for much longer.
I'm just so happy I can finally get round to all these projects I have had on the back burner all these years.
The productivity is incredible, and things mostly just work. It really brings me a lot of joy and makes me happy.
That’s a good way to put it. I hadn’t realized how gamified it has become. I originally felt like Claude and I were a team, but it goes off the rails so much that I find myself pulling the lever with increasing febrility. Fortunately I’m old enough to know when to quit but I’ve seen a friend just disappear into coaxing Claude for hours instead of writing code himself. I wonder if he’s got Claude gambling addiction
The irony is I alt-tabbed to HN to read this article after starting Claude Code on an implementation pass.
My usage of Claude Code sounds different to a lot of ways I hear people using it. I write medium detail task breakdowns with strict requirements and then get Claude to refine them. I review every single line of code methodically, attempting to catch every instance Claude missed a custom rule. I frequently need to fix up broken implementations, or propose complete refactors.
It is a totally different experience to any other dev experience I have had previously. Despite the effort that I have to put in, it gets the job done. A lot of the code written is better than equivalent code from junior engineers I have worked with in the past (or at worst, no worse).
Any code that chatgpt or claude ever gave me was overly verbose and highly inefficient in the best case, and riddled with subtle or not so subtle bugs in the worst case. Before the average junior dev will even discover those bugs his grasp on the codebase will have fallen so far behind that he won't stand a chance to redeem the project. Software quality is taking a nosedive. Our industry is vibecoding itself off the cliff.
My experience with AI seems to be totally different than for most people. As an example, the other day asks chatgpt to write a configuration file for SQL fluff that formatted the code as an example that I provided.
It proceeded to invent all the SQL fluff rules. And the ones that were actual rules were useless for the actual format that I wanted. I get it, SQLFluff rules are really confusing, but that's why I asked for help. I know how to code python I don't need AI to write code that then I will need to review
I think that's a very common experience when you try to make it write niche stuff. It just makes everything up wholesale. If you on the other hand wanted to write a react app ...
But then I may as well have the AI say no, I don't know how to do that, here are some useful resources. Instead of misleading me and making me waste my time figuring out why the code doesn't work
We might get there at some point. But it's not natural for this technology. It wasn't trained to recognize what it does and doesn't know. But I'm hopeful. It was terrible at doing math as well and it's getting significantly better with just more effort.
It might be hard to tune it though so that AI won't claim that it doesn't know something when it does, by error, or just because it doesn't like you.
It's not uncommon for a student to say they don't know something they actually do when they are questioned.
Maybe that idea has probably been considered (a lot) and never implemented because the can't tell?
There was a post somewhere that said if an AI invents a method or rule for something, it actually should be there. =)
It's a statistical prediction machine and it says your library should have a do_foo function. Is there a reason why it doesn't have one?
> My experience with AI seems to be totally different than for most people.
It's not different from most people. Everyone runs into AI bullshit. However, hype and new tech optimism overrides everything.
Or, you know, there are different ways of using these tools. Slapping something into ChatGPT is one way, though maybe not the most efficient way of getting value out of these tools.
So what should I have done differently? If I have to spend 1 hour to setup the AI tools then I'm not saving any time
Using an agentic coding assistant would be the first step (there are many, Cline, Claude Code, Gemini CLI and various others) as those can traverse the code base, execute tests, run queries or web search and feed the outputs back into itself to validate correctness of whatever the agent has created/done.
You won't need to set up this stuff for an hour every time, you set it up once and then you just give it commands.
The skill ceiling is deceptive, it feels very low at first (after all, it's just natural language, right?) but getting an intuition for where these tools work best and where they break down, how to task them, what to include in the instructions, it takes a bit of using them first.
That said, if you're a code maximalist, if you get most enjoyment out of hand crafting code or of you don't feel comfortable communicating effectively or delegating work, then maybe these tools aren't for you.
At this point in time I'm also pretty much over proselytizing anyone, I get a TON of value out of this stuff, but everbody has to find their own workflows.
How would adding my codebase help when I literally was starting from scratch and that's why I needed the configuration file?
> Or, you know, there are different ways of using these tools.
There aren't. Every new "one true way of doing it" that changes every few days runs into these problems.
Every iteration of the tools improves the output quality, many of the problems from a year ago are not problems today.
And new problems appear. This remains a fact of life: https://news.ycombinator.com/item?id=44702776
Definitely, but isn't that progress? We solve problems and new problems appear, which we also solve. Rinse and repeat until the sun blows up.
> Definitely, but isn't that progress?
That is beside the point of the original comment
> We solve problems and new problems appear, which we also solve.
In AI space these are not new problems. These are the same "let's try this new magic incantation agains a non-deterministic black box".
Ok man, you do you. I'm over here making food use of this tooling, but it's not for everyone. Agree to disagree.
> I'm over here making food use of this tooling, but it's not for everyone.
Yup, you're the one using perfect tooling that never produces any issues, or erroneous output, and is perfect in every way.
Unlike these idiot opponents of yours who don't have the intelligence and skill to use these amazing magical tools.
Or, perhaps, your opponents actually use these tools daily and actually understand what they can and can't do?
Who says these tools don't make any mistakes? Don't put words in my mouth or project your own fallacies. Nothing in the world is perfect, but there is absolutely useful stuff to be had.
Keep your head in the sand though.
> Who says these tools don't make any mistakes?
You heavily imply it in every comment you write. You've literally started debating my comment where I say that everyone runs into AI bullshit. You literally keep debating me when I point out that despite all the progress AI bullshit remains.
Your literal answer to "It's not different from most people. Everyone runs into AI bullshit." was literally "Or, you know, there are different ways of using these tools."
> Nothing in the world is perfect, but there is absolutely useful stuff to be had.
Says the person claiming I put words in his mouth or projecting my fallacies. Where exactly did I say this stuff wasn't useful? Literally nowehere.
> Keep your head in the sand though
Someone recently told me: "Don't put words in my mouth or project your own fallacies. "
Adieu.
That headline really resonates as I spent many years in Las Vegas. LLMs in general have very slot machine like qualities. WHen they “pay off” they are great.
Oh great, together we are two datapoints that reinforce the OP's hypothesis. I have a strong distaste for gambling in all forms and I don't enjoy using opaque, unreliable text generators either.
There are many ways to describe LLMs and coding assistants. The slot machine is a pretty good one.
I also compare "AI" to using a Ouija Board. It's not meant for getting real answers or truth. The game is to select the next letter in a word to create a sequence of words. It's an entertainment prop, and LLMs should be treated similarly.
I have also compared "Artificial Intelligence" to artificial flavors. Beaver anus is used as artificial vanilla flavoring (that is a real thing that happens), and "AI"/LLMs are the digital equivalent. Real vanilla tastes so much better, even if it is more expensive. I have no doubt that code written by real humans works much better than AI slop code. Having tried the various "AI" coding assistants, and I am not at all impressed with what it creates. Half the time if I ask for "vanilla", it will tell me "banana".
.. But the house always wins ?
Right? I hope that at some point the weights system will become clear enough that one could bias against wrong answers. Just “telling” it that is wrong biases for the current token cache and doesn’t back propagate to the model. Of course back propagating user input would be very exploitable so I don’t see that happening.
What about if further individualized training could occur at the user site?
Quite possibly. They are subsidized right now, but those things are really expensive.
I started writing software in 2001 - I loved problem solving, or the act of creating the perfect snowflakes of SOLID code, the most beautifully optimized database query or the most developer friendly SDK libraries - probably stemming my experience joining projects where the code base was trash. But parts of the job do feel like repetitive drudgery... which is where I think AI comes in beautifully.
What I've learned so far is that AI is only as good as the average developer who writes code and is only as effective as the codebase is approachable... unless you let the AI contribute to the architecture at the ground floor it will get just as confused and write just as much spaghetti code as a human coder will.
Like other professions before us... this is a moment where software engineers must adapt or perish. It was a battle to overcome the stubborn mindset of being unchanged in my ways (and adopt AI)... but the writing is on the wall. And now I'm building and refining the very same AI tools that do the jobs of data analysts and software engineers.
In both scenarios (slot machines and vibecoding) anticipation is the name of the game. Much like doomscrolling.
My worry is we're going to have a generation of engineers that have not built up the necessary critical thinking/pattern matching skills needed to weigh tradeoffs and bring in context to ask the right questions and interpret the answers.
Sure we can segment this into code generation models and code review models but are engineers really going to want to be questioned by a code review tool on "what are you trying to do?" or are they just going to merge and pull the slot lever again?
my time coding with Claude has been the most joyful experience in my 25 years of coding.
I have delivered many pet projects I always wanted to build and now focus in the operation of them.
no moment in my coding life has been this productive and enlightening. pretty often I sit down to read how the ai solved the issue and learn new techniques and tools.
studying a paper, discussing it with Opus, back and forth, taking notes, make Opus check my notes. it improved a lot my studying sessions too.
I respect the different experiences each of us get from this. for fairness I share mine
It's nice that you have all those wonderful experiences with LLMs. But for once in your life, could you show us the code? Because you look like yet another cheerleader that have nothing to show, and it's annoying.
Sure. I'll show something. I'm working on an app to help teach myself french. I work at a busy startup so I only have a few hours to spare here and there, but I've managed to make an app that works very well for me, mainly because of the help I receive from Claude Code. I can't make the github repo public because it contains some copyright material [^1]. but maybe I'll make a censored version public if there's interest. It's at https://yap.town .
[^1]: to be clear, nothing in the frontend is copyrighted. I use some copyrighted works to figure out how common various words are, which I need because I wanted the app to teach the most common words first.
Edit: the site uses the FileSystemWritableFileStream API, so Safari/iOS users will need Safari 26.
Site isn’t working for me on iOS safari.
I should have mentioned. The site uses the FileSystemWritableFileStream API, so Safari/iOS users will need Safari 26.
Site is stuck on "checking browser support".
There should be a better UX for users on unsupported browsers now.
You touch upon an interesting phenomenon that is quite pervasive throughout the world of software development, and possibly many other fields as well.
To avoid heated discussions, allow me to illustrate the concept with why enterprise software is mainly built with Java, whereas most blog posts are about writing backends with TypeScript, Python, or Rust. The reason for this is at least twofold:
1. Professional programmers don't get paid to write blog posts, and typically want to spend their free time doing other things. Hobbyists do have the time, but they typically do not see the added value of a boring language such as Java, because they don't work in teams.
2. When something is already known, it is boring for people to read about, and therefore less interesting to write about. When something is new, many people write about it, but it's hard to tell who is right and who is wrong.
Given that good writing, and the additional marketing to find the respective audience, take energy, it is not strange that we find weirdly biased opinions when reading blog posts and forums on the internet. I typically find it better to discuss matters with people I know and trust, or to experiment a bit by myself.
The same might happen now with reporting on AI assisted coding.
Edit: might as well just have said "visibility bias" and "novelty bias" if I had consulted an LLM before commenting.
As someone who has been using Java for enterprise software for over 25 years, but who likes to program his pet projects in Python, let me give you another reason:
3. Python has a very fast feedback loop. You type, run and see the result immediately. This is great for small projects and prototypes. Java needs much more work, not just for the compiling but it also needs more boilerplate. This is fine for enterprise projects which typically are very large and prefer stability over speed of development. But at home I don't have the time or the patience for that.
I'm very into tight cadence and have a lot of options to choose from, doing most of my "pets" in Racket, Elixir, Picolisp and p5js, but I still sometimes generate a Maven project and start hacking in a unit test because libraries and performance are excellent and sometimes it requires less effort to brute a problem with imperative mutations.
Pharo is an alternative but documentation and libraries just aren't as good, and maybe never will be.
Here's an example, from a session from yesterday and today, buyer beware naturally I'm still testing and refining it: https://github.com/rdaum/tature
I'll now go through this, remove the excessive comments and flowery language, add more tests, put it through its paces. But it did me a service by getting the pieces in place to start.
And I'm even above the 250 karma threshold!
This is the new "Source?" comment (which, funny enough, still works).
But I don't think the code matters as much as the intention. The comment is all about exploration and learning. If you treat your LLM like a Wikipedia dive, you will come out the other end with newfound knowledge. If you only want it to achieve a discrete goal, it may or may not do so, but you will have no way to know which.
I have had similar experiences to OP. All of these apps (mostly maths learning, but also the bus one) were coded using a mix of copilot and Gemini CLI: https://rupertlinacre.com/
I'm probably capable of building all of them by hand, but with a 6yo I'd have never had the time. He loves the games, his mental arithmetic has come on amazingly now he does it 'for fun'.
All code is here: https://github.com/rupertlinacre
Much of this built out of a frustration that most maths resources online are trying to sell you something, full of ads, or poor quality. Just a simple zoomable numberline is hard to find
No code to share yet, but results nonetheless.
Tabu search guided graph layout:
https://bsky.app/profile/micahscopes.bsky.social/post/3luh4s...
https://bsky.app/profile/micahscopes.bsky.social/post/3luh4d...
Fast Gaussian blue noise with wgpu:
https://bsky.app/profile/micahscopes.bsky.social/post/3ls3bz...
In both these examples, I leaned on Claude to set up the boilerplate, the GUI, etc, which gave me more mental budget for playing with the challenging aspects of the problem. For example, the tabu graph layout is inspired by several papers, but I was able to iterate really quickly with claude on new ideas from my own creative imagination with the problem. A few of them actually turned out really well.
Sometimes I'll admit that I do treat Claude like a slot machine, just shooting for luck. But in the end that's more trouble than it's worth.
The most fruitful approach is to maintain a solid understanding of what's happening and guide it the whole way. Ask it to prove that it's doing what it says it's doing by writing tests and using debug statements. Channel it toward double checking its own work. Challenge it.
Another thing that worked really well the other day was to use Claude to rewrite some old JavaScript libraries I hand wrote a few years ago in rust. Those kinds of things aren't slot machine problems. Claude code nails that kind of thing consistently.
Ah, one more huge success with code: https://github.com/micahscopes/radix_immutable
I took an existing MIT licensed prefix tree crate and had Claude+Gemini rewrite it to support immutable quickly comparable views. In about one day's work. I scoured the prefix tree libraries available in rust, as well as the various existing immutable collections libraries and found that nothing like this existed. This implementation has decently comprehensive tests and benchmarks.
One more I'll share, an embarrassing failure: https://github.com/micahscopes/splice-weaver-mcp
I used vibe kanban like a slot machine and ended up with a messy MCP server that doesn't really do anything useful that I can tell. Mostly because I didn't have a clear vision when I went into it.
they almost exclusively have under 250 karma too...
> I have delivered many pet projects I always wanted to build and now focus in the operation of them. > pretty often I sit down to read how the ai solved the issue and learn new techniques and tools.
I have very similar experiences, but very often I wonder if I couldn't just have gone to an open source project on the same topic (e.g. building a toy parser) and read the source code there, instead of letting a code generator AI reproduce it for me. Because that happy feeling is very similar to early moments in my developer career, when I read through open source standard libraries and learned a lot from it.
> I have delivered many pet projects I always wanted to build and now focus in the operation of them.
We probably have different personalities but the former is the only part I care about. It’s the operation that bores me.
I'd love to read the article, but the gray text is too well camouflaged against the gray background.
Good catch. I tweaked it some, let me know if that helps.
I started using Claude AI, ChatGPT, and DeepSeek for helping me to develop Windows applications using Delphi Pascal a few months ago. I absolutely love it. I learned Pascal when I was 16 (high school) and throughout college. I have never been a professional programmer in my life. I'm getting old. I want to start getting back into programming. AI has helped me tremendously. AI has helped me to develop many special procedures and functions which I could not figure out by myself anymore. I am a Vice President at a company that sells computer networking equipment. Still need to keep my day job. By the way, Claude AI is the best so far when it comes to Pascal. ChatGPT is disappointing, maybe it's better in other programming languages. DeepSeek depends, it's average.
> 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.
That's why developers are poorly paid and viewed as disposable cogs. It feels "easy" to many people and so they internally think it is immoral to get paid and corporations ruthlessly prey on that feeling. Reality is that development is hard and requires immense mental work, constant upskilling and is not something you can switch off after 5pm and think of something else. Your brain is constantly at work. That work also is creating millions and billions that gets extracted from developers and flow to the greedy hands of the rich, who now control all the means of production (think of cloud services, regulation - try starting your own forum today, anything with user generated content etc.).
Developer did themselves dirty.
TIL that “developers are poorly paid”.
TIL someone thinks a £60k dev job in London means you’re not being exploited - because you can afford a Tesco meal deal and a flatshare in Zone 4. Never mind your code prints money for people you’ll never meet, or that your “reward” is a Jira ticket and a perf review.
Developers went from garage-tinkerers to the backbone of the modern economy - and somehow ended up as overworked, disposable employees in open-plan office farms. The owners changed, the IDEs got fancier, but the deal stayed the same: build the machine, never own it.
You upskill constantly just to not fall behind. You work nights “for the launch.” You get gaslit into thinking stock options in a private company are equity. Then you’re laid off via email - while the founders post yacht selfies.
And the worst part? Most of you still believe you’re lucky. That’s the grift: teach engineers to think they’re “not like other workers” - then extract surplus value just like any other industry has done since the 19th century.
Developers are poorly paid - not because the salary is low, but because the upside is stolen. You created the wealth, they captured it.
The tool is insanely powerful, but Anthropic needs to build a more interactive structure into the tool. Just "accept this diff or not" is not ideal.
If you prompt it correctly and rigidly, and review everything it does large or small, it's a 10x tool for grinding through some very hard problems very quickly.
But it can very easily lead you into overconfidence and bloat. And it can "cheat" without you even realizing it.
Claude Code is best used as an augmentation, not automation tool. And it's best that the tool makers and investors realize that and stop pretending they're going to replace programmers with things like this.
They only work well when combined with a skilled programmer who can properly direct and sift through the results. What they do allow is the ability to focus on higher level thinking and problems and let the tool help you get there.
>> AI disrupts the process.
I completely agree when using synchronous tools like Windsurf and Cursor. This is why I much prefer the async workflow most of the time. Here you get a chance to think about how the AI should be constrained in order to have the highest probability of a "one shot" PR or at least something that would only require a few edits. I spend a lot of time on the AGENTS.md file and as well as thinking a lot about the prompt that I am going to use. I sometime converse with ChatGPT a little on the prompt as the feedback loop is very fast. Then, just send it and wait ~5 minutes for completion.
I still use synchronous tools sometime for UI and other things were it is hard to specify up front and iteration is required. But realistically, I use async 50:1 over sync.
Lovable, I feel, works at a higher abstraction layer. The unpredictability of whether my prompt will generate something delightful in that initial design creates an addictive slot machine dynamic. But would these tools lose their magic if the results became completely deterministic?
Nah, it would become actually useful. Companies are not going to keep paying for slot machines. There is a strong incentive to make them reliable.
Companies will rationally stop paying for slot machines that pay out $0.90 for every $1 wagered, but they’ll happily pay for slot machines that pay out $5 for every $1 wagered.
Which will be the case is the interesting question.
At this point I am doubtful about calling companies rational actors in many many cases. So probably they play both machines. And it is somewhat luck which they hit and some maybe have rational leaders.
> But would these tools lose their magic if the results became completely deterministic?
No. They would become extremely useful and more magical. Because instead of weird incantations and shamanic rituals of "just one more .rules file, bro, I swear" you could create useful reproducible working tools.
Except an LLM is not and never will be deterministic, by its very design that is not how it operates. It would need to be a fundamentally different tech from the ground up.
Exactly :)
Am I the only one who doesn't find CC makes me faster? I mean, it could, if I let it, but that means not reading or understanding what it's writing. Basically I just don't really believe anyone is writing software of the same quality in less time. But I can totally see how you can write software of lower quality in a fraction of the time.
The interesting thing is going to be how this all holds up in a year or five. I suspect it's going to be a lot of rewriting the same old shit with LLMs again and again because the software they've already made is unmaintainable.
I didn't get into software to labour like a factory worker day in, day out. I like to solve problems and see them deliver value over years and even decades, like an engineer.
> AI coding tools supercharge this, allowing you to bring whole machineries to life by waving your hands around, offloading the understanding for much longer
I guess you could use them like that, but you'll do much better if you try to get an understanding of the problem beforehand. This way you can divide the problem into subtasks with reasonably clear description, that Claude will be able to handle without getting lost and without needing too many corrections.
Also, you'll still need to understand pretty much every task that Claude has implemented. It frequently makes mistakes or does things in a suboptimal way.
When you use AI properly it's a great tool, it's like an IDE on steroids. But it won't take away the need to use your brains.
Love it or hate it, at the very least you can grant it this: Claude Code can mitigate some of the cost of Yak Shaving [1]. You need this digression/distraction feature, even though it's not the main attraction. Testing/infrastructure etc -- whatever it is, let's just have the automaton do the tedium.
[1] https://en.wiktionary.org/wiki/yak_shaving
Actually the model I like to use is a Pacinko machine. Where you can visualize all of the options that are available, while internal cursor just randomly bounces from pin to pin.
You definitely need to be careful of the addition mechanics of CC, but is it still a slot machine if there are loads of steps you can take to improve your odds of success? For instance, only allowing it to code within a feedback loop of some kind. I find the author's premise that the skill here is just "knowing which model to use" way too reductive. Seems like an entirely different beast to gambling, where the odds are fixed by the house.
If you actually can code and know to define testable constraints around what you want it's great.
But it is amazing how many people really are playing it like a slot machine and hoping for the best.
That's just people and as always some will better utilise new tech than others. On aggregate I think everyone still wins
Yes, the gamification is why some people like it. It is another addiction. Most proponents and bloggers are tied to "AI" money though, directly or indirectly.
I've seen little organic praise from high profile programmers. There aren't many, and once you search they all at least work on a commercial "AI" application.
Simon Willison[1] of Django Framework founder[2] fame is a pretty big AI programming proponent at his blog. He's pretty high profile, as far as real-world programmers (as in, not executives and not promoters) go.
You could argue, he makes money off of AI with his newsletter and whatnot, so he does stand to gain something, but it's a lot less than the executives and investors who've filled the news.
[1] https://simonwillison.net/ [2] https://en.wikipedia.org/wiki/Django_(web_framework)
There are other ways to use AI for coding. Watch this, if you want to see my (different than the vibe coding approach) way: https://www.youtube.com/watch?v=3Z7T0DgHrWM&ab_channel=Salva...
I've been reading Hooked by Nir Eyal and this was my conclusion too about all LLMs after just the introduction.
elaborate more as I dont read the book yet
Without explaining the book: Feedback loops + random chance llm is right
When it’s wrong, what do you do? Pull the lever.
> AI coding tools supercharge this, allowing you to bring whole machineries to life by waving your hands around, offloading the understanding for much longer, but if you want it all to actually work, you'll need to dive into the details eventually.
The answer to this is nuanced. You can summon ~30k LoC codebases using CC without much fanfare. Will it work? Maybe, in some of the ways you were thinking -- it will be a simulacrum of the thing you had in your mind.
If something is not working, you need to know the precise language to direct CC (and _if you know this language_, you can use CC like a chisel). If you don't know this language, you're stuck -- but you'd also be stuck if you were writing the thing _by hand_.
In contrast to _writing the thing by hand_, you can ask CC to explain what's going on. What systems are involved here, is there a single source of truth, explain the pipeline to me ...
It's not black and white in the way I experienced this paragraph. The "details" you need to know vary across a broad spectrum, and excellent wizards can navigate throughout the spectrum, and know the meta-strategies to use CC (or whatever agentic system) to unstick themselves in the parts of the spectrum they don't know.
(lots of that latter skill set correlate with being a good programmer in the first place)
Many of my colleagues who haven't used CC as much seem to get stuck in a "one track" frame of mind about what it can and cannot do -- without realizing that they don't know the meta-strategies ... or that they're describing just one particular workflow. It's a programmable programming tool, don't put it into a box.
I read this entire post before realizing you weren't referring to `cc`, the C compiler. It actually kinda works with this interpretation, particularly the "if you know this language" part.
I'm a 72 year old dev. Ai and Claude specifically are great because I can't focus on code like I used to. Ai has extended my viability for a few years.
See also Anthropic's blog post directly comparing Claude Code to a slot machine, and the top comment pointing out said comparison: https://news.ycombinator.com/item?id=44678535
I compared vibe coding to gambling in one of my recent blog posts and thought that metaphor was slightly uncharitable, but I didn't expect "slot machine" to actually now be the term of art.
In other words: code assistants are going to wipe out software engineering (and adjacent roles) as a lucrative career path for generations to come...but not before our generation retires and "gets ours."
Claude works best for context based pattern matching. I specifically use claude for tasks which are simply replicating the logic with minor contextual differences. I can’t even imagine Claude writing whole features by itself.
One unpopular opinion I hold is that in recent times programming became a lot more about integrating libraries and frameworks vs writing your own thing. This was fine because if someone open sourced it, why repeat the same work. That ended up in cases where a lot of work was modifying the libraries to your use case.
With vibe coding, I suspect this is a group that has adapted to it really well (alongside hobby coders and non coders). The thrill comes from problem solving, and when you can try out the solution quickly and validate, it is just addictive. The other side is how open source frameworks have increased, and there are a lot of oss libraries for just about everything. (A personal experience is implementing Cmd bar (like linear) in react when i was just learning. It took me a week or so, and then i just inserted an oss thing for comparison. It was super smooth, but i did not know the assumptions. In production, i will prefer that, and dont always have time to learn and implement from scratch). We see this with langchain etc in LLMs too, and other agentic frameworks as well. The shift is not towards less code but getting the thing to work faster. Claude code accelerates that exponentially as well.
Unpopular opinion would be that if the project is not much more than a bunch of libraries/tools/techs integrated together than the need for its existence is questionable. Diversity there breaks "one way of doing things" and makes it harder to learn actual tech that makes it work.
i meant in a way that programming is always synthesis. (to my brain) combining stuff from multiple places is good, but not great synthesis you can do on your own. Many developer feel there is not much of a difference between the two. No comment on whether there is a need for the existence.
Typical dark pattern with your mystery boxes and player skins. Claude code just makes it easier to tell yourself that its ok to play.
One of the reasons a lot of things look like gambling is that a lot of things look like gambling. Hunting, gathering, and other baseline pre-civilization survival activities look like gambling. Dating looks like gambling. Reproduction even looks like gambling with each offspring, as a product of genetic recombination, being a dice roll. Investing, of course, looks like gambling.
It's why we get so addicted to gambling. We're built for it because a lot of legitimate real things look like gambling.
It's definitely addictive. But also, it works really well with some steady guidance.
avoid any gambling addiction, run with --dangerously-skip-permissions
Anyone else kind of lose the high of solving a difficult problem since LLMs became the workflow?
You still have to really guide the AI, none of this is automatic. Yet I no longer feel the mega joys I once felt hand building something and watching it work correctly. The thrill is gone! Don't know if this is good or bad yet. I don't miss the plumbing bullshit. I do miss the joy.
This is a common argument against AI generation and I dislike it because people derive their joy from different things. Some engineers get their joy from the process of creation, others get their joy from the final result. Neither way is inherently better or more morally correct than the other.
Claude Code is^W^W^WEvery LLM is a slot machine.
> but if you want it all to actually work, you'll need to dive into the details eventually.
I don't think that's true. I'm wondering if the author has tried Claude 4 Opus.
I have just fought 4 days with Claude 4 Sonnet because it generates too much garbage for my usage, and I am considering stopping the AI usage altogether. No matter what system prompt, rules et. all you give, they don't want to do as I said, but instead do something which compiles (Rust) but is not performant or is extremely verbose and includes all kinds of unnecessary things. They have too much assumptions that some function is used/not used in async context, or it is okay to clone, or whatever. Is the Opus really that big leap?
So is our brain. We pay with time.
anyone know how to make claude code to be less invasive?
The degree of after-the-fact ad hoc justifications for using these tools makes my brain hurt. "I'm in meetings all day anyway" …wtf?! So yay for the machines taking over our skillsets and hard-earned craft so we can attend more meetings*? Sure sounds like a hellscape to me!
* How 'bout I deploy my "digital twin" to attend the meetings for me. That'll show 'em!
It is just another tool. Novel and powerful, but a tool nonetheless.
You cannot write everything using LLMs, you cannot maintain hodgepodge LLM codebases, but also you might want a break from writing scaffolding code or simple functions.
and a damn good one
in the sense that is totally unpredictable and suck your time into the void without learning anything?
in the sense that if I have to change the shape of a complex static object or do anything tedious, it can just do it. What exactly would you say I have to learn from tasks like that?
I think you meant a slop machine
The world is a slot machine.
There’s a reason intermittent rewards are so intoxicating to naturally evolved brains: exploiting systems that give intermittent rewards is a great resource acquisition strategy.