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.

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.

Prototyping is a perfectly fine use of LLMs - its easier to see a closer-to-finished good than one that is not.

But that won't generate the returns Model producers need :) This is the issue. So they will keep pushing nonsense.

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

You are correct, but this is not a new role. AI effectively makes all of us tech leads.

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.

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.

Paragraphs, man. Paragraphs.

Sure but his post is very valid. Nice post fella.

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've managed small dev teams in small startups. Yeah, it's not quite 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.

I envy you to be honest. My muse doesn't bring me visions of sublime beauty. No melodies, landscapes, scenes or plays in the mind's eye. Just blueprints, system diagrams, feedback loops, crystalized reasoning, probable futures, things going wrong, breaking. Never in a way that seems to be communicable to galvanize more than a couple people who probably already know what I'm seeing deep down in their hearts. But... I'm trying. I flubbed the middle. The point was, no one at the bottom can unseat the people at the top or their optimization function from inside the system, playing by it's rules. Unless we all align on something to force a change; the system's stable & will remain so. There's just one outcome, and it ain't pretty for most of us. I can't even bring myself to throw my weight in as much as I used to, because I just can't not see the patterns everywhere I look now. Didn't mean to be rude. Just. Tired. So, so, very tired. The kind sleep won't fix. Whatever your art form... May you get good inspiration, and may the work to realize lighten your soul in the doing, and everyone's around you. Mine... Certainly doesn't.

Appreciate this very direct and real share. I pray that you find your way to a more merciful part of this life game, or that somehow all that you're going through now is worth it for something later.

Yet another wannabe systems engineer cheers the robbery and loss of job of real systems engineers.

Calling somebody a wannabe systems engineer is unneccessarily antagonistic.

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.

Standard AI promotion talking points. Show us the frigging code or presumably your failed slow website that looks like a Bootcamp website from 2014.

I don't mean to be rude, but you write like a chatbot. This makes sense, to be honest.

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.

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.

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.

I hear you, but I have subtle disagreements:

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

Honestly, based on where this is going, I suspect we might agree more than it appears in this short exchange.

As for the point about complexity, I will meditate on it.

My first cut is that what you're getting at is something like: you're using "complexity" in the technical sense of the word, in which case we're in the realm of so-called "wicked problems" and such. There is some kind of 'making sense' that goes beyond 'mere ideas,' or at the very least something like "throw more minds and hands at the problem," in this context, is the wrong attitude.

In such a world, a machine that amplifies human effort (while obscuring it) is not the right tool for the job—more than likely you find yourself spinning around an attractor basin.

I personally have a tentative conclusion that I specifically am able to avoid this by amplifying certain strategies I've developed over my life, but really, I don't have solid confirmation yet.

In any event, I'm enjoying the experiment, but I'll reflect on why you seem to be certain about it.

I agree and think we're mostly on the same page fwiw. But there are parts I disagree with. We are more aligned than misaligned. But I do want to clear some things up

  > you're using "complexity" in the technical sense of the word

Unfortunately complexity is a bit more complex than this and I think it's leading to some miscommunication. Even in technical settings complexity is overloaded. Something can be computationally complex but easy to understand. Something can be conceptually complex, but trivial to compute. I do really mean "complexity is complex".

But I am using it in both senses. I'll make a pretty straight forward argument here. As we advance on any given topic it becomes harder to advance, right? Just take something simple like playing a video game. You start from nothing and then you get a lot better simply by figuring out the controls. But as you progress towards the "professional" level it both gets computationally harder to advance (it requires more time and training) as well as conceptually harder (as little details and the number of things you need to consider increases). You have to process more information and you have to account for more information. Another way to see this is with a mathematical example: a Taylor Series. A first order approximation is relatively easy to compute but it quickly grows as you want your accuracy to increase. And the relationship isn't linear...

  > I personally have a tentative conclusion that I specifically am able to avoid this by amplifying certain strategies I've developed over my life

I can't answer this. I'm just some dude on the internet and have no idea about you. So my response shouldn't be taken in that way.

What I can do is ask an important question. Are you able to confirm you are unique or are you just tricking yourself?

Either could be true, right? I mean we put mental defenses around us all the time. There's so much crazy shit we treat as mundane. I mean just a solar flare being the size of a dozen earths and we treat it like our little minds can comprehend that and make it mundane. We like to convince ourselves that we understand things much better than we actually do. It's normal, but recognition of it is important to help us continue moving forward, right? To question what we believe. Since our understanding is never perfect, there's always more, but our brains like to feel done as that feels accomplished.

