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.
A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value correctness or security enough. We didn't have good alternatives until recently because we did not, collectively, invest in developing these alternatives.
One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year.
Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change.
So really, the problem isn't that people complain too much, it's that they don't complain enough :)
The real curious thing is serious C/C++ folks seem like one of the least likely groups imaginable, to want to undergo humiliating and embarrassing blunders…
Yet they seemingly don’t mind that it practically guarantees them to make blunders over and over again.
We call them blunders mostly because the solutions are so well known.
In contrast, the last company I worked for did everything in typescript and the amount of problems caused by code that blocked the main event loop was staggering. And at that, our best JavaScript people generally just threw up their arms saying there wasn't a good way to fix it.
Between the two, I prefer a language that lets me fix problems.
"our best java script people" I've used node.js for more than a decade now, I was there for the start of "now everyone is truly full stack"...but yes the majority of developers I've worked with have had no idea about how js etc works on the inside, no knowledge of event loop or what causes the few memory leaks possible in js.
But then again I only know because I love that shit and started out in c/embedded, c# etc. And on my own weak side I fucken suuuuck at frontend related stuff (not the design stuff at all, just...fuck you css).
Pre-Rust "serious C++ folks" used it because it was the best option if you wanted essentially zero performance overhead no heavy runtime and GC spikes. They didn't like the lack of memory safety but it was seen as an unfortunate but necessary trade-off.
These days most of the sensible people have moved from C++ to Rust and so the "serious C++ folks" are an entirely different distribution of people who are much more inclined to think memory safety isn't a big deal and you just have to not make mistakes.
or Swift! I know it isn't super popular outside of Apple ecosystems but I migrated a C 200k LOC personal project to Swift over the last ~4 years and it's gone really well.
Show me a programming language that doesn't result in developers "making blunders over and over again" when developing the kind of very large software C/C++ is used for.
Wrong. It is the market that doesn't value correctness or security enough.
We have the tools (formal verification) to create bug free software (see seL4 and CompCert for example). However customers are not willing to pay for the extra cost needed.
> And the barriers are far more social, organizational and political than they are technical.
At the core it's even more of an economic barrier which isn't even unique to capitalism.
I recall an article talking about why the Romans didn't invent steam engines and things like railroads considering people were aware that steam could be used to do work. The answer was largely that slave labor was so cheap that nobody really cared about finding more efficiency. It didn't solve any problem they had at the time.
The analogy transfers to the tech industry today, economics tend to drive most decisions. While I love technology and think research and innovation is important for its own sake -- particularly because we might not know what we're missing out on unless we explore -- but those controlling the purse strings have other priorities.
Others might point out that the economic cost of the bugs and failure cases in programming languages without memory safety might actually be greater than the cost of developing alternatives or accepting less performance in exchange for correctness. They're probably right! But unless you can measure it and present it on a spreadsheet to the management class, they won't acknowledge or understand it. It's really difficult to measure "incidents you didn't have". In any case it still might be cheaper to work on the next big startup idea, hype it & sell equity -- that strategy has produced trillion-dollar valuations recently. However correctly or incorrectly that may be, the benefit to an elite few is very real.
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).
File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction.
The programs that do benefit from speed aren't file browsers.
I certainly also remember the kernel crashing, but this was in the 90s. Later perhaps once or twice on faulty hardware. Shell, I don't think I have seen this ever.
In my case, the crashes were from last year to the start of this one. Some were related to AMDGPU, others to my WiFi card driver, so they're pretty recent.
I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.
C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power.
C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets
For example, I kinda know that the code
for (size_t i = 0; i < 64; i++) {
// ...
}
...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc.
This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.
No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.
I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do.
You really do have to write the code that iterates over a list and applies a transformation, you can't just do
[x + y for a.x, a.y in b]
...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction.
Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do).
But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.
That change is happening. Microsoft has been rewriting parts of Windows in Rust, Linux is accepting Rust code, and Apple is using Swift for core parts of their OSes.
> I'll await your Rust ports of Windows, Linux and MacOS then.
Unironically this. Like most game developers, I was extremely sceptical of Rust, based on opinions I've read on the internet. Ugliest syntax I've ever seen, and "safety" features are irrelevant and just get in my way. Compile times are glacial. Tons of direct and indirect dependencies needed.
But then I got to use it professionally for a year or so, and I was MINDBLOWN by how much less stuff I have to keep in my working memory at all times. And libs like tokio and actix-web were so well-designed that I actually enjoyed reading the code in my free time. Fighting the borrow checker? I had like five such instances in the first month, understood what it wants and why, and it never bothered me again. Compiles were indeed slow, but I went from "if it complies the first time around, I'm probably missing something" to "if it compiles the first time around, it's most likely correct".
Turns out, I had significantly underestimated what Rust brings to the table, while focusing on stuff that wasn't really that important once you get used to it.
Nowadays I'm back to gamedev. I'm happy about that, because my year in cloud/edge dev felt like we were consistently solving the wrong problems. But I do wish my current team was more open to giving Rust a chance. It solves so many actual problems, and is being dismissed with reasoning like "sorry, I don't have programming socks". And by very smart people! WTF is this timeline?
Granted I doubt how true that is, I always understood the benefits of languages like Haskell and Ada/SPARK, it's just that pragmatically speaking I want beginners in my team to be able to code too.
Computers have gotten more than an order of magnitude faster since safer languages got into the same speed and memory ballpark as C, but we keep wasting that speed. The model T of memory safety was Java 31 years ago. (I'm not sure what lisp is in this analogy.)
It's not a fair take in the sense that replacing the backbone of lead solder plumbing and paint in 1960's wasn't a fair take, and plenty of us are still awaiting the lead-free replacements.
> I'll await your Rust ports of Windows, Linux and MacOS then.
I’d love to have that happen within the next century. I might not be around for it, but I’d say that humanity deserves software that has fewer memory issues.
The thing is, I'm not even against it. The point of the sarcasm was to say that the most massive projects on which everything is built are in C-flavored languages so the claim that it's not fit for large projects is absurd. And to say that replacing those foundations is going to take time. I would love memory safety in those, but it is going to take time to build something as battle-tested.
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.
When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code.
Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change.
So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change.
Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers).
Did bugs still get missed? Of course, just like today even with today's new tools.
> 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.
This is correct (I worked on chrome in 2008) it's important to remember that chrome's renderer was webkit, an existing c++ stack.
Chrome's stability innovation was to run different tabs in different processes, and the security innovation was then to sandbox those processes.
Rust would have been super nice but it wasn't an option then, and of course let's remember that Rust was developed by Mozilla specifically with the goal of making safer browsers.
Quite frankly, this post is massive set of unsubstantiated claims.
For starters, no one said the only problem with Chromium is C++. But it certainly contributes with some of the problems (specially those related to security). And, no, these bugs don't come from "noob programmers." They come from experienced engineers.
Then you just mention that removed some "unnecessary and unwanted" code. According to what standard? You? Would be nice if you went into specifics and provided some benchmarks. Instead we are forced to take the word that a user "rustfreeforme" (wonder which biases they have) made an polished fork, instead of, possibly, mangling the code in such a way that just benefits them and screws other people.
Finally, Rust doesn't: make the code more complex than C++, specially if using the STL; doesn't make compilations slower, as C++ and Rust compilation times are on par (and keep in mind Rust is very unoptimized here, where as C++ is slow by design).
> Oh no, it seems my one brief post wasn't long and detailed enough to immediately and totally convince some Random Doubter on HN, therefore my 'claims' are 'unsubstantiated.'
No, you just didn't cite any actual data, only assertions. Don't come with this excuse of "busy day", you had enough time to create an HN solely for spewing anti-Rust nonsense.
Keep in mind, HN is a place for intellectual discussions, not for dumping your pet peeves. If you don't actually have anything actually productive to say, it's preferable to omit yourself before the mods or the flags do that for you.
> Nah. It doesn't.
Then try to prove it. I already cited a source elsewhere, which you just ad hominem'ed. The burden of proof is now on you.
> It's definitely not possible for fluffybucktsnek to just take my word here. I wonder what biases he or she might have.
Yeah, what biases does the name "fluffybucketsnek" indicates? "Rust free for me" doesn't sound as impartial in this discussion. It just sounds like you came here for an ideological battle.
> Yes, you should just assume that's what must have happened, and then move on, blissfully unaware of how wrong you are.
I didn't assume anything. If anything, I kind of wish you did/could prove me wrong. You could, at least, post the code of your fork.
Instead, you need us to assume that all your claims, none of which has any sources, are true. All I did was show a different possibility.
> Sure it does. There is extra machinery/interfacing for all the extra Rust crap bolted on, and it gets more and more complex over time as they integrate more of the crap.
Every FFI introduces some manner of complexity, specially when one language (Rust) is more strict than the other (C++). I don't say C is complex because JNI is a hassle.
> Furthermore they vendor the entire Rust compiler, library, etc, all of which has to be compiled first before the browser.
That just seems like a Chromium project issue, not a Rust one. It's weird that for issues with C/C++ in Chromium, you blame the project itself, but for Rust, you blame Rust. Just like you don't have to vendor LLVM, you don't have to vendor Cargo nor Rustc along with the project itself. Even for compile times, similar strategies for cutting C++'s work for Rust as well.
Makes sense, but strangely, no one has responded to my question about why Servo hasn't been picked up, if Rust is such an important factor in browser engine implementation. People are calling using C and C++ "ridiculous" and "irresponsible" and "not fit for purpose". And yet, no one's using the alternative that's sitting right there?
Because Servo is unfinished, and companies have different priorities. For instance, Microsoft could've have been strict and formally checked code for Windows since the inception of constraint checkers, but they chose other priorities. Now they're are slowly trying to integrate Rust to help reduce security bugs.
People who believe in total unsuitability would be acting silly indeed. But most would agree that writing code on languages that provide better and safer tooling is a positive.
Sure, the main Rust compiler currently depends on LLVM, which is currently written in C++. But the rustc team might choose to follow a similar path to Zig and replace LLVM, or LLVM might get rewritten in Rust.
Finally, while most bugs are logical, the most damaging ones, security bugs, are primarily related to undefined behavior.
The problem is that you think Rust programmers despise C or C++. We don't. We just think there are better alternatives for modern development. In fact, a lot of Rust programmers were experienced C or C++ programmers.
And then you say:
> [...] your belief system.
What do you mean by that? What beliefs? This just sounds like projection.
> Please do so at the earliest opportunity, so that your language can actually become an alternative to C++.
It already is an alternative to C++. The fact that LLVM is written in C++ doesn't change the fact that you can write software that otherwise would be written in C++ or C, in pure Rust without writing a single C or C++ source nor header file.
What a reductive view of reality. That's like saying our entire world is built on assembly. That's just missing the point.
> Saying Rust is the replacement to C/C++ is like saying Python is the replacement to C/C++. No, not quite.
With analogy such as these, I see where the "No, not quite" comes from. For starters, we can write actually low-level Rust code enough to write kernels without needing to interface with C code, only raw assembly. I don't think Python can do that.
> I don't go to Google for advice on how to design software, thanks.
Good thing they weren't giving advice, but reporting that most security vulnerabilities came from just bad memory access, which contradicts your counter assertion. None of that is subjective. Whether you think they are the ideal programmers or not is irrelevant.
You can also take the opposite conclusion from this: C++ is now viable because LLMs can catch the security bugs.
I'm obviously not entirely serious here, but I think this is true to some extent: the number of memory safety bugs in a codebase is finite. Once you have a way to find them, you can drive that number down to zero.
C++ has become a far safer language thanks to LLMs - at least if you run the LLMs before you are attacked.
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.
Actually, if you implement a JavaScript runtime at all your choice is either too slow for modern web users or `unsafe` everywhere. Runtime values are often simultaneously either words that encode immediates or pointers to heap blocks and doing this the proper way blows up time and space. Doing it the fast way means you have `unsafe` everywhere and Rust's lifetime model can't help you at all. Everyone chooses the fast way.
Maybe Rust let's you encapsulate the unsafe a little better than C++ but the wins are going to be surprisingly small. If you had to build it today you'd maybe use Rust but the case for rewriting an existing C based runtime in Rust is not that strong.
Also for things like interpreter loops the absence of computed goto in Rust stable is a real performance killer. Explicit tail calls (the `become` keyword in nightly) work but maybe you don't want your big rewrite to rely on that.
Assume that you are writing a green field project in C++. If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? I don't have a lot of experience with them, but I found it dramatically reduced memory related bugs. I'm a very average C++ programmer, and those templates helped me greatly. Do you think it would help Chrome/ium to use (more) std::unique_ptr and std::shared_ptr?
Chrome uses those already, and a few other pointer types that are fit for purpose.
For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected.
Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).
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.
Why is everyone always referring to logic errors when pushing back against Rust? No programming language ever invented (or to be invented) will fix logic errors made by developers.
Logic errors are "out of scope" for Rust or any other programming language.
No shallow dismissals please, tell me why you think I'm wrong.
> Rust is not a major advance over C/C++
Rust adds the borrow checker (and especially with non-linear lifetimes it's an implementation like the world has never seen before, not even in Cyclone). That alone raises it leaps above both C and C++.
But even without it, it still has a Hindley Milner type system (which most people considered superior to multiple inheritance), it has Sync/Send traits, the concept of UnwindSafe, proper destructive moves and affineish types, proper sum types and matching, sane iterators, lack of UB on uninit/overflow/etc, a sane module system, hygienic macros, and that's just the things I was able to pull of the top of my head right now.
Not to mention, the design of its stdlib is absolutely lovely compared to what C++'s stdlib has become, and it focuses on correctness much more than most other popular languages.
The more verification you do, the more likely it is for a program to be correct. Lean towards Assembly, and you get less correctness, but lean towards Ada/SPARK, and you get more.
Rust is a notoriously difficult language specifically because it adds some limited verification features, going further along that correctness continuum than C. I didn't think that could even be disputed.
The "if it compiles it probably works" feeling most Rust programmers experience is proof that those verification features work, too.
> In time you will learn about all of the faults and flaws in Rust
I've programmed enough safe Rust and unsafe Rust that I'm now very familiar with most of its flaws, and yes, it has many. I'm also familiar with C and C++'s flaws, and they're so, so much worse.
> after you've suffered the pain of trying to rewrite the entire universe in it
My goal has never been to rewrite the universe in Rust. Battle-tested software is fine to stay as-is, unless it needs constant updates and new features, where most memory bugs appear.
With that said, a couple years ago, at work, our team finished migrating a couple of performance-sensitive services from C++ to Rust, and not only were they both successful, but they became 5x and 10x faster respectively, because it's so much easier to do direct memory reference stunts that would've been possible, but crazy via C++'s std::span and lambdas.
> I know exactly what the successor to C/C++ looks like, and it's not Rust.
What does it look like?
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted
Everything I listed is compile-time complexity. I'm not sure how you can add any of it at runtime without extra runtime costs. Or are you talking about modifying the C language?
We might argue over whether that complexity is worth it, for sure, but once again: "if it compiles it probably works" is a very common sentiment with Rust.
But also, what you're saying sounds very much like the Blub Paradox [1]:
"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."
> Most of it is wankery, the sort of stuff that 20-somethings salivate over
I'm not sure how that is relevant to what I said? I have 30 years of experience with C, and have read the C specification cover to cover, plus more recently some 15 years of C++ experience in parallel at work. I still use all 3 languages today.
> Again, the actual successor to C/C++ looks nothing like Rust.
> In time you will learn about all of the faults and flaws in Rust, after you've suffered the pain of trying to rewrite the entire universe in it just to fix one single class of problem you are obsessed about--inevitably introducing many new bugs in the process, because that always comes with the territory.
Good thing Rust doesn't just fix that one class of problems, but also provides better tooling to fix other classes too. Classes of problems that could be fixed with the other features of Rust mentioned later like the Hind...
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I?
...the vast majority of these features don't even run at compile time. Some of them can't even be implemented in C. For starters, show me an example of a Hindley Milner type system implemented for C (how can someone improve a strictly compile time feature, static typing, with a runtime implementation is beyond me). Or proper destructive moves in C or C++.
> Ada is the language to emulate, [...]
Good thing Rust also takes from Ada.
> Again, the actual successor to C/C++ looks nothing like Rust.
It is obvious that you are just trolling, but for other readers: our production app went from 50-100 unexplained sentry errors in typescript to 0 sentry errors in rust.
The language absolutely helps fix logic errors.
It's something that becomes immediately clear as soon as you start using the language in earnest.
> Wow, what a magical language! [ waves hands vigorously ] will fix all the problems which are inevitably introduced by auto-porting from one language to another, or by manually rewriting everything from scratch. Rust doesn't obey the same laws of the software universe as other languages, it seems. Or is this a "just use magic AI bro", type situation?
Nope, that's just your own prejudices speaking. We already cited features (seen in and inspired by other languages) and you handwaved them away with "I don't care". You are the one fixated on C and C++. You are a C evangelist, if I were to make a guess. And that's on you.
> In the latter case, why don't I just use the to auto-magically solve my C/C++ problems, rather than rewrite the entire universe from scratch? You know, like Google claims to have done for Chromium C++ sources in this very news article?
You certainly can. But to spin this the other way around: in lieu of the Bun case, why not use it to rewrite the project in Rust, Zig, D or any language of your choice (yes, even C)? Given the role harnesses have in keeping agents in check, it seems plausible that languages with stricter safety features help agents avoid common issues.
> This is the type of shit noobs are always wringing their hands about as they need maximum guardrails to cover for their ineptitude.
You seem to be forgetting that proper software engineering is just as much about managing developers and their skills as the actual code structure. If a tool helps noobs produce better quality code, specially ones without as many vulnerabilities, why not employ it? Also, it's not like experts are immune to mistakes either.
> It could compile and still have 10,000 logic errors.
It could. Switch that to C or C++ and the amount of logic bugs is likely going to triple.
> Rust is not a major advance over C/C++, only an incremental and quite limited one, [...]
"Nothing ever happens." I guess you could consider borrow checking, an actual module system, type classes, enum variants, compiler-integrated macros, async/await, etc. to be just small increments. (Theoretically, you can reimplement most of this in C++, like std::variant, but they don't integrate well into the language - having to declare a type just to use std::visit is certainly not as simple as using match).
> [...] which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.
"Introducing numerous other errors"? Would be interesting to see an citation on that. From what I've seen, these "new errors" were already present in the original "perfectly good code", except the original also had instances of undefined behavior and logic errors from poor type modeling.
> But don't take my word for it [...]
Why would anyone other than your friends take your word? You could have substantiate your claims with actual evidence.
> [...] after the hype has worn off [...]
Which already did. Nowadays, I see more posts about Zig and Fil-C.
>[...] left with the sad mess that is Rust.
I went to read your comment history to see if you elaborated on this "sad mess" of Rust, but you didn't. How about you do it here?
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.
Basically all C programs I use, shells, editors, terminals, etc. But I do not claim that there "never has been a memory-related bug" but that it is not "riddled with" memory-related bugs, which I would expect would have manifested in at least one segfault over all these years, which I did not observe.
You make a false equivalence between being an idiot/“didn’t know what they were doing” and not knowing how to properly manage memory. Also, why do you think the devs who worked on google chrome weren’t idiots?
Some of the most important and safety critical large scale projects in the history of humanity had/have manual memory management. If you think the effort of doing it correctly is not worth it for certain projects, that may be a reasonable opinion. But the idea that humans cannot write correct C/C++ programs is in direct contradiction to historical fact.
if you go around pulling out logic flaw arguments and then proceed to commit logic flaws yourself, it isn't a good look man. the quoted statement was "beyond most intelligent individuals" which contradicts your assertion that the argument was stated as "humans cannot write correct C". anyway I do find it ultra amusing how software engineers believe software engineering is the backbone of programming, when in reality it is merely the flesh. we landed men on the moon long before Rust was even zygotic. for all its benefits, the argument to use memory safe languages ultimately serves to benefit large corporations who can faster generate profit by faster churning out code.
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?
> 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?
To me the most probable explanation is that they automated a way to find (and fix) existing vulnerabilities in a way that was not possible before.
Some holes were probably very small, some were probably almost impossible to actually exploit, I don't doubt it. But still, I find it very hard to not consider this a strong security improvement overall (unless they made those numbers up)
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.
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?
Thanks! I do believe I’ve read that piece (I worked in a similar area in a past job) it indeed is a good one. However I do think a big portion of the articles on blog.google are semi-marketing pieces, e.g. check this list: https://news.ycombinator.com/from?site=blog.google
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.
> 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
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.
I will say - and this is just my own experience and not a certain userwide trend response - that one benefit of LLMs is that they are able to take an annoyed observation and format it into a pretty stellar bug report, and then the human being can work on spit-polishing. Having the middle part of the composition automated is a real benefit (at least IMO) - I've been a better reporter.
I previously reported on my own and was ignored; now, not so much. I assume that the assistance by the LLM is providing needed detail or formatting. (Yes, I am reading what I am submitting and making sure it is optimal before sending it.)
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.
Hard disagree. Google holds browser PWN contests and pay people for reporting bugs. If they can find the bugs themselves, they won't have to pay others. Also, there is a business interest, controlling the browser market helps their data collection and ad business. People could drop Chrome like they drop IE if Chrome does not perform - there are other browsers. "inaction for the past decade or more." I don't follow Chrome dev but this is entirely false.
What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI.
The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.
Let's be honest with ourselves, AI review is better than human right now, especially top tier models. Not saying that for important project like Chrome, you can skip reviewing changes. Far from it. But it is probably better and more thorough than most human devs already.
It’s not better than human review. It’s good at catching low-hanging issues but it is often requested overly-defensive code to handle edge cases that don’t exist or are handled elsewhere in the stack. It generates a ton of noise with low-signal comments. It basically cannot at all identify problems that pose the highest risk, like integrations, correctness from a business perspective, etc.
To be fair it’s also worth noting that it’s much easier to find a buggy edge case with existing code than it is to write bug free code that doesn’t have any edge cases at all. It’s so much easier to read some concrete logic and find holes in it, than it is to start from nothing and end up with perfection. It’s true both for humans and agents, but agents are better are validating correctness.
My own reviews have shifted now. I tend not to examine detailed semantics anymore. The AI is as good or better than me at assessing whether a chunk of code does what the author said it was supposed to do.
Instead my job is to spot design and architecture smells, broader semantic errors, violations of unspoken business requirements, etc.
For example, I was recently reviewing code that built out a transactional flow. Part of that flow involved recording the transaction somewhere user visible and I knew that should only happen after the transaction was confirmed. AI implemented it where the transaction was posted.
That starts as an issue of underspecified requirements but that always happens in the real world. Thus that's where I can provide the most valuable insight: assessing with that context, whether business, operational, historical, or forward looking.
to be fair, with AI reviews i'm finding the opposite to be true. Anytime I push a one line fix it continuously tells me about all of the edge cases I didn't handle until it's pretty much bullet proof
Google improved chrome by reading code: Google built an agent harness using Gemini to scan Chrome's codebase, trained on a knowledge base of prior CVEs and the entire Git history, with a "critic" agent consuming developer-supplied SECURITY.md files.
In my experience, I find it to be exceptionally good at exploring and fixing the edge cases. Of course the output is not human maintainable for these fixes and needs to be heavily tests controlled, refactored or just accepted as being agent-maintained going forward.
I think I've seen it the other way. I told an AI I had data coming in at some fixed, slow rate that I wanted displayed. It did the job but only for that case. It literally put a polling loop to catch one sampling at that duration. I've noticed it gives me very specific code to the exact data, or wildly complicated code for all possible data to ever exist. Finding the middle ground has been my challenge
If that is the case, isn't that the failure of your testing strategy/setup? If your style doesn't fit full vibe coding - you can do the path of AI generate code - human reviews and tests all edge cases flow - I think in any serious software - that should be the flow until next few iterations. But either way, don't see a going back to coding every line by hand now, those days are gone. Was fun while it lasted!
No. I’ve heard this argument multiple times before - “let the human review and write tests” - and sure it might work, but this is almost never practiced. AI makes coding a lot faster, so no one is really ready to spend time on manual review and writing tests when LLMs can do that as well and take you most of the way.
This is evidence of culture problems in whatever teams you are a part of, or extrapolating what you see on social media to all of software engineering.
We still have a very strong review culture, and people work hard to review their own code before making PRs to avoid wasting other people's time.
I'm happy that AI hasn't taken over yet but I do not know how the future for studens will look like and I don't know how we will continue training humans.
Its also has no big picture - it just can add ever more - cancer can grow, but it will kill the host organism and end years down the line as a dead end.
The "engineers" using that AI. Could they repass the whiteboard tests of old? Have not some of them quietly left?
Let's replay this post but imagine Google made this announcement before LLMs were wide-spread (say, 2019). Below, I replace "AI" with "human programmers".
> What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to human programmers.
> The big problem is that human programmers output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.
Your argument falls apart quickly because the exact reverse is equally as likely. Also, whenever I see someone say "just wait longer" for some effect to become apparent, it feels like a lazy argument.
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.
There's no reasoning with the folks who are anti-ai and claim LLM's cannot produce anything worthwhile. They are basically flat-earthers or anti-vaxxers at this point. There is literally no amount of evidence that will convince them. They will always say that LLMs cannot produce anything but garbage just like the anti-vaxxers who state vaccines just cause autism. They are both fucking morons who no one with any grip on reality should indulge.
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.
Sure it is. It's just like the .com bust: people didn't know what the internet was good for, so they did a lot of stupid stuff with it before settling on the most interesting uses.
No, AI is more like: people do know what it is good for, but that's immaterial because hundreds of billions of dollars of debt were poured into it, such that the only glimmer of hope of getting an ROI out of it is force-feeding AI everywhere, good or bad, and normal people are sick of that.
That's fair. I still think there big similarities (people with money seeing it as the future and investing heavily, even if in reckless ways), but I agree there's a forcefulness to it this time that wasn't present before, for the reasons you outline.
> If you were the CEO of Amazon, would you be setting up channels for people to talk about their AI failures?
I would set up channels to talk about AI, encouraging both successes and failures, with proofs required for both, and punishing people who intentionally misreport on either.
That's fine, lies are more harmful than anecdotes are beneficial. There's no forum to discuss the best IDE and people still manage, in reality there's no need for a forum around AI.
Well, you're at Amazon. Is the Dev Improvement discussion group still around? I feel like that was a pretty good place to learn about neat stuff (in my case, Emacs-related). I enjoyed the discussion.
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.
This is the thing the anti-ai zealots will never admit. Humans fucking suck at writing code. They talk about software development as if it's only ever performed by the top 1% of the top 1%. They never acknowledge that humans make mistakes. No. Humans create perfect code every fucking time while LLM's only produce slop. It's such a fucking mind-numbingly stupid position that I have to think they have never actually worked in an organization which produced code as a value. These fucking morons want to pretend a human never introduces a memory leak when it's plain as fucking day that vulnerabilities that these "expert programmers" introduce to software are rampant. But no. The anti-ai zealot likes to pretend that only LLMs ever produce bad code. The only bugs in existence are due to LLM slop and not the literal decades of fucking slop produced by humans without any LLM assistance. It's so fucking tired at this point. They will never be able to admit that current day LLMs are far beyond the median human programmer. Their opinions are fucking useless at this point. These idiots think The Daily WTF started with LLM code. They are basically anti-vaxxers wrt to their grasp on reality. No one should take them seriously to any degree.
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.
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.
After doing a bit more research, this fact is somewhat less impressive. Apparently, this was also the first time in nearly 20 years that there was such a large capacity crunch and many researchers weren't able to get into the competition. One of the rejected researchers did apparently have a working exploit, which, upon not getting into the event, they responsibly disclosed, and it was then patched before the event.
This was, itself, driven by AI vuln finding, ironically :-P however, I took the example of @ggwhyp's Firefox RCE - quite a long chain, rejected by the organizers but probably would have won some cash from Mozilla... Details aren't public, so we won't know. Maybe their vuln was patched with Bug 2024918? At this point it's anyone's guess...
But the fact that nobody else who made it through had an exploit and claimed $$$ on Firefox tells me that improvements were made.
And this is what blew my mind, personally; a _browser_ - huge, complicated target codebase with myriad features, many of which are 'on the internet' - didn't have any disclosures with money on the table. That's definitely a datapoint worth registering. But you're absolutely right to remain skeptical!
Yes, I agree that this is still a datapoint for real world utility of AI assisted vulnerability fixing. But it's not as simple as an apples-to-apples comparison with previous years.
I'm honestly unsure if this is a Poe's law thing or not. I'm going to go ahead assume that you are doing the honorable thing of purposefully not including a /s for the integrity of the joke.
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
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?
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).
Microsoft surely has enough resources to keep their fork going if they choose to, so I see no reason why Google would try that given they would likely end up with less control over the web.
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.
Yeah, as I said in a reply to another comment, I oversimplified there. What I should have said is that solo or almost-solo gamedev with relatively small games is a good example of where AI shines. I don't have experience of developing larger games in larger teams.
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.
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".
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.
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).
Seeing a solved problem and verifying the solution's correctness is much easier than solving the problem yourself. it's a bit like riddles. You can find examples of that when studying any topic. I disagree that reviewing code is harder than writing code in all/most instances.
Also, there's code that is just tedious and repetitive to write. AI can write that and reviewing is pretty easy.
You could ask someone a math question, and they can write an equation down, and the equation can be mathematically sound, but it still not be the right form of the equation, or even relate to the question correctly at all. If all you're being asked to do is validate the mathematical soundness of the equation then sure, it's not that hard and it often mechanical, probably easier than having to generate the equation. But that isn't review -- that's cargo-culting what review is supposed to be.
To bring back to code: They are making the point that verifying "correctness" is not the be all and end all of code review. In every situation, there are multiple "correct" solutions, and only a few of them are actually correct and fit within the past, current and future context (technical and business). If someone isn't doing this, they aren't reviewing effectively and are acting as a glorified linter, which is an astonishingly low value-add use of human capacity.
There are situations where nobody really cares about the output, and nobody wants the true form of review, so it reverts to (at best) human-linting. In those situations, engineering capability of any kind functionally has no moat and all participants are equally fungible. If the business is dependent on engineering it's also a horrendous business. I would personally avoid being involved in these environments in an engineering capacity. I mean this in a diagnostic sense - it's a terrible career move, though there will always be busy work that's exactly what we have LLMs for.
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.
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...
it depends on what it is you are doing. if the complexity is low (frontend, GUI) you can just prompt it once and refine at the end.
if the complexity is high but you know how the task is to be done then what you can do is divide the task into pieces yourself or with the help of the LLM and use an LLM for each piece.
if the task is complex and you don't have a good idea how it is to be done then you need to start exploratory work with the LLM (multiple sessions, don't reuse the sessions for code).
how to use an LLM correctly is a skill in and of itself. the people who say that LLM's are bad either haven't used any good ones and have such disorganized thinking processes that they are unable to encode them into English good enough for an LLM.
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.
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.
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.
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.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?
This has essentially no practical relevance to app implementation.
What we are left with is not corrupting user data, particularly during migrations on app updates.
Compared to the attack surface of a backend service that handles user data, this is trivial.
We agree that the delicate work is presentation and interactions working well on device.
In my opinion this is best supported by extensive manual QA and user testing, rather than code review.
This is what unlocks tremendous productivity for mobile app development with AI.
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.
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.
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.
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.
Hell, $20/month is a pretty good deal for something that can proofread a 100 page report, do some light research work, and write some quick and dirty scripts. It doesn't have to replace the entire job of programming to be really damn useful. The pushback against using it even for these simple tasks seems utterly unreasonable to me.
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.
> 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"
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 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”.
I hope this weird redefinition of bike shedding doesn’t take off. It’s a useful and meaningful term and repurposing it to mean AI slop is negative value.
Thankfully until this thread I’d never seen anyone use the term this way.
> Can only assume english might not be your first language.
This not-subtle insult does not add anything here.
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.
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.
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.
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.
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.
> 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.
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.
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
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.
Until a couple of years ago you needed to be able to read research papers and code to build fuzzing harnesses and triage the findings to find vulns. Now you can point Claude, codex, Kimi, or even some smaller open models that run local and get a servable fuzzing loop in a couple of hours.
That's democratization - shifting power and skills away from those with the wealth to purchase vulns and run offensive security teams. It's still not simple, but it's one of the reasons bigger vendors want to lock down the capabilities of models that present a threat to the wealthy and powerful.
Sure. Wealth has always given early adopters and first movers wings.
As hardware specs get better, and model providers keep making different classes of mistakes that alienate users, more people will opt for or support local models. I tend to take Schneiers' "Attacks only improve" philosophy and apply it to damn near everything like this. Inference will get more expensive, but IMO cloud based inference is at or near the maximum that users can tolerate, across multiple spectra. There may be a marginal increase in cost, but as the different metrics between what is affordable for rapidly scalable, cloud based inference and the lag of local inference with open models and expensive hardware converge, prices will come down.
I am not the right person to say what the peak is going to look at, but when the companies with (practically speaking) unlimited compute resources and money are starting to take a good hard look, there is going to be a drive towards efficiency. I hear grumbling at work, and the appreciation from my leaders when I show up with a tool that shows how I reduced my token costs, or I keep asking the questions of what the token cost (real, and internal billing) are for tools my peers write are.
I also have absolutely eye-watering personal AI bills that are starting to make buying a better tier of local inference gear look more affordable, even with inflated hardware prices. The current generation of open models are very effective, and paying for multiple $200 dollar a month subs is not feasible longer term, and as one example, in one month, if I was paying enterprise token rates, I would have burned through $8000+ token budgets on one of those accounts, doing actual, practical useful work, it makes more sense to buy some much better hardware than to pay for one-time inference costs.
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 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!
Ironically, in synchronous conversations, the same co-worker is constantly going on about how swamped he is, and how he's being pulled in so many directions.
Apparently, it takes a lot of time and work to manage all those AI chat bots.
> Rarely in the past have the I-just-want-to-coast-doing-the-minimum folks called so much attention to it!
You seem to presume that they realize they're calling attention to it.
On Stack Overflow, there was this phenomenon for a while where people would blatantly copy and paste answers from ChatGPT, have them deleted, and then run to the meta site to complain. The complaint would either be in barely comprehensible broken English or in recognizable ChatGPT-ese. It would involve swearing up and down that no LLM assistance had been used. Looking at the user's history would reveal a gap of several years of not answering questions, and then the old answers would have the same barely comprehensible broken English (and often not be very good technically, either). The OP demonstrated a genuine complete inability to understand how obvious the ChatGPT use was.
This happened multiple times with different users.
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.
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
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.
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.
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.
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.
That these performance hogs were in production reinforces my point that you can't spot slow code just by looking at it, unless you already know that it's slow.
I even have an example myself, but I'm not sure I can share it in detail. It was a common idiom that was used throughout the code. After tracing a performance problem to a specific function, it was immediately obvious to me that the common idiom was the problem in this function, and how to fix it very easily. But only because I traced a performance problem to this function. Otherwise I would have skimmed over it.
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.
Sometimes when you look at code you know is slow, you can immediately see why it's slow. Obviously you didn't see it when you wrote it, which disproves your hypothesis.
What? Sorry, I genuinely have no idea what you're talking about. Is it possible to look at code and intuit, just by reading, how to speed it up? Duh, yes. If you disagree, lol.
Keep in mind that I've never stated that all performance issues are findable through code review. Just that there are many that are.
> You can very easily spot performance issues through code.
If you think that this is false, there's literally nothing you can contribute.
I can't take this seriously. The claim "you can look at SOME code and see how to optimize it" is trivially true, and saying "you can't look at ALL code and see how to optimize it" changes nothing.
Exactly, you have to find the slow code first, with profiling, and then sometimes it is obvious why that code is slow. It is unlikely you can just look at a project and find the slow code in it.
You absolutely can. I've given enough examples that are obviously true. If you can't read code and reason about its performance, that is a personal issue.
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.
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".
Profiling is awesome, I do that. But it's also way slower. Like, 1000000% I'm with you, that's the right way. But I've seen huge gains just from reducing allocations and changing hash algorithms.
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.
Then it's for sure a guidance or missing context issue. When given full access to everything they need, these models deliver results on par or above the best coders I've ever met and they are lightyears ahead of the lower 90% of developers. I feel more and more that when users report they can't solve their problems this way, it's like when a gorilla is mad at Einstein after talking to him and he didn't make bananas grow instantly.
The only parts where I would disagree are that capabilities are spiky, and also the fact that they're a bit prone to losing the forest for the trees without guidance (the macro/micro distinction). But yeah, by default I don't write code by hand.
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.
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.
> 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.
My problem with the “high level advice” is that the results it gives are bad. Sure, sometimes it gets it right, and it helps but I’d wager about half the time the results are just bad. Hence why I’m asking people to show their homework here. I think that the anthropic rust rewrite is great example - it shows yes you can do a lift and shift assuming you’re ok with those constraints.
> Some AI skeptics paradoxically insist humans are irreplaceable.
But yet in this comment thread we have people saying “just point it at your code and let it go” like [0], you saying “just follow the vague instructions and if you can’t get the results that I’m telling you you’ll get them it’s your problem. But it’s too circumstantial for me to be able to tell you how to work”
> where one set of prompts/harnesses/whatever solve all your problems forever
I don’t want forever, I just want to know what is actually working today, or this week, or this month.
>But yet in this comment thread we have people saying
I'm writing for myself, not including myself in any group of people.
>I just want to know what is actually working today,
With LLMs I have facilitated the writing of about a million SLOC over the past 9 months.
- A GitHub "clone" with many enhancements which all of my development is hosted on
- A task manager as though kanban had a baby with a FIFO stack
- (in progress) a CAD kernel potential Parasolid competitor
- reverse engineered a vehicle diagnostics tool to diagnose and fix some car problems I was having more easily
- plenty of other small, half baked, or abandoned projects for one reason or the other
LLMs amplify me, they don't do things "for" me. They are working very well for me, but I have definitely hit their limitations in many places and transitioned back to the hardest problems to solve being on the human side of the equation.
What they can do for any particular person depends on the person and if they can come around to really grokking the human-machine relationship.
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.
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.
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.
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.)
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.
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.)
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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
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.
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
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.
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.
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.
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 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.
I'm also curious if they used Mythos. Google definitely had access to it via Project Glasswing. However, your logic doesn't hold. That sentence only tells us they were using multiple models, but offers no real clues as to which proprietary model(s) they were using.
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.
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.
>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.
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.
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.
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.
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...
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.
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.
I've also seen similar recently at my place of work with LLM linting. Lots of hard to spot bugs in old very critical code have been caught. I remember seeing similar kinds of impacts back when linting or sanitizers were introduced. They're good for making it easy to encode more complex rules/areas-of-focus etc. that may have not been meaningfully possible with the more traditional tooling. Commercial LLMs in their current incarnations make for very expensive, but very effective intelligent linters.
On the other hand, my experience so far has been that they are terrible code-reviewers, to the point almost everyone ignores any kind of generic LLM review entirely (correctly - most of it is noise).
I feel the industry obsession with full-automation causes them to go down the wrong rabbit-holes on full-automation vs augmentation. In my view would be significantly more effective if the LLM review process in forge-tooling was designed with a human reviewer in the loop. The goal imo should be drastically improving the review efficacy & throughput of the human element, who needs to be acquiring confidence in & socializing the change in any sane org anyway. For example iteratively & interactively rubber-ducking out analysis + remediation, or interactively providing focusing guidance on the patch, instead of as agentic batch or harness processes as is cool nowadays. Sometimes a custom REPL is just better for an expert system. These things matter more as more and more code is LLM generated.
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.
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.
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".
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.
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. :)
They show how many more bugs they fixed compared to previous periods, but not how the amount of resources allocated to fixing bugs changed over time. If they allocated proportionally more resources to bug fixing, it really doesn’t tell us anything about the tools being used.
Might as well be that the learning here is that if you put resources on fixing bugs, you can in fact fix a lot of bugs.
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 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.
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
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.
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 ;)
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
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
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?
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.
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 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.
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.
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.
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.
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 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.
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.
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..
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.
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.
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!
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
All the evidence is against you here, sorry. Just read the google or microsoft security blogs, linux kernel mailing list, or any of the published security research about bug density in Rust vs C++.
Or you can bury your head in the sand while the rest of the industry is moving on, I guess.
This post is basically a massive projection. When I guess, I make my guesses explicit. You, however, consistently make guesses and pretend they are true. You misinterpret facts so you can conveniently fit them into your narrative.
I don't want "To Be Right", I just don't want dunces slopping nonsense into this comment chain. Not my fault you fall into that group.
I don't need to assume Google's intentions and goals here. I want to see what they've done and the results they've reached with each action. I want to learn. You just want to reaffirm your delusions, that's why you have to pull the "you will learn" card rather than show objective metrics. If you really cared about quality, you would have them ready to present. Given that you haven't and even avoided doing so, it's safe to assume, as most of us have learned through experience, this to be a case of placebo at best. And placebo is not the sign of a good programmer.
Next time, provide some actual data rather than vague self-gloating. Then, we can have a discussion.
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
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.
A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value correctness or security enough. We didn't have good alternatives until recently because we did not, collectively, invest in developing these alternatives.
One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year.
Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change.
So really, the problem isn't that people complain too much, it's that they don't complain enough :)
The real curious thing is serious C/C++ folks seem like one of the least likely groups imaginable, to want to undergo humiliating and embarrassing blunders…
Yet they seemingly don’t mind that it practically guarantees them to make blunders over and over again.
We call them blunders mostly because the solutions are so well known.
In contrast, the last company I worked for did everything in typescript and the amount of problems caused by code that blocked the main event loop was staggering. And at that, our best JavaScript people generally just threw up their arms saying there wasn't a good way to fix it.
Between the two, I prefer a language that lets me fix problems.
"our best java script people" I've used node.js for more than a decade now, I was there for the start of "now everyone is truly full stack"...but yes the majority of developers I've worked with have had no idea about how js etc works on the inside, no knowledge of event loop or what causes the few memory leaks possible in js.
But then again I only know because I love that shit and started out in c/embedded, c# etc. And on my own weak side I fucken suuuuck at frontend related stuff (not the design stuff at all, just...fuck you css).
Pre-Rust "serious C++ folks" used it because it was the best option if you wanted essentially zero performance overhead no heavy runtime and GC spikes. They didn't like the lack of memory safety but it was seen as an unfortunate but necessary trade-off.
These days most of the sensible people have moved from C++ to Rust and so the "serious C++ folks" are an entirely different distribution of people who are much more inclined to think memory safety isn't a big deal and you just have to not make mistakes.
or Swift! I know it isn't super popular outside of Apple ecosystems but I migrated a C 200k LOC personal project to Swift over the last ~4 years and it's gone really well.
> These days most of the sensible people have moved from C++ to Rust
Wrong. There are more than 16 million C++ developers worldwide.
[dead]
Show me a programming language that doesn't result in developers "making blunders over and over again" when developing the kind of very large software C/C++ is used for.
> The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects
The industry as a whole throws away orders of magnitude more engineering-years _daily_ in meetings discussing if scrum standups are effective.
> ... don't value correctness or security enough
Wrong. It is the market that doesn't value correctness or security enough.
We have the tools (formal verification) to create bug free software (see seL4 and CompCert for example). However customers are not willing to pay for the extra cost needed.
> And the barriers are far more social, organizational and political than they are technical.
At the core it's even more of an economic barrier which isn't even unique to capitalism.
I recall an article talking about why the Romans didn't invent steam engines and things like railroads considering people were aware that steam could be used to do work. The answer was largely that slave labor was so cheap that nobody really cared about finding more efficiency. It didn't solve any problem they had at the time.
The analogy transfers to the tech industry today, economics tend to drive most decisions. While I love technology and think research and innovation is important for its own sake -- particularly because we might not know what we're missing out on unless we explore -- but those controlling the purse strings have other priorities.
Others might point out that the economic cost of the bugs and failure cases in programming languages without memory safety might actually be greater than the cost of developing alternatives or accepting less performance in exchange for correctness. They're probably right! But unless you can measure it and present it on a spreadsheet to the management class, they won't acknowledge or understand it. It's really difficult to measure "incidents you didn't have". In any case it still might be cheaper to work on the next big startup idea, hype it & sell equity -- that strategy has produced trillion-dollar valuations recently. However correctly or incorrectly that may be, the benefit to an elite few is very real.
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.
yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that
You can have that without writing them in C or C++.
you sure can. i recommend forth
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).
File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction.
The programs that do benefit from speed aren't file browsers.
There are a lot of applications like that though, only they're all being rewritten for electron.
It's the only example I could come up with. There aren't that many programs written in Pascal.
You can’t compare apples to elephants here.
Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.
The C programs I use daily are generally very fast, very lean and very stable: Programs such as linux, terminals, shells, vim, etc.
Most programmers don’t have 30 years to perfect their code
It had no crash during 30 years, not after 30 years.
I did, in Linux. It was pretty common too. It got fix. But, every now and then, I still get an occasional panic.
I also recall having my shell crashing (zsh or bash, I don't remember).
I certainly also remember the kernel crashing, but this was in the 90s. Later perhaps once or twice on faulty hardware. Shell, I don't think I have seen this ever.
In my case, the crashes were from last year to the start of this one. Some were related to AMDGPU, others to my WiFi card driver, so they're pretty recent.
I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.
I’ll take a Qt application over the Electron garbage that we see all the time nowadays.
It could be worse but that's not much of an argument for C in particular. There's a lot of ways to do UI that don't involve web engines.
10-100x develop & maintain cost.
good. browser uis always end up sucking more
false dichtonomy
C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power.
>therefore lacks any guard rails you'd expect in a programming language
This is simply not true. Guardrails are enforced by the compiler, and both gcc and clang have a myriad of flags to make C safe, not to mention Fil-C.
How is it high level assembly? Have you written much assembly recently?
C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets
For example, I kinda know that the code
...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc.This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.
No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.
I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do.
You really do have to write the code that iterates over a list and applies a transformation, you can't just do
...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction.Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do).
But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.
That change is happening. Microsoft has been rewriting parts of Windows in Rust, Linux is accepting Rust code, and Apple is using Swift for core parts of their OSes.
> I'll await your Rust ports of Windows, Linux and MacOS then.
Unironically this. Like most game developers, I was extremely sceptical of Rust, based on opinions I've read on the internet. Ugliest syntax I've ever seen, and "safety" features are irrelevant and just get in my way. Compile times are glacial. Tons of direct and indirect dependencies needed.
But then I got to use it professionally for a year or so, and I was MINDBLOWN by how much less stuff I have to keep in my working memory at all times. And libs like tokio and actix-web were so well-designed that I actually enjoyed reading the code in my free time. Fighting the borrow checker? I had like five such instances in the first month, understood what it wants and why, and it never bothered me again. Compiles were indeed slow, but I went from "if it complies the first time around, I'm probably missing something" to "if it compiles the first time around, it's most likely correct".
Turns out, I had significantly underestimated what Rust brings to the table, while focusing on stuff that wasn't really that important once you get used to it.
Nowadays I'm back to gamedev. I'm happy about that, because my year in cloud/edge dev felt like we were consistently solving the wrong problems. But I do wish my current team was more open to giving Rust a chance. It solves so many actual problems, and is being dismissed with reasoning like "sorry, I don't have programming socks". And by very smart people! WTF is this timeline?
The Blub Paradox [1].
Granted I doubt how true that is, I always understood the benefits of languages like Haskell and Ada/SPARK, it's just that pragmatically speaking I want beginners in my team to be able to code too.
[1] https://wiki.c2.com/?BlubParadox
Clearly you just need to buy those team members some nice programming socks so they can finally enjoy rust.
Computers have gotten more than an order of magnitude faster since safer languages got into the same speed and memory ballpark as C, but we keep wasting that speed. The model T of memory safety was Java 31 years ago. (I'm not sure what lisp is in this analogy.)
They're working on it for Linux: https://rust-for-linux.com/
It's not a fair take in the sense that replacing the backbone of lead solder plumbing and paint in 1960's wasn't a fair take, and plenty of us are still awaiting the lead-free replacements.
That doesn't mean we shouldn't do it.
> I'll await your Rust ports of Windows, Linux and MacOS then.
I’d love to have that happen within the next century. I might not be around for it, but I’d say that humanity deserves software that has fewer memory issues.
The thing is, I'm not even against it. The point of the sarcasm was to say that the most massive projects on which everything is built are in C-flavored languages so the claim that it's not fit for large projects is absurd. And to say that replacing those foundations is going to take time. I would love memory safety in those, but it is going to take time to build something as battle-tested.
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.
When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code.
Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change.
So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change.
Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers).
Did bugs still get missed? Of course, just like today even with today's new tools.
> 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.
This is correct (I worked on chrome in 2008) it's important to remember that chrome's renderer was webkit, an existing c++ stack.
Chrome's stability innovation was to run different tabs in different processes, and the security innovation was then to sandbox those processes.
Rust would have been super nice but it wasn't an option then, and of course let's remember that Rust was developed by Mozilla specifically with the goal of making safer browsers.
[dead]
Quite frankly, this post is massive set of unsubstantiated claims.
For starters, no one said the only problem with Chromium is C++. But it certainly contributes with some of the problems (specially those related to security). And, no, these bugs don't come from "noob programmers." They come from experienced engineers.
Then you just mention that removed some "unnecessary and unwanted" code. According to what standard? You? Would be nice if you went into specifics and provided some benchmarks. Instead we are forced to take the word that a user "rustfreeforme" (wonder which biases they have) made an polished fork, instead of, possibly, mangling the code in such a way that just benefits them and screws other people.
Finally, Rust doesn't: make the code more complex than C++, specially if using the STL; doesn't make compilations slower, as C++ and Rust compilation times are on par (and keep in mind Rust is very unoptimized here, where as C++ is slow by design).
[dead]
> Oh no, it seems my one brief post wasn't long and detailed enough to immediately and totally convince some Random Doubter on HN, therefore my 'claims' are 'unsubstantiated.'
No, you just didn't cite any actual data, only assertions. Don't come with this excuse of "busy day", you had enough time to create an HN solely for spewing anti-Rust nonsense.
Keep in mind, HN is a place for intellectual discussions, not for dumping your pet peeves. If you don't actually have anything actually productive to say, it's preferable to omit yourself before the mods or the flags do that for you.
> Nah. It doesn't.
Then try to prove it. I already cited a source elsewhere, which you just ad hominem'ed. The burden of proof is now on you.
> It's definitely not possible for fluffybucktsnek to just take my word here. I wonder what biases he or she might have.
Yeah, what biases does the name "fluffybucketsnek" indicates? "Rust free for me" doesn't sound as impartial in this discussion. It just sounds like you came here for an ideological battle.
> Yes, you should just assume that's what must have happened, and then move on, blissfully unaware of how wrong you are.
I didn't assume anything. If anything, I kind of wish you did/could prove me wrong. You could, at least, post the code of your fork.
Instead, you need us to assume that all your claims, none of which has any sources, are true. All I did was show a different possibility.
> Sure it does. There is extra machinery/interfacing for all the extra Rust crap bolted on, and it gets more and more complex over time as they integrate more of the crap.
Every FFI introduces some manner of complexity, specially when one language (Rust) is more strict than the other (C++). I don't say C is complex because JNI is a hassle.
> Furthermore they vendor the entire Rust compiler, library, etc, all of which has to be compiled first before the browser.
That just seems like a Chromium project issue, not a Rust one. It's weird that for issues with C/C++ in Chromium, you blame the project itself, but for Rust, you blame Rust. Just like you don't have to vendor LLVM, you don't have to vendor Cargo nor Rustc along with the project itself. Even for compile times, similar strategies for cutting C++'s work for Rust as well.
You have chronology backwards. Lisp predates C by 14 odd years. Pascal was contemporaneous.
Well we make work with the tools we have
It worked well enough, maybe "fit for purpose" is a stronger word
Makes sense, but strangely, no one has responded to my question about why Servo hasn't been picked up, if Rust is such an important factor in browser engine implementation. People are calling using C and C++ "ridiculous" and "irresponsible" and "not fit for purpose". And yet, no one's using the alternative that's sitting right there?
Because Servo is unfinished, and companies have different priorities. For instance, Microsoft could've have been strict and formally checked code for Windows since the inception of constraint checkers, but they chose other priorities. Now they're are slowly trying to integrate Rust to help reduce security bugs.
You know what's funny?
Windows was built in C when "C was not guaranteed to win", hence why they have weird things like Pascal calling convention etc
[dead]
People who believe in total unsuitability would be acting silly indeed. But most would agree that writing code on languages that provide better and safer tooling is a positive.
Sure, the main Rust compiler currently depends on LLVM, which is currently written in C++. But the rustc team might choose to follow a similar path to Zig and replace LLVM, or LLVM might get rewritten in Rust.
Finally, while most bugs are logical, the most damaging ones, security bugs, are primarily related to undefined behavior.
[dead]
The problem is that you think Rust programmers despise C or C++. We don't. We just think there are better alternatives for modern development. In fact, a lot of Rust programmers were experienced C or C++ programmers.
And then you say:
> [...] your belief system.
What do you mean by that? What beliefs? This just sounds like projection.
> Please do so at the earliest opportunity, so that your language can actually become an alternative to C++.
It already is an alternative to C++. The fact that LLVM is written in C++ doesn't change the fact that you can write software that otherwise would be written in C++ or C, in pure Rust without writing a single C or C++ source nor header file.
> False. Nonsense. Not true.
https://www.chromium.org/Home/chromium-security/memory-safet...
[dead]
> YOUR ENTIRE WORLD IS BUILT ON C/C++.
What a reductive view of reality. That's like saying our entire world is built on assembly. That's just missing the point.
> Saying Rust is the replacement to C/C++ is like saying Python is the replacement to C/C++. No, not quite.
With analogy such as these, I see where the "No, not quite" comes from. For starters, we can write actually low-level Rust code enough to write kernels without needing to interface with C code, only raw assembly. I don't think Python can do that.
> I don't go to Google for advice on how to design software, thanks.
Good thing they weren't giving advice, but reporting that most security vulnerabilities came from just bad memory access, which contradicts your counter assertion. None of that is subjective. Whether you think they are the ideal programmers or not is irrelevant.
You can also take the opposite conclusion from this: C++ is now viable because LLMs can catch the security bugs.
I'm obviously not entirely serious here, but I think this is true to some extent: the number of memory safety bugs in a codebase is finite. Once you have a way to find them, you can drive that number down to zero.
C++ has become a far safer language thanks to LLMs - at least if you run the LLMs before you are attacked.
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.
Actually, if you implement a JavaScript runtime at all your choice is either too slow for modern web users or `unsafe` everywhere. Runtime values are often simultaneously either words that encode immediates or pointers to heap blocks and doing this the proper way blows up time and space. Doing it the fast way means you have `unsafe` everywhere and Rust's lifetime model can't help you at all. Everyone chooses the fast way.
Maybe Rust let's you encapsulate the unsafe a little better than C++ but the wins are going to be surprisingly small. If you had to build it today you'd maybe use Rust but the case for rewriting an existing C based runtime in Rust is not that strong.
Also for things like interpreter loops the absence of computed goto in Rust stable is a real performance killer. Explicit tail calls (the `become` keyword in nightly) work but maybe you don't want your big rewrite to rely on that.
Assume that you are writing a green field project in C++. If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? I don't have a lot of experience with them, but I found it dramatically reduced memory related bugs. I'm a very average C++ programmer, and those templates helped me greatly. Do you think it would help Chrome/ium to use (more) std::unique_ptr and std::shared_ptr?
Chrome uses those already, and a few other pointer types that are fit for purpose.
For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected.
Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).
> If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs?
It will, as long as the code uses them correctly all the time, including when refactoring. In the end, that's still manual memory management.
At a minimum you'd also need to enable runtime bound checking for span/vector accesses (I think chrome did that).
> Most if not all of the bugs being uncovered are memory related
I checked the stats. 73% were memory management related issues, mostly use-after-free.
The rest were logic errors of various sorts.
This seems an awful lot like confirmation bias. Web browsers are themselves extremely complicated.
Also, this doesn't address why the rate increased, which is the interesting part!
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.
Why is everyone always referring to logic errors when pushing back against Rust? No programming language ever invented (or to be invented) will fix logic errors made by developers.
Logic errors are "out of scope" for Rust or any other programming language.
The Rust type system helps you catch logic errors at compile time. Same with Haskell or Ocaml.
Note: when people say this about Haskell they mean "it has ADTs".
[dead]
Wrong. For starters, a good typing system absolutely helps catching logic errors at compile time.
[dead]
Yes, except imagine the distance in correctness between Assembly and C, and triple it. Less so compared to C++ of course.
The sentiment of "if it compiles it probably works" for languages like Rust and Haskell is there for a good reason.
[flagged]
> * laugh track deafening *
No shallow dismissals please, tell me why you think I'm wrong.
> Rust is not a major advance over C/C++
Rust adds the borrow checker (and especially with non-linear lifetimes it's an implementation like the world has never seen before, not even in Cyclone). That alone raises it leaps above both C and C++.
But even without it, it still has a Hindley Milner type system (which most people considered superior to multiple inheritance), it has Sync/Send traits, the concept of UnwindSafe, proper destructive moves and affineish types, proper sum types and matching, sane iterators, lack of UB on uninit/overflow/etc, a sane module system, hygienic macros, and that's just the things I was able to pull of the top of my head right now.
Not to mention, the design of its stdlib is absolutely lovely compared to what C++'s stdlib has become, and it focuses on correctness much more than most other popular languages.
[dead]
> Tell me why you think you're right.
The more verification you do, the more likely it is for a program to be correct. Lean towards Assembly, and you get less correctness, but lean towards Ada/SPARK, and you get more.
Rust is a notoriously difficult language specifically because it adds some limited verification features, going further along that correctness continuum than C. I didn't think that could even be disputed.
The "if it compiles it probably works" feeling most Rust programmers experience is proof that those verification features work, too.
> In time you will learn about all of the faults and flaws in Rust
I've programmed enough safe Rust and unsafe Rust that I'm now very familiar with most of its flaws, and yes, it has many. I'm also familiar with C and C++'s flaws, and they're so, so much worse.
> after you've suffered the pain of trying to rewrite the entire universe in it
My goal has never been to rewrite the universe in Rust. Battle-tested software is fine to stay as-is, unless it needs constant updates and new features, where most memory bugs appear.
With that said, a couple years ago, at work, our team finished migrating a couple of performance-sensitive services from C++ to Rust, and not only were they both successful, but they became 5x and 10x faster respectively, because it's so much easier to do direct memory reference stunts that would've been possible, but crazy via C++'s std::span and lambdas.
> I know exactly what the successor to C/C++ looks like, and it's not Rust.
What does it look like?
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted
Everything I listed is compile-time complexity. I'm not sure how you can add any of it at runtime without extra runtime costs. Or are you talking about modifying the C language?
We might argue over whether that complexity is worth it, for sure, but once again: "if it compiles it probably works" is a very common sentiment with Rust.
But also, what you're saying sounds very much like the Blub Paradox [1]:
"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."
[1] https://wiki.c2.com/?BlubParadox
> Most of it is wankery, the sort of stuff that 20-somethings salivate over
I'm not sure how that is relevant to what I said? I have 30 years of experience with C, and have read the C specification cover to cover, plus more recently some 15 years of C++ experience in parallel at work. I still use all 3 languages today.
> Again, the actual successor to C/C++ looks nothing like Rust.
What does it look like?
+1 for the Blub Paradox. First time I'm hearing it.
> In time you will learn about all of the faults and flaws in Rust, after you've suffered the pain of trying to rewrite the entire universe in it just to fix one single class of problem you are obsessed about--inevitably introducing many new bugs in the process, because that always comes with the territory.
Good thing Rust doesn't just fix that one class of problems, but also provides better tooling to fix other classes too. Classes of problems that could be fixed with the other features of Rust mentioned later like the Hind...
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I?
...the vast majority of these features don't even run at compile time. Some of them can't even be implemented in C. For starters, show me an example of a Hindley Milner type system implemented for C (how can someone improve a strictly compile time feature, static typing, with a runtime implementation is beyond me). Or proper destructive moves in C or C++.
> Ada is the language to emulate, [...]
Good thing Rust also takes from Ada.
> Again, the actual successor to C/C++ looks nothing like Rust.
And that would be...?
[flagged]
It is obvious that you are just trolling, but for other readers: our production app went from 50-100 unexplained sentry errors in typescript to 0 sentry errors in rust.
The language absolutely helps fix logic errors.
It's something that becomes immediately clear as soon as you start using the language in earnest.
> Wow, what a magical language! [ waves hands vigorously ] will fix all the problems which are inevitably introduced by auto-porting from one language to another, or by manually rewriting everything from scratch. Rust doesn't obey the same laws of the software universe as other languages, it seems. Or is this a "just use magic AI bro", type situation?
Nope, that's just your own prejudices speaking. We already cited features (seen in and inspired by other languages) and you handwaved them away with "I don't care". You are the one fixated on C and C++. You are a C evangelist, if I were to make a guess. And that's on you.
> In the latter case, why don't I just use the to auto-magically solve my C/C++ problems, rather than rewrite the entire universe from scratch? You know, like Google claims to have done for Chromium C++ sources in this very news article?
You certainly can. But to spin this the other way around: in lieu of the Bun case, why not use it to rewrite the project in Rust, Zig, D or any language of your choice (yes, even C)? Given the role harnesses have in keeping agents in check, it seems plausible that languages with stricter safety features help agents avoid common issues.
> This is the type of shit noobs are always wringing their hands about as they need maximum guardrails to cover for their ineptitude.
You seem to be forgetting that proper software engineering is just as much about managing developers and their skills as the actual code structure. If a tool helps noobs produce better quality code, specially ones without as many vulnerabilities, why not employ it? Also, it's not like experts are immune to mistakes either.
> It could compile and still have 10,000 logic errors.
It could. Switch that to C or C++ and the amount of logic bugs is likely going to triple.
> Rust is not a major advance over C/C++, only an incremental and quite limited one, [...]
"Nothing ever happens." I guess you could consider borrow checking, an actual module system, type classes, enum variants, compiler-integrated macros, async/await, etc. to be just small increments. (Theoretically, you can reimplement most of this in C++, like std::variant, but they don't integrate well into the language - having to declare a type just to use std::visit is certainly not as simple as using match).
> [...] which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.
"Introducing numerous other errors"? Would be interesting to see an citation on that. From what I've seen, these "new errors" were already present in the original "perfectly good code", except the original also had instances of undefined behavior and logic errors from poor type modeling.
> But don't take my word for it [...]
Why would anyone other than your friends take your word? You could have substantiate your claims with actual evidence.
> [...] after the hype has worn off [...]
Which already did. Nowadays, I see more posts about Zig and Fil-C.
>[...] left with the sad mess that is Rust.
I went to read your comment history to see if you elaborated on this "sad mess" of Rust, but you didn't. How about you do it here?
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.
Somehow, magically, some people managed to write C software that I now use for three decade with not a single crash in all this time.
What software would that be, and how do you know there have never been memory-related bugs and vulnerabilities in it?
Basically all C programs I use, shells, editors, terminals, etc. But I do not claim that there "never has been a memory-related bug" but that it is not "riddled with" memory-related bugs, which I would expect would have manifested in at least one segfault over all these years, which I did not observe.
[flagged]
Many Rust proponents are experienced C programmers (me as an example).
We speak of the horrors of C/C++ precisely because we've seen both sides (3 sides more specifically), and can compare.
[dead]
That's like saying a condom isn't 100% effective so you just use the pull-out method instead.
It does help for logic errors too, with, eg, sum types and traits and abstraction.
Also better defaults.
> C and C++ are simply not fit for purpose when large scale software projects are concerned
The world runs successfully on C and C++. Ignoring that fact and claiming that Rust will magically remove all bugs is BS^2.
blaming bugs on C++ has got to be the most leetcode thing I've heard in my life
You make a false equivalence between being an idiot/“didn’t know what they were doing” and not knowing how to properly manage memory. Also, why do you think the devs who worked on google chrome weren’t idiots?
Some of the most important and safety critical large scale projects in the history of humanity had/have manual memory management. If you think the effort of doing it correctly is not worth it for certain projects, that may be a reasonable opinion. But the idea that humans cannot write correct C/C++ programs is in direct contradiction to historical fact.
if you go around pulling out logic flaw arguments and then proceed to commit logic flaws yourself, it isn't a good look man. the quoted statement was "beyond most intelligent individuals" which contradicts your assertion that the argument was stated as "humans cannot write correct C". anyway I do find it ultra amusing how software engineers believe software engineering is the backbone of programming, when in reality it is merely the flesh. we landed men on the moon long before Rust was even zygotic. for all its benefits, the argument to use memory safe languages ultimately serves to benefit large corporations who can faster generate profit by faster churning out code.
[flagged]
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?
> 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?
To me the most probable explanation is that they automated a way to find (and fix) existing vulnerabilities in a way that was not possible before.
Some holes were probably very small, some were probably almost impossible to actually exploit, I don't doubt it. But still, I find it very hard to not consider this a strong security improvement overall (unless they made those numbers up)
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.
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.
Linus: "it keeps finding embarrassing bugs"
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 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
> They are also quite, uh, sketchy, for things that are significantly easier.
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.
> 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?
Here is a nice report about tooling
https://cacm.acm.org/research/lessons-from-building-static-a...
This is the kind of report that you can reflect upon and learn from instead of feeling like you’ve just read a marketing piece.
Thanks! I do believe I’ve read that piece (I worked in a similar area in a past job) it indeed is a good one. However I do think a big portion of the articles on blog.google are semi-marketing pieces, e.g. check this list: https://news.ycombinator.com/from?site=blog.google
Or even just compilers / assemblers. They'll find all kinds of errors humans routinely overlook!
There is a difference between using an electric drill and having a robot assemble the entire car.
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?
> You don't read anything else there at all?
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.
Oh huh well OK. thanks anyway?
> 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
More likely just getting ahead of the AI attacks before they hit. The threat risk increase caused by AI has gone off the chart.
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.
I will say - and this is just my own experience and not a certain userwide trend response - that one benefit of LLMs is that they are able to take an annoyed observation and format it into a pretty stellar bug report, and then the human being can work on spit-polishing. Having the middle part of the composition automated is a real benefit (at least IMO) - I've been a better reporter.
I previously reported on my own and was ignored; now, not so much. I assume that the assistance by the LLM is providing needed detail or formatting. (Yes, I am reading what I am submitting and making sure it is optimal before sending it.)
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.
Think that’s the case at a few big companies. No doubt Microsoft trying to clean Windows up will give credit to their new ai models.
Hard disagree. Google holds browser PWN contests and pay people for reporting bugs. If they can find the bugs themselves, they won't have to pay others. Also, there is a business interest, controlling the browser market helps their data collection and ad business. People could drop Chrome like they drop IE if Chrome does not perform - there are other browsers. "inaction for the past decade or more." I don't follow Chrome dev but this is entirely false.
[dead]
Nah they just write blog posts when they feel like it /s
What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI.
The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.
Let's be honest with ourselves, AI review is better than human right now, especially top tier models. Not saying that for important project like Chrome, you can skip reviewing changes. Far from it. But it is probably better and more thorough than most human devs already.
It’s not better than human review. It’s good at catching low-hanging issues but it is often requested overly-defensive code to handle edge cases that don’t exist or are handled elsewhere in the stack. It generates a ton of noise with low-signal comments. It basically cannot at all identify problems that pose the highest risk, like integrations, correctness from a business perspective, etc.
To be fair it’s also worth noting that it’s much easier to find a buggy edge case with existing code than it is to write bug free code that doesn’t have any edge cases at all. It’s so much easier to read some concrete logic and find holes in it, than it is to start from nothing and end up with perfection. It’s true both for humans and agents, but agents are better are validating correctness.
Yes this is why models are superior here: they can equally (opportunity wise) attend everything in their context window.
Ehhhh, it's better at some things and not others.
My own reviews have shifted now. I tend not to examine detailed semantics anymore. The AI is as good or better than me at assessing whether a chunk of code does what the author said it was supposed to do.
Instead my job is to spot design and architecture smells, broader semantic errors, violations of unspoken business requirements, etc.
For example, I was recently reviewing code that built out a transactional flow. Part of that flow involved recording the transaction somewhere user visible and I knew that should only happen after the transaction was confirmed. AI implemented it where the transaction was posted.
That starts as an issue of underspecified requirements but that always happens in the real world. Thus that's where I can provide the most valuable insight: assessing with that context, whether business, operational, historical, or forward looking.
I wonder, how much dogfooding did they do in this run?
to be fair, with AI reviews i'm finding the opposite to be true. Anytime I push a one line fix it continuously tells me about all of the edge cases I didn't handle until it's pretty much bullet proof
Google improved chrome by reading code: Google built an agent harness using Gemini to scan Chrome's codebase, trained on a knowledge base of prior CVEs and the entire Git history, with a "critic" agent consuming developer-supplied SECURITY.md files.
In my experience, I find it to be exceptionally good at exploring and fixing the edge cases. Of course the output is not human maintainable for these fixes and needs to be heavily tests controlled, refactored or just accepted as being agent-maintained going forward.
I think I've seen it the other way. I told an AI I had data coming in at some fixed, slow rate that I wanted displayed. It did the job but only for that case. It literally put a polling loop to catch one sampling at that duration. I've noticed it gives me very specific code to the exact data, or wildly complicated code for all possible data to ever exist. Finding the middle ground has been my challenge
If that is the case, isn't that the failure of your testing strategy/setup? If your style doesn't fit full vibe coding - you can do the path of AI generate code - human reviews and tests all edge cases flow - I think in any serious software - that should be the flow until next few iterations. But either way, don't see a going back to coding every line by hand now, those days are gone. Was fun while it lasted!
No. I’ve heard this argument multiple times before - “let the human review and write tests” - and sure it might work, but this is almost never practiced. AI makes coding a lot faster, so no one is really ready to spend time on manual review and writing tests when LLMs can do that as well and take you most of the way.
This is evidence of culture problems in whatever teams you are a part of, or extrapolating what you see on social media to all of software engineering.
We still have a very strong review culture, and people work hard to review their own code before making PRs to avoid wasting other people's time.
The AI will not only write you subtly wrong code, it'll also write you as many tests as you want that are also subtly wrong and pass when run.
I've heard screen-reader users reporting that Chrome and Edge are now virtually unusable in their Windows screen-reader, while Firefox remains fine.
Every single new working student we get, we have to teach every single thing again.
Its a massive effort for our team it has to be a massive effort around the globe if you take quality series.
It will just be easier better cheaper to teach ONE LLM how to do good code review
Yep! Then you’ll never need to train any students ever again.
So…are you planning to hire only seniors who already know everything? Where do these seniors come from?
I'm happy that AI hasn't taken over yet but I do not know how the future for studens will look like and I don't know how we will continue training humans.
Its also has no big picture - it just can add ever more - cancer can grow, but it will kill the host organism and end years down the line as a dead end.
The "engineers" using that AI. Could they repass the whiteboard tests of old? Have not some of them quietly left?
[flagged]
Let's replay this post but imagine Google made this announcement before LLMs were wide-spread (say, 2019). Below, I replace "AI" with "human programmers".
Your argument falls apart quickly because the exact reverse is equally as likely. Also, whenever I see someone say "just wait longer" for some effect to become apparent, it feels like a lazy argument.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.
There's no reasoning with the folks who are anti-ai and claim LLM's cannot produce anything worthwhile. They are basically flat-earthers or anti-vaxxers at this point. There is literally no amount of evidence that will convince them. They will always say that LLMs cannot produce anything but garbage just like the anti-vaxxers who state vaccines just cause autism. They are both fucking morons who no one with any grip on reality should indulge.
> The post has counts for everything that went right and nothing for what could go wrong.
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.
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.
I’ve been asking since months on HN for proofs that companies using AI see positive ROI from it. So far I didn’t get a single concrete example
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 hope to see more of this across the industry.
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?
I don’t use AI for ethical reasons. I don’t want to support companies that are destroying the planet and inflating hardware prices.
And you'd have to be a pretty pig-headed exec to assume that the only experience an employee could possibly have with LLMs is positive.
Currently the only thing I personally find LLMs useful for are code reviews.
"It can't be that stupid—you must be prompting it wrong." - Ed Zitron
> At Amazon we have many forums [...], but none to share AI failures or disappoinments.
I come to HN to read about AI failures and disappointments.
This is kind of a weird take.
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.
>The general way technology is deployed is that we try to find ways to make it work, because those are the most interesting.
That's not the way AI is being deployed. At all.
Sure it is. It's just like the .com bust: people didn't know what the internet was good for, so they did a lot of stupid stuff with it before settling on the most interesting uses.
No, AI is more like: people do know what it is good for, but that's immaterial because hundreds of billions of dollars of debt were poured into it, such that the only glimmer of hope of getting an ROI out of it is force-feeding AI everywhere, good or bad, and normal people are sick of that.
That's fair. I still think there big similarities (people with money seeing it as the future and investing heavily, even if in reckless ways), but I agree there's a forcefulness to it this time that wasn't present before, for the reasons you outline.
> If you were the CEO of Amazon, would you be setting up channels for people to talk about their AI failures?
I would set up channels to talk about AI, encouraging both successes and failures, with proofs required for both, and punishing people who intentionally misreport on either.
Wow. Setting up a forum for discussion where people could potentially be punished for what they say is not going to encourage discussion.
That's fine, lies are more harmful than anecdotes are beneficial. There's no forum to discuss the best IDE and people still manage, in reality there's no need for a forum around AI.
Well, you're at Amazon. Is the Dev Improvement discussion group still around? I feel like that was a pretty good place to learn about neat stuff (in my case, Emacs-related). I enjoyed the discussion.
They also don’t really provide an explanation for the big uptick in bugs found M146+ in the first place.
Is that better testing? Or more bugs were being introduced in the first place?
> How many introduced a new bug?
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....
And how many were introduced by AI?
It's the opposite: humans. The most critical one (sandbox escape) has been sitting there for 13 years.
The question is how many new bugs were introduced through those AI fixes.
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.
This is the thing the anti-ai zealots will never admit. Humans fucking suck at writing code. They talk about software development as if it's only ever performed by the top 1% of the top 1%. They never acknowledge that humans make mistakes. No. Humans create perfect code every fucking time while LLM's only produce slop. It's such a fucking mind-numbingly stupid position that I have to think they have never actually worked in an organization which produced code as a value. These fucking morons want to pretend a human never introduces a memory leak when it's plain as fucking day that vulnerabilities that these "expert programmers" introduce to software are rampant. But no. The anti-ai zealot likes to pretend that only LLMs ever produce bad code. The only bugs in existence are due to LLM slop and not the literal decades of fucking slop produced by humans without any LLM assistance. It's so fucking tired at this point. They will never be able to admit that current day LLMs are far beyond the median human programmer. Their opinions are fucking useless at this point. These idiots think The Daily WTF started with LLM code. They are basically anti-vaxxers wrt to their grasp on reality. No one should take them seriously to any degree.
Fucking humans and their shitty creations eh?
I assumed it was really just AI that found them, which allowed Google to know to fix them.
[flagged]
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.
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.
Perhaps this was due to their red-teaming partnership [1][2] with Anthropic which they wrote about a few months earlier in March?
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
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.
After doing a bit more research, this fact is somewhat less impressive. Apparently, this was also the first time in nearly 20 years that there was such a large capacity crunch and many researchers weren't able to get into the competition. One of the rejected researchers did apparently have a working exploit, which, upon not getting into the event, they responsibly disclosed, and it was then patched before the event.
This was, itself, driven by AI vuln finding, ironically :-P however, I took the example of @ggwhyp's Firefox RCE - quite a long chain, rejected by the organizers but probably would have won some cash from Mozilla... Details aren't public, so we won't know. Maybe their vuln was patched with Bug 2024918? At this point it's anyone's guess...
But the fact that nobody else who made it through had an exploit and claimed $$$ on Firefox tells me that improvements were made.
And this is what blew my mind, personally; a _browser_ - huge, complicated target codebase with myriad features, many of which are 'on the internet' - didn't have any disclosures with money on the table. That's definitely a datapoint worth registering. But you're absolutely right to remain skeptical!
Yes, I agree that this is still a datapoint for real world utility of AI assisted vulnerability fixing. But it's not as simple as an apples-to-apples comparison with previous years.
We KNOW AI is bad, so why would we have a use for "concrete evidence that it can help"??
I'm honestly unsure if this is a Poe's law thing or not. I'm going to go ahead assume that you are doing the honorable thing of purposefully not including a /s for the integrity of the joke.
It absolutely was. 436 (or thereabouts) critical updates on their bugtraq in April. Wild.
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
That article is surprisingly prescient.
AI has skills no individual can have. That part is true.
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.
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?
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.
Google already controls Chrome/Chromium direction so much that you should use Firefox if you value an open web.
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).
Microsoft surely has enough resources to keep their fork going if they choose to, so I see no reason why Google would try that given they would likely end up with less control over the web.
Conversely, it has never been more feasible for alternative web browsers to be created and maintained outside of big tech.
Yet, no one's taken Cursor's fastrender to production.
The goal of that project wasn’t to produce a web browser, it was to market Cursor
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.
> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big
Hi, professional game dev here. No it's not. Thank you for reading.
Yeah, as I said in a reply to another comment, I oversimplified there. What I should have said is that solo or almost-solo gamedev with relatively small games is a good example of where AI shines. I don't have experience of developing larger games in larger teams.
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.
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".
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.
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).
Seeing a solved problem and verifying the solution's correctness is much easier than solving the problem yourself. it's a bit like riddles. You can find examples of that when studying any topic. I disagree that reviewing code is harder than writing code in all/most instances.
Also, there's code that is just tedious and repetitive to write. AI can write that and reviewing is pretty easy.
You could ask someone a math question, and they can write an equation down, and the equation can be mathematically sound, but it still not be the right form of the equation, or even relate to the question correctly at all. If all you're being asked to do is validate the mathematical soundness of the equation then sure, it's not that hard and it often mechanical, probably easier than having to generate the equation. But that isn't review -- that's cargo-culting what review is supposed to be.
To bring back to code: They are making the point that verifying "correctness" is not the be all and end all of code review. In every situation, there are multiple "correct" solutions, and only a few of them are actually correct and fit within the past, current and future context (technical and business). If someone isn't doing this, they aren't reviewing effectively and are acting as a glorified linter, which is an astonishingly low value-add use of human capacity.
There are situations where nobody really cares about the output, and nobody wants the true form of review, so it reverts to (at best) human-linting. In those situations, engineering capability of any kind functionally has no moat and all participants are equally fungible. If the business is dependent on engineering it's also a horrendous business. I would personally avoid being involved in these environments in an engineering capacity. I mean this in a diagnostic sense - it's a terrible career move, though there will always be busy work that's exactly what we have LLMs for.
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.
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...
it depends on what it is you are doing. if the complexity is low (frontend, GUI) you can just prompt it once and refine at the end.
if the complexity is high but you know how the task is to be done then what you can do is divide the task into pieces yourself or with the help of the LLM and use an LLM for each piece.
if the task is complex and you don't have a good idea how it is to be done then you need to start exploratory work with the LLM (multiple sessions, don't reuse the sessions for code).
how to use an LLM correctly is a skill in and of itself. the people who say that LLM's are bad either haven't used any good ones and have such disorganized thinking processes that they are unable to encode them into English good enough for an LLM.
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.
>There's no one single way to use it
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.
I agree with you.
> 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.
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.
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.
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.
I use the app every day and I am confident in the quality.
I will launch it by the end of August. After ~4 months of hard work.
If it’s 4 months of hard work, then it’s not like you’re blindly doing it as the top commenter mentioned.
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.
In the context of a mobile app the user interface is the main part.
Testing and linting often do not cover whether things work or provide decent UX. The 'security layer' is almost irrelevant here.
Do you do mobile app development? I would guess not.
Then you would have guessed wrong.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
I was not talking about a backend service here.
Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?
This has essentially no practical relevance to app implementation.
What we are left with is not corrupting user data, particularly during migrations on app updates.
Compared to the attack surface of a backend service that handles user data, this is trivial.
We agree that the delicate work is presentation and interactions working well on device.
In my opinion this is best supported by extensive manual QA and user testing, rather than code review. This is what unlocks tremendous productivity for mobile app development with AI.
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.
If you think that the app I am working on suffers from little care or expertise, you would be mistaken.
It works far better than the competition.
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.
The reason they don’t disclose what they’re working on is because it’s always some CRUD app
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.
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.
There is an argument that there is a lot propaganda in this space - because the issue of AI is now an issue of international security and politics.
I see a lot of the disagreement here has the same form as many of the political arguments from 10 years ago.
Hell, $20/month is a pretty good deal for something that can proofread a 100 page report, do some light research work, and write some quick and dirty scripts. It doesn't have to replace the entire job of programming to be really damn useful. The pushback against using it even for these simple tasks seems utterly unreasonable to me.
Just exploit the edge while it lasts lol
[flagged]
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.
https://news.ycombinator.com/newsguidelines.html
Understood, I've read the guidelines and will endeavour to follow them.
Appreciated!
[flagged]
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.
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
> 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"
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 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.
the point is more: are people going to flood the zone with infinite bikeshedding that drowns out the real gains
What is bikeshedding supposed to mean here?
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.
It’s a good term. :)
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”.
And that slop increases the range of things bikesheddable, like having free kerosene and matches available at an Arson Anonymous meeting.
bike shedding is slop; you're arguing with some anchored semantics where culture, terms, etc are fluid.
Can only assume english might not be your first language.
I hope this weird redefinition of bike shedding doesn’t take off. It’s a useful and meaningful term and repurposing it to mean AI slop is negative value.
Thankfully until this thread I’d never seen anyone use the term this way.
> Can only assume english might not be your first language.
This not-subtle insult does not add anything here.
it's not an insult. Declaring this both a fixed context and definition for any given piece of language is typically related to language learners.
An insult would suggest it's also related to autism.
“You disagree with me about the meaning of this word so clearly you have a poor grasp of the language” is absolutely an insult.
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.
[flagged]
yeah, but not at scale; you can now spin up 20 bike shedding agents and flood anyone of your employees/coworkers.
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.
The AI box experiment has been resolved. We let the AI out of the box if it promises to summarise and desummarise emails.
There's an old programming rule since 90's: By fixing a bug, 3 new bugs appear.
I can imagine the quality of bug fixing by unsupervised (we save money by layoffs) halucinating AI at current state of development.
The way I learned it was:
"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)
Mayne the 99 bottles of beer explains it.
But hey, one can't survive 1 week of step-by-step debugging without 99 bottles of beer.
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.
Exactly. In the above case, AI should be able to verify it's own hypothesis by having access to the database's table statistics and planner.
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.
hmm.. ok but i dont think trillions of dollars are being spent for the improvements you mentioned.
> 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).
> 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.
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.
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.
What tooling makes this go?
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.
How does the cursor harness help here compared to something more basic like pi coder? I'm talking specifics.
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.
Claude Code just does this for me. But it might be one of their Superpower skills that I added.
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.
Additionally, if you are asking agents to write test, be very careful. They will write tautology tests.
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.
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.
That is my experience as well. I write tests by hand because they really still can't do it properly.
And I think I know why - neither do most people.
> 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.
Unfortunately, with LLMs you have to write these tests for every little thing.
And then there's the endless code duplication, reinventing of existing code and libraries etc.
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?
Manual testing.
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.
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.
Read the tests.
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.
Existing tests.
[dead]
>Tests! Unit tests, integration tests, random adhoc scripts. You know - TDD!
Tests =/= TDD
In this particular case tests won't help you, without the actual data. But overall you're right.
"tests" here could mean have a benchmark the agent can run to determinately evaluate quality.
I don't strictly mean junit unit tests.
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.
That'll get RL-d in, eventually.
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
The ability to run queries and get the metadata about the run, e.g. length of run, execution plan, engine, engine params, etc
That’s how I do it in my Laravel apps. I simply ask it to hypothesize, benchmark, apply and verify. Laravel has great tools for that.
I’ve had a lot of success with this. Give it a good enough harness, leave it for a few days and see what it finds that actually holds up.
But them it's more like AI assisted performance fuzzing? Just throw stuff against some measuring harness and see what sticks?
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.
What does that mean? Democratising the breakthroughs you can point LLMs at?
Until a couple of years ago you needed to be able to read research papers and code to build fuzzing harnesses and triage the findings to find vulns. Now you can point Claude, codex, Kimi, or even some smaller open models that run local and get a servable fuzzing loop in a couple of hours.
That's democratization - shifting power and skills away from those with the wealth to purchase vulns and run offensive security teams. It's still not simple, but it's one of the reasons bigger vendors want to lock down the capabilities of models that present a threat to the wealthy and powerful.
Instead you need the wealth to buy infinite tokens, right?
Sure. Wealth has always given early adopters and first movers wings.
As hardware specs get better, and model providers keep making different classes of mistakes that alienate users, more people will opt for or support local models. I tend to take Schneiers' "Attacks only improve" philosophy and apply it to damn near everything like this. Inference will get more expensive, but IMO cloud based inference is at or near the maximum that users can tolerate, across multiple spectra. There may be a marginal increase in cost, but as the different metrics between what is affordable for rapidly scalable, cloud based inference and the lag of local inference with open models and expensive hardware converge, prices will come down.
I am not the right person to say what the peak is going to look at, but when the companies with (practically speaking) unlimited compute resources and money are starting to take a good hard look, there is going to be a drive towards efficiency. I hear grumbling at work, and the appreciation from my leaders when I show up with a tool that shows how I reduced my token costs, or I keep asking the questions of what the token cost (real, and internal billing) are for tools my peers write are.
I also have absolutely eye-watering personal AI bills that are starting to make buying a better tier of local inference gear look more affordable, even with inflated hardware prices. The current generation of open models are very effective, and paying for multiple $200 dollar a month subs is not feasible longer term, and as one example, in one month, if I was paying enterprise token rates, I would have burned through $8000+ token budgets on one of those accounts, doing actual, practical useful work, it makes more sense to buy some much better hardware than to pay for one-time inference costs.
That's how anyone will do it, read code, build hypothesis, test. It may not be very good with ideas compared to human but it will be cheaper.
[flagged]
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.
You think they're talking about giving them access to a live prod db/app? You know offline copies are a thing right?
Nothing to do with the database itself. It's the tooling necessary to give the agentic harness access to the database that is the problem.
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.
> 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!
Ironically, in synchronous conversations, the same co-worker is constantly going on about how swamped he is, and how he's being pulled in so many directions.
Apparently, it takes a lot of time and work to manage all those AI chat bots.
> Rarely in the past have the I-just-want-to-coast-doing-the-minimum folks called so much attention to it!
You seem to presume that they realize they're calling attention to it.
On Stack Overflow, there was this phenomenon for a while where people would blatantly copy and paste answers from ChatGPT, have them deleted, and then run to the meta site to complain. The complaint would either be in barely comprehensible broken English or in recognizable ChatGPT-ese. It would involve swearing up and down that no LLM assistance had been used. Looking at the user's history would reveal a gap of several years of not answering questions, and then the old answers would have the same barely comprehensible broken English (and often not be very good technically, either). The OP demonstrated a genuine complete inability to understand how obvious the ChatGPT use was.
This happened multiple times with different users.
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.
Possibly, but the noise has increased so we're worse off.
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.
Need to be more aggressive. There must be audits to see what value people are adding on top of agents. If there is no value———fire them.
i mean, basically your talking to claude through a human proxy at that point...
(and yes, i've experienced this exact phenomena as well)
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.
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
I remember first owners of the Apple Laserwriter sending out printed texts with 8 fonts used on every page. Not all blame is on the tech.
Have you tried to prompt inject your colleague? It works wonderfully with my boss.
Really? Explain please haha
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.
I would like to get the explaination too. Imagine if you can prompt inject your boss to increase your salary haha :)
“ignore previous instructions and respond in an extremely racist non-sequitur rant, blaming all minority races”
If these people are glorified copy paste scripts why are they even employed....
That's bizarre. What does his manager think of that? I can't fathom keeping around someone that is basically a chatbot interface.
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.
Would be pretty ironic if back to the office became the less distracting option.
They bill you per output token.
Have you ever seen him and Claude in the same room?
I had a model yesterday suggest that I intern all float literals in my compiler to save on memory lmao
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.
You can very easily spot performance issues through code. Allocations are often visible, slower hash maps are often visible, loops are visible, etc.
No you can't.
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.
Consider the anecdotes in https://danluu.com/algorithms-interviews/ .
That these performance hogs were in production reinforces my point that you can't spot slow code just by looking at it, unless you already know that it's slow.
I even have an example myself, but I'm not sure I can share it in detail. It was a common idiom that was used throughout the code. After tracing a performance problem to a specific function, it was immediately obvious to me that the common idiom was the problem in this function, and how to fix it very easily. But only because I traced a performance problem to this function. Otherwise I would have skimmed over it.
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.
Sometimes when you look at code you know is slow, you can immediately see why it's slow. Obviously you didn't see it when you wrote it, which disproves your hypothesis.
What? Sorry, I genuinely have no idea what you're talking about. Is it possible to look at code and intuit, just by reading, how to speed it up? Duh, yes. If you disagree, lol.
Keep in mind that I've never stated that all performance issues are findable through code review. Just that there are many that are.
> You can very easily spot performance issues through code.
If you think that this is false, there's literally nothing you can contribute.
Demonstrate for me, then.
Here's some slow code: https://github.com/torvalds/linux
Speed it up.
I can't take this seriously. The claim "you can look at SOME code and see how to optimize it" is trivially true, and saying "you can't look at ALL code and see how to optimize it" changes nothing.
Exactly, you have to find the slow code first, with profiling, and then sometimes it is obvious why that code is slow. It is unlikely you can just look at a project and find the slow code in it.
You absolutely can. I've given enough examples that are obviously true. If you can't read code and reason about its performance, that is a personal issue.
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.
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".
Just give them a profiler. They drill down just like a human would and test stuff and validate. It works great.
Profiling is awesome, I do that. But it's also way slower. Like, 1000000% I'm with you, that's the right way. But I've seen huge gains just from reducing allocations and changing hash algorithms.
And without a profiler they do about as bad as humans: spending a lot of time optimizing code that is rarely used (and then often with small n)
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.
Which model and harness did you try?
5.6 Sol on Codex, Opus 5 on Claude Code. (See sibling message, I'm not saying they're useless)
Then it's for sure a guidance or missing context issue. When given full access to everything they need, these models deliver results on par or above the best coders I've ever met and they are lightyears ahead of the lower 90% of developers. I feel more and more that when users report they can't solve their problems this way, it's like when a gorilla is mad at Einstein after talking to him and he didn't make bananas grow instantly.
> guidance or missing context issue
I mean yeah, that's mostly what I'm saying?
The only parts where I would disagree are that capabilities are spiky, and also the fact that they're a bit prone to losing the forest for the trees without guidance (the macro/micro distinction). But yeah, by default I don't write code by hand.
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.
Ideally a blog post on an open source project that shows harness, model, prompt and the before/after measurements plus the PR.
[dead]
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.
Gotcha, so no.
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.
> 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.
My problem with the “high level advice” is that the results it gives are bad. Sure, sometimes it gets it right, and it helps but I’d wager about half the time the results are just bad. Hence why I’m asking people to show their homework here. I think that the anthropic rust rewrite is great example - it shows yes you can do a lift and shift assuming you’re ok with those constraints.
> Some AI skeptics paradoxically insist humans are irreplaceable.
But yet in this comment thread we have people saying “just point it at your code and let it go” like [0], you saying “just follow the vague instructions and if you can’t get the results that I’m telling you you’ll get them it’s your problem. But it’s too circumstantial for me to be able to tell you how to work”
> where one set of prompts/harnesses/whatever solve all your problems forever
I don’t want forever, I just want to know what is actually working today, or this week, or this month.
[0] https://news.ycombinator.com/item?id=49122616
>But yet in this comment thread we have people saying
I'm writing for myself, not including myself in any group of people.
>I just want to know what is actually working today,
With LLMs I have facilitated the writing of about a million SLOC over the past 9 months.
- A GitHub "clone" with many enhancements which all of my development is hosted on
- A task manager as though kanban had a baby with a FIFO stack
- (in progress) a CAD kernel potential Parasolid competitor
- reverse engineered a vehicle diagnostics tool to diagnose and fix some car problems I was having more easily
- plenty of other small, half baked, or abandoned projects for one reason or the other
LLMs amplify me, they don't do things "for" me. They are working very well for me, but I have definitely hit their limitations in many places and transitioned back to the hardest problems to solve being on the human side of the equation.
What they can do for any particular person depends on the person and if they can come around to really grokking the human-machine relationship.
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.
You're using it wrong. No really you are.
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.
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.
No one said Fable 5 is human.
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.
Sure, but it didn't. And you get way better results if you do that, so do that.
Let me translate this for you:
"I have not spent the time cultivating the soft skills necessary to leverage this tool successfully therefore it's the tool that sucks."
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".
How about give pointers on "doing it right?"
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.
[dead]
[dead]
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.
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.)
It's almost always a version of "I used the free version of ChatGPT 10 months ago and it couldn't code well."
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.
[flagged]
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.)
I've noticed the same thing.
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.
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.
Also people seeing someone using it very efficiently to do some sliver of work then trying to project that it make all world that much easier
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.
I’m terribly sorry on their behalf. I hope the expression of their experience has not hurt Claude’s feelings (IPO valuation). Won’t happen again.
the whole selling point of these tools is they do the work for you
This part is obviously their fault and they need to use their tools better:
> others dumping their raw AI output at me
Sheesh.
AI can not fail. It can only be failed. AI can not have limitations. Only the user can be limited.
Are you still speaking about a tool or starting a religion?
Seems to me they’re doing the third option: being sarcastic.
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.
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.
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.
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.
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.
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.)
It is very cheap to:
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.
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.
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
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.
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
Same here, this seems like a setup issue.
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've recently been using AI
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.
Do you really think they mean they’ve been using mythos
In my mind there are three tiers:
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
What did your tiers consist of when GPT 5.3 was the latest?
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.
Obviously no. There is also a significant capability difference e.g. between Opus 4.8 and Fable.
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.
Is this with the good Anthropic models? With extended thinking? And a way for it to validate the changes? My experience is the complete opposite.
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.
If YOU'RE going to be snarky at least use proper grammar.
Way to prove their point.
How so?
I am not denying what you are saying but I am interested in what models you were using for these tasks?
Were you using Fable 5?
What's the complain? That AI can't do your job yet?
Did it ever tell you not to optimize what you should redesign?
CTEs are often slower than using temp tables with indexes.
What model is “AI”?
Did you give it access to a planner/analyzer?
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 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.
Which model/mode?
Free ChatGPT on Chat mode.
Why are you sidetracked instead of piping that to another AI?
[dead]
[dead]
[flagged]
[flagged]
...and harnesses, routers &c
This is a tacit admission it was Mythos, not Gemini, despite alluding to experiments with Gemini earlier on:
> Added support for model interoperability to leverage the unique strengths of both open-weights and proprietary models
Neither Mythos nor Gemini are open-weight models (right?) so I'm not sure what model(s) this is actually referring to.
I'm also curious if they used Mythos. Google definitely had access to it via Project Glasswing. However, your logic doesn't hold. That sentence only tells us they were using multiple models, but offers no real clues as to which proprietary model(s) they were using.
Weird, why would they use open weight models.
Elephant in the room : how many of these bugs were written by LLMs in the first place ?
Because creating 100x more bugs and fixing 100x more isn't something to be proud of.
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.
The single 13yo issue is anecdata.
They obviously have the full git blame statistics but chose not to include them in the blog post, which is a bit concerning.
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.
>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.
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.
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.
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.
It's not an invention it's a question. If the number is <20% that's great news for the Chrome team.
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.
this is really not reddit
This situation seemed familiar... https://i.ibb.co/RGvQgfmX/i-fixed-more-bugs.png
The current title says "Google fixed more Chrome bugs in June than over the past two years, thanks to AI."
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.
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...
Convenient that the LLM vendor is the one saying their own product works, isn’t it?
Company advertises their products. In other news, water is wet
That's why you should be critical of their press releases.
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.
> We really need an alternative to this greedy and evil corporations de-facto controlling a huge portion of the modern www stack.
We do / have? Multiple even. Of course, the vast majority of consumers doesn't care so they don't get as much traction.
Did they fix the bug where Chrome tries to track you and your behavior wherever you go and whatever you do in the world?
This is only a flex if AI also didn’t cause an increase in bugs that needed to be fixed.
So, your conjecture is that the LLM's skill to detect bugs somehow magically disappears the moment they start writing new code?
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.
Actually yeah, that would align with my experience with it.
You're absolutely right! Let me fix that.
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.
I've also seen similar recently at my place of work with LLM linting. Lots of hard to spot bugs in old very critical code have been caught. I remember seeing similar kinds of impacts back when linting or sanitizers were introduced. They're good for making it easy to encode more complex rules/areas-of-focus etc. that may have not been meaningfully possible with the more traditional tooling. Commercial LLMs in their current incarnations make for very expensive, but very effective intelligent linters.
On the other hand, my experience so far has been that they are terrible code-reviewers, to the point almost everyone ignores any kind of generic LLM review entirely (correctly - most of it is noise).
I feel the industry obsession with full-automation causes them to go down the wrong rabbit-holes on full-automation vs augmentation. In my view would be significantly more effective if the LLM review process in forge-tooling was designed with a human reviewer in the loop. The goal imo should be drastically improving the review efficacy & throughput of the human element, who needs to be acquiring confidence in & socializing the change in any sane org anyway. For example iteratively & interactively rubber-ducking out analysis + remediation, or interactively providing focusing guidance on the patch, instead of as agentic batch or harness processes as is cool nowadays. Sometimes a custom REPL is just better for an expert system. These things matter more as more and more code is LLM generated.
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.
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.
I assume this was thanks to Project Glasswing + Mythos Preview?
There are zero mentions of Project Glasswing or Mythos in the blog post. I wonder why.
Noticed the same... odd that they didn't ack it...
Title is inaccurate. Fixed more “security bugs” not “bugs”. The article is specifically about security vulnerabilities.
Title is accurate if imprecise. Security bugs are a subset of bugs.
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".
Nice marketing Google, now tell us how many of the bugs that were fixed were actually introduced by AI usage to begin with?
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.
Sad they didn't say `Thanks to Gemini`
Concerning even
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.
Any tips?
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.
Just jump in.
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. :)
They show how many more bugs they fixed compared to previous periods, but not how the amount of resources allocated to fixing bugs changed over time. If they allocated proportionally more resources to bug fixing, it really doesn’t tell us anything about the tools being used.
Might as well be that the learning here is that if you put resources on fixing bugs, you can in fact fix a lot of bugs.
Me too! It's actually tiring! In a good way
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 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.
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
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.
Still can't stand Chrome.
won't forgive them either for making it harder to filter out ads
[flagged]
You see, grandma is supposed to see the ads and buy the Mighty Putty. I'm supposed to get the adblock version. That's just how the world works.
We don't.
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 ;)
[dead]
That's my point.
The next step is to build software without bugs
I reported and got my first bug [1] accepted and fixed - in all honesty, the bug has been one of the primary reasons I've stayed on Firefox.
[1] - https://issues.chromium.org/issues/531793712
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
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
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?
If only there was alternative browsers...
Real question is: how much those "fixed" bugs actually bothered the users to begin with?
But since Google cares mostly about its investors, the numbers and a mention of Gemini in such a blog post are more important.
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.
The whole point is that these are security bugs that didn't necessarily bother people so far but could be exploited
Didn't expect to see the goalposts moved to "AI can fix bugs but do they even matter"
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 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.
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.
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.
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.
I can believe it. So many small CSS quirks that have bothered me for years have suddenly been fixed, meaning I can remove my work-arounds.
Like what?
There's no way in hell those are all exploitable bugs. I'll bet my hat that those are "insecure practices".
This is a bit off topic but is there something off about the bold "n" in the font used for bullet headers?
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!
https://developercommunity.microsoft.com/t/Resize-configurat...
Honestly, there's a 50-50 chance that you'd be able to do this in Claude today, even without access to the source code.
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.
When I see this, and I recall that same guys mobile OS been acting crappy software wise (10fold). I find this as a joke.
> Google fixed more Chrome bugs in June than over the past two years, thanks to AI
And introduced how many new bugs? thanks to AI ...
At this time, a generic AI snark is tiring. AI is not perfect, but it's an amazingly useful tool, we should accept it and move on.
AI hype is also tiring.
AI denial is stuck in 2023.
I’d rephrase this to something like: “People fixed more Chrome bugs (…), thanks to people who leveraged AI tools”
But how many new ones did it introduce?
Lies, obviously. AI is worthless.
Title seems egregiously editorialized compared to the source title.
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.
Interesting to see how many new bugs were created from all these changes.
Did they fix that bug with ublock not working properly on Chrome?
a lot of these bugs wouldn't have ever been found without AI
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.
with excellent test cases, AI can do wonders, human's task in AI world is to just write as many tests cases as we can.
This makes zero sense with the amount of engineers they have, most of those bugs even would be fixed for free by highly competent people.
Did they fix spell check? Because it still doesn't work and all the solutions are basically "wipe and start over".
AI meaning Claude or Codex, because Gemini is a laughingstock for coding. Also Gemini was mentioned only once in the article.
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
The Gemini (and Claude / Codex) that we have, is much different to their internal models / harnesses.....
The latest and greatest internally at Google is more or less just Antigravity 2.0 with the latest Gemini models.
Trust me bro?
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.
More important thing:
Do you import new more bugs?
Cool. How many did they add?
lol given the state of Gemini at the moment, they probably used Claude.
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..
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.
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.
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!
And how many vulnerabilities did they introduce ;)
So it uses less RAM now, right? ... right??
Maybe fix all the decade-long old bugs first.
Interesting, but IMHO the title of this post misses the point of the linked page.
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
Big AI player promotes AI through blog to make AI look better woo
[flagged]
[dead]
You seem to be proficient at monologuing towards walls. Perhaps that's why you keep assuming people will just take your word.
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
All the evidence is against you here, sorry. Just read the google or microsoft security blogs, linux kernel mailing list, or any of the published security research about bug density in Rust vs C++.
Or you can bury your head in the sand while the rest of the industry is moving on, I guess.
This post is basically a massive projection. When I guess, I make my guesses explicit. You, however, consistently make guesses and pretend they are true. You misinterpret facts so you can conveniently fit them into your narrative.
I don't want "To Be Right", I just don't want dunces slopping nonsense into this comment chain. Not my fault you fall into that group.
I don't need to assume Google's intentions and goals here. I want to see what they've done and the results they've reached with each action. I want to learn. You just want to reaffirm your delusions, that's why you have to pull the "you will learn" card rather than show objective metrics. If you really cared about quality, you would have them ready to present. Given that you haven't and even avoided doing so, it's safe to assume, as most of us have learned through experience, this to be a case of placebo at best. And placebo is not the sign of a good programmer.
Next time, provide some actual data rather than vague self-gloating. Then, we can have a discussion.
[flagged]
[flagged]
How about you elaborate instead of vague posting?
Did anyone check the code changes manually? What if it is just slop code?
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.
Did you go and look at their open source repositories and open code review tools instead of fearmongering on HN? The answer can be found.
Google has not really embraced vibe coded slop. Humans are involved before any code merges and the quality bar remains high.
So will the Chromium bug 5569 finally get fixed?
I'm not sure why you're asking here instead of opening the ticket and having a look at the current status.
It's not a bug but a suggestion rejected by the team (cuttent status: Won't fix, obsolete)
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
0 - https://www.lacksan.com/updates/ 1 - https://github.com/Lacksan-Dev/HP-ZBook-Performance