I like how they say they don't vibe in this comment, and then that they don't read the code anymore in just the previous comment in their comment history.
You can also see a recent comment of theirs saying they "don't look at code any more" but in this comment they say they "still require a code review" for changes.
My view is write the code that matters to you and that you want or need to be proficient with. If you need to defend, explain or discuss code, you are better off writing it yourself.
That seems like an odd way to interpret what they wrote.
Imagine old school machinists saying to a CNC machinist “Ha! See, maybe you don’t jog the axes manually, but you still have to be involved in placing the stock material, and you have to do the CAD/CAM work - so did it really machine the part for you? No!”
AI is a tool like any other. It has its limitations. It has classes of problems that it is suited to handle, and others it isn’t. If it’s true that they haven’t written (as in “typed out by hand”) a single line of code, why can’t they say that without you making that statement into more than it is?
I haven’t written a single line of code in 6 months, and that’s simply fact. It is also true that I put in a lot of other work to make that feasible, but that work isn’t in the form of writing code.
“it’s mature and the next step of engineering”
Tautologically, it’s mature enough for what it is mature enough for, and it certainly is the next step in the same way that CNC was the next step for machining — if you’re not using it as a machinist, you’re going to produce less compared to those who are.
Same thing with garden hoses. Yes, you can go fetch water from a lake and splash it on your lawn, or, you know, you could just use a sprinkler connected to your garden hose. Doesn’t replace buckets. Buckets just have a narrower scope in a world where garden hoses exist.
I'm sorry but both of these are false equivalences. CNC isn't about making general machining operations faster or necessarily better. It's about making a single machine more versatile. Instead of needing an assembly line of machines you can get a bunch of different operations done on the same part without moving it to a different machine. You can also do compound operations that were otherwise highly specialized (like milling a turbocharger's radial compressor wheel). You can get the same job done with a series of manual operations though.
A garden hose vs a bucket is also the same situation. You can accomplish the same thing with either, but one might be more labor intensive.
AI is nothing like either of those. It would be like instead of a bucket you get a garden hose that points in a different direction every time you try to use it. Or instead of a 5 axis mill that rigorously executes the g-code it just randomly reinterprets tool paths each time it cuts a part. Both of these things would be worse than useless in their respective applications.
AI is different because it plays to the pliability of the software domain. Even fairly shitty, irreproducible results can be good enough for software development, if you don't look at it too closely. Make analogies to the physical world at your peril!
There is a reason why such discussions about CNC machines never happened. I wonder what it cculd be? Becausw their output is better than man-made atuff? Because they are reliable? Because their manufacturers generally don't lie?
I think discussion with open registration is doomed precisely for this reason, it is too open to being influenced by bad actors. Maybe the lobste.rs invitation model would be better ...
What's up with all the new accounts astroturfing AI? There are multiple in these threads. People from the 'foundation model' companies having to keep up the AI hype?
Usually they provide grandiose claims (like the top-level comment) without any evidence or just anecdotal evidence that is not verifiable.
To me the big thing I see in blog posts is this implication that “all software engineering best practices are out the window”
And to me, AI should best be used to add rocket fuel to existing practices. Better tests, better observability, more atomic changes instead of big changes, automatic rollback etc.
> And to me, AI should best be used to add rocket fuel to existing practices
The more your codebase follows best practices and consistent patterns, the better AI will do and the faster you can move.
Same as humans really, just even faster. I'm also excited that people are finally writing docs and without even any flogging! They're calling the docs "skills" but hey whatever works
My main grief with AI-generated docs is that they (unless the instructions were very clear on this) by default describe the path to the current code and how it is an improvement over what was before, instead of just explaining its purpose. I see this all the time when reviewing other people's code... Fortunately it is easy to add a generic instruction to project-wide CLAUDE.md to avoid this problem, but it would be nice if this skill came out of the box.
I think what has really happened is a re-weighting of the importance of a lot of software practices. I think basically all of scrum/agile is completely useless now, but tests, PR reviews, documentation, decision records, etc, are more important than ever.
> To me the big thing I see in blog posts is this implication that “all software engineering best practices are out the window”
Yes, this is indeed a pungent smell. AI code assistants allow whole projects to be refactored and even rewritten in entirely different programming languages and software stacks in a few minutes, sometimes even with one-shot prompts. Most assistants even support creating and maintaining test suites with first-class support. Whatever you prompt, they do it.
And here we are, expected to believe that these tools can't or don't follow best practices?
> AI code assistants allow whole projects to be refactored and even rewritten in entirely different programming languages and software stacks in a few minutes, sometimes even with one-shot prompts. Most assistants even support creating and maintaining test suites with first-class support. Whatever you prompt, they do it.
> And here we are, expected to believe that these tools can't or don't follow best practices?
Uh they don't really. The contradiction you're seeing is actually fictional because that premise is wrong.
There’s a chance that it doesn’t change previously assumed cost benefit, or at least not in the aggregate. There has always been more code than could be safely integrated.
I don’t think AI actually changes that we should always be questioning everything, including how much we question at a time.
> And I haven't written a single line of code myself since what - February maybe?
Have you measured the impact of that on your ability to create good code? From my experience, relying on AI tends to degrade that ability.
Also, you seem to be able to do all of what you say and benefit from AI tools because you seem to understand the overall bigger picture well enough to be able to drive the AI agents to do their work properly. In other words, you operate in a familiar territory where you do not need to learn much new things.
But what about the junior people with little experience? Will they be able to manage such AI workflow? And more importantly, if junior people are given such AI tools, how will they learn?
These are all questions which may not matter in the short term and one might ignore them if they just want to see the profits and efficiency gains during the next cycle. But what about the long term?
I understand what you mean, but in my opinion there's a big difference between writing in natural language and actively engaging your brain with writing code, looking up documentation, etc.
It also sort of feels like "you don't know what you don't know", i.e. would you have considered an alternative better solution if you thought about it yourself, went to the documentation, found a tutorial on the web?
Of course, production is arguably a lot faster but it feels like there's starting to become a trade-off where the models feel so capable that we stop trying to find the solution to the problem ourselves and thus perhaps degrading our personal reasoning capabilities. I say this as something I'm afraid is happening, not something I'm certain of.
A compiler is a predictable, testable, deterministic piece of software.
An LLM is not.
Sure, all abstractions leak; so, at some point in time, for some reason, you may need to check its compiled code ( coughcough gcc 2.96 ). But, if today your code compiles properly, it will properly compile tomorrow as well.
This would only be somewhat equivalent if you compiled your code into assembly and committed that output to the repo, and then had to continue development within the assembly codebase using the same method.
How is that relevant to the topic of this discussion?
Compilation from higher order languages to the machine code is deterministic. It is sufficient to review and well-test the tool which does the translation. Given the same input, the output will always be the same.
Transformation of a natural language prompt to code by an AI tool is non-deterministic. The outputs will vary between runs. Therefore, it is always necessary to verify them.
The usual response to this is the "but high level languages are deterministic blah blah blah" (which IMO would be a good enough argument but well, we know how this goes now)
I posit a different argument. When you install a compiler on your computer, that compiler is "yours" for as long as you have the binary. You are able to completely forget about assembly because of 1. reliable _enough_ compiler 2. reliable access to said compiler.
Let's rewind decades back and pretend that the very first assembly compiler was behind a monthly subscription*. Do you think we'd be in the same place now?
Now the natural follow up to this "but the open models are close to SotA now". Well why aren't we using them? Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that?
But my point is, _these are not the same things_ and positing them as such is frankly insulting. How good are you at writing assembly when your compiler is inevitably taken away?
* I'm not a historian so I wouldn't be surprised some version of them were
Interactions with agents are conversational, while higher order langs are declarative. Spec driven development has been failing us, because there is no feedback loop from the runtime to the spec.
It's due to the jagged edge of AI experience. Because it's not deterministic the results don't play out deterministically (e.g. similar scenarios will have different and potentially drastically different results)
What tools have you tried? Are we talking Codex GPT 5.5 and Opus 4.7?
Would you say the project is well architected? Clear boundaries? Or ball of mud?
How large is large?
Are there AGENT.md files giving good information that helps LLMs get context when looking at a certain area of the code?
Is it all in one repo? multiple repos?
Are there good tests?
I feel like these are some of the many variables that can make a difference.
I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes. I also use LLMs to explore options and prototype quickly. They're also very good at fixing bugs, failing tests etc.
> What tools have you tried? Are we talking Codex GPT 5.5 and Opus 4.7?
Yes, with generous budgets.
> They're also very good at fixing bugs,
Seeing opposite here too, they are like eager juniors 'oh the issue is here and here's a 5 page report why', and it's wrong... then you add more info and it goes to a different spot... repeat until you get tired and solve it yourseld, it is useful as a rubber ducky i guess.
> I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes.
Great that it's working for you, I'm just pointing out there's a massive disconnect.
I would assume your work can be done by a junior engineer without any prior knowledge (except LLM md files) with same quality but less speed?
If yes, then great, perhaps that's where the disconnect is, complexity.
Also, if yes, which would be cheaper?, junior engineer or LLM?
I’m also in a big tech company and a lot of the team hasn’t written any lines of code by hand for awhile and it’s causing a whole lot of tech debt and frustrations are beginning to boil.
I’m not sure it’s possible to force someone to read every line of AI generated code and understand it. People generate code faster than they take time to read it.
Pressure from C-suite to AI AI AI AI AI MORE AI AI AI AI doesn’t help.
> I feel like I'm in a different field compared to the rest of hacker news.
That should be my line. My new employer does not use LLMs at all. Software development, marketing, hardware development, nothing. Maybe too little, but whatever.
The problems the company is facing are entirely unrelated to "throughput".
There's not, sorry. I can only advice you look outside the "tech sector" (FAANG and the smaller wannabes).
As implied, my employer's product is not software, but rather hardware. This hardware does of course run firmware and software and needs to interface with other systems. It's entirely B2B. All this combined makes work relatively relaxed.
> Now Claude is writing great commit messages but since I'm no longer looking at code - I never see them.
Let it be a learning opportunity for us, folks. This is why you shouldnt take comments on the internet too seriously. People (or bots) will say anything just to get attention.
p.s. Offtopic, but this is why I believe the ability to hide post history was the tipping point of Reddit's downfall.
I'm in a big tech company everyone has heard of and we have seen a huge spike in incidents which correlates with how much new code is shipped due to AI. Perhaps it's to AI's credit or our engineers' credit that the spike is relatively 1:1 with the spike in new code.
It's causing problems in all parts of the business and leadership's answer is that we must use AI to make fixing incidents faster and automated rather than assess whether we should be shipping enormous amounts of buggy code every day...
It may be the case. I've been around in the industry for 25 years and I barely code. I babysit multiple instances of Claude and we were very purposeful and deliberate in altering our workflows for it; we made our local dev environments capable of spinning up multiple instances to work from parallel worktrees. We added MCP servers to let LLMs observe our CI, Jira and deployments.
Most of our time is spent doing spec work, planning, and injecting the proper context into LLMs. Like the OP, our metrics have drastically improved the time for delivery of new features, slightly improved bug resolution times, and now we're bottlenecked by needing more code review and manual QA to handle the workload.
Why is there manual QA step? If AI was that good you would go straight to prod. Actually have agent deploy live with full control over the whole production environment.
Microservices in big companies where you have to first write the spec and then fully understand the changes is maybe among the least benefiting use cases yet.
When you work on just a new mobile app, this is where I find AI is making the biggest difference.
On mobile you don't need specs and you don't need to understand every detail of the implementation. You can QA test the app on a real device. It gives me more confidence than just having written the code myself, and it's much faster. You can implement multiple major features in a single day.
This kind of e2e testing is just not possible with backend services.
> And I haven't written a single line of code myself since what - February maybe?
And how many lines of Markdown have you written? Pointless metric. I think I type more now because I don't get any helpful autocomplete for... English.
I feel the same and don’t get the extreme AI is inherently evil vs. AI is the best thing ever invented discussions. For me it’s all just emacs vs vi or tabs vs spaces kind of discussions.
It’s a tool and the good old sh* in sh* out principle applies.
People might take Mitchell’s comment as some kind of anti-AI stance, but it’s not he uses it regularly and makes a point in the X comments: “use AI, but think”
That comment sums it up best, because right now it’s hard to talk to either side, which separates at the comma.
I believe your anecdote. I am also agree with what you wrote below: "Tautologically, it’s mature enough for what it is mature enough for"
What programming language are you using? It seems like some programming languages are more mature in LLMs, e.g., Python, Java, C#, maybe Golang. (Oh yeah, and definitely JavaScript/TypeScript.) Rust, Zig, C++: I have a harder time believing you can manage a large project using only an LLM to write code.
The magnitude of negative responses to this comment is very encouraging.
Not because I agree with my sibling comments, but because I strongly agree with the parent, making me think my org and I are much earlier than I thought. :)
It's a two months account hyping AI (look at the comments).
And to answer your question: No. I am yet to see a product made by AI or a product that used to require a dozen engineer and a few years being made by a single engineer in a month. Anything demoed is always a UI/functionality clone of the same thing LLMs regurgitates.
Our experience is very similar except we didn't really have a review process before, and now LLMs find bugs before PRs get merged in main.
We had 5x-100x speedups in some legacy but important pipelines, with no regressions (validated after extensively by humans).
It's not that the code was actively bad. It's just only 1-5% people in the local SWE market would be able to write code that runs so fast and efficient and benchmark it correctly.
We found a subtle correctness bug that was in production for half of the decade (both GPT-5 and Claude Opus were able to find it), confirmed by human after.
And we keep finding subtle bugs that have been introduced by humans before (despite the human reviews, the particular domain is just difficult no matter how many docs and comments and tests one writes)
I am convinced human reviews are overhyped in the industry. We've done it in my company since we started it, and bugs keep happening. People are just terrible at spotting them in the middle of 100 lines of correct code.
Machines, OTOH, are very good at it. I am currently trying to make the code review experience better for humans by not just having the AI review the code, but interact with the human, pointing out potential problems, bad patterns, perhaps hiding some code (e.g. renamings, formatting changes).
Developers still want to review the code, despite provably being bad at spotting bugs, because they want to actually keep knowledge of what's being modified in the code base, so I think this is the best approach.
Maybe the humans are just overwhelmed by the amount of poorly readable AI code you're throwing at them? Maybe they'd be better at reviewing if the code was written by somebody who had put thought into the code instead?
If you actually have time to read all your code, understand it, and are willing to be bottlenecked by human understanding, then yes, you are living in a different world.
In my world, that is far too slow, and you will be seen as a low performer who just can't keep up with the tech.
I think this divide has something to do with the way people are using these tools. I do a lot of planning in my documents and I rarely use conversations accept to interate on something I wrote instructions for.
> I haven't written a single line of code myself [...] I need to understand the code
What's the difference? I don't think anybody get paid by how efficiently they type on a keyboard. If you to use a die or raise a crow to get your next keypress I honestly don't think your PM cares as long as the actual output you contribute to the project is something you are responsible for.
I'm not saying it has no implications on how you think or no costs socially, ecologically, politically, solely that nobody cares HOW you get the code, only in your ability to keep on making it increasingly work better, closer to the evolving needs of the project.
Some programmers are gardeners. It sounds like you're one too. Your job is to maintain a large existing codebase. You probably didn't understand the entire codebase before AI, nobody did, so it doesn't matter that you don't understand it now. AI is very good at gardening, nobody doubts that.
Other programmers are painters. Their job is to start with a blank canvas and create something that others will value. When AI tries to paint, it tends to produce slop: a facsimile of everything it's ever seen.
The right metaphor isn't painting, though, it's molding clay. That first pass is slop, but it's raw clay that the agent is very good at molding given a modicum of direction and "not this, do that" comments. The combined first-pass and reshaping time is still far less than writing by hand from scratch. And increasingly, that first pass is ... not bad?
Not all code is fixable. Sometimes the best thing to do with code is to throw it away.
Without any human code to grab on to, AI has a habit of writing code that is pervasively low quality and rife with misunderstandings such that it always needs to be thrown out.
And yes with considerable prompting effort you can improve this picture. But it's easier, faster and cheaper to just write the code yourself. Code is the best specification language we have.
[flagged]
[flagged]
I like how they say they don't vibe in this comment, and then that they don't read the code anymore in just the previous comment in their comment history.
3 replies →
Gosh that is a dark pattern! Now we need to be aware of injected opinions to control the narrative.
4 replies →
You can also see a recent comment of theirs saying they "don't look at code any more" but in this comment they say they "still require a code review" for changes.
Pretty sus, bot or otherwise.
Or he's just giving a sane take, one that most people in the Bay Area have by now.
Lots of tech companies are doing just fine with purely AI written code at this point.
Saying that the quality is getting worse in some immeasurable way (while incidents remain the same) is literally unfalsifiable.
10 replies →
[flagged]
4 replies →
[flagged]
6 replies →
Damn.
There are more points of view than that on HN.
A common one: "I have stopped writing code, the world is going to end"
Another: "I will code by hand, I don't care"
Another: "I use it as a tool, but the hype bothers me so much that I have to bitch and moan from morning to night"
This one is: "I have stopped writing code, it wasn't the end of the world."
My view is write the code that matters to you and that you want or need to be proficient with. If you need to defend, explain or discuss code, you are better off writing it yourself.
I would say his post has the tone of earnest discourse while yours devolves into ad hominem laden reflexive sensitivity.
Which is the pathological take?
The Bun rewrite’s aftermath will provide strong evidence either for or against GP.
That’s like saying “the aftermath of Hiroshima will provide strong evidence either for or against nuclear power scientists”.
It’s irrelevant and unrelated.
6 replies →
That seems like an odd way to interpret what they wrote.
Imagine old school machinists saying to a CNC machinist “Ha! See, maybe you don’t jog the axes manually, but you still have to be involved in placing the stock material, and you have to do the CAD/CAM work - so did it really machine the part for you? No!”
AI is a tool like any other. It has its limitations. It has classes of problems that it is suited to handle, and others it isn’t. If it’s true that they haven’t written (as in “typed out by hand”) a single line of code, why can’t they say that without you making that statement into more than it is?
I haven’t written a single line of code in 6 months, and that’s simply fact. It is also true that I put in a lot of other work to make that feasible, but that work isn’t in the form of writing code.
“it’s mature and the next step of engineering”
Tautologically, it’s mature enough for what it is mature enough for, and it certainly is the next step in the same way that CNC was the next step for machining — if you’re not using it as a machinist, you’re going to produce less compared to those who are.
Same thing with garden hoses. Yes, you can go fetch water from a lake and splash it on your lawn, or, you know, you could just use a sprinkler connected to your garden hose. Doesn’t replace buckets. Buckets just have a narrower scope in a world where garden hoses exist.
I'm sorry but both of these are false equivalences. CNC isn't about making general machining operations faster or necessarily better. It's about making a single machine more versatile. Instead of needing an assembly line of machines you can get a bunch of different operations done on the same part without moving it to a different machine. You can also do compound operations that were otherwise highly specialized (like milling a turbocharger's radial compressor wheel). You can get the same job done with a series of manual operations though.
A garden hose vs a bucket is also the same situation. You can accomplish the same thing with either, but one might be more labor intensive.
AI is nothing like either of those. It would be like instead of a bucket you get a garden hose that points in a different direction every time you try to use it. Or instead of a 5 axis mill that rigorously executes the g-code it just randomly reinterprets tool paths each time it cuts a part. Both of these things would be worse than useless in their respective applications.
AI is different because it plays to the pliability of the software domain. Even fairly shitty, irreproducible results can be good enough for software development, if you don't look at it too closely. Make analogies to the physical world at your peril!
3 replies →
There is a reason why such discussions about CNC machines never happened. I wonder what it cculd be? Becausw their output is better than man-made atuff? Because they are reliable? Because their manufacturers generally don't lie?
3 replies →
I think discussion with open registration is doomed precisely for this reason, it is too open to being influenced by bad actors. Maybe the lobste.rs invitation model would be better ...
[flagged]
[flagged]
What's up with all the new accounts astroturfing AI? There are multiple in these threads. People from the 'foundation model' companies having to keep up the AI hype?
Usually they provide grandiose claims (like the top-level comment) without any evidence or just anecdotal evidence that is not verifiable.
43 replies →
RSI?
4 replies →
The vast majority of positive opinions about AI on Reddit and HackerNews are bots.
The one you respond to is an obvious bot, new account only posting comments saying how great AI is for example.
No need to look further.
To me the big thing I see in blog posts is this implication that “all software engineering best practices are out the window”
And to me, AI should best be used to add rocket fuel to existing practices. Better tests, better observability, more atomic changes instead of big changes, automatic rollback etc.
> And to me, AI should best be used to add rocket fuel to existing practices
The more your codebase follows best practices and consistent patterns, the better AI will do and the faster you can move.
Same as humans really, just even faster. I'm also excited that people are finally writing docs and without even any flogging! They're calling the docs "skills" but hey whatever works
My main grief with AI-generated docs is that they (unless the instructions were very clear on this) by default describe the path to the current code and how it is an improvement over what was before, instead of just explaining its purpose. I see this all the time when reviewing other people's code... Fortunately it is easy to add a generic instruction to project-wide CLAUDE.md to avoid this problem, but it would be nice if this skill came out of the box.
2 replies →
I have recently needed to read a skill document because it was more understandable and more through than the official document.
I think what has really happened is a re-weighting of the importance of a lot of software practices. I think basically all of scrum/agile is completely useless now, but tests, PR reviews, documentation, decision records, etc, are more important than ever.
> To me the big thing I see in blog posts is this implication that “all software engineering best practices are out the window”
Yes, this is indeed a pungent smell. AI code assistants allow whole projects to be refactored and even rewritten in entirely different programming languages and software stacks in a few minutes, sometimes even with one-shot prompts. Most assistants even support creating and maintaining test suites with first-class support. Whatever you prompt, they do it.
And here we are, expected to believe that these tools can't or don't follow best practices?
I’ve seen AI write a lot of buggy code. I’ve rarely seen AI wrote test cases that expose buggy code.
16 replies →
> AI code assistants allow whole projects to be refactored and even rewritten in entirely different programming languages and software stacks in a few minutes, sometimes even with one-shot prompts. Most assistants even support creating and maintaining test suites with first-class support. Whatever you prompt, they do it.
> And here we are, expected to believe that these tools can't or don't follow best practices?
Uh they don't really. The contradiction you're seeing is actually fictional because that premise is wrong.
4 replies →
It does change previously assumed cost benefit trade offs and you should at least question any previously held beliefs.
There’s a chance that it doesn’t change previously assumed cost benefit, or at least not in the aggregate. There has always been more code than could be safely integrated.
I don’t think AI actually changes that we should always be questioning everything, including how much we question at a time.
> And I haven't written a single line of code myself since what - February maybe?
Have you measured the impact of that on your ability to create good code? From my experience, relying on AI tends to degrade that ability.
Also, you seem to be able to do all of what you say and benefit from AI tools because you seem to understand the overall bigger picture well enough to be able to drive the AI agents to do their work properly. In other words, you operate in a familiar territory where you do not need to learn much new things.
But what about the junior people with little experience? Will they be able to manage such AI workflow? And more importantly, if junior people are given such AI tools, how will they learn?
These are all questions which may not matter in the short term and one might ignore them if they just want to see the profits and efficiency gains during the next cycle. But what about the long term?
How good are you at writing assembly? What about junior people that take an introductory course in assembly but never practice it.
Maybe I’m pushing it a bit, I know, but a couple of decades ago you could’ve been asking this instead.
I understand what you mean, but in my opinion there's a big difference between writing in natural language and actively engaging your brain with writing code, looking up documentation, etc.
It also sort of feels like "you don't know what you don't know", i.e. would you have considered an alternative better solution if you thought about it yourself, went to the documentation, found a tutorial on the web?
Of course, production is arguably a lot faster but it feels like there's starting to become a trade-off where the models feel so capable that we stop trying to find the solution to the problem ourselves and thus perhaps degrading our personal reasoning capabilities. I say this as something I'm afraid is happening, not something I'm certain of.
> How good are you at writing assembly?
This is a false equivalence.
A compiler is a predictable, testable, deterministic piece of software.
An LLM is not.
Sure, all abstractions leak; so, at some point in time, for some reason, you may need to check its compiled code ( cough cough gcc 2.96 ). But, if today your code compiles properly, it will properly compile tomorrow as well.
6 replies →
That's a apples vs oranges comparison. Higher programming languages are still deterministic and not full of superstition.
1 reply →
This would only be somewhat equivalent if you compiled your code into assembly and committed that output to the repo, and then had to continue development within the assembly codebase using the same method.
> How good are you at writing assembly?
How is that relevant to the topic of this discussion?
Compilation from higher order languages to the machine code is deterministic. It is sufficient to review and well-test the tool which does the translation. Given the same input, the output will always be the same.
Transformation of a natural language prompt to code by an AI tool is non-deterministic. The outputs will vary between runs. Therefore, it is always necessary to verify them.
That is the difference.
8 replies →
The usual response to this is the "but high level languages are deterministic blah blah blah" (which IMO would be a good enough argument but well, we know how this goes now)
I posit a different argument. When you install a compiler on your computer, that compiler is "yours" for as long as you have the binary. You are able to completely forget about assembly because of 1. reliable _enough_ compiler 2. reliable access to said compiler.
Let's rewind decades back and pretend that the very first assembly compiler was behind a monthly subscription*. Do you think we'd be in the same place now?
Now the natural follow up to this "but the open models are close to SotA now". Well why aren't we using them? Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that?
But my point is, _these are not the same things_ and positing them as such is frankly insulting. How good are you at writing assembly when your compiler is inevitably taken away?
* I'm not a historian so I wouldn't be surprised some version of them were
4 replies →
Interactions with agents are conversational, while higher order langs are declarative. Spec driven development has been failing us, because there is no feedback loop from the runtime to the spec.
[flagged]
Bot account - 70 days old, no submissions, all comments are hyping AI
I'm seeing the exact opposite on a large C++ project.
I have friends at other companies with similar projects, they say the same thing.
It's like we're living in different worlds.
Still, LLMs are nice for well defined small projects, microservices, tools and research.
Noticed different results from friends, we have similar projects and tools.
We're guessing it comes from organizational behavior (culture, governance, management, etc.), we work in diverse teams / regions / companies.
It's due to the jagged edge of AI experience. Because it's not deterministic the results don't play out deterministically (e.g. similar scenarios will have different and potentially drastically different results)
Or just when one person sees "great result", the other sees "garbage".
What tools have you tried? Are we talking Codex GPT 5.5 and Opus 4.7?
Would you say the project is well architected? Clear boundaries? Or ball of mud?
How large is large?
Are there AGENT.md files giving good information that helps LLMs get context when looking at a certain area of the code?
Is it all in one repo? multiple repos?
Are there good tests?
I feel like these are some of the many variables that can make a difference.
I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes. I also use LLMs to explore options and prototype quickly. They're also very good at fixing bugs, failing tests etc.
> What tools have you tried? Are we talking Codex GPT 5.5 and Opus 4.7?
Yes, with generous budgets.
> They're also very good at fixing bugs,
Seeing opposite here too, they are like eager juniors 'oh the issue is here and here's a 5 page report why', and it's wrong... then you add more info and it goes to a different spot... repeat until you get tired and solve it yourseld, it is useful as a rubber ducky i guess.
> I work on a pretty large project/code base, written mostly in Go, and I have pretty positive experience with LLMs. I take on fairly small chunks, I review and understand the changes.
Great that it's working for you, I'm just pointing out there's a massive disconnect.
I would assume your work can be done by a junior engineer without any prior knowledge (except LLM md files) with same quality but less speed?
If yes, then great, perhaps that's where the disconnect is, complexity.
Also, if yes, which would be cheaper?, junior engineer or LLM?
7 replies →
That's a lot of "ifs" for something supposed to revolutionize the industry.
Man I dunno.
I’m also in a big tech company and a lot of the team hasn’t written any lines of code by hand for awhile and it’s causing a whole lot of tech debt and frustrations are beginning to boil.
I’m not sure it’s possible to force someone to read every line of AI generated code and understand it. People generate code faster than they take time to read it.
Pressure from C-suite to AI AI AI AI AI MORE AI AI AI AI doesn’t help.
> I feel like I'm in a different field compared to the rest of hacker news.
That should be my line. My new employer does not use LLMs at all. Software development, marketing, hardware development, nothing. Maybe too little, but whatever.
The problems the company is facing are entirely unrelated to "throughput".
That's great.
Is it possible to have any means of private communication with you where you would share the information who this employer is?
There's not, sorry. I can only advice you look outside the "tech sector" (FAANG and the smaller wannabes).
As implied, my employer's product is not software, but rather hardware. This hardware does of course run firmware and software and needs to interface with other systems. It's entirely B2B. All this combined makes work relatively relaxed.
^ this account commented this last month:
> Now Claude is writing great commit messages but since I'm no longer looking at code - I never see them.
Let it be a learning opportunity for us, folks. This is why you shouldnt take comments on the internet too seriously. People (or bots) will say anything just to get attention.
p.s. Offtopic, but this is why I believe the ability to hide post history was the tipping point of Reddit's downfall.
I'm in a big tech company everyone has heard of and we have seen a huge spike in incidents which correlates with how much new code is shipped due to AI. Perhaps it's to AI's credit or our engineers' credit that the spike is relatively 1:1 with the spike in new code.
It's causing problems in all parts of the business and leadership's answer is that we must use AI to make fixing incidents faster and automated rather than assess whether we should be shipping enormous amounts of buggy code every day...
1. What product(s)? 2. What features? 3. How.much ARR increase per employee?
If you can't answer these questions credibly, I'm afraid I'll have to treat your answer as LLM influencer propaganda.
Anthropic/OpenAI have been flooding this site with pro "AI" bots the last few weeks, this is for sure a pro-AI bot or employee from an "AI" company.
It sure feels that way.
It may be the case. I've been around in the industry for 25 years and I barely code. I babysit multiple instances of Claude and we were very purposeful and deliberate in altering our workflows for it; we made our local dev environments capable of spinning up multiple instances to work from parallel worktrees. We added MCP servers to let LLMs observe our CI, Jira and deployments.
Most of our time is spent doing spec work, planning, and injecting the proper context into LLMs. Like the OP, our metrics have drastically improved the time for delivery of new features, slightly improved bug resolution times, and now we're bottlenecked by needing more code review and manual QA to handle the workload.
Why is there manual QA step? If AI was that good you would go straight to prod. Actually have agent deploy live with full control over the whole production environment.
You had me until "manual QA". What is special about your product that your QA needs to be manual in 2026?
1 reply →
Sounds like a miserable existence.
1 reply →
Microservices in big companies where you have to first write the spec and then fully understand the changes is maybe among the least benefiting use cases yet.
When you work on just a new mobile app, this is where I find AI is making the biggest difference.
On mobile you don't need specs and you don't need to understand every detail of the implementation. You can QA test the app on a real device. It gives me more confidence than just having written the code myself, and it's much faster. You can implement multiple major features in a single day.
This kind of e2e testing is just not possible with backend services.
What do you consider a "major feature" in this comment?
Let's say iCloud sync
> And I haven't written a single line of code myself since what - February maybe?
And how many lines of Markdown have you written? Pointless metric. I think I type more now because I don't get any helpful autocomplete for... English.
I feel the same and don’t get the extreme AI is inherently evil vs. AI is the best thing ever invented discussions. For me it’s all just emacs vs vi or tabs vs spaces kind of discussions.
It’s a tool and the good old sh* in sh* out principle applies.
People might take Mitchell’s comment as some kind of anti-AI stance, but it’s not he uses it regularly and makes a point in the X comments: “use AI, but think”
That comment sums it up best, because right now it’s hard to talk to either side, which separates at the comma.
I believe your anecdote. I am also agree with what you wrote below: "Tautologically, it’s mature enough for what it is mature enough for"
What programming language are you using? It seems like some programming languages are more mature in LLMs, e.g., Python, Java, C#, maybe Golang. (Oh yeah, and definitely JavaScript/TypeScript.) Rust, Zig, C++: I have a harder time believing you can manage a large project using only an LLM to write code.
> We don't really vibe though. At least I don't. I see it more as comment driven development.
This is why this feels foreign. Most people don't take this approach (I'd argue it's the correct, rational way to use AI).
The magnitude of negative responses to this comment is very encouraging.
Not because I agree with my sibling comments, but because I strongly agree with the parent, making me think my org and I are much earlier than I thought. :)
Yeah I don’t get it, the parent is a pretty reasonable take
If you still hold code review to the same standard and just make the agent do incremental changes rather than vibing the results are pretty good.
Can you name the company or product? At least that way some of the claims of shipped features and stability can be objectively verified.
It's a two months account hyping AI (look at the comments).
And to answer your question: No. I am yet to see a product made by AI or a product that used to require a dozen engineer and a few years being made by a single engineer in a month. Anything demoed is always a UI/functionality clone of the same thing LLMs regurgitates.
It's because HN is in AI meta-psychosis :)
Our experience is very similar except we didn't really have a review process before, and now LLMs find bugs before PRs get merged in main.
We had 5x-100x speedups in some legacy but important pipelines, with no regressions (validated after extensively by humans). It's not that the code was actively bad. It's just only 1-5% people in the local SWE market would be able to write code that runs so fast and efficient and benchmark it correctly.
We found a subtle correctness bug that was in production for half of the decade (both GPT-5 and Claude Opus were able to find it), confirmed by human after.
And we keep finding subtle bugs that have been introduced by humans before (despite the human reviews, the particular domain is just difficult no matter how many docs and comments and tests one writes)
I am convinced human reviews are overhyped in the industry. We've done it in my company since we started it, and bugs keep happening. People are just terrible at spotting them in the middle of 100 lines of correct code.
Machines, OTOH, are very good at it. I am currently trying to make the code review experience better for humans by not just having the AI review the code, but interact with the human, pointing out potential problems, bad patterns, perhaps hiding some code (e.g. renamings, formatting changes).
Developers still want to review the code, despite provably being bad at spotting bugs, because they want to actually keep knowledge of what's being modified in the code base, so I think this is the best approach.
Maybe the humans are just overwhelmed by the amount of poorly readable AI code you're throwing at them? Maybe they'd be better at reviewing if the code was written by somebody who had put thought into the code instead?
4 replies →
If you actually have time to read all your code, understand it, and are willing to be bottlenecked by human understanding, then yes, you are living in a different world.
In my world, that is far too slow, and you will be seen as a low performer who just can't keep up with the tech.
Something tells me you are in a highly regulated industry.
I think this divide has something to do with the way people are using these tools. I do a lot of planning in my documents and I rarely use conversations accept to interate on something I wrote instructions for.
> I haven't written a single line of code myself [...] I need to understand the code
What's the difference? I don't think anybody get paid by how efficiently they type on a keyboard. If you to use a die or raise a crow to get your next keypress I honestly don't think your PM cares as long as the actual output you contribute to the project is something you are responsible for.
I'm not saying it has no implications on how you think or no costs socially, ecologically, politically, solely that nobody cares HOW you get the code, only in your ability to keep on making it increasingly work better, closer to the evolving needs of the project.
Some programmers are gardeners. It sounds like you're one too. Your job is to maintain a large existing codebase. You probably didn't understand the entire codebase before AI, nobody did, so it doesn't matter that you don't understand it now. AI is very good at gardening, nobody doubts that.
Other programmers are painters. Their job is to start with a blank canvas and create something that others will value. When AI tries to paint, it tends to produce slop: a facsimile of everything it's ever seen.
> to start with a blank canvas and create something that others will value
AI is much faster at taking an idea and creating a working proof of concept than any human I've seen.
Not saying it's good engineering, but leave that to the gardeners.
The right metaphor isn't painting, though, it's molding clay. That first pass is slop, but it's raw clay that the agent is very good at molding given a modicum of direction and "not this, do that" comments. The combined first-pass and reshaping time is still far less than writing by hand from scratch. And increasingly, that first pass is ... not bad?
Not all code is fixable. Sometimes the best thing to do with code is to throw it away.
Without any human code to grab on to, AI has a habit of writing code that is pervasively low quality and rife with misunderstandings such that it always needs to be thrown out.
And yes with considerable prompting effort you can improve this picture. But it's easier, faster and cheaper to just write the code yourself. Code is the best specification language we have.
[dead]
Are bots using Karpathy's tinystories model now? This account has been relentlessly pushing AI in a deliberately naive and calm manner.
Are other bots upvoting this?
Agreed, I’ve never been more efficient
You're at G, which is absolutely the only place I'd expect to be doing this in a mature/adult/non-psychotic way.