It certainly does not help that we're working with tools that are trained for human preference. I use them too. I am an AI researcher even. But I think we also need to be careful. The same objective we use to train these systems to be accurate and sound natural in their speech also maximizes their ability to deceive us. It is a really tricky thing, so I think it is also something we need to be extremely cautious about. If we don't believe we could be the fool then that makes us the biggest fool of them all, right? So how do we find out if we've been fooled or not? I don't think that's so easy and I honestly don't have an answer. There's a lot of complexity to this as you dig in and... complexity is complex.

Yeah, I know what you mean. I do my best to check myself and also run things by people I trust, but there's an ever-present risk I'm going insane.

As a test, I've been attempting an incredibly complex project that goes far beyond my abilities as a kind of deliberate worst-case-scenario. It's more or less a programming language for a very specific purpose that compiles to a custom bytecode and runs on a custom runtime with specific performance guarantees.

I've spent part of the last month iterating on a formal model of the system and various specifications. Along the way, I teach myself how to understand and critique the part of the system I'm working on, however I also deliberately keep things just beyond my understanding by opportunistically pulling in concepts from various sources ... algebraic topology, obscure corners of PL, concepts plucked from similar systems. It's a complete monstrosity with, now, hundreds of supporting documents, research spikes, processed references, critique passes, etc.

If I'm able to complete this project and have it work as expected, I think I'll have learned a lot about what is or isn't possible. If the current design does in fact work, I'm fairly confident I'll have advanced the state of the art in the niche field I'm working in.

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

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

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

Oh, we're quoting Dijkstra? I'll add one :)

  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

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

The "formal letter" framing is right, and spec-driven development takes it further: you are not just writing clearly, you are decomposing the request into named sections that the model can reason about independently.

Role, context, objective, constraints, output format. These map almost directly to how a well-written spec is structured. The difference between a vague prompt and a good one is usually that the good one has all those pieces present, even if implicitly. Making them explicit and separate removes the ambiguity.

Built github.com/Nyrok/flompt around this: a visual canvas to decompose prompts into those blocks and compile to XML. The spec-driven angle validates why structure beats raw text.

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?

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.

This is the positive side of AI and that's inspiring. I have a friend who is into digital marketing but now he has automated most of the processes and moving towards learning to code at the side. Within a year I can say he is on par with a junior dev and now understands if I explain something technical.

> But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.

Because the instances of this happening are a) random and b) rarely ever happening ?

Quite frankly, if AI can write better code than most of your engineers "hundreds of times", then your hiring team is doing something terribly wrong.

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?

In other words, there's probably a market for a model trained on a curated collection of high-quality code.

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.

That is what we have today - it's why Opus 4.5+ and GPT-5.2+ are so much better at driving coding agents than previous models were.

These people also prefer plastic averaged-out images of AI girls to real ones.

The Average is their top-tier.

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.

Silly old me, how could've I forgotten about such drastic improvements between say Sonnet 3.7 and Sonnet 4.6. It's 500x better now!

Thank you for teaching me, AI understander. You're definitely not detached from reality one bit. It's me, obviously.

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?

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.

This is kind of like saying a kid can never become a better programmer than the average of his teachers.

IMHO, the reasons not to use AI are social, not logical.

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.

Yeah, but it's been trained on the boring, repetitive stuff, and A LOT of code that needs to be written is just boring, repetitive stuff.

By leaving the busywork for the drones, this frees up time for the mind to solve the interesting and unsolved problems.

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.

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.

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.

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

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

>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 just can’t compete in speed and thoroughness

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.

Maybe the bottleneck for most high profile open source is PR review and not coding?

The most thorough review is done when you write the code, it takes much more effort to be as thorough when you read it as when you write it.

So if what you say is true then agentic coding will be net negative for same quality.

I've been by far the fastest engineer everywhere I've worked. I've produced 1000s of lines of code in a single day when I was really into it. I have nearly 500 Github repositories and almost all of them is a real open source application that does something useful. Think what you want though.

you’ve been hearing that since mid 2025 bc that’s when it became true.

Their story is clearly fake. No one is getting screenshots of broken code texted to them so often that it's daily, and if they did, everyone must hate them.

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

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.

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.

