11 ms·

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

by noemit 7mo ago

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.

input_sh 7mo ago
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.
- theshrike79 7mo ago
  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.
  - input_sh 7mo ago
    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.
    - theshrike79 7mo ago
      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.
    - rel_ic 7mo ago
      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.
      - input_sh 7mo ago
        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.
        arcanemachiner 7mo ago
        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.
      - nitwit005 7mo ago
- deleted 7mo ago
  [deleted]
- Cthulhu_ 7mo ago
  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.
  - input_sh 7mo ago
    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?
    - wartywhoa23 7mo ago
      These people also prefer plastic averaged-out images of AI girls to real ones. The Average is their top-tier.
    - jasomill 7mo ago
      In other words, there's probably a market for a model trained on a curated collection of high-quality code.
      - kelipso 7mo ago
        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.
      - simonw 7mo ago
        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.
    - simonw 7mo ago
javadhu 7mo ago
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.
- noemit 7mo ago
  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.
  - javadhu 7mo ago
    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.
hansmayer 7mo ago
> 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 ?
pydry 7mo ago
>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.
- kolinko 7mo ago
  you’ve been hearing that since mid 2025 bc that’s when it became true.
- brabel 7mo ago
  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.
  - pydry 7mo ago
    >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.
    - ericd 7mo ago
      Maybe the bottleneck for most high profile open source is PR review and not coding?
      - Jensson 7mo ago
kdheiwns 7mo ago
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.
tern 7mo ago
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.
- wartywhoa23 7mo ago
  [flagged]
  - sd9 7mo ago
    Calling somebody a wannabe systems engineer is unneccessarily antagonistic.
  - tern 7mo ago
    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.
    - deleted 7mo ago
      [deleted]
- salawat 7mo ago
  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.
codebolt 7mo ago
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).
- skydhash 7mo ago
  > 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)
  - godelski 7mo ago
    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
kif 7mo ago
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.
- choutos 7mo ago
  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.
- sn0wflak3s 7mo ago
  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.
- sdf2df 7mo ago
  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.
- palmotea 7mo ago
  > 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.
sn0wflak3s 7mo ago
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...
Frannky 7mo ago
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 :(
_dwt 7mo ago
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.
- godelski 7mo ago
  > 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.
godelski 7mo ago
> 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.
gavmor 7mo ago
When AI screws up, it's "stupid." When AI succeeds, I'm smart. It's some cousin of the Fundamental Attribution Error.
dboreham 7mo ago
> 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.

by noemit 7mo ago

input_sh 7mo ago

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.

theshrike79 7mo ago
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.
- input_sh 7mo ago
  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.
  - theshrike79 7mo ago
    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.
  - rel_ic 7mo ago
    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.
    - input_sh 7mo ago
      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.
      - arcanemachiner 7mo ago
        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.
    - nitwit005 7mo ago
deleted 7mo ago
[deleted]
Cthulhu_ 7mo ago
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.
- input_sh 7mo ago
  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?
  - wartywhoa23 7mo ago
    These people also prefer plastic averaged-out images of AI girls to real ones. The Average is their top-tier.
  - jasomill 7mo ago
    In other words, there's probably a market for a model trained on a curated collection of high-quality code.
    - kelipso 7mo ago
      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.
    - simonw 7mo ago
      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.
  - simonw 7mo ago

javadhu 7mo ago

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.

noemit 7mo ago
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.
- javadhu 7mo ago
  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.

hansmayer 7mo ago

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

pydry 7mo ago

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

kolinko 7mo ago
you’ve been hearing that since mid 2025 bc that’s when it became true.
brabel 7mo ago
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.
- pydry 7mo ago
  >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.
  - ericd 7mo ago
    Maybe the bottleneck for most high profile open source is PR review and not coding?
    - Jensson 7mo ago

kdheiwns 7mo ago

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.

tern 7mo ago

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.

wartywhoa23 7mo ago
[flagged]
- sd9 7mo ago
  Calling somebody a wannabe systems engineer is unneccessarily antagonistic.
- tern 7mo ago
  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.
  - deleted 7mo ago
    [deleted]
salawat 7mo ago
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.

codebolt 7mo ago

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

skydhash 7mo ago
> 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)
- godelski 7mo ago
  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

kif 7mo ago

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.

choutos 7mo ago
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.
sn0wflak3s 7mo ago
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.
sdf2df 7mo ago
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.
palmotea 7mo ago
> 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.

sn0wflak3s 7mo ago

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

Frannky 7mo ago

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 :(

_dwt 7mo ago

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.

godelski 7mo ago
> 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.

godelski 7mo ago

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

gavmor 7mo ago

When AI screws up, it's "stupid." When AI succeeds, I'm smart. It's some cousin of the Fundamental Attribution Error.

dboreham 7mo ago

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