Not a day goes by that a fellow engineer doesn't text me a screenshot of something stupid an AI did in their codebase. But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
The catch about the "guided" piece is that it requires an already-good engineer. I work with engineers around the world and the skill level varies a lot - AI has not been able to bridge the gap. I am generalizing, but I can see how AI can 10x the work of the typical engineer working in Startups in California. Even your comment about curiosity highlights this. It's the beginning of an even more K-shaped engineering workforce.
Even people who were previously not great engineers, if they are curious and always enjoyed the learning part - they are now supercharged to learn new ways of building, and they are able to try it out, learn from their mistakes at an accelerated pace.
Unfortunately, this group, the curious ones, IMHO is a minority.
I am going to try to put this kindly: it is very glib, and people will find it offensive and obnoxious, to implicitly round off all resistance or skepticism to incuriosity. Perhaps to alienate AI critics even further is the goal, in which case - carry on.
But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"? Is it possible that they are not enthusiastic for the change in the nature of the work? Is it possible they are concerned about "automation complacency" setting in, precisely _because_ of the ratio of "hundreds of times" writing decent code to the one time writing "something stupid", and fear that every once in a while that "something stupid" will slip past them in a way that wipes the entire net gain of AI use? Is it possible that they _don't_ feel that the typical code is "better than most engineers can write"? Is it possible they feel that the "learning" is mostly ephemera - how much "prompt engineering" advice from a year ago still holds today?
You have a choice, and it's easy to label them (us?) as Luddites clinging to the old ways out of fear, stupidity, or "incuriosity". If you really want to understand, or even change some minds, though, please try to ask these people what they're really thinking, and listen.
My feeling is that the code it generates is locally ok, but globally kind of bad. What I mean is, in a diff it looks ok. But when you start comparing it to the surrounding code, there's a pretty big lack of coherency and it'll happily march down a very bad architectural path.
In fairness, this is true of many human developers too.. but they're generally not doing it at a 1000 miles per hour and they theoretically get better at working with your codebase and learn. LLMs will always get worse as your codebase grows, and I just watched a video about how AGENTS.md actually usually results in worse outcomes so it's not like you can just start treating MD files as memory and hope it works out.
> But when you start comparing it to the surrounding code, there's a pretty big lack of coherency and it'll happily march down a very bad architectural path.
I had an idea earlier this week about this, but haven’t had a chance to try it. Since the agent can now “see” the whole stack, or at least most of it, by having access to the repos, there’s becoming less of a reason to suspect they won’t be able to take the whole stack into account when proposing a change.
The idea is that it’s like grep: you can call grep by itself, but when a match is found you only see one line per match, not any surrounding context. But that’s what the -A and -B flags are for!
So you could tell the agent that if its proposed solution lies at layer N of the system, it needs to consider at least layers N-1 (dependencies) and N+1 (consumers) to prevent the local optimum problem you mentioned.
The model should avoid writing a pretty solution in the application layer that conceals and does not address a deeper issue below, and it should keep whatever contract it has with higher-level consumers in good standing.
Anyway, I haven’t tried that yet, but hope to next week. Maybe someone else has done something similar and (in)validated it, not sure!
I don't think that people who don't want to use these tools or clean old ways are incurious. But I think these developers should face the fact that those skills and those ways they are reticent to give up are more or less obviated at this point. Not in the future, but now. It's just that the adoption of these tools isn't evenly distributed yet.
I think there's a place for thoughtful dialogue around what this means for software engineering, but I don't think that's going to change anything at this point. If developers just don't want to participate in this new world, for whatever reason, I'm not judging them, but also I don't think the genie is going back in the bottle. There will be no movement to organize labor to protect us and there be no deus ex machina that is going to reverse course on this stuff.
> I think these developers should face the fact that those skills and those ways they are reticent to give up are more or less obviated at this point.
Yes. We are this generations highly skilled artisans, facing our own industrial revolution.
Just as the skilled textile workers and weavers of early 19’th century Britain were correct when they argued this new automated product was vastly inferior, it matters not at all. And just as they were also correct, that the government of the day was doing nothing to protect the lives and livelihoods of those who had spent decades mastering a difficult set of professional skills (the middle class of the day), the government of this day will also do nothing.
And it doesn’t end with “IT”; anything that can be turned into a factory process with our new “thinking engines” will be. Perhaps we can do better in society this time around. I am not hopeful.
I'm using Claude every day, and it definitely makes me faster but.. I'm also able to give it a lot of very specific instructions and correct a lot of mistakes quickly because I look at the code and understand what it's doing; and I'm also asking it to write code in domains I understand. So I don't think these skills are obsolete at all. If anything, keeping them sharp is the only differentiator we have. "Agentic Engineering" is as much as joke as "Vibe Coding" is in my mind. The tools are powerful, but they don't make up for knowing how to code, and if you're just blindly trusting it it's going to end badly.
>I'm using Claude every day, and it definitely makes me faster but..
I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case.
Now of the course the "this isn't the case" stuff is statistically, thus there can be individual developers whom are faster, but there can also be that an individual developer sometimes is faster and sometimes not but the times that they are faster are just so clearly faster that it sort of hides the times that they're not. Statistics of performance over a number of developers can flatten things out. But I don't know that is the case.
So my question for you, and everyone that claims it makes them so perceptively and clearly faster - how do you know? Given all the studies showing that it doesn't make you faster, how are you so sure it does?
It's incredibly frustrating arguing these same points, over and over, every time that this comes up. You're asking people who are experienced developers absolutely chewing through checklists and peeking at HN while compiling/procrastinating/eating a sandwich/waiting for a prompt to finish to not just explain but quantify what is plainly obvious to those people, every day. You want us to bring paper receipts, like we have some incentive to lie to you.
From our perspective, the gains are so obvious that it really does feel like you must just be doing something fundamentally wrong not to see the same wins.
So when someone says "I can't make it do the magic that you're seeing" it makes me wonder why you don't have a long list of projects that you've never gotten around to because life gets in the way.
Because... if you don't have that list, to us that translates as painfully incurious. It's inconceivable that you don't have such a list because just being a geek in this moment should be enough that you constantly notice things that you'd like to try. If you don't have that, it's like when someone tells you that they don't have an inner monologue. You don't love them any less, but it's very hard not to look at them a bit differently.
>It's incredibly frustrating arguing these same points, over and over,
quite frankly there seems to be something incredibly frustrating in your life going on, but I'm not sure that the underlying cause of whatever is weighing on your mind at the moment is that I asked "how do you know that what you are feeling is actually true, in comparison to what studies show should be true?" (rephrased, as not reasonable to quote whole post)
>From our perspective, the gains are so obvious that it really does feel like you must just be doing something fundamentally wrong not to see the same wins.
From my perspective, when I think i am experiencing something that data from multiple sources tell me is not what is actually happening I try to figure out how I can prove what I am experiencing, I reflect upon myself, have I somehow deluded myself? No? Then how do I prove it when analysis of many similar situations to my own show a different result?
You seem to think what I mean is people saying "Claude didn't help me, it wasn't worth it", no, just to clarify although I thought it was really clear, I am talking about numerous studies always being posted on HN so I'm sure you must have seen them where productivity gains from coding agents do not seem to actually show up in the work of those who use it. Studies conducted by third parties observing the work, not claims made by people performing the work.
I'm not going to go through the rest of your post, I get the urge to be insulting, especially as a stress release if you have a particularly bad time recently. But frankly, statistically speaking, my life is almost certainly significantly worse than yours, and for that reason, but not that reason alone, I will also quite confidently state without hardly any knowledge of you specifically but just my knowledge of my life and comparison of having met people throughout it, that my list dwarfs yours.
I'm a principal engineer, been working on the same set of codebases for almost 10 years. I handle the 20% or so of my time that constitutes inbound faster than ever and I know because that inbound volume has clearly increased and yet I have, for the first time ever, begun chipping away at the "nice to have" backlog. My biggest time sink now is interviewing and code reviews -- the latter being directly proportional to the velocity increase across the teams I work with. Actually that's my biggest concern -- we are approaching a breaking point for code review volume.
Sorry I don't have DX stats or token usage stats I can share, but based on the directives from on high, those stats are highly correlated (in the positive).
> everyone that claims it makes them so perceptively and clearly faster - how do you know?
For me, AI tools act like supercharged code search and auto complete. I have been able to make changes in complex components that I have rarely worked on. It saved me a week of effort to find the exact API calls that will do what I needed. The AI tool wrote the code and I only had to act as a reviewer. Of course I am familiar with the entire project and I knew the shape of the code to expect. But it saved me from digging out the exact details.
> I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case.
Most of these studies were done one or more years ago, and predate the deployment and adoption of RLHF-based systems like Claude. Add to that, the AI of today is likely as bad as it's ever going to be (i.e., it's only going to get better). Though I do think the 10x claims are probably unfounded.
I mean obviously things will always be a little bit behind that one reads about, so this is one of the claims I see sometimes about these studies is they are out of date, and if working with the new models they would find that wasn't the case. but then that is one of the continuing claims one also sees about LLMS, that the newest model fixes whatever issue one is complaining about. And then the claim gets reiterated.
The thing is when I use an AI I sort of feel these gains, but not any greatness, it's like wow it would have taken me days to write all this reasonable albeit sort of mediocre code. I mean that is definitely a productivity gain. Because a lot of times you need to write just mediocre code. But there are parts where I would not have written it like that. So if I go through fixing all these parts, how much of a gain did I actually get?
As most posters on HN I am a conceited jerk, so I can claim that I have worked with lots of mediocre programmers (while ignoring the points where I was mediocre by thinking oh that didn't count I followed the documentation and how it was suggested to use the API and that was a stupid thing to do) and I certainly didn't fix everything that they did, because there just wasn't enough hours in the day.
And they did build stuff that worked, much of the time, so now I got an automated version of that. sweet. But how do I quantify the productivity? Since there are claims put forth with statistical backing that the productivity is illusory.
This is just one of those things that tend to affect me badly, I think X is happening, study shows X does not happen. Am I drinking too much Kool-Aid here or is X really happening!!? How to prove it!!? It is the kind of theoretical, logical problem seemingly designed to drive me out of my gourd.
I'm still going to need at least one of my vendors to speed up their release pace before I'll believe that. I'm seeing a ton of churn and no actual new product.
Well, no, not with that attitude there won’t! I am not trying to insinuate that there is a conspiracy, or that posts like yours are part of it, but there has been a huge wave of posts and comments since February which narrow the Overton window to the distance between “it’s here and it’s great” and “I’m sad but it’s inevitable”.
Humanity has possessed nuclear weapons for 80 years and has used them exactly twice in anger, at the very beginning of that span. We can in fact just NOT do things! Not every world-beating technology takes off, for one reason or another. Supersonic airliners. Eugenics. Betamax.
The best time to air concerns was yesterday. The next best time is today. I think we technologists wildly overestimate public understand and underestimate public distrust of our work and of “AI” specifically. We’ve got CEOs stating that LLMs are a bigger deal than nuclear weapons or fire(!) and yet getting upset that the government wants control of their use. We’ve got giddy thinkpieces from people (real example from LinkedIn!) who believe we’ll hit 100% white collar unemployment in 5 years and wrap up by saying they’re “5% nervous and 95% excited”. If that’s what they really think, and how they really feel, it’s psychopathic! Those numbers get you a social scene that’ll make the French Revolution look like a tea party. (“And honestly? I’m here for it.”)
So no, while I _think_ you’re correct, I don’t accept the inevitability of it all. There are possibilities I don’t want to see closed off (maybe data finally really is the new oil, and that’s the basis for a planetary sovereign wealth fund. Maybe every man, woman, and child who ever wrote a book or a program or an internet comment deserves a royalty check in the mail each month!) just yet.
I agree with you on that. Not just on AI but a lot of things that suck about this world, and in particular the United States. But capital is too powerful. And these tools are legitimately transformative for business. And business pays our bills and, more importantly, provides the healthcare insurance for our families. The wheel is a real fucking drag isn't it?
I don't see anything short of a larger revolution against capital stopping or even stemming this. For that to really happen we would need a lot more people and interests than just those of software practitioners. Which may come yet when trucking jobs collapse and customer service jobs disappear. I don't know. I do know that I'm taking part in something that will potentially (likely?) seed the end of my career as I know it but it's just one of many contradictions that I live with. In the meantime the tools are impressive and I'm just figuring out how to live with them and do good work with them and as you can probably tell, I'm pretty convinced that's the best we can make of the situation right now.
100% this. I don't know why we think that pouring trillions of dollars into something we barely understand to create an economic revolution that is almost certainly awful is at all "inevitable". We just need leaders that aren't complete idiots. I'm generally cynical, but I do see that normies (ie not in tech) are waking up a bit. I don't think the technology is inherently a bad thing, but the people that think that we should just do this as fast as possible to win "the race" should be shot into space as far as I'm concerned. To start with, we need a working SEC that can actually punish the grifting CEO's that are using fear to manipulate markets.
A new technology comes out — admittedly one that’s extraordinarily capable at some things — and suddenly conventional software engineering is “more or less obviated at this point”? I’m sorry, but that’s really fucking dumb. Do you think LLMs are actually intelligent? Do you think their capabilities exceed the quality of their training corpus? Is there no longer any need to think about new software paradigms, build new frameworks, study computer science, because the regurgitated statistical version of programming is entirely good enough? After all, what’s code but a bunch of boring glue and other crap that’s used to prop up a product idea until a few bucks can be extracted from it?
Of course, there’s nothing wiser than tying the entirety of your career to a $20/month subscription (that will jump 10x in price as soon as the market is captured).
Is writing solved because LLMs can make something decently readable? Why say anything at all when LLMs can glob your ideas into a glitzy article in a couple of seconds?
I swear, some people in this field see no value in their programming work — like they’ve been dying to be product managers their entire lives. It is honestly baffling to me. All I see is a future full of horrifying security holes, heisenbugs, and performance regressions that absolutely no one understands. The Idiocracy of software. Fuck!
> Is there no longer any need to think about new software paradigms, build new frameworks, study computer science, because the regurgitated statistical version of programming is entirely good enough?
All I'm saying is you're gonna have to figure out how to do this with an agent. It's not that I don't see value in the craft; it's just that value is less important. As far as the new paradigms, the new frameworks, new studies in computer science -- they still exist, it's just that they are going to focus on how to mitigate heisenbugs, performance regressions and security holes in agent written code. Who knows.. in five years most of the code written may not even be readable. I'm not saying it's going to be like that, but it's entirely possible.
In the meantime, there's nothing stopping you from using the agent to write the code that is every bit as high quality as if you sat down and typed it in yourself. And right now there is a category of engineers that exclusively use agents to create quality software and they are more efficient at it than anybody that just does it themselves. And that category is growing and growing every day.
I may be out a job in five years because all of this. But I am seeing where this is going and it's clear and so I'm going to have to change with it.
> you're gonna have to figure out how to do this with an agent
I'm really not, though, any more than I "had to" learn JavaScript 20 years ago or blockchains 5 years ago (neither of which I did). Hell, I still use Perl day-to-day.
> In the meantime, there's nothing stopping you from using the agent to write the code that is every bit as high quality as if you sat down and typed it in yourself.
“When you're in Hollywood and you're a comedian, everybody wants you to do things besides comedy. They say, ‘OK, you're a stand-up comedian — can you act? Can you write? Write us a script?’ It's as though if I were a cook and I worked my ass off to become a good cook, they said, ‘All right, you're a cook — can you farm?’”
—Mitch Hedberg
Agentic programming isn’t engineering: it’s a weird form of management where your workers don’t grow or learn and nobody really understands the system you’re building. That sounds like a hellish, pointless career and it’s not what I got into the field to do. So no thanks: I’ll just keep doing the kind of monkey engineering I find invaluable. Especially while most available models are owned and trained by authoritarian, billionaire, misanthropic cultists.
Fortunately, I am not beholden to some AI-pilled corporation for salary.
It's important to point out that you're the one working hard to define AI critics as a camp/group/class when a stronger argument can be made that we're all in the same camp/group/class. I use agentic LLMs for coding every day and I think that it's incredibly important to maintain a critical lens and be open to changing our minds.
However, history suggests that creating artificial divisions is the first step towards all of the the bad things we claim not to like in this world.
Tech adoption generally moves like Time's Arrow. People who use LLMs aren't geeks who changed; we're just geeks. If you want to get off the train, that's your call. But don't make it an us vs them.
Underlying this and similar arguments is the presumption that the "old way" was perfect. You or your colleagues weren't doing one mistake per 100 successful commits. I have been in an industry for decades, and I can tell you that I do something stupid when writing code manually quite often. The same goes for the people that I work with. So fear that the LLM will make mistakes can't really be the reason. Or if it is the reason, it isn't a reasonable objection.
I read the parent comment as calling the majority of AI users "incurious", and not referring to us who resist AI for whatever reasons. The curious AI users can obtain self-improvement, the incurious ones want money or at least custom software without caring how its made.
I don't want the means of production to be located inside companies that can only exist with a steady bubble of VC dollars. It's perfectly reasonable to try AI or use it sparingly, but not embrace it for reasons that can be articulated. Not relevant to parent commenters point, though. Maybe you are "replying" to the article?
Time and time again that I observe it is the AI skeptic that is not reacting with curiosity. This is almost fundamentally true, as in order to understand a new technology you need to be curious about it; AI will naturally draw people who are curious, because you have to be curious to learn something new.
When I engage with AI skeptics and I "ask these people what they're really thinking, and listen" they say something totally absurd, like GPT 3.5-turbo and Opus 4.6 are interchangeable, or they put into question my ability as an engineer, or that I am a "liar" for claiming that an agent can work for an hour unprompted (something I do virtually every day). This isn't even me picking the worst of it, this is pretty much a typical conversation I have on HN, and you can go through my comment history to verify I have not drawn any hyperbole.
AI will naturally draw people who are lazy and not interested in learning.
It's like flipping through a math book and nodding to yourself when you look at the answers and thinking you're learning. But really you aren't because the real learning requires actually doing it and solving and struggling through the problems yourself.
This is just completely inaccurate. There is more to learn now than ever before, and I find myself spending more and more time teaching myself things that I never before would have been able to find time to understand.
This is just completely inaccurate. There's the same amout of information available as before. It's not like LLMs provide you with information that isn't available anywhere else.
But I agree that it can serve as a tool for a person who it's interested in learning but I bet you that for every such person there's 10x as many who are happy to outsource all their thinking to the machine.
We already have reports from basically every school in the world struggling with this exact problem. Students are just copy pasting LLMs and not really learning.
I'm sorry you've had that experience, and I agree there are a good share of "skeptics" who have latched on to anecdata or outdated experience or theorycrafting. I know it must feel like the goalposts are moving, too, when someone who was against AI on technical grounds last year has now discovered ethical qualms previously unevidenced. I spend a lot of time wondering if I've driven myself to my particular views exclusively out of motivated reasoning. (For what it's worth, I also think "motivated reasoning" is underrated - I am not obligated to kick my own ass out of obligation to "The Truth"!)
That said, I _did_ read your comments history (only because you asked!) and - well, I don't know, you seem very reasonable, but I notice you're upset with people talking about "hallucinations" in code generation from Opus 4.6. Now, I have actually spent some time trying to understand these models (as tool or threat) and that means using them in realistic circumstances. I don't like the "H word" very much, because I am an orthodox Dijkstraist and I hold that anthropomorphizing computers and algorithms is always a mistake. But I will say that like you, I have found that in appropriate context (types, tests) I don't get calls to non-existent functions, etc. However, I have seen: incorrect descriptions of numerical algorithms or their parameters, gaslighting and "failed fix loops" due to missing a "copy the compiled artifact to the testing directory" step, and other things which I consider at least "hallucination-adjacent". I am personally much more concerned about "hallucinations" and bad assumptions smuggled in the explanations provided, choice of algorithms and modeling strategies, etc. because I deal with some fairly subtle domain-specific calculations and (mathematical) models. The should-be domain experts a) aren't always and b) tend to be "enthusiasts" who will implicitly trust the talking genius computer.
For what it's worth, my personal concerns don't entirely overlap the questions I raised way above. I think there are a whole host of reasons people might be reluctant or skeptical, especially given the level of vitriol and FUD being thrown around and the fairly explicit push to automate jobs away. I have a lot of aesthetic objections to the entire LLM-generated corpus, but de gustibus...
Your response is definitely on the top 5% of reasonableness from AI skeptics, so I appreciate that :-)
But, if you don't mind me going on a rant: the hallucinations thing. It kind of drives me nuts, because every day someone trots out hallucinations as some epic dunk that proves that AI will never be used in the real world or whatever. I totally hear you and think you are being a lot more reasonable than most (and thank you for that) -- you are saying that AI can get detail-oriented and fiddly math stuff wrong. But as I, my co-workers, and anyone who seriously uses AI in the industry all know, hallucinations are utterly irrelevant to our day-to-day.
My point is that hallucinations are irrelevant because if you use AI seriously for a while you quickly learn what it hallucinates on and what it does not, you build your mental model, and then you spend all your time on the stuff it doesn't hallucinate on, and it adds a fantastic amount of value there, and you are happy, and you ignore the things it is bad at, because why would you use a tool on things it is bad at? Hearing people talk about hallucinations in 2026 sounds to me like someone saying "a hammer will never succeed - I used it to smack a few screws and it NEVER worked!" And then someone added Hammer-doesnt-work-itis to Wikipedia and it got a few citations in Arxiv now it's all people can say when they talk about hammers online, omfg.
So when you say that I should spend more time asking "what do they see that I don't" - I feel quite confident I already know exactly what you see? You see that AI doesn't work in some domains. I quite agree with you that AI doesn't work in some domains. Why is this a surprise? Until 2023 it worked in no domains at all! There is no tool out there that works in every single domain.
But when you see something new, the much more natural question than "what doesn't this work on" is "what does this work on". Because it does work in a lot of domains, and fabulously well at that. Continuously bringing up how it doesn't work in some domain, when everyone is talking about the domains it does work, is just a non-sequitur, like if someone were to hop into a conversation about Rust and talk about how it can't solve your taxes, or a conversation about CSS to say that it isn't turing complete.
you make it seem like ai hesitation is a misunderstood fringe position, but it's not. i don't think anyone is confused about why some people are uninterested in ai tooling, but we do think you're wrong and the defensive posturing lines in the sand come off as incredibly uncurious.
I simply have no need for these things. I am faster, smarter, and I understand more. I syntesize disparate concepts your SoT models could never dream of. Why should I waste the money? I have all that I need up in my brain.
When everyone forgets how to read, I'll be thriving. When everyone is neurotic from prompting-brain, I will be in my emacs, zen and unburdened.
I love that yall have them though, they are kinda fun to mess with. And as long as I can review and reject it, all yalls little generations are acceptable for now.
> But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"?
I'd argue these are good questions to ask in general, about many topics. That it's an essential skill of an engineer to ask these types of questions.
There's two critical mistake that people often make: 1) thinking there's only one solution to any given problem, and 2) that were there an absolute optima, that they've converged into the optimal region. If you carefully look at many of the problems people routinely argue about you'll find that they often are working under different sets of assumptions. It doesn't matter if it's AI vs non-AI coding (or what mix), Vim vs Emacs vs VSCode, Windows vs Mac vs Linux, or even various political issues (no examples because we all know what will happen if I do, which only illustrates my point). There are no objective answers to these questions, and global optima only have the potential to exist when highly constraining the questions. The assumptions are understood by those you closely with, but that breaks down quickly.
If your objective is to seek truth you have to understand the other side. You have to understand their assumptions and measures. And just like everyone else, these are often not explicitly stated. They're "so obvious" that people might not even know how to explicitly state them!
But if the goal is not to find truth but instead find community, then don't follow this advice. Don't question anything. Just follow and stay in a safe bubble.
We can all talk but it gets confusing. Some people argue to lay out their case and let others attack, seeking truth, updating their views as weaknesses are found. Others are arguing to social signal and strengthen their own beliefs, changing is not an option. And some people argue just because they're addicted to arguing, for the thrill of "winning". Unfortunately these can often look the same, at least from the onset.
Personally, I think this all highlights a challenge with LLMs. One that only exasperates the problem of giving everyone access to all human knowledge. It's difficult you distinguish fact from fiction. I think it's only harder when you have something smooth talking and loves to use jargon. People do their own research all the time and come to wildly wrong conclusions. Not because they didn't try, not because they didn't do hard work, and not because they're specifically dumb; but because it's actually difficult to find truth. It's why you have PhD level domain experts disagree on things in their shared domain. That's usually more nuanced, but that's also at a very high level of expertise.
I am solidly in this "curious" camp. I've read HN for the past 15(?) years. I dropped out of CS and got an art agree instead. My career is elsewhere, but along the way, understanding systems was a hobby.
I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language design, compiler optimization, and open source politics in my free time.
There are many bits of tacit knowledge I don't have. I know I don't have them, because I have that knowledge in other domains. I know that I don't know what I don't know about being a "real engineer."
But I also know what taste is. I know what questions to ask. I know the magic words, and where to look for answers.
For people like me, this feels like an insane golden age. I have no shortage of ideas, and now the only thing I have is a shortage of hands, eyes, and on a good week, tokens.
But that knowledge was never hidden or out of reach. Why not read books, manuals, or take online classes? There is free access to all these things, the only cost is time and energy.
Everyone has tons of ideas. But every good engineer (and scientist) also knows that most of our ideas fall apart when either thinking deeper or trying to implement it (same thing, just mental or not). Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
> Why not read books, manuals, or take online classes? There is free access to all these things, the only cost is time and energy.
Sure, but it's just way faster now. I can get the exact right piece of knowledge I need to advance my understanding on demand, rather than having to spend minutes or hours tracking down the right information, then scanning around the text to filter out all the irrelevant stuff.
There's also a motivational effect: the activation energy of bothering to do this was such that in many domains, it didn't seem worth it.
> Everyone has tons of ideas
Most people have profoundly bad ideas
> Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
Agree, however that's the challenge of this time. Things are becoming less visible. On the other hand, you can implement and get that feedback ten times faster, or point ten minds at stress-testing a concept in 3 minutes. For many of my projects, that's the difference between getting anything done vs idly fantasizing. For others, it could easily be irrelevant.
> The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
I don't think this is a coherent statement. How could you possibly surmount complexity with anything other than better ideas and more hands?
> I can get the exact right piece of knowledge I need to advance my understanding on demand
This is where I disagree. It would be different if these LLMs were acting as instructors and pushing you through courses designed for learning things, but this is more akin to looking at the section of a textbook that contains the exact paragraph you need. Or doing the same thing with a manual. I do not think this is the best way to learn and I actually think it is a good way to perpetuate misunderstandings. There are plenty of bad textbooks and docs, I don't want to dismiss that, but that extra information in the chapter, the previous chapters, or leading up to that paragraph are important. They are designed to be learned in order for a reason. Skipping that other information more often harms you than helps you. It gets you done with a task faster, but doesn't make you learn faster. Two different things. For review, that's different though, but the other knowledge is already there.
I think there's this belief that there are shortcuts to learning. That's a big mistake. You can't learn programming by reading, yet so many people try to do something similar with different domains. It is exactly the same thing that leads people to conspiracy theories. They have such "swiss cheese knowledge" that they don't understand how things actually are connected. How people use LLMs is typically to take the direct route to the information they want, which is only logical, but misses all that other important stuff that you wouldn't know is important to understanding those things until you have mastery of that knowledge.
If there was a shortcut, people would be writing manuals and textbooks very differently. We've been doing it for thousands of years and iterating it for just as long. It's converged to the place it has for a reason.
> Most people have profoundly bad ideas
Yes, and why? One of the most common reasons is people are missing the surrounding context. All those little details. It's exactly what I said before about figuring it out as you go. This is part of why the "doing" matters. Why that stuff that doesn't seem important to the novice actually is, and why experts include it in their teachings.
> you can implement and get that feedback ten times faster,
You can, but you can also dig yourself into a 10x deeper hole 10x faster. The LLM doesn't make you an expert. The LLM doesn't make context appear. I'm sorry, but all that nuance doesn't go away. The LLM only makes it less visible as it does some things for you and every time it does something you don't know how to do you're that much deeper into the water. It's okay to be in a little over your head (that's how we learn) but these tools also make it very easy to get into much deeper waters than you can handle. When that happens, you are unable to do anything and are at the mercy of the LLM. So good luck.
> I don't think this is a coherent statement
Because complexity is complex. There are many different types. Sit with the idea longer, I promise it is coherent. But I'm not going to give you a shortcut. Maybe the LLM will, I'm fairly confident it will be able to figure it out.
Yeah, you're absolutely right. I was just thinking yesterday ... that because the majority of reading I do now is output from chatbots, I'm starting to think and write like a chatbot.
A little terrifying. Probably the solution is to read 19th century literature before bed.
So from my perspective as a professional programmer, my feeling is good on you, like, you're empowered to make things and you're making them. It reminds me of people making PHP sites when the web was young and it was easier to do things.
I think where I get really irritated with the discourse is when people find something that works for them, kinda, and they're like "WELL THIS IS WHAT EVERYONE HAS TO DO NOW!" I wouldn't care if I felt like "oh, just a rando on the internet has a bad opinion", the reason this subject bothers me is words do matter and when enough people are thoughtlessly on the hype train it starts creating a culture shift that creates a lot of harm. And eventually cooler heads prevail, but it can create a lot of problems in the meantime. (Look at the damage crypto did!)
You think you know what taste is. Have you been cranking on real systems all these years, or have you been on the sidelines armchairing the theoretics? I'm not trying to come across as rude, but it may be unavoidable to some degree when indirect criticism becomes involved. A laboring engineer has precious little choice in the type of systems available on which to work on. Fundamentally, it's all going to be some variant of system to make money for someone else somehow, or system that burns money, but ensures necessary work gets done somehow. That's it. That's the extent of the optimization function as defined by capitalism. Taste, falls by the wayside, compared to whether or not you are in the context of the optimizers who matter, because they're at the center of the capital centralization machine making the primary decisions as to where it gets allocated, is all that matters these days. So you make what they want or you don't get paid. As an Arts person, you should understand that no matter how sublime the piece to the artist, a rumbling belly is all that currently awaits you if your taste does not align with the holders of the fattest purses to lighten. I'm not speaking from a place of contempt here; I have a Philosophy background, and reaching out as one individual of the Humanities to another. We've lost sight of the "why we do things" and let ourselves become enslaved by the balance sheets. The economy was supposed to serve the people, it's now the other way around. All we do is feed more bodies to the wood chipper. Until we wake up from that, not even the desperate hope in the matter of taste will save us. We'll just keep following the capital gradient until we end up selling the world from under ourselves because it's the only thing we have left, and there is only the usual suspects as buyers.
You seem to be saying two things. For me, the answer is: I've been somewhere in the middle—working on real projects, sure. I've been employed as a software developer in the past, and I've worked with startups and corporations. I've also worked in academia.
Have I spent years, personally grinding directly in the belly of the beast? No. I managed a small dev team in small startup once. Yeah, it's not the same thing. I know I don't know everything.
Yes, I'm familiar with the critiques of capitalism. I went to art school. Art school is like studying philosophy, but only the social critique parts (for better or worse).
Yes, I'm aware that I'm being ingested by machinery that serves capital. I've read Nick Land.
We're all doing our best to navigate this, but don't forget that poets, mathematicians, artists, and musicians really exist. They contact the cold realities of real life too, and many of them still succeed, still live beautiful lives. And no matter how bad things are, they still write history in the long-run.
Ok fella. But show me something then. This is all talk.
Personally I have been able to produce a very good output with Grok in relation to a video. However, it was insanely painful and very annoying to produce. In retrospect I would've much preferred to have hired humans.
Not to mention I used about 50 free-trial Grok accounts, so who knows what the costs involved were? Tens of thousands no doubt.
I know it's not anyone's fault exactly, but the current state of systems in general is an absolute shit show. If you care about what you do, I'd expect you to be cheering that we just might have an opportunity for a renaissance.
Moreover, this kind of thinking is incredibly backward. If you were better than me then, you can easily become much better than I'll ever be in the future.
But that's the problem. Something that can be so reliable at times, can also fail miserably at others. I've seen this in myself and colleagues of mine, where LLM use leads to faster burnout and higher cognitive load. You're not just coding anymore, you're thinking about what needs to be done, and then reviewing it as if someone else wrote the code.
LLMs are great for rapid prototyping, boilerplate, that kind of thing. I myself use them daily. But the amount of mistakes Claude makes is not negligible in my experience.
This is a fair observation, and I think it actually reinforces the argument. The burnout you're describing comes from treating AI output as "your code that happens to need review." It's not. It's a hypothesis. Once you reframe it that way, the workflow shifts: you invest more in tests, validation scenarios, acceptance criteria, clear specs. Less time writing code, more time defining what correct looks like. That's not extra work on top of engineering. That is the engineering now. The teams I've seen adapt best are the ones that made this shift explicit: the deliverable isn't the code, it's the proof that the code is right.
> I've seen this in myself and colleagues of mine, where LLM use leads to faster burnout and higher cognitive load.
This needs more attention. There's a lot of inhumanity in the modern workplace and modern economy, and that needs to be addressed.
AI is being dumped into the society of 2026, which is about extracting as much wealth as possible for the already-wealthy shareholder class. Any wealth, comfort, or security anyone else gets is basically a glitch that "should" be fixed.
AI is an attempt to fix the glitch of having a well-compensated and comfortable knowledge worker class (which includes software engineers). They'd rather have what few they need running hot and burning out, and a mass of idle people ready to take their place for bottom-dollar.
This is a fair point. The cognitive load is real. Reviewing AI output is a different kind of exhausting than writing code yourself.
Even when the output is "guided," I don't trust it. I still review every single line. Every statement. I need to understand what the hell is going on before it goes anywhere. That's non-negotiable. I think it gets better as you build tighter feedback loops and better testing around it, but I won't pretend it's effortless.
One issue is that developers have been trained for the past few decades to look for solutions to problems online by just dumping a few relevant keywords into Google. But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).
> But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).
That's probably why spec driven development has taken off.
The developers who can't write prompts now get AI to help with their English, and with clarifying their thoughts, so that other AI can help write their code.
You are correct. You absolutely must fill the token space with unanbiguous requirements, or Claude will just get "creative". You don't want the AI to do creative things in the same way you don't want an intern to do the same.
That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.
Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?
> the ability to formulate your thoughts in a clear manner, have become essential skills for engineering
<Insert astronauts meme “Always has been”>
The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.
And
Some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.
Dijkstra (1976-79) On the foolishness of "natural language programming" (EWD 667)
by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. ... I claim that a programmer has only done a decent job when his program is flawless and not when his program is functioning properly only most of the time. But I have had plenty of opportunity to observe that this suggestion is repulsive to many professional programmers: they object to it violently! Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing. In this streamlined age, one of our most under-nourished psychological needs is the craving for Black Magic, and apparently the automatic computer can satisfy this need for the professional software engineers, who are secretly enthralled by the gigantic risks they take in their daring irresponsibility.
Concern for Correctness as a Guiding Principle for Program Composition. (EWD 288)
Things don't seem to have changed, maybe only that we've embraced that black box more than ever. That we've only doubled down on "it works, therefore it's correct" or "it works, that's all that matters". Yet I'll argue that it only works if it's correct. Correct in the way they Dijkstra means, not in sense that it functions (passes tests).
50 years later and we're having the same discussions
Engineers will go back in and fix it when they notice a problem. Or find someone who can. AI will send happy little emoji while it continues to trash your codebase and brings it to a state of total unmaintainability.
I agree on the curiosity part, I have a non CS background but I have learned to program just out of curiosity. This led me to build production applications which companies actually use and this is before the AI era.
Now, with AI I feel like I have an assistant engineer with me who can help me build exciting things.
I'm currently teaching a group of very curious non-technical content creators at one of the firms I consult at. I set up Codex for them, created the repo to have lots of hand-holding built in - and they took off. It's been 4 weeks and we already have 3 internal tools deployed, one of which eliminated the busy work of another team so much that they now have twice the capacity. These are all things 'real' engineers and product managers could have done, but just empowering people to solve their own problems is way faster. Today, several of them came to me and asked me to explain what APIs are (They want to use the google workspace APIs for something)
I wrote out a list of topics/key words to ask AI about and teach themselves. I've already set up the integration in an example app I will give them, and I literally have no idea what they are going to build next, but I'm .. thrilled. Today was the first moment I realized, maybe these are the junior engineers of the future. The fact that they have nontechnical backgrounds is a huge bonus - one has a PhD in Biology, one a masters in writing - they bring so much to the process that a typical engineering team lacks. Thinking of writing up this case study/experience because it's been a highlight of my career.
> But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
Your experience is the exact opposite of mine. I have people constantly telling me how LLMs are perfectly one shotting things. I see it from friend groups, coworkers, and even here on HN. It's also what the big tech companies are often saying too.
I'm sorry, but to say that nobody is talking about success and just concentrating on failure is entirely disingenuous. You claim the group is a minority, yet all evidence points otherwise. The LLM companies wouldn't be so successful if people didn't believe it was useful.
The K-shaped workforce point is sharp and I think you're right. The curious ones are a minority, but they've always been the ones who moved things forward. AI just made the gap more visible :)
Your Codex case study with the content creators is fascinating. A PhD in Biology and a masters in writing building internal tools... that's exactly the kind of thing i meant by "you can learn anything now." I'm surrounded by PhDs and professors at my workplace and I'm genuinely positive about how things are progressing. These are people with deep domain expertise who can now build the tools they need. It's an interesting time. please write that up...
This is my experience too. Also, the ones not striving for simplicity and not architecting end up with giant monsters that are very unstable and very difficult to update or make robust. They usually then look for another engineer to solve their mess. Usually, the easy way for the new engineer is just to architect and then turbo-build with Claude Code. But they are stuck in sunk cost prison with their mess and can't let it go :(
I have LLMs write code all day almost every day and these days I really haven't seen this happen. The odd thing here and there (e.g. LLM finds two instances of the same error path in code, decides to emit a log message in one place and throw an exception in the other place) but nothing just plain out wrong recently.
Maybe. The reality of software engineering is that there's a lot of mediocre developers on the market and a lot of mediocre code being written; that's part of the industry, and the jobs of engineers working with other engineers and/or LLMs is that of quality control, through e.g. static analysis, code reviews, teaching, studying, etc.
And those mediocre engineers put their work online, as do top-tier developers. In fact, I would say that the scale is likely tilted towards mediocre engineers putting more stuff online than really good ones.
So statistically speaking, when the "AI" consumes all of that as its training data and returns the most likely answer when prompted, what percentage of developers will it be better than?
That's not how modern LLMs are built. The days of dumping everything on the internet into the training data and crossing your fingers are long past.
Anthropic and OpenAI spent most of 2025 focusing almost expensively on improving the coding abilities of their models, through reinforcement learning combined with additional expert curation of training data.
Have you seen how many people are talking about the November 2025 inflection point, where the models ticked over from being good at running coding agents to being really good at it?
Doubt it”s sustainable. These big models keep improving at a fast pace and any progress like this made in a niche would likely get caught up to very quickly.
The "most engineers" not "most engineers we've hired".
But also "most engineers" aren't very good. AIs know tricks that the average "I write code for my dayjob" person doesn't know or frankly won't bother to learn.
Even speaking from a pure statistical perspective, it is quite literally impossible for "AI" that outputs world's-most-average-answer to be better than "most engineers".
In fact, it's pretty easy to conclude what percentage of engineers it's better than: all it does is it consumes as much data as possible and returns the statistically most probable answer, therefore it's gonna be better than roughly 50% of engineers. Maybe you can claim that it's better than 60% of engineers because bottom-of-the-barrel engineers tend to not publish their works online for it to be used as training data, but for every one of those you have a bunch of non-engineers that don't do this for a living putting their shitty attempts at getting stuff done using code online, so I'm actually gonna correct myself immediately and say that it's about 40%.
The same goes for every other output: it's gonna make the world's most average article, the most average song in a genre and so on. You can nudge it to be slightly better than the average with great effort, but no, you absolutely cannot make it better than most.
Which indicates something unknown. Code quality evaluations in training. Do you know if there is any sort of code quality evaluation for the training data? I think the argument is a little reductive without knowing the actual details of the model training input pipeline and the stages of generating the output on that same dimension, but I don't really have any concrete knowledge here either, so your baseline assumption could be right.
The thing that separates AI Agents from normal programmers is that agents don't get bored or tired.
For most engineers the ability might be there, but the motivation or willingness to write, for example, 20 different test cases checking the 3 line bug you just fixed is fixed FOR SURE usually isn't there. You add maybe 1-2 tests because they're annoying boilerplate crap to write and create the PR. CI passes, you added new tests, someone will approve it. (Yes, your specific company is of course better than this and requires rigorous testing, but the vast majority isn't. Most don't even add the two tests as long as the issue is fixed.)
An AI Agent will happily and without complaining use Red/Green TDD on the issue, create the 20 tests first, make sure they fail (as they should), fix the issue and then again check that all tests pass. And it'll do it in 30 minutes while you do something else.
The kid can learn and become better over time, while "AI" can only be retrained using better training data.
I'm not against using AI by any means, but I know what to use it for: for stuff where I can only do a worse than half the population because I can't be bothered to learn it properly. I don't want to toot my own horn, but I'd say I'm definitely better at my niche than 50% of the people. There are plenty of other niches where I'm not.
The AI doesn't know what good or bad code is. It doesn't know what surpassing someone means. It's been trained to generate text similar to its training data, and that's what it does.
If you feed it only good code, we'd expect a better result, but currently we're feeding it average code. The cost to evaluate code quality for the huge data set is too high.
The training data includes plenty of examples of labelled good and bad code. And comparisons between two implementations plus trade-offs and costs and benefits. I think it absolutely does "know" good code, in the sense that it can know anything at all.
There does exist some text making comparisons like that, but compared to the raw quantity of totally unlabeled code out there, it's tiny.
You can do some basic checks like "does it actually compile", but for the most part you'd really need to go out and do manual categorization, which would be brutally expensive.
> Maybe you can claim that it's better than 60% of engineers because bottom-of-the-barrel engineers tend to not publish their works online for it to be used as training data, but for every one of those you have a bunch of non-engineers that don't do this for a living putting their shitty attempts at getting stuff done using code online, so I'm actually gonna correct myself immediately and say that it's about 40%.
And there are a bunch of engineers from certain cultures who don't know what they don't know, but believe that a massive portfolio of slop is better than one or two well-developed projects.
I can only hope that the people training the good coding models know to tell AI that these are antipatterns, not patterns.
>> Even speaking from a pure statistical perspective, it is quite literally impossible for "AI" that outputs world's-most-average-answer to be better than "most engineers". In fact, it's pretty easy to conclude what percentage of engineers it's better than: all it does is it consumes as much data as possible and returns the statistically most probable answer
Yeah, you come across as someone who thinks that the AI simply spits out the average of the code in its training data. I don't think that understanding is accurate, to say the least.
>But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
Are you serious? I've been hearing this constantly. since mid 2025.
The gaslighting over AI is really something else.
Ive also never seen jobs advertised before whose job was to lobby skeptical engineers over about how to engage in technical work. This is entirely new. There is a priesthood developing over this.
I wrote code by hand for 20 years. Now I use AI for nearly all code. I just can’t compete in speed and thoroughness. As the post says, you must guide the AI still. But if you think you can continue working without AI in a competitive industry, I am absolutely sure you will eventually have a very bad time.
I certainly know engineers for which this is true but unfortunately they were never particularly thorough or fast to begin with.
I believe you can tell which way the wind is blowing by looking at open source.
Other than being flooded with PRs high profile projects have not seen a notable difference - certainly no accelerated enhancements. there has definitely been an explosion of new projects, though, most of dubious quality.
They will never admit it, but many are scared of losing their jobs.
This threat, while not yet realized, is very real from a strictly economic perspective.
AI or not, any tool that improves productivity can lead to workforce reduction.
Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
You have a choice: fire 5 people, or produce 2,000 loaves per month. But does the city really need that many loaves?
To make matters worse, all your competitors also have the same semi-automatic ovens...
> Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
That is actually the case with a lot of bakeries these days. But the one major difference being,the baker can rely with almost 100% reliability that the form, shape and ingredients used will be exact to the rounding error. Each time. No matter how many times they use the oven. And they don't have to invent strategies on how to "best use the ovens", they don't claim to "vibe-bake" 10x more than what they used to bake before etc... The semi-automated ovens just effing work!
Now show me an LLM that even remotely provides this kind of experience.
Eh accuracy and reliability is a different topic hashed out many times on HN. This thread is about productivity. I’m a staff engineer and I don’t know a single person not using AI. My senior engineers are estimating 40% gains in productivity.
A bit simplistic. The bakery can just expand its product range or do various other things to add work. In fact that's exactly what I would expect to happen at a tech company, ceteris paribus.
This is what I find interesting - the response from most companies is "we will need fewer engineers because of AI", not "we can build more things because of AI".
What is driving companies to want to get rid of people, rather than do more? Is it just short-term investor-driven thinking?
I think it's an excuse to do needed lay offs without saying as much. So yes, preserving signals, essentially. I've never met a tech company that didn't love expanding work to fill capacity, even if the work is of little value.
How much more productive are we supposed to be in engineering? Are we 10x'ing our testing capability at the same time? QA is already a massive bottleneck at my $DAYJOB. I'm not sure what benefits the company at-large derives from having the typing machine type faster.
Perhaps this is one of the understanding gaps that crop up around AI development? At my current company and most others I've worked at, testing capability is part of the same bucket because engineers do their own QA.
Two loaves of bread off the same line are perfect substitutes for each other, and compete to be sold.
Lines of code within the same code base aren't competing to be sold. They either complement each other by adding new features, making the actual product sold more valuable, or one replaces another to make a feature more desirable- look better, work faster, etc.
The market grows if you add new features- your bread now doubles as a floatation device- or you introduce a new line of bread with nuts and berries.
So, the business has to decide- does it fire some workers and pocket the difference until someone else undercuts them, or does it keep the workers and grow the market it can sell to faster?
Adding new features doesn't necessarily grow the market. Your bread with nuts and berries competes with the regular bread for the customer's money. Other things also compete for the same money, such as medical, daycare, schooling etc. So increasing features won't necessarily grow the market because the market. Even in an optimistic scenario, those features only have a probability of increasing revenue, it's not certain.
OTOH, if you fire those workers, it is a certainty that your bakery gets more cash. You can then use that cash to reward your shareholders (a category that conveniently includes you) via buybacks or dividends.
Read the comment I replied to to see where the bread came from.
But on your point (which seems to hinge on wish thinking), this infinity of new features you propose for every product still needs those new markets you take for granted to justify their inclusion in the product. However cornering a new market isn't as straightforward as deploying a new feature - we all wish it was. The tech that makes it trivial for one firm to develop these features, makes it trivial for everyone else to build them. This means any new market will be immediately saturated.
Even if the leap of finding new markets was as easy as you think, you still need to explain why this hypothetical company would keep paying millions in avoidable salaries. Because whatever jobs you assign to AI, it won't be any less available to do the work of the human labor.
On another note, if you had 100 engineers and you lay almost all of them off and keep 5 super-AI-accelerated engineers, and your competitor keeps 50 of such engineers, your competitor is still able to iterate 10x as fast. So you still lay people off at the risk of falling behind.
I'm starting to think for software it's produce 2,000 loaves per month. I'm realizing now software was supply-constrained and organizations had to be very strategic about what apps/UIs to build. Now everything and anything can be an app and so we can build more targeted frontends for all kinds of business units that would've been overlooked before.
Writing software isn't like a small bakery with fixed demand. There are always more features to build and improvements to do than capacity allows. For better or worse software products are never finished.
"You can learn anything now. I mean anything." This was true before before LLMs. What's changed is how much work it is to get an "answer". If the LLM hands you that answer, you've foregone learning that you might otherwise have gotten by (painfully) working out the answer yourself. There is a trade-off: getting an answer now versus learning for the future. I recently used an LLM to translate a Linux program to Windows because I wanted the program Right Now and decided that was more important than learning those Windows APIs. But I did give up a learning opportunity.
I'm conflicted about this. On one hand, I think LLMs make it easier to discover explanations that, at least superficially, superficially "click" for you. Sure, they were available before, but maybe in textbooks you needed to pay for (how quaint), or on websites that appeared on the fifth page of search results. Whatever are the externalities of that, in the short term, that part may be a net positive for learners.
On the other hand, learning is doing; if it's not at least a tiny bit hard, it's probably not learning. This is not strictly an LLM problem; it's the same issue I have with YouTube educators. You can watch dazzling visualizations of problems in mathematics or physics, and it feels like you're learning, but you're probably not walking away from that any wiser because you have not flexed any problem-solving muscles and have not built that muscle memory.
I had multiple interactions like that. Someone asked an LLM for an ELI5 and tried to leverage that in a conversation, and... the abstraction they came back feels profound to them, but is useless and wrong.
This. I feel this all the time. I love 3Blue1Brown's videos and when I watch them I feel like I really get a concept. But I don't retain it as well as I do things I learned in school.
It's possible my brain is not as elastic now in my 40s. Or maybe there's no substitute for doing something yourself (practice problems) and that's the missing part.
One factor in favor of the use of LLM as a learning tool is the poor quality of documentation. It seems we've forgotten how to write usable explanations that help readers to build a coherent model of the topic at hand.
> On one hand, I think LLMs make it easier to discover explanations that, at least superficially, superficially "click" for you.
The other benefit is that LLMs, for superficial topics, are the most patient teachers ever.
I can ask it to explain a concept multiple times, hoping that it'll eventually click for me, and not be worried that I'd look stupid, or that it'll be annoyed or lose patience.
It always comes down to economics and then the person and their attitude towards themselves.
Some things are worth learning deeply, in other cases the easy / fast solution is what the situation calls for.
I've thought recently that some kinds of 'learning' with AI are not really that different from using Cliffs Notes back in the day. Sometimes getting the Cliffs Notes summary was the way to get a paper done OR a way to quickly get through a boring/challenging book (Scarlet Letter, amirite?). And in some cases reading the summary is actually better than the book itself.
BUT - I think everyone could agree that if you ONLY read Cliffs Notes, you're just cheating yourself out of an education.
That's a different and deeper issue because some people simply do not care to invest in themselves. They want to do minimum work for maximum money and then go "enjoy themselves."
Getting a person to take an interest in themselves, in their own growth and development, to invite curiosity, that's a timeless problem.
So I've actually been putting more effort into deliberate practice since I started using AI in programming.
I've been a fan of Zed Shaw's method for years, of typing out interesting programs by hand. But I've been appreciating it even more now, as a way to stave off the feeling of my brain melting :)
The gross feeling I have if I go for too long without doing cardio, is a similar feeling to when I go for too long without actually writing a substantial amount of code myself.
I think that the feeling of making a sustained effort is itself something necessary and healthy, and rapidly disappearing from the world.
I’ve always like the essential/accidental complexity split. It can be hard to find, but for a problem solving perspective, it may defines what’s fun and what’s a chore.
I’ve been reading the OpenBSD lately and it’s quite nice how they’ve split the general OS concepts from the machine dependent needs. And the general way they’ve separated interfaces and implementation.
I believe that once you’ve solve the essential problem, the rest becomes way easier as you got a direction. But doing accidental problem solving without having done the essential one is pure misery.
That's not what the author means. Multiple times a day, I have conversations with LLMs about specific code or general technologies. It is very similar to having the same conversation with a colleague. Yes, the LLM may be wrong. Which is why I'm constantly looking at the code myself to see if the explanation makes sense, or finding external docs to see if the concepts check out.
Importantly, the LLM is not writing code for me. It's explaining things, and I'm coming away with verifiable facts and conceptual frameworks I can apply to my work.
Yeah, it's a great way for me to reduce activation energy to get started on a specific topic. Certainly doesn't get me all the way home, but cracks it open enough to get started.
I've managed to go my whole career using regex and never fully grokking it, and now I finally feel free to never learn!
I've also wanted to play with C and Raylib for a long time and now I'm confident in coding by hand and struggling with it, I just use LLMs as a backstop for when I get frustrated, like a TA during lab hours.
If you're going to deploy what you make with them to production without accidentally blowing your feet off, 100%, be they RegExp or useEffect(), if you can't even tell which way the gun is pointing how are you supposed to know which way the LLM has oriented it?
Picking useEffect() as my second example because it took down CloudFlare, and if you see one with a tell-tale LLM comment attached to it in a PR from your coworkers who are now _never_ going to learn how it works, you can almost be certain it's either unnecessary or buggy.
For things Im working on seriously for my work, for sure, I spend time understanding them, and LLMs help with that. I suppose, also having experience Im already prone to asking questions about things I have a suspicion can go wrong
But there is also a ton of times something isnt at all important to me and I dont want to waste 3 hours on
I am beginning to disagree with this, or at least I am beginning to question its universal truth. For instance, there are so many times when "learning" is an exercise at attempting to apply wrong advice many times until something finally succeeds.
For instance, retrieving the absolute path an Angular app is running at in a way that is safe both on the client and in SSR contexts has a very clear answer, but there are a myriad of wrong ways people accomplish that task before they stumble upon the Location injectable.
In cases like the above, the LLM is often able to tell you not only the correct answer the first time (which means a lot less "noise" in the process trying to teach you wrong things) but also is often able to explain how the answer applies in a way that teaches me something I'd never have learned otherwise.
We have spent the last 3 decades refining what it means to "learn" into buckets that held a lot of truth as long as the search engine was our interface to learning (and before that, reading textbooks). Some of this rhetoric begins to sound like "seniority" at a union job or some similar form of gatekeeping.
That said, there are also absolutely times (and sometimes it's not always clear that a particular example is one of those times!!) when learning something the "long" way builds our long term/muscle memory or expands our understanding in a valuable way.
And this is where using LLMs is still a difficult choice for me. I think it's less difficult a choice for those with more experience, since we can more confidently distinguish between the two, but I no longer think learning/accomplishing things via the LLM is always a self-damaging route.
Is this maybe more about the quality of the documentation? I say this 'cause my thinking is that reading is reading, it takes the same time to read the information.
How is this faster than just reading the documentation? Given that LLMs hallucinate, you have to double check everything it says against the docs anyway
I learn fastest from the examples, from application of the skill/knowledge - with explanations.
AIs allowed me to get on with Python MUCH faster than I was doing myself, and understand more of the arcane secrets of jq in 6 months than I was able in few years before.
And AIs mistakes are brilliant opportunity to debug, to analyse, and to go back to it saying "I beg you pardon, wth is this" :) pointing at the elementary mistakes you now see because you understand the flow better.
Recently I had a fantastic back and forth with Claude and one of my precious tools written in python - I was trying to understand the specifics of the particular function's behaviour, discussing typing, arguing about trade-offs and portability. The thing I really like in it that I always get a pushback or things to consider if I come up with something stupid.
It's a tailored team exercise and I'm enjoying it.
Human teachers make mistakes too. If you aren't consuming information with a skeptical eye you're not learning as effectively as you could be no matter what the source is.
The trick to learning with LLMs is to treat them as one of multiple sources of information, and work with those sources to build your own robust mental of how things work.
If you exclusively rely on official documentation you'll miss out on things that the documentation doesn't cover.
If I have to treat LLMs as a fallible source of information, why wouldn't I just go right to the source though? Having an extra step in between me and the actual truth seems pointless
If the WinAPI docs are solid you can do things like copy and paste pages of them into Claude and ask a question, rather then manually scan through them looking for the answer yourself.
Apple's developer documentation is mostly awful - try finding out how to use the sips or sandbox-exec CLI tools for example. LLMs have unlocked those for me.
If you're good at programming you can usually tell exactly why it worked or didn't work. That's how we've all worked before coding agents came along too - you don't blindly assume the snippet you pasted off StackOverflow will work, you try it and poke at it and use it to build a firm mental model of whether it's the right thing or not.
Sure. A big part of how I'd know that the function I'm calling does what I think it does, is by reading the source documentation associated with it
Does it have any threading preconditions? Any weird quirks? Any strange UB? That's stuff you can't find out just by testing. You can ask the LLM, but then you have to read the docs anyway to check its answer
Except you have no idea if what the LLM is telling you is true
I do a lot of astrophysics. Universally LLMs are wrong about nearly every astrophysics questions I've asked them - even the basic ones, in every model I've ever tested. Its terrifying that people take these at face value
For research at a PhD level, they have absolutely no idea what's going on. They just make up plausible sounding rubbish
Astrophysicist David Kipping had a podcast episode a month ago reporting that LLMs are working shockingly well for him, as well as for the faculty at the IAS.[1]
It's curious how different people come to very different conclusions about the usefulness of LLMs.
The answer it gave was totally wrong. Its not a hard question. I asked it this question again today, and some of it was right (!). This is such a low bar for basic questions
Bam, that's the single source of truth right there. Microsoft's docs are pretty great
If I use an LLM, I have to ask it for the documentation about "GetQueuedCompletionStatus". Then I have to double check its output, because LLMs hallaucinate
Doubly checking its output involves googling "GetQueuedCompletionStatus", finding this page:
I have not done win32 programming in 12 years. Maybe you've done it more recently. I'll use an LLM and you look up things manually. We can see, who can build a win32 admin UI that shows a realtime view of every open file by process with sorting, filtering and search on both the files and process/command names.
I estimate this will take me 5 minutes
Would you like to race?
This mentality is fundamentally why I think AI is not that useful, it completely underscores everything that's wrong with software engineering and what makes a very poor quality senior developer
I'll write an application without AI that has to be maintained for 5 years with an ever evolving featureset, and you can write your own with AI, and see which codebase is easiest to maintain, the most productive to add new features to, and has the fewest bugs and best performance
Sure let's do it. I am pretty confident mine will be more maintainable, because I am an extremely good software engineer, AI is a powerful tool, and I use AI very effectively
I would literally claim that with AI I can work faster and produce higher quality output than any other software engineer who is not using AI. Soon that will be true for all software engineers using AI.
Why does it matter? We have table of contents, index and references for books and other contents. That’s a lot of navigational aid. Also they help in providing you a general overview of the domain.
I don't know, most shit I learned programming (and subsequently get paid for) is meaningless arcana. For example, Kubernetes. And for you, it's Windows APIs.
For programming in general, most learning is worthless. This is where I disagree with you. If you belong to a certain set of cultures, you overindex on this idea that math (for example) is the best way to solve problems, that you must learn all this stuff by this certain pedagogy, and that the people who are best at this are the best at solving problems, which of course is not true. This is why we have politics, and why we have great politicians who hail from cultures that are underrepresented in high levels of math study, because getting elected and having popular ideas and convincing people is the best way to solve way more problems people actually have than math. This isn't to say that procedural thinking isn't valuable. It's just that, well, jokes on you. ChatGPT will lose elections. But you can have it do procedural thinking pretty well, and what does the learning and economic order look like now? I reject this form of generalization, but there is tremendous schadenfreude about, well the math people are destroying their own relevance.
All that said, my actual expertise, people don't pay for. Nobody pays for good game design or art direction (my field). They pay because you know Unity and they don't. They can't tell (and do not pay for) the difference between a good and bad game.
Another way of stating this for the average CRUD developer is, most enterprise IT projects fail, so yeah, the learning didn't really matter anyway. It's not useful to learn how to deliver better failed enterprise IT project, other than to make money.
One more POV: the effortlessness of agentic programming makes me more sympathetic to anti intellectualism. Most people do not want to learn anything, including people at fancy colleges, including your bosses and your customers, though many fewer in the academic category than say in the corporate world. If you told me, a chatbot could achieve in hours what would take a world expert days or weeks, I would wisely spend more time playing with my kids and just wait. The waiters are winning. Even in game development (cultural product development generally). It's better to wait for these tools to get more powerful than to learn meaningless arcana.
> But no amount of politics and charisma will calculate the motions of the planets or put satellites in orbit.
the government invented computers. you need politics to fund all of this. you are talking about triumphs of politics as much as invention. i don't know why you think i am pro influencer or charlatan...
I do disagree with the notion that you have to slog through a problem to learn efficiently. That it's either "the easy way [bad, you dont learn] or the hard way [good you do learn]" is a false dichotomy. Agents / LLMs are like having an always-on, highly adept teacher who can synthesize information in an intuitive way, and that you can explore a topic with. That's extremely efficient and effective for learning. There is maybe a tradeoff somewhat in some things, but this idea that LLMs make you not learn doesn't feel right; they allow you to learn _as much as you want and about the things that you want_, which wasn't before. You had to learn, inefficiently(!), a bunch of crap you didn't want to in order to learn the thing you _did_ want to. I will not miss those days.
I don't think your saying the same thing. Ai can help you get through the hard stuff effeciently and you'll learn. It acts as a guide, but you still do the work.
Offloading completely the hard work and just getting a summary isn't really learning.
It’s kind of funny seeing all the AI hype guys talking about their 10 OpenClaw instances all running doing work and when you ask what it is, you can never get a straight answer..
For the record though, I love agentic coding. It deals with the accumulated cruft of software for me.
If execution no longer matters, then what possible ideas exist out there that both are highly valuable as well as only valuable to the first mover? If the second person to see the value in the idea can execute it in a weekend using AI tools, what value is there in the idea to begin with?
In fact the second mover advantage seems to me to be even larger than before. Let someone else get the first version out the door, then you just point your AI bot at the resulting product to copy it in a fraction of the time it took the original person to execute on it.
If anything, ideas seem to be even cheaper to me in this new world. It probably just moves what bits of execution matter even more towards sales and marketing and hype vs. executing on the actual product itself.
I think there might be some interesting spaces here opening up in the IP combined with "physical product" space. Where you need the idea as well as real-world practical manufacturing skills in order to execute. That will still be somewhat of a moat for a little while at least, but mostly at a scale where it's not worth an actual manufacturer from China to spin up a production line to compete with you at scale.
While that’s theoretically correct, as soon as your idea is a product, that’s done deal now everyone can just execute at a stupid speed.
You might get head start but just like a bicycle race the one behind you will be more efficient because you already solved the domain problems and figured out the UX.
Eventually you will have to tell people what the idea is, even if it is at product launch. And then, if execution is as cheap and easy as they claim, then anyone can replicate the idea without having to engage with the person in the first place.
Fair enough. I know how that reads. But when anyone with a laptop and a subscription can ship production software in a weekend, the architecture and the idea start to matter a lot more. The technical details in the post are real. I just can't share the what yet. Take it or leave it.
This has been a fallacy for as long as businesses have been built, and it will still be a fallacy in the AI era.
Ideas are cheap and don't need to be protected. Your taste, execution, marketing, UX, support, and all the 1000 things that aren't the code still matter. The code will appear more quickly now: You still need to get people to use it or care about it.
I've found almost without fail that you have more to gain in sharing an idea and getting feedback (both positive and negative) before/while you build the thing than you do in protecting the idea with the fear that as soon as someone hears it they'll steal it and do it better than you.
(The exception I think is in highly competitive spaces where ideas have only a short lifetime -- eg High Frequency Trading / Wall Street in general. An idea for a trade can be worth $$ if done before someone else figures it out, and then it makes sense to protect the idea so you can make use of it first. But that's an extremely narrow domain.)
I understand your concern. The copycat problem is real.
But if you come from a technical background and this is your first time building a product, you'll soon learn that it is so damn hard to get users, especially *paying* ones.
I was there. I built something, shared it, prayed people would notice. The truth is most of the time your product fails. Better explore the problem you are trying to solve first, share your idea if necessary, and collect feedback. You'll have a much clearer picture of what you need to do from there.
I've heard this a thousand times and I have not once seen a person give an example of this actually happening. I'm more likely to believe the crocodiles coming out of sewer pipes urban legend at this point.
I don't think it's about ideas or even the code. It's about execution, marketing, talking to your customers and doing sales. This is something AI can't do...yet
I am running local offline small models in the old fashioned REPL style, without any agentic features. One prompt at a time.
Instead of asking for answers, I ask for specific files to read or specific command line tools with specific options. I pipe the results to a file and then load it into the CLI session. Then I turn these commands into my own scripts and documentation (in Makefile).
I forbid the model wandering around to give me tons of irrelevant markdown text or generated scripts.
I ask straight questions and look for straight answers.
One line at a time, one file at a time.
This gives me plenty of room to think what I want and how I get what I want.
Learning what we want and what we need to do to achieve it is the precious learning experience that we don’t want to offload to the machine.
> I ask straight questions and look for straight answers. One line at a time, one file at a time.
I've also taken to using the Socratic Method when interrogating an LLM. No loaded questions, squeaky clean session/context, no language that is easy to misinterpret. This has worked well for me. The information I need is in there, I just need to coax it back out.
I did exactly this for an exercise a while back. I wanted to learn Rust while coding a project and AI was invaluable for accelerating my learning. I needed to know completely off-the-wall things that involved translating idioms and practices from other languages. I also needed to know more about Rust idoms to solve specific problems and coding patterns. So I carefully asked these things, one at a time, rather than have it write the solution for me. I saved weeks if not months on that activity, and I'm at least dangerous at Rust now (still learning).
This. I'm also using an LLM very similarly and treat it like a knowledgeable co-worker I can ask for an advice or check something. I want to be the one applying changes to my codebase and then running the tests. Ok, agents may improve the efficiency but it's a slippery slope. I don't want to sit here all day watching the agents modify and re-modify my codebase, I want to do this myself because it's still fun though not as much fun as it was pre-AI
I'm glad I am no longer in tech because I just don't want to do this.
This is not a dig at AI. If I take this article at face value, AI makes people more productive, assuming they have the taste and knowledge to steer their agents properly. And that's possibly a good thing even though it might have temporary negative side effects for the economy.
>But the AI is writing the traversal logic, the hashing layers, the watcher loops,
But unfortunately that's the stuff I like doing. And also I like communing with the computer: I don't want to delegate that to an agent (of course, like many engineers I put more and more layers between me and the computer, going from assembly to C to Java to Scala, but this seems like a bigger leap).
I'm a developer who was made redundant, and I'm now casting around for an entirely new job because, likewise, I have no interest in working with AI. It sounds boring, and the concept squicks me out, to be honest.
as of this moment I
officially resigned from my job as
software engineer and will take up work
on the farm shoveling pig shit and
administering anal suppositories to sick
horses because that will be a thousand
times more tolerable than being in the
same industry as dipshits like you
I work in tech, and I think the worst part is seeing all the pieces of catastrophe that have had to come together to make AI dominate
There's several factors which are super depressing:
1. Economic productivity, and what it means for a company to be successful have become detached from producing good high quality products. The stock market is the endgame now
2. AI is attempting to strongly reject the notion that developers understanding their code is good. This is objectively wrong, but its an intangible skill that makes developers hard to replace, which is why management is so desperate for it
3. Developers had too much individual power, and AI feels like a modern attempt at busting the power of the workforce rather than a genuine attempt at a productivity increase
4. It has always been possible to trade long term productivity for short term gains. Being a senior developer means understanding this tradeoff, and resisting management pressure to push something out NOW that will screw you over later
5. The only way AI saves time in the long term is if you don't review its output to understand it as well as if you'd written it yourself. Understanding the code, and the large scale architecture is critical. Its a negative time savings if you want to write high-long-term-productivity code, because we've introduced an extra step
6. Many developers simply do not care about writing good code unfortunately, you just crank out any ol' crap. As long as you don't get fired, you're doing your job well enough. Who cares about making a product anymore, it doesn't matter. AI lets you do a bad job with much less effort than before
7. None of this is working. AI is not causing projects to get pushed out faster. There are no good high quality AI projects. The quality of code is going down, not up. Open source software is getting screwed
Its an extension of the culture where performance doesn't matter. Windows is all made of react components which are each individually a web browser, because the quality of the end product no longer matters anymore. Software just becomes shittier, because none of these companies actually care about their products. AAA gaming is a good example of this, as is windows, discord, anything google makes, IBM, Intel, AMD's software etc
A lot of this is a US problem, because of the economic conditions over there and the prevalence of insane venture capitalism and union busting. I have a feeling that as the EU gets more independent and starts to become a software competitor, the US tech market is going to absolutely implode
Right now I'm working two AI-jobs. I build agents for enterprises and I teach agent development at a university. So I'm probably too deep to see straight.
But I think the future of programming is english.
Agent frameworks are converging on a small set of core concepts: prompts, tools, RAG, agent-as-tool, agent handoff, and state/runcontext (an LLM-invisible KV store for sharing state across tools, sub-agents, and prompt templates).
These primitives, by themselves, can cover most low-UX application business use cases. And once your tooling can be one-shotted by a coding agent, you stop writing code entirely. The job becomes naming, describing, and instructing and then wiring those pieces together with something more akin to flow-chart programming.
So I think for most application development, the kind where you're solving a specific business problem, code stops being the relevant abstraction. Even Claude Code will feel too low-level for the median developer.
You think prompting is here to stay? Sql has survived a long period of time. Servlets haven’t. We moved from assembly to higher languages. Flash couldn’t make it. So, im not sure for how long we will be prompting. Sure it looks great right now (just like Flash, servlets and assembly looked back then) but I think another technology will emerge that perhaps is based on promps behind the curtains but doesn’t look like the current prompting.
I would say prompting is not here to stay. It’s just temporary “tech”
Eventually we might even develop some kind of language beyond english. One more precise and formalized. This way the LLM could perfectly understand what we're saying. The LLM could produce code based on that formalized language. And Google docs is nice, but imagine some kind of editor tailored to that formalized language we create.
> The job becomes naming, describing, and instructing and then wiring those pieces together with something more akin to flow-chart programming.
That's precisely what peoples are bad at. If people don't grasp (even intuitively) the concept of finite state machine and the difference between states and logic, LLMs are more like a wishing well (vibes) than a code generator (tooling for engineering).
Then there's the matter of technical knowledge. Software is layers of abstraction and there's already abstraction beneath. Not knowing those will limit your problem solving capabilities.
Strangely we never hear gushing pieces on how great gcc is. If you have to advertise that much or recruit people with AI mania, perhaps your product isn't that great.
"But guided? The models can write better code than most developers. " <- THIS PART! I get that "senior" developers feel a certain kind of way about it but the truth is that AI really DOES write better code than most developers. I'm not saying ALL developers but AI (at least in my experience with Claude) does the "coding" part much better. They might not be ready to get it perfect yet but they're getting closer every couple of months. It won't be long now. This scares people. I prefer to embrace this AI movement. There is no stopping it no matter how much people complain about it. We all know that. What I'm realizing is that instead of spending all that time actually WRITING the code I have more time to THINK about what I want to do. It reduces the cognitive load :)
> But guided? The models can write better code than most developers. That’s the part people don’t want to sit with. When guided.
Where do you draw the line between just enough guidance vs too much hand holding to an agent? At some point, wouldn't it be better to just do it yourself and be done with the project (while also build your muscle memory, experiences and the mental model for future projects, just like tons of regular devs have done in the past)
I'm not asking an agent to build me a full-stack app. That's where you end up babysitting it like a kindergartener and honestly you'd be faster doing it yourself. The way I use agents is focused, context-driven, one small task at a time.
For example: i need a function that takes a dependency graph, topologically sorts it, and returns the affected nodes when a given node changes. That's well-scoped. The agent writes it, I review it, done.
But say I'm debugging a connection pool leak in Postgres where connections aren't being released back under load because a transaction is left open inside a retry loop. I'm not handing that to an agent. I already know our system. I know which service is misbehaving, I know the ORM layer, I know where the connection lifecycle is managed. The context needed to guide the agent properly would take longer to write than just opening the code and tracing it myself.
That's the line. If the context you'd need to provide is larger than the task itself, just do it. If the task is well-defined and the output is easy to verify, let the agent rip.
The muscle memory point is real though. i still hand-write code when I'm learning something new or exploring a space I don't understand yet. AI is terrible for building intuition in unfamiliar territory because you can't evaluate output you don't understand. But for mundane scaffolding, boilerplate, things that repeat? I don't. llife's too short to hand-write your 50th REST handler.
The issue is that you become lazy after a while and stop “leading the design”. And I think that’s ok because most of the code is just throwaway code.
You would rewrite your project/app several times by the time it’s worth it to pay attention to “proper” architecture. I wish I had these AIs 10 years ago so that I could focus on everything I wanted to build instead to become a framework developer/engineer.
I agree. I've got more lazy over time too. But the cost of creating code is so cheap... it's now less important to be perfect the first time the code hits prod (application dependant). It can be rewritten from scratch in no time. The bar for 'maintainability' is a lot lower now, because the AI has more capacity and persistence to maintain terrible code.
I'm sure plenty of people disagree with me. But I'm a good hand programmer, and I just don't feel the need to do that any more. I got into this to build things for other people, and AI is letting me do that more efficiently. Yes, I've had to give up a puritan approach to code quality.
< I enjoy writing code. Let me get that out of the way first.
< I haven’t written a boilerplate handler by hand in months. I haven’t manually scaffolded a CLI in I don’t know how long. I don’t miss any of it.
Sounds like the author is confused or trying too hard to please the audience. I feel software engineering has higher expectation to move faster now, which makes it more difficult as a discipline.
I personally code data structures and algorithms for 1 - 2 hrs a day, because I enjoy it. I find it also helps keeps me sharp and prevents me from building too much cognitive debt with AI generated code.
I find most AI generated code is over engineered and needs a thorough review before being deployed into production. I feel you still have to do some of it yourself to maintain an edge. Or at least I do at my skill level.
The only way I see out of this crisis (yes I'm not on the token-using side of this) is strict liability for companies making software products (just like in the physical world). Then it doesn't matter if the token-generator spits out code or a software engineer spits out code - the company's incentives are aligned such that if something breaks it's on them to fix it and sort out any externalities caused. This will probably mean no vibe-coded side hustles but I personally am OK with that.
I think this is coming, alongside professional licensure for "software engineers". Every public-facing project will need someone to put a literal stamp of approval on the code, and regardless whether Claude or Codex wrote the bulk of it, it'll be that person's head on a pike when something goes wrong.
This isn't what many of us probably would have wanted, but I think the public blowback when "AI-coded" systems start failing is going to drive us there. (Note to passing hype-men: I did not say they will fail at higher rates than human-coded systems! I happen to believe this, but it is not germane to the argument - only the public perception matters here.)
I've been programming for literally my entire life. I love it, it's part of me, and there hasn't been more than a week in 30 years that I haven't written some code.
This is the first time that I feel a level of anxiety when I am not actively doing it. What a crazy shift that I am still so excited and enamored by the process after all of this time.
But there's also the double edged sword. I am also having a really hard time moderating my working hours, which I naturally struggle with anyway, even more. Partly because I am having so much fun and being so productive. But also because it's just so tempting to add 1 more feature, fix one more bug.
I don't agree with the headline of "we're all AI engineers now", but I do agree that AI is more of a multiplier than anything. If you know what you're doing, you go faster, if you don't, you're just making a mess at a record pace.
I'm not sure how this sustains though; like, I can't help but think this technology is going to dull a lot of people's skills, and other people just aren't going to develop skills in the first place. I have a feeling a couple years from now this is going to be a disaster (I don't think AGI is going to take place and I think the tools are going to get a lot more expensive when they start charging the true costs)
> I can still reverse a binary tree without an LLM. I can still reason about time complexity, debug a race condition by reading the code, trace a memory leak by thinking.
A 2026 AI Engineer is a 1996 Software Architect. I don't need to be the one manually implementing the individual widgets of a system, I can delegate their implementation to developers (agents).
I'm being a little facetious, but I don't think it's far off the mark from what TFA is saying, and it matches my experience over the past few months. The worst architects we ever worked with were the ones who couldn't actually implement anything from scratch. Like TFA says, if you've got the fundamentals down and you want to see how far you can go with these new tools, play the role of architect for a change and let the agents fly.
I’ve always designed systems along the classic path: requirements → use cases → schematization. With AI, I continue in the same spirit (structure precedes prompting), but now the foundational layer of my systems is axioms and constraints, and the architecture emerges through structured prompts. Any AI on the shift is an aide in building systems that are logically grounded. This is where the “all of us as AI engineers” claim becomes subtle. Yes, anyone can generate code, but real engineering remains about judgment and structure. AI amplifies throughput, but the bottleneck is still problem framing, abstraction choice, and trade-off reasoning.
So far the issue for me is that you can generate more crap by far than you can keep an eye on.
Once you have your 50k line program that does X are you really going to go in there and deeply review everything? I think you're going to end up taking more and more on trust until the point where you're hostage to the AI.
I think this is what happens to managers of course - becoming hostage to developers - but which is worse? I'm not sure.
Saw the edit: I think that clarification was important.
The core point resonates with me personally. The shift isn't about writing less code, it's about where the real judgment lives. Knowing what to build, how to decompose a problem, which patterns to reach for - and critically, when the model is confidently wrong. Without that foundation you're not moving faster, you're just making bad decisions faster.
The scope point resonates too. Small, well-defined tasks with verifiable output is where agents actually shine.
Without writing some code how will people really know what's right? I've supervised people before - one thinks one knows best and pontificates at them and then when one actually starts working in the codebase onself many issues become clear. If you never get your hands dirty your decisions will tend off towards badness.
> Building systems that supervise AI agents, training models, wiring up pipelines where the AI does the heavy lifting and I do the thinking. Honestly? I’m having more fun than ever.
I'm sure some people are having fun that way.
But I'm also sure some people don't like to play with systems that produce fuzzy outputs and break in unexpected moments, even though overall they are a net win.
It's almost as if you're dealing with humans. Some people just prefer to sit in a room and think, and they now feel this is taken away from them.
I get this. I don't think either of you is wrong. There's a real loss in not writing something from scratch and feeling it come together under your hands. I'm not dismissing that.
I have immense respect for the senior engineers who came before me. They built the systems and the thinking that everything I do now sits on top of. I learned from people. Not from AI. The engineers who reviewed my terrible pull requests, the ones who sat with me and explained why my approach was wrong. That's irreplaceable. The article is about where I think things are going, not about what everyone should enjoy.
Right. What about to K.I.S.S (Keep It Simple Stupid)? If I need a bunch of agents and various levels of orchestration to simply close a bunch of Jira tasks then we have a problem. Also, what happens in a few years when this start failing and human operators are no longer able to troubleshoot the issue, forget fixing it.
Very much on the same page as the author, I think AI is a phenomenal accelerant.
If you're going in the right direction, acceleration is very useful. It rewards those who know what they're doing, certainly. What's maybe being left out is that, over a large enough distribution, it's going to accelerate people who are accidentally going in the right direction, too.
Maybe to the people writing the invoices for the infra you're renting, sure. Or to the people who get paid to dig you out of the consequences you inevitably bring about. Remember, the faster the timescale, the worse we are wired to effectively handle it as human beings. We're playing with a fire that catches and spreads so fast, by the time anyone realizes the forest is catching and starting to react, the entire forest is already well on the way to joining in the blaze.
> We're playing with a fire that catches and spreads so fast, by the time anyone realizes the forest is catching and starting to react, the entire forest is already well on the way to joining in the blaze.
I suspect this has been said in one form or another since the discovery of fire itself.
The perception seems to be that AI is only causing security vulnerabilites (see: openclaw injection in npm (Clinejection)). But the article's optimistic tone much reflects my own, and if it were all bad, then nobody would be using AI. But it's mostly good, and with the benchmarks, it's a statistical fact that it helps more than it hurts. It's just math at a certain point.
Maybe I'm entirely out of the loop and a complete idiot, but I am really not sure at all what people mean when they talk about this stuff. I use AI agents every day, but people who say they spend 'most of my time writing agents and tools' must be living in an absolutely different world.
I don't understand how people are making anything that has any level of usefulness without a feedback loop with them at the center. My agents often can go off for a few minutes, maybe 10, and write some feature. Half of the time they will get it wrong, I realize I prompted wrong, and I will have to re-do it myself or re-do the prompt. A quarter of the time, they have no idea what they're doing, and I realize I can fix the issue that they're writing a thousand lines for with a single line change. The final quarter of the time I need to follow up and refine their solution either manually or through additional prompting.
That's also only a small portion of my time... The rest is curating data (which you've pretty much got to do manually), writing code by hand (gasp!), working on deployments, and discussing with actual people.
Maybe this is a limitation of the models, but I don't think so. To get to the vision in my head, there needs to be a feedback loop... Or are people just willing to abdicate that vision-making to the model? If you do that, how do you know you're solving the problem you actually want to?
This essay somehow sounds worse than AI slop, like ChatGPT did a line of coke before writing this out.
I use AI everyday for coding. But if someone so obviously puts this little effort into their work that they put out into the world, I don’t think I trust them to do it properly when they’re writing code.
FWIW I reported your post to the mods because it reads completely AI generated to me. My judgement was that it might have been slightly edited but is largely verbatim LLM output.
Some tells that you might wanna look at in your writing, if you truly did write it yourself without Any LLM input are these contrarian/pivoting statements. Your post is full of these and it is imo the most classic LLM writing tell atm. These are mostly variants of the 'Its not X but Y" theme:
- "Not whether they've adopted every tool, but whether they're curious"
- "I still drive the intuition. The agents just execute at a speed I never could alone."
- "The model doesn't save you from bad decisions. It just helps you make them faster."
- "That foundation isn't decoration. It's the reason the AI is useful to me in the first place."
- "That's not prompting. That's engineering"
It is also telling that the reader basically cant take a breather most of the sentences try to emphasize harder than the last one. There is no fluff thought, no getting side tracked. It reads unnatural, humans do not think like this usually.
Yours is maybe the first good post on managing a team of AIs that I've read. There is no spoon.
I've been shifting from being the know-it-all coder who fixes all of the problems to a middle manager of AIs over the past few months. I'm realizing that most of what I've been doing for the last 25 years of my career has largely been a waste of time, due to how the web went from being an academic pursuit to a profit-driven one. We stopped caring about how the sausage was made, and just rewarded profit under a results-driven economic model. And those results have been self-evidently disastrous for anyone who cares about process or leverage IMHO. So I ended up being a custodian solving other people's mistakes which I would never make, rather than architecting elegant greenfield solutions.
For example, we went from HTML being a declarative markup language to something imperative. Now rather than designing websites like we were writing them in Microsoft Word and exporting them to HTML, we write C-like code directly in the build product and pretend that's as easy as WYSIWYG. We have React where we once had content management systems (CMSs). We have service-oriented architectures rather than solving scalability issues at the runtime level. I could go.. forever. And I have in countless comments on HN.
None of that matters now, because AI handles the implementation details. Now it's about executive function to orchestrate the work. An area I'm finding that I'm exceptionally weak in, due to a lifetime of skirting burnout as I endlessly put out fires without the option to rest.
So I think the challenge now is to unlearn everything we've learned. Somehow, we must remember why we started down this road in the first place. I'm hopeful that AI will facilitate that.
Anyway, I'm sure there was a point I was making somewhere in this, but I forgot what it was. So this is more of a "you're not alone in this" comment I guess.
Edit: I remembered my point. For kids these days immersed in this tech matrix we let consume our psyche, it's hard to realize that other paradigms exist. Much easier to label thinking outside the box as slop. In the age of tweets, I mean x's or whatever the heck they are now, long-form writing looks sus! Man I feel old.
> The problem is: you can’t justify this throughput to someone who doesn’t understand real software engineering. They see the output and think “well the AI did it.” No. The AI executed it. I designed it. I knew what to ask for, how to decompose the problem, what patterns to use, when the model was going off track, and how to correct it. That’s not prompting. That’s engineering.
That’s the “money quote,” for me. Often, I’m the one that causes the problem, because of errors in prompting. Sometimes, the AI catches it, sometimes, it goes into the ditch, and I need to call for a tow.
The big deal, is that I can considerably “up my game,” and get a lot done, alone. The velocity is kind of jaw-dropping.
I’m not [yet] at the level of the author, and tend to follow a more “synchronous” path, but I’m seeing similar results (and enjoying myself).
I vibe coded a Kubernetes cluster in 2 days for a distributed compilation setup. I've never touched half this stuff before. Now I have a proof of concept that'll change my whole organization.
That would've taken me 3 months a year ago, just to learn the syntax and evaluate competing options. Now I can get sccache working in a day, find it doesn't scale well, and replace it with recc + buildbarn. And ask the AI questions like whether we should be sharding the CAS storage.
The downside is the AI is always pushing me towards half-assed solutions that didn't solve the problem. Like just setting up distributed caching instead of compilation. It also keeps lying which requires me to redirect & audit its work. But I'm also learning much more than I ever could without AI.
> I vibe coded a Kubernetes cluster in 2 days for a distributed compilation setup. I've never touched half this stuff before. Now I have a proof of concept that'll change my whole organization.
Dunning-Kruger as a service. Thank God software engineers are not in charge of building bridges.
“Hey Claude, you have a bunch of skills defined, some mcps, and memory filled with useful stuff. I want to use you on a machine accessible over SSH at <host>, can you clone yourself over?”
I think he is absolutely right. But what if he is not right? Then he is also absolutely right. He is just always absolutely right right?. Even when he is not right? Yes he is always absolutely right.
I agree wholeheartedly with all that is said in this article. When guided, AI amplifies the productivity of experts immensely.
There are two problems left, though.
One is, laypersons don't understand the difference between "guided" and "vibe coded". This shouldn't matter, but it does, because in most organizations managers are laypersons who don't know anything about coding whatsoever, aren't interested by the topic at all, and think developers are interchangeable.
The other problem is, how do you develop those instincts when you're starting up, now that AI is a better junior coder than most junior coders? This is something one needs to think about hard as a society. We old farts are going to be fine, but we're eventually going to die (retire first, if we're lucky; then die).
What comes after? How do we produce experts in the age of AI?
The instincts can absolutely be developed faster with AI — if you set it up right. I work with an AI partner daily and one thing I've noticed is that it's a brutal mirror: it exposes gaps in your thinking immediately because it does exactly what you tell it, not what you meant.
That feedback loop, hundreds of times a day, compresses years of learning into months. The catch is you need guardrails — tests that fail when the AI drifts, review cycles you can't skip, architecture constraints it must respect.
That's what builds the instincts: not the AI doing the work for you, but the AI showing you where your understanding breaks down, fast enough that you actually learn from it. Just-In-Time Learning.
This is the question I keep coming back to. I don't have a clean answer yet.
The foundation I built came from years of writing bad code and understanding why it was bad. I look at code I wrote 10 years ago and it's genuinely terrible. But that's the point. It took time, feedback, reading books, reviewing other people's work, failing, and slowly building the instinct for what good looks like. That process can't be skipped.
If AI shortens the path to output, educators have to double down on the fundamentals. Data structures, systems thinking, understanding why things break. Not because everyone needs to hand-write a linked list forever, but because without that foundation you can't tell when the AI is wrong. You can't course-correct what you don't understand.
Anyone can break into tech. That's a good thing. But if someone becomes a purely vibe-coding engineer with no depth, that's not on them. That's on the companies and institutions that didn't evaluate for the right things. We studied these fundamentals for a reason. That reason didn't go away just because the tools got better.
People always learn the things they need to learn.
Were people clutching their pearls about how programmers were going to lack the fundamentals of assembly language after compilers came along? Probably, but it turned out fine.
People who need to program in assembly language still do. People who need to touch low-level things probably understand some of it but not as deeply. Most of us never need to worry about it.
I don't think the comparison (that's often made) between AI and compilers is valid though.
A compiler is deterministic. It's a function; it transforms input into output and validates it in the process. If the input is incorrect it simply throws an error.
AI doesn't validate anything, and transforms a vague input into a vague output, in a non-deterministic way.
A compiler can be declared bug-free, at least in theory.
But it doesn't mean anything to say that the chain 'prompt-LLM-code' is or isn't "correct". It's undecidable.
Actually, it isn't that different. Compilers are trash. They produce hilariously bloated and stupid code, even the C++ compilers, not to speak about your average JIT compiler.
However, in practice we don't care because it's good enough for 99% of the code. Sure, it could be like 5x better at least but who cares, our computers are fast enough.:tm:
AI is the same. Is it as good as the best human output? Definitely not. Does it do the job most of the time? Yes, and that's what people care about.
(But yes, for high-impact work - there's many people who know how to read x64 asm or PTX/SASS and they do insane stuff.)
Not usually they aren't. They can be made to be, but it requires extra effort and tradeoffs. Hence why there is a lot of work put into reproducible builds — something you would get for free if compilers were actually always deterministic.
Unless you are taking a wider view and recognizing that, fundamentally, nothing running on a computer can be nondeterministic, which is definitely true.
>People always learn the things they need to learn.
No, they don't. Which why a huge % of people are functionaly illiterate at the moment, know nothing about finance and statistics and such and are making horrendous decisions for their future and their bottom line, and so on.
There is also such a thing as technical knowledge loss between generations.
I find really sad how people are so stubborn to dismiss AI as a slop generator.
I completely agree with the author, once you spend the time building a good enough harness oh boy you start getting those sweet gains, but it takes a lot of time and effort but is absolutely worth it.
what about the environmental impact of AI, especially agentic AI? I keep reading praise for AI on the orange site, but its environmental impact is rarely discussed. It seems that everyone has already adopted this technology, which is destroying our world a little more.
I believe the orange site's consensus was that it's approximately one additional mini fridge or dish washer worth of consumption on average. You've got users who use these tools barely 1k tokens per week. Assuming it's all batched ideally that's like running an LED floodlight for a minute or so. The other end of the spectrum can be pretty extreme in consumption but it's also rare. Most people just use the adhoc stuff.
The environmental impact of AI replacing a human programmer is orders of magnitude lower than the environmental impact of that programmer. Look up average US water consumption and CO2 emissions per capita.
And then add on top the environmental impact of all of the money that programmer gets from programming - travels around the world, buying large houses, ...
If you care about the environment, you should want AI's replacing humans at most jobs so that they can no longer afford traveling around the world and buying extravagant stuff.
Yes the environmental impact of an AI agent performing a given task is lower. However we will not simply replace every programmer with an agent: in the process we will use more agents exceeding the previous environmental impact of humans. This is the rebound effect [0].
Your reasoning could be effective if we bounded the computing resources usable by all AI in order to meet carbon reduction goals.
>The environmental impact of AI replacing a human programmer is orders of magnitude lower than the environmental impact of that programmer. Look up average US water consumption and CO2 emissions per capita.
The programmer will continue to exist as a consumer of those things even if they get replaced by AI in their job.
on top of that for sure all programmers AI is replacing are all extravagantly traveling around the world (especially ones in America that make the most dough and 90% do not have a passport)
If you read the book, my point should be crystal clear - that environmental impact which aligns with The Party goals (shareholder profits) the best, is painted the least concerning of all.
The phrase "shape up or ship out" is an apt one I've heard. Agentic AI is a core part of software engineering. Either you are learning and using these tools, or you're not a professional and don't belong in the field.
Seems strange, for decades we allowed developers to use what made them comfortable, you like notepad? go ahead and use it. Don't want an LSP? that's fine disable it.
So long as their productivity was on par with the rest of the team there was no issue.
Suddenly, everyone needs to use this new tool (which we haven't proven to actually be effective) and if you don't you don't belong in the industry.
> So long as their productivity was on par with the rest of the team there was no issue.
Emphasis added. And anyway, for most software dev in most shops it wasn't true; most development takes place in whatever IDE the group/organization standardized on for the task, to make sure everyone gets proper tooling and to make collaboration and information sharing easier. Think of all the Java enterprise software developed by legions of drones in the 2000s and 2010s. They all used Eclipse, because Eclipse is what they were given.
It's only with the emergence of whiny, persnickety Unix devs who refused to leave the comforting embrace of their editor of choice that shops in the internet/dotcom/startup tradition embraced a "use whatever tools you want" philosophy. They had uncharacteristically enormous leverage over the tech stack being deployed in such businesses and could force employers to make that concession. And anyway, what some of them could do with vi blew the boss's mind.
It is true that we don't have a whole lot of hard data from large organizations that show AI productivity improvements. But absence of evidence is not evidence of absence. Turns out, most large organizations just haven't adopted AI in the amount and ways that could make a big impact.
But we have enough anecdata from competent developers to suggest that the productivity gains are huge. So big, AI not only lets you do your normal tasks many times faster, it puts projects within reach that you would not have countenanced before because they were too complex or tedious to be worth the payoff.
So no. Refusing to use AI is just pure bloodymindedness at this point—like insisting on using a keypunch while everyone around you discovers the virtues of CRT terminals and timesharing. There were people like this even in the 1970s when IBM finally came around and made timesharing available in their mainframes. Those people either got up to speed or moved on to a different profession. They couldn't keep working the way they'd been working because the productivity expectations changed with the availability of new technology.
> It's only with the emergence of whiny, persnickety Unix devs who refused to leave the comforting embrace of their editor of choice that shops in the internet/dotcom/startup tradition embraced a "use whatever tools you want" philosophy. They had uncharacteristically enormous leverage over the tech stack being deployed in such businesses and could force employers to make that concession. And anyway, what some of them could do with vi blew the boss's mind.
They had enormous leverage because they were more productive then the drones who use whatever tools they are handed and lack the curiosity to use anything else. These breathless reports of increased productivity are constant, but why is there no evidence of that productivity increase otherwise? Why hasn't there been a surge of side-project video games on Steam? Why is github down so often despite Microsoft's commitment to AI?
The AI tools make it easier to do things that were already easy, but the minute your code gets interesting these tools are an absolute mess.
The catch about the "guided" piece is that it requires an already-good engineer. I work with engineers around the world and the skill level varies a lot - AI has not been able to bridge the gap. I am generalizing, but I can see how AI can 10x the work of the typical engineer working in Startups in California. Even your comment about curiosity highlights this. It's the beginning of an even more K-shaped engineering workforce.
Even people who were previously not great engineers, if they are curious and always enjoyed the learning part - they are now supercharged to learn new ways of building, and they are able to try it out, learn from their mistakes at an accelerated pace.
Unfortunately, this group, the curious ones, IMHO is a minority.
But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"? Is it possible that they are not enthusiastic for the change in the nature of the work? Is it possible they are concerned about "automation complacency" setting in, precisely _because_ of the ratio of "hundreds of times" writing decent code to the one time writing "something stupid", and fear that every once in a while that "something stupid" will slip past them in a way that wipes the entire net gain of AI use? Is it possible that they _don't_ feel that the typical code is "better than most engineers can write"? Is it possible they feel that the "learning" is mostly ephemera - how much "prompt engineering" advice from a year ago still holds today?
You have a choice, and it's easy to label them (us?) as Luddites clinging to the old ways out of fear, stupidity, or "incuriosity". If you really want to understand, or even change some minds, though, please try to ask these people what they're really thinking, and listen.
In fairness, this is true of many human developers too.. but they're generally not doing it at a 1000 miles per hour and they theoretically get better at working with your codebase and learn. LLMs will always get worse as your codebase grows, and I just watched a video about how AGENTS.md actually usually results in worse outcomes so it's not like you can just start treating MD files as memory and hope it works out.
I had an idea earlier this week about this, but haven’t had a chance to try it. Since the agent can now “see” the whole stack, or at least most of it, by having access to the repos, there’s becoming less of a reason to suspect they won’t be able to take the whole stack into account when proposing a change.
The idea is that it’s like grep: you can call grep by itself, but when a match is found you only see one line per match, not any surrounding context. But that’s what the -A and -B flags are for!
So you could tell the agent that if its proposed solution lies at layer N of the system, it needs to consider at least layers N-1 (dependencies) and N+1 (consumers) to prevent the local optimum problem you mentioned.
The model should avoid writing a pretty solution in the application layer that conceals and does not address a deeper issue below, and it should keep whatever contract it has with higher-level consumers in good standing.
Anyway, I haven’t tried that yet, but hope to next week. Maybe someone else has done something similar and (in)validated it, not sure!
I think there's a place for thoughtful dialogue around what this means for software engineering, but I don't think that's going to change anything at this point. If developers just don't want to participate in this new world, for whatever reason, I'm not judging them, but also I don't think the genie is going back in the bottle. There will be no movement to organize labor to protect us and there be no deus ex machina that is going to reverse course on this stuff.
Yes. We are this generations highly skilled artisans, facing our own industrial revolution.
Just as the skilled textile workers and weavers of early 19’th century Britain were correct when they argued this new automated product was vastly inferior, it matters not at all. And just as they were also correct, that the government of the day was doing nothing to protect the lives and livelihoods of those who had spent decades mastering a difficult set of professional skills (the middle class of the day), the government of this day will also do nothing.
And it doesn’t end with “IT”; anything that can be turned into a factory process with our new “thinking engines” will be. Perhaps we can do better in society this time around. I am not hopeful.
I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case.
Now of the course the "this isn't the case" stuff is statistically, thus there can be individual developers whom are faster, but there can also be that an individual developer sometimes is faster and sometimes not but the times that they are faster are just so clearly faster that it sort of hides the times that they're not. Statistics of performance over a number of developers can flatten things out. But I don't know that is the case.
So my question for you, and everyone that claims it makes them so perceptively and clearly faster - how do you know? Given all the studies showing that it doesn't make you faster, how are you so sure it does?
From our perspective, the gains are so obvious that it really does feel like you must just be doing something fundamentally wrong not to see the same wins.
So when someone says "I can't make it do the magic that you're seeing" it makes me wonder why you don't have a long list of projects that you've never gotten around to because life gets in the way.
Because... if you don't have that list, to us that translates as painfully incurious. It's inconceivable that you don't have such a list because just being a geek in this moment should be enough that you constantly notice things that you'd like to try. If you don't have that, it's like when someone tells you that they don't have an inner monologue. You don't love them any less, but it's very hard not to look at them a bit differently.
quite frankly there seems to be something incredibly frustrating in your life going on, but I'm not sure that the underlying cause of whatever is weighing on your mind at the moment is that I asked "how do you know that what you are feeling is actually true, in comparison to what studies show should be true?" (rephrased, as not reasonable to quote whole post)
>From our perspective, the gains are so obvious that it really does feel like you must just be doing something fundamentally wrong not to see the same wins.
From my perspective, when I think i am experiencing something that data from multiple sources tell me is not what is actually happening I try to figure out how I can prove what I am experiencing, I reflect upon myself, have I somehow deluded myself? No? Then how do I prove it when analysis of many similar situations to my own show a different result?
You seem to think what I mean is people saying "Claude didn't help me, it wasn't worth it", no, just to clarify although I thought it was really clear, I am talking about numerous studies always being posted on HN so I'm sure you must have seen them where productivity gains from coding agents do not seem to actually show up in the work of those who use it. Studies conducted by third parties observing the work, not claims made by people performing the work.
I'm not going to go through the rest of your post, I get the urge to be insulting, especially as a stress release if you have a particularly bad time recently. But frankly, statistically speaking, my life is almost certainly significantly worse than yours, and for that reason, but not that reason alone, I will also quite confidently state without hardly any knowledge of you specifically but just my knowledge of my life and comparison of having met people throughout it, that my list dwarfs yours.
Sorry I don't have DX stats or token usage stats I can share, but based on the directives from on high, those stats are highly correlated (in the positive).
[edit] And SEV rates are not meaningfully higher.
For me, AI tools act like supercharged code search and auto complete. I have been able to make changes in complex components that I have rarely worked on. It saved me a week of effort to find the exact API calls that will do what I needed. The AI tool wrote the code and I only had to act as a reviewer. Of course I am familiar with the entire project and I knew the shape of the code to expect. But it saved me from digging out the exact details.
I think that is a fairly good definition of what an LLM is. I'd say the third leg of the definition is adjustable randomness.
Most of these studies were done one or more years ago, and predate the deployment and adoption of RLHF-based systems like Claude. Add to that, the AI of today is likely as bad as it's ever going to be (i.e., it's only going to get better). Though I do think the 10x claims are probably unfounded.
The thing is when I use an AI I sort of feel these gains, but not any greatness, it's like wow it would have taken me days to write all this reasonable albeit sort of mediocre code. I mean that is definitely a productivity gain. Because a lot of times you need to write just mediocre code. But there are parts where I would not have written it like that. So if I go through fixing all these parts, how much of a gain did I actually get?
As most posters on HN I am a conceited jerk, so I can claim that I have worked with lots of mediocre programmers (while ignoring the points where I was mediocre by thinking oh that didn't count I followed the documentation and how it was suggested to use the API and that was a stupid thing to do) and I certainly didn't fix everything that they did, because there just wasn't enough hours in the day.
And they did build stuff that worked, much of the time, so now I got an automated version of that. sweet. But how do I quantify the productivity? Since there are claims put forth with statistical backing that the productivity is illusory.
This is just one of those things that tend to affect me badly, I think X is happening, study shows X does not happen. Am I drinking too much Kool-Aid here or is X really happening!!? How to prove it!!? It is the kind of theoretical, logical problem seemingly designed to drive me out of my gourd.
Humanity has possessed nuclear weapons for 80 years and has used them exactly twice in anger, at the very beginning of that span. We can in fact just NOT do things! Not every world-beating technology takes off, for one reason or another. Supersonic airliners. Eugenics. Betamax.
The best time to air concerns was yesterday. The next best time is today. I think we technologists wildly overestimate public understand and underestimate public distrust of our work and of “AI” specifically. We’ve got CEOs stating that LLMs are a bigger deal than nuclear weapons or fire(!) and yet getting upset that the government wants control of their use. We’ve got giddy thinkpieces from people (real example from LinkedIn!) who believe we’ll hit 100% white collar unemployment in 5 years and wrap up by saying they’re “5% nervous and 95% excited”. If that’s what they really think, and how they really feel, it’s psychopathic! Those numbers get you a social scene that’ll make the French Revolution look like a tea party. (“And honestly? I’m here for it.”)
So no, while I _think_ you’re correct, I don’t accept the inevitability of it all. There are possibilities I don’t want to see closed off (maybe data finally really is the new oil, and that’s the basis for a planetary sovereign wealth fund. Maybe every man, woman, and child who ever wrote a book or a program or an internet comment deserves a royalty check in the mail each month!) just yet.
I agree with you on that. Not just on AI but a lot of things that suck about this world, and in particular the United States. But capital is too powerful. And these tools are legitimately transformative for business. And business pays our bills and, more importantly, provides the healthcare insurance for our families. The wheel is a real fucking drag isn't it?
I don't see anything short of a larger revolution against capital stopping or even stemming this. For that to really happen we would need a lot more people and interests than just those of software practitioners. Which may come yet when trucking jobs collapse and customer service jobs disappear. I don't know. I do know that I'm taking part in something that will potentially (likely?) seed the end of my career as I know it but it's just one of many contradictions that I live with. In the meantime the tools are impressive and I'm just figuring out how to live with them and do good work with them and as you can probably tell, I'm pretty convinced that's the best we can make of the situation right now.
100% this. I don't know why we think that pouring trillions of dollars into something we barely understand to create an economic revolution that is almost certainly awful is at all "inevitable". We just need leaders that aren't complete idiots. I'm generally cynical, but I do see that normies (ie not in tech) are waking up a bit. I don't think the technology is inherently a bad thing, but the people that think that we should just do this as fast as possible to win "the race" should be shot into space as far as I'm concerned. To start with, we need a working SEC that can actually punish the grifting CEO's that are using fear to manipulate markets.
Of course, there’s nothing wiser than tying the entirety of your career to a $20/month subscription (that will jump 10x in price as soon as the market is captured).
Is writing solved because LLMs can make something decently readable? Why say anything at all when LLMs can glob your ideas into a glitzy article in a couple of seconds?
I swear, some people in this field see no value in their programming work — like they’ve been dying to be product managers their entire lives. It is honestly baffling to me. All I see is a future full of horrifying security holes, heisenbugs, and performance regressions that absolutely no one understands. The Idiocracy of software. Fuck!
All I'm saying is you're gonna have to figure out how to do this with an agent. It's not that I don't see value in the craft; it's just that value is less important. As far as the new paradigms, the new frameworks, new studies in computer science -- they still exist, it's just that they are going to focus on how to mitigate heisenbugs, performance regressions and security holes in agent written code. Who knows.. in five years most of the code written may not even be readable. I'm not saying it's going to be like that, but it's entirely possible.
In the meantime, there's nothing stopping you from using the agent to write the code that is every bit as high quality as if you sat down and typed it in yourself. And right now there is a category of engineers that exclusively use agents to create quality software and they are more efficient at it than anybody that just does it themselves. And that category is growing and growing every day.
I may be out a job in five years because all of this. But I am seeing where this is going and it's clear and so I'm going to have to change with it.
I'm really not, though, any more than I "had to" learn JavaScript 20 years ago or blockchains 5 years ago (neither of which I did). Hell, I still use Perl day-to-day.
You can only speak for yourself.
Agentic programming isn’t engineering: it’s a weird form of management where your workers don’t grow or learn and nobody really understands the system you’re building. That sounds like a hellish, pointless career and it’s not what I got into the field to do. So no thanks: I’ll just keep doing the kind of monkey engineering I find invaluable. Especially while most available models are owned and trained by authoritarian, billionaire, misanthropic cultists.
Fortunately, I am not beholden to some AI-pilled corporation for salary.
And others see too much value in their work.
I test to see the way people think now. People like you would pass my interview.
However, history suggests that creating artificial divisions is the first step towards all of the the bad things we claim not to like in this world.
Tech adoption generally moves like Time's Arrow. People who use LLMs aren't geeks who changed; we're just geeks. If you want to get off the train, that's your call. But don't make it an us vs them.
I don't want the means of production to be located inside companies that can only exist with a steady bubble of VC dollars. It's perfectly reasonable to try AI or use it sparingly, but not embrace it for reasons that can be articulated. Not relevant to parent commenters point, though. Maybe you are "replying" to the article?
When I engage with AI skeptics and I "ask these people what they're really thinking, and listen" they say something totally absurd, like GPT 3.5-turbo and Opus 4.6 are interchangeable, or they put into question my ability as an engineer, or that I am a "liar" for claiming that an agent can work for an hour unprompted (something I do virtually every day). This isn't even me picking the worst of it, this is pretty much a typical conversation I have on HN, and you can go through my comment history to verify I have not drawn any hyperbole.
It's like flipping through a math book and nodding to yourself when you look at the answers and thinking you're learning. But really you aren't because the real learning requires actually doing it and solving and struggling through the problems yourself.
But I agree that it can serve as a tool for a person who it's interested in learning but I bet you that for every such person there's 10x as many who are happy to outsource all their thinking to the machine.
We already have reports from basically every school in the world struggling with this exact problem. Students are just copy pasting LLMs and not really learning.
That said, I _did_ read your comments history (only because you asked!) and - well, I don't know, you seem very reasonable, but I notice you're upset with people talking about "hallucinations" in code generation from Opus 4.6. Now, I have actually spent some time trying to understand these models (as tool or threat) and that means using them in realistic circumstances. I don't like the "H word" very much, because I am an orthodox Dijkstraist and I hold that anthropomorphizing computers and algorithms is always a mistake. But I will say that like you, I have found that in appropriate context (types, tests) I don't get calls to non-existent functions, etc. However, I have seen: incorrect descriptions of numerical algorithms or their parameters, gaslighting and "failed fix loops" due to missing a "copy the compiled artifact to the testing directory" step, and other things which I consider at least "hallucination-adjacent". I am personally much more concerned about "hallucinations" and bad assumptions smuggled in the explanations provided, choice of algorithms and modeling strategies, etc. because I deal with some fairly subtle domain-specific calculations and (mathematical) models. The should-be domain experts a) aren't always and b) tend to be "enthusiasts" who will implicitly trust the talking genius computer.
For what it's worth, my personal concerns don't entirely overlap the questions I raised way above. I think there are a whole host of reasons people might be reluctant or skeptical, especially given the level of vitriol and FUD being thrown around and the fairly explicit push to automate jobs away. I have a lot of aesthetic objections to the entire LLM-generated corpus, but de gustibus...
But, if you don't mind me going on a rant: the hallucinations thing. It kind of drives me nuts, because every day someone trots out hallucinations as some epic dunk that proves that AI will never be used in the real world or whatever. I totally hear you and think you are being a lot more reasonable than most (and thank you for that) -- you are saying that AI can get detail-oriented and fiddly math stuff wrong. But as I, my co-workers, and anyone who seriously uses AI in the industry all know, hallucinations are utterly irrelevant to our day-to-day.
My point is that hallucinations are irrelevant because if you use AI seriously for a while you quickly learn what it hallucinates on and what it does not, you build your mental model, and then you spend all your time on the stuff it doesn't hallucinate on, and it adds a fantastic amount of value there, and you are happy, and you ignore the things it is bad at, because why would you use a tool on things it is bad at? Hearing people talk about hallucinations in 2026 sounds to me like someone saying "a hammer will never succeed - I used it to smack a few screws and it NEVER worked!" And then someone added Hammer-doesnt-work-itis to Wikipedia and it got a few citations in Arxiv now it's all people can say when they talk about hammers online, omfg.
So when you say that I should spend more time asking "what do they see that I don't" - I feel quite confident I already know exactly what you see? You see that AI doesn't work in some domains. I quite agree with you that AI doesn't work in some domains. Why is this a surprise? Until 2023 it worked in no domains at all! There is no tool out there that works in every single domain.
But when you see something new, the much more natural question than "what doesn't this work on" is "what does this work on". Because it does work in a lot of domains, and fabulously well at that. Continuously bringing up how it doesn't work in some domain, when everyone is talking about the domains it does work, is just a non-sequitur, like if someone were to hop into a conversation about Rust and talk about how it can't solve your taxes, or a conversation about CSS to say that it isn't turing complete.
When everyone forgets how to read, I'll be thriving. When everyone is neurotic from prompting-brain, I will be in my emacs, zen and unburdened.
I love that yall have them though, they are kinda fun to mess with. And as long as I can review and reject it, all yalls little generations are acceptable for now.
There's two critical mistake that people often make: 1) thinking there's only one solution to any given problem, and 2) that were there an absolute optima, that they've converged into the optimal region. If you carefully look at many of the problems people routinely argue about you'll find that they often are working under different sets of assumptions. It doesn't matter if it's AI vs non-AI coding (or what mix), Vim vs Emacs vs VSCode, Windows vs Mac vs Linux, or even various political issues (no examples because we all know what will happen if I do, which only illustrates my point). There are no objective answers to these questions, and global optima only have the potential to exist when highly constraining the questions. The assumptions are understood by those you closely with, but that breaks down quickly.
If your objective is to seek truth you have to understand the other side. You have to understand their assumptions and measures. And just like everyone else, these are often not explicitly stated. They're "so obvious" that people might not even know how to explicitly state them!
But if the goal is not to find truth but instead find community, then don't follow this advice. Don't question anything. Just follow and stay in a safe bubble.
We can all talk but it gets confusing. Some people argue to lay out their case and let others attack, seeking truth, updating their views as weaknesses are found. Others are arguing to social signal and strengthen their own beliefs, changing is not an option. And some people argue just because they're addicted to arguing, for the thrill of "winning". Unfortunately these can often look the same, at least from the onset.
Personally, I think this all highlights a challenge with LLMs. One that only exasperates the problem of giving everyone access to all human knowledge. It's difficult you distinguish fact from fiction. I think it's only harder when you have something smooth talking and loves to use jargon. People do their own research all the time and come to wildly wrong conclusions. Not because they didn't try, not because they didn't do hard work, and not because they're specifically dumb; but because it's actually difficult to find truth. It's why you have PhD level domain experts disagree on things in their shared domain. That's usually more nuanced, but that's also at a very high level of expertise.
I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language design, compiler optimization, and open source politics in my free time.
There are many bits of tacit knowledge I don't have. I know I don't have them, because I have that knowledge in other domains. I know that I don't know what I don't know about being a "real engineer."
But I also know what taste is. I know what questions to ask. I know the magic words, and where to look for answers.
For people like me, this feels like an insane golden age. I have no shortage of ideas, and now the only thing I have is a shortage of hands, eyes, and on a good week, tokens.
Everyone has tons of ideas. But every good engineer (and scientist) also knows that most of our ideas fall apart when either thinking deeper or trying to implement it (same thing, just mental or not). Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
> Why not read books, manuals, or take online classes? There is free access to all these things, the only cost is time and energy.
Sure, but it's just way faster now. I can get the exact right piece of knowledge I need to advance my understanding on demand, rather than having to spend minutes or hours tracking down the right information, then scanning around the text to filter out all the irrelevant stuff.
There's also a motivational effect: the activation energy of bothering to do this was such that in many domains, it didn't seem worth it.
> Everyone has tons of ideas
Most people have profoundly bad ideas
> Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
Agree, however that's the challenge of this time. Things are becoming less visible. On the other hand, you can implement and get that feedback ten times faster, or point ten minds at stress-testing a concept in 3 minutes. For many of my projects, that's the difference between getting anything done vs idly fantasizing. For others, it could easily be irrelevant.
> The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
I don't think this is a coherent statement. How could you possibly surmount complexity with anything other than better ideas and more hands?
I think there's this belief that there are shortcuts to learning. That's a big mistake. You can't learn programming by reading, yet so many people try to do something similar with different domains. It is exactly the same thing that leads people to conspiracy theories. They have such "swiss cheese knowledge" that they don't understand how things actually are connected. How people use LLMs is typically to take the direct route to the information they want, which is only logical, but misses all that other important stuff that you wouldn't know is important to understanding those things until you have mastery of that knowledge.
If there was a shortcut, people would be writing manuals and textbooks very differently. We've been doing it for thousands of years and iterating it for just as long. It's converged to the place it has for a reason.
Yes, and why? One of the most common reasons is people are missing the surrounding context. All those little details. It's exactly what I said before about figuring it out as you go. This is part of why the "doing" matters. Why that stuff that doesn't seem important to the novice actually is, and why experts include it in their teachings. You can, but you can also dig yourself into a 10x deeper hole 10x faster. The LLM doesn't make you an expert. The LLM doesn't make context appear. I'm sorry, but all that nuance doesn't go away. The LLM only makes it less visible as it does some things for you and every time it does something you don't know how to do you're that much deeper into the water. It's okay to be in a little over your head (that's how we learn) but these tools also make it very easy to get into much deeper waters than you can handle. When that happens, you are unable to do anything and are at the mercy of the LLM. So good luck. Because complexity is complex. There are many different types. Sit with the idea longer, I promise it is coherent. But I'm not going to give you a shortcut. Maybe the LLM will, I'm fairly confident it will be able to figure it out.A little terrifying. Probably the solution is to read 19th century literature before bed.
I think where I get really irritated with the discourse is when people find something that works for them, kinda, and they're like "WELL THIS IS WHAT EVERYONE HAS TO DO NOW!" I wouldn't care if I felt like "oh, just a rando on the internet has a bad opinion", the reason this subject bothers me is words do matter and when enough people are thoughtlessly on the hype train it starts creating a culture shift that creates a lot of harm. And eventually cooler heads prevail, but it can create a lot of problems in the meantime. (Look at the damage crypto did!)
Have I spent years, personally grinding directly in the belly of the beast? No. I managed a small dev team in small startup once. Yeah, it's not the same thing. I know I don't know everything.
Yes, I'm familiar with the critiques of capitalism. I went to art school. Art school is like studying philosophy, but only the social critique parts (for better or worse).
Yes, I'm aware that I'm being ingested by machinery that serves capital. I've read Nick Land.
We're all doing our best to navigate this, but don't forget that poets, mathematicians, artists, and musicians really exist. They contact the cold realities of real life too, and many of them still succeed, still live beautiful lives. And no matter how bad things are, they still write history in the long-run.
Personally I have been able to produce a very good output with Grok in relation to a video. However, it was insanely painful and very annoying to produce. In retrospect I would've much preferred to have hired humans.
Not to mention I used about 50 free-trial Grok accounts, so who knows what the costs involved were? Tens of thousands no doubt.
Moreover, this kind of thinking is incredibly backward. If you were better than me then, you can easily become much better than I'll ever be in the future.
LLMs are great for rapid prototyping, boilerplate, that kind of thing. I myself use them daily. But the amount of mistakes Claude makes is not negligible in my experience.
This needs more attention. There's a lot of inhumanity in the modern workplace and modern economy, and that needs to be addressed.
AI is being dumped into the society of 2026, which is about extracting as much wealth as possible for the already-wealthy shareholder class. Any wealth, comfort, or security anyone else gets is basically a glitch that "should" be fixed.
AI is an attempt to fix the glitch of having a well-compensated and comfortable knowledge worker class (which includes software engineers). They'd rather have what few they need running hot and burning out, and a mass of idle people ready to take their place for bottom-dollar.
Even when the output is "guided," I don't trust it. I still review every single line. Every statement. I need to understand what the hell is going on before it goes anywhere. That's non-negotiable. I think it gets better as you build tighter feedback loops and better testing around it, but I won't pretend it's effortless.
But that won't generate the returns Model producers need :) This is the issue. So they will keep pushing nonsense.
That's probably why spec driven development has taken off.
The developers who can't write prompts now get AI to help with their English, and with clarifying their thoughts, so that other AI can help write their code.
That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.
Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?
<Insert astronauts meme “Always has been”>
Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.And
Dijkstra (1976-79) On the foolishness of "natural language programming" (EWD 667)50 years later and we're having the same discussions
Because the instances of this happening are a) random and b) rarely ever happening ?
Now, with AI I feel like I have an assistant engineer with me who can help me build exciting things.
I wrote out a list of topics/key words to ask AI about and teach themselves. I've already set up the integration in an example app I will give them, and I literally have no idea what they are going to build next, but I'm .. thrilled. Today was the first moment I realized, maybe these are the junior engineers of the future. The fact that they have nontechnical backgrounds is a huge bonus - one has a PhD in Biology, one a masters in writing - they bring so much to the process that a typical engineering team lacks. Thinking of writing up this case study/experience because it's been a highlight of my career.
I'm sorry, but to say that nobody is talking about success and just concentrating on failure is entirely disingenuous. You claim the group is a minority, yet all evidence points otherwise. The LLM companies wouldn't be so successful if people didn't believe it was useful.
Your Codex case study with the content creators is fascinating. A PhD in Biology and a masters in writing building internal tools... that's exactly the kind of thing i meant by "you can learn anything now." I'm surrounded by PhDs and professors at my workplace and I'm genuinely positive about how things are progressing. These are people with deep domain expertise who can now build the tools they need. It's an interesting time. please write that up...
It's some cousin of the Fundamental Attribution Error.
I have LLMs write code all day almost every day and these days I really haven't seen this happen. The odd thing here and there (e.g. LLM finds two instances of the same error path in code, decides to emit a log message in one place and throw an exception in the other place) but nothing just plain out wrong recently.
So statistically speaking, when the "AI" consumes all of that as its training data and returns the most likely answer when prompted, what percentage of developers will it be better than?
Anthropic and OpenAI spent most of 2025 focusing almost expensively on improving the coding abilities of their models, through reinforcement learning combined with additional expert curation of training data.
Thank you for teaching me, AI understander. You're definitely not detached from reality one bit. It's me, obviously.
The Average is their top-tier.
But also "most engineers" aren't very good. AIs know tricks that the average "I write code for my dayjob" person doesn't know or frankly won't bother to learn.
In fact, it's pretty easy to conclude what percentage of engineers it's better than: all it does is it consumes as much data as possible and returns the statistically most probable answer, therefore it's gonna be better than roughly 50% of engineers. Maybe you can claim that it's better than 60% of engineers because bottom-of-the-barrel engineers tend to not publish their works online for it to be used as training data, but for every one of those you have a bunch of non-engineers that don't do this for a living putting their shitty attempts at getting stuff done using code online, so I'm actually gonna correct myself immediately and say that it's about 40%.
The same goes for every other output: it's gonna make the world's most average article, the most average song in a genre and so on. You can nudge it to be slightly better than the average with great effort, but no, you absolutely cannot make it better than most.
For most engineers the ability might be there, but the motivation or willingness to write, for example, 20 different test cases checking the 3 line bug you just fixed is fixed FOR SURE usually isn't there. You add maybe 1-2 tests because they're annoying boilerplate crap to write and create the PR. CI passes, you added new tests, someone will approve it. (Yes, your specific company is of course better than this and requires rigorous testing, but the vast majority isn't. Most don't even add the two tests as long as the issue is fixed.)
An AI Agent will happily and without complaining use Red/Green TDD on the issue, create the 20 tests first, make sure they fail (as they should), fix the issue and then again check that all tests pass. And it'll do it in 30 minutes while you do something else.
IMHO, the reasons not to use AI are social, not logical.
I'm not against using AI by any means, but I know what to use it for: for stuff where I can only do a worse than half the population because I can't be bothered to learn it properly. I don't want to toot my own horn, but I'd say I'm definitely better at my niche than 50% of the people. There are plenty of other niches where I'm not.
By leaving the busywork for the drones, this frees up time for the mind to solve the interesting and unsolved problems.
If you feed it only good code, we'd expect a better result, but currently we're feeding it average code. The cost to evaluate code quality for the huge data set is too high.
You can do some basic checks like "does it actually compile", but for the most part you'd really need to go out and do manual categorization, which would be brutally expensive.
And there are a bunch of engineers from certain cultures who don't know what they don't know, but believe that a massive portfolio of slop is better than one or two well-developed projects.
I can only hope that the people training the good coding models know to tell AI that these are antipatterns, not patterns.
Yeah, you come across as someone who thinks that the AI simply spits out the average of the code in its training data. I don't think that understanding is accurate, to say the least.
Are you serious? I've been hearing this constantly. since mid 2025.
The gaslighting over AI is really something else.
Ive also never seen jobs advertised before whose job was to lobby skeptical engineers over about how to engage in technical work. This is entirely new. There is a priesthood developing over this.
I certainly know engineers for which this is true but unfortunately they were never particularly thorough or fast to begin with.
I believe you can tell which way the wind is blowing by looking at open source.
Other than being flooded with PRs high profile projects have not seen a notable difference - certainly no accelerated enhancements. there has definitely been an explosion of new projects, though, most of dubious quality.
Spikes and research are definitely cheaper now.
This threat, while not yet realized, is very real from a strictly economic perspective.
AI or not, any tool that improves productivity can lead to workforce reduction.
Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
You have a choice: fire 5 people, or produce 2,000 loaves per month. But does the city really need that many loaves?
To make matters worse, all your competitors also have the same semi-automatic ovens...
That is actually the case with a lot of bakeries these days. But the one major difference being,the baker can rely with almost 100% reliability that the form, shape and ingredients used will be exact to the rounding error. Each time. No matter how many times they use the oven. And they don't have to invent strategies on how to "best use the ovens", they don't claim to "vibe-bake" 10x more than what they used to bake before etc... The semi-automated ovens just effing work!
Now show me an LLM that even remotely provides this kind of experience.
What is driving companies to want to get rid of people, rather than do more? Is it just short-term investor-driven thinking?
Where is this expanded demand coming from?
Lines of code within the same code base aren't competing to be sold. They either complement each other by adding new features, making the actual product sold more valuable, or one replaces another to make a feature more desirable- look better, work faster, etc.
The market grows if you add new features- your bread now doubles as a floatation device- or you introduce a new line of bread with nuts and berries.
So, the business has to decide- does it fire some workers and pocket the difference until someone else undercuts them, or does it keep the workers and grow the market it can sell to faster?
OTOH, if you fire those workers, it is a certainty that your bakery gets more cash. You can then use that cash to reward your shareholders (a category that conveniently includes you) via buybacks or dividends.
But on your point (which seems to hinge on wish thinking), this infinity of new features you propose for every product still needs those new markets you take for granted to justify their inclusion in the product. However cornering a new market isn't as straightforward as deploying a new feature - we all wish it was. The tech that makes it trivial for one firm to develop these features, makes it trivial for everyone else to build them. This means any new market will be immediately saturated.
Even if the leap of finding new markets was as easy as you think, you still need to explain why this hypothetical company would keep paying millions in avoidable salaries. Because whatever jobs you assign to AI, it won't be any less available to do the work of the human labor.
> If I don’t understand what it’s doing, it doesn’t ship. That’s non-negotiable.
Holy LinkedIn
Hmm, I wonder why!
On the other hand, learning is doing; if it's not at least a tiny bit hard, it's probably not learning. This is not strictly an LLM problem; it's the same issue I have with YouTube educators. You can watch dazzling visualizations of problems in mathematics or physics, and it feels like you're learning, but you're probably not walking away from that any wiser because you have not flexed any problem-solving muscles and have not built that muscle memory.
I had multiple interactions like that. Someone asked an LLM for an ELI5 and tried to leverage that in a conversation, and... the abstraction they came back feels profound to them, but is useless and wrong.
It's possible my brain is not as elastic now in my 40s. Or maybe there's no substitute for doing something yourself (practice problems) and that's the missing part.
The other benefit is that LLMs, for superficial topics, are the most patient teachers ever.
I can ask it to explain a concept multiple times, hoping that it'll eventually click for me, and not be worried that I'd look stupid, or that it'll be annoyed or lose patience.
I could not agree more.
Some things are worth learning deeply, in other cases the easy / fast solution is what the situation calls for.
I've thought recently that some kinds of 'learning' with AI are not really that different from using Cliffs Notes back in the day. Sometimes getting the Cliffs Notes summary was the way to get a paper done OR a way to quickly get through a boring/challenging book (Scarlet Letter, amirite?). And in some cases reading the summary is actually better than the book itself.
BUT - I think everyone could agree that if you ONLY read Cliffs Notes, you're just cheating yourself out of an education.
That's a different and deeper issue because some people simply do not care to invest in themselves. They want to do minimum work for maximum money and then go "enjoy themselves."
Getting a person to take an interest in themselves, in their own growth and development, to invite curiosity, that's a timeless problem.
I've been a fan of Zed Shaw's method for years, of typing out interesting programs by hand. But I've been appreciating it even more now, as a way to stave off the feeling of my brain melting :)
The gross feeling I have if I go for too long without doing cardio, is a similar feeling to when I go for too long without actually writing a substantial amount of code myself.
I think that the feeling of making a sustained effort is itself something necessary and healthy, and rapidly disappearing from the world.
I’ve been reading the OpenBSD lately and it’s quite nice how they’ve split the general OS concepts from the machine dependent needs. And the general way they’ve separated interfaces and implementation.
I believe that once you’ve solve the essential problem, the rest becomes way easier as you got a direction. But doing accidental problem solving without having done the essential one is pure misery.
Importantly, the LLM is not writing code for me. It's explaining things, and I'm coming away with verifiable facts and conceptual frameworks I can apply to my work.
Selectively pick and struggle through things you want to learn deeply. And let AI spoon-feed you for things you don't care as much about.
I've also wanted to play with C and Raylib for a long time and now I'm confident in coding by hand and struggling with it, I just use LLMs as a backstop for when I get frustrated, like a TA during lab hours.
Like do I really get anything out of learning another framework or how some particular library does something?
Picking useEffect() as my second example because it took down CloudFlare, and if you see one with a tell-tale LLM comment attached to it in a PR from your coworkers who are now _never_ going to learn how it works, you can almost be certain it's either unnecessary or buggy.
But there is also a ton of times something isnt at all important to me and I dont want to waste 3 hours on
For instance, retrieving the absolute path an Angular app is running at in a way that is safe both on the client and in SSR contexts has a very clear answer, but there are a myriad of wrong ways people accomplish that task before they stumble upon the Location injectable.
In cases like the above, the LLM is often able to tell you not only the correct answer the first time (which means a lot less "noise" in the process trying to teach you wrong things) but also is often able to explain how the answer applies in a way that teaches me something I'd never have learned otherwise.
We have spent the last 3 decades refining what it means to "learn" into buckets that held a lot of truth as long as the search engine was our interface to learning (and before that, reading textbooks). Some of this rhetoric begins to sound like "seniority" at a union job or some similar form of gatekeeping.
That said, there are also absolutely times (and sometimes it's not always clear that a particular example is one of those times!!) when learning something the "long" way builds our long term/muscle memory or expands our understanding in a valuable way.
And this is where using LLMs is still a difficult choice for me. I think it's less difficult a choice for those with more experience, since we can more confidently distinguish between the two, but I no longer think learning/accomplishing things via the LLM is always a self-damaging route.
It also gives you an avenue to accelerate your learning if that is your goal.
You could learn the windows APIs much faster if you wanted to learn them
AIs allowed me to get on with Python MUCH faster than I was doing myself, and understand more of the arcane secrets of jq in 6 months than I was able in few years before.
And AIs mistakes are brilliant opportunity to debug, to analyse, and to go back to it saying "I beg you pardon, wth is this" :) pointing at the elementary mistakes you now see because you understand the flow better.
Recently I had a fantastic back and forth with Claude and one of my precious tools written in python - I was trying to understand the specifics of the particular function's behaviour, discussing typing, arguing about trade-offs and portability. The thing I really like in it that I always get a pushback or things to consider if I come up with something stupid.
It's a tailored team exercise and I'm enjoying it.
The trick to learning with LLMs is to treat them as one of multiple sources of information, and work with those sources to build your own robust mental of how things work.
If you exclusively rely on official documentation you'll miss out on things that the documentation doesn't cover.
WinAPI docs are pretty accurate and up to date
If the WinAPI docs are solid you can do things like copy and paste pages of them into Claude and ask a question, rather then manually scan through them looking for the answer yourself.
Apple's developer documentation is mostly awful - try finding out how to use the sips or sandbox-exec CLI tools for example. LLMs have unlocked those for me.
Unless you're just taking the LLM answers at face value?
That's always a better signal than anything that official documentation might tell you.
Does it have any threading preconditions? Any weird quirks? Any strange UB? That's stuff you can't find out just by testing. You can ask the LLM, but then you have to read the docs anyway to check its answer
I do a lot of astrophysics. Universally LLMs are wrong about nearly every astrophysics questions I've asked them - even the basic ones, in every model I've ever tested. Its terrifying that people take these at face value
For research at a PhD level, they have absolutely no idea what's going on. They just make up plausible sounding rubbish
It's curious how different people come to very different conclusions about the usefulness of LLMs.
https://youtu.be/PctlBxRh0p4
Every time I ask LLMs questions I know the answers to, its results are incomplete, inaccurate, or just flat out wrong much of the time
The idea that AI is an order of magnitude superior to coders is flat out wrong as well. I don't know who he's talking to
Sure it's not there yet. Give it a few months
I asked chatgpt the other day:
"Where did elements heavier than iron come from?"
The answer it gave was totally wrong. Its not a hard question. I asked it this question again today, and some of it was right (!). This is such a low bar for basic questions
Like, if I want to find out what, I don't know, "GetQueuedCompletionStatus" does. I google
GetQueuedCompletionStatus
Find this page:
https://learn.microsoft.com/en-us/windows/win32/api/ioapiset...
Bam, that's the single source of truth right there. Microsoft's docs are pretty great
If I use an LLM, I have to ask it for the documentation about "GetQueuedCompletionStatus". Then I have to double check its output, because LLMs hallaucinate
Doubly checking its output involves googling "GetQueuedCompletionStatus", finding this page:
https://learn.microsoft.com/en-us/windows/win32/api/ioapiset...
And then reading the docs to validate whether or not what its told me is correct. How does this save me any time?
I have not done win32 programming in 12 years. Maybe you've done it more recently. I'll use an LLM and you look up things manually. We can see, who can build a win32 admin UI that shows a realtime view of every open file by process with sorting, filtering and search on both the files and process/command names.
I estimate this will take me 5 minutes Would you like to race?
I'll write an application without AI that has to be maintained for 5 years with an ever evolving featureset, and you can write your own with AI, and see which codebase is easiest to maintain, the most productive to add new features to, and has the fewest bugs and best performance
I would literally claim that with AI I can work faster and produce higher quality output than any other software engineer who is not using AI. Soon that will be true for all software engineers using AI.
Take it with a grain of salt..
- Socrates
(I think something like this comes up in the Phaedrus)
For programming in general, most learning is worthless. This is where I disagree with you. If you belong to a certain set of cultures, you overindex on this idea that math (for example) is the best way to solve problems, that you must learn all this stuff by this certain pedagogy, and that the people who are best at this are the best at solving problems, which of course is not true. This is why we have politics, and why we have great politicians who hail from cultures that are underrepresented in high levels of math study, because getting elected and having popular ideas and convincing people is the best way to solve way more problems people actually have than math. This isn't to say that procedural thinking isn't valuable. It's just that, well, jokes on you. ChatGPT will lose elections. But you can have it do procedural thinking pretty well, and what does the learning and economic order look like now? I reject this form of generalization, but there is tremendous schadenfreude about, well the math people are destroying their own relevance.
All that said, my actual expertise, people don't pay for. Nobody pays for good game design or art direction (my field). They pay because you know Unity and they don't. They can't tell (and do not pay for) the difference between a good and bad game.
Another way of stating this for the average CRUD developer is, most enterprise IT projects fail, so yeah, the learning didn't really matter anyway. It's not useful to learn how to deliver better failed enterprise IT project, other than to make money.
One more POV: the effortlessness of agentic programming makes me more sympathetic to anti intellectualism. Most people do not want to learn anything, including people at fancy colleges, including your bosses and your customers, though many fewer in the academic category than say in the corporate world. If you told me, a chatbot could achieve in hours what would take a world expert days or weeks, I would wisely spend more time playing with my kids and just wait. The waiters are winning. Even in game development (cultural product development generally). It's better to wait for these tools to get more powerful than to learn meaningless arcana.
But no amount of politics and charisma will calculate the motions of the planets or put satellites in orbit.
A nation needs more than just influencers and charlatans.
the government invented computers. you need politics to fund all of this. you are talking about triumphs of politics as much as invention. i don't know why you think i am pro influencer or charlatan...
Offloading completely the hard work and just getting a summary isn't really learning.
For the record though, I love agentic coding. It deals with the accumulated cruft of software for me.
And creates more at record speeds!
Personally I'm quite pleased with this inversion.
If execution no longer matters, then what possible ideas exist out there that both are highly valuable as well as only valuable to the first mover? If the second person to see the value in the idea can execute it in a weekend using AI tools, what value is there in the idea to begin with?
In fact the second mover advantage seems to me to be even larger than before. Let someone else get the first version out the door, then you just point your AI bot at the resulting product to copy it in a fraction of the time it took the original person to execute on it.
If anything, ideas seem to be even cheaper to me in this new world. It probably just moves what bits of execution matter even more towards sales and marketing and hype vs. executing on the actual product itself.
I think there might be some interesting spaces here opening up in the IP combined with "physical product" space. Where you need the idea as well as real-world practical manufacturing skills in order to execute. That will still be somewhat of a moat for a little while at least, but mostly at a scale where it's not worth an actual manufacturer from China to spin up a production line to compete with you at scale.
You might get head start but just like a bicycle race the one behind you will be more efficient because you already solved the domain problems and figured out the UX.
Eventually you will have to tell people what the idea is, even if it is at product launch. And then, if execution is as cheap and easy as they claim, then anyone can replicate the idea without having to engage with the person in the first place.
Ideas will never not be cheap.
Ideas are cheap and don't need to be protected. Your taste, execution, marketing, UX, support, and all the 1000 things that aren't the code still matter. The code will appear more quickly now: You still need to get people to use it or care about it.
I've found almost without fail that you have more to gain in sharing an idea and getting feedback (both positive and negative) before/while you build the thing than you do in protecting the idea with the fear that as soon as someone hears it they'll steal it and do it better than you.
(The exception I think is in highly competitive spaces where ideas have only a short lifetime -- eg High Frequency Trading / Wall Street in general. An idea for a trade can be worth $$ if done before someone else figures it out, and then it makes sense to protect the idea so you can make use of it first. But that's an extremely narrow domain.)
But if you come from a technical background and this is your first time building a product, you'll soon learn that it is so damn hard to get users, especially *paying* ones.
I was there. I built something, shared it, prayed people would notice. The truth is most of the time your product fails. Better explore the problem you are trying to solve first, share your idea if necessary, and collect feedback. You'll have a much clearer picture of what you need to do from there.
Instead of asking for answers, I ask for specific files to read or specific command line tools with specific options. I pipe the results to a file and then load it into the CLI session. Then I turn these commands into my own scripts and documentation (in Makefile).
I forbid the model wandering around to give me tons of irrelevant markdown text or generated scripts.
I ask straight questions and look for straight answers. One line at a time, one file at a time.
This gives me plenty of room to think what I want and how I get what I want.
Learning what we want and what we need to do to achieve it is the precious learning experience that we don’t want to offload to the machine.
I've also taken to using the Socratic Method when interrogating an LLM. No loaded questions, squeaky clean session/context, no language that is easy to misinterpret. This has worked well for me. The information I need is in there, I just need to coax it back out.
I did exactly this for an exercise a while back. I wanted to learn Rust while coding a project and AI was invaluable for accelerating my learning. I needed to know completely off-the-wall things that involved translating idioms and practices from other languages. I also needed to know more about Rust idoms to solve specific problems and coding patterns. So I carefully asked these things, one at a time, rather than have it write the solution for me. I saved weeks if not months on that activity, and I'm at least dangerous at Rust now (still learning).
https://gist.github.com/ontouchstart/bc301a60067f687b65dad64...
(This is an ongoing experiment, it doesn't matter what model I use.)
This is not a dig at AI. If I take this article at face value, AI makes people more productive, assuming they have the taste and knowledge to steer their agents properly. And that's possibly a good thing even though it might have temporary negative side effects for the economy.
>But the AI is writing the traversal logic, the hashing layers, the watcher loops,
But unfortunately that's the stuff I like doing. And also I like communing with the computer: I don't want to delegate that to an agent (of course, like many engineers I put more and more layers between me and the computer, going from assembly to C to Java to Scala, but this seems like a bigger leap).
I expect there are going to be a bunch of people in similar situations to you over the next few years, I'm interested to know where they end up.
> "I cannot wait to castrate a 3000 pound bull as it kicks my head in"
How I feel about merging an AI-generated PR these days and waiting for the issues
is my favorite quote from the video.
There's several factors which are super depressing:
1. Economic productivity, and what it means for a company to be successful have become detached from producing good high quality products. The stock market is the endgame now
2. AI is attempting to strongly reject the notion that developers understanding their code is good. This is objectively wrong, but its an intangible skill that makes developers hard to replace, which is why management is so desperate for it
3. Developers had too much individual power, and AI feels like a modern attempt at busting the power of the workforce rather than a genuine attempt at a productivity increase
4. It has always been possible to trade long term productivity for short term gains. Being a senior developer means understanding this tradeoff, and resisting management pressure to push something out NOW that will screw you over later
5. The only way AI saves time in the long term is if you don't review its output to understand it as well as if you'd written it yourself. Understanding the code, and the large scale architecture is critical. Its a negative time savings if you want to write high-long-term-productivity code, because we've introduced an extra step
6. Many developers simply do not care about writing good code unfortunately, you just crank out any ol' crap. As long as you don't get fired, you're doing your job well enough. Who cares about making a product anymore, it doesn't matter. AI lets you do a bad job with much less effort than before
7. None of this is working. AI is not causing projects to get pushed out faster. There are no good high quality AI projects. The quality of code is going down, not up. Open source software is getting screwed
Its an extension of the culture where performance doesn't matter. Windows is all made of react components which are each individually a web browser, because the quality of the end product no longer matters anymore. Software just becomes shittier, because none of these companies actually care about their products. AAA gaming is a good example of this, as is windows, discord, anything google makes, IBM, Intel, AMD's software etc
A lot of this is a US problem, because of the economic conditions over there and the prevalence of insane venture capitalism and union busting. I have a feeling that as the EU gets more independent and starts to become a software competitor, the US tech market is going to absolutely implode
This like how my grandpa said he was glad to get out of engineering before they started using computers.
The technology i used was the fun technology. The technology you use is the un-fun technology.
But I think the future of programming is english.
Agent frameworks are converging on a small set of core concepts: prompts, tools, RAG, agent-as-tool, agent handoff, and state/runcontext (an LLM-invisible KV store for sharing state across tools, sub-agents, and prompt templates).
These primitives, by themselves, can cover most low-UX application business use cases. And once your tooling can be one-shotted by a coding agent, you stop writing code entirely. The job becomes naming, describing, and instructing and then wiring those pieces together with something more akin to flow-chart programming.
So I think for most application development, the kind where you're solving a specific business problem, code stops being the relevant abstraction. Even Claude Code will feel too low-level for the median developer.
The next IDE looks like Google Docs.
I would say prompting is not here to stay. It’s just temporary “tech”
That's precisely what peoples are bad at. If people don't grasp (even intuitively) the concept of finite state machine and the difference between states and logic, LLMs are more like a wishing well (vibes) than a code generator (tooling for engineering).
Then there's the matter of technical knowledge. Software is layers of abstraction and there's already abstraction beneath. Not knowing those will limit your problem solving capabilities.
Where do you draw the line between just enough guidance vs too much hand holding to an agent? At some point, wouldn't it be better to just do it yourself and be done with the project (while also build your muscle memory, experiences and the mental model for future projects, just like tons of regular devs have done in the past)
I'm not asking an agent to build me a full-stack app. That's where you end up babysitting it like a kindergartener and honestly you'd be faster doing it yourself. The way I use agents is focused, context-driven, one small task at a time.
For example: i need a function that takes a dependency graph, topologically sorts it, and returns the affected nodes when a given node changes. That's well-scoped. The agent writes it, I review it, done.
But say I'm debugging a connection pool leak in Postgres where connections aren't being released back under load because a transaction is left open inside a retry loop. I'm not handing that to an agent. I already know our system. I know which service is misbehaving, I know the ORM layer, I know where the connection lifecycle is managed. The context needed to guide the agent properly would take longer to write than just opening the code and tracing it myself.
That's the line. If the context you'd need to provide is larger than the task itself, just do it. If the task is well-defined and the output is easy to verify, let the agent rip.
The muscle memory point is real though. i still hand-write code when I'm learning something new or exploring a space I don't understand yet. AI is terrible for building intuition in unfamiliar territory because you can't evaluate output you don't understand. But for mundane scaffolding, boilerplate, things that repeat? I don't. llife's too short to hand-write your 50th REST handler.
I'm sure plenty of people disagree with me. But I'm a good hand programmer, and I just don't feel the need to do that any more. I got into this to build things for other people, and AI is letting me do that more efficiently. Yes, I've had to give up a puritan approach to code quality.
I think frameworks (especially those that have testing built-in) are even more important as guardrails now.
< I haven’t written a boilerplate handler by hand in months. I haven’t manually scaffolded a CLI in I don’t know how long. I don’t miss any of it.
Sounds like the author is confused or trying too hard to please the audience. I feel software engineering has higher expectation to move faster now, which makes it more difficult as a discipline.
I personally code data structures and algorithms for 1 - 2 hrs a day, because I enjoy it. I find it also helps keeps me sharp and prevents me from building too much cognitive debt with AI generated code.
I find most AI generated code is over engineered and needs a thorough review before being deployed into production. I feel you still have to do some of it yourself to maintain an edge. Or at least I do at my skill level.
What does this mean? You do leet code problems a few hours a day? Or go through a text book? Genuinely curious.
This isn't what many of us probably would have wanted, but I think the public blowback when "AI-coded" systems start failing is going to drive us there. (Note to passing hype-men: I did not say they will fail at higher rates than human-coded systems! I happen to believe this, but it is not germane to the argument - only the public perception matters here.)
This is the first time that I feel a level of anxiety when I am not actively doing it. What a crazy shift that I am still so excited and enamored by the process after all of this time.
But there's also the double edged sword. I am also having a really hard time moderating my working hours, which I naturally struggle with anyway, even more. Partly because I am having so much fun and being so productive. But also because it's just so tempting to add 1 more feature, fix one more bug.
Except the rest of the article strongly implies he feels pretty good about it, assuming you can properly supervise your agents.
I'm not sure how this sustains though; like, I can't help but think this technology is going to dull a lot of people's skills, and other people just aren't going to develop skills in the first place. I have a feeling a couple years from now this is going to be a disaster (I don't think AGI is going to take place and I think the tools are going to get a lot more expensive when they start charging the true costs)
All your incantations can't protect you
I'm being a little facetious, but I don't think it's far off the mark from what TFA is saying, and it matches my experience over the past few months. The worst architects we ever worked with were the ones who couldn't actually implement anything from scratch. Like TFA says, if you've got the fundamentals down and you want to see how far you can go with these new tools, play the role of architect for a change and let the agents fly.
Once you have your 50k line program that does X are you really going to go in there and deeply review everything? I think you're going to end up taking more and more on trust until the point where you're hostage to the AI.
I think this is what happens to managers of course - becoming hostage to developers - but which is worse? I'm not sure.
I'm sure some people are having fun that way.
But I'm also sure some people don't like to play with systems that produce fuzzy outputs and break in unexpected moments, even though overall they are a net win. It's almost as if you're dealing with humans. Some people just prefer to sit in a room and think, and they now feel this is taken away from them.
I have immense respect for the senior engineers who came before me. They built the systems and the thinking that everything I do now sits on top of. I learned from people. Not from AI. The engineers who reviewed my terrible pull requests, the ones who sat with me and explained why my approach was wrong. That's irreplaceable. The article is about where I think things are going, not about what everyone should enjoy.
If you're going in the right direction, acceleration is very useful. It rewards those who know what they're doing, certainly. What's maybe being left out is that, over a large enough distribution, it's going to accelerate people who are accidentally going in the right direction, too.
There's a baseline value in going fast.
Maybe to the people writing the invoices for the infra you're renting, sure. Or to the people who get paid to dig you out of the consequences you inevitably bring about. Remember, the faster the timescale, the worse we are wired to effectively handle it as human beings. We're playing with a fire that catches and spreads so fast, by the time anyone realizes the forest is catching and starting to react, the entire forest is already well on the way to joining in the blaze.
I suspect this has been said in one form or another since the discovery of fire itself.
I don't understand how people are making anything that has any level of usefulness without a feedback loop with them at the center. My agents often can go off for a few minutes, maybe 10, and write some feature. Half of the time they will get it wrong, I realize I prompted wrong, and I will have to re-do it myself or re-do the prompt. A quarter of the time, they have no idea what they're doing, and I realize I can fix the issue that they're writing a thousand lines for with a single line change. The final quarter of the time I need to follow up and refine their solution either manually or through additional prompting.
That's also only a small portion of my time... The rest is curating data (which you've pretty much got to do manually), writing code by hand (gasp!), working on deployments, and discussing with actual people.
Maybe this is a limitation of the models, but I don't think so. To get to the vision in my head, there needs to be a feedback loop... Or are people just willing to abdicate that vision-making to the model? If you do that, how do you know you're solving the problem you actually want to?
I use AI everyday for coding. But if someone so obviously puts this little effort into their work that they put out into the world, I don’t think I trust them to do it properly when they’re writing code.
Some tells that you might wanna look at in your writing, if you truly did write it yourself without Any LLM input are these contrarian/pivoting statements. Your post is full of these and it is imo the most classic LLM writing tell atm. These are mostly variants of the 'Its not X but Y" theme:
- "Not whether they've adopted every tool, but whether they're curious"
- "I still drive the intuition. The agents just execute at a speed I never could alone."
- "The model doesn't save you from bad decisions. It just helps you make them faster."
- "That foundation isn't decoration. It's the reason the AI is useful to me in the first place."
- "That's not prompting. That's engineering"
It is also telling that the reader basically cant take a breather most of the sentences try to emphasize harder than the last one. There is no fluff thought, no getting side tracked. It reads unnatural, humans do not think like this usually.
First we develop the machines, then we contort the entire social and psychic order to serve their rhythms and facilitate their operation.
I've been shifting from being the know-it-all coder who fixes all of the problems to a middle manager of AIs over the past few months. I'm realizing that most of what I've been doing for the last 25 years of my career has largely been a waste of time, due to how the web went from being an academic pursuit to a profit-driven one. We stopped caring about how the sausage was made, and just rewarded profit under a results-driven economic model. And those results have been self-evidently disastrous for anyone who cares about process or leverage IMHO. So I ended up being a custodian solving other people's mistakes which I would never make, rather than architecting elegant greenfield solutions.
For example, we went from HTML being a declarative markup language to something imperative. Now rather than designing websites like we were writing them in Microsoft Word and exporting them to HTML, we write C-like code directly in the build product and pretend that's as easy as WYSIWYG. We have React where we once had content management systems (CMSs). We have service-oriented architectures rather than solving scalability issues at the runtime level. I could go.. forever. And I have in countless comments on HN.
None of that matters now, because AI handles the implementation details. Now it's about executive function to orchestrate the work. An area I'm finding that I'm exceptionally weak in, due to a lifetime of skirting burnout as I endlessly put out fires without the option to rest.
So I think the challenge now is to unlearn everything we've learned. Somehow, we must remember why we started down this road in the first place. I'm hopeful that AI will facilitate that.
Anyway, I'm sure there was a point I was making somewhere in this, but I forgot what it was. So this is more of a "you're not alone in this" comment I guess.
Edit: I remembered my point. For kids these days immersed in this tech matrix we let consume our psyche, it's hard to realize that other paradigms exist. Much easier to label thinking outside the box as slop. In the age of tweets, I mean x's or whatever the heck they are now, long-form writing looks sus! Man I feel old.
I wasn't quite sure though. Sometimes it's clearly GPT, sometimes clearly Claude, and this article was like a blend.
That’s the “money quote,” for me. Often, I’m the one that causes the problem, because of errors in prompting. Sometimes, the AI catches it, sometimes, it goes into the ditch, and I need to call for a tow.
The big deal, is that I can considerably “up my game,” and get a lot done, alone. The velocity is kind of jaw-dropping.
I’m not [yet] at the level of the author, and tend to follow a more “synchronous” path, but I’m seeing similar results (and enjoying myself).
- Ones who see it generated something bad, and blame the AI.
- Ones who see it generated something bad, and revert it and try to prompt better, with more clarity and guidance.
- Ones that use it as a “pair partner,” as opposed to an employee.
Thanks for the implicit insult. That was helpful.
That would've taken me 3 months a year ago, just to learn the syntax and evaluate competing options. Now I can get sccache working in a day, find it doesn't scale well, and replace it with recc + buildbarn. And ask the AI questions like whether we should be sharding the CAS storage.
The downside is the AI is always pushing me towards half-assed solutions that didn't solve the problem. Like just setting up distributed caching instead of compilation. It also keeps lying which requires me to redirect & audit its work. But I'm also learning much more than I ever could without AI.
Dunning-Kruger as a service. Thank God software engineers are not in charge of building bridges.
Looking forward to your post-mortem.
This is hyperbole, right? In what world does it take 3 months to learn the syntax to anything? 3 days is more than enough time.
oh no... this is one of my "uncanny valley" AI tropes
We’re getting there..
“Hey Claude, you have a bunch of skills defined, some mcps, and memory filled with useful stuff. I want to use you on a machine accessible over SSH at <host>, can you clone yourself over?”
There are two problems left, though.
One is, laypersons don't understand the difference between "guided" and "vibe coded". This shouldn't matter, but it does, because in most organizations managers are laypersons who don't know anything about coding whatsoever, aren't interested by the topic at all, and think developers are interchangeable.
The other problem is, how do you develop those instincts when you're starting up, now that AI is a better junior coder than most junior coders? This is something one needs to think about hard as a society. We old farts are going to be fine, but we're eventually going to die (retire first, if we're lucky; then die).
What comes after? How do we produce experts in the age of AI?
That feedback loop, hundreds of times a day, compresses years of learning into months. The catch is you need guardrails — tests that fail when the AI drifts, review cycles you can't skip, architecture constraints it must respect.
That's what builds the instincts: not the AI doing the work for you, but the AI showing you where your understanding breaks down, fast enough that you actually learn from it. Just-In-Time Learning.
The foundation I built came from years of writing bad code and understanding why it was bad. I look at code I wrote 10 years ago and it's genuinely terrible. But that's the point. It took time, feedback, reading books, reviewing other people's work, failing, and slowly building the instinct for what good looks like. That process can't be skipped.
If AI shortens the path to output, educators have to double down on the fundamentals. Data structures, systems thinking, understanding why things break. Not because everyone needs to hand-write a linked list forever, but because without that foundation you can't tell when the AI is wrong. You can't course-correct what you don't understand.
Anyone can break into tech. That's a good thing. But if someone becomes a purely vibe-coding engineer with no depth, that's not on them. That's on the companies and institutions that didn't evaluate for the right things. We studied these fundamentals for a reason. That reason didn't go away just because the tools got better.
People always learn the things they need to learn.
Were people clutching their pearls about how programmers were going to lack the fundamentals of assembly language after compilers came along? Probably, but it turned out fine.
People who need to program in assembly language still do. People who need to touch low-level things probably understand some of it but not as deeply. Most of us never need to worry about it.
A compiler is deterministic. It's a function; it transforms input into output and validates it in the process. If the input is incorrect it simply throws an error.
AI doesn't validate anything, and transforms a vague input into a vague output, in a non-deterministic way.
A compiler can be declared bug-free, at least in theory.
But it doesn't mean anything to say that the chain 'prompt-LLM-code' is or isn't "correct". It's undecidable.
However, in practice we don't care because it's good enough for 99% of the code. Sure, it could be like 5x better at least but who cares, our computers are fast enough.:tm:
AI is the same. Is it as good as the best human output? Definitely not. Does it do the job most of the time? Yes, and that's what people care about.
(But yes, for high-impact work - there's many people who know how to read x64 asm or PTX/SASS and they do insane stuff.)
Not usually they aren't. They can be made to be, but it requires extra effort and tradeoffs. Hence why there is a lot of work put into reproducible builds — something you would get for free if compilers were actually always deterministic.
Unless you are taking a wider view and recognizing that, fundamentally, nothing running on a computer can be nondeterministic, which is definitely true.
No, they don't. Which why a huge % of people are functionaly illiterate at the moment, know nothing about finance and statistics and such and are making horrendous decisions for their future and their bottom line, and so on.
There is also such a thing as technical knowledge loss between generations.
We might all be AI users now, though.
And then add on top the environmental impact of all of the money that programmer gets from programming - travels around the world, buying large houses, ...
If you care about the environment, you should want AI's replacing humans at most jobs so that they can no longer afford traveling around the world and buying extravagant stuff.
Your reasoning could be effective if we bounded the computing resources usable by all AI in order to meet carbon reduction goals.
[0] https://en.wikipedia.org/wiki/Rebound_effect_(conservation)
The programmer will continue to exist as a consumer of those things even if they get replaced by AI in their job.
"You'll be fine digging trenches, programmer", they said.
Seriously, though:
...so that they can no longer afford traveling around the world...
This is either a sarcasm I failed to parse, or pure technofascism.
So long as their productivity was on par with the rest of the team there was no issue.
Suddenly, everyone needs to use this new tool (which we haven't proven to actually be effective) and if you don't you don't belong in the industry.
Emphasis added. And anyway, for most software dev in most shops it wasn't true; most development takes place in whatever IDE the group/organization standardized on for the task, to make sure everyone gets proper tooling and to make collaboration and information sharing easier. Think of all the Java enterprise software developed by legions of drones in the 2000s and 2010s. They all used Eclipse, because Eclipse is what they were given.
It's only with the emergence of whiny, persnickety Unix devs who refused to leave the comforting embrace of their editor of choice that shops in the internet/dotcom/startup tradition embraced a "use whatever tools you want" philosophy. They had uncharacteristically enormous leverage over the tech stack being deployed in such businesses and could force employers to make that concession. And anyway, what some of them could do with vi blew the boss's mind.
It is true that we don't have a whole lot of hard data from large organizations that show AI productivity improvements. But absence of evidence is not evidence of absence. Turns out, most large organizations just haven't adopted AI in the amount and ways that could make a big impact.
But we have enough anecdata from competent developers to suggest that the productivity gains are huge. So big, AI not only lets you do your normal tasks many times faster, it puts projects within reach that you would not have countenanced before because they were too complex or tedious to be worth the payoff.
So no. Refusing to use AI is just pure bloodymindedness at this point—like insisting on using a keypunch while everyone around you discovers the virtues of CRT terminals and timesharing. There were people like this even in the 1970s when IBM finally came around and made timesharing available in their mainframes. Those people either got up to speed or moved on to a different profession. They couldn't keep working the way they'd been working because the productivity expectations changed with the availability of new technology.
They had enormous leverage because they were more productive then the drones who use whatever tools they are handed and lack the curiosity to use anything else. These breathless reports of increased productivity are constant, but why is there no evidence of that productivity increase otherwise? Why hasn't there been a surge of side-project video games on Steam? Why is github down so often despite Microsoft's commitment to AI?
The AI tools make it easier to do things that were already easy, but the minute your code gets interesting these tools are an absolute mess.