> We can in fact just NOT do things!

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.

> We can in fact just NOT do things!

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.

If it helps, I would consider learning about and deploying local LLMs (llama.cpp etc), if you have the hardware (and it doesn't take all that much hardware at all). They're nowhere near as fast as LLM providers, but they come fairly close in overall quality (including agentic workflows).

The reason that I suggest this is that not only does running locally democratize AI (while AI democratizes software), it solves a lot of the discomfort surrounding the new reliance, dependence, data, and trust given to LLM providers. Basically it removes a lot of the "ick" surrounding LLMs, while also hedging any bets that the investment schemes of LLM providers are unsustainable. You may also hedge bets surrounding "owning" the maintenance of the machines that replace you.

I don't know, it's a small thing that makes me feel a little better during this tumultuous time.

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.

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

You can only speak for 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.

Congrats on that.

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

Good for you! Most people will, though. If I hadn't learnt JavaScript, I couldn't work on a large chunk of the projects that put bread on the table for the past 5-10 years.

If most folks don't learn AI (or its shortcomings and practicalities of it), then they will not be as competitive in the job market. Corpos don't care about the flaws.

That's not really true yet; most of the companies are being a lot more hesitant than individual developers (the companies have legal and TCO worries the devs themselves don't). It's possible what you're describing will become true, but that's not the present

So how will progress be made in our field, in your scenario of the future?

It's both an obvious consequence of how they operate, and an easily observable reality, that even the best models utterly fail at any task that is even slightly outside of the space spanned by their training set. In this future, software in 2022 was as good and as capable as it was ever going to get. In which case -- fuck, I had higher hopes for what computers and software would be able to achieve when I started in this business 20 years ago, than this sorry state of affairs. We were finally getting some traction on the idea that we urgently need to work on security, reliability, stability, etc., and suddenly we're all supposed to be excited about heading full speed the other way.

> I swear, some people in this field see no value in their programming work

And others see too much value in their work.

Yes, we should punish care and craftsmanship. That's a recipe for success.

Obsolescence is not punishment.

Lol. Im a CEO and Ive re-vamped my hiring process that has nothing to do with writing code.

I test to see the way people think now. People like you would pass my interview.

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.

This takes the cake for one of the strangest replies I've ever received on here.

I'm not sure how or indeed why you draw lines from what I said to my life situation... which is relevant how?

What I apparently did not do a good enough job of conveying is that those "data from multiple sources" get cited and then people immediately reply with "those are old studies". It's circular in the same way that arguing with anti-vax people is circular.

The difference is that unlike vaccines, it's very easy for someone to see how productive they are when using LLMs properly. It's not a subtle difference.

Hence the frustration with people who keep insisting that we're imagining our own productivity. It's not a good faith inquiry.

OK, glad to hear I was mistaken, but it certainly seemed like about halfway through your first response you went off the rails and decided to take my question as some sort of personal affront. It was not the strangest response I've had on HN, but one of the strangest. I could go through with a full analysis of why I thought "this guy is having problems", but that would take a long time and as you say you aren't I guess it isn't particularly useful.

I guess we aren't going to get anything meaningful between us on this subject, because you seem to think it is like arguing with an anti-vaxxer, which funny enough I thought the same thing,

So fine, you experience a gain, you just do, and it is so clear and evident you don't need to guard yourself against being deluded despite studies suggesting that gain is not there. That seems crazy to me, I would doubt and want to verify my gain if I read a study suggesting the gain was illusory. No meaningful convergence seems possible between needing verification and not needing verification.

I like remus' comment to your previous message; you're telling a guy with a chainsaw who is busy chopping down trees at lightning speed that he should stop and defend his daily experience against some studies that suggest tree chopping speeds are not what they seem.

At some point you just have to shrug and get back to work chopping down 3-5x more trees than you did last year.

Writing software is not chopping trees, though.

For instance, there is a lot of evidence (and intuition, frankly) to the argument that while LLM increase superficial, short-term productivity, they also cause an extreme accumulation in technical debt that may more than wipe out any initial, fast progress down the line.

If you aren't reviewing the changes its proposing, you deserve what's coming to you.

To lay it out, Im pretty firmly pro-AI.

