18,571 karma · joined March 11, 2012
There is one useful observation buried in it, which is that when vulnerability discovery becomes cheap while triage and remediation remain expensive, you create a larger queue rather than a safer system. Fine. I think that point has been raised in many of the other discussions on this site. But then he inflates that into "finding vulnerabilities has never been the bottleneck" which is demonstrably false. Discovery may not be the bottleneck in fleet-wide CVE management but it is plainly the bottleneck for every serious vulnerability that nobody has discovered yet. His own examples of flaws surviving decades of expert scrutiny shows this.
The Glasswing figures show a triage-capacity problem. They do not establish the essay's much stronger claim that "we aren't any safer." You simply cannot infer that from the ratio of findings to fixes! You would need to know which findings were exploitable, which fixes were accepted and deployed, whether attackers would otherwise have found them, how much review work was consumed, and whether the incidents were prevented. The essay measures literally none of that.
Its alternative history claim is also unsupported. Supposedly every participating organization diverted dozens of senior engineers, spent millions, and would have produced more security by assigning those same people to asset inventory and patch automation. Perhaps. Where are the staffing data, budgets, opportunity-cost estimates or comparative outcomes? Promotional model credits are not engineering expenditure and vulnerability researchers, at least to my layperson's knowledge, are not interchangeable with infrastructure engineers.
The broader essay repeatedly collapses distinct anchors and problems into a single villain called "AI." Grok's sexual-image scandal says something damning about xAI. Military targeting failures say something damning about the military, its contractors, its data and its command structure. Datacenter expansion creates genuine environmental and infrastructure costs requiring policy. But none of that establishes that someone using an LLM to understand an unfamiliar API or to write a PRD is morally participating in every one of those failures. That's just guilt by association.
The irony is that the author condemns anthropomorphic language for diffusing corporate responsibility (which is fine), then spends the rest of the essay treating "AI" as a unitary agent responsible for all sorts of things, from corporate procurement and military decisions to power generation, bad software, ugly prose and programmers becoming lazy. He recreates exactly the accountability blur he claims to oppose.
Overall it's a poorly thought out vent piece.
If you use it for even 15 minutes you will see this is not true. At all.
Can you be more specific? "Improve structure" can mean different things to different people.
We've ensured that agents strictly adhere to code architecture rules, using both agentic review rules and deterministic CI gates. Everything from file naming, location and namespacing to the "shape" of each file that shares the same role are consistent. We can trace functions of the same role across the same set of modules, with abstractions and code reuse where they make sense. Once someone learns the code in one part of the codebase, their understanding of that "spine" translates to other areas - the only differences relate to the specific business rules governing those areas.
>> And of course, given the number of LoC (and the fact that the agent rewrites so much code all the time), it's physically impossible that all of them were reviewed by a human being.
Code review was difficult at the start due to the volume of code. One insight we gained midway through though is that the value humans bring to code review is judgment and business context. So we created a code-atlas skill that creates an artifact for PR reviewers. That artifact highlights the most important parts of the code. For example, if a PR author has made the choice to use soft-deletes when the product uses hard-deletes for everything else, that is flagged by the code atlas, and a human reviewer can use that to ask questions about it. Meanwhile, things like boilerplate are de-emphasized; any problems associated with them are reliably found and flagged by AI reviewers anyway. The refreshing part about this is that this has almost completely eliminated bike-shedding: people no longer argue about module naming or whether a comment is worded properly.
Not really, but I can see why some people think that.
We treat 100% test coverage as "required, but by itself not sufficient". It doesn't give us false confidence that everything will be perfect or anything like that. But it provides us with the discipline to make sure no corners are cut, and the bugs that are fixed don't come back.
One refreshing aspect was that during PR reviews we stopped debating whether something needed test coverage. Instead we focused on what was being tested and how.
Yes. At work we recently finished a complete rewrite of the platform. The old codebase got abandoned and two new codebases got stood up. Previous stack was Phoenix LiveView and the new one is Phoenix API + Vue /w TypeScript. Zero code shared between the two. We took the opportunity to re-architect a lot of the core functionality and get rid of the tech debt that had been hounding us and killing our velocity for the past six years.
We finished the rewrite in two months. A little over 700k LoC total. 95% of it was planned, orchestrated and written by AI. We could have gotten it done faster, but we were well aware of the potential for slop and thus paid an absurd amount of attention to (and tokens for) code quality. For example, there is a 100% test coverage requirement in both server and client, combined with AI-driven review rules that say all tests must be non-vacuous, plus a ton of invariants enforced via deterministic checks. Everything from standard linting and formatting rules to AI-necessitated stuff like "comments cannot be more than five lines each" is in there. At the end of each week, we get together for ~30 minutes to review each bug that was fixed that week (there haven't been that many) and try to figure out if more deterministic checks can be added (or new ones extended) to prevent that class of bug from re-appearing. We actually have an Architecture epic with a dedicated Fable agent orchestrating all the initiatives and tickets in it and keeping track of improvements (and the occasional regression). So things like accessibility, usage of shared helpers, enforcement of common patterns, etc. are all kept track of.
The difference between the old codebase and the two new ones has been night and day. The new codebases, combined, are ~35% larger than what we had before, and yet there are way fewer bugs (we actually got suspicious at first and had to check to make sure our logging instrumentation was configured correctly). Performance is also stellar, features have been a lot easier to add and extend, and everything is a lot easier to find. When someone asks a question or has an issue we have a pretty good idea of what part of the codebase to look in and we're usually right.
It wasn't all unicorns and rainbows. Not everyone on the team was proficient with AI-driven development, so they had to be brought up to speed quickly and taught the tools and also what works and doesn't. Code reviews were also difficult and time-consuming. We had to deal with our anxieties about working in two new codebases none of us had authored much code in ourselves. What made all of it worse was that we were racing towards a deadline imposed by external factors so we all ended up working a lot of hours. It was essentially between getting it done this summer or waiting until next summer and we bit the bullet and did it. It absolutely would not have been possible without AI.
To me, having to give extremely specific instructions and provide tight guidelines and guardrails defeats the purpose of agentic coding agents almost completely. At that point I might as well do the task myself.
With Fable I can start with a general ask like "I'm trying to do X, can you investigate and tell me what the shape would look like" and have it poke around and think, ask me questions with single-choice or multiple-choice answers, then break the task into small chunks, each of which becomes a ticket.
With Astra, it's like pulling teeth. It often does not understand what I'm trying to do, takes things literally, does not go above and beyond (i.e. infer intent), and stops way too short of the actual goal. I have to constantly prod it and it's frankly exhausting.
Sam is admitting it now for two reasons:
1. He wants to make it sound like not IPO'ing is actually the rational thing to do 2. He wants to throw cold water on Anthropic's IPO in a few weeks
Number 1 is just spin. Number 2 makes it particularly nasty. Your opponent offers a fig leaf and you turn around and underhandedly try to sabotage them?
Sam doesn't have many redeeming qualities in my book. Just an atrocious, rotten person with a friendly personality.
Max Howell, creator of Homebrew, was famously rejected from Google for not being able to invert a binary tree on a whiteboard.
Well, I think the issue is that most people, even software developers, don't have the luxury of choosing. Everyone needs to put food on the table, and often times that involves working for companies one dislikes or even hates. The problem is now those companies are turning to AI.
Anthropic is structured as a Public Benefit Corporation with a strong charter. In addition, founders will have super-voting shares and so it won't be possible to push them out. Therefore the whole "beholden to investors" thing is not a concern.
Yeah... don't do that. Don't make your job or career the center of your identity. You have to form and then internalize the belief that you are valuable not because you can offer value to others in a material sense, but rather in an intrinsic sense. You have experiences that nobody else has. You have meaning to others in your life, whether deep or not. Your thoughts and perspectives are unique to you. That is your real value.
"DeepSeek serves Claude instead of its own models and collects exchanges for model training"
Obviously. This is how they were able to score so high in benchmarks.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
I went ahead and uninstalled the app. Won't be renewing.
I gave Astra a pretty straightforward bug ticket yesterday. The bug involved an edge case that could sometimes result in an invalid value getting stored in a user profile field. Pretty harmless, no crash or anything, just annoying.
Based on past experience, I don't trust OpenAI, so I decided to watch Astra as it worked. About four minutes in, it convinced itself that it should also check the prod database to see "how far the corruption has spread" and attempted to SSH into the hosting provider. This resulted in my 1Password to prompt me, which I of course denied. Then I stopped Astra, closed the ChatGPT/Codex app and gave the task to Opus 5. Suffice it to say I will not be renewing my subscription, because "you have to watch it like a hawk" is the opposite of agentic engineering.
Get outta here.
OpenAI has been behind in the AI race since last November. They have been playing catch-up.
They recently released Astra and declared it is AGI. Now they are desperate for anything they can use as evidence for that claim.
In other words: they had clear motive to do anything they could to steal the glory from prominent mathematicians who worked hard on this problem and solved it. And they also cannot prove that said mathematician's data was not accessed by either the model or the OAI users prompting the model.
Sorry, but the burden of proof lies in the other direction: OpenAI needs to definitively prove that their agents did not look at the existing work that was about to be published. Otherwise OpenAI simply stole the glory and the spotlight (and I'm being charitable here).