> In the real world, it does feel likely that we’re going to hit some sort of a ceiling on the number of useful bugs, and probably we’ll hit it soon.
This doesn't resonate with me. I see companies adding more sloppily written features with AI. I see more bugs in the software I use, not less. While it's plausible that software is getting both buggier and more secure, I suspect those two move in the same direction not opposite.
My guess is that we're getting better at finding _existing_ security issues with AI (and thus fixing those issues), but simultaneously adding more insecure surface areas _at a faster rate_.
One way to resolve the tension here is to note that CNE and lawful-intercept access to phones depends generally on platform vulnerabilities, not application code vulnerabilities. Low-level platform code churns less, absorbs more fixes under AI workloads than it does new features, and works in a constrained space where guardrails are easier to provide (and where those guardrails already have institutional support at Apple and Google).
Over the long term this state of play could change, and IC/LEO organizations could start leaning more on application vulnerabilities than on platform RCEs. But the action would probably still coalesce around a couple of app-layer targets that could themselves be hardened.
Lawful-intercept is in general implemented at the server equipment of telecom operator, not in the phones. In general, intelligence services don't access phones, if the interception can be done at the operator, because this could alert the subject or expose their techniques.
According to a friend, who is working for an telecom company in Europe, Lawful-intercept is done at a server rack provided by and managed by a law enforcement agency, all traffic of this telecom company is copied to this server rack. The server rack also has a second direct connection to the law enforcement agency. Employees of the telecom company don't know which phone numbers are targeted or which traffic is intercepted.
> My guess is that we're getting better at finding _existing_ security issues with AI (and thus fixing those issues), but simultaneously adding more insecure surface areas _at a faster rate_.
This does seem to be true in the vibe coding era, which I expect will implode at some point. But LLMs could certainly lead to a future where vulnerabilities are scarce. The best time to vet security factors is designing the model and writing the initial code, and LLMs are extraordinarily useful for this too. Most code with security implications is not written by a security expert.
An LLM can be the most anal and well informed security expert you can find. If you write the code yourself but have one in the loop from the start, the code will be in much better shape.
I don't have any colleagues like that anymore, but even as far back as the last half of 2025 I was seeing that automated AI review was becoming effective enough that I considered it essential to any project where security was a serious concern.
These days we're generating multiple times more code than we were writing before. That means a similar multiple of opportunities for bugs to be introduced - so the ability to automate security review is more impactful in proportion to that.
Same as usual: add tests. Over time the test suite becomes the spec that describes how the software should function. As the test suite grows you squeeze out room for undefined behaviour and bugs.
Yet apparently people still dump unvetted LLM outputs onto their colleagues and expect them to thank them for the privilege. So it’s worth asking them what the consensus is of their work to find out if it’s the case.
That's the old way. The current way is nobody reviews anything. The LLM reviews it all and nobody even reads it, they just click approve, and merge blindly. I wish I were kidding.
The point is that people who want to be secure can be more secure than ever while people who don’t care about security will be less secure than now.
Author claims something slightly different but that’s how I would look at it.
The extremes are more potent because either you get super secure 10 times vetted system or you get underpowered model slop with all the vulnerabilities it entails.
Disagree, and in a way it feels like we are dealing with inverse issues: the security "skill" is well defined and will be also engaged with by an agent. Communication companies are further incentivized as any failure is at best reputational harm. Meanwhile SaaS companies are not strictly required to have good UX for their human end users, largely because those users will likely work around the issue. also network effect vs low costs of switching for for comms
> I see companies adding more sloppily written features with AI
I think this is a side-effect of the old product management process adapting to AI. We (as an industry) were never very good at defining features rigorously, because there was a smart human in the loop who had to implement the feature and could push back on sloppy definitions.
Whereas security bugs are easy for the LLM to define and fix.
My hot take is that AI is a multiplier. Software engineers skill can be measured on a scale from -10 to +10, where 0 means you introduce as many bugs as you solve, or something along those lines(this scale is loosely defined, don't think too much about it)
Any engineer who's skill value evaluates below 0 on my scale, ends up with a large negative number when they use AI. Anyone with a positive number ends up with a large positive number.
The extra bugs you're seeing are from devs on the wrong side of 0 on my poorly defined scale.
Brilliant! Makes a simple children's game very interesting. One aspect I really enjoy is that it makes clear the knee-jerk response towards action bias[0]. There are times when your opponent has two-in-a-row, but the probability of a frown on the third is > 50%, in which case it's in my interest to have my opponent click on the third square instead of me (but even knowing that cognitively, it's still hard to not action).
Thank you!! Sage will eventually change its name (I just recently found out about this), but I haven't had time to come up with a good replacement name and make art + quippy sayings for it yet! :)
I might just go with a completely made up word to avoid any trademarks entirely haha
There's an implicit assumption that the organizers would cancel the race if conditions are unsafe. E.g., when I go on a rollercoaster, I assume engineers have calculated the safety better than I could ever evaluate
Sounds like an interesting--although presumably not easily and quickly scalable--solution to fertilizer shortages. I am dubious about the environmental improvement. According to a meta-analysis[0], chemical fertilizers produce less ammonia emissions
> However, ammonia emissions, nitrogen leaching and nitrous oxide emissions per product unit were higher from organic systems.
Basically, chemical fertilizers are much more efficient and have more uniform distribution of nutrients.
> Did you use a regex to verify the data looks like a uuid before putting it into the database?
Is that really a thing? I have used UUIDs as primary keys many times in my life, and never had a need to do such a thing. I am struggling to even think of a valid use case.
> Did you use a regex to verify the data looks like a uuid before putting it into the database? Is your database (like sqlite) using a case sensitive collation for the column? Then you have a problem.
yeah, it seems like the premise is flawed. I don't know that there's actually a problem here.
Might be related to the use of SQLite which doesn't really support data types to begin with and allows to store anything in a column regardless of the declared data type (e.g. you can store 'fourty two' in a column declared as integer).
Apparently it's a deliberate decision because they don't really want to be a "database" just something better then "a file".
The only thing I can think of is if the user can export data from one system and import it to another, and for some reason there was a requirement to keep the UUIDs the same.
...or maybe if you're storing data from a remote API that uses UUID's as primary keys, and you want to make sure you catch it if they change things. Though in that case I would likely have my own primary key and store the remote primary key in a separate column
I have had coffee daily, gone months without any caffeine, and currently average about one cup of coffee every week or two.
I think the best approach is experimental and data-driven. Everyone has different genes, life circumstances, sleep quality, etc., so it's hard to deduce too much from others' anecdotes. Once a week, I do a version of the Beck Depression Inventory[0] to measure my mood over the previous week. For me, daily coffee definitely causes me to be slightly depressed. I have found a cup when I really need it (which is about once every week or two) is ideal. But, whatever it is you want to optimize for (lines of code, happiness, sleep quality, etc.), make sure you are measuring, and then start experimenting!
This doesn't resonate with me. I see companies adding more sloppily written features with AI. I see more bugs in the software I use, not less. While it's plausible that software is getting both buggier and more secure, I suspect those two move in the same direction not opposite.
My guess is that we're getting better at finding _existing_ security issues with AI (and thus fixing those issues), but simultaneously adding more insecure surface areas _at a faster rate_.