Putting it succinctly, these kind of conversations feel weird because it's like asking whether carpenters are faster using power tools or hand tools. If you've used power tools it's obvious they make work a lot faster. Maybe there were some studies around the time power tools were introduced looking at the productivity of carpenters, if those studies had results saying the productivity gains weren't obvious in the data that means you have a problem with your study and the data you have collected (which is totally understandable, measuring imprecise things like productivity accurately is really hard). You have to look at the evidence in front of you though, try telling the guy with a chainsaw that he's actually no more productive than he was when he was using an axe and he'll laugh at you.

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

This puts what I have been feeling in the recent months into words pretty concisely!

To me, it really is a force multiplier: https://news.ycombinator.com/item?id=47271883

Of course, I still have to pay attention to what AI is doing, and figure out ways how to automate more code checks, but the gradual trend in my own life is more AI, not less: https://blog.kronis.dev/blog/i-blew-through-24-million-token... (though letting it run unconstrained/unsupervised is a mess, I generally like to make Claude Code create a plan and iterate on it with Opus 4.6, then fire off a review, since getting the Max subscription I don't really need Cerebras or other providers, though I still appreciate them)

At the same time I've seen people get really bad results with AI, often on smaller models, or just expecting to give it vague instructions and get good results, with no automated linters or prebuild checks in place, or just copying snippets with no further context in some random chat session.

Who knows, maybe there's a learning curve and a certain mindset that you need to have to get a benefit from the technology, to where like 80% of developers will see marginal gains or even detriment, which will show up in most of the current studies. A bit like how for a while architecturally microservices and serverless were all the rage and most people did an absolutely shit job at implementing them, before (hopefully) enough collective wisdom was gained of HOW to use the technology and when.

Totally! Though I maintain that the only good aspect to microservices is that krazam video. You know the one.

I do get frustrated when I see people not using Plan steps, copy/pasting from web front-ends or expecting to one-shot their entire codebase from a single dense prompt. It's problematic because it's not immediately obvious whether someone is still arguing like it's late 2024, you know what I mean?

Also, speaking for myself I can't recommend that anyone use anything but Opus 4.5 right now. 4.6 has a larger context window, but it's crazy expensive when that context window gets actually used even while most agree that these models get dumber when they have a super-large context. 4.5 actually scores slightly better than 4.6 on agentic development, too! But using less powerful models is literally using tools that are much more likely to produce the sorts of results that skeptics think apply across the board.

Haven't looked into 4.5 vs 4.6 in depth (since the latter seems good for my needs), but

> but it's crazy expensive

was something I struggled with until just going for the Max subscription and cancelling my other ones.

I'm not sure what Anthropic is doing, but they're either making truckloads of money from those paying per-token (especially since you're not supposed to use subscriptions for server use cases --> devs can use Claude Code, but not code review bots etc.), or heavily subsidizing subscriptions.

100 USD is worth it for me, I've only hit the 5 hour limits a few times, and haven't hit 100% of the weekly limits once. I fear to think how much comparable usage with any of the Opus models would have been, if I were to pay per token - even Sonnet could get similarly expensive.

I don't get/like/want Claude Code. I do everything in Cursor, and I am very happy. I recommend it! And there's no time-based limits. You get deeply discounted API calls included in your monthly subscription, and then overage is billed at the same discounted rate. It's essentially committing to an "at least" amount per month in exchange for a preferred rate.

I have a USD$200/month Cursor plan, and I do hundreds of hours worth of Opus 4.5 prompting with it every month. I tend to pay $250-300 a month after overages, and I consider myself a heavy user. During Opus 4.1 days, one month I paid $700. 4.5 got substantially cheaper and smarter, and I consider that the real moment agentic coding got real.

I don't know your financial situation and I recognize that $300/month is more than much of the world makes in a month. I am just saying that for me, what I'm working on is important enough that I am absolutely willing to pay a premium for access to the best tooling available, because every dollar I spend represents literally an hour of my time. Maybe more? It's so incredibly cheap compared to hiring an unreliable human who needs to sleep.

You can't pay someone $3600/year to lick stamps, much less pair program application development.

That's pretty cool! I haven't really been a heavy user of Cursor, but found Cline/RooCode/KiloCode in VSC to be pretty good, while letting me preserve my existing setup and also easily switch between multiple providers, sometimes in the middle of some work, to let another model check the output of the first one!

I think most I ever spent per month was 300 USD, but I had to cut down on that and Anthropic's subscription being way more affordable than paying per token (alongside GitHub Copilot, which also has multiple model support and pretty generous limits alongside unlimited autocomplete), since I'm also helping a friend with expenses during their chemo and some other friends with some meds and stuff, even though policemen and teachers and others have way worse financial circumstances than software devs in Latvia, the economy here doesn't give that much breathing room for that kind of thing.

Oh for a while I was also using Cerebras Code which gives you really generous token limits (like 24M per day on the 50 USD per month tier), though the GLM 4.7 model I tried out still made me go back and work on fixing its output more often than I'd like. Eventually I kinda settled on SOTA.

That said, I do remember a post here on HN where some founders were thinking whether they should throw something like over 1000 USD at Anthropic (the API variety) per month and they realized that for them that amount of money was totally reasonable, compared to getting some junior devs or whatever.

I read that same post, and for me it wasn't just something I remember; it had a profound impact on how I came to be typing at you casually about how I have spent up to $700 a month on Opus tokens in Cursor (which absolutely lets you switch between providers... I just really like Opus 4.5!)

To me, all of the switching between dev environments + all of the time spent undoing errors causes by less powerful models has a huge time cost; not to be cliche that means it's very expensive to use error prone models and obsess over trying all of the new half-baked things (I've never even heard of most of the stuff you mentioned, lol). Like, if I spend an hour of my time mucking around with some tool, that's a good chunk of the $200/month I commit to Cursor.

