To me this merely signals how broken C++ development really is. Most if not all of the bugs being uncovered are memory related and therefore intimately tied to the mental memory model of C and C++, namely manual memory management.
It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability.
C and C++ are simply not fit for purpose when large scale software projects are concerned. All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
The hundreds if not thousands of developers working on Chrome weren't idiots who didn't know what they're doing. The complexity of programming in C/C++ is simply beyond most intelligent individuals' ability to get perfect all the time.
I'll await your Rust ports of Windows, Linux and MacOS then.
This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly.
Its staying power is due to the fact that we really haven't had many good alternatives until maybe the last few years. Things are not going to get ported and rewritten overnight, especially when they largely just work like Linux & PostgreSQL. We'd nuke a huge amount of institutional knowledge and inertia to change those up.
And C/C++ are still key in the embedded space where we still have devices constrained on compute and memory. That's not going to go away anytime soon.
This criticism feel like someone complaining about why anyone still uses horses on the day the Model T was announced. Change takes time.
C is literally "high level assembly" and therefore lacks any guard rails you'd expect in a programming language. It's just unfortunate that so many software developers embraced C for its speed, even when it wasn't strictly needed.
I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.
I, for one, can't see any speed difference between a program written in Pascal (Total Commander, which I use every day) and one written in C++ (Windows Explorer).
The entire compute world was built on top of C and C++. Saying they're not fit for purpose doesn't seem correct. I think what you're really saying is they're not an optimal choice from a safety perspective.
> All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly.
Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?
I assure you that Microsoft knew for years that there were thousands if not tens of thousands of memory related bugs lurking in Windows. But their policy was "don't fix" (and "don't look") unless a remotely exploitable vulnerability was making headlines. Because every minute a developer spends finding and fixing bugs is a minute he can't spend on adding new features customers will pay for.
Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner.
And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary.
Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs?
Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
> Saying they're not fit for purpose doesn't seem correct.
I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration.
Writing a browser in C++ in the 21st century was ridiculous and irresponsible.
Ekhem. When Chrome was announced there wasnt Rust. And Java was a programming language for slow moving systems, with many a flaws and its own classes of footguns.
I dont think they had much of a choice in 2008. Now? Sure. I bet a rust port is in the works.
Rust certainly helps for certain classes of errors but doesn't help at all for logic errors or incompletely understood requirements or occasional need for hacks due to business needs.
It basically completely eliminates the most common class of errors which are bugs related to memory management. Hard numbers and statistics show that every application with enough complexity will be riddled with those.
It is simply impossible, even for the smartest human minds, to manage this kind of complexity. And this is a fact.
C++ has had smart pointers for memory (and other resource) management for a long time now (see e.g. the Windows ATL classes for working with COM objects and resources).
There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust).
1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated).
2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code.
3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.
Not that I don't believe its possible to fix a lot of bugs, I also wonder what the actual dynamic was. Were the people in team working much more than usual as well? Given its Google, I wouldn't be surprised if there was an "internal push" to fix more bugs over next X sprints so that they can publish this blog and some manager can show impact and AI adaption to his superior.
Google's entire modus operandi has been "automate everything" for decades. They've been doing this with fuzzers, with project zero and so on. Adding LLMs on top is a very obvious next step. And LLMs improving and finding more bugs also follows. Then improve the harness and the dev tools, to better use the LLMs. And then everything together end-to-end to find-triage-fix-confirm. Your LLMs are as good as the loop they run in, and the loop is as good as the verifier. Seems a reasonable enough dynamic without (or despite, depends how cynical you wanna be) the need for managers to show number goes up on some chart.
So thinking about this, do you think these bugs are all unique or are there a small set of new bug categories that were found and once automated resulted in many separate bug fixes?
For many of the new bugs, do we think they would all have been prioritized in the past? Are these all critical bugs that would have all been addressed in a timely fashion or are they getting done because its easier to do.
Another way to ask it would be, do we think we're discovering that Chrome had more big holes than we thought or are we raising the security bar by fixing smaller holes?
I would guess they have been confronted with an initial flood of newly discovered bugs whenever they added a new analysis tool or approach (e.g. automated static analysis, fuzzing, ...). Once working through that initial flurry of newly discovered bugs one would assume that the frequency goes down again.
> In early 2026, we saw a gradual increase in all categories of bug reports, but by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025
sure, moreover - maybe big AI usage significantly influenced the amount of bugs.
So, the picture can be like that:
- 2025: 50bugs found, 45fixed
- 2026: 500bugs found, 450 fixed
1. Our backlog of bugs gets processed quicker because instead of staring at the code for 10 minutes fiuring out what's happening, there's a tool that can reason about it quicker.
2. Code reviews and security reviews happen quicker and produce more findings.
I would think that (m)any team(s) using AI might also be seeing a higher rate of finding and fixing issues.
Even the Linux Kernel (I'd say Windows and Apple too) are seeing the same phenomenon.
The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many. Some people didn't think we would see the day where that comparative human limitation was laid bare in simpler tasks than they expected. I believe older developers are less likely to be offended, having to deal with this as a matter of course (as the mind declines).
I don't know why people keep acting like any kind of LLM skepticism or criticism is based on bristled fur or something.
I am very skeptical of these workflows, but I also use LLMs regularly. I specifically use them because they are better than me at sifting through massive amounts of complex information. They are also quite, uh, sketchy, for things that are significantly easier. A total mixed bag in my experience that ultimately is useful, and I will continue to use
> The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many
Lol! What about fuzzers, linters, typecheckers and formal tooling? There’s plenty of machine code evaluators that people do use because it’s better than relying on human skills.
The issue is the actual report and the lack of information.
> What about fuzzers, linters, typecheckers and formal tooling?
Pretty sure Chrome has been using all of those forever, along with some of the best security researchers in the world, yet AI (which is what GP really means by “machine” here) is finding way more bugs. I think GP’s point is that AI makes some people uncomfortable because it operates more like a human than a special purpose tool.
As for lack of information, I’m curious what you’d be interested in seeing. More information about the kinds of bugs it found perhaps?
I don't know, this more and more feels like a sentiment projected on to people than anything real these days.. Like even in that linked thread, is personal offense like you lay out here really were you can place Laurent Pinchart's push back? You don't read anything else there at all?
And either way, what, we are going to keep this line going for another 5 years? Aren't you bored?
The citation was in support of the post above mine and was incidentally a link to a mailing list. I did not read the mailing list threads out of personal interest, admittedly. I think it's a particularly bad way to communicate (took 15 years for me to figure it out), so I avoid them.
> Like even in that linked thread, is personal offense like you lay out here
Taking it personally, is a concrete demonstration of what I described. The replies to my comment, are unsurprising.
AI is very good at finding security bugs. If you are working on a product that processes hostile data like a web browser and has a security bug bounty program, your choices are either to find them yourself or be overwhelmed by external submissions.
This is just my hypothesis, but I suspect that at Chrome‘s engineering team there has been a culture of inaction for the past decade or more. That nothing gets done, no bugs fixed, unless some higher ups at Google sees a business interest in resolving it.
And what has changed now is that the higher ups at Google do indeed see a business interest in fixing bugs and giving the credit to AI to sell us more AI.
Bingo. The issue is not lack of knowledge but prioritization at these companies. Microsoft has the ability to fix Windows bugs, they just think it's secondary compared to adding their own new bug ridden features.
Exactly this. And there are few bigger targets than Chrome when it comes to finding exploits (OSes and network equipment are probably on par). I'm sure they have devoted large compute resources and human staffing at making sure that they find and fix these issues before anyone else does.
The real datapoint was Firefox not paying any money in Berlin's Pwn2Own competition round this May just gone. Unheard of to have nothing confirmed... they've paid out every event since 2007 (I checked). Does this mean we must move past the low-hanging fruit now? Probably... Certainly indicates some usefulness of these models.
I just did a search and apparently this fact (the specific one about no payouts for the first time in almost 20 years) has not gotten a discussion on HN. Given the degree of skepticism around the utility of AI bug finding and fixing (this very thread is full of it), I would have thought that concrete evidence that it can help actually make real software more secure against attacks would have gotten a write-up somewhere.
How many of those automated fixes were reverted? How many introduced a new bug? What's the false positive rate on the finding agents? The post has counts for everything that went right and nothing for what could go wrong.
Exactly, also it lacks a lot of context as to why they did that.
Possible (probable?) scenario:
- Marketing: "we found and fixed lots of bugs thanks to AI"
- Reality: the KPI is now to fix as many bugs as possible with the help of AI, so they used AI to search old and easy bugs in the backlog, and then fixed it manually
Huh? Maybe a third scenario is that AI helped fix the bugs? Like described in the actual post you are replying to? This level of conspiracy theory is getting a bit ridiculous.
I think you’re right, my base assumption is that the models can code and can fix bugs, and can code more in parallel and faster than humans at a lower cost.
If Google are tackling lower value bugs with AI the number is in a way inflated compared to some utility measure (fixing a smaller number of worse bugs could be preferable) but it’s still things fixed.
At my company there's a lot of discussion about AI and complaints that people run out of tokens within a day, but zero results are shown. No measurable (or measured) gains. Or nothing that people are willing to talk about, in any case.
At my company the performance improvements channels has been exploding, with people claiming giant improvements in latency, throughput, and decreased cost of the services. The cost decreases itself is order of magnitude more (at annualized run rate) more than we pay for tokens. YMMV.
I definitely make use of AI but in my experience I almost always could have done it better myself, the places where I threw AI at the problem I didn't care about the results being good, only good enough.
When we see memory and compute requirements for version x+1 of software decrease instead of increase I will happily say AI is the oracle people proclaim it to be.
In $COMPANY, for the mid-yearly review, the employees were asked whether their AI usage was 1/ efficient, 2/ adoptive (integrated in the way they work) or 3/ transformative.
Saying “never used it” or “I tried and it was useless” was literally not possible.
You'd have to be a pretty stubborn software engineer to not find AI useful for anything at this point, unless they're making you use Github Copilot or something far behind the frontier. You don't have repetitive tests to write? You never need to write a script to run something?
If you were the CEO of Amazon, would you be setting up channels for people to talk about their AI failures? The general way technology is deployed is that we try to find ways to make it work, because those are the most interesting. We're not as interested in all the ways it doesn't work.
From my perspective, some people are trying to use AI in the same way somebody might use a laptop to paddle a canoe. Sure, you can do it, but it's not a good idea. The fact that it doesn't work well is not particularly interesting.
If I steelman your position, I guess the ideal repository would be a set of cases where it's known to work well and a set of cases where it's known to not work well. A little bit like ProtonDB or SteamDB, perhaps.
I'd say that one is not really an issue. In 2012 the Pinkie Pie exploit chain already required chaining 6 bugs to lead to an exploit [1]. Since then we've seen chains requiring more than 10 bugs (!).
If you fix any one of those bugs, the exploit is non-functional anymore. Sorry out of luck.
So if, say, for every ten bugs you fix, you introduce two new ones then it's still a very net win. Unless of course it introduces a bug so bad it becomes a simple exploit not requiring a long chain of exploits.
But in the case of browsers we've only ever been moving to longer and longer chains of exploits required to pwn a browser.
A great many window of opportunities are closing for dark-side hackers / north korean intelligence etc.: there were probably exploit chains still open for exploitation in April that just got closed by Google.
If anything, besides the supply chains attacks in amateur-land, the world didn't stop working: projects (not just browsers but OSes too) are being hardened left and right.
Using AI to find potential bugs is an amazing use case and there really aren't many downsides.
> The post has counts for everything that went right and nothing for what could go wrong.
I'm not saying there aren't a few downsides but the benefits are just too good to ignore.
Or people don't ask questions for which the answer is known to be "None, really."
I get that many don't like what LLMs are doing to the industry, but this is just incorrect reaction to a very specific benefit that's proven beyond doubt (Security hardening).
Accept it imo - LLMs are solving very large problems that have plagued software security.
Sorry it is your reaction that is really weird. These are legitimate questions, and I have definitely seen Claude finding the wrong cause and then implementing completely incorrect/irrelevant fixes, only to find that it didn't work and need to start over. Not saying humans don't do the same thing, but LLMs are far from perfect, and it would be delusional to only talk about successes.
I've done security work before, and I've done it now with frontier. I've seen the difference first hand, and as the OP and so many other articles show, so have the leading experts in the world.
So either they are lying, or you may not yet be seeing and experiencing what they are. If that's wierd, ok.
You did not address my points or those in OP but kept repeating yours (that are not even relevant) in a handwavy way.
And that's fine. You can continue to live in your bubble. Others simply have different experience, and your asserting "AI is perfect" on a forum is not going to matter in terms of everyone's own, first hand experience.
AI critique often funnels itself into a narrow bucket: creating code blindly with AI is bad. That's easy to grant.
Adversarial testing, checking developer assumptions, refactor suggestions, small dev tools and even some guided coding all sit on the other side of the spectrum of what you can do with coding and AI. For larger and larger codebases even simple things like tracing dependencies or behavior might be greatly aided.
And the critiques reserved for that narrow bucket on the other end, blindly generating code, are too easily conflated with the rest.
Yes. AI is a tool, it’s supposed to be used a certain way, anything else is a misunderstanding og what AI is. You have to aim it in the direction you want it to go, not expect it to solve all your problems magically
AI isn’t “supposed to be” anything (other than “intelligent”). It just turned out that LLMs have to be used in particular ways to be useful. Nobody planned or designed them to be that way. We all as users are put to do the job of discovering the ways.
LLMs are increasingly not tools anymore but agents. The difference is still one of degree, but it's clear in which direction we are currently moving. It was even clear to some people 10 years ago: https://gwern.net/tool-ai
Have LLMs shown any decent capabilities in resolving non-security bugs yet? Security bugs are important, but my day to day frustration with tech tends to be caused by UX/functionality bugs. And Google seem to struggle more than most other companies with those.
Google Home became so unbelievably buggy, and I felt so betrayed by that, that I stopped using every single Google product - from Gmail to Android to Google Cloud Platform. The few physical Google devices that I'm yet to replace account for 10% of my tech, but still cause 90% of my problems.
Worrying. Extrapolating a (speculative) future, this means (Google will feel) that soon the chromium base will no longer need the crowd-sourced bug hunting that is open-source. I expect Google to eventually stop working on chromium (in the open) and all current chromium-flavours will become de-facto forks of the last published version of chromium. These forks won't be equally easy to maintain given that the groups running them do not have access to the same level of subsidy as Chrome does with Gemini.
Which I do (actually a fork of firefox - waterfox), but it is still worrying as the viability of chromium-base browsers is what's keeping us having "merely" a chromium-monoculture (with viable ad blockers e.g. and website operators that check compatibility with more than one browser), rather than a chrome-monoculture (where ad-blockers surely would have been killed by now).
I wrote a pretty insignificant book. So many complaints over the years because there are a lot of mistakes. Not something to be proud of, but I’m the only person working on a pretty large project. Thanks to AI I fixed a large number of mistakes last month.
Can't have been much, as the Chrome project is 20+ years old and LLMs have only recently become a thing; they did not slacken their code review and testing practices with the advent of LLM code generators. And I doubt they do much development on the affected areas at the moment, they mention a 13 year old issue for example.
But it's an open source project, you can go and figure out whether your assertion is correct.
>Can't have been much, as the Chrome project is 20+ years old and LLMs have only recently become a thing
That's not a great argument. GPT3.5 was launched over 4 years ago, so that's already significant compared to Chrome's age. LLMs notoriously also produce more verbose code than a human, so its not out of question that it might produce 5x more bugs on average given the same time frame.
It's weird to assume that this is all smoke and mirrors where AI is fixing AI's bugs. When we dove into the rsync issue, what was happening is that AI was revealing bugs that had been previously unknown, resulting in the need to fix them. I would be stunned if that were not the case here.
If people are handing off the coding to AI more and more then they'll be less skilled at spotting potential bugs in the first place. AI, course of, could be run to find potential bugs in the AI-coded features before commit. But then you're getting further and further towards a world where code, and code that runs infrastructure, is incomprehensible. We'll have to start sacrificing the first-born to the silicon in the hopes of a good build for code that controls your electrical sub-station.
Look at the git stats for the project. Lines of code submitted haven't changed dramatically. Not everyone is just merging slop into the codebase. There are many ways to use AI, and most established players are not merging vibe coded nonsense.
That is a stat you invented out of thin air, based upon nothing but pejorative hope, against all logic or rational consideration of the timeline or the scale of the project, and you declare it the "elephant in the room"?
HN is so weird on the topic of AI, and so many desperately are trying to contrive a reality. Odd stuff.
The elephant in the room is how many people in this discussion are actually alien lifeforms.
The elephant in the room is how many turtles obtained law degrees.
The elephant in the room is whether this is worth discussing because we're all in a simulation.
No, it isn't the elephant in the room. You made up some horseshit that betrays how little you know about the field, which will get upvoted because HN has a hearty contingent of "if I pretend AI is actually useless, maybe that will manifest in reality" zealots. It's bizarre.
Turtles with law degrees don't exist, but LLMs that increase tech debt in code bases do. Maybe recent ones got better, and it's useful to quantify the progress being made.
If you assume that AI can produce code with less bugs, your 100 times increase in fresh bugs means you also increased your speed for new functionality by more than 100 times.
If models can spot 13 years old critical bugs, I think they can also produce fresh code without those bugs. The skillset is the same.
> If models can spot 13 years old critical bugs, I think they can also produce fresh code without those bugs. The skillset is the same.
As if humans are incapable of spotting critical bugs simply because they've existed for a long time? And we know humans don't produce fresh bug-free code, because the old bugs exist.
A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you. They get mad at Excel for the poor investment returns. At this point, this is such a strawman, it isn't worth counter arguing.
I think I'll abandon this discussion and keep using AI quietly while exchanging tips with like-minded people who are interested in using it properly and efficiently.
> A lot of people here seem to be living in a different universe than me
I feel this way on this topic too.
> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.
The problem is; how _should_ I use AI? On a previous thread, I had two replies to the same comment, one saying "provide the LLM all the context it needs and let it go ham", and the other saying "Carefully guide and craft it and review everything". Both subthreads had people agreeing.
My experience with LLMs is leaving them unattended gives very poor results within a handful of iterations, and that carefully guiding them can be a value add, but the effort ot do that is very often as much as just writing the damn code myself, particularly if there's a few iterations that go on.
I think the main cause of different views is just the fact that people have very different products and codebases they're working on. Therefore, the requirements and applicability of AI varies a lot, case-by-case. It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details, but at least some transparency would be great.
I've found AI to be immensely useful in gamedev, mainly UX development, research, and curation. In those areas I let it go quite wild, with mechanical and visual tests for UX, and summaries for research and curation. I've also made skills, custom subagents, hooks, and scripts (all made with AI assistance) to streamline development.
Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big. If I worked on, let's say banking, I'd be much more careful. On my day job, as a data scientist (moving towards product owner) in a large industrial company, I'm much more careful. UX can run on vibes, but anything that touches data processing or business logic needs to be looked at by a human, row by row. Depending on use cases, it may be fine to look at only the tests. The main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.
> It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details,
It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.
> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big
I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.
> he main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.
I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".
AI is great at reading, so give it things to read. Claude will try to throw big markdown docs in your repo, but you don't have to do that. Make it keep docs by the code.
I include a line in AGENTS.md that says "We *always* add docstrings to methods, classes, structs, and namespaces - there should be 100% coverage of docstrings."
It will make better choices about what functions to make or remove if you force it to justify why the function exists.
And when you have to go back and understand, it becomes easier.
It’s clear at this point that agents don’t actually follow agents.md
They try to but they don’t. As an example, we use perforce in games. I regularly have to stop an agent and remind it to use p4 edit rather than blasting through the read only flag, despite the first paragraph of Claude.md being “this is a project using perforce. Batch call p4 edit on all files before modifying, do not manually remove the read only flag”
> It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.
Yes, good addition.
> I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.
Yeah, I should have been more specific since our use cases are very different. I'm working solo on small games, so it's easier to keep the AI on a leash. I can imagine it can be a nightmare on large code bases with many collaborators.
> I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".
Yeah, probably our use cases are very different here too. We mostly develop/maintain dozens of microservices for internal use, mostly greenfield, relatively small in scope, and with 1-3 developers in each. And maybe 98% was a bit too optimistic. The larger and older the codebase, the more problems AI tends to create. But it's very good at helping to understand old codebases (even those written by myself haha).
Oh, and esoteric data science topics can be a minefield too. If there's a topic that's new to me, It's difficult to know what is hallucination and what is not. It's best to let AI suggest alternative methods and then study those yourself.
I've found that these models are extremely good at reasoning since late last year, but they're basically 200 IQ Amelia Bedelias. So my working model earlier this year was to give it a brief instruction and watch how it failed, which was generally a lack of context that it couldn't have possibly known. Then I'd add that context to the team AI docs repo, try again from scratch, and iterate until it did what I wanted without me having to give a bunch of detail in the prompt. Over the course of 2-3 months, I needed to give new context and steering less and less.
I also encouraged my team to paste any inquiries or alerts we got in our slack channel verbatim into codex and follow that procedure until it could figure it out as a one-shot.
I still treat it as more of a design and coding partner day-to-day, so I'm typically not trying to one-shot, but it can e.g. be triggered by a pagerduty alert, reference our code, check grafana panels, query application state across different servers/clusters, and come up with bug fix PRs all autonomously, and then post its analysis, mitigation suggestions, and PR link to slack for the on-caller to review. This was all just some docs, scripts, and a little listener service to trigger a one-shot model prompt that we built.
As a design partner, it's made it easier to add more telemetry or create rapid prototypes to check my assumptions. I've encouraged my team to regularly ponder on what facts they wish they knew, no matter how difficult it would be to find out. Pretend you could just ask God anything you want to know. Then ask the AI to go add whatever's needed to find out. We should all move toward a perfect intuition for what our system is doing because all questions can now be easily answered if we can only think to ask them.
It’s a very soft skill that changes as the capabilities of AI change.
But one thing that doesn’t change is the need to specify an end goal correctly and precisely. I think the emphasis of knowledge/information-processing work is going to increasingly be placed on verification mechanisms. This is practically equivalent to precisely defining an end goal.
Spend time deeply thinking about what it means for a solution to be correct. What properties will a correct solution have? What of those properties are testable? Write those things down and tell the agent.
As models get better, agents will be able to target more and more difficult end goals. The strategy just becomes more useful. (It’s useful for people as well.)
For example, if you want an agent to write a photo editor, think about what end properties the editor should have. There are reference images for color space and rendering transformations. That’s a good start.
Sometimes the goal will be fuzzier. “I want a feature like CaptureOne where I provide a reference image and it makes my image look like that.” Well, time to think really hard about what that means. Iterate with AI on how to test for that precisely. Come up with some good metrics/heuristics. Maybe it means local contrast should match. Maybe the overall distribution of colors. Maybe something more complicated.
Then you have a target and you can let an implementation agent work against that. If it fails, it’s either because the agent is bad or your target was incorrect or incomplete. As models get better, the limiting factor becomes your ability to correctly define a problem.
The reality of the current situation is that we have dozens of families of different model; each of which is differentiated further into various revision numbers and power levels, and depending on which one you use and what the nature of the tasks is, you very much need a different usage style that can only be discerned after multiple (Sometimes very many) sessions of using that individual model for that category of task. It is not one size fits all, and trying to pretend that it is will lead to failure.
> It is not one size fits all, and trying to pretend that it is will lead to failure.
I'm not asking for a one size fits all solution. I'm asking for "vibe coding with Codex on GPT 5.6 with high is the way, but if you want to be more ivnolved, Sonnet 4.6 on Claude is the path. Here's the proof."
Saying that it depends and it's impossible to quantify allows the camp who are claiming it's more productive to say "you're holding it wrong".
Latest models like Opus 5.0 work well in both scenarios. You can just give it a goal and let it make a plan, review the plan and then let it go ham.
Or you can also use it piece-meal and have it do parts of work that you want. It works in both ways and works really well.
I don't think there is any model right now that you can use with 0 oversight, but you can do pretty complex stuff without writing single line of code at this point.
I don't generally use AI to write code I feel I can write efficiently. In these cases, I'll just ask AI for a review. But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself. These instances are not too common, though.
I also ask direct questions to AI for brainstorming and advanced programming language usage. In these cases, AI isn't touching the code.
> But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself.
I see this mindset a bunch, and I just don’t get it. Reviewing code is so much harder than writing code! To write code, I need to find one path to achieve my goal, and convince myself, the compiler, and the reviewer that it does so. To review code, I need to consider all reasonable paths to achieve the goal, and confirm that a sufficiently-good one was selected. This is why we have junior engineers write code and seniors review it. If you’re beyond your comfort level writing it, how can you possibly review whether the author (AI or otherwise) made good choices? You only have exposure to one possible choice lane, and by problem statement you weren’t comfortable populating the other lanes…
To write code, I effectively need to do a mini-review as I go, and type vastly slower than the AI. To review code, given that all the automated checks are out of the way, I need to consider the objectives of the code (in terms of fitting into the existing codebase, having a reasonably appropriate style, etc.) and ensure there isn't anything too far out of line. Knowing that something is "sufficiently good" doesn't entail awareness of all possibilities, because you aren't ranking the thing but measuring it.
Seniors review code because they have a much better understanding of the necessary taste and discretion, and an awareness of the larger system the code will integrate into, whereas there's only so much you can learn about coding that's relevant to most of the code you'll write (and only so fast you'll ever really be able to type it, and most of the issues can be caught by automated, deterministic systems).
What can be concluded is that some get immense value out of Ai and some are incredibly critical of that claim.
I do not know what the secret sauce is.
But I have a responsibility to the team I lead. I need to protect our velocity. Which means that my hiring practices now include specific checks that people are able to work with ai.
In the end, it might be a step thing. Some people are just inherently incapable of working with this technology...
The truth is that using AI well is a skill much like anything else. There's no one single way to use it much like there's no one single way to write a program that serves hackernews.
The fact that people jump on the "you're simply using it wrong" wagon in every HN comment section whenever someone shares their negative/neutral experience with it implies otherwise.
There can be many correct ways to use a tool, while still having incorrect ways to use it.
Sometimes you need to set your oven to grill, other times fan force. But if you're complaining about getting burned then, yes, you're simply using it wrong.
You can today develop a mobile app with 20 screens without ever reviewing any of the code generated.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.
I really hope vibe coded apps have to be labeled as such so I can make sure to avoid using them. As a customer, I have zero interest in using something that was made with little care or expertise.
Unless the app is released and running on user’s device, your “it works” is on the level of hackathon’s demo. Being on prod has always been the true testing ground of code.
It seems like when people are talking about production level quality and how the AI. should be helping them there, plenty of people comes up with their “it works on my machine” anecdotes.
That is true, I was mostly speaking about a supposed need to review the code.
My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.
The limitation here is mostly that the model does not know what looks and feels good.
With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.
> That is true, I was mostly speaking about a supposed need to review the code.
Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct? Is the security layer good enough?…
The user interface part of the code is only one single component out of many.
Honestly, things have really changed in the past 6 months. Opus 4.5 got most of the way there, and Fable can now literally one-shot your run off the mill CRUD app.
I use a few of them daily. While there are still bugs, there are significantly less than there used to be back when everything was being maintained in my spare time.
Still not Netflix/Google standard yet, but definitely better than the average side project or pre-AI Bangalore special.
This (fixing bugs, making code better, refactoring), is the best fit for AI.
I think a lot of us were excited that we will finally be able to polish our old software.
Many of us were never given the opportunity and were tasked to produce new features at an ever increasing pace. Depending on where you landed you can be either elated or jaded.
It appears to me that this is the same pattern you often see when junior employees are given one or more resources intended to help them succeed. Despite having access to those resources, there is frequently no shortage of complaints about how incompetent people are, that they "should know" esoteric home-built sowtware patterns or business knowledge without being told or that they failed to perform a task in the one specific way that someone considers the "correct" approach.
LLMs are the first tech topic I’ve seen that attracts as much wishcasting as political debates. Some people get attached to the conclusion they want to believe and get angry at anyone who disagrees with them.
Most of the tech people I talk to outside of HN, Reddit, Twitter, and other debate heavy spaces have a more nuanced view. In group chats we share stories about the amazing things we got out of an LLM today, or the hilarious failures or mistakes they made. We share tips and battle stories. We talk about the pros and cons of different models. We discuss the hard things we’re doing that LLMs can’t handle yet.
Go on HN or LinkedIn or Lobsters and there are some comments from people who seem like they’re coming from a different universe or timeline. Some people claim LLMs are doing everything in their life perfectly. They’re posting thought leader Tweets about working 2 hours per day and doing everything with ChatGPT voice so they don’t even need to be at their computer. Others are claiming that LLMs are useless and they can’t get anything usable out of them at all, or that they create more problems than they solve.
It’s weird. I can’t recall a time when people in tech were having hot takes that disagreed with such polarized extremes. Like I can look at LLM output all day long and see that both of the extreme takes are not right, but they’re all steadfast in their ideas.
I find plenty of nuanced takes on HN. Honestly I think it's easier here than elsewhere; I just have to filter down to them. On other platforms, polarized takes are incentivized by the struggle for "engagement". (Youtubers often have fairly nuanced takes, but are incentivized to clickbait by misrepresenting themselves as believing something more extreme. Then they're incentivized to make a longer video, wasting your time and distributing the interesting bits across the middle.)
I think LinkedIn belongs in a natural category with Reddit and Twitter far more than HN does.
> A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.
Where do you suppose those misconceptions on how to use the tool comes from? That's rhetorical because the answer is obvious: the people selling the tools and their army of bots and sycophants. You can't be mad at people for being like "hey I tried to use this tool in the way it has been sold to me and its not delivering on its promises"
Reminds me those Bitcoin threads where I would explain a use case it solved for me and everyone was like "nope that's impossible, there's no use case". And before the inevitable replies come in: no, I'm not saying AI is like Bitcoin.
Did you think for a second that maybe other people work with other languages, domains, tools and work approaches than you?
It's so bizarre that noone realizes that there's a bit of a difference between banging together JavaScript into websites, writing firmware for widgets, herding servers or fixing medical devices?
This right here is the truth. Too often people talk in abstract ways, not disclosing what they're actually working on. And then they tell their experiences as universal facts.
The goal of software development is to eventually be done. Yes there are new incentives or new use cases that come up, but the aim should be towards a stable state where you're barely have to work on the software anymore. It's like an house where you spend a good chunk of money to build it, but afterwards you just maintain it.
That's my main issue with AI hypers. There's often no goal in sight, they're just busy for the sake of being busy. They talk about their process, but not their objectives. It's not about progress for them, it's only about being in motion.
It's true that metacommenting about leaving a discussion in order to leave a supercilious last word is a flamebait trope. But please don't respond by breaking the site guidelines yourself. That only makes things worse.
Please don't use quotation marks to make it look like you're quoting someone when you aren't. That's also a snark trope, and we're trying to avoid those here.
I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change.
In fact, if it wasn't for the fact that it made making the actual changes I identified much easier (move these joins into a CTE etc) it would have been a detriment. Not only did I get sidetracked by a bunch of useless suggestions but I also had to put up with others dumping their raw AI output at me as if it was somehow a meaningful contribution.
The useless suggestions are exhausting. One of my co-workers uses Claude for all asynchronous communication, including Slack messages, Jira comments, code reviews, and emails.
Every single message from him, literally every time he communicates, it's a massive wall of text, overflowing with scope-creep suggestions like nothing I've ever seen before. It's impossible to ask him a simple question and get a simple answer.
And this seems to be a broader trend with AI in general. It's getting more and more difficult to retain some semblance of brevity with AI tools. I'm constantly asking them to "be brief," and "only answer the question I asked," and "don't provide more information than I requested," but they keep churning out more than I want in their responses.
It looks like a subtle attempt to use up more tokens.
I have at least one coworker who literally copy-paste AI output to respond to code and doc reviews (and most of her communications like on Teams and Asana) despite me telling her multiple times to take it a notch down. Two days ago, she started answering my doc review questions with literally AI outputs (like "Good question. <insert a bunch of verbose response>" and "You're right. <insert a lot of fluff with little substance>").
That really bothered me that I finally announced AI "code of conduct" (more like AI usage expectation) and stressed that if one is not so kind as to have his/her coworker review AI output as it is, then I'll take formal measures to address that. We'll see what happens in the near future.
Really worrying that some people are totally comfortable with relying 100% on AI to do their work. Then what's human agency? What's the point of having them in the team (as opposed to just building an AI agent and work with that)?!
> If I were to be real, my coworkers that post AI responses straight rarely had insightful comments before AI.
There's never been a shortage of low-value coworkers because hiring is hard and firing is unpleasant and painful in many ways.
But there's a weird phenomenon with AI where a lot of people are using it to actively call attention to the fact that they aren't doing anything but call the tools.
Rarely in the past have the I-just-want-to-coast-doing-the-minimum folks called so much attention to it!
Yeah, but now it’s more confidently slowing us down… It kind of sucks. Someone else said that non-SMEs can’t filter through the noise and may actually mistake the AI slop for signal, which worsens the problem.
Hard for me to even imagine being in that kind of work environment. I know that I don't always like the output for AI, and even will argue with it at times (often into submission), then ask it to restate.
For code gen and review, it's been pretty good since recent Opus versions, and I really like Fable's outputs (though a bit costly in terms of use). Fable is much closer to my own style for the couple things I've done with it.
I have yet to even consider replying to emails/messages with AI. I sometimes write a wall of text on my own, but it's entirely me.
What have your or their manager said about this? About any or all of (a) slowing everyone else down with crap, (b) wasting company resources on generating crap, (c) not doing anything that a CI integration couldn't trigger the AI to do itself?
This is my personal experience: I've seen multiple emails from management about handling AI properly - it hasn't improved the situation. Those people don't hear and my org still sort-of says to people to use as much AI as possible (though they've limited which models we can use, and slashed token spending).
And with hiring effectively frozen there is not even an incentive to let go of those people because they will not be replaced - they may have contributed little overall (routine tasks, oncall weeks) and now contribute 10x more spam while before they would not even try to investigate an issue, but we don't have the cycles to allocate that to someone else. And every time you tell them something they try to gaslight you by telling you they're trying to learn and you're being too aggressive.
I've become so frustrated by seeing claude-isms in slack or in emails it has become impossible for me to use it to work on my personal projects and I'm moving over to codex. Maybe it's time to try pi and some chinese models, definitely I need a break from this madness.
Basically me as a junior AI engineer . It was frustating it starts with just using AI to reply to questions you don't know the answer too and it ends with fully automated ai answeringmachine.
As much as I don't truly love the shop I'm at now, stories like this keep me from looking for anything new. At least until the AI psychosis [hopefully] passes. I can't even get my management to approve a $100 Claude Max subscription, which is kind of annoying but also means they have not changed their expectations on what the team produces. None of my coworkers is going to be shoveling AI slop my direction because then they'd have to explain to management why they are using an unapproved tool to look at internal company code.
Yeah, I can't even run AI on work hardware... I have been able to use it for writing small utils/libraries that I then pull into the work... but the divide is clear and I review all the code myself.
For a couple examples, working through an animated loader for html/js/css with an svg for the org. Another was working through a library implementation to work against an interface that was designed for Mongo, but the org is using SQL Server. Latest was a quick util to extract a zip file of pdfs into a 1bit(b/w), zopfli compressed png file per page.
Generally stuff I could do, but would take me a few days for research and experimentation vs an hour or two with AI.
I'm not that guy but I've advised end users submitting tickets to prompt inject the importance of the ticket so that it gets triaged higher by lazy people only using AI and not actually reviewing.
Not sure how efficacious but I know the reviewer is just relying on the AI decision.
Or they could just explain in the ticket why it's important instead of trying to trick an AI? AIs and humans will both read your explanation of why we should care and use that to prioritize.
If you have to lie to get your tickets fixed, that sounds like either you're bad at explaining why things are important, or you're working on things you shouldn't be.
My product owner does the same. Every ticket she makes is multiple paragraphs now. It drives me up the wall, especially as some tickets are so simple I need two clear lines to know what I need to do. But no, I get 15 lines written by Claude with sometimes conflicting instructions.
it's one thing if it's malicious compliance. it's another if the person has no clue and is leaning into LLMs to get by. the loudest evangelists I experience are from people that are not coders but feel like they can dictate now they can generate code
The thing that makes it work really well is to make sure it has all the tooling to verify its hypotheses. If you allow it to run the full lifecycle in loops you will be surprised how well it works.
Built exactly this for work a few months ago. Claude has a read-only account to the dev DB and a bunch of python postgres tools, I point it at queries/views and ask it optimize, and it has to:
1) verify identical query results
2) run repeatedly to get average, worst, best, etc duration of runs
Sped up so many legacy things that none of us were ever going to bother with.
What if the shape of data in the dev db doesn't stay consistent with real life?
Is the harness for the AI set up with any sort of instructions to generally prefer broadly-applicable first-principals query performance analysis over unintuitive results that may be local maxima due to certain things specific to that env?
Even with humans I've had to unwind "optimizations" before that worked great for low-volume envs by taking advantage of 'be inefficient in the small scale with memory to save CPU and wall clock time' or such in a way that caused pain deployed.
It comes from C. Northcote Parkinson's work, where he calls it "The Law of Triviality". The idea is that people clog up decision-making by introducing a swarm of issues that have little relative impact or importance for the project at hand, leading to a massive misallocation of attention. His example is a $10 million construction project for a Nuclear Reactor where as much time is spent debating the materials to be used for a $3000 bike shed as on the actual reactor buildout. The law of triviality says "the time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved."
Source: C. Northcote Parkinson, "Parkinson's Law and Other Studies in Administration" (1957)
Thanks. I know what bikeshedding is. I’m asking what cyandees specifically means. The normal definition of bikeshedding doesn’t seem to make any sense in his sentence.
I’m assuming he’s using it to mean “cruft” or “low value features” but maybe there’s some meaning I’m missing.
Funny enough, I didn't know, but your comment made me look it up, then I tracked down a PDF of the book, read the relevant section, and wrote my reply. So, even if I didn't help you out, you helped me lol.
I originally heard it in the context of picking paint color for the bike shed, which is probably more on point for software engineers, most of whom would not be involved in any discussion around building a nuclear reactor.
LLM increase the range of things bikesheddable, so some folks will try to have a LLM design a nuclear reactor and manage the coffee budget in addition to the traditional bikeshed design complications. Whether this is an improvement or more engines of what passes for civilization catching on fire, well…
I don’t understand how LLMs make more stuff “bike sheddable”. What LLMs do is allow people to contribute low value garbage to all areas, but we have a word for that and it’s not “bike shedding”. It’s “slop”.
It's a low-effort drive-by comment, but I read it as tourists prompting about an issue they don't really know about.
People will recognize a glimmer of something they can attach to, prompt and get a few pages of junk about this narrow topic, and then contribute it in a way that further reduces the signal-noise ratio of the discussion or project.
Like, dude, we have the same tools. We can get the same slop from the tap at any time.
Just like humans, AI needs a "reality" to check things against. If we don't provide that in an automated way, somehow, it will always make mistakes and we'd have to point it out. Since, at that point, we're just mediating with what reality gives us and what an AI should do with it.
AI doesn't have enough senses yet. It's trapped in a box.
I’d say it’s not so much senses but defining what success means.
If you want to learn darts or perfect parallel parking for example, most of the increase in accuracy comes from simply but very deliberately
pointing out to your brain where you wanted to land versus where it did land.
We like to usually just do things and hope for the best. Defining success is not something we automatically do and naturally we don’t do it with AI either.
The same tooling that you'd use. AI is not magic, it cannot know exactly how a program will run under your exact circumstances and data. Therefore, if it can use a profiler, test suite or application, or be able to read logs, just like you would, it then can make changes, evaluate them, and iterate. Personally, I've created test MCP servers that will perform actions like submit orders, have the AI capture and analyze PerfViews and Concurrency Visualizer, write out tracing data to logs... all the same stuff I was doing by hand for years.
Tests! Unit tests, integration tests, random adhoc scripts. You know - TDD!
I’ve been working on UI component improvements and it was doing a lousy job until i specifically told it to test in a headless browser to validate it works. I think somewhere in an AGENTS.md i have an instruction to “don’t state your guesses as fact - validate findings and results”.
It bothers me that you have to explicitly state this to the agent. Makes me think what else is missing from that file which also needs to be explicitly stated, but I don't know what don't know. "Do a good job"?
This is where the harness shines. It's why products like Cursor have been growing like crazy. If you drop an extremely intelligent person into a problem they've never seen before, the initial context and knowledge-sharing just to get them up to speed is immense. They'll make a lot of mistakes until they're ready to fix your problem. The harness can leapfrog most of that. There is a booming industry in harnesses with no saturation in sight. We're not even close to maximising the utility of current models, let alone the amazing improvements which are happening week to week.
An agent doesn’t know what “job” it’s being asked to do until you tell it.
Imagine you’re blind and deaf and have temporary retrograde amnesia. You “wake up” one moment with a memory of some words in your head like “what is the bug?” …but you don’t recall the context of that question, and nor can you look/listen around to observe the context.
So you don’t know whether you’re e.g. at the office, in front of your computer, in the middle of doing some pair-programming (where, yes, you’d in investigate the bug thoroughly with tools), vs. having a conversation with a colleague over lunch (where the expectation is for you to tap into your knowledge + intuitions to either guess or say you don’t know — not to pull out your laptop.
That’s what it’s like to be one of these LLMs being prompted by some agent harness. Unless the harness injects the proper context into its “recent memory”, it just doesn’t know.
If you ask Fable or 5.6 Sol to improve performance, it will generally know to build a benchmark and create a test corpus. I'm not sure where the contrary suggestion is coming from.
This was my experience with some of the stupider models, but I haven't had Claude do this type of thing since I started using it for work about 6mo ago.
Claude will do some boneheaded things for sure, but it's pretty good about writing tests that are useful, and not removing or modifying tests just because they're in the way.
Claude is pretty bad about assuming that it couldn't have broken a test it didn't know about, as it has often told me "this is already broken on main" which is definitely NOT true.
Will, it depends on the AI. Anthropic used to have a lecture-length system prompt for their models to explain this stuff—part of the secret sauce for Claude Code—and famously found that the 5 series models no longer need it.
As usual, if you use anything but the best model available I’m going to state that the better ones do better. If you do use the best model available, then I’ll just mention that Fable still has limits and still needs some guidance.
One thing it does not do is deliberately build tests which test nothing at all, or which restate the code under test. I mention this because certain other models absolutely would.
> Tests! Unit tests, integration tests, random adhoc scripts. You know - TDD!
Tests onli validate the presence of bugs, not their abscence (Djikstra).
I'll also add that tests look at outputs and don't care how those outputs are derived. E.g. code filtering the entire db in memory will be fine in tests.
"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
Tests prove the things you thought of worked, and it often isn't hard to find the likely edge cases such that you have reasonable confidence everything works. You will be wrong from time to time, but not that often. You can prove code correct, but if the proof is wrong (common when a human is doing it), or the spec is wrong (most people have no clue how to write a comprehensive spec) it can still be wrong.
Haven't you ever written tests that assert that certain things happen or do not happen along the way? We use mocks all the time to, say, make sure that the code doesn't load the entire db in memory. Then it's there as a regression if somebody down the line wants to do that exact thing for some reason.
If the agent can write the tests its supposed to pass and we are worried that agent produces quite a lot of slop (which is why we are doing the tests), then what is the defense against test slop? Test the tests?
1st line of defence, use something like ponytail to enforce brevity. Use property testing and behavioural testing on top of unit testing. Enforce readability standards so you will be able to understand the tests.
2nd line, code review.
Do the first pass with an agent, ask it to bounce back vacuous or tautological tests. Ask it to verify that the tests verify what they claim to. Then read them yourself.
3rd line, mutation testing. If the tests don't actually catch broken code, kill the mutants.
Doing a pass where you just ask the AI to sanity-check the existing tests (against rules like “test against the spec, not the implementation” can also help.
In this case, you need benchmarks, in addition to regular tests. You also need concise instructions (or better yet, following your language / ecosystem norms if applicable) to how to run this stuff
I'm convinced this is why there's a bifurcation in old-hand/new-hand results: the old hands include the steps they'd do and the tools they'd use, and the new-hands never learned those tools.
Yes, sort of. Not that there is anything wrong with that. Fuzzing yields tons of trash results, the occasional fleck of gold and the even more rare nugget. Then you analyze how it found the flakes and nuggets update your fuzzing harness. Every so often you get to write a paper or give a talk about a breakthrough to share meaningful improvements.
Current AI isn't super effective at making the breakthroughs, but it sure is effective at democratizing the ones you can point it at.
Very few problems really have "all the tooling to verify its hypotheses" though. even if you want to construct such an harness.
Also let me ask you why we need better and better and models if what we have already can produce good output with 'all the tooling to verify its hypotheses'
> Also let me ask you why we need better and better and models if what we have already can produce good output with 'all the tooling to verify its hypotheses'
“Good” isn’t “perfect” and even if it was, the ability to produce perfect output with all the tooling to verify its hypotheses could still be improved, in time and token efficiency, by better models producing fewer spurious hypotheses, rejecting those it does generate faster, and taking fewer unnecessary steps in confirming its good hypotheses.
> Very few problems really have "all the tooling to verify its hypotheses"
This is such a blanket dismissal that I can’t agree or disagree.
Maybe very few of YOUR problems are this way. At least mention some problem domains.
Recent experiences: compiler-related (helpful), UI-related (agree it isn’t testable but the design iteration is quick, easy, and correct), debugging technical configuration problems (useless; I basically have to solve each problem myself before the LLM recognizes it).
We don't. You could freeze model development today and we would be able to use our current models to effectively optimize existing code for years to come.
If you run it in a sandbox with no internet access and a read-only role login for the database, and you supervise it, how big is the risk do you reckon?
Of course there's an issue if the data in the database is contractually restricted and you don't have a zero retention endpoint for inference, but the former usually comes with the budget to fund the latter.
The mistake there is to point it at code to figure out performance optimizations.
The place to find them would be performance profiles, query plans, telemetry. The guidance for perf still applies, measure before and after change.
The issue is that the code often does not contain the information to do a perf optimization. Eg. you can't tell your cache size, the volumes of data in your DB or the latency of your network through just the text. Should you provide this context, you can get better results.
> The place to find them would be performance profiles, query plans, telemetry.
Tbh, once this information is available (which is the tricky part), in 99% of cases there's really no AI needed to analyze the data, since the 'low hanging fruits' will usually stand out anyway. And once you get into the area where optimization hotspots are no longer obvious, you're already deep in the diminishing returns area and optimizations for one use case or hardware configuration may degrade performance on others. That's my experience anyway.
> there's really no AI needed once this information is available
Most people are not arguing that problems are too tricky for a human to solve once presented with it, but AI can look at 1000 things at the same time across a whole code base and then just come back with the results a human can review.
True, but at least IME, once you get beyond fixing the 'obvious bugs' (how many there are depends on the initial quality of the code base - but I agree that AI is really useful to find those), you'll get into a murky grey area of "maybe false positives" which require a lot of time to validate. As a result you sink a lot of time creating and tweaking code-base-specific rules to try filtering out false positives, and IMHO this is exactly the tipping point where the whole thing becomes pointless because it becomes a bureaucratic monster.
E.g. a good code analysis tool needs to work predictably at button press on any code base.
Still better than nothing of course, e.g. I actually think bug scanning / code analsysis is indeed the one area where LLMs are actually useful, but it suffers from the same 'diminishing returns' problem as traditional approaches, if not worse (e.g. still no silver bullet, but a mostly useful additional tool in the toolbox).
>in 99% of cases there's really no AI needed to analyze the data
As I've seen it, there's a large chunk of those getting the most out of AI doing so because they weren't aware of or couldn't be bothered by already existing, more reliable alternatives.
It really depends on the context. On a pure computational code, it can work really well.
I recently optimized some code asking Claude to "make it faster" 2 different programs. For each, it wrote a benchmark, gathered initial data. Emitted some hypothesis and measured data around them with profilers, then did some changes (behind feature flags), checked the output was identical in either side and through profiling that the right code path was taken, and then benchmarked both.
And it did that for multiple successive changes in both codebases. Some changes were purely algorithmic (better complexity), some were related to tradeoffs between memory and computation (caching intermediate results better), some were about creating less intermediate objects to relieve the memory pressure, some where about a better memory layout to improve data locality.
The annoying part is that some of the code that was optimized was generated by Claude in the first place, so it's a bit frustrating that it didn't do those in the first place. But I guess, my iterative approach to making those tools didn't work on big enough data sets at first where it would have been an issue.
Are you serious? Of course you can. Some hash algorithms are slower than others, you can read that and know that. Allocating in a hot loop is probably slower than allocating outside of it. Duh? I can't believe this even has to be justified, of course you can look at code and get an idea of its performance properties lol
Obviously you want empirical evidence to justify changes, but like... duh, you can read code and understand how it executes.
Not really a rebuttal. There's a lot of low hanging fruit in code bases were you can read code and see what's making things slow. Like the parent comment stated, you can visually tell if there's a lot of allocations in a certain part, and easily see if those allocs are present in a loop and often reason simply how many times that loop can be called.
I can see in the code when data layouts aren't optimal, and fix that.
There's a lot of optimizations that need more of a deep dive, but you can get a lot of gains by just reading and reasoning about your code/data.
EDIT: To add, there are cases were you specifically can't read code and understand performance issue, but you should first ask, is that because you just don't understand the APIs/Libs/tools you're using, or is it fundamentally difficult. For example, often at work I see people complain about their torch code being slow and needing to bust out a profiler, but often those people just don't understand how tensor operations work internally so of course they can't reason about the code and see the way they're using the lib is suboptimal.
I've consistently found that I see performance issues that the AI misses. It often says "that's not going to be what improves performance, it's noise" and then I get it to do it and it's like a global 30% throughput win lol. I think a lot of performance guidance it'll be trained on is shit - I see devs consistently misunderstand performance too and downplay the impact of anything other than "IO".
Which model are you using? There is monumental difference between models. Even between "frontier models". When people tell these stories, it would be great to also add which model you were using.
As an example Opus 5.0 is in completely different class compared to Cursor Grok 4.5 even if the benchmarks don't show such massive difference. Not even talking about regular stuff like Sonnet or Composer or stuff like that.
Yeah. If you need something to dig deep, you need to try Fable (optionally in /goal mode).
For performance testing, I wrote isolated testbeds that try to impair the system in realistic ways (latency/jitter/bandwidth limit on logical WAN hops when load testing), and Fable is happy to send a bunch of agents at it and iterate until it gets the results it's looking for.
I think that if you are used to Sonnet medium or something, this will surprise you, but models like Fable and Sol on high/xhigh will really dig deep until they meet your goal. (I mostly use this for bug hunting and not perf, but ... I think it can do perf if you set it up right.)
Yup, I do this regularly now. Whenever I think that something takes longer than it should I just tell it to set up a testing harness to measure each part of the process.
Once I have the baseline I'll just set a goal to improve performance by 10x. Works better than it has any right to. Have to be careful to exclude changes that massively increase complexity for tiny gains after its done, but the big improvements are often sensible choices that I'd also make as an engineer (i.e. more efficient data representation, caching and memoization where it matters, parallel processing, etc.)
Thats fine but then Fable 5 should have requested this information instead of blundering along. So why didn't it? An expert human asked to do the same task would have surely asked for the additional data.
That's what I add at the end of my prompts: "Ask me questions on anything that's not clear related to this task" or similar. Both the CLI and the VSCode plugin have a nice interface designed for this, asking the user questions.
That's like saying Fable 5 should have told me how to prompt it to solve the Riemann hypothesis like Terence Tao would. The skill of the user still matters.
No one in this chain said it sucks. Any sort of criticism towards LLM workflows is constantly met with these kinds of absurd statements. I've never seen any other tool with this kind of mentality from proponents
Even if true, this kind of response is unhelpful and fosters dismissal of your point. This kind of attitude more broadly paints AI advocates as cultists because they refuse to engage beyond "you're doing it wrong".
My comment is dismissive because the parent comment is also dismissive. But you are right, advice is helpful. It's in my comment, but it may not be obvious to everybody, so here it is:
Work on your project management, communication, and mentorship skills. The AI tools are much more like a team of sloppy but capable junior engineers and not a reliably consistent fabrication machine. Change your perception that one simple prompt is going to magically solve a hard problem the first time. Learn to break projects down, organize them into sub-projects, and implement them in steps. Learn to communicate more clearly, define your requirements more rigorously, and adapt around your "team's" strengths and weaknesses.
We want these things to be rigorous and flawless but reality is messy just like working with a regular team of engineers. They are good at some things, terrible at others, constantly changing, and unreliable. But we've historically built tons of reliable software on unreliable actors by focusing on process, collaboration, and communication.
AKA, not just the hard technical skills, but the soft skills that allow unreliable software teams to thrive. They don't know what they don't know and it's your job to manage that.
Exactly. I'm a huge FP fan. When someone doesn't like FP I don't lecture them on how they're holding it wrong. I usually assume that, unsurprisingly, the tool doesn't suit every problem or there may be a design issue in the tool they ran into
> I usually assume that […] the tool doesn't suit every problem
My expectation: inexperienced FP is trying to shoehorn a mutation-based approach into a framework that performs best with immutable data, or is manually recreating familiar structure (for loop) instead of using the idiomatic way.
But what do you tell someone in this case? They really need to learn more about the basics. Which is how I am interpreting the GGP’s dismissive-sounding comment.
Which model/agent/harness tool did you use? I've found what you describe was my exact experience some ~6-8 months ago, but since about a month or so the game has completely changed. Using 5.6 Sol with highest reasoning setting in Codex or Fable in Code, the models come up with a list of possible improvements from static analysis (ranked by complexity/benefit), write and run their own custom profilers and deliver significant performance improvements with barely any input needed from my side. So this is no longer a model issue, it's a user toolchain issue.
Very hard to say anything definitive on this because it's a moving target, but last time I tried models still had a distinct sense of "consistently good, sometimes great at micro, bad at macro". Similar to how, even for relatively pedestrian CRUD, they'll do code that's objectively fine at the function/file/class level but can still make a mess if you don't supervise them at least at a high-level.
It is moving so fast that your experience with older models is irrelevant today. Sorry.
Claude Code, Fable 5, xhigh reasoning, allow it to run the full CI, end to end and benchmark, it will not make silly mistakes (or only occasionally). Also, be able to state what you desire. Have any docs or materials in the same directory so the model can reference it. For even better results: turn on speech recognition and braindump what you know about the system, its goals, its context, history anything relevant, any gotchas you'd explain to a new employee or intern. Talk for 5-10 minutes. This is optional, "make it faster" can already get a large part of the job done.
And if it doesn't work well, describe what you dislike in its solution and tell it. Even just one extra iteration can make things work.
(I guess GPT-5.6 can be similarly good, I use Claude)
I feel like some people are emotionally invested in it not working and subconsciously sabotage their own effective use of the tool.
I'm not saying I don't get any use out of them, fwiw. In a lot of ways they write perfectly fine code, I'm just saying without some guidance at the macro-level they lose the forest for the trees, that's all.
Yes, definitely. It's too happy to just go and diligently work based on too little information, instead of asking questions first. And it makes many people think that they don't have to specify what they actually want, and the AI will mindread them and do what they want without being given access to docs and tools and context info that's crucial to know and they would intuitively know to hand over to a human collaborator but with AI they think they don't have to.
I've had a completely different experience. I usually know the problematic part and then ask the AI to optimize that exact part with benchmarks, telling it to try various different approaches, and it very often gains massive performance increases on various tasks, with me of course steering it and giving it pointers every now and then.
I was able to optimize a physical water simulation that was almost unrunnable on browsers to a buttery smooth 60fps version.
A self validating loop goes a long way with getting AI to optimize stuff. We had some builds that used to take a long time (15-20~ minutes), that i just asked Claude to reduce the build time. It brought it down to 2 minutes and under 10 seconds for incremental builds.
Turns out folks had been copy pasting some setup code which took 2 minutes to run, and only needed to be run once per environment. Claude refactored the code to get it to run once, and since we had tests which validated the build artifacts, it was able to roll back if its change had broke the build.
You have to learn to use your tools, not try whatever intuitively made sense to you at first (expecting the tool to do all the work) and then whining on Hacker News when it doesn’t work out for you.
We're reliving the early day Google era. It's an objectively simple tool to use, but some people just refuse to put any effort to learn.
I'm thinking the issue is probably that LLMs/harnesses are too easy to use? It crossed the thin line between magic and tooling and blur the mental model. If Claude Code were as hard to use as, say, ComfyUI, perhaps there would be less programmers having absurd expectation of it.
To be fair, isn't the hypothetical promise of LLMs that the tool does all the thinking for you? If the AI companies are saying "delegate all your thinking", and then people delegate their thinking and it doesn't work out well, isn't that partially on the people overselling the capabilities? People are going to naturally benchmark on the promises. If these AI companies would admit it's just another tool instead of pretending we're in the singularity and doing a new stunt daily we wouldn't be dealing with all this.
Incredibly dismissive of the parent comment. They made a comment explaining their usecase, and issues with the tool, which you just labeled as whining. Is this not a discussion board to talk about things? Is expressing issues with a use case you found now just considered whining on HN?
The parent commenter was trying to learn how to use the tool. Perhaps he could've used it better, but like you said, what may have worked was not necessarily the intuitive approach.
The parent comment also changed his approach, and AI worked for him to test out changes. That's not expecting the tool to do all the work, he's actually agreeing with you that "expecting the tool to do all the work" is a misstep.
When I listen to some people or to stuff that comes out of the frontier labs, they indeed do sometimes sound like a religious cult talking about deity. I find it disturbing.
My favorite thing lately is that it's very good at resolving dependency security vulnerabilities. GitHub already does a good job at detecting and notifying which packages are vulnerable and at what versions they're fixed, and without AI, it's just a super tedious process to figure out what things all depend on that package, find a version that'll work for all of them (potentially including upgrading the things that depend on it), wire it up, test things, and make any minor changes necessary in our code.
It's not "hard" or novel--it's just tedious grunt work. I'm happy to have AI solving that one.
I did a lot of SQL optimisation with claude code over the last year, what made it work for me was making sure I verify everything with explain analyze. The whole loop was not fully “agentic” because of this but it was still faster and better than when done entirely manually. Claude also suggested plenty of small optimisations I would otherwise not do.
One of my tasks is to take various AI models the data science team has produced/fine-tuned and make them runnable with optimizations on GPUs (TensorRT, vLLM, Triton Inference Server, etc.), involving conversion, deploy, smoke-test, packaging, documentation, all within a uniform framework. The documentation includes model-provenance, simple deployment instructions (usually a Docker run), simple deployment test. The DevOps team takes this and tailors it to Kubernetes / helm-charts or whatever the target environment needs.
I had worked on some earlier deployment environments for a few models where we focused on one version of Triton and one runtime technology. Even upgrading to a newer Triton version was brittle, involving a lot of command-line changes at various phases. This was written mostly pre-Claude-getting-real-good. I decided that probably Claude had matured and was way better at understanding the particulars of AI-model-GPU-deployment-and-technologies. I worked with Claude to make the framework a much more lightweight wrapper, ignorant for the most part of a lot of the deployment internals.
After this refactoring and doing the first couple of models, it's quite amazing at how well Claude can figure things out. For any new model we now set up its "specialization" directory and its documentation subdirectory, point Claude at the proper AI-model files, point Claude to the sample non-optimized inference code and test data, and point Claude to a similar conversion we've done in the past. There a multi-layer class hierarchy dealing with various tiers. I ask Claude to explore the existing conversion/packaging, the model, any documentation that comes with it (a lot of times there are unexpected twists), the sample code, and the desired multiple use cases the model is meant to address, and the test data. Claude has been trained, I'm sure, on a lot of AI model conversion, so it's able to synthesize the full multi-stage conversion/deployment pipeline, come up with appropriate test cases for all the use cases involved. There are usually between 3 and 10 refinements after initial synthesis, fixing outright errors, refinemnts that the data-science team requests after playing with test deployments, etc. The options and pitfalls are vast, and without Claude each preparation likely would 10x or more longer. I just put most details in Claude's hands, and make sure the general framework is good enough to provide external uniformity. When all is working, it takes a couple of hours to make sure the documentation is good.
All this to say that at least for this domain, Claude / AI has been a game-changer and has sped up the process amazingly.
1. Ask Claude Code or coding agent to research the internet, documentation, and Github for examples and learning working with similar problems.
2. Make the ten best examples of solving the problem based on the research.
3. Run each against the database enough times (100, 1000, or 10,000,000 depending) to empirically prove which is optimized. You can set other criteria based on your knowledge.
4. ???
5. Profit
The point is, it is cheap to research combing through 1,000s of examples and learnings and test the best and most relevant.
Echoing the other folks, I have a different experience.
I profile sql performance and LLMs find more opportunities than I could. All it takes is real data, a sql repl and an agent. Just ask the agent to use the repl to EXPLAIN and profile the sql. It works amazingly most of the time.
For sql, i found that it can recommend indexes that i didnt have in place. So for that part of it, its great. For optimizing code, it does an ok job, i guess.
Ask it to create a small sample to reproduce the issue in isolation. If it can't reproduce the performance changes then it drops it.
That might work better. I haven't tried it with SQL but it worked with a few complex UI issues I had. It identified the actual issue after a few false starts.
I'm surprised to hear this. I've found AI incredibly useful for optimizing queries. Give it the EXPLAIN ANALYZE output of your query and it will have no problem optimizing it
If you give the LLM the ability to run queries against prod-like data and review the paths, you have a fully autonomous system that can correctly optimize your ORM/queries. Been doing this for months.
pgAnalyze is a great complementary tool for this and they offer MCP
I hate these type of questions, they scream "YOUR HOLDING IT WRONG."
My experience is if you have been racking up the tech debt and have some low hanging fruit, Claude is really good at cleaning it up. If you have been properly stewarding the project, it's much less effective.
This is the research taste part - often they can be good but human experts are really good at this (also you know your codebase, without the prompt these models have no other background).
Then being able to suggest several things to try and have them go off and build, measure and tweak is hugely useful in my experience.
Also things like making custom visualisations for comparing changes.
AI can uncover certain issues and resolve certain problems but it also has its blind spots.
I've been using Claude to create a software architecture diagram. It came up with a lot of useful functionality that we had neglected to show but upon further examination a lot of steps didn't make any sense. It added a box to do validation on some data then it put another box downstream to do validation again on the exact same piece of data (the second box had a different name but upon questioning, Claude conceded that it was the exact same validation step). When doing inference on user input, it put a box to extract specific insights from the prompt and then it put another box to do inference again on the inferred data to categorize it... And this would add latency and unnecessarily strip out useful context when doing the second inference... It really only needed a single inference step...
I re-uploaded the diagram to Claude and confronted it and it conceded to all of my points and it even noticed a theme between them and suggested that the diagram exhibited "a pattern of redundant steps." But it was incapable of suggesting viable solutions besides name changes. All of its solutions made the design more complicated. It was incapable of simplifying the design. I've noticed this with AI code; it can make things more complicated, add more features but struggles to simplify things.
Also, AI is horrible at rating things... It's just too superficial. For example, if you write a huge amount of intentionally over-engineered, tightly coupled code with poor separation of concerns but you do proper linting, define all the types, add a lot of comments, it will give it a higher score than a shorter, more readable and maintainable snippet which exhibits loose coupling and high cohesion because it lacks the superficial aspects.
It's horrible because now business people who understand nothing about coding may ask AI about code quality and it will consistently rank low quality over-engineered projects that are full of bugs, unmaintable and less secure, with a higher score.
Frustratingly, if you point out problems in its judgement, it will concede to your points without reservation, even building on top of your argument... but it will never actually tell you this stuff up-front, unprompted if you don't already know it! It never seems to reveal new insights, at best it can only expand on existing insight which you've already had.
It tells you what you want to know but not what you need to know.
People in the comments sound like they're literally asking claude: "hey claude, can you find areas for performance improvements." Nah, it doesn't work like that. You have to be more like: "can you profile [...] and identify hot spots." then looks at results that are suspicious. if you don't ground it to the real world reality of your project then don't be surprised when it makes up its own.
that's the first mistake i made as a new claude user. i only knew what prompts people were sharing on forums. but since they had been written by vibe coders it was all complete non-sense. also think about this: software engineering is filled with highly specialised tooling that can easily improve software quality. the thing is, most developers dont know how to use them, and if they do -- using them is so slow that its almost not worth it.
any tool you can name claude can use. obscure academic proof verifiers, memory corruption scanners, debuggers, profilers, coverage tools, backdoor supply chain pattern scanners... it can run these and have results in seconds. really is like living in the future.
Then you're not grounding it to reality properly. LLMs get bad pretty quickly when you just tell them to pull the answer out of thin air. Pin them to reality with actual performance tests to run to test theories and the results will be much better.
Performance optimization involves simulating real world loads and measurable results. Give them the opportunity to actually have a closed loop if you want more than trivial improvements.
Have you any example materials that show a harness that an agent can be pointed at an app with some sort of telemetry tool, the results it gained and the cost of doing so? Because my experience is the same as the parents - the LLM goes on massive tangents, and the more tangents it goes on the worse the results get.
Not sure what materials your hoping for, but I've pointed codex at pprof application endpoints and just told it to identify hotspots and propose lowest hanging fruit/highest ROI items to fix, which I then approved it to open PRs for. Reduced application CPU usage by ~30% on loaded servers.
It's not magic. Fairly obvious oversights that I or someone else on the team could've found and fixed if we had looked, but it was never a business priority so we never did until I curiously spent 5 minutes asking it to do it for me.
Tell the coding agent to install
or build its own performance and profiling tools.
A few lines of Python with a time.time() call is enough to start iterating on performance improvements, and the really good models know how to use much more advanced existing tools.
Ultimately the harness is me and the experience is like managing an unruly toddler. You have to pay attention to what it does and issue corrections. Skills and prompts and AGENTS.md do some, nested sets of agents do some, but over it all is me keeping track of what it's doing and needs to do.
You have to size the unit of work to its useful attention span, you have to have code architecture that is conducive to units of work, and you have to have tools like ticket managers, etc. that keep the big picture and smaller pictures in mind. Reverting from agile practices to more pre-planning whole project documentation and architecture decisions helps.
But in the end it's you. LLMs have their limits and need humans to direct them.
You don't need a "blog post." You need experience managing projects, tracking progress, coordinating conversations, mentoring less experienced engineers, etc. That experience comes with practice and time.
If you really need something to latch onto, there's plenty of educational material available about how to be an effective scrum master. Start there.
Indeed. I'm saying the human inside the engineering loop is essential. If a person needs training, particularly if the set of high level advice I set out in a reply is rejected, a blog post isn't going to cut it anyway.
Some AI skeptics paradoxically insist humans are irreplaceable and then get almost mad(?) when you discuss how humans are necessary in the loop. At least that's my interpretation of what is going on, it's hard to tell.
When building with LLMs I'm mostly product manager and QA, the whole task is having the judgement to evaluate and correct course. You can share advice but it's not a copy-paste situation where one set of prompts/harnesses/whatever solve all your problems forever. They have to be adjusted for a particular situation.
The trend I've noticed is that AI struggles to think outside the box when making optimisations, which exactly what's needed when you've made all of the practical DB and logic optimisations to the existing code.
Often you need to take a step back and question how the system is working and if there would be better ways to design it so the bottlenecks you're hitting wouldn't exist in the first place. Caching things, adding indexes, tweaking logic – these can help, but you'll quickly hit diminishing returns once you've done all of the obvious stuff.
I've seen people here say how AI is great at optimising code though, but I'm not sure if that's because they're giving it optimisation problems with a lot of low hanging fruit or if they're successfully getting AI to rework their systems to remove bottlenecks. This one area I find AI to still be particularly bad at.
As others have said, these were uninformed guesses which LLMs seem still to be willing to hand out deliberately. If you provide more information (your schemas, the distribution of values in your database tables, the EXPLAIN ANALYZE outputs, DB configuration etc.) it will do a much better job.
I had good results when I started AI with building the testing for the actual problem, then it can just run itself over and over without wasting much time on verifying its output.
And at worst you still saved a bunch of time on writing the tooling to test the issue
Yep, as a performance specialist I've had the same outcomes - it'll find "smoking guns" galore which will sound plausible and be completely wrong.
But that's ok - I still get a lot of value of the tool elsewhere (e.g. writing data analysis scripts, exploring code, breaking down bug artifacts...), but it doesn't stop the tiring BS from other people going "why not just AI it?" (especially from managers).
I usually let them try to "just AI it" and most of them learn quickly that it's not that simple. (The others stay deranged and are making my job miserable.)
That's uninteresting as long as you don't specify the model you used. For example, Mythos was far better at finding security bugs than previous models.
I believe I was still using Opus 4.6 with the Claude Code CLI.
Before that, Gemini 3 Pro in Antigravity.
I have no experience with GPT 5.3 beyond seeing the nightmares colleagues produced in their MRs with GPT 5.3 Codex. It could be that they had the distilled 5.3 Codex Spark selected, I am not sure.
I would never undertake a big performance optimization without first measuring that area's total impact. The LLM would then be great to work out the refactoring and you can give it your bench suite (which it probably wrote) to work against.
I guess just another area where the LLM is useful only as long as you remain in charge using your own programming experience as a guide.
In my experience LLMs do find a lot of embarrassing bugs as Linus says but it can constantly turn into a game of whack-a-mole where most of the bugs it finds were written in previous LLM sessions. It's a huge struggle to get it to actually fix the root cause of the bug instead of patching the symptom.
Yes, it is relatively easy to find any solution to a bug. It is hard to find the root cause and change only what is necessary to fix the bug. AI makes it very efficient to "fix" bugs with code that needs to be fixed again later. The big problem in fixing bugs is understanding what is causing it, not to suggest a temporary "bug fix".
It's so hard to believe these kind of affirmations coming from a firm that has so many hundreds (thousands ?) of billions invested directly and indirectly in generative AI...
Code related Vulnerability discovery is one of those bright spots where AI can shine because its shaped as a learning-test: every example it runs gives it feedback that is deterministic. If you have ever pointed claude/codex to your a binary executable and asked it to figure out something it can run against full throttle, I fond it always gets back to you with some good insights.
On a related note: Visual Studio still has dialogs that cannot be resized, even after years of people begging Microsoft to make them resizable. Shouldn't this be a trivial fix for AI?
I'll believe in AI when I get to resize my Configuration Manager!
I wouldn't say "magically", it's what happens with me and every other engineer I know: we're all detecting bugs and yet we're all writing them too. Not saying that LLMs work the same as humans, but saying it's not a logical fallacy.
No, the extra code velocity allowed by AI without proper QA support means there could have been a lot more bugs introduced into products over the last year or so, giving AI more bugs to find. It’s tongue in cheek but not completely uncalled for. It’s been long known that one dishonest way to inflate your bug fix count is to put more bugs into the product to fix. Goodhart’s law is merciless.
Just admit that Chromium is too complex at this point, we've all seen show HNs doing what could be considered magic in Chromium. We probably need to issue a mortarium in new platform features and focus on a deep clean in bug fixes. I've said that Mozilla is too busy doing redesigns than bug fixes as well.
What I like is that this is a measurable productivity increase that can be directly linked to AI and they go over their methodology. AI-positive posts skew heavily anecdotal and hyperbolic.
I have a software degree and some work experience but have been doing other things for a decade or so.
I'm curious to try out some "vibe engineering" but it seems a bit daunting to get started, there are so many new tools available on top of the AI itself.
Are there good resources for somebody like me to get started, that'll guide me though how to think about prompting, and using CI and how go have the agent successfully write specs and tests and what-not. I don't mind paying some for a good course, but I find it hard to figure out which one would be worthwhile, or whether there are some youtubers that would be better to follow.
The best option at this point is to just sign up for a paid plan with either ChatGPT or Claude and then ask the model the same thing. My preference would be for ChatGPT and if you've been out of the game for a long time then using the desktop app might be the best choice https://chatgpt.com/codex/
Then try starting with voice mode (if you're comfortable chatting out loud) and just talk your way through it.
Build a sandbox, download Codex CLI or Claude Code or whatever and spend some time doing some creative stuff with it just for the sake of learning how it all fits together.
Pay attention to the inputs you provide and the outputs that they result in. Keep your bullshit detector engaged: Bots often lie.
If you get stuck, or it gets stuck, or you want prompting advice or whatever: Ask any frontier-level bot for help. Sometimes, it's very instructive to get help from Claude for an issue with Codex, or vice-versa.
Want better tools? Ask the bot to suggest some that exist. (None of the existing tools fit? Have the bot write new ones.)
All of this stuff is always in a state of flux, so even with the lies they'll do better at teaching than any fixed reference will. They're LLMs and processing language is what they tend to be best at... so go ahead and use that.
And remember: They're designed to behave kinda-sorta like humans, but they are not humans. They're just computer programs. If you don't like their output style, or they don't like your input style: Ask them how to implement rules that make them knock that shit off. :)
No worries, writing with AIs can improve the speed bugs enter the code base as well. Would be interesting to know the breakdown.
> the “latent security issue.” Code that is safe and robust in isolation can be transformed into a critical vulnerability by an entirely unrelated, minor logic change elsewhere in the tree.
Similarly, you can accidentally fix a bug without discovering/triaging it, so the pointless repeated bug lifecycle is incomplete
They keep breaking inertial scroll on Mac though, which is something that irritates me thousands of times a day.
First they made it so when it came to rest it would then start scrolling again and overshoot by 2 lines before coming to a halt.
They fixed that after a few weeks then it worked until last week and now it’s left in a state where as it’s coming to a halt it jerks every time like dropping frames of the scroll almost.
I know it’s not my machine, config or trackpad because I’m seeing it on multiple computers.
The article is great reflection how LLMs are actually doing Quality assurance on both security and codebase sides, but i still doubt the creative part that means UI side, So far in my experience LLMs at best are unable to determine what the good UI is , may be its not inherently a bug detection rather a creative process
The privatization and obfuscation of the security industry is worrying.
Google claims to help open source developers, but donates millions to the Alpha Omega Foundation that did not give access to Mythos to Curl and only found one issue.
The Alpha Omega people appear to be selected on physical appearance and take the money away from open source without doing much.
The entire Chrome article is obviously directed at suits and unsurprisingly hypes AI for better promotion chances.
Okay, now how many bugs would have been fixed if Google had spent $130B (Google's AI capex) in human resources instead of AI?
Just to have a sense of proportion, considering an average software engineer salary of $200k, that same money would buy you 650,000 engineer-year salaries. Of course there are other expenses, but that gives you an idea of the order of magnitude.
I recently switched from Chrome to Edge after using Chrome for decades. It is so bloated and slow. I can have same number of tabs open in both and Edge is always 30% to 50% more efficient.
That's something those products need to figure out, not the users, one potential solution is to erect paywalls and find out how much those products are actually worth to their users ;)
spent a several months working on their bug bounty program earlier this year while working full time and lost a lot of motivation after a duplicate combined with lower bounty awards and claude safety guards all at the same time
I can't comment on Chrome bugs, but I can comment on Safari bugs. According to a search of the WebKit Bugzilla, I'm the most prolific filer of web inspector bugs outside of the WebKit team itself.
Recently I noticed an unusually high number of web inspector bugs fixed by one longtime WebKit engineer, and I suspected AI assistance, though the commit messages include no disclosure of this. Nonetheless, the increase in volume was quite dramatic.
The other day, an update to Safari Technology Preview was released, and I attempted to verify whether a couple of my bugs were indeed fixed. However, it was impossible for me to verify, because the latest version of Safari Technology Preview introduced a new web inspector bug that totally broke the features I was testing.
Thus, I remain unimpressed.
Without a doubt, LLMs have demonstrable skills and can produce code much faster than humans. I never thought that producing code fast was wise, though, even before LLMs arrived. For many years I've criticized software development based on management-driven release schedules, where developers are forced to pump out code regardless of quality, regardless of whether it's ready. Your boss may not like it, but code is done when it's done, not when your boss says it has to be done. If software complexity were predictable and reproducible, then indeed management could replace engineers with automation, but that's not how it works in reality.
Back to Chrome, the browser is notorious for continually adding invasive new "features" to the web that nobody wants except advertisers. I wonder how many Chrome bugs were the result of Google push push pushing all of this new crap on users over the years?
Good. Now please fix youtube. Amount of bugs that I'm getting in youtube app on iphone should be embarassing for company like Google. I cannot believe how bad it become in last couple years.
My fear is that on average all software will get worse and be less optimized. There will still be high quality products at a high cost with high touch humans shepherding development, but I think there will also be a bunch of 'good enough' slop for everyday functional tasks where there exists neither the talent nor the budget to create truly wonderful solution.
Fast foot didn't kill fine dining, but it is killing us..
I wish they'd spent more time on improving the UI now. It's largely been the same since Chrome appeared. Their recent vertical tabs are so much inferior to Dia, which is built by a much smaller team.
I’ve heard from people inside Google that they’re prohibited from using anything but their own models. AlbertaTech on YT, ex-Google working on YT said in a video that right before she quit someone had threatened to quit if they couldn’t get access to Claude Code
Kind of, but you can also assert it yourself; the big tech companies have billions of lines of code not publicly available, they can train their in-house code assistants on those instead of or in addition to what's available out in the open.
Maybe they could ask the AI to fix their atrocious build times. Only in Chrome do you have 300 line source files that blow up to 20 megabytes after preprocessing as a matter of course. 3 GB per compile job is getting more common - and RAM is expensive right now!
Earlier today I opened Chrome on my iPhone, went to the Reading List. It started flicking fast and then the phone restarted. That's a first for me on iPhone.
Old bugs at the bottom of the prioritization list deserve to be fixed.
Some were probably just theoretical "if we have over 2B of this item, it'll crash because X/Y/Z and that can be exploited", some are probably in rarely used features.
Once the LLMs are done going through the code, the baseline will be all better and they will probably fix a lot less than they have now. Or they will have LLMs automatically check every single crash bug that has been submitted and take care of those too. I am assuming that they are probably already using this as an input source for their AI.
I've mostly only used Codex for reviews, for Godot/GDScript code, and it helped me catch bugs that would've taken me ages to even notice on my own; games be tricky like that.
Claude was mostly useless or annoying up until the last time I tried it (about 3 months ago)
You have to be vigilant though: Codex often picks out obscure edge cases and suggests adding multiple new functions and flags to avoid issues that would be better off left as fast-failure crashes. Maybe that's because of the 5.6 Sol Max I leave it on.
The biggest bug still has not been fixed here, which is:
Google.
We really need an alternative to this greedy and evil corporations
de-facto controlling a huge portion of the modern www stack. All
decision-making processes are here subjugated to what fits Google's
adEmpire. This is a perpetual system of control amplifying abusive
systems in place. We already see this with the recent age sniffing;
Google just yesterday announced that all android users must hand
over their age to everyone else. Before that google kicked out
or locked out open source alternatives to android (or, at the least,
made their life significantly harder than before). These are not
isolated ways of abuse - this is systematic abuse.
We really need alternatives to Google here. It can not be that one
tyrant company dictates so much of people's open lives (and no,
Firefox is no alternative; Mozilla is basically a nerfed and bribed
entity that has given up on firefox many years ago already; ladybird
may become an alternative at one point in time, but right now is not
and there are questions over how Kling handles the overall project,
but these complaints are significantly below what Google is doing
globally here).
Fixing more bugs in the adChromium code base does not change the underlying problem at hand.
Seems like they have enough AI they could find a way to put ManifestV2 back into the browser and fix things we actually wanted instead of putting more bullshit "AI improvements" we didn't?
give it another year and AI will be filing bugs faster than humans can merge the fixes, and the Chrome team will need a separate AI just to triage the first AI's bug reports
So Google could have been using AI to fix the XSLT bugs instead of acting like a cult and forcing everyone to remove it? What does this mean for things Google deems too bug riddled to be a viable feature? Will they remove the HTML surface now or fix it? I would love for the geniuses on the WHATWG to answer.
A company valued at $4+ trillion based on the recent AI hype alone is touting the benefits of using said AI, and we're supposed to take this shit for granted.
I'm wondering what the Alphabet employees still commenting on this forum have to say about it? I guess for the right comps they can keep their mouths shut no matter the high level of idiocy involved.
There is hype, but there are also real tangible wins as well. Analyzing code for bugs is something that works very well. We use it for helping us revert changes that lead to a flaking test and it's dramatically faster than previous techniques. It's great at suggesting duplicate bug reports. It's amazing at scaling an API migration throughout a codebase. It's great at prototyping an idea before you decide to do it properly.
There are many things it's not good at (eg design and architecture), but that doesn't invalidate the things it is good at. Everyone is learning how to best use it and there are growing pains. Ignore the hype and try to find the common patterns in what people say.
I don't know about Chromium specifically, but in general Google requires 2 humans to have looked at every change (normally one is the author, but not necessarily for bot-authored changes).
They did roll this policy for Chromium changes a few years ago too.
And it wasn't just 2 humans but 2 Googlers. One Googler author and one Googler reviewer works. But an external author needed 2 Googlers to review changes, and all files needed to be reviewed by one author at least.
So if you touched multiple files owned by different people for a more complex feature, you would naturally get there.
I am actually using AI to learn about Windows OS performance. I have a couple of prompts scheduled to research, test, and implement performance gains in the OS, then post them here [0] and here [1]. I always admired Brendan Greg and Bryan Cantrill at Sun/Illumos/ for their work on OS performance but never had the time to sit down and catch up to their level due to my time in the military.
I got Codex to find and apply a bunch of settings I didn't know about and in the future I hope to use AI to make real changes in performance that venders probably don't have time or resources for.
that being said, what I've learned so far is essentially
WhyIsItAlwaysHN's entire comment "The place to find them would be performance profiles, query plans, telemetry."
I just find it so frustrating that for a user interface that was basically solved in the 90s, Windows GUI still struggles to survive on hardware exceptionally more powerful than what we had 30 years ago
It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability.
C and C++ are simply not fit for purpose when large scale software projects are concerned. All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
The hundreds if not thousands of developers working on Chrome weren't idiots who didn't know what they're doing. The complexity of programming in C/C++ is simply beyond most intelligent individuals' ability to get perfect all the time.
This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly.
Its staying power is due to the fact that we really haven't had many good alternatives until maybe the last few years. Things are not going to get ported and rewritten overnight, especially when they largely just work like Linux & PostgreSQL. We'd nuke a huge amount of institutional knowledge and inertia to change those up.
And C/C++ are still key in the embedded space where we still have devices constrained on compute and memory. That's not going to go away anytime soon.
This criticism feel like someone complaining about why anyone still uses horses on the day the Model T was announced. Change takes time.
I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.
> All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly.
Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?
Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner.
Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration.
Writing a browser in C++ in the 21st century was ridiculous and irresponsible.
I dont think they had much of a choice in 2008. Now? Sure. I bet a rust port is in the works.
It worked well enough, maybe "fit for purpose" is a stronger word
It is simply impossible, even for the smartest human minds, to manage this kind of complexity. And this is a fact.
There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust).
1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated).
2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code.
3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.
Also, this doesn't address why the rate increased, which is the interesting part!
For many of the new bugs, do we think they would all have been prioritized in the past? Are these all critical bugs that would have all been addressed in a timely fashion or are they getting done because its easier to do.
Another way to ask it would be, do we think we're discovering that Chrome had more big holes than we thought or are we raising the security bar by fixing smaller holes?
sure, moreover - maybe big AI usage significantly influenced the amount of bugs. So, the picture can be like that: - 2025: 50bugs found, 45fixed - 2026: 500bugs found, 450 fixed
2. Code reviews and security reviews happen quicker and produce more findings.
I would think that (m)any team(s) using AI might also be seeing a higher rate of finding and fixing issues.
Even the Linux Kernel (I'd say Windows and Apple too) are seeing the same phenomenon.
Linux Kernel: https://lore.kernel.org/all/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80Kzs...
The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many. Some people didn't think we would see the day where that comparative human limitation was laid bare in simpler tasks than they expected. I believe older developers are less likely to be offended, having to deal with this as a matter of course (as the mind declines).
I am very skeptical of these workflows, but I also use LLMs regularly. I specifically use them because they are better than me at sifting through massive amounts of complex information. They are also quite, uh, sketchy, for things that are significantly easier. A total mixed bag in my experience that ultimately is useful, and I will continue to use
Like having real difficulty with basic counting while being able to solve extreme math problems.
Being context machines, talking about what they’re definitely good at and definitely shit at, in broad terms, has been… difficult.
Lol! What about fuzzers, linters, typecheckers and formal tooling? There’s plenty of machine code evaluators that people do use because it’s better than relying on human skills.
The issue is the actual report and the lack of information.
Pretty sure Chrome has been using all of those forever, along with some of the best security researchers in the world, yet AI (which is what GP really means by “machine” here) is finding way more bugs. I think GP’s point is that AI makes some people uncomfortable because it operates more like a human than a special purpose tool.
As for lack of information, I’m curious what you’d be interested in seeing. More information about the kinds of bugs it found perhaps?
And either way, what, we are going to keep this line going for another 5 years? Aren't you bored?
The citation was in support of the post above mine and was incidentally a link to a mailing list. I did not read the mailing list threads out of personal interest, admittedly. I think it's a particularly bad way to communicate (took 15 years for me to figure it out), so I avoid them.
> Like even in that linked thread, is personal offense like you lay out here
Taking it personally, is a concrete demonstration of what I described. The replies to my comment, are unsurprising.
And what has changed now is that the higher ups at Google do indeed see a business interest in fixing bugs and giving the credit to AI to sell us more AI.
1: https://www.anthropic.com/news/mozilla-firefox-security
2: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...
Previous discussion: https://news.ycombinator.com/item?id=47273854
Possible (probable?) scenario:
- Marketing: "we found and fixed lots of bugs thanks to AI"
- Reality: the KPI is now to fix as many bugs as possible with the help of AI, so they used AI to search old and easy bugs in the backlog, and then fixed it manually
If Google are tackling lower value bugs with AI the number is in a way inflated compared to some utility measure (fixing a smaller number of worse bugs could be preferable) but it’s still things fixed.
Is that better testing? Or more bugs were being introduced in the first place?
Is it less than a human would have? Is it more? Is it the same type of bugs?
I could be convinced either way and it's an interesting thing to ponder in my opinion.
That's AI for you.
At Amazon we have many forums to share our AI wins, but none to share AI failures or disappoinments.
No wonder execs make bad decisions regarding AI, they only hear completely one-sided stories.
I definitely make use of AI but in my experience I almost always could have done it better myself, the places where I threw AI at the problem I didn't care about the results being good, only good enough.
When we see memory and compute requirements for version x+1 of software decrease instead of increase I will happily say AI is the oracle people proclaim it to be.
Saying “never used it” or “I tried and it was useless” was literally not possible.
If you were the CEO of Amazon, would you be setting up channels for people to talk about their AI failures? The general way technology is deployed is that we try to find ways to make it work, because those are the most interesting. We're not as interested in all the ways it doesn't work.
From my perspective, some people are trying to use AI in the same way somebody might use a laptop to paddle a canoe. Sure, you can do it, but it's not a good idea. The fact that it doesn't work well is not particularly interesting.
If I steelman your position, I guess the ideal repository would be a set of cases where it's known to work well and a set of cases where it's known to not work well. A little bit like ProtonDB or SteamDB, perhaps.
I come to HN to read about AI failures and disappointments.
I'd say that one is not really an issue. In 2012 the Pinkie Pie exploit chain already required chaining 6 bugs to lead to an exploit [1]. Since then we've seen chains requiring more than 10 bugs (!).
If you fix any one of those bugs, the exploit is non-functional anymore. Sorry out of luck.
So if, say, for every ten bugs you fix, you introduce two new ones then it's still a very net win. Unless of course it introduces a bug so bad it becomes a simple exploit not requiring a long chain of exploits.
But in the case of browsers we've only ever been moving to longer and longer chains of exploits required to pwn a browser.
A great many window of opportunities are closing for dark-side hackers / north korean intelligence etc.: there were probably exploit chains still open for exploitation in April that just got closed by Google.
If anything, besides the supply chains attacks in amateur-land, the world didn't stop working: projects (not just browsers but OSes too) are being hardened left and right.
Using AI to find potential bugs is an amazing use case and there really aren't many downsides.
> The post has counts for everything that went right and nothing for what could go wrong.
I'm not saying there aren't a few downsides but the benefits are just too good to ignore.
[1] https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....
I get that many don't like what LLMs are doing to the industry, but this is just incorrect reaction to a very specific benefit that's proven beyond doubt (Security hardening).
Accept it imo - LLMs are solving very large problems that have plagued software security.
So either they are lying, or you may not yet be seeing and experiencing what they are. If that's wierd, ok.
And that's fine. You can continue to live in your bubble. Others simply have different experience, and your asserting "AI is perfect" on a forum is not going to matter in terms of everyone's own, first hand experience.
Adversarial testing, checking developer assumptions, refactor suggestions, small dev tools and even some guided coding all sit on the other side of the spectrum of what you can do with coding and AI. For larger and larger codebases even simple things like tracing dependencies or behavior might be greatly aided.
And the critiques reserved for that narrow bucket on the other end, blindly generating code, are too easily conflated with the rest.
But AI is not smarter than you, AI is as smart as the user who uses it. It often makes wrong decisions unless user corrects it.
Google Home became so unbelievably buggy, and I felt so betrayed by that, that I stopped using every single Google product - from Gmail to Android to Google Cloud Platform. The few physical Google devices that I'm yet to replace account for 10% of my tech, but still cause 90% of my problems.
> Added support for model interoperability to leverage the unique strengths of both open-weights and proprietary models
Because creating 100x more bugs and fixing 100x more isn't something to be proud of.
But it's an open source project, you can go and figure out whether your assertion is correct.
That's not a great argument. GPT3.5 was launched over 4 years ago, so that's already significant compared to Chrome's age. LLMs notoriously also produce more verbose code than a human, so its not out of question that it might produce 5x more bugs on average given the same time frame.
They obviously have the full git blame statistics but chose not to include them in the blog post, which is a bit concerning.
HN is so weird on the topic of AI, and so many desperately are trying to contrive a reality. Odd stuff.
The elephant in the room is how many turtles obtained law degrees.
The elephant in the room is whether this is worth discussing because we're all in a simulation.
No, it isn't the elephant in the room. You made up some horseshit that betrays how little you know about the field, which will get upvoted because HN has a hearty contingent of "if I pretend AI is actually useless, maybe that will manifest in reality" zealots. It's bizarre.
If models can spot 13 years old critical bugs, I think they can also produce fresh code without those bugs. The skillset is the same.
As if humans are incapable of spotting critical bugs simply because they've existed for a long time? And we know humans don't produce fresh bug-free code, because the old bugs exist.
I think I'll abandon this discussion and keep using AI quietly while exchanging tips with like-minded people who are interested in using it properly and efficiently.
I feel this way on this topic too.
> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.
The problem is; how _should_ I use AI? On a previous thread, I had two replies to the same comment, one saying "provide the LLM all the context it needs and let it go ham", and the other saying "Carefully guide and craft it and review everything". Both subthreads had people agreeing.
My experience with LLMs is leaving them unattended gives very poor results within a handful of iterations, and that carefully guiding them can be a value add, but the effort ot do that is very often as much as just writing the damn code myself, particularly if there's a few iterations that go on.
I've found AI to be immensely useful in gamedev, mainly UX development, research, and curation. In those areas I let it go quite wild, with mechanical and visual tests for UX, and summaries for research and curation. I've also made skills, custom subagents, hooks, and scripts (all made with AI assistance) to streamline development.
Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big. If I worked on, let's say banking, I'd be much more careful. On my day job, as a data scientist (moving towards product owner) in a large industrial company, I'm much more careful. UX can run on vibes, but anything that touches data processing or business logic needs to be looked at by a human, row by row. Depending on use cases, it may be fine to look at only the tests. The main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.
It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.
> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big
I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.
> he main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.
I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".
I include a line in AGENTS.md that says "We *always* add docstrings to methods, classes, structs, and namespaces - there should be 100% coverage of docstrings."
It will make better choices about what functions to make or remove if you force it to justify why the function exists.
And when you have to go back and understand, it becomes easier.
They try to but they don’t. As an example, we use perforce in games. I regularly have to stop an agent and remind it to use p4 edit rather than blasting through the read only flag, despite the first paragraph of Claude.md being “this is a project using perforce. Batch call p4 edit on all files before modifying, do not manually remove the read only flag”
Yes, good addition.
> I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.
Yeah, I should have been more specific since our use cases are very different. I'm working solo on small games, so it's easier to keep the AI on a leash. I can imagine it can be a nightmare on large code bases with many collaborators.
> I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".
Yeah, probably our use cases are very different here too. We mostly develop/maintain dozens of microservices for internal use, mostly greenfield, relatively small in scope, and with 1-3 developers in each. And maybe 98% was a bit too optimistic. The larger and older the codebase, the more problems AI tends to create. But it's very good at helping to understand old codebases (even those written by myself haha).
Oh, and esoteric data science topics can be a minefield too. If there's a topic that's new to me, It's difficult to know what is hallucination and what is not. It's best to let AI suggest alternative methods and then study those yourself.
Hi, professional game dev here. No it's not. Thank you for reading.
I also encouraged my team to paste any inquiries or alerts we got in our slack channel verbatim into codex and follow that procedure until it could figure it out as a one-shot.
I still treat it as more of a design and coding partner day-to-day, so I'm typically not trying to one-shot, but it can e.g. be triggered by a pagerduty alert, reference our code, check grafana panels, query application state across different servers/clusters, and come up with bug fix PRs all autonomously, and then post its analysis, mitigation suggestions, and PR link to slack for the on-caller to review. This was all just some docs, scripts, and a little listener service to trigger a one-shot model prompt that we built.
As a design partner, it's made it easier to add more telemetry or create rapid prototypes to check my assumptions. I've encouraged my team to regularly ponder on what facts they wish they knew, no matter how difficult it would be to find out. Pretend you could just ask God anything you want to know. Then ask the AI to go add whatever's needed to find out. We should all move toward a perfect intuition for what our system is doing because all questions can now be easily answered if we can only think to ask them.
But one thing that doesn’t change is the need to specify an end goal correctly and precisely. I think the emphasis of knowledge/information-processing work is going to increasingly be placed on verification mechanisms. This is practically equivalent to precisely defining an end goal.
Spend time deeply thinking about what it means for a solution to be correct. What properties will a correct solution have? What of those properties are testable? Write those things down and tell the agent.
As models get better, agents will be able to target more and more difficult end goals. The strategy just becomes more useful. (It’s useful for people as well.)
For example, if you want an agent to write a photo editor, think about what end properties the editor should have. There are reference images for color space and rendering transformations. That’s a good start.
Sometimes the goal will be fuzzier. “I want a feature like CaptureOne where I provide a reference image and it makes my image look like that.” Well, time to think really hard about what that means. Iterate with AI on how to test for that precisely. Come up with some good metrics/heuristics. Maybe it means local contrast should match. Maybe the overall distribution of colors. Maybe something more complicated.
Then you have a target and you can let an implementation agent work against that. If it fails, it’s either because the agent is bad or your target was incorrect or incomplete. As models get better, the limiting factor becomes your ability to correctly define a problem.
I'm not asking for a one size fits all solution. I'm asking for "vibe coding with Codex on GPT 5.6 with high is the way, but if you want to be more ivnolved, Sonnet 4.6 on Claude is the path. Here's the proof."
Saying that it depends and it's impossible to quantify allows the camp who are claiming it's more productive to say "you're holding it wrong".
Or you can also use it piece-meal and have it do parts of work that you want. It works in both ways and works really well.
I don't think there is any model right now that you can use with 0 oversight, but you can do pretty complex stuff without writing single line of code at this point.
I also ask direct questions to AI for brainstorming and advanced programming language usage. In these cases, AI isn't touching the code.
I see this mindset a bunch, and I just don’t get it. Reviewing code is so much harder than writing code! To write code, I need to find one path to achieve my goal, and convince myself, the compiler, and the reviewer that it does so. To review code, I need to consider all reasonable paths to achieve the goal, and confirm that a sufficiently-good one was selected. This is why we have junior engineers write code and seniors review it. If you’re beyond your comfort level writing it, how can you possibly review whether the author (AI or otherwise) made good choices? You only have exposure to one possible choice lane, and by problem statement you weren’t comfortable populating the other lanes…
Seniors review code because they have a much better understanding of the necessary taste and discretion, and an awareness of the larger system the code will integrate into, whereas there's only so much you can learn about coding that's relevant to most of the code you'll write (and only so fast you'll ever really be able to type it, and most of the issues can be caught by automated, deterministic systems).
I do not know what the secret sauce is.
But I have a responsibility to the team I lead. I need to protect our velocity. Which means that my hiring practices now include specific checks that people are able to work with ai.
In the end, it might be a step thing. Some people are just inherently incapable of working with this technology...
The fact that people jump on the "you're simply using it wrong" wagon in every HN comment section whenever someone shares their negative/neutral experience with it implies otherwise.
Sometimes you need to set your oven to grill, other times fan force. But if you're complaining about getting burned then, yes, you're simply using it wrong.
> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.
However this is how it’s marketed. C-suite is telling people eventually you won’t need to read code, frontier labs saying programmers won’t exist etc.
The reality is like you said, a tool to accelerate you.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.
It works far better than the competition.
It seems like when people are talking about production level quality and how the AI. should be helping them there, plenty of people comes up with their “it works on my machine” anecdotes.
I will launch it by the end of August. After ~4 months of hard work.
My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.
The limitation here is mostly that the model does not know what looks and feels good.
With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.
Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct? Is the security layer good enough?…
The user interface part of the code is only one single component out of many.
I use a few of them daily. While there are still bugs, there are significantly less than there used to be back when everything was being maintained in my spare time.
Still not Netflix/Google standard yet, but definitely better than the average side project or pre-AI Bangalore special.
I think a lot of us were excited that we will finally be able to polish our old software.
Many of us were never given the opportunity and were tasked to produce new features at an ever increasing pace. Depending on where you landed you can be either elated or jaded.
Most of the tech people I talk to outside of HN, Reddit, Twitter, and other debate heavy spaces have a more nuanced view. In group chats we share stories about the amazing things we got out of an LLM today, or the hilarious failures or mistakes they made. We share tips and battle stories. We talk about the pros and cons of different models. We discuss the hard things we’re doing that LLMs can’t handle yet.
Go on HN or LinkedIn or Lobsters and there are some comments from people who seem like they’re coming from a different universe or timeline. Some people claim LLMs are doing everything in their life perfectly. They’re posting thought leader Tweets about working 2 hours per day and doing everything with ChatGPT voice so they don’t even need to be at their computer. Others are claiming that LLMs are useless and they can’t get anything usable out of them at all, or that they create more problems than they solve.
It’s weird. I can’t recall a time when people in tech were having hot takes that disagreed with such polarized extremes. Like I can look at LLM output all day long and see that both of the extreme takes are not right, but they’re all steadfast in their ideas.
I think LinkedIn belongs in a natural category with Reddit and Twitter far more than HN does.
Where do you suppose those misconceptions on how to use the tool comes from? That's rhetorical because the answer is obvious: the people selling the tools and their army of bots and sycophants. You can't be mad at people for being like "hey I tried to use this tool in the way it has been sold to me and its not delivering on its promises"
I see a lot of the disagreement here has the same form as many of the political arguments from 10 years ago.
It's so bizarre that noone realizes that there's a bit of a difference between banging together JavaScript into websites, writing firmware for widgets, herding servers or fixing medical devices?
That's my main issue with AI hypers. There's often no goal in sight, they're just busy for the sake of being busy. They talk about their process, but not their objectives. It's not about progress for them, it's only about being in motion.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
In fact, if it wasn't for the fact that it made making the actual changes I identified much easier (move these joins into a CTE etc) it would have been a detriment. Not only did I get sidetracked by a bunch of useless suggestions but I also had to put up with others dumping their raw AI output at me as if it was somehow a meaningful contribution.
Every single message from him, literally every time he communicates, it's a massive wall of text, overflowing with scope-creep suggestions like nothing I've ever seen before. It's impossible to ask him a simple question and get a simple answer.
And this seems to be a broader trend with AI in general. It's getting more and more difficult to retain some semblance of brevity with AI tools. I'm constantly asking them to "be brief," and "only answer the question I asked," and "don't provide more information than I requested," but they keep churning out more than I want in their responses.
It looks like a subtle attempt to use up more tokens.
That really bothered me that I finally announced AI "code of conduct" (more like AI usage expectation) and stressed that if one is not so kind as to have his/her coworker review AI output as it is, then I'll take formal measures to address that. We'll see what happens in the near future.
Really worrying that some people are totally comfortable with relying 100% on AI to do their work. Then what's human agency? What's the point of having them in the team (as opposed to just building an AI agent and work with that)?!
There's never been a shortage of low-value coworkers because hiring is hard and firing is unpleasant and painful in many ways.
But there's a weird phenomenon with AI where a lot of people are using it to actively call attention to the fact that they aren't doing anything but call the tools.
Rarely in the past have the I-just-want-to-coast-doing-the-minimum folks called so much attention to it!
For code gen and review, it's been pretty good since recent Opus versions, and I really like Fable's outputs (though a bit costly in terms of use). Fable is much closer to my own style for the couple things I've done with it.
I have yet to even consider replying to emails/messages with AI. I sometimes write a wall of text on my own, but it's entirely me.
And with hiring effectively frozen there is not even an incentive to let go of those people because they will not be replaced - they may have contributed little overall (routine tasks, oncall weeks) and now contribute 10x more spam while before they would not even try to investigate an issue, but we don't have the cycles to allocate that to someone else. And every time you tell them something they try to gaslight you by telling you they're trying to learn and you're being too aggressive.
I've become so frustrated by seeing claude-isms in slack or in emails it has become impossible for me to use it to work on my personal projects and I'm moving over to codex. Maybe it's time to try pi and some chinese models, definitely I need a break from this madness.
For a couple examples, working through an animated loader for html/js/css with an svg for the org. Another was working through a library implementation to work against an interface that was designed for Mongo, but the org is using SQL Server. Latest was a quick util to extract a zip file of pdfs into a 1bit(b/w), zopfli compressed png file per page.
Generally stuff I could do, but would take me a few days for research and experimentation vs an hour or two with AI.
Not sure how efficacious but I know the reviewer is just relying on the AI decision.
If you have to lie to get your tickets fixed, that sounds like either you're bad at explaining why things are important, or you're working on things you shouldn't be.
1) verify identical query results
2) run repeatedly to get average, worst, best, etc duration of runs
Sped up so many legacy things that none of us were ever going to bother with.
Is the harness for the AI set up with any sort of instructions to generally prefer broadly-applicable first-principals query performance analysis over unintuitive results that may be local maxima due to certain things specific to that env?
Even with humans I've had to unwind "optimizations" before that worked great for low-volume envs by taking advantage of 'be inefficient in the small scale with memory to save CPU and wall clock time' or such in a way that caused pain deployed.
Source: C. Northcote Parkinson, "Parkinson's Law and Other Studies in Administration" (1957)
I’m assuming he’s using it to mean “cruft” or “low value features” but maybe there’s some meaning I’m missing.
I originally heard it in the context of picking paint color for the bike shed, which is probably more on point for software engineers, most of whom would not be involved in any discussion around building a nuclear reactor.
Can only assume english might not be your first language.
People will recognize a glimmer of something they can attach to, prompt and get a few pages of junk about this narrow topic, and then contribute it in a way that further reduces the signal-noise ratio of the discussion or project.
Like, dude, we have the same tools. We can get the same slop from the tap at any time.
AI doesn't have enough senses yet. It's trapped in a box.
I can imagine the quality of bug fixing by unsupervised (we save money by layoffs) halucinating AI at current state of development.
"99 bugs in the code, 99 bugs in the code... Fix one bug, compile it again, 101 bugs in the code!"
(To the tune of 99 Bottles Of Beer)
If you want to learn darts or perfect parallel parking for example, most of the increase in accuracy comes from simply but very deliberately pointing out to your brain where you wanted to land versus where it did land.
We like to usually just do things and hope for the best. Defining success is not something we automatically do and naturally we don’t do it with AI either.
I’ve been working on UI component improvements and it was doing a lousy job until i specifically told it to test in a headless browser to validate it works. I think somewhere in an AGENTS.md i have an instruction to “don’t state your guesses as fact - validate findings and results”.
Imagine you’re blind and deaf and have temporary retrograde amnesia. You “wake up” one moment with a memory of some words in your head like “what is the bug?” …but you don’t recall the context of that question, and nor can you look/listen around to observe the context.
So you don’t know whether you’re e.g. at the office, in front of your computer, in the middle of doing some pair-programming (where, yes, you’d in investigate the bug thoroughly with tools), vs. having a conversation with a colleague over lunch (where the expectation is for you to tap into your knowledge + intuitions to either guess or say you don’t know — not to pull out your laptop.
That’s what it’s like to be one of these LLMs being prompted by some agent harness. Unless the harness injects the proper context into its “recent memory”, it just doesn’t know.
They will mock things to no end. They will flat out REMOVE assertions (saying it's not needed). They can also write test to assert the wrong result.
You have to always review it, it's exhausting.
And I think I know why - neither do most people.
Claude will do some boneheaded things for sure, but it's pretty good about writing tests that are useful, and not removing or modifying tests just because they're in the way.
Claude is pretty bad about assuming that it couldn't have broken a test it didn't know about, as it has often told me "this is already broken on main" which is definitely NOT true.
As usual, if you use anything but the best model available I’m going to state that the better ones do better. If you do use the best model available, then I’ll just mention that Fable still has limits and still needs some guidance.
One thing it does not do is deliberately build tests which test nothing at all, or which restate the code under test. I mention this because certain other models absolutely would.
Tests =/= TDD
Tests onli validate the presence of bugs, not their abscence (Djikstra).
I'll also add that tests look at outputs and don't care how those outputs are derived. E.g. code filtering the entire db in memory will be fine in tests.
Tests prove the things you thought of worked, and it often isn't hard to find the likely edge cases such that you have reasonable confidence everything works. You will be wrong from time to time, but not that often. You can prove code correct, but if the proof is wrong (common when a human is doing it), or the spec is wrong (most people have no clue how to write a comprehensive spec) it can still be wrong.
And then there's the endless code duplication, reinventing of existing code and libraries etc.
I work on user facing applications, and since the models do not have good taste, testing the UX is essential.
If you spot a bug, usually the model will attempt to reproduce it in a new test case that does cover the actual issue.
2nd line, code review.
Do the first pass with an agent, ask it to bounce back vacuous or tautological tests. Ask it to verify that the tests verify what they claim to. Then read them yourself.
3rd line, mutation testing. If the tests don't actually catch broken code, kill the mutants.
Doing a pass where you just ask the AI to sanity-check the existing tests (against rules like “test against the spec, not the implementation” can also help.
I don't strictly mean junit unit tests.
That'll get RL-d in, eventually.
Current AI isn't super effective at making the breakthroughs, but it sure is effective at democratizing the ones you can point it at.
Also let me ask you why we need better and better and models if what we have already can produce good output with 'all the tooling to verify its hypotheses'
“Good” isn’t “perfect” and even if it was, the ability to produce perfect output with all the tooling to verify its hypotheses could still be improved, in time and token efficiency, by better models producing fewer spurious hypotheses, rejecting those it does generate faster, and taking fewer unnecessary steps in confirming its good hypotheses.
This is such a blanket dismissal that I can’t agree or disagree.
Maybe very few of YOUR problems are this way. At least mention some problem domains.
Recent experiences: compiler-related (helpful), UI-related (agree it isn’t testable but the design iteration is quick, easy, and correct), debugging technical configuration problems (useless; I basically have to solve each problem myself before the LLM recognizes it).
> Maybe very few of YOUR problems are this way. At least mention some problem domains.
i did in second part of my comment. why do you think billions are being poured into ai if ai can already do verifable tasks.
Of course there's an issue if the data in the database is contractually restricted and you don't have a zero retention endpoint for inference, but the former usually comes with the budget to fund the latter.
The place to find them would be performance profiles, query plans, telemetry. The guidance for perf still applies, measure before and after change.
The issue is that the code often does not contain the information to do a perf optimization. Eg. you can't tell your cache size, the volumes of data in your DB or the latency of your network through just the text. Should you provide this context, you can get better results.
Tbh, once this information is available (which is the tricky part), in 99% of cases there's really no AI needed to analyze the data, since the 'low hanging fruits' will usually stand out anyway. And once you get into the area where optimization hotspots are no longer obvious, you're already deep in the diminishing returns area and optimizations for one use case or hardware configuration may degrade performance on others. That's my experience anyway.
Most people are not arguing that problems are too tricky for a human to solve once presented with it, but AI can look at 1000 things at the same time across a whole code base and then just come back with the results a human can review.
E.g. a good code analysis tool needs to work predictably at button press on any code base.
Still better than nothing of course, e.g. I actually think bug scanning / code analsysis is indeed the one area where LLMs are actually useful, but it suffers from the same 'diminishing returns' problem as traditional approaches, if not worse (e.g. still no silver bullet, but a mostly useful additional tool in the toolbox).
As I've seen it, there's a large chunk of those getting the most out of AI doing so because they weren't aware of or couldn't be bothered by already existing, more reliable alternatives.
I recently optimized some code asking Claude to "make it faster" 2 different programs. For each, it wrote a benchmark, gathered initial data. Emitted some hypothesis and measured data around them with profilers, then did some changes (behind feature flags), checked the output was identical in either side and through profiling that the right code path was taken, and then benchmarked both.
And it did that for multiple successive changes in both codebases. Some changes were purely algorithmic (better complexity), some were related to tradeoffs between memory and computation (caching intermediate results better), some were about creating less intermediate objects to relieve the memory pressure, some where about a better memory layout to improve data locality.
The annoying part is that some of the code that was optimized was generated by Claude in the first place, so it's a bit frustrating that it didn't do those in the first place. But I guess, my iterative approach to making those tools didn't work on big enough data sets at first where it would have been an issue.
Obviously you want empirical evidence to justify changes, but like... duh, you can read code and understand how it executes.
I can see in the code when data layouts aren't optimal, and fix that.
There's a lot of optimizations that need more of a deep dive, but you can get a lot of gains by just reading and reasoning about your code/data.
EDIT: To add, there are cases were you specifically can't read code and understand performance issue, but you should first ask, is that because you just don't understand the APIs/Libs/tools you're using, or is it fundamentally difficult. For example, often at work I see people complain about their torch code being slow and needing to bust out a profiler, but often those people just don't understand how tensor operations work internally so of course they can't reason about the code and see the way they're using the lib is suboptimal.
As an example Opus 5.0 is in completely different class compared to Cursor Grok 4.5 even if the benchmarks don't show such massive difference. Not even talking about regular stuff like Sonnet or Composer or stuff like that.
For performance testing, I wrote isolated testbeds that try to impair the system in realistic ways (latency/jitter/bandwidth limit on logical WAN hops when load testing), and Fable is happy to send a bunch of agents at it and iterate until it gets the results it's looking for.
I think that if you are used to Sonnet medium or something, this will surprise you, but models like Fable and Sol on high/xhigh will really dig deep until they meet your goal. (I mostly use this for bug hunting and not perf, but ... I think it can do perf if you set it up right.)
Once I have the baseline I'll just set a goal to improve performance by 10x. Works better than it has any right to. Have to be careful to exclude changes that massively increase complexity for tiny gains after its done, but the big improvements are often sensible choices that I'd also make as an engineer (i.e. more efficient data representation, caching and memoization where it matters, parallel processing, etc.)
Give Fabe 5 access to a test database with some data, or even restricted access to your live DB and tell it to optimize then.
I've had stunning success optimizing for performance this way. In a single day, I made the core part of our app 2-3x faster.
That's like saying Fable 5 should have told me how to prompt it to solve the Riemann hypothesis like Terence Tao would. The skill of the user still matters.
"I have not spent the time cultivating the soft skills necessary to leverage this tool successfully therefore it's the tool that sucks."
How about give pointers on "doing it right?"
Work on your project management, communication, and mentorship skills. The AI tools are much more like a team of sloppy but capable junior engineers and not a reliably consistent fabrication machine. Change your perception that one simple prompt is going to magically solve a hard problem the first time. Learn to break projects down, organize them into sub-projects, and implement them in steps. Learn to communicate more clearly, define your requirements more rigorously, and adapt around your "team's" strengths and weaknesses.
We want these things to be rigorous and flawless but reality is messy just like working with a regular team of engineers. They are good at some things, terrible at others, constantly changing, and unreliable. But we've historically built tons of reliable software on unreliable actors by focusing on process, collaboration, and communication.
AKA, not just the hard technical skills, but the soft skills that allow unreliable software teams to thrive. They don't know what they don't know and it's your job to manage that.
My expectation: inexperienced FP is trying to shoehorn a mutation-based approach into a framework that performs best with immutable data, or is manually recreating familiar structure (for loop) instead of using the idiomatic way.
But what do you tell someone in this case? They really need to learn more about the basics. Which is how I am interpreting the GGP’s dismissive-sounding comment.
Claude Code, Fable 5, xhigh reasoning, allow it to run the full CI, end to end and benchmark, it will not make silly mistakes (or only occasionally). Also, be able to state what you desire. Have any docs or materials in the same directory so the model can reference it. For even better results: turn on speech recognition and braindump what you know about the system, its goals, its context, history anything relevant, any gotchas you'd explain to a new employee or intern. Talk for 5-10 minutes. This is optional, "make it faster" can already get a large part of the job done.
And if it doesn't work well, describe what you dislike in its solution and tell it. Even just one extra iteration can make things work.
(I guess GPT-5.6 can be similarly good, I use Claude)
I feel like some people are emotionally invested in it not working and subconsciously sabotage their own effective use of the tool.
I was able to optimize a physical water simulation that was almost unrunnable on browsers to a buttery smooth 60fps version.
Turns out folks had been copy pasting some setup code which took 2 minutes to run, and only needed to be run once per environment. Claude refactored the code to get it to run once, and since we had tests which validated the build artifacts, it was able to roll back if its change had broke the build.
I'm thinking the issue is probably that LLMs/harnesses are too easy to use? It crossed the thin line between magic and tooling and blur the mental model. If Claude Code were as hard to use as, say, ComfyUI, perhaps there would be less programmers having absurd expectation of it.
The parent commenter was trying to learn how to use the tool. Perhaps he could've used it better, but like you said, what may have worked was not necessarily the intuitive approach.
The parent comment also changed his approach, and AI worked for him to test out changes. That's not expecting the tool to do all the work, he's actually agreeing with you that "expecting the tool to do all the work" is a misstep.
> others dumping their raw AI output at me
Sheesh.
It's not "hard" or novel--it's just tedious grunt work. I'm happy to have AI solving that one.
I had worked on some earlier deployment environments for a few models where we focused on one version of Triton and one runtime technology. Even upgrading to a newer Triton version was brittle, involving a lot of command-line changes at various phases. This was written mostly pre-Claude-getting-real-good. I decided that probably Claude had matured and was way better at understanding the particulars of AI-model-GPU-deployment-and-technologies. I worked with Claude to make the framework a much more lightweight wrapper, ignorant for the most part of a lot of the deployment internals.
After this refactoring and doing the first couple of models, it's quite amazing at how well Claude can figure things out. For any new model we now set up its "specialization" directory and its documentation subdirectory, point Claude at the proper AI-model files, point Claude to the sample non-optimized inference code and test data, and point Claude to a similar conversion we've done in the past. There a multi-layer class hierarchy dealing with various tiers. I ask Claude to explore the existing conversion/packaging, the model, any documentation that comes with it (a lot of times there are unexpected twists), the sample code, and the desired multiple use cases the model is meant to address, and the test data. Claude has been trained, I'm sure, on a lot of AI model conversion, so it's able to synthesize the full multi-stage conversion/deployment pipeline, come up with appropriate test cases for all the use cases involved. There are usually between 3 and 10 refinements after initial synthesis, fixing outright errors, refinemnts that the data-science team requests after playing with test deployments, etc. The options and pitfalls are vast, and without Claude each preparation likely would 10x or more longer. I just put most details in Claude's hands, and make sure the general framework is good enough to provide external uniformity. When all is working, it takes a couple of hours to make sure the documentation is good.
All this to say that at least for this domain, Claude / AI has been a game-changer and has sped up the process amazingly.
1. Ask Claude Code or coding agent to research the internet, documentation, and Github for examples and learning working with similar problems.
2. Make the ten best examples of solving the problem based on the research.
3. Run each against the database enough times (100, 1000, or 10,000,000 depending) to empirically prove which is optimized. You can set other criteria based on your knowledge.
4. ???
5. Profit
The point is, it is cheap to research combing through 1,000s of examples and learnings and test the best and most relevant.
I profile sql performance and LLMs find more opportunities than I could. All it takes is real data, a sql repl and an agent. Just ask the agent to use the repl to EXPLAIN and profile the sql. It works amazingly most of the time.
That might work better. I haven't tried it with SQL but it worked with a few complex UI issues I had. It identified the actual issue after a few false starts.
If you give the LLM the ability to run queries against prod-like data and review the paths, you have a fully autonomous system that can correctly optimize your ORM/queries. Been doing this for months.
pgAnalyze is a great complementary tool for this and they offer MCP
What model? There is no "AI", there are only specific models.
My experience is if you have been racking up the tech debt and have some low hanging fruit, Claude is really good at cleaning it up. If you have been properly stewarding the project, it's much less effective.
Then being able to suggest several things to try and have them go off and build, measure and tweak is hugely useful in my experience.
Also things like making custom visualisations for comparing changes.
I've been using Claude to create a software architecture diagram. It came up with a lot of useful functionality that we had neglected to show but upon further examination a lot of steps didn't make any sense. It added a box to do validation on some data then it put another box downstream to do validation again on the exact same piece of data (the second box had a different name but upon questioning, Claude conceded that it was the exact same validation step). When doing inference on user input, it put a box to extract specific insights from the prompt and then it put another box to do inference again on the inferred data to categorize it... And this would add latency and unnecessarily strip out useful context when doing the second inference... It really only needed a single inference step...
I re-uploaded the diagram to Claude and confronted it and it conceded to all of my points and it even noticed a theme between them and suggested that the diagram exhibited "a pattern of redundant steps." But it was incapable of suggesting viable solutions besides name changes. All of its solutions made the design more complicated. It was incapable of simplifying the design. I've noticed this with AI code; it can make things more complicated, add more features but struggles to simplify things.
Also, AI is horrible at rating things... It's just too superficial. For example, if you write a huge amount of intentionally over-engineered, tightly coupled code with poor separation of concerns but you do proper linting, define all the types, add a lot of comments, it will give it a higher score than a shorter, more readable and maintainable snippet which exhibits loose coupling and high cohesion because it lacks the superficial aspects.
It's horrible because now business people who understand nothing about coding may ask AI about code quality and it will consistently rank low quality over-engineered projects that are full of bugs, unmaintable and less secure, with a higher score.
Frustratingly, if you point out problems in its judgement, it will concede to your points without reservation, even building on top of your argument... but it will never actually tell you this stuff up-front, unprompted if you don't already know it! It never seems to reveal new insights, at best it can only expand on existing insight which you've already had.
It tells you what you want to know but not what you need to know.
that's the first mistake i made as a new claude user. i only knew what prompts people were sharing on forums. but since they had been written by vibe coders it was all complete non-sense. also think about this: software engineering is filled with highly specialised tooling that can easily improve software quality. the thing is, most developers dont know how to use them, and if they do -- using them is so slow that its almost not worth it.
any tool you can name claude can use. obscure academic proof verifiers, memory corruption scanners, debuggers, profilers, coverage tools, backdoor supply chain pattern scanners... it can run these and have results in seconds. really is like living in the future.
Performance optimization involves simulating real world loads and measurable results. Give them the opportunity to actually have a closed loop if you want more than trivial improvements.
It's not magic. Fairly obvious oversights that I or someone else on the team could've found and fixed if we had looked, but it was never a business priority so we never did until I curiously spent 5 minutes asking it to do it for me.
A few lines of Python with a time.time() call is enough to start iterating on performance improvements, and the really good models know how to use much more advanced existing tools.
You have to size the unit of work to its useful attention span, you have to have code architecture that is conducive to units of work, and you have to have tools like ticket managers, etc. that keep the big picture and smaller pictures in mind. Reverting from agile practices to more pre-planning whole project documentation and architecture decisions helps.
But in the end it's you. LLMs have their limits and need humans to direct them.
If you really need something to latch onto, there's plenty of educational material available about how to be an effective scrum master. Start there.
Some AI skeptics paradoxically insist humans are irreplaceable and then get almost mad(?) when you discuss how humans are necessary in the loop. At least that's my interpretation of what is going on, it's hard to tell.
When building with LLMs I'm mostly product manager and QA, the whole task is having the judgement to evaluate and correct course. You can share advice but it's not a copy-paste situation where one set of prompts/harnesses/whatever solve all your problems forever. They have to be adjusted for a particular situation.
The trend I've noticed is that AI struggles to think outside the box when making optimisations, which exactly what's needed when you've made all of the practical DB and logic optimisations to the existing code.
Often you need to take a step back and question how the system is working and if there would be better ways to design it so the bottlenecks you're hitting wouldn't exist in the first place. Caching things, adding indexes, tweaking logic – these can help, but you'll quickly hit diminishing returns once you've done all of the obvious stuff.
I've seen people here say how AI is great at optimising code though, but I'm not sure if that's because they're giving it optimisation problems with a lot of low hanging fruit or if they're successfully getting AI to rework their systems to remove bottlenecks. This one area I find AI to still be particularly bad at.
And at worst you still saved a bunch of time on writing the tooling to test the issue
But that's ok - I still get a lot of value of the tool elsewhere (e.g. writing data analysis scripts, exploring code, breaking down bug artifacts...), but it doesn't stop the tiring BS from other people going "why not just AI it?" (especially from managers).
I usually let them try to "just AI it" and most of them learn quickly that it's not that simple. (The others stay deranged and are making my job miserable.)
That's uninteresting as long as you don't specify the model you used. For example, Mythos was far better at finding security bugs than previous models.
The SOTA: Fable, GPT 5.6 Sol, Opus 5
The "enterprise admin did not turn on the new models": Opus 4.8, GPT 5.5
The "I love hallucinated garbage": Sonnet, Qwen 3.6, GPT 5.4 mini, GPT 5.3 Codex, etc.
Results vary widely
Before that, Gemini 3 Pro in Antigravity.
I have no experience with GPT 5.3 beyond seeing the nightmares colleagues produced in their MRs with GPT 5.3 Codex. It could be that they had the distilled 5.3 Codex Spark selected, I am not sure.
I guess just another area where the LLM is useful only as long as you remain in charge using your own programming experience as a guide.
I'll believe in AI when I get to resize my Configuration Manager!
https://developercommunity.microsoft.com/t/Resize-configurat...
Just open up a configuration window manually, tell if that the Window is open and it can pull apart the executable from there.
Biggest impediment would be Fable safeguards if it tries to decompile.
You're absolutely right! Let me fix that.
Any tips?
Then try starting with voice mode (if you're comfortable chatting out loud) and just talk your way through it.
Build a sandbox, download Codex CLI or Claude Code or whatever and spend some time doing some creative stuff with it just for the sake of learning how it all fits together.
Pay attention to the inputs you provide and the outputs that they result in. Keep your bullshit detector engaged: Bots often lie.
If you get stuck, or it gets stuck, or you want prompting advice or whatever: Ask any frontier-level bot for help. Sometimes, it's very instructive to get help from Claude for an issue with Codex, or vice-versa.
Want better tools? Ask the bot to suggest some that exist. (None of the existing tools fit? Have the bot write new ones.)
All of this stuff is always in a state of flux, so even with the lies they'll do better at teaching than any fixed reference will. They're LLMs and processing language is what they tend to be best at... so go ahead and use that.
And remember: They're designed to behave kinda-sorta like humans, but they are not humans. They're just computer programs. If you don't like their output style, or they don't like your input style: Ask them how to implement rules that make them knock that shit off. :)
> the “latent security issue.” Code that is safe and robust in isolation can be transformed into a critical vulnerability by an entirely unrelated, minor logic change elsewhere in the tree.
Similarly, you can accidentally fix a bug without discovering/triaging it, so the pointless repeated bug lifecycle is incomplete
First they made it so when it came to rest it would then start scrolling again and overshoot by 2 lines before coming to a halt.
They fixed that after a few weeks then it worked until last week and now it’s left in a state where as it’s coming to a halt it jerks every time like dropping frames of the scroll almost.
I know it’s not my machine, config or trackpad because I’m seeing it on multiple computers.
Google claims to help open source developers, but donates millions to the Alpha Omega Foundation that did not give access to Mythos to Curl and only found one issue.
The Alpha Omega people appear to be selected on physical appearance and take the money away from open source without doing much.
The entire Chrome article is obviously directed at suits and unsurprisingly hypes AI for better promotion chances.
Just to have a sense of proportion, considering an average software engineer salary of $200k, that same money would buy you 650,000 engineer-year salaries. Of course there are other expenses, but that gives you an idea of the order of magnitude.
And introduced how many new bugs? thanks to AI ...
Recently I noticed an unusually high number of web inspector bugs fixed by one longtime WebKit engineer, and I suspected AI assistance, though the commit messages include no disclosure of this. Nonetheless, the increase in volume was quite dramatic.
The other day, an update to Safari Technology Preview was released, and I attempted to verify whether a couple of my bugs were indeed fixed. However, it was impossible for me to verify, because the latest version of Safari Technology Preview introduced a new web inspector bug that totally broke the features I was testing.
Thus, I remain unimpressed.
Without a doubt, LLMs have demonstrable skills and can produce code much faster than humans. I never thought that producing code fast was wise, though, even before LLMs arrived. For many years I've criticized software development based on management-driven release schedules, where developers are forced to pump out code regardless of quality, regardless of whether it's ready. Your boss may not like it, but code is done when it's done, not when your boss says it has to be done. If software complexity were predictable and reproducible, then indeed management could replace engineers with automation, but that's not how it works in reality.
Back to Chrome, the browser is notorious for continually adding invasive new "features" to the web that nobody wants except advertisers. I wonder how many Chrome bugs were the result of Google push push pushing all of this new crap on users over the years?
Fast foot didn't kill fine dining, but it is killing us..
This is wrong on almost every count.
1. The numbers are by milestone not month.
2. The latest milestone (or month) did not exceed the previous two years of milestones.
3. The only thing discussed are security bugs, not bugs in general.
What is true: the article is about Chrome.
Do you import new more bugs?
But since Google cares mostly about its investors, the numbers and a mention of Gemini in such a blog post are more important.
Some were probably just theoretical "if we have over 2B of this item, it'll crash because X/Y/Z and that can be exploited", some are probably in rarely used features.
Once the LLMs are done going through the code, the baseline will be all better and they will probably fix a lot less than they have now. Or they will have LLMs automatically check every single crash bug that has been submitted and take care of those too. I am assuming that they are probably already using this as an input source for their AI.
I've mostly only used Codex for reviews, for Godot/GDScript code, and it helped me catch bugs that would've taken me ages to even notice on my own; games be tricky like that.
Claude was mostly useless or annoying up until the last time I tried it (about 3 months ago)
You have to be vigilant though: Codex often picks out obscure edge cases and suggests adding multiple new functions and flags to avoid issues that would be better off left as fast-failure crashes. Maybe that's because of the 5.6 Sol Max I leave it on.
Google.
We really need an alternative to this greedy and evil corporations de-facto controlling a huge portion of the modern www stack. All decision-making processes are here subjugated to what fits Google's adEmpire. This is a perpetual system of control amplifying abusive systems in place. We already see this with the recent age sniffing; Google just yesterday announced that all android users must hand over their age to everyone else. Before that google kicked out or locked out open source alternatives to android (or, at the least, made their life significantly harder than before). These are not isolated ways of abuse - this is systematic abuse.
We really need alternatives to Google here. It can not be that one tyrant company dictates so much of people's open lives (and no, Firefox is no alternative; Mozilla is basically a nerfed and bribed entity that has given up on firefox many years ago already; ladybird may become an alternative at one point in time, but right now is not and there are questions over how Kling handles the overall project, but these complaints are significantly below what Google is doing globally here).
Fixing more bugs in the adChromium code base does not change the underlying problem at hand.
We do / have? Multiple even. Of course, the vast majority of consumers doesn't care so they don't get as much traction.
I'm wondering what the Alphabet employees still commenting on this forum have to say about it? I guess for the right comps they can keep their mouths shut no matter the high level of idiocy involved.
There are many things it's not good at (eg design and architecture), but that doesn't invalidate the things it is good at. Everyone is learning how to best use it and there are growing pains. Ignore the hype and try to find the common patterns in what people say.
And it wasn't just 2 humans but 2 Googlers. One Googler author and one Googler reviewer works. But an external author needed 2 Googlers to review changes, and all files needed to be reviewed by one author at least.
So if you touched multiple files owned by different people for a more complex feature, you would naturally get there.
I got Codex to find and apply a bunch of settings I didn't know about and in the future I hope to use AI to make real changes in performance that venders probably don't have time or resources for.
that being said, what I've learned so far is essentially WhyIsItAlwaysHN's entire comment "The place to find them would be performance profiles, query plans, telemetry."
I just find it so frustrating that for a user interface that was basically solved in the 90s, Windows GUI still struggles to survive on hardware exceptionally more powerful than what we had 30 years ago
0 - https://www.lacksan.com/updates/ 1 - https://github.com/Lacksan-Dev/HP-ZBook-Performance