Anyhow, at the real risk of sounding like an unpaid Cursor salesman, IMO it's worth every penny. For me, the jury is still out on whether people find Opus 4.6's 5x context to be valuable enough to pay significantly more for it over 4.5, which again is rated as being slightly better at agentic coding than 4.6. Since agentic coding is what I do....

> You want us to bring paper receipts, like we have some incentive to lie to you

Of course you might be heavily financially invested in AI companies so you might indeed have an incentive to hype up the tech

Or you might be relying on your hype to drive traffic to your blog

I don't have an investment portfolio, and I don't have a blog. But I appreciate that you're actually thinking about what I said, so thanks for that.

That said, if I did have a blog, the amount of negative attention that AI gets these days is not going to have the desired effect.

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

[edit] And SEV rates are not meaningfully higher.

thanks, this seems pretty useful information.

Assuming inbound volume clearly increased is something like we've been handling more tickets than ever before over the last few quarters or something like that.

I've read this code review thing before, and this tends to go into these studies suggesting that the whole process is taking the same amount of time, but for that to be the case the code reviews would have to take longer on the individual code review level and for you it is just volume increase because of increased tickets being pushed through.

Is there anything about your ticketing strategy? For example do you make your tickets much more atomic than lots of teams who say they do but then end up with things that could be split up into two or three tickets? How much time do spend on preparing tickets for ready for development / ready for AI?

Just trying to identify behavioral patterns in your successful usage that would explain the success. Given the example of throughput of tickets over long time I suppose we can assume that the gain is not illusory.

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

> For me, AI tools act like supercharged ... search and auto complete.

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.

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

Fair question! I've wondered that myself, there is always the possibility that the productivity gain is in my head. I'm not AI pilled, if these things disappeared tommorow I would probably just shrug, I'm just trying to keep up to date.

Where I find it makes me faster is in dealing with writing low value code that's repetitive, which I might normally procrastinate. Like, the thing I'm working on is a data editor that generates a lot of fields, so having it churn out a lot of samey react code is useful to me in that context. There's already an obvious pattern for the tools to follow.

I also find it useful for "rubber ducking". Bouncing ideas I might previously have bugged a colleague about.

By faster I'm not suggesting a fanciful number for me. Maybe like 10 to 20 percent if I were to guess.

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.

> 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 think the analogy is directionally good, but it short changes the abstract and recursive nature of software.

We were already writing code that was automating not only manual work but also simpler programs. LLMs essentially just move us one more (large) hop up the abstraction ladder. And yes I get that it’s a different type of hop (non-deterministic, extremely leaky, etc), but it’s still a hop.

So if the only thing you want to do is manually write code in the traditional way (perhaps with vim instead of IntelliJ) then yeah I think you’re cooked. On the other hand, if you are willing to work with LLM-assisted tooling and learn how to compensate for its shortcomings then I think you’ll have a bright future.

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

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?

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.

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

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.

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.

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

When AI screws up, it's "stupid." When AI succeeds, I'm smart.

It's some cousin of the Fundamental Attribution Error.

> something stupid an AI did in their codebase

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.