I hope some of these backdoors and/or 0-days being kept under wraps by nation states or corporate espionage companies (Pegasus et al) are being found incidentally through all this.
It’s frustrating to have all these 0days and CVEs to patch for now, but in the long run perhaps we’ll leave with more robust software.
The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the pretense of "software engineering" into reality, making the engineering part explicit.
That only works when humans actually understand what they're doing.
> "I have only proven [my code] correct, not bug free."
> -- Donald Knuth (if I recall that exact quote correctly)
Just because you have proven the correctness of your code, that does not mean that it is infallible. Especially -- as a lot of HN users point out -- there's intricate complexity that is likely to cause erroneous behavior if several interfaces/complexities get combined. And those might be caused, for example by a 'user' setting the driver to 'db.backend.sqlite' instead of 'db.backend.sqlite3'; and then you have suddenly an unexpected configuration.
Were you aiming for this?
“Program testing can be used to show the presence of bugs, but never to show their absence!”
― Edsger W. Dijkstra
Or the second one, that I would have attributed to Dijkstra, too:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.”
C.A.R. Hoare, The 1980 ACM Turing Award Lecture
I once saw an interview with a guy that designed garbage cans for National Parks. When asked what the hardest part of the job was he said, “accounting for the considerable overlap between the dumbest humans and the smartest bears”.
For months after some researchers “proved” our code signing system sound I was still finding security holes in the system. To this day I’m not sure what they proved. That the architecture worked? We’d already proven that to a hundred people.
This doesn't necessarily require proving everything mathematically, it also helps to design things in a way that doesn't rely on discipline to avoid gaping holes. For example, languages that allow pointer arithmetic, unchecked array access, or use-after-free have huge opportunities to make security errors that don't exist in languages without them.
A problem I frequently have with setting up testing policies is in convincing people to test what they can reliably test with the tools, and know what they cannot test.
Inconclusive tests to increase automation and coverage accomplish less than nothing. The opportunity cost, the loss of trust, the conflation of the manual testing surface area, are all worse than doing nothing.
The point of testing is to establish a level of trust. That level doesn’t need to be 100%. It can’t be 100% regardless. So you do what you can, and you solve the remaining problem a different way. But you need to know it’s there to address it, and the smoke and mirrors fight that.
I used to work for a company that enforced 80% code coverage for our CI/CD pipelines. Both teams I worked with there, in wildly different parts of the company, were playing games with excluding most files in the repo and writing dozens of tests that didn't actually test anything, just ran the code in the testing container so the lines would count as having been tested. I think LLMs have probably cleaned it all up a lot in the end, because the tests they write do actually test the code (against the code at the point you told the LLM to write the test a lot of the time, rather than a third party spec, but at least it's not just return true all the time).
Every 6 months there was a new testing initiative, which seemed to all be responded to by writing wrappers that returned true to the test automation system we were ordered to use.
> For example, languages that allow pointer arithmetic, unchecked array access, or use-after-free have huge opportunities to make security errors
All languages are built on top of an ISA, whether directly (assembler), or by mapping it to an abstract machine. The you have the dreaded “eval” function. Then because a lot of software lives on top of an OS, there’s all the virtualization that is going on (timesharing, virtual memory, filesystems,…). Memory safety is nice, but it doesn’t help you when the attacker send valid, but malicious data from a compromised source, or by exploiting a logic error.
And for kernel code, where everything is accessible to everyone, it’s much a matter of discipline, especially with so much hardware interrupts and syscalls from userspace going around. Most kernel code has very short lifecycle, it’s the data that is long lived, and it’s a shapeless blob in memory that you have to trust the other party kept in good shape.
The rule is about data structures but I feel it has wider applicability user choices in software. You should either give the user no choices, give them individual binary choices, or let them pick anything that could theoretically be valid and design your system to assume they'll sometimes pick invalid options which will need to be handled appropriately.
Here the user was the deployer and presumably owner of the deployment. An overall setup is only correct if they and the software define a setup that happens to be correct. The software is incorrect if it doesn't support the incorrect setup they require.
> The software is incorrect if it doesn't support the incorrect setup they require.
Is that what you intended to type?
Software is not required to support the requirements of every potential user. Only the ones they mean to support. That’s why Porsche and BMW ignore people complaining about how expensive they are. You aren’t their customer and they don’t want you.
A family of eight who buys a (classic) Porsche bought an incorrect car unless it is for an expensive gag like putting sugar in the gas tank then an EV would be incorrect, no?
You are confusing the wants of a manufacturer with a system that is being used by a person. The person owns the system that is either correct or incorrect for their needs and the manufacturer takes money and screws off. Or, you have the "soup Nazi" as proposed with the manufacturer makes sure you use the system as they imagined and not with a database setup beyond their control.
The user doesn't have to be someone that grew up on Defcon talks and CTFs anymore though. Any Joe/Jane off the street can ask an LLM what is a JTAG or what is a 90 nop and keep asking until they're satisfied. So we have to assume the user is capable of all of those things.
Knuth seemed more interested in Tony’s notion of “obviously no bugs”. There always seemed to me to be a self-evident flavor to his literate code notions.
I say that as someone who sees Knuth as problematic in other respects starting in the 2010’s. Physics governs so much of computational complexity now that I think the idealized form he presents has transitioned from merely holding us back to being crippling. Only game designers, hyperscalers, and an esoteric few of the rest of us seem to understand the vast gulf between theory and practice that has developed in the five orders of magnitude that compute power has experienced since his first edition.
Many, many things that are considered constant in his world are instead logarithmic to the size of the data being managed, or in the case of very large data sets, order n^1/2 because of speed of light and thermodynamics. That vastly reorders the toolbox, because second shelf algorithms now rival or beat the top shelf ones and some options even farther down now become interesting for novel situations.
Regarding your remark "[...] because second shelf algorithms now rival or beat the top shelf ones [...]". That is honestly something I would never have believed back in the 2000s, Windows XP era:
I thought we needed more than the classic mathematical operations and if/else for an operating system that drives the modern world like it had been envisioned by sci-fi in the past 100 years.
That turned out to be wrong: Your modern android with a couple of simple apps is everything a man from 1900 might ever conceivably want from technology.
And it is all if/else/while and mathematical operations.
It turned out you just needed enough of these, to get everything working nicely.
Maybe that says something about kubernetes. Software systems that are complex enough to be intractable should probably be regarded as too complex to operate safely.
I don't fully understand what you're objecting to. Are you saying it's not possible to build a formally verified container orchestration thing?
I do think that most software out there is unsafe. That doesn't make it useless, but if the effort required to exploit vulnerabilities is decreasing we will probably need to stop building things that way.
Which implies that software engineers in the future won't be so cavalier in allowing mod-able or unix-like systems. There won't be an db.backend.sqlite since your software likely won't use a db, and if it does it will be a custom design. It won't be "if several interfaces" it will be "there are no interfaces" no programmer interfaces and certainly no user ones.
> The only way to do that is to make your code provable. That again is only realistically doable using AI.
I think that LLMs actually cannot do this right now while people can?
Also there is a lot of defensive programming that has been left to application and runtime layers because of dated security models in our OS and permissions that are way too coarse. It's a lot easier to write a correct program when you don't have to check every path and do that perfectly when the permission system can ensure that no files that haven't been whitelisted cannot be read
My intuition is the opposite? The math results we are seeing lately are done with theorem provers. LLMs are getting very good at this and surpassing what humans have been able to prove. Verified code is traditionally very expensive and only applicable in niche areas when done by humans.
> LLMs are getting very good at this and surpassing what humans have been able to prove.
But if the reverse were true it would be impossible to prove. AI is trained on all of humanities solutions - LLMs stand on the shoulders of giants, not the other way around.
As of today, the training data the originates from humans represents a vanishingly small portion of the total training. The vast majority of training - how many 9’s is a trade secret - of a frontier model is synthetic RLVR data. That’s how they got good at this.
LLMs can, in principle, do everything humans can. And arguably more. "Right now" is how long? People are slow.
"Provable" essentially means, you have explicit operators acting on explicit states in an exhaustively defined way that preserves "truth", explicitly defined invariants.
A finite thing you can argue over deterministically.
Obviously, "you" there is an LLM, the machine your code is run on has to be defined in that very same exacting manner and so on.
That still isn't enough, you need abstraction, a hierarchy of categories that preserve your intent and accurately describe the problem space.
"Programming" then is solving an inverse problem over that hierarchy, filling in the blanks sensibly on your way down through the model hierarchy, all the way to atomic instructions your (proven) hardware understands.
Those layers of proper abstraction is what's largely missing currently. Or rather, is merely vaguely approximated.
All of which is to say: yes, the current state is a mess. Resolving that is far from easy.
But you really have no choice, that mess is transparent to large-enough LLMs. Security by obscurity only goes so far.
> But you really have no choice, that mess is transparent to large-enough LLMs.
It's transparent to large-enough LLMs given enough resources. Which is the thing that was always true. The difference now is that the level of resources is lower, so we're finding a bunch of things it wasn't previously economical to find.
But the cost still isn't zero. On top of that, the same LLMs are now generating enormous volumes of new code, which both nobody has verified to that level of exaction and nobody has even considered how it interacts with existing and other new code.
> Those layers of proper abstraction is what's largely missing currently. Or rather, is merely vaguely approximated.
This I can agree with, and my perspective would be that we have theoretical solutions with no ergonomics, and rely on unproven (as in formally proven/validated) mechanisms. WASM + capability passing is enough, but the WASM layer is still built on an OS or runtime that is not proven and you'll have a heck of a time trying to build a product on it
> LLMs can, in principle, do everything humans can.
Oh yeah? slides baton Pick up that can, Clanker.
Jokes aside, I do want to see the first news of AI going out of its way to acquire and make use of actual currency and hiring a meat proxy. I don't even care what for, can be making paperclips.
The first such news is pretty old: In ARC's 2023 eval of GPT-4, it hired a TaskRabbit worker to bypass a CAPTCHA out of the small research budget allocated to the agent. Even the rentahuman.ai site which forms a market for meat puppets is kinda old now.
While I whole-heartedly support the goal of actually bug free software and treating software engineering as a serious engineering discipline, as an experienced software engineer who also studied physics, I have to challenge your base premise about what it means to make engineering explicit.
Namely:
> The only way to do that is to make your code provable.
Proofs are a mathematical concept. They only work in the abstract world of mathematics where everything is perfectly logical.
Engineering exists in the real world. The physical realm where our mathematics are only imperfect models of what actually exists. Removing bugs through physical engineering requires persistent trial and error until you have found all the places where our mathematical models don't adequately represent the real world.
It's the same in software engineering, which involves cobbling together a myriad of systems not all designed to talk to each other and massive, ever changing codebases where perfect knowledge is impossible.
So yes, we should be trying to engineer bug free code. But that's really more a matter of changing our resource allocation, spending more time and money on QA and doing away with mottos like "Move fast and break things". It's a cultural shift and will only come when the bosses -- the venture capitalists who ultimately control our industry -- are held accountable when things break, and given strong incentives to ensure they don't break.
> It's a cultural shift and will only come when the bosses -- the venture capitalists who ultimately control our industry -- are held accountable when things break, and given strong incentives to ensure they don't break.
The problem here is that the correct amount of resources is context-dependent.
Suppose you're a small business and you're putting up a website to display the menu for your restaurant and directions to get there. Do you want it to get compromised? Of course not. Does it matter very much if it does? Eh. Should you spend $50M in formal verification to make sure it doesn't? Definitely not.
Whereas if you're developing the software that keeps planes from falling out of the sky, that's an entirely different context.
The problem comes when someone grabs the awful WordPress junk that was suitable for displaying static menus and wants to use it to process credit cards. But even that isn't really the fault of the awful WordPress junk, it's the fault of the credit card companies for designing their financial technology in such a ridiculous way that Merchant A has to be given a secret that allow purchases to be made against the same card at Merchant B, instead of using the decades-old cryptography that would prevent the customer from ever needing to give anyone a secret that enables that wide a scope of compromise.
It comes down to how much work is justified to ensure that the thing not have problems, which is not at all the same across different domains.
The physical world is actually part of mathematics. Look into John Archibald Wheeler and his "It from bit". In particular, the physical world is finite.
Therefore, mathematical proofs very much apply to physics.
You're right about approximations: we gather data and improve theoretical models in an attempt to exhaust that complexity reality poses.
You're wrong about exhaustive knowledge about codebases being impossible. LLMs enable exactly that.
The trick then is to transfer that knowledge in a usable way to what we know about the codebase.
Keep in mind, a mathematical proof is just "an argument that convinces a mathematician".
It doesn't actually give you the truth of a statement, it just convinces a mathematician of its truth.
That doesn't actually change when computers are brought into things. You can convince a mathematician that an automatic theorem prover constructs correct proofs with another proof, but it's "I think this looks right" all the way down.
No, you're incorrect. A mathematical proof actually is a program by the Curry-Howard correspondence.
Mathematicians are trained to act as the compiler, verifying the code, doing the type checks, and to a degree the state machine "running" those programs.
Human mathematicians use introspection to tell you whether a proof/program does what it is supposed to do. They keep those programs small enough to be run on human brains by modularization, abstracting away complexity behind defined interfaces. They mostly rely on other mathematicians to have checked those sub-modules properly.
By defining that state machine, compiler and the tree of "all" known proofs as programs explicitly on a computer, you get Lean and the according libraries of verified proofs.
A proof-program there is verified when it compiles and passes the deterministic structural type-checks built into the language while fulfilling the requirements stated for its interface.
It all reduces to a few thousand lines of trusted code, the Lean kernel, being correct. It's mostly what humans do too, but actually considerably more thorough.
The legal framework for software liability is tightening. The Cyber Resilience Act is one such example that forces developers to get their act together.
Back when I worked at Boeing, I was encouraged to get a PE license. I looked into it. I was not impressed with the exam (it was too basic), nor the requirements, and so did not bother.
Engineering is the discipline of designing and implementing solutions that achieve desired outcomes, using limited resources, while satisfying a defined set of constraints and minimum acceptable standards.
We have way more resources now to achieve way higher standards.
As a general rule, building things as an engineering project (according to engineering, whatever you want to call it) doesn't prove they work. Rather, it proves they don't fail in specific known/defined ways. There's always ways they can fail that aren't known/checked, and frequently ways that aren't considered important.
Kind of like automated tests in software development. Except the people that pay for the engineering stuff are more likely to pay for the extra tests, because of liability.
If a new jet completes extensive flight testing and has flown around the world but has undiscovered engineering flaws, “it’s working”.
Meeting verification and validation requirements in a sound engineering development program should certainly get you to “it’s working”, whether there are undiscovered engineering flaws or not.
Anything men build is subject to failure and unknown unknowns - so nothing works?
Engineering is the application of science and mathematics to solve problems and create solutions… that “application of science and mathematics” is what’s been missing from the majority these last 20 years.
I don't think so. The article refers to formal verification, but also notes that proof checking should be done by humans. We don't have enough capable humans for that.
Looks like AI is finally proving Linus's Law[1]: "given enough eyeballs, all bugs are shallow"
Open Source was supposed to prove this, but as it turns out, there weren't enough human eyeballs, and those eyeballs weren't looking for bugs. LLMs eyeballs see the entire codebase at once.
> That again is only realistically doable using AI
The opposite. The amount of bugs that I've seen AI add to software is tremendous, some bugs are things that even a 18 years old that starts working as a developer right after school wouldn't do.
Also they are unable to fix them, if you ask them to fix a bug they probably introduce 3 other more, and so on, and you arrive quickly at the point that the code is a mess of spaghetti that needs to be rewritten completely (by a human, this time).
On the opposite side AI is good at finding bugs, so I use it more as an advanced linter that tells me if I'm doing something wrong.
You’re describing vibe coding and GP is describing systems for proving correctness.
If you ask an AI to generate a novel math proof, it will inevitably produce garbage. If you give it the tools to do this (e.g. Lean), evidence is that it can in fact generate meaningful proofs.
To the extent that we cannot prove software correct, this is probably largely a tooling problem.
“tooling problem” makes it sound trivial, its a tooling problem like building a quantum computer is a tooling problem. Ie something that probably won’t be solved in our lifetime
> something that probably won’t be solved in our lifetime
If you told me five years ago that AI would eventually be generating novel math proofs, I probably would’ve said that it’s not happening in my lifetime. And yet here we are.
I don’t know what it looks like to get to fully provable code, but I don’t see that it’s fundamentally impossible in my lifetime. Especially depending on scope. Will an entire operating system and everything on it be fully proven correct in my lifetime? Maybe not. Could the authentication stack for a product be entirely proven correct? Sure. I can’t believe that.
> If you told me five years ago that AI would eventually be generating novel math proofs, I probably would’ve said that it’s not happening in my lifetime. And yet here we are.
A single PC can solve a very complex simulation model in seconds, something that would require years using humans to do. Same as solving a very complicated maze. So if coupling a text generator with a proof verifier is now capable of coming up with a proof, I’m not particularly surprised. But given the cost, and the actual usefulness of the proof, I’m not particularly excited either.
But code is not a closed system, even if we do prove a lot of the internal mechanism, we still can’t know the input (noise), and whether the axiomatic foundation will hold. That’s the reason people don’t bother. The theory of computation is just too loose in its constraints. You just write enough tests to catch egregious errors.
"Software" might not be, and definitely not software systems -- but code can have each part of it atomically proven to be correct, assuming you test it with a sufficiently complex simulation model (which you've already granted is within the possibilities for LLMs).
Prove all the code in the software system correct, then prove their interactions are correct, and you've achieved your goal.
(I won't claim this is inevitable with the current tools, but it's at least within the realm of possibility)
What model are you talking about when you say this? "AI" is not one thing, and if you think frontier models are at all comparable to a typical 18yo SWE, you've never actually worked with one of those two.
Most bugs are not security issues and most potential security issues aren’t exploitable. So you can have plenty of bugs in your code without getting hacked.
> The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
> The only way to do that is to make your code provable. That again is only realistically doable using AI.
If you're code is "provable" doesn't that only mean you've proved the code meets its specification? The specification can still have bugs.
Yes, that's where the "engineering" part comes in.
Engineering builds models that approximate the real world under practical considerations. You e.g. have to weigh costs vs risks and apply good judgement.
In essence, you try to achieve the best possible with the resources you've got.
You are describing the difference between Verification (Does this do what we explicitly said it would do?) and Validation (Does this do what we wanted to achieve?). One is about compliance of design promises, and the other covers the issue that the various levels of design documents might have failed to completely capture intent.
Depends which way you mean. It is possible to provide a formal specification for a proof verification engine and prove, in the same language that the engine is for, that the engine implements that specification.
Proving that the system it implements is like, logically sound, is a different issue, and for that you do need stronger axioms.
On the contrary - this is explicitly the mission of most military organizations. There are countries in the world today where every day their bridges and buildings face adversarial attacks from state level threat actors.
The difference is, people who build civilian bridges and buildings are not actually generally expected to build structures that can withstand such attacks because preventing those attacks is considered the government’s job.
So no, they typically don’t undergo ‘more rigorous testing’ than software against security threats. The fact that governments make no effort to protect networked systems from being attacked places the burden of withstanding those attacks fully on the private civilian operators.
In an important way bridges and buildings are indeed proven to be sound by applying the mathematical tools of structural engineering, materials science, etc. Software Engineering also has analogous formal tools at its disposal (Lean is one gaining a lot of exposure these days), but many were being neglected because it wasn't worth the bother. In this new adversarial world, we'll be forced to reach for them more often. Luckily the models are also a big help in making these tools more approachable.
> It’s frustrating to have all these 0days and CVEs to patch for now, but in the long run perhaps we’ll leave with more robust software.
I'm skeptical; every line of code is a liability. Humans regularly make the trade-off between adding lines of code vs doing without the incremental feature addition. LLMs don't; everything gets added.
The recent brotli attack should have been a wakeup call - few people use it, no one actually needs it, but the exploit that it carried was present on every system. Everything from IIS to Caddy and in-between, and yet no one was actually using the thing.
It's a liability to add code, whether you're duplicating existing code in the codebase or adding a feature 1% will use.
LLMs can run with whatever directive you give them. If the directive is lots of code that's what you get. But when everyone gets repeatedly burned by vulnerabilities the directive becomes building bullet-proof code. With the right prompting an LLM can be a lot more diligent about that than we ever could.
This is like saying humans just shouldn't gamble or drink or have sex with the wrong people.
It might be true but it's also a pointless statement that doesn't impact the problem, because it won't happen. And "it won't happen" isn't some unsupported prediction that no one can say. The aggregate behaviour of humans is a known thing, and it's not productive to the actual problem to pretend otherwise. It's only productive an individual looking for an easy excuse to avoid dealing with the problem.
Uh, I'm literally asking LLMs to shorten code daily. Sure not everyone will but I think the point is that LLMs likely do make it possible to write far more robust and secure software, including short code, if the user wants to.
By default, yes. But you don't have to let them, and enforcing some code quality was shown to use significantly fewer tokens (can't find the link now).
It doesn't have to be that way. You can use llms to greatly improve the quality of the code. You do this by focusing on one part of the design use the LLM to explore alternatives, use it to poke holes in what you have. I think the engineering cultures that embrace this way of using AI will far outperform everyone else in the long term.
I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later - because the time to test the possible regression cases of the original code wasn't available right now.
I could have worked through all that on my own, but having the AI as a rubber duck to talk to - plus the edge cases it was able to point out - was really helpful.
> I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later
I wonder if a refactor is even necessary.
Concepts like KISS, DRY, etc. are largely human-centric. They're meant to make code easier to write, understand, and maintain - for people.
Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
But with coding agents, some of those tradeoffs start to change. An agent can find and update duplicate implementations in seconds. It doesn't need to maintain the same mental map of a codebase that a human does.
And if we have good specifications and comprehensive tests, behavioral divergence should be detectable and correctable. In fact, duplication can offer an advantage over shared abstractions: isolation. Changes to one implementation don't risk breaking unrelated consumers of shared code, and each implementation can evolve independently.
Maybe we won't need as many high-level abstractions, or eventually even some of the architectural patterns we consider best practices today.
If the cost of writing and maintaining code approaches zero, perhaps we should optimize less for human readability and more for runtime performance, memory efficiency, isolation, and correctness.
We might even regain some CPU and memory efficiency by eliminating layers of indirection, virtual calls, and abstractions that primarily existed to make code manageable for humans.
Perhaps the optimal architecture for AI-maintained software is fundamentally different from the optimal architecture for human-maintained software.
A lot of our software engineering best practices are based on the economics/ergonomics of human maintenance. What happens when those fundamentally change?
> Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
Until proven wrong by coding agents, this is still the case even for agents. Not sure why you are assuming this doesn't apply for the machine
I cannot read a 50-page T&C document. I mean, obviously, I can physically do it, but I don't have the patience, and I'd lose track of what I'd read. Getting an LLM to summarise a 50-page T&C document is simple, it doesn't lose track, and it spits out a summary in seconds.
I cannot read a 50K LOC code base at once. I mean, obviously, I can physically do it, but I don't have the patience, etc. I need mental shortcuts like abstractions layers to hold even parts of the code base in my head. LLMs don't. They can read that in seconds and hold the whole thing in context.
This doesn’t really support the argument that KISS et al don’t apply to LLMs. They may not ‘need’ these principles for the same reasons as humans, but will still benefit from the context having higher information density.
>because the time to test the possible regression cases of the original code wasn't available right now.
The models don't know that they're not human when they estimate. It's worth telling them that all estimates need to be made in the context of an agentic AI doing the work.
It's funny, I've had similar conversations, where the agent would recommend the 'lazy' solution because the robust one took too long. More often than not, it was assuming human-hours of work though. Once reminded that a clanker would be doing the work it's conclusion shifted to the robust one.
Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.
It’s jarring when the bot tells you something will take a “week of work”. A good reminder I guess that it doesn’t have self awareness as we usually think of it.
Yeah, I've seen that, too. In my case it was less about the dev time and more about the regression testing time (much of which would fall on QA and involved reading from external feeds, etc - so, complicated). But your point is fair. The AI is ... notoriously bad at LOE. Not that it's always wrong, but frequently enough (and by a large enough amount) that tradeoffs like that really need humans considering them.
People complain about LLMs not respecting KISS, but fail to address why = LLMs being defensive and coding for situations that either do not happen or are unlikely to happen. That doesn't absolve you from deciding using your human brain if given change makes sense or doesn't. You can also tell LLMs to not program defensively.
Same with any other acronyms - if you don't set up guardrails on when given principle should apply you'll get code that you can only complain about.
My complaint is that LLMs’ approach to making code robust is something we used to pejoratively describe as “enterprisey”.
Oftentimes there are two broad ways to fix a gap in the logic. You can eliminate the source of it, which often involves refactoring but tends to result in less code and cleaner, more comprehensible logic. Or you can leave the gap there, but attempt to render it safe by adding extra logic to detect and handle the error condition. This reduces changes to existing code, but makes the overall system more complicated.
You can’t just indiscriminately favor one approach. Which one of those is best depends on the situation. The deciding factor is often something like a time constraint that you can’t know just by reading the code. You might need to talk to your team before deciding.
But LLMs don’t do that. They always choose option B: slap a bandage on it. Keep on adding more epicycles. In the 2000s we learned that, over time, always choosing this approach inexorably leads to codebases that are brittle, bloated and expensive to maintain.
So the problem, from my perspective, isn’t that we shouldn’t be coding defensively. It’s that LLMs encourage us to do it in a way that we’ve already learned is unsustainable.
Agree. It should fall on to developers to decide what to do = whether tackling tech debt is viable solution (whether making decision on their own or talking to people that can make such decision) or not. If, however, you're told "here is a codebase that you're seeing for first time, fix this error" and you simply cannot make the decision, even prior to LLMs you'd put a bandaid on it. Or at least - that's the standard approach = fix now, refactor later, where later in my experience never happens (sorry for this train of thought).
I don't think this is anything new, nor LLMs are to blame here. Although - LLMs want to make you happy, or maybe they don't think about what user actually needs, just how to accomplish the goal that was stated; they do stuff without asking questions (unless you constrain them or plan first). I've actively put in a hook for my agent to not make decisions on their own and ask me when it detects it's about to make a decision.
Agreed, it is not at all a new problem. The enterprisey codebases I’ve encountered are ones that have chronically had no clear owner, or constant ownership churn. I have been in that position before, and I also decided to make the code even more bloated for the same reason: I did not and was not going to have the time to learn the system well enough to safely do a better job.
I think where a lot of people run into problems with the KISS principle is they conflate simple and easy. More often than not, simple is hard. Which is maybe a soft reason why agentic coding, which is all about trying to make every task easy, leads so consistently to complexity and bloat.
Nobody else is likely to see this comment but I want to make it anyway. Yes, simple is hard. Thank you for articulating it so well.
And yes, that's also why LLM code is usually (unless driven by someone who really knows what he's doing) full of unnecessary complexity. Because although LLMs can get a much broader "understanding" of a code base than I would have given them credit for a couple years ago, their "understanding" is still shallow. And what you need to truly be able to achieve that hard simplicity (I heard someone refer to it once as "the simplicity on the other side of complexity", e.g. when Kepler figured out that orbits were ellipses, not circles, and that allowed getting rid of epicycles) is deep understanding. Which LLMs are not capable of, hence why their code is full of the kind of needless complexity that one produces when one has only a shallow understanding of the code. (E.g., you in that enterprisey codebase when you weren't going to be given time to reach deep understanding).
So true! And it goes hand-in-hand with a different problem: You being able to try and brute-force solutions.
If you write your prompt as a request, and not carefully as an idea or suggestion, the bot can blindly agree to 'help'. And if you are stubborn about it, you can lose hours on something that cannot work, or make the code infinitely worse.
However, it's also the path of getting better at programming. To learn to take a step back, to ask yourself if it's really sensible. Just that now it also involves questioning the bot's help, as well as writing your prompts to prevent it.
> coding for situations that either do not happen or are unlikely to happen.
Not coding for situations that “do not happen” is exactly what creates vulnerabilities. But I also don’t think that such code is the main source of complexity in LLM-generated code.
An example to what I'm talking about: I have application that takes two inputs from request. I've put in validation on request values to deny values that are greater than 100. In my code I'm adding these values. LLM can say "cater for addition of these two numbers, because they might go over MAX_INT and result in overflow". This is a situation that won't happen. LLM can recommend - add assertions. That's unnecessary.
And the day you add a way to batch import request through another code path, you may forget the validation.
Having it in the lower layer is correct, a proper optimizing compiler should be able to detect there's a single code path to the function and that the checks have already been done, skipping the second check.
Arguably it’s only unnecessary when the value range is enforced by the programming language (types). The structure of who calls what in the code can change, and suddenly larger values can appear. You don’t want to have to perform whole-program analysis on every change to check whether all assumptions made in the past still hold. That’s also a source of vulnerabilities: assumptions that held when the code was written, but stopped holding sometime later.
That’s why I think code needs to document all its assumptions, and in a way that is checked by the compiler to the extent possible. If you document that the values have restricted range, then the AI should be taking it into account.
I vibe-slopped a small and local forms application for my family. I explicitly mentioned that fact to the LLM.
Yet, I removed 2/3s of the code, because it triple-checked that every file really existed and was valid, that the input form was less than a million bytes in size, that there were propper HTTP status codes for everything, that every possible error from reading data was eagerly checked and caught, and so on.
Like come on, three people will ever look at it. So keep it small and tidy so I can understand it better!
Depends on your incentives, most people and companies are measuring Lines of codes and features as the metric so ofc it will increase it, but AI can create small KISS applications. It might have a little difficulties in doing so sometimes because it sometimes likes to overengineer things but I have to wonder how much of it is because it is RLHF'd to solve questions at any costs in terms of lines of code rather than training it in solving it in KISS principles. Also I wonder how AI will perform if we explicitly treat KISS as the only principle and have checks running on it and have it discard all the code which wouldn't follow KISS principle if it doesn't follow the principle.
Yeah, so far coding agents haven't been good at reducing entropy at a large scale. That's the area where we need to push hardest in my opinion. Writing code is cheap now, but that makes it easier than ever to inflate codebases to millions of lines of unnecessary complexity that are impossible to work with and maintain. I want to see an LLM reduce a complex multi-million line codebase to 1/10th of its size or less without breaking functionality. That would be impressive!
> but that makes it easier than ever to inflate codebases to millions of lines of unnecessary complexity that are impossible to work with and maintain.
Impossible for you, me, and other humans maybe. But not hard to understand for LLMs
> I want to see an LLM reduce a complex multi-million line codebase to 1/10th of its size or less without breaking functionality. That would be impressive!
They can and do, if you ask them to.
If you have tests to validate functionality, it can easily reduce and refactory.
Well, with fewer architecture astronauts overdoing things, all those extra abstractions and dimensions of extensibility that never get used never get written, so one might hope the code is simpler in the long run. But right now coding agents just love writing code, and they don't have a lot of taste for boundaries and architecture, so we have the loop-unrolled, big-pile-of-ifs kind of logic that isn't good.
I may be ignorant, but what do you mean with this and why is it upvoted so much?
To me KISS is basically about how you’d write the code, the architecture, which is something that - at least currently - humans need to oversee when writing new code with LLMs.
But what does it have to do with AI discovering a ton of bugs in a lot of (open-source) software?
Software that does less is easier to understand and reason about, and typically requires less code. Less opportunity for bugs to appear.
Maybe, when they build a pomodoro timer, people will consider the possibility that the entirety of a browser engine as well as 30 000 javascript dependencies from random unvetted sources introduces unnecessary complexity and a practically infinitely fractal attack surface.
Someone not following KISS, might install Windows Server + tons of bloated applications, in order to serve a .asp server, which serves JSON that never changes, or something similarly stupid.
Meanwhile, the KISS developer would put static .json files on a CDN or self-hosted Varnish or whatever, and call it a day.
The first opened up a whole can of potential venues for exploitation, while the second might only have opened up one potential venue for exploitation.
As a testing tool, yes, post AI software is going to be more robust in the face of attack. We saw this when Metasploit became a thing, it provided an easy way for web site owners to test their stack against 'known problems.' I think that as a rule, we won't get a lot of action on this until we change the laws around incidental damages liability with regards to software.
It is also unfortunate than in more than half the cases where AI provides a 'fix' that fix breaks something else, so my guess is this is going to be 90% human labor to correct, at least initially.
It's interesting that no-one talks about writing new systems and base languages that don't inherit anything from the current toolchain. That's the first step, then new architectures / fully open auditable hardware basis. With html you don't need any of this dependency chain. As long as you can write a browser you can be running on anything underneath.
While it's hard to point to a fully top bottom initiative to create new platforms from the ground up, the Chinese appeared to be making an effort to reduce their non-native surfaces with things like Harmony OS.
A complete plan to reduce vulnerability from untoward influences is more feasible now with agent assisted engineering. You have to be carefully selective about what matters and what doesn't, or the cost and time balloon out of control.
That's also weird, in this reality, isn't it? You've got russians, chinese, etc, supposedly antagonistic to the western cultural hegemony, but then they just rely on western technology tool-chains. If I was guiding any of these countries a close to number 1 priority, technologically speaking, would be to create a completely independent software tool-chain. And talk through adaptors.
I think China uses NeoKylin, and Russia Astra Linux, both based on Linux.
I don't see China antagonistic to the west - they want autonomy, and don't share many of the values, but they're open to a wealthy West spending lots of money in Chinese goods.
Russia, at least its government, is a bit more, especially recently. But anyway, why reinvent the wheel when a battle tested FOSS is there for the taking?
At this point, a browser is a significant part of the way to being an OS virtualised inside the OS it's really running on. Complete with occasional leaks through the virtualisation to the real host OS/machine.
Yes, chrome for instance is more lines of code than the entirety of Linux, I think this just makes the case stronger for what I said. Although I understand why it might be so.
What do you mean with "don't inherit anything"? Using the existing binary ABI is mandatory for interoperability so yes, in that sense every new programming language inherits something. Other than that, there's plenty of languages that have fully self-contained toolchains and runtimes, e.g. Erlang and Rust come to mind. Guix bootstraps its entire environment from a minimal Lisp implementation. There's also Microsoft's CLR and its entire ecosystem of programming languages, but I don't know if the runtime exists next to the Win64 C/C++ base or on top of it.
HTML is entirely the wrong comparison as it's a document format and not a programming language, and "as long as you can write a browser" is not a simple condition. Do we have any browser (even in development) that isn't written with current toolchains? Or a headless javascript runtime perhaps?
HTML as the "transport"/"dialect" to keep compatibility with the existing computational world. What I mean is from the ground up, no C, no erlang (which Im a big fan of in terms of application organisation), no Rust, no Javascript. Start from first principles, OS'es closer to uni-kernels, sane sharing/privacy policies, ability for instance to start an "executable" (already an abstraction tied to the current mode of software production, albeit a perhaps useful one) with a narrow set of scoped access. Then it only has to implement a browser/subset of it to parse HTML and it can "access" most of the relevant parts of the existing software world (internet). Ditch anything complex, if necessary make a browser that just uses flexbox, no other things, no backwards, compatibility, if you need compatibility buy a normal laptop with a normal OS, that comes with all the cruft, but design this new one from the ground up.
But I also don't understand why (without compatibility layers) a browser should be as complex, or remotely as complex, as currently, specially with all the knowledge in hindsight.
I'm not saying this is easy, doable, or whatever, but that was what I meant.
We will leave with more robust software if there are people understanding how this software can be build. Don't forget that the industry as whole stopped hiring new people who wants to enter this field, also skill degradation is a real thing.
It would be the opposite. While old backdoors will be patched (if easier ones are not switched off or upgraded already), new far more sophisticated ones will be added with AI that only few states will have.
Shannon's entropy theory disagrees. No matter how good the best AI is, its ability to hide a backdoor is limited by the information density within the programming language, and the complexity of possible backdoors will plateau, allowing much lesser AIs to discover them. Consider that binary software is just a more dense form of code, too. A much less dense form, Javascript, makes finding backdoors easy because they all have to use obfuscation via base64 or something to avoid static analysis, which itself immediately draws suspicion.
I was thinking that intelligence agencies and "security" companies like Celebrite must be worried. If eventually all vulnerabilities are patched there will not be any avenue for them to gain access to adversaries' computers.
I predicted long ago that when computers become totally secure intelligence and LEA will lobby for mandatory backdoors, possibly through secret courts.
more likely the bugs will shift complexity. this has happened before, but slower. then that added complexity will make the new backdoors and 0days even more expensive again.
in the beginning, ppl didnt know a lot, and default passwords and stack overflows were 0days.
then awareness came and a lot of that is actually fixed. Writing a modern exploit more often now requires many stages and a shit ton of skills and knowledge.
I'm more annoyed by the fact the fixes and exploits themselves are being artificially delayed in misguided attempts to coordinate disclosure, in world where anyone can just point AI at vague direction of the bug and just find it
Right, it entertaining to me to prompt an LLM with a build error or a runtime dependency error and it will literally start reverse engineering things before even attempting to look at docs.
I would be shocked if there isn't a big team of people at the NSA/GCHQ, etc, right now monitoring all the advanced-LLM discovered holes in commonly used software that they might have already been using for 10 or 15 years without anyone knowing about it. And writing daily reports basically saying "cross this one off the list, it's getting patched by debian, RHEL, etc".
This is the real reason for the vulnpocalypse, not "technical debt".
NSA spent 20 years stockpiling vulns and pushing the industry towards half-assed solutions like address sanitization and pointer tagging when they could have put the industry on memory-safe languages instead.
They managed to get the IME/PSP/TrustZone into 99% of the CPUs out there by mandating it for government purchases; they could have done the same thing with memory-safe languages. But instead they chose to stockpile vulns. Hope they burn in hell for this.
Why do you think the NSA could have put the industry on memory-safe languages?
Even if they wanted to, I highly doubt they could push the industry to do that. The industry does what it wants to do, and rewriting tons of software was far from its priorities. There were no LLMs back then to help with such a massive migration.
There's also the fact that rewriting software tends to introduce a lot of new bugs.
The U.S. government could have required all new software for any government-procured system to be written memory-safe languages, thus making it ubiquitous. This could have been phased in slowly with a few years of on-ramp time to allow for industry to acquire the relevant skills.
The DoD tried that with Ada and largely failed. That was with defense contractors whose primary customer mandated it. That was despite Ada being proven to work in its first projects.
The U.S. government had pushed Ada for years and it never worked out. The government was forced to accept C++ because industry was rebelling against ADA, even though ADA was memory safe. Well, Ada did have the ability to be memory unsafe. It was much better by default.
I mean, the government could have just stopped working with those rebellious, incompetent contractors, but I guess the pork barrel was just too enticing.
But even in memory-safe languages, compiler bugs are still an issue. The theory is perfect but the implementation is flawed. In such case once the compiler bugs are found, the software would have to be rewritten to compile. For example an 11 year old memory bug was discovered recently in the rust compiler: https://www.penligent.ai/hackinglabs/rust-borrow-checker-bug....
Memory safe languages are not a silver bullet either.
I think we'll have flying cars before we have to start focusing on compiler bugs. Most software is already written in memory safe languages and their vulnerabilities are unrelated to memory safety, they're just plain old logic bugs.
Basically, the borrow checker allowed writing memory unsafe programs without using the keyword unsafe.
Compilers for C, C++ etc. are well established but Rust is a relatively new language. There are many bugs to come just like this.
Using a memory safe language is not a silver bullet for writing memory safe code. The implementation of the memory safe language introduces bugs as well.
You misunderstood, I'm not saying that compiler bugs don't exist or that they're unrelated to memory safety.
I'm saying that these compiler bugs are extremely low on our list of priorities. If we want to eliminate all vulnerabilities in all of software we have about a century worth of logic bugs that are likely more critical and easily exploitable than compiler bugs.
The DoD have even created their own language: ADA. Massive contracts power, but different markets to incentivize.
The distance between the usual consumer/b2b tech startup and the kind of company that sells software to the air force is even bigger than the distance between Google and the kind of company who hires Accenture.
Why do you think the NSA could have put the industry on memory-safe languages?
Did you even read my comment? I very explicitly answered this.
Government purchasing requirements have an immense effect on industry. IME/PSP/TrustZone have 99% CPU coverage because NSA put "owner-inaccessible oversight processor with disjoint physical address space" into federal sourcing requirements.
They could easily have done the same with "memory-safe language". Note this is not the same as "must use Ada" which is obviously dumb. The IME/PSP/TrustZone req worked so well because they specified the feature not the implementation (and indeed it has been implemented three different ways).
But instead, NSA actively pushed in the opposite direction and funded all sorts of kludges to try to keep memory-unsafe languages kicking as long as possible.
They have actively sabotaged the national security of their own country.
Sometime the profit made by the companies for inserting backdoors can be quantified:
"
In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program. In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm.
"
People seem to be fine with it as long as their own team seems to be profiting from it - but for those of us who are not subject citizens of the NSA's government, it is a truly heinous state of affairs.
I remember reading Godel Escher Bach back in the day, and there is the parable of the record player between the tortoise and the rabbit. And the tortoise keeps building more and more secure record players that the rabbit keeps finding ways to break.
GEB then goes on to teach you that, no, in fact, you cannot have a perfectly secure system. Not just practically or economically, but even in theory, all systems are fundamentally breakable. GEB, after a lot of chapters (what a doorstop!) ties that parable into Godel's Incompleteness Theorem, and essentially proves that no, you can't make unbreakable things, as a fundamental point of logic.
So, when I look at all this, I see that yes, there is an economics point of view here, that fixing code is just expensive, like making a less and less breakable record player. And that AIs push that breaking and economics point much further along than what we have had.
But then I also see a lot of comments here that seem (to me) to be arguing that there is an unbreakable code out there.
Am I reading this right? Is there such a thing as 'perfect' code? Or is my outdated reading of GEB still valid or not?
[0]Note, I'm not a CS person, more a biophysics person.
The record player thing is a clever analogy for Godel’s theorem, but the “strange loop” is not especially relevant to the security scenario.
Godel’s theorem says that unprovable true statements exist. Fortunately there is a vast set of provable true statements that are quite useful in real life.
Similarly, the halting problem is that you can’t write a program that always determines whether absolutely any program you give it will halt. But in real life compilers can still detect infinite loops in your code unless you try really hard to fool them.
In practical terms a software system can never be “perfect”, because first you have to define “perfect” (i.e., specify correct behavior in every possible state), which is practically impossible, and even if you manage that, the hardware has to implement the software abstraction perfectly, and that never happens. (See prefetch attacks, cache timing attacks, supply glitch attacks, rowhammer, etc.)
The security issues come about when someone finds where you failed to specify desired behavior, or (at any level) your system failed to implement it in some circumstance. No strange loop required.
>But in real life compilers can still detect infinite loops in your code unless you try really hard to fool them.
Having never written compiled code, this intriques me. I often write one offs that I actually want to loop infinitely until I tell them to stop.
How does the compiler know whether it's just really long or infinite? Like, if I write a progressive approximation of pi or prime search algorithm, both are never going to halt because we're certain there are infinite digits of pi and prime numbers. The program could technically halt, but not as a function of the program but rather the hardware.
Or, being silly, if I write a "flip bits in target directory until all bits are flipped" and target /dev/null as a user of the software, it wouldn't halt, so the compiler would detect that?
Is there some --don't-mind-the-recursion flag for developing a program like ycruncher? I get the feeling that there's a list of "this typically causes infinities" that it checks against and if your use isn't on there well then... So it's just the mouse/mouse trap thing but in a compiler?
Or is there some unique CS going on that the compiler employs to determine certain classes of loops?
I think it's worth pointing out the compiler usually won't do much (if any) of this kind of check unless you tell it to.
When you tell it to, you usually have good control around what kind of thing you want it to consider a problem, how much effort you want it to spend trying to prove that, and what should happen with code it can't prove that property for. Most commonly, people just use the "tell me if I've made an obviously dumb infinite loop which does nothing useful while it runs".
E.g. y-cruncher does something other than infinitely loop for no reason so it wouldn't trigger the loop detection logic on most anyone's compilation settings.
On the other hand, a loop which does nothing but run until the last digit of pi would either trigger the compiler to say this is a useless infinite loop or to say it isn't able to prove this loop stops (almost certainly the latter, as such a loop is a great example of going out of your way to fool the compiler).
A loop which sometimes terminates and sometimes doesn't depending on runtime input would depend on your compiler settings, but almost always nobody sets it in a way to say that's a problem (and when they do almost always it's not possible for the compiler to prove one way or the other) if their compiler even supports that kind of analysis.
Interestingly, in C++, a trivial infinite loop is undefined behavior. So the compiler not only doesn’t have to detect it, it is allowed to assume you didn’t do it. [0] This is inconvenient when you actually want a trivial infinite loop. (C++26 was going to fix this, but it seems we may not ever get a C++26…)
in C infinite loops with no side effects are UB, so detecting them is useful for diagnostics.
guaranteed termination also is needed for some optimizations. but since side-effect-less infinite loops are UB in C, a compiler doesn't have to prove that such a loop terminates, it can just assume it does. other languages may differ, but I don't think any of them prove convergence of algorithms.
a don't-mind-the-recursion flag can be `-fno-finite-loops` on clang, or a read or write to a `volatile` variable in standard C.
How does the compiler know whether it's just really long or infinite?
One straightforward approach is to use Hoare logic [1], specifically the method of loop invariants and loop conditions. If you have a loop where the conditions are expressed only in terms of invariants then the conditions will never change truth values during iteration of the loop, thus you have an infinite loop.
Now, some loops are written deliberately like this, i.e. "while (true)", and so there you need to look at whether the body of the loop contains any side effects (reading input, printing, etc). Then you have what is called a "productive infinite loop", such as an event loop or a REPL. Of course you can't prove this sort of loop will ever halt, since the user may never elect to issue the quit command, but these sorts of loops often tend to spend most of their time with the process sleeping until the operating system wakes them up to handle an event.
Perfect security is actually pretty easy to achieve, for example, if you turn off your computer, it's impossible to hack over the internet. But it's also useless - you want some people to access the machine some of the time.
Another way you have very good (and fake) security, is by reducing the scope of the problem - if you check every request against a very strong crypto signature, it's also practically unbreakable.
But then you have issues like who signs these tokens, who decides which user gets what permissions etc. etc. which mean you have to weaken practical security to make it useful.
Another example is the L4 microkernel, which 'proven' to be bug-free and secure. But it also doesn't do like 99% of the stuff a regular kernel like Linux does, and sort of pushes the issue to the user.
So even defining 'perfect' security in a way that the system remains practically usable is very difficult and potentially impossible.
We come down to to the permissions problem - each person should have as much permissions to do their work as necessary and nothing more - which is essentially a reformulation of Gödel's incompleteness theorem.
This is a misconception of what is being said in GEB.
Gödel's Incompleteness, very roughly, says that not every true statement (in a formal system) can be proven. In particular, it says that for a logic equipped with arithmetic the statement holds; how you get to security I do not follow.
The idea is that since you can make every security program turing complete, I thiiiiink?, then you can have it be a formal system. So, you can then get the code, in very tortured ways, to execute a paradox, thereby breaking it. Likely in enough ways to let you gain access, though not always.
Godel's Incompleteness Theorem basically says "any system complicated enough to give you basic math is either 'incomplete' or broken."
Clearly our math system gives basic math, so we should conclude that it is either 'incomplete' or broken. Before the incompleteness theorem, it was exciting to imagine that it might be complete, but we had no idea. Now it seems likely to be incomplete. The odds of it being broken haven't really changed.
If it is broken, 2+2 still equals 4 (we didn't really learn that fact from abstract math), but we'll need to fix up set theory. In a world where math isn't formally verified (and even lean itself isn't formally verified), the Incompleteness Theorem is permission to be awed by how huge the space of all logical deduction is, not an argument that logic is a fiction.
To come at it another way, do you believe that there is an 64-bit integer which, any time it is inserted into register 8 on any computer, will immediate convert the raw mass of the earth into a black hole? No, because even if you suspect there is a hole in the foundation of math, you still believe in brute-force case-analysis, and you know that every 64-bit integer has been inserted into register 8 on a computer before.
The important distinction in the book that was made is that it was for a sufficiently advanced reproducer of the original sound, a thing that would make the perfect sound based in the record would cause its own destruction. Something lossy or without that property is actually less susceptible to damage.
The article takes PHP2Shell as the worst offender of the present wave of vulnerabilities but HTTP2Shell/Brotli2Shell was arguably worse. The consequence over at Brotli may very well be the same, but the timeline shows, if anything, that at least part of reality is actually still very much "humans just sitting on vulnerabilities for months or even years". From the timeline: 8 years in the code, 8 months unreleased (but fix in Git) and at least 4 independent researchers finding the problem and pointing it out.
Google also authored libwebp which contained the high severity buffer-overflow vulnerability used for the zero-click hack that made the Pegasus weaponized spyware famous worldwide for targeting journalists, human rights activists, etc.
That'd be true if companies were approaching AI responsibly, and not attempting to YOLO vibecode entire platforms. But as core utilities go, I do see the value in hardening against vulnerabilities by using AI. And when sanity returns and companies start approaching its use rationally when it comes to development...develop best practices around how to build with AI, and ensure code remains reviewable and understandable by humans, limit scope creep and sprawl, and slow down a bit to think through these issues - yes, it could yield some very positive outcomes in the long run.
The problem is there is no way that you won't have someone, somewhere videcoding platforms, accumulating technical debt and benefiting short-term thereby. And once such approaches work and get semi-reliable, they'll spill over onto other areas, gradually becoming universal.
I mean, LLMs themselves come from exactly this phenomena. They are a product of finding a technology that scales and going with that no matter what. And parts of this will hit a wall and have to retrench, current players may implode but the genie isn't going back into its bottle so disruption within disruption will continue.
I also feel like this is true. We are going to see a massive explosion of CVE's being found and patched, then it will gradually slow down. But there is also the possibility, the code being written now is written so fast, and by people that might not even understand it in the first place, that the pace of adding new vulnerabilities might explode at the same time. I'm not sure which is faster.
I feel that while it's plausible that AI progress in making existing software less shitty will outweigh the increasing capabilities to exploit software and so make the existing software more secure; however, I feel that the trend is that the rate of making existing software less shitty is far, far outpaced by people releasing vast quantities of new shitty software.
Ai only reliably returns whats in the training set with sufficient power. As you can imagine, this is a supremely limited scope of all of human knowledge and depends on data that were both recorded and made available for training.
> But when this is all over, software will be more secure than it has ever been before
I don't see sufficient evidence that this is not going to be a perpetual race between people/AIs fixing existing software and more advanced and powerful next generation AIs finding new vulnerabilities and exploits.
While no chatbot can ride a bike currently, that doesn't invalidate OP's point. "Distillation of all human knowledge" here is not a scientific claim, it's a colloquial exaggeration to emphasize its actual capabilities vs the complaint people have against it.
Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work? Collectively, we just won't know for a while.
It totally feels like the former if you watch it find and fix vulnerabilities or other debt-tasks one after another.
But only so many of these "technical debt" issue are little off-by-one errors that get remedied by a surgically narrow patch.
Many enough require some kind of restructuring or redevelopment of their own and it's going to take time to figure out if AI faces the same dilemma as human developers: where each non-trivial change carries the risk of some new issue, ad infinitum.
If that happens to be the case, and AI isn't able to magically produce perfect software in finite time, then what's really happened is that the threat of hostile AI exploiting our technical debt will force us to always be burning and churning code just to remain a moving target.
"Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work? Collectively, we just won't know for a while."
Yes, let's fix the foundation. It will make adding features easier once the debt is paid off. And we will probably learn how to do better in the future. It reminds me of settings compiler warning to be treated as errors. Once you do that, you have a ton of work to do. But if you are smart (not all devs are), you learn why the warnings are there and avoid these problems in the future.
> It will make adding features easier once the debt is paid off.
I'm not so sure: DJB-style secure microkernel/microservice architectures are hard to extend, and I have little hope that today's monolithic code bases are securable without retreating to a small, proven, and well-tested TCB--even by ASI.
The original technical debt, which cannot be paid off, was the decision to use a Von Neumann architectures instead of a Harvard architectures for CPUs.
Basically, have an explicit distinction between data and code at the architectural level, to enforce "Write xor Execute" in hardware. In this way, you would prevent e.g. a buffer overflow letting an attacker injecting shellcode that gets executed later by somehow pointing at it. AFAIK the issue would still remain with some programming languages though.
and it's not sufficient anyways. even with NX you could have the attacker control a function pointer you call. in any sufficiently complex program you'll have enough widgets to build anything you want just out of data.
code and data are the same thing. whatever inputs your system receives is "code" that your application interprets, just like your application is the code that the CPU interprets. turtles all the way down.
There is no fundamental distinction between code and data. This separation does not exist as category in actual reality (and I vividly remember that being one of the bigger points GEB made, early on). They're fundamentally one and the same, and classifying some bits as data and some as code is a point of view that really depends on what you're doing and why.
As for Harvard architecture - every time you branch on your "data", you're effectively executing it, and your "code" can be seen as emulating a system where your "data" is the actual code.
To clarify what intrasight is talking about: A Harvard architecture CPU has two physically separate memory busses for code and data. This makes it possible to build a computer with a program memory that cannot be altered through the data bus. In practice, this isn't normally done -- even on Harvard architecture microcontrollers, the flash and RAM are connected to both busses because memory is expensive. And having inalterable program memory doesn't save you from stack-smashing attacks that alter a return address.
All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.
Code and data being equivalent is a consequence of Turing completeness; you can always write a Python interpreter, point it at "data" and have it execute that via interpretation.
> All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.
Says you. I wrote a program for a Hardvard architecture chip (PIC) that read bytecode from the data memory and executed it. Updates were made by replacing the data block with a new data block.
In practice, there is no way to separate data and instructions. After all, JS downloaded inside a webpage is literally data, and it gets executed.
Wait, how do you create programs then? How do you compile?
That doesn't even make sense, to be honest. Interpreted languages like Python aren't running machine code. They are taking data and executing machine code based on the data. Is Python safe?
According to Wikipedia, Modified Harvard Architecture is a common thing and appears to have properties of both Harvard and Von Neumann architectures. It's probably worth discussing a specific device, OS, and programming language rather than having a vague discussion where both parties are constantly describing different goalposts.
It's not that hard to imagine that in a specific embedded device the kernel / compiler have access to write to the instruction memory space while user space programs don't have any API / permissions to do that.
I see. I guess this does solve the issue of a program managing to insert arbitrary machine code on an address and point the CPU at it, or replacing the memory where the machine code already exists. But I think there already exists OS-level protections against writable executable memory?
It also doesn't solve one important attack vector: the existing executable has logic that can be used maliciously (e.g. a function that sends a file to the internet), and this logic is executed based on data on memory. In this case you only need to manipulate the data, without manipulating the "code", in order to exploit it.
I'm not sure I understand why would you need special hardware for that.
I think that the principle of "code is data" is that data influences the algorithms either way, so there is not much of a point in separating the two.
This sort of thing is much more common in microcontrollers, where the code is cross-compiled on another computer and written to flash memory through a debug interface.
In practice, it's usually possible to write to the embedded flash memory via software, but it's much more difficult and disruptive than a simple CPU memory access.
A compiler writes machine code do a file. The OS then loads the code from the file into executable memory before it runs the program. The compiler isn't actually trying to execute the machine code it produces. This is why a JIT wouldn't work - the JIT bypasses the interpreter and produces machine code _that executes directly on the CPU_ inside of the same app.
I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.
Yes, and that's my doubt. Compiling is turning data (text) into code (something executed by the CPU). I thought the point of the hardware is that data can't become code. If data can become code, then data is code, and it doesn't matter if the data is compiled first or interpreted at runtime. There doesn't seem to be a way to prevent "data" from becoming "code".
This argument is much worse than "we should have made functional programming the standard back in 196X" (which might some merit but overdone imo). The Harvard architecture is just a hardware separation of instructions and data - the argument is virtually an urban legend. Hardwave code/data separations are relatively easy, have existed at time but change nothing since dynamic language just makes its code into data and the self-modification is unhindered.
Separating the call stack (and probably inventing a very specific "the only valid reads/writes in this area are the ones made by the CALL/RET instructions" permission bit for it) from the data stack would make almost all buffer overflows useless for taking over the control flow: the normal STORE instruction simply can't overwrite the return address, period.
Of course, the interpreters would still be vulnerable, but even for them having separate (and distant) stacks make this particular vulnerability much harder to exploit. And again, a generalized technique having different processor instructions for manipulating differently "painted" memory regions would help there too — at least, it would be there so the implementers of the interpreters could reach for it if they decided to.
In the end, of course, nothing can save you from having a program that insists on literally doing eval(fetch(url=input())), or curl "$(read ; printf "%s" "$REPLY")" | "$SHELL", or something else to this effect.
Given that there were no mothers in the Garden (other than arguably Adam who gave birth from his rib), the maternal mortality rate was undefined behavior (0/0). Which checks out -- what did they do during all their time in the Garden, anyway? I guess now we know that we cannot know, and that Lilith must have been of the nasal variety.
Modern CPUs already split code and data between two types of L1 caches. So they are technically both "Von Neumann" and "Harvard" simultaneously.
It's also missing the point because modern buffer overflow exploits no longer write code into the stack, they overwrite the return address on the stack and assemble jumps to the end of functions known as "return oriented programming", but the underlying issue still applies to function pointers on the heap.
the equilibrium state would be having found a good pattern for making patterns good. we probably aren't too far from that, so i think your worry may show up in the short term but not the long one
that would do it too, and i suppose people are working on that. but even without that, there arent infinite low hanging fruit problems to find, and any given code can just sort of be play-doh'd into other code. so the llms will need a few idk years worth of rounds of being trained on the things that pop up that wed never have the time to harden, and things will settle. like, its hard patching stuff up quick right now but we're managing and society hasnt fallen in to chaos.
> Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work?
My problem with even talking about this is that there's absolutely no evidence for it. The idea that coming up with a technology to find holes in the hulls of boats starts with a flurry of holes being found and a bunch of patching to be done does not even hint at the theory that there are an infinite number of holes in all boats, and now that we can find them we will have to spend the rest of our lives patching them.
Code was bad, and we knew it was bad. We would have found most of these bugs if instead of coming up with LLMs, a bunch of countries got together and decided that they were going to put $10B into hiring programmers to do nothing but review all the code in the world for bugs. With AI, we managed to do it for only a trillion dollars.
Max AI-glazing perspective in the title, as expected. We need to fix bugs that no mere humans could successfully find and exploit. Thankfully we have AI that can fix those bugs that wouldn’t be a problem without superhuman code agents.
But there are potential upsides like the already mentioned possible nation state exploits (sleeper exploits).
While I have mixed feelings about AI's impact on my work, I am happy that I can address 5-7 years of technical debt in code bases as I come across it due to AI lowering the cost. Typically the solution is not too difficult; it just required a lot of time in research and testing which AI streamlined. I am able to verify everything at the end ran through the proper test cases and that the fix is what I expected.
I just can't understand that anyone is seriously thinking that AI is improving the situation when it comes to tech debt instead of making it way worse.
For every bug or security issue it fixes, it creates 10 more.
if you have problems to "For every bug or security issue it fixes, it creates 10 more." degree then you are using it badly, or on wildly different code from where I tried it
Having worked on both sides of the table, the reality is that it is far too easy to game certs like ISO27001. The risk calculation by companies taking that route is changing right out from under them thanks to Ai tools.
These certs only exist for compliance, not for security. Nobody cares they don't add any extra value, because they allow every business to say "my supplier was ISO certified, so I did my due diligence".
And nobody really ever gets prosecuted for lying during their audit.
It seems like you've never tried to get it. ISO27001 is a security certification. You will not pass the independent audit if you're bad at security. You will not be recertified if you're bad at security. You can say this for other, non-prescriptive certs, but not ISO27001.
> You will not pass the independent audit if you're bad at security.
I wouldn't agree with that. What I would say is that to pass the audit you must appear to be good at security. More to the point, you must appear to be doing many things that most companies don't actually want to do.
I worked at a place which got ISO27001 yet had its proprietary source code available unauthenticated from an old CVS server, including over HTTP. You just needed to connect to the wifi or plug in any Ethernet cable into any device. The company just did the magic “accept the risk” and moved on. Anecdotal but I can’t help but feel it would be common for other orgs which are bad at security getting certified anyway. https://youtube.com/watch?v=9IG3zqvUqJY
I have. What I wrote was based on personal experience working for an ISO 27001 certified company and being very involved in the (successful) audit and recertification.
> You will not pass the independent audit if you're bad at security.
Incorrect. You will pass if you have all required processes documented and have documentation that show you follow those processes. Whether you actually do follow the processes is irrelevant, the auditor just needs to think you do.
Also, you can be incredibly bad at security and still be ISO 27001 certified. For example:
Process: Describes that employees use an encrypted password vault for secret management. Keys in the vault are rotated each year and when employees leave.
Reality: Keepass database is sent through email, the password is "CompanyNameVault2023!", which is shared in the same email. Keys are never rotated because it's annoying.
This will 100% get you ISO certified, in my experience at least.
The auditor will require evidence of password rotation and take that evidence into their report. I don't see any way an audit could pass lacking this evidence, on either end here.
I've been referring to this as honing a codebase (like a knife). I've used AI to vibecode sloppy one-off scripts, demos, and proof of concepts. But then I've turned around and used it to hammer in actual projects to a level of quality I just would not have had the time or motivation to achieve previously.
That is a choice I make every day when I get into an argument with Claude about the chosen design and how I find it insufficient. Does it slow me down? Sure, a little. But at least I know the foundation is bedrock instead of sand.
We could rephrase it like this: “AI has removed all the excuses we had not to remove technical debt”
Yes, AI developed code might have vulnerabilities or bugs, but so already has your JSP based web server that has Oracle and God knows what else among dependencies.
I invested in an AI security seed fund started this year exactly because everyone knew that was in the know on the matter all thought we were about to hit a wall of major security problems.
The biggest monetary risk is obviously is the frontier labs, and the variability of seed companies in general, but I really just can't wrap my head around the frontier labs being able to communicate with all the businesses about their individual security needs.
Companies that just do Red Team simulated attacks to find and expose tech debt are going to be critical to literally just communicating these vulnerabilities to management.
I think the real issue we are facing isn't the 40 years of tech debt, that's obviously real, but the real issue is communicating to non-technical management of companies of basically any size that they absolutely need to prioritize this stuff. People don't understand that we're going to live in a world where every single 0-day is going to be figured out in 48 months, and it's going to be easy pickings if you don't take this stuff extremely seriously.
We are in still in the the good ol' days of AI. Like the internet, there was usenet, irc, blogs, slashdot, slackware, archie, gopher, ncsa mosaic. Now we have reddit, discord, facebook, tiktok, chrome. The early adopters build a community, then everybody else shows up and turns it to shit.
It will happen with AI and it won't be pretty. It will stop being useful and start being annoying and turn to outright danger. Fridges spoiling food is only the beginning.
Where LLMs as a genie are being forced out of the bottle early, the size and scale of it can like only be met by the same tools, better used and equipped and directed by humans vs the LLM iterating until it seems to work.
> The apparent safety of a tool-AI, meanwhile, may be illusory. In order for tools to be versatile enough to substitute for superintelligent agents, they may need to deploy extremely powerful internal search and planning processes. Agent-like behaviors may arise from such processes as an unplanned consequence.
In my experience it seems like it finds one bug in an area then kind of gives up and goes somewhere else, and I wonder if it has to do with how training works; if they're deliberately setting up single bugs per area, so it acts most "efficiently" when it stops work in that area once it's found "the" bug.
> Is it a big deal considering AI is actually helping patch most of them anyways?
Double side sword. If you were the creator, the owner of the source tree, easy win. Why not. You know what it will change and the states changed from it.
If you're someone with no understanding to the code has been tasked with "use ai to fix bugs" that is where the trouble starts. When you don't hold the full knowledge of the source tree then you should be shy in using LLM's to fix bugs.
How do you know that bug fix doesn't cause issues further up-stream?
we're seeing easier PR approvals when AI is involved. Since changing the code in the future is a lot easier.
Instead of a highly structured engineering process it's more like a gardening process of figuring out what works, what doesn't, what the Business actually wants vs what their requirements were
So more debt because there's more code but it's easier and simpler to change that debt. And in 3 years the product is EOL so shrugs
Not necessarily and most likely not. I think a lot of people's definition of "fixed" is "stop hiccuping in the previous way so that my butt is covered" and not "yes, it actually works and was given the proper time and testing to ensure that remains true."
Developers would do well to remove the word fast from their vocabulary. It has done tremendous damage to human systems (and the mental well-being of the people dependent on those systems). The whole reason the "technical debt" exists is because there's an addiction to speed. The sad part is that when you poke at that with most people, they couldn't give you a clear reason as to why they need to move fast; just that they have a sense that it's "how everyone does it."
As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Everybody in the industry knows that we've been building on quicksand. Moore's law meant that we could just sacrifice performance and add a dozen layer on top of technology from the 90s (if not older) and keep the thing chugging along.
Look at the PHP situation:
- HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays and might be better left off to higher layers. But of course, we can't break compat, so everybody still implements all the naughty parts, just in case.
- PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people. Cue the PHP fans telling me that "it's good now". Maybe, I don't really care, the effort that went into making it good should have gone into ditching PHP for a better language 20 years ago. The bandaid mentality is what got us in this situation.
- And of course to add insult to injury, PHP, this security-critical language, is still implemented in garbo C using things like setjmp/longjmp. Just to make sure to absolutely maximize the damage if a vuln is discovered, I suppose. Brilliant.
- Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.
We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.
Of course the reason things are done this way is generally to maintain backward compatibility and make transition easier. At least now that we have LLMs this excuse will hopefully vanish: porting even huge codebases to a new language/framework, something that was a tremendous undertaking mere months ago, is now vastly easier and faster. We can leave the 1990s behind us.
> We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly
I think you have things backwards. Devs aren't clowns who make it this far. But in industries where buggy code doesn't kill people, devs are expected to ship fast and iterate, because they can and more importantly, it serves the business.
Personally, I'm all about good software engineering principles, unfortunately I don't think you can last long in most companies if you're too opinionated about this and can't compromise (and it's getting even worse with AI, reading the code is no longer a requirement, go explain your teammate that there's an abstraction leak in their code...).
Yes... there are statisticians on my team, for example. They're capable, thoughtful individuals however have little exposure to the oblique and (outwardly) contradictory ways in which production software fails.
But explaining that openly, as is your duty, means surfacing something which could be read as 'bad work' by a non-technical manager unable to grasp the complexity. So in low-trust teams it very quickly becomes a game of brinkmanship, or a prisoner's dilemma for technical diligence
I am currently in a stalemate where I have written a proposal that is very technical. The only “business” outcome is that we clean up a massive security mess and rebase on a new consistent architecture.
My manager can’t understand the RFC, and knows that clean up projects aren’t palatable to his senior eng leadership so he keeps asking me to simplify or derive some business justification. I’ve proposed superficial ones like improving security posture etc but he wants a hard number that can be measured (yet another senior leadership mandate).
I’m kind of exasperated and honestly think it’s his job to figure this out.
You've uncovered the kernel of the software industry- if it works well enough, don't touch it. This is why legacy software hangs around for longer than it should.
You first need to assess the risk of the current setup, and explain that the new setup will reduce the risk (which you may be able to express in monetary terms).
You really think it’s wrong that you need to show how it will save money in the long run? Why do you care if the software is poorly written? Because you don’t like fixing bugs? Why should they care? If you care then you need to give them a reason to care. I am not saying it doesn’t matter, I am saying you can’t just expect them to agree to do it because you don’t like it. And it seems like that is what you are saying. “Because security” is not an answer. Everything can be made more secure. Show them the risk and impact.
It never ceases to amaze me how common this situation is, where a quantifiable compromise is clearly the answer between engineering and leadership, yet none is presented by engineering. No party is ever inherently trustworthy, we all need quantifiable reasons to make decisions. I've never unquestionably trusted leadership, so I've never expected them to trust me.
I've been in plenty of meetings with non-technical folk who basically shut their ears off whenever anyone brings up explanations for things like why security matters.
I now work in a highly regulated field (payments/banking) and it's a bit better, but from prior experience if there's no regulator to beat people with, they will simply not give a shit, the only thing they want is to shove out whatever feature as fast as humanly possible.
As an example GDPR was a godsend because I could finally convince people to get rid of the 11 trillion stupid analytics and tracking bullshit we had "Because GDPR", whereas no number of arguments, no matter how well researched and presented, would ever convince anyone before
I also think it’s fair to expect that non-technical people learn some technical reasoning. They don’t need to be engineers, but IMO it’s completely ridiculous that we just let anyone who is business-adjacent off the hook for not knowing anything.
Business people should understand, at a high technical level, how their products work and what they’re actually asking to implement.
I’ve worked with many great business analysts and product people and consistently the best ones are the ones with the “engineer brain”. They might not know how to read even a single line of code, but they understand software products from their pieces. Those people consistently propose high-quality and feasible solutions. Other business people do not.
As developers, we are expected to constantly think on our feet and adapt. We learn new products and methods on practically a weekly basis. But for whatever reason, the business folk are not even expected to understand the product they help build. There’s such a large disconnect there between dev and business.
Yep. I recently had to convince management to let us fix a legacy CloudFormation template that was brushing right up against the AWS resource limit for a single stack (which also means it was WAY over the recommended limit for a production stack). It had been causing CFN to occasionally choke on a deployment for over a year, and it was just a matter of time before we either added the resource that pushed us over the hard limit, or CFN choked on a deployment and failed to roll back to the last good state.
The director of my department kept asking, "But do we HAVE to do this now?", so my final answer was this:
"Do we _have_ to? No, but it's like a bridge. Bridges have an expected lifespan when they're built, and they're supposed to be torn down and rebuilt after that. It's not a HARD limit, though. The bridge doesn't immediately collapse the day after its lifespan, but there are fault accumulating. Metal fatigue, erosion of support material, and other things. Commuters can't tell the bridge is past its lifespan, and they'll continue crossing it every day without issue. And then one day the issues will accumulate to the point that the bridge fails and people DIE. That's the situation we're in with this stack. It will continue to function just fine until the day it doesn't, and on that day I won't be able to tell you how quickly we'll be able to recover the application stack, if at all."
> The director of my department kept asking, "But do we HAVE to do this now?",
If someone says that something is a risk and we should address it, I don't expect a director to ask for a specific date the risk to become a disaster. Instead, he should just add it to some todo list and slot some time to analyze it and and budget resources. AKA, doing some "management" work. You shouldn't have to explain his job. You didn't need to learn semiconductors physical properties to know that storage can fail and you need to do backup.
And they’ll ask for the probability of these outcomes to find the expected cost. And you’ll struggle to give one without heavy caveats, and thereby lose perceived credibility.
Honestly, in traditional engineering firms it’s not the job of the mechanical engineer to quantify risks monetarily, and it shouldn’t be in IT either. It’s other people’s job to turn "without urgent repairs, we’ll have to put severe tonnage limits on this bridge or close it altogether or risk collapse" to the cost of inaction in terms of economic loss.
You could make an analogy to getting a flu vaccine. There's a small up-front cost, but you're making a bet that it will prevent or reduce the severity of a larger issue down the road. There's no guarantee that the larger issue would ever occur, but "getting the vaccine" makes it less likely to occur, and less costly if it does occur. Skipping the "vaccine" is a reasonable choice if the business is willing to incur substantial damages in the case of a large event in the future. To put hard numbers to it, you could always show numbers like "X% of our customers are likely to leave if we leak all their data to hackers", and base it on documented examples from recent history.
The problem is the "interface" of software engineering being oblique to outsiders. It's alchemy in essence.
The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the current mere pretense of software engineering into reality, making the engineering part explicit.
That in turn only works when humans actually understand what they're doing and can communicate it to outsiders.
It seems straightforward to present the tradeoff in a formulation that statisticians can understand, eg. the expected value of an 80% correct solution that ships now is higher than a 100% correct solution that will take 3 months. The opportunity cost of the extra care often only really pays off for security-sensitive code, like crypto, where the cost of failure is potentially catastrophic.
Thank you! I entered the industry a lot more meticulous, test driven development, integration tests, end-to-end.
But shipping faster was pushed at almost every company until, if it's not revenue generating, stop putting resources into it. Not all are like this but it's not all or nothing, it's always a sliding scale how much you can put into making the software correct.
I'm a software artisan deep down but I could never justify putting too much time into making the stuff I used to build "clean and fully maintainable". I tried, but eventually I realized that if I didn't get things out of the door, my company would start losing money and I'd lose my job. Who cares about perfect software in a bankruptcy auction?
There are things you buy out there that don't need Swiss quality because most people will simply not need the quality or won't have the money to pay for it.
I think the biggest problem isn't that a random webpage is sloppy, but when a critical system that could kill people is built the same way as the random webpage.
I hear you, but humans are incredibly bad at context switching like that.
Near the point where things become minorly safety critical, people will blur the line. The point where safety kicks in moves a little further out, and we start blurring the lines again.
There’s a reason the FAA is anal-retentive about things with only very minor safety implications, like the in-flight entertainment system or turning on airplane mode. It helps prevent complacency where it actually really does matter.
You either do it the right way 100% of the time, or I’m not taking bets that you’ll do it right on a particular occasion.
> eventually I realized that if I didn't get things out of the door, my company would start losing money and I'd lose my job.
This is like 90% because most tech is different enough that civil torts don’t exist for them yet, so they don’t have to care.
Eg if Google deletes all your photos they kind of just shrug and you’re out of luck. If I deposited photos at a bank who burned them without notice or approval, they’re on the hook for that.
The law will eventually catch up and acknowledge that bits can have value. Then everyone will have to care again.
You are describing my field - Systems Engineering.
We track EVERY requirement to ensure it is met. Maybe it's a safety issue; maybe it's landscaping approvals (I work in Rail). Regardless, it's bigger $ if not caught up front, and if you start grading requirements on perceived risk, you start the slippery slope to not caring. Example: mark all landscaping requirements as "Not Critical". Then scheduled clearing of the right-of-way is missed. Then pedestrians are at risk with blocked line-of-sight, and trees might drop across the rail.
I can't say I disagree. How it is with engineers they get certified as PEs due to the responsibility they have. In my mind it be similar, you don't need everyone engineer certified, but if you over X revenue or employees side it should apply, and be required to have Y numbers of certified based on company size. Then the companies like with their lawyers, will have to figure out how to follow the regulations and push forward.
I think this is good thinking. I work for a state agency that deals with construction codes and licensing of building contractors, electricians, etc. If the safety of the web is in such a critical state of vulnerability as to potentially impact what the article author terms "normal" non-tech people, maybe there should be some certification that is government-regulated like you suggest. Or maybe that'll happen after real (not potential) devastation occurs - that's how building codes came around.
I don't understand. Do you people just figured out how to write good software? Not long ago, 70% of projects just failed. Not were written badly, but just weren't completed at all. I don't know current number. But looking around me, it's so obvious that we don't know how to write good software. For a reasonable price anyway.
What that PE certification will check? That guy knows how to write unit tests? Well, that's not much. Who will write certification? Where's that genius, why he's hiding from the rest of us?
Maybe building is figured out. I don't know. I still see bridges failing and buildings crushed, so apparently it's not perfect. But I do know that programming is not figured out. Absolutely not. We can apply tremendous effort, pay billions and produce some simple firmware which can be uploaded to a martian rover. But that doesn't scale to the rest of industry.
Then when company forces a product to skip safety checks, test units. And the PE proves the did their but the company pushed forward, the company gets wide open to fines and lawsuits.
Make a company responsible and hit their bottom line, other will think twice before they say "just ship it, or I'll hire someone cheaper to do it". And no they don't say that, that's how it's done.
When your paycheck or livelihood is on the line, you tend to slowly sacrifice the principles.
I think your being short sighted here. And a aggressive for no reason.
Shipping bad software does not serve the business indefinitely. Application/product security was expensive relative to its perceived value, so it was underfunded nearly everywhere.
Completely agree, but the problem is that the execs don’t understand that. People at the leadership level don’t truly understand or prioritize technical debt. Paying down the debt can be really hard to sell to leadership.
Look at the solo projects from professional devs with nobody overseeing them. Look at what so many of your colleagues submit despite the frustration of your thoughtful team lead and manager. Look at what your so many of your team leads asks for even when they've been granted full discretion. Some select few are great, but most are disturbing if you have any sense of quality or preparedness yourself.
Even for decades before AI, there was lazy naive misguided slop everywhere. During the social coding era of the last 15 years this even amplified itself, streamers and influencers and conference presenters -- professional developers themselves -- would share horrid practices to wide applause. Moving fast and breaking things was what developers were excited about. Rigor was dead. Correctness was a problem for later. Code was presumed best written by a rando on github who'd accumulated a lot of stars rather than by a known responsible hand. Security was a copy and paste job from Stack Overflow, not something to be comprehended and considered.
If only it were a top down problem from outsiders!
But the truth is that the call has been coming from inside the house all along, and the outsiders giving direction have had no problem finding celebrated industry "experts" and "thought leaders" affirming and encouraging all the clowning they could imagine.
Developers could always move fast and do things right but most just didn't have any interest in learning how, and many of those who might have just gave up on bothering.
Thanks for the counterpoint. It's true that being sloppy and taking shortcuts isn't always a calculated business decision and it can be a lack of skills.
Businesses would definitely love great code if they could have it fast and easy. The problem is that they can’t. Developers tend to believe that they could generate perfect code if just they were given enough time. Well I have given my team infinite time. I tried it, do you think they delivered perfect code? Of course not. First of all if you don’t stay really close to everything they do, they will spend all their time on useless stuff like setting up their editor instead of using a readytogo IDE that actually speeds their work up, or testing things that will probably be thrown away a few weeks later when we decide that the strategy we were trying to use didn’t really work, but still require lots of time to “refactor” into the completely different thing we now need. Even when they do build the right thing and focus, more time simply does not equal more quality, it can even get worse at some point as you again get lost and start veering off on a tangent and forget what the business is actually about.
In fact, I have myself spent years on solo projects with the goal of making perfect software. You know, nothing like getting a few users to quickly destroy that idea from your naïve brain. You can’t write perfect code because that is nearly impossible for most of us, no matter how hard and how long you try. Think of it like this: can you beat the greats in your favorite sport or hobby? Probably not, you may be good at a small team level, but at a large city level you are almost certainly mediocre. This goes for your coding skills too. How many great developers out there creating great software we all know and use and love? I know a couple of names, that’s it. Most of us are writing shit enterprise applications everyone who is forced to use hates and that has more bugs than PHP in the early days. And when we try our own thing it’s even more horrible. Show me your repos and let me se if you’re the genius you think you are. Oh of course, you don’t have time to spend on hobby projects since you have a life… great, enjoy that, but don’t pretend you’re able to paint the Mona Lisa just because you spend all day with a brush in your hand striking on a canvas that no one can really see and if they did, it would most likely be a repulsive, incomplete, bug hidden piece of shit.
Just take a look at some of the opensource academic, infrastructure or "passion-projects", where there is no management pressures to "move fast & break-things" and ship-ship-ship. They tend to be very stable, very predictable - and very high quality.
I've seen software that academics write. It's no better than average. It's often cut-and-paste code, or these days AI slop. Software is a means to an end in academia, rarely a product in itself.
> They tend to be very stable, very predictable - and very high quality.
Some of them are, most are not.
Actually, most FOSS stuff is anything but stable or predictable. Instead it is constant treadmill, broken compatibility, and recently, thousand of commits from claude et al.
I agree... many people seem very purist. But I think it depends on what you're doing. Some things make sense to do fast and cheap. I work helping fundraising, and it's often better to have 95% solution that is delivered on time than a 100% solution that comes out after the campaign has ended for example. Management should warn us ahead of time and give us the time and the space to do it right, sure, but how often is that reality? As long as it's a conscious trade off I think it's fine.
Wow, it’s almost like it’s really hard to get everything perfectly right and this is endemic to software, particularly when the language accepts incorrect code.
The only two things we know mitigate this are proofs (eg rust borrow checker, lean, etc) and DST which is basically the equivalent of accelerated time testing which is done in other industries too. Most people don’t even bother with property testing
simias referred to the industry and you took it personally.
Why is it whenever someone mentions the shortcomings of software industry, there is always a comment saying "no no no, developers were just following orders!"
Because systemtic problems are often better explained through structural relationships rather than personal failings?
I don't disagree with the point that a lot of software that isn't pressured to be shipped quickly still ends up following bad practices, but I don't think we can ignore that the quality issues in software aren't also found all over in many industries because of profit motives?
He spoke of a clown industry. That means the industry as a whole. That includes, but by far isn't limited to, the devs. Which of course have to operate in an environment, most of them set by their employers. And of course, responsibility scales with the position in the hierarchy. So yes, to a large part it is the management setting deadlines, budgets, staffing and planning allowing for technical soundness and of course safety and security.
But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
It's coordination problems and large scale distributed action, not some moral character of how serious the people are. Effort is not fungible. To make php good, you only have to act at one point, in a localized way, at the php foundation. To ditch php, you have to act in a coordinated way across any resource strapped companies and individuals. Just see how hard it was to ditch Python 2 or how ipv4 is still not ditched.
Trying to understand underlying reasons and incentive structures is much more productive and useful than simply venting about the worse moral character and seriousness of people in one industry vs the next. Curiously, the grass seems always greener - when you ask people in other industries, you'll often hear endless complaints about the state of things there too.
It's a market thing too. Company A tries to write perfect code. Company B tries to write something that the users don't hate. Company B wins in the vast majority of cases. Especially when company A these days is stuck with a huge space to investigate.
This isn't unique to coding, but coding has been built on it for decades, with the "safety valve" of "who has the time to check all that?". So defcon speakers and intelligence agencies burn time investigating for weak links that might take months to find, and the rest of the world churns on.
Now you have companies throwing thousands or millions in compute at problems just checking EVERY possible problem and yeeeeup, looks like there's a lot of "good enough, ship it" which is now a major problem for all those companies using that tech.
It's still going to be interesting to see how this develops because, yes, there's a lot of code being written by people who haven't even read it (although the amount of enterprise production level code I've seen that's bad stack overflow copy paste makes me less worried about this), and there's maybe better tools and standards to catch these things (why not spin up a test suite if it's an afternoon of AI poking rather hiring a dev and getting them up to speed?).
You exercise every code path with a unit or integration test.
I tend to write integration tests for the paths users take through the application (website), and fill in the holes with unit tests. I'll also write unit tests for methods that change often or are critical, such as business logic.
> PHP was a joke language from the start.... Cue the PHP fans telling me that "it's good now".
First, I am not a PHP fan, but I will absolutely stick up for the "its good now".
Yes, absolutely no debate the old PHP 4.x/5.x was shocking. However to give PHP their due, they absolutely did make serious efforts in 7.x/8.x. They deserve due recognition for that.
Unfortunately lots of people – I'm guessing you're one of them – still have battle-scars from 4.x/5.x and they think (incorrectly) that 7.x/8.x is "more of the same".
Second "joke language", well, cast your mind back to what else was available at the time... ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
Sure, to borrow your terminology, the Java fans will be along soon to tell us all how awesome Java is for the web. But many of us still bear battle-scars of the horrors of Java stacktraces, messing around with incomprehensible XML config files, Java's penchant for eating RAM for breakfast, and generally trying to figure out why the hell Tomcat is not working (again !).
> ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
Pffft. VRML is the whole game, baby! Once everyone runs out and gets an SGI oxygen, Nobody is going to use freaking web browsers ever again. I mean, HTML, what a joke.
Also, ASPX (so ASP.Net) was a vastly superior technology to PHP. It was my first love, and I ditched it for Ruby on Rails, but ASP.Net was really good. Especially when you ran it on Linux using Mono.
The previous post probably should have said classic ASP, not ASPX.
Classic ASP was the more direct competitor to PHP, while ASP.net came along later, as part of a next generation of web server languages/frameworks/platforms.
Don't clutch those straws too tightly, you might drop them. ;)
Seriously. You're moving goalposts. I think we both know how popular Log4j is and how many millions of Java deployments that Log4j vulnerability affected.
Wait a second, in very recent years the major Java projects I touched were still messing around with incomprehensible XML config files. Has that actually changed in some part of the industry?
Yes, when I started getting into Spring(Boot?) in 2013-14 I was complaining about the annotation magic that you needed to sprinkle around the code, so that you could have a Java project take a long time to start up and fall over. The response at the time was that it was so much better than the old XML way that you "had" to do. So that kind of XML hasn't been needed for 10+ years.
Unless you count the XML dependency management with Maven, which isn't too bad.
> Has that actually changed in some part of the industry?
I suspect the only thing that's changed is that Oracle now charge you for the pleasure. ;)
More seriously though, its been a long time since I've touched Java, but I suspect the only thing that's changed is that its all hidden in magical kubernetes containers these days.
Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle. Many things have changed in the Java world. Kubernetes doesn't have any special relation to Java.
> Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle.
Congratulations Java Fan on missing BOTH the smily-face at the end of the first phrase AND the "More seriously though" at the start of the second.
I'm glad someone still loves Java though. ;)
P.S. The kubernetes reference was – since that one appears to have gone over the top of your head too – that in todays world Kubernetes is extraordinarily popular and therefore it is likely most people now hide the complexities of Java deployment into a container that is magically generated and deployed through CI/CD. Hence I was inferring that life is probably "easier" today with Java because you just deploy the magical container.
PHP had a super power - it was pretty stateless before that was cool. Thus, it is easy to understand and it's easy to scale. And a lot of it is basically transforming SQL columns into JSON or XML text. I used to laugh at it but now I just shrug. There's much worse things in Node-land.
CVE-2026-109618 is evidence that it is absolutely not "good now". To make a pro-PHP argument the week that PHP's shortcomings just cost half the internet millions of dollars of lost time panic-patching an RCE is... an interesting choice.
>CVE-2026-109618 is evidence that it is absolutely not "good now"
That's a C language error, not a PHP language error. I don't see that CVE as particularly different from when they showed python's dictionaries could be attacked using dictionary hash-collision (something that also affected PHP). It's worse in being remotely executable, rather than merely a denial of service, but it's ultimately a facet of the C implementation rather than something wrong with the language itself. CVEs, even remote ones, will happen. Even java had its logging execution attack.
I've made fun of plenty of things in PHP over time, but the language hit the mark it was aiming for initially. It was easy. A 12 year old could sit down and write an ugly little forum and it would work. Because it was easy for amateurs, a lot of amateurs wrote in it, and there's a ton of clumsy code out there. Because it was easy to setup and run with minimal setup, popular packages were very popular. Wordpress vulnerabilities matter because it was very easy for programming chop shops to hack out tons of websites for all the millions of little businesses out there that didn't often follow up on patching etc once that was done. PHP was bad largely for the same reason BASIC was bad. It was easy.
PHP being easy gives it a huge blast radius for anything that goes wrong with its implementation or popular frameworks and libraries.
Perhaps C isn’t the right language with which to implement PHP. C is bristling with foot-guns. That implementation choice is still the responsibility of PHP.
> We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance.
What industry do you think is different?
I've had a decent amount of construction work done on my house, and if I had a pound for every shortcut that the guys doing the work took, it would pay for the work they did. And these are the _good_ ones. The bad ones don't even bother following the legal requirements. Somewhat recently [0] it was found that less than half of healthcare workers followed recommendations on _hand washing_.
Residential construction isn’t much better. But the people who build the really tall stuff, the structures that would kill people if they collapse, that’s real engineering. The odd bridge that collapses is usually a political problem (lack of funds for maintenance).
Go hang out on a subreddit for electricians, or plumbers, and in any thread where they talk about the professional side of it, you'll see a consensus that all the work is awful, done with no regard for professionalism, and that if there was just more support for doing it properly they would. Just like here.
There are plenty of software projects that are managed to an incredibly high standard professionally - OpenBSD, PostgreSQL, Curl all come to my mind pretty much immediately. Linux is probably the closest thing to "skyscraper" development and has been going for 35 years at this point.
I use to joke about PHP in the early 2000s, but now that I see the "better languages", I am starting to like PHP.
If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.
PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.
As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.
Yeah PHP was the first time web applications really "clicked" for me because there were not a hundred layers of abstractions between the html page and the application code. I was new to programming, and I took a look at J2EE and its literal million lines of code pet store that was supposed to be the shining example of how to do J2EE right, and I was like wtf is all of this... PHP though it was so easy to just make a page that gets some stuff from a DB, does some stuff with it, and outputs the result. I didn't need to read a 500 page book to get started with it.
In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
Having lived through that era, J2EE was ultimately a disaster. I remember an "entity bean" (terrible name for a class that manages data persistence) requiring multiple java files and at least a couple XML configuration files. It was complete madness. It was slow to build, slow to deploy, slow to run.
PHP's other advantage is deployment: it's simple. In the 2000's, I used to work at an enterprise Java shop but also did PHP freelance work. The amount of bullshit you had to go through to deploy a Java app on JBoss was insane.
> None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now.
Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.
Verbosity and architectural complexity matter to a coding agent. LLMs have limited context windows, and the less verbose the code, the more you can fit in there.
Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.
Ish. I remember when the earliest versions of Rails used a CGI runner. Development didn't carry on long before application startup time became so horrendously slow that it was no longer viable. That is when it started to become popular to add a server in the application.
Now that people are back to writing their applications in languages that aren't as slow as Ruby they've, in many cases, taken the server back out of their application and have returned to the CGI model again; what is often marketed as "serverless".
>We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people
Another industry does even better: the medical/health industry. It's both a clown industry AND kills people AND they have made it way beyond what software can only dream.
Having 25+ years experience straddling both disciplines, i.e. in both CS (Dev) and Medicine (as a licensed provider) -- and who currently works in frontier drug discovery, can wholeheartedly confirm both industries are a joke.
The big fun factor is the place in the Venn diagram where they both intersect. I used to work for a medical device manufacturer who's biggest and most popular product routinely had stack traces at inopportune times.
I have actually gotten a tremendous amount of value from PHP and WordPress: the via negativa! They showed me, in remarkable detail, how things should not be designed.
(I'm not kidding. If you take each element of their designs and invert it, you end up with a very solid design.)
On that note, I misspoke somewhat: I assert that PHP and JavaScript were not "badly designed", because that would imply that someone sat down, carefully considered how the different parts of the system interact, second order consequences etc. — and then somehow came to all the incorrect decisions. Rather, it's quite clear a serious design process has simply not occurred to begin with.
Once I recognized this phenomenon, I began to see it in all areas of life. Things are much worse than they could be, simply because nobody has designed them to be good. They just ended up the way they are now, by accident of history.
--
Polemic aside, I am fond of JS and PHP in many respects. I just think we should clean them up! "This mess has always been here, so it's too late to clean it now" would be laughed at in any other context.
We already broke compat with "use strict". Now we just need a "use sane" :)
> Rather, it's quite clear a serious design process has simply not occurred to begin with.
I don't think it holds with
> If you take each element of their designs and invert it, you end up with a very solid design.
The rule of thumb is "the inverse of stupidity is not intelligence". So, if we have an example where you can get a good design by inverting the bad one, we can't then state that the bad one was a result of a chance. The probability is very low.
I worked at a kitchen job one time. The place was, to use the tired phrase, full of toxic narcissists. People who didn't care about what was true, or good, but cared about shitting all over each other.
For example, in one case, the toilets were flooded, and they spent nearly an hour arguing about whose fault/responsibility it was. I snuck off quietly and solved the problem. (This offended them, presumably because then they couldn't bitch about it anymore!)
Anyway, I started keeping a list of complaints — all the ways that job violated my standards. At first, naively, thinking "surely if I show this to mgmt they will fix things!", and later, "ok, red flags list for next job."
At some point I realized I had actually created a spec for the perfect job, but with each term inverted:
Abusive assholes -> respectful colleagues
Total lack of process and communication -> a place that's actually functional and well thought out
Everyone hates their job -> people actually want to be there and enjoy what they're doing
Mindless drudgery -> creative and technical challenges
And so on. Amusingly, inverting the shitty kitchen job produced an almost exact description of VALVE corporation.
Anyway, I'm sure there's a term for this. Maybe "negative space"?
Oh I assure you, all industries are clown-driven, clown-built, and clown-maintained. Nobody has time to do things according to a retrospective analysis of "best" which will just be re-evaluated next generation. We build with what we have and fix when we must.
Another thing that has bothered me for a long time: we have far too many data isolation mechanisms, each with their own idiosyncrasies and trying to cover up for each other's gaps. Very very roughly, from source code up:
On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.
If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.
You have a point that there are a lot of separation mechanisms and that, if things were designed better, fewer would be needed but by the same argument it also seems unwise to increase the number of mechanisms to share data. Sockets by themselves are quite big enough on their own to quite literally drive the whole internet through.
A socket is just a raw byte stream. It's a solid base layer, but you'll have to implement your own communication protocol on top, and it'll require copying the data from one process to another. A "stream" is the wrong metaphor for local data sharing.
The data is already in memory and the source program knows its "shape"; there should be an easy mechanism to provide access to that by default, like /proc or gdb but for arbitrary data structures and with better UI.
One idea would be that the data structures that a program uses declare if and how they want to be protected/accessed. E.g., access levels could be: only accessible in a local code block, only accessible in one thread, accessible by a limited number of threads, persistent or not between program runs, accessible over the network by certain machines/people, accessible to the whole world. A tree of all data in a program/computer could be exposed subjected to such access control. I would think that this does not even need to cost performance because 'only accessible in one thread' would not have to be implemented in a way that is different from current local/global variables.
Non-technical managers don't want to wait for the 'nerds' to 'do it right' because that takes a long time and the nerds don't agree on how best to solve the problem because most capable nerds (who sort of know what they are doing) are working on lower-level problems and making the big bucks (they are not running WordPress for the local News Paper).
So that leaves non-technical managers telling non-technical nerds to just install WordPress. Then, AI comes along and wipes them out. And everyone is like... how did this happen?
And, we know how to write code properly if that's what is required. There are methodologies from avionics and other critical code where every line of code has an audit trail back to a requirement. Where malloc is disallowed. If you want to compare it to other engineering, there are skyscrapers and there are doghouses. Most software is doghouses.
This is not completely a bad thing. Using skyscraper techniques for dog houses is not sustainable.
The key is to identify when you are working on a skyscraper and when you're working on a dog house and act accordingly. To my mind, the boundary between the two is whether or not you are handling sensitive personally identifiable or financial data.
>Non-technical managers don't want to wait for the 'nerds' to 'do it right' because that takes a long time and the nerds don't agree on how best to solve the problem because most capable nerds (who sort of know what they are doing) are working on lower-level problems and making the big bucks (they are not running WordPress for the local News Paper).
>So that leaves non-technical managers telling non-technical nerds to just install WordPress.
Good summary of how the world operates generally everywhere. It's a clown world.
I'll generally agree, and I include myself in this industry, but we've simply have been bound by compatibility. I don't think anyone chose intentionally to keep the crap around; it was simply never worth it to pay the "break compatibility" cost, until now.
> Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.
The interesting thing is that memory bandwidth has become a big issue. CISC instructions take up less space than the equivalent RISC instructions, so you can effectively get more instructions per cache line. Effectively the CISC to RISC conversion acts as a type of decompression. Because if that, stopping the CISC messiness without moving to a compressed instruction stream would actually hurt performance.
One of the reasons the M series of processors from Apple can manage such a high instruction throughput is that the instructions are fixed length, which allows them to just be slotted into the multiple instruction decoders. The instructions compression provided by CISC in the amd64 instruction set means that the instructions do not start at predictable places, which makes it much harder to decode many instructions per clock cycle.
> CISC instructions take up less space than the equivalent RISC instructions
In theory CISC instructions take less space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
Absolutely. The industry could have moved towards safer languages, better coding methodology and formal verification years ago (see for example MISRA C as at least a partial movement in this direction). It didn't, because it was cheaper not to.
We've had Ada since the 1970s yet it was never widely adopted outside of DoD and even DoD has moved away from it. Why? Whatever that answer may be, and I think it is as much about the novelty-seeking of the software world as anything else, would likely tell us a lot about how we ended up where we are.
Your desire is not to build things on quicksand but your solution is to just throw LLMs at everything and rewrite it all? That's not the solution and causing even more rapid churn by ditching backwards compatibility is just going to exacerbate the problem.
This goes double when you add in the same non-technical-sourced pressures that caused developers to take shortcuts are still there, and now even worse with their unrealistic expectations for LLMs.
It's simply not realistic to expect the entire world rewrite its entire technology stack from scratch, starting at the transistor level on up every time there's a new industry innovation in security or performance.
LLMs might make this somewhat easier, but you're still going to have to deal with backwards compatibility and legacy systems. Completely eliminating the use of architectural cornerstones like x86 or HTTP or even PHP across the entire industry isn't going to happen anytime soon, let alone overnight, especially if the only argument for doing so is "we could design this better if we implemented it from scratch".
> to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
There's only one area I sorta give a pass, and that's mainframes. It takes an insane amount of physical servers to replace a mainframe. Why IBM didn't invest more into making mainframes a drastically better platform for devs is beyond me. I don't know that any other server platform has ever achieved the level of uptime a mainframe has.
Still, it is no excuse to leave them with ultra legacy code that remains unmaintained for decades.
Exactly. There was even a whole domain of expertise (SRE) that exploded because of the lack of engineering rigor. That's not to say if everyone did all the right things all the time there would be NO need for SREs, but there would be fewer of us - something that I've tried to communicate to everyone I've worked for in the past ~14 years of being one.
But we had to deliver. We had to increase shareholder value.
SREs became a thing because management realized the DevOps mindset of making your programmers DBAs and sys admins wasn't really working but management were too ashamed to admit they were wrong so they invented a new term.
I am no fan of PHP but it wasn't really a joke language. Its goal I think was to add some dynamic snippets to your homepage for which I guess it served its purpose pretty good. PHP even originally stood for Personal Home Page iirc. The problem seems to be that the rest of the language was built on top of that. I haven't used PHP in over a decade, so I don't know if it's still the case, but you used to start a PHP file with a PHP opening tag, which is such a weird "feature", but I guess kinda makes sense in a world where everything outside of PHP tags used to be HTML.I remember seeing PHP files that were impossible to work with: thousands of lines with HTML mixed in with PHP classes etc.
It's been a while for me as well, and I don't know what's original and what's a backronym, but the well-known "PHP Hypertext Preprocessor" name is sort of part of the answer. The "weird \"feature\"" is central to the point of PHP, which you sort of mentioned, just overspecified as dynamic snippets instead of reusable snippets generally. Since a php include() could (and very often did) pull in things like HTML (page templates) or CSS (pre-SASS/LESS/variables) it was necessary, or rather natural, to explicitly invoke PHP (invoke it again, even, separately from the tag preceding the include statement).
This was the tradeoff (or should I say trade-up) for going from
(Of course, as you point out, we promptly recreated the former situation in PHP -- but maybe there was some rationale to it? I wouldn't know; I did my best to avoid that kind of overwrought PHP project)
Lol, thanks, but I only wish I could pull off wearing the P.I.M.P. shirt.¹ I've always been fascinated by the whole culture of it, but I wouldn't say I really know Perl, even if I once cobbled together a working irssi extension.²
Anyway, for (hopefully) your enjoyment, here's my best fizzbuzz golf (but not the best):
2. Really cobbled, and in all seriousness that's why I say I don't know Perl (I only did any of this stuff with very heavy reference to documentation and no real sense of orientation at all)
Not sure if I disagree with all your points, but this one caught my attention:
> HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays
HTTP 1.x is that, perhaps. But I was in the trenches when HTTP/2 came out, brand new and running on binary. It was so new that there were very few implementations around, and my team had to code one. The people who worked on the spec had a lot of learning to apply from HTTP 1.1. That resulted in many nice bits in HTTP/2, but HTTP/2 also had serious issues at a spec level. Which is my way of saying that "modern" doesn't necessarily mean "bug free".
Just goes to show how quality never is and never was a key to success. Same with JS. That trash only became successful (widely used and popular) because it was conveniently available in the browser and hit a user need.
> As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Not sure why you would. It seems like the people who made these compromises were roughly right and the problem only escalated when it also came with a solution.
The reason PHP and other, "joke languages" are still in use is because business needs power businesses, not engineering wants. Plenty of businesses are still run on pen, paper, and custom spreadsheets because those things just work or work well enough. Could they do a better job or scale up more with a SaaS offering or two? Possibly, but why?
The issue is simple: YOU work for clowns who prioritize financial success above all else, including quality of output. You usually don't have the ability to say "No" to a bad decision made by a senior person. Deadlines, managers dumping more work, feature creep, etc. Then, when you can't deliver they taunt you for their incompetence. So you eat shit all day long churning out crap. That or management hires the bottom of the barrel because its cheap and maybe one or two seniors who eat turd sandwiches all day, give up and ship shit. Enjoy workplace hell. Fire your incompetent boss.
It's especially fun when not implementing the naughty bits is its own source of vulns. Your code is simpler and less prone to RCE, but your proxy mishandling or whatever allows for credential smuggling attacks, identity spoofing, request smuggling, cache poisoning, and all the normal issues at the application layer.
I get your drift but... This sounds a bit like advocating "why not ditch all progamming languages and build some super language that makes no exploits possible". While we are at it, ditch the Von Neumann architecture. Or saying "why not ditch all natural languages in favor of Esperanto".
No, we don't need the "perfect language". But we definitely need to switch to better methods - which were available for decades already - more quickly. There are plenty of memory-safe languages. They have been available for decades. And here we are, a huge amount of servers affected by a memory bug, in especially badly written C. There are probably many more fundamental design bugs in PHP.
Don't all industries work this way? Construction has "old work" and "new work" versions of many parts. For instance, replacing windows on a finished house is a different job from installing windows on a house that's still under construction, so they build "replacement windows" and "new windows." We don't demolish functional homes unless they are unsalvageable; we cut into drywall and patch over the hole. The drywall would look bad if you looked at the backside of it, but the homeowners can't see the inside of the drywall and don't care.
This is a good analogy! Another similar analogy would be construction codes for earthquake proof, or fire proof or whatever safety feature new building must have to be compliant. We don't go and fix everything currently built unless we have to, or can.
The risk is of course, an earthquake where it could destroy all houses built before year X.
But we do the same in all industries, path of least resistance.
> PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people.
Don't forget the other half of the web development stack: Javascript. The absolute worst scripting language ever desi--well no, it wasn't designed, it just kind of happened accidentally. At least PHP solved a problem of the day, Javascript was nonsense from the start, and somehow managed to become critical infrastructure.
I'm seeing this claim all over this sub-thread and I will stick up for JS here.
While yes, PHP begun as a collection of macros and was never intended to be a programming language, JS was made by someone with intention. To quote from wiki,
> [Eich] originally joined intending to put Scheme "in the browser", but his Netscape managers insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.
I've seen quotes before from Eich himself I believe that he was combining these influences at the time - Scheme's closures, Self's prototypes. It didn't "just happen".
Yup. Another reminder of how far software engineering lags behind other engineering disciplines in rigor and accountability. The chickens are coming home to roost.
I hope that the current enclosure of hardware + the help of AI means that we might finally, finally have an era of optimization in which software is made to run much better on existing and older hardware. How nice it would be to have an OS and basic software that opened instantly, responded as soon as I clicked, etc.
> the tendency of software devs, and in particular web devs
Software devs absolutely love to create a mess, and are never challenged by business, product, management, or you name it, to increase speed to market, cut down cost estimates and, to say it crudely, deliver half-assed work.
Any effort towards a perceived best practice or bug fix that doesn’t have a measurable impact on the business is a wasted opportunity cost. Engineers only have jobs because the software they build makes money. It’s not art work.
There quality should be there, but it should only ever be “good enough”
Have you ever watched Ken Burns' Brooklyn Bridge [0]? That doc struck me as straight-jacket-in-a-padded-room insane. The bridge's designer John A Roebling [1] was a Prussian who seems mostly self-educated (who wasn't in 1820? lol) and kind of learned by doing / invented "on the job". Successfully built a couple bridges, dreamed up the mega-project and started building it using caissons [2], then died with it unfinished due to personal injury and hubris. His son took over and completed the bridge, but was plagued by poor health as a result of caisson disease from the Brooklyn Bridge project until his death. Throughout its history, there were concerns about safety, repairs made, upgrades made .. and as a result, there it still is today, as good as it ever was and used daily by zillions of people.
I bring this up because it's the first thing that popped into my head thinking about PHP's legacy. And, admittedly maybe it's not the best analogy, but when people shit on the caissons that bridged the internet because it seems crazy in hindsight to continue use those techniques, shit dreamed up by wacky people to do the impossible, or maybe said we should tear it down and build it a different way, the reality is that sometimes you just leave the bridge in place and improve where you can. It's still standing, you know?
I might be stretching here with all this, but despite you making some very defensible points, I just don't buy into the whole narrative. Just because retrospection has blessed us with the ability to intellectually point out that we built things on quicksand doesn't mean that there were real alternatives to build on at the time. The ease and speed that things like PHP provide(d) allowed enough things to be created to make the web as we know it coalesce into existence in the first place. Pedantic or more expensive or arguably safer choices easily could have slowed progress to a crawl, OR you just build the bridge and see if it's still standing 143 years later.
Was it software devs? I've always had the impression it was management that didn't want to give us time to address technical debt, but just focus on shipping more features.
I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.
When I did the EM role my biggest fights were pushing VPs to give the team more time. Features rushed because some VP told some board member it would be delivered by X. The first mistake is setting an aggressive schedule.
With AI you can actually start fresh, don't know if its that easy in CPU design, but you can literally rewrite something from the ground up with rust or whatever you want now, and make it reproduce the behavior of your old program
What language was a better choice than PHP in 2006? Or in 2001? Some times what we see (now) is a choice that looked like the best option (then) and only became less good over time. Humans do that pretty often?
The thing that pisses me off about people who complain about PHP is that all these smarty pants people have pointed out the flaws in PHP, but never really understood why it was successful, and because of that they never created a language that could succeed it. The things that made PHP successful were:
1. It just werked. You could write incredibly shitty code and it, like HTML, would work as long as there wasn't a fatal error. And sure you could just say "git gud", but that's not going to happen. People will just use the best language that works for them, and in this case, it was PHP.
2. It required very few resources to run low to medium traffic websites. Because of the Apache mod_php module, PHP sites wouldn't use any resources if they weren't being served, unlike every other language at the time. So it meant places could host thousands of websites on the same server no proble.
The guy who created PHP, Rasmus Leerdorf, never wanted and never expected that PHP would become as popular as it has. He has mentioned that he thought that at any moment, someone was going to come around and create a language that would succeed PHP. But it never happened. People are just better at pointing and complaining instead of solving the issues that people want solved.
>to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet
It's totally the devs fault and not the environments devs have to work in. Deadlines forced down on you until you have to make compromises, 24/7 having to compete with people who actually don't care because you have to meet months end payments somehow. Whole businesses blinded by a tech gold rush.
>We're a clown industry.
I do agree here, but that includes every non dev person.
You don't see the same problems in say, structural engineering as you do in software engineering. I suggest this is due to needing to go through the formal training required of a structural engineer, and membership bodies like chartered institutions, with standards and codes of ethics. We might want to reflect on that
The state space of what you must check to ensure correctness in physical engineering is infinitesimal compared to ensuring correctness in software. Correctness in software is qualitatively more difficult by nature and an open problem at a theoretical level.
No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.
It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.
Structural engineering, is engineering (though mechanical engineers would disagree), 'software engineering' not so much. It just happens to be a word that's a useful synonym for 'building things'.
I rarely call myself an 'engineer', preferring developer or programmer.
Isn't software "engineering" or shouldn't it be considered that? Creating a new painting program might not be considered that and a software failure would have little impact, but there is a huge amount of software which is essential for the operation of complex systems. We just had large parts of the internet impacted by the PHP bug - a lot of businesses were harmed in their fundamental processes by it. Like if a roof of a warehouse had collapsed.
In Europe, a lot of supermarkets were hit by a remote exploit which allowed attackers to switch off cooling of food. A blood bank in France was attacked the same way.
So how would building software for important or even safety-relvant systems not be considered "engineering"?
Especially, as faulty software might not only cause a product or device to fail in a dangerous manner, faulty software in this day and age often makes it possibly to remotely attack the faulty product.
I agree with you but I would extend that observation to include the age of the industries. We have been making structures for thousands of years. Software is an infant compared to that.
I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".
competing with others doing the same thing in a zero sum game. We all just have to simultaneously coordinate to agree not to set unrealistic expectations or deadlines! Sounds easy, right?
You forgot NPM. Whereby we download code from unknown authors on GitHub and run in with full access to our filesystem on our machines. No vulnerability, it's been designed like this, we even have designed scripts to autoupdate vulnerabilites, that's the proof that vulns are not common.
Well, you certainly should check your Perl knowledge - it's older and do not use Github as a repo :) There is CPAN and testers, etc. Other languages do not invested into that "intemediary" infra.
The amount of begging I've had to do as a Ruby on Rails dev to be given time to refactor debt was unreal. This was pre-AI, around 2018.
I basically just worked extra unpaid hours with a colleague to do it since it was frustrating.
Not even from a security standpoint as it is now, but just plain developer happiness.
But while we were cleaning the Swamps of Dagobah the other team was extending them.
Our deliverance came when the other team got woo-ed by React and started coding less in Ruby.
For my mental sanity I treat the React project as a black box.
Just heard they had to update the Redis connection configuration in 6 places, after we had switched to Sentinel based connections.
Also, path-dependency is a real issue everywhere. You would know that if you would actually experience true industries. All in all, software world is far more malleable than anything.
> the effort that went into making it good should have gone into ditching PHP
What effort? PHP foundation has one employee!
> The bandaid mentality is what got us in this situation.
> We're a clown industry.
We are clown industry becauee nobody would sponsor solid research, infrastructure and fixing all those bugs! PHP is junk literslly written over nights by some volunteers!
I suspect you're being intentionally obtuse here but the PHP Foundation isn't where PHP gets written. Zend are the closest we have to the PHP company I guess, and they have approximately 100 employees, then you've got however many people are employed either as contractors or by other companies with a primary focus of working on PHP itself.
> PHP is junk literslly(sic) written over nights by some volunteers!
And yet everyone knows this, and millions of people still continue to use it and develop new software with it, to avoid learning from our mistakes. The software industry is just not interested in fixing these problems; I've heard people upset that AI is pointing out flaws, instead of being upset that flaws exist. Deeply unserious.
Things have moved on from PHP, but at the time, the alternatives had many more tradeoffs in a wide range of cases. Without PHP the internet would have unfolded much differently, much more slowly.
The "bandaid" mentality you decry exists of course, and is outright bad in some cases, but is just good business in many others.
Rewriting everything makes no sense. And, of course, in the vast majority of cases is never going to happen, so advocating for that is effectively advocating doing nothing at all for 90%+ of sites. A much more efficient and effective approach to using AI here would be to find and fix issues in the PHP runtime, and to assist in automating the deployment of the runtime. Time spent on this fixes thousands and millions of sites at a time, in a consistent, improvable way, rather than one at a time, in a piecemeal way.
> We're a clown industry
I think if we want to bring more engineering discipline to software development, we need sober analysis, not outraged rants.
There is no upper limit on the definition of "clown." It all depends on how much money you have to play with and how many nines you're willing to accept.
> We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.
Ironically, the opposite is the case with LLMs. Now those on your teams that wanted to stop the clownery will be overruled by the vast amount of bullshit code from their less skilled peers. Of course, those that care can use LLMs to faster clean up, but there's no way they are able to keep up.
Managers always favored outcome over correctness, and not giving two shits about the internals was, and will always be, incentivized.
On the RISC stuff specifically: It sounds like you're saying CISC is just RISC with a microcode translation layer. It's not wrong, but then RISC is also RISC with a microcode translation layer.
The CISC vs RISC debate hasn't been interesting in a quarter century at least. The only real difference is that the instruction decoding (which CISC and RISC both have) is likely going to need more transistors on x86 than other contemporaries.
But I'm not sure what you mean by "stop doing things like that". The ISA is "the API". Sometimes the best CPU implementation (for whatever definition of "best") will need to change the ISA-to-microcode translation.
It's not reasonable to assume that a decades old ISA will have a 1:1 instruction to microcode mapping. Hell, it's not even 1:N. Macro-op fusion makes the mapping N:M. So you could say that RISC also has variable length instructions, in a way.
And RISC-V has two sizes of instructions, with RVC. So it's not even "super transistor efficient because all instructions are 32bit".
Then there's the "reverse micro-op" that is instructions intended to cause traps for software to handle. E.g. Alpha's PALcode that handled (among other things) unaligned memory accesses.
>frustrated by the tendency of software devs, and in particular web devs
Are you sure that's not the typical cost optimisation of management/c-levels rather than a developer problem?
What you wrote reads a bit like ye olde typical "nyeeeh javascript! you're only a dev if you write everything in assembly! kids these days!"
sorry, but you are really naive. php was peak engineering compared to the contrived layers of llm generated executable pseudocode we are about to build upon for the foreseeable future. php is opcode running in a C/C++ driven virtual machine. what llms are spitting out is statistically inspired plagiarisations void of sense that linguistically abstract non-linguistical concepts chaining all that crap then build towers of it and nobody will be able to even reason about what's going on without adding more llm to the mix. think apollo guidance computer but 1TB of code.
Haha, so how do I become a palace clown? Just kidding. I like and trust AI, but I don't think AI can solve the debt, because AI code creates a different type of debt than code written by humans.
I think we need to start over with safer languages and runtimes.
That’s what I started to do 10 months ago.
You want a safer language AND transpilers from PHP, JS, Python etc. into it? So you can find issues in your original code using source maps, or just speed up your PHP by 10x and your Python by 100x? Here you go:
> As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Your analysis is severely flawed and naive.
Software devs often patch and sidestep the root issues for the same reason why every single engineering field resorts to patching ans sidestepping root issues.
Why do you think there is such a thing as aviation duct tape? This is a field where people's lives are on the line.
There is a very puerile belief around opinionated junior devs which an inconvenience in the code justifies redesigning whole systems, even if they are still quite capable of performing their functions. Things need to be clean and ideally elegant, and any minor deviation is cause to tear everything down and start over.
In the meantime, experienced and competent engineers instead get the system back in working order and downgrade the criticality of existing issues until it's convenient to address them.
Go ask a project manager if all bugs should block a release, or if it is ok to release something with a known bug. Listen to them. Perhaps then you'll understand why patching works.
Are you sure you are senior? Because in my 22 years of experience in 3 countries and host of employers (banking, telco, insurance, military, municipality, energy distribution, retail etc) it was always management setting the tone and only fools ignore the hand feeding you and go against it due to some 'higher principles'.
No we don't need to have documentation and keep updating it what you can't read code? No we don't need to rewrite system that was patched ad absurdum so codebase became fragile and its hard to navigate layers of abstractions. We need to deliver this project yesterday at all costs since somebody up there slept on requirements for 6 months and didn't do their basic job, and we will never pick up half-assed pieces we were forced to deliver. No we don't need to update those 12 years old libraries, too much work and testing. I could go on and on.
It seems like you consider engineering to be delivery of perfect things, or utter failure. Thats not how things are anywhere, sw dev is more unstructured but you also don't have 5 million ways to build a good wall using every possible substance in the universe, do you.
As someone who went into electrical and computer engineering in the 90s and was noodling with toy neural nets in the 90s; yeah agreed with the joke/clown knowledge job
Been saying to boos and rotten veggies "it's just electrical state in a machine; yall are deluding and debasing yourself for money." And "if you want to improve security stop using leaky abstractions to configure your machines".
Even better is that AI is replacing all knowledge work it just reinforces how absolutely bonkers the US "services economy" is and giving social stature to credentialed randos whose skills are whittled down to cooking frozen meals, grubhub, and Excel Sheet expert; unserious country peddling before the eyes of the poorest manual workers all these years that their degree in accounting earned them the right to wander through someone's home town across the world via resource intensive travel
Or better yet just being born rich earns them that!
This is an unserious country and social culture top to bottom to continue to assume modern people of nations rebuilt since Murica bombed them to the stone age don't see how Americans are drinking their own piss since the end of WW2; refusal to acknowledge externalities like generational churn (among all the others) makes it clear America is an unserious country.
HR and accounting and even a law degree do not make the individual worker bee irreplaceable themselves; whole lot of arrogant low skilled "knowledge workers", biological fuzzy VHS of often debunked pseudoscience studies now 30 years outdated... can pound sand.
Set aside the circumlocutions inherent to old thinkers like Marx and Adam Smith and capitalism is a social/communal discovery of services and prices; seems pretty fucking social and communal. But that's not "the Sacred Jedi Texts!"[1]
Top to bottom American society is a clown car stuffed full
[1] will take to my grave Luke screaming about Jedi Sacred texts was a metaphor for dogmatic people in general
We are not a clown industry - we are an evolved industry - both parts of that matter. We evolved in an environment where these kind of attacks were not possible or were freak, state sponsored events. Kind of like moving from a sheltered lagoon to the Pacific Ocean. And we are an industry - where profit matters. Open source was lead by people like you who cared and did not have profit to constrain them. Which is why it’s better engineered (and frankly if open source like Linux or FreeBSD had not existed in our lagoon, the profit would have failed earlier and commercial Linux would have had to been built and built to same standard (god knows how)
But we are out in the pacific now, and boats that sink make no profit, so we will evolve again, and again.
But it’s hard to blame Moana standing on a pacific island for not inventing a nuclear powered battleship.
These attacks aren’t freak, and nor did they take state money. It’s more so that security by obscurity really did work because it didn’t cost a few dollars to attack people. Now we’re having to reckon with security debt, not code debt. It’s still quite fashionable to increase code debt to buy velocity and efficiency.
So I was saying that prior to AI say 2025, complex multi layered attacks were so hard to do that the resources kept it at a low frequency. Now layering ten different vulnerabilities to capture a flag is just five prompts away. This used to be so hard it could be ignored as a “likely” security risk.
That’s changed - we are in stormier weather and need better boats, but it would have been unlikely to have built battleships to sail the lagoon just in case…
ironically, AI is also making us create a new whole new level of technical debt - where _no one_ has actual understanding of the code being written and we're just trusting the machine
Multiple times in my career my teams have received ownership of large projects, often the legacy kind, either though reorgs or layoffs or acquisitions, that we had absolutely no understanding of the code of. It was just chucked over the wall with some docs and runbooks -- maybe a short handoff meeting if we were lucky enough to have the previous owners around. And given that this was typically on top of our existing workload, we did not have the luxury of understanding the new code at all.
The world didn't end. It was a complete black box, but we followed the runbooks and kept things running, and only learnt enough of the code as needed to fix any issues or add any enhancements that popped up. Diving in, doing some software archaeology, and spot-changing relevant code became a skill we had to develop.
At scale and over time, I would guess that the percentage of code running on machines that is actually understood by anybody approaches 0. Yet the world does not end.
right, but the scale was MUCH smaller. And there's usually someone who know someone who has context, so you had someone to call.
I'm working on a repo these days that's larger than _entire companies_ I worked with in the past. A 10-person team maintaining more code than 100s at a previous job. The _scale_ makes this wildly different from what we're used to, no matter how much "legacy code" you had to maintain before.
I used to work on Visual Studio 20 years ago. At the time it was 30M lines of code with a history going back over a decade and about ~1k people working on it. Product cycles were measured in years. Time spent working on new features was measured in months, since no one understood how it all fit together we then had to spend years playing whack-a-mole with bugs, to stabilize it before shipping it. I regularly had to debug through large parts of the stack I'd never been in before. So did lots of other people.
Being able to work effectively in large amounts of unfamiliar code was an expectation for mid-level engineers (L62 if I recall correctly). Its not a new skill, but it is increasing in value again.
Yes but you are talking about code which you can do archeology on. A given code base may seem a complete mess but you can often understand it by deciphering which programmer created what and what their style and intentions were. I haven't tried to understand reams of vibed code so I am just curious and perhaps skeptical whether any kind of similar process could be used.
It is possible, but I it will be really difficult if the code is not reviewed stringently for simplicity.
What I've found is that even the best models can write very good code "in the small", and the code is mostly correct, but they can be highly problematic in their design, architecture and abstractions they use. The most common problem is that there is a strong tendency to overcomplicate things, and often this can be traced (ironically!) to the agents not having enough context.
E.g. a very common failure mode is that agents are unaware of some invariant in the architecture (or the fact that they could potentially stipulate a new invariant) and write code to handle a dozen edge cases that would never occur. The code is correct, but there's a ton of unnecessary slop.
My suspicion (confirmed by friends and posts on HN) is that at most places, people don't bother reviewing the code and blindly ship all this slop. The reason things haven't imploded yet is a) the code is usually technically correct, and b) all that additional complexity is never exposed to humans -- it is just outsourced to even more agents to manage. Which explains Anthropic's exploding revenue, I suppose.
That said, it's not like things were better before AI. I once had to go Indiana Jones-ing into a humongous legacy Python codebase so full of magic that there were some code paths I could never figure out even with a debugger. I could only tell that if I got a row written to a specific table, some completely disconnected code path elsewhere would get triggered. I suspect what was happening was a function name was being constructed out of 3 different strings from 3 different sources, one of which was a column in the DB row that was getting written, and that function was being eval'd in some thread somewhere.
This was to fix a bug, which I managed to do without ever figuring this flow out. I still spent an inordinate amount of time trying to figure this out before I realized I was being too idealistic and closed the ticket and moved on. I bet an agent would have figured it out though.
Not really. One of my coworkers has been using it more recently, and just pushed a merge request last week that mixes a bunch of different styles with little abstraction. And I don't mean styles like linting, it looks like it was done by three different devs who couldn't agree on functional or object oriented style, or whether "spooky action at a distance" was good or not (extra effort to avoid it in some places, relying on it in others). Plenty of things aren't named well either so you have to look at the implementation to figure out what they're doing. And this wasn't even very big, around a thousand lines greenfield.
I like to think of it as a new abstraction layer on top of something we've been comfortable with for years. The developers of the past had to trust that human-readable code would compile to the machine-level bytecode they were used to write, and that even though it wasn't as efficient as they could make it, one day the benefits would outweigh the negatives. Today most developers don't understand compilers well enough to even begin questioning if the code doesn't work because the compiler has a bug or because their code has a bug. They have to trust the abstraction layer beneath their current domain, and they have to find ways to prove that their work is correct in that domain (e.g., writing a sufficient number of unit- and integration tests, compiling with different compilers to different targets, etc.).
We, too, have to adjust to this change, this new abstraction layer, because whether we like it or not, the code an LLM will produce in no more than five years will arguably be much, much better than the code any 10x developer could produce even if given months of time and an infinite supply of caffeine.
We "just" need to find a way to confirm that our work in this new abstraction layer - primarily prompt engineering - results in the code functionality that we had in mind, not necessarily the code implementation that we had in mind.
I've spend the past month-or-two on developing a platform scroller game for smartphones using nothing but AI. It has created everything given my instructions, to my liking, from the way the game is played to graphical assets to sound effects. It looks and feels like any other typical studio-developed game you could find in the store, the difference is that I didn't have a studio of professionals working fulltime for months or years with various levels of project management and what not. It's just me. Me and my agentic coding subscription.
Vibe coding originally meant giving an LLM an instruction, having it regurgitate something potentially wholesome, testing it and feeding back the errors for it to fix it. What I've done in the past couple of months is so, so much more than that. I'm a puppet master and my coding agent is my puppet. I don't need to understand the code when I can describe the problem I want solved and it will do it 100x faster than I ever could.
I didn't use code to describe this level of abstration. I used English prose - and a heck of a lot of software engineering theory, mind you. If you know the solution requires a quad-tree and binary search because in this case, that is the best option, then that's an instruction, not a block of code.
Is it faster because you are using English prose or because you don't actually have to do a great job of specifying your game. If you say, make it look like X or have the controls like Y; you are just reusing the work of someone who has specified all that, probably in code. If you actually had to spell out every rule in English, you would find code is a much better language.
You are probably right, and then I would most likely copy solutions to specific problems from StackOverflow like in the glory days of the 2010’s.
My first lead developer was an old school developer who preferred to look up guidelines and solutions in physical books he had on his desk. Nobody should waste time reinventing the wheel.
To answer your first question, it’s faster for me because I can formulate my request as a developer as if my AI agent was also a developer (in a sense it is) faster than I can figure out how to implement it on my own, especially in a new language and ecosystem. I didn’t just prompt Claude Fable at Max thinking capacity “yo dawg make me a game for iPhone that will make me rich just pick whatever style and stuff” and let it run for a week or two. I brainstormed the idea of the game with my AI agent (Opus 5.5 mostly at High), asked for suggestions, adjusted its proposal to my liking, asked it to flesh out an implementation plan for each milestone of the development journey, worked on different topics as we progressed (introducing complex graphics was sometimes challenging which required a bit of guidance for it to get the assets right), had it create a level editor for me because explaining every single thing was taking too long when I could just drag the sprite a little on my screen and tell it to compile my changes, we worked on ambience audio and sound effects at multiple levels (background, middle, foreground), and the list goes on.
A LOT of work has gone into this project, but without an AI I would not have gotten any further in the time spent than barely figuring out how to get even a simple round ball bouncing on a flat surface in Unity. With AI I’m looking at a feature complete game ready to ship to the App Store after the last bit details have been settled (advertisement laws and whether to monetise one way or the other or not at all, mostly).
AI is an incredibly powerful technology and when you wield it correctly you can go from 1x or 10x engineering to 100x or even 1000x at minimal risk (because you mitigated it along the way).
If you don't particularly care how the code works or specifically what it does it seems pointless to worry about abstraction. Since, as you say, it solved the what you wanted solved and did so quickly.
But when you do care, it becomes important.
And, I suppose, computer code in general is terrible about writing things at the right level of abstraction, or at least human generated code is and I think LLMs do worse, somehow. So there is something to be said for prose as a specification language in most cases.
But I still think we're going to end up with some kind of code to reason about programs. Same way mathematicians have been using mathematical notation to reason about maths. But maybe it will be different code. Who knows, literary programming might catch on.
Is it a challenge to Agile methodologies? I mean is most software today designed at all? If we want a pm to be able to write half baked feature ideas and expect the devs to sort it out, rather than just paste the ticket into Claude, don't we make this chaos inevitable. Maybe there is a missing formal engineering layer missing between feature request and prompt. Llms seem to do much better when they are told exactly what to do, vs when they are given room to...express themselves
I note you're downvoted but I strongly agree. Forcing humans to speak machine language is inherently inefficient. Having them speak a language we're already comfortable with is an obvious evolution in abstraction and control. I suspect you've ruffled some feathers because speaking machine language has been a knowledge and skill gate which is rapidly becoming redundant. It doesn't feel good when one's career and skillset become much less valuable. Never-the-less, this technology is not going anywhere. Opus 5.5 already codes better than most of my developers at about 100x the speed. Architecture is still valuable, but I have no doubt that this is also going to be done better by AI soon.
Some people react to harsh realities and truth with negativity and the only the only things they have control of here on HN: a downvote. :)
I, personally, never downvote people I disagree with. Who am I if I don't use another perspective as an opportunity to learn and grow? I can tell that many people agree, too, because my "comment score" is still mostly neutral at the time of writing.
Human speech is inherently inefficient and ambiguous. Humans rely on non-verbal clues and context to distill the exact meaning of phrases, and even then the potential for miscommunication is non-negligible. It is a huge leap to assume that artificial intelligence can succeed in flawlessly divining intent from regular human speech to the point where it can generate debt-free code. And if your solution to that is to say "no, you need to issue specific instructions to guide the machine to the correct solution" then you have not removed the skill requirement, you have merely redefined the skillset.
I think you mistakenly believe that the existing abstraction layers don't already contain ambiguity. It's true that formal languages are built to reduce ambiguity, but there is still much ambiguity. For example, gaps in the specification still leave room for interpretation. [They list some in Cambridge's free C course:](https://www.cl.cam.ac.uk/teaching/1516/CandC++/lecture10.pdf)
- Implementation-defined: the compiler documents its choice, e.g. sizeof(int).
- Unspecified: the compiler picks from options, e.g. argument evaluation order.
- Undefined: no requirements at all, e.g. signed overflow.
The notes take you through compilers deleting an overflow check and a kernel null check because of undefined behaviour.
There are also abstraction leaks. Spolsky’s Law of Leaky Abstractions says all non-trivial abstractions leak. SQL is one example. Logically equivalent queries can differ in speed by thousands of times.
In other words, formal languages are no different to spoken languages. They exist on a spectrum of ambiguity, assumption, and implied meaning, depending on the domain. Human language has the potential to introduce more ambiguity, assumption, and implied meaning, but that's not a predetermined quality. You can be as detailed as you like in your communication with your AI. To a degree of precision equal to or better than a formal language. You reference this in your last sentence. The distinction is fairly obvious: being specific in English has a much lower skill bar than being specific in C.
One of the more interesting topics in research and philosophy right now is this question of alignment. To what degree to these models understand our meaning when we're not extremely detailed. We can see in research that they're becoming extremely competent at inferring meaning. They can often understand our intent with very few words.
The worry for me is, we talk about future super-intelligence altering the economy and financial system and others to such a degree humans simply won't have the capacity to understand the complexity. It's a fear people are raising currently for the future.
But software powers so much of our modern world, seeing companies decide "well maybe we don't understand the code but trust the governance and harness will allow AI to always fix it" is essentially that above hypothesis in action today.
Indeed, and it's just going to end up as a zero-sum game where the winner is the one who can most adeptly manipulate the machine to cause harm to the other.
Is a nuclear power plant dangerous? Or an airplane? Both are examples of an advanced form of what other entities in their category do.
Of course we should proceed with even more powerful tools. We also need even stronger governance of said tools. We don't want an AI-version of the Chernobyl incident but we do want the AI-version of the benefits that nuclear power gives.
Yup. Feels very much it's creating a mess on purpose IMHO.
It's like an over-eager junior engineer that will implement whatever pattern they read about last week. It just doesn't feel trained on high-quality enterprise, battle-hardened codebases.
Even Opus 5.5 on High thinking still littered a root directory of a JS project with source files without thinking to put it in a 'src' directory. It had to be told to use a testing framework. Had to be told to also test with Firefox (the project already had established Chrome /and/ Firefox targets).
I have to continuously burn tokens and effort correcting it.
I imagine it performs a bit better with a huge corpus of architecture and style guides. But I did expect to get some that for free with the "leading" model.
Or to restate another way, most modern programming languages are a highly specialized and specific dialect of english. Perhaps it's possible that with AI we will find a new but equally specialized and specific enough dialect of english for interacting with it when generating code. But then you just re-invented a new programming language for people to learn.
So, It is the same quality as a team of outsourced developers asked to do the same task (at least back in the day; I say this from experience evaluating said "code" that the team delivered -- it did function, I suppose).
Same with that situation. One shot code from prompt is still not great.
Maybe if you had a prompt with highly detailed requirements for structure and code formatting it would be ok.
I generally hate the look of AI gen code, so I have some pretty detailed code formatting rules for even small edits. And the AIs still ignore them some of the time.
I don't know what I'm getting at here; other than. It is acting pretty human like at this point in the code delivery phase. Human as in asking someone to do your work for you and you not always getting back what you want; as opposed to being good enough to replace your actual work (assuming you are good at the task you are asking from the Agent -- does work pretty fast though. which makes it a trade off worth considering; but then your time is in picking through the code to confirm it is correct).
the worst case for this is if that doesnt cause sufficient problems to force a reckoning. it has to hurt badly enough that we put significant effort into training legibility into the process.
This reminds me of a slightly different take. AI will allow us to deliver on promises made over the past 20 years. For instance, CI/CD is actually happening now like evangelists claimed before and it really does unlock tremendous value, mostly through efficiency.
Software bugs are always a cat and mouse game with the mouse improving with time and the cat elevating its defenses. Now there comes a supermouse demanding supercat skills. But the massive difference now is that the defender has the exact same tools as the attacker.
Every SW developer must use AI to test the security in existing and future projects before deploying. I cannot believe it has not been done yet for all public facing software. And a system must be deemed insecure if it does not pass an LLM stress test. This should also become standardised and maybe included in OWASP.
What's hillarious is people vibe coding massive AI apps thinking its not creating tech debt and security holes. If anything, AI is discovering existing holes, and creating them faster than ever before in history.
All those "paying down" technical debt with AI, I would advise reading the code _very_ carefully. Sometimes the "solution" which passes some test or adheres to some described functionality is incredibly narrow / brittle, and/or has failure cases that are non-obvious.
Yes I'm using $latest_model on high, its still not there. Unless your threshold for "fixed" is "the 1M line lean proof runs, we don't know how it works", it still requires a lot of attention, hand-holding, and scrutiny, especially when fixing issues / working around failures (where it tends to shortcut or invent workarounds).
A developer on my team introduced new features behind feature flags despite concerns about whether we should have those features and how they are going to be maintained. Changes touched 200+ files which is half of the files.
Turns out nobody wants to use them, they caused many subtle bugs in existing features and is a distraction for many things we do.
The developer left the team, and I am left with purging all of this.
The same can be said with human-written code. LLM code is by far better than the average developer’s code at this point, and there’s not enough top percentile developers to go around, so it’s a wonderful tool.
Also, those very average developers are also the ones doing the code review.
Below-average developers generating bugs now will be submitting AI created security holes at 10x the rate going forward. Hah, people are literally on this forum debating whether to use openSSL because they can vibe-code it with a smaller surface area (just have AI only create what you need).
Anthropic is literally creating their own git alternative because they are slopping so much code. You think its 100% secure? Even if it has bugs at 10% the rate, there is 10x more of it to go around.
Do you think Anthropic's git alternative tool is more secure and better written than git? Hah, I bet it was just some vibe-coded thing they did over a couple of days, when it starts bogging down, dropping commits, or getting unstable, they just have to prompt harder! I wonder why they won't open source or release to the public, its probably too dangerous to release!
In a few years we'll be able to look back and compare the technical debt in code written since 2026 vs code written in the 40 years prior. We'll then have another metric to quantify the impact and usefulness of AI.
If AI's code is sloppy but bug-free, is it better than the alternative?
I honestly think there are some kind of laws of physics at play here... in the statistical limit of the massively participatory interaction of engineers, there is some kind of least action principle where the system is seeking lower energy (i.e. less code complexity, better foundations, etc), but only locally. The path towards a radically better foundation for the entire industry is outside of the "energy well" that it is currently in---at least that's how I see it. I feel like that's why we see more things like elegant scripting languages rather than ground-up reimaginings of computing itself.
There is a concept of the hourglass model [0] of internet protocols, where IP sits at the waist. I believe that similar things are probably true in any "stack" based structure, such as computing, where the protocol at the waist has the most staying power (which at the current moment could be e.g. x86, or something) because it's essentially the universal translation layer that enables all the language protocols built above it to be agnostic to all the transport protocols below it. So, I see it as an open question as to what the best way to affect change in a situation like this is. I'm interested in if anyone else has any thoughts along these lines.
Earlier this year, the cybersecurity firm Calif offered to independently audit PHP, sponsored by OpenAI. Within two weeks, a researcher at Calif, aided by AI tools, found a way to use the out-of-memory bug to run arbitrary code on the host server, allowing a malicious actor to install malware or read critical data. Now, it was no longer a minor bug—it was a critical vulnerability, and the Calif team alerted the PHP foundation to start working on a patch immediately.
So, the headline should read,
"AI is helping us eliminate 40 years of technical debt."
Since AI found the bug, and probably also generated the patch at this point.
An abundance of solutions is a problem for people who sell solutions.
Does the phrase technical debt suggest that the “debt” could’ve been dealt with if enough resources were allocated or a different engineering paradigm was followed? I feel it to be an inevitable consequence of deploying tireless ai robots dedicated to find issues
It's not just security. When Opus 5.5 got more capable in September (anybody know why? they definitely did something), we suddenly got flooded with a bunch of old debt that it kept finding and suggesting we fix. And it was right, in a majority of cases. Ate us 2-3 frantic weeks easily just to get from a deluge to a ... well, not yet a trickle, but something more manageable.
> As far as anyone is aware, disaster has been averted: The hack was discovered by cybersecurity researchers who reported it to the PHP Foundation
Thanks to The Lord everytime someone discovers the vulnerability he reports it right to the owners/maintainers and there are no bad actors out there keeping it as secret and using for years.
The strain from the amount of bugs is visible in bug bounty programs. A run on many targets will turn up exploits, but if you report them on any of the platforms a majority are instantly marked duplicate. It's so overloaded that companies are shutting down their programs from the volume of reports.
Anthropic is arguing for formal verification [0]. This is an excellent idea on the edge of feasibility, but it's hard to see how this can work for the majority of software that has to adapt rapidly and are so open ended that it's difficult to even conceptualize all the input modes. It's an easy prediction that we will see verification on large trunks of fundamental software in the next few years, and a sub-verification confidence scheme for the software on top of it.
currently following some other posts made here on HN with a similar goal; inspired honestly by that mini-firmware project a few days ago
nothing i'm proud enough to open to the world yet, but my personal public server will be my first deployment, and will definitely "Show HN" then too :)
In my opinion, the whole paradigm how we use computers needs to be replaced. It is like the 80s, but now with internet and a thread larger then anything in computer history before. I remember boot sector viruses and stuff.
My approach is https://tix.im/ - not launched yet. But from expedience: modeling everything as workflows of composeable nix flakes (expert systems from programs, skills, agents, workflows and their snippets, DBs blobs, service descriptions, ...) and then run everything in highly isolated environments. It is not only so much more efficient, reduces errors, increases quality, reduces unnecessary cognitive load, ...
I start to move more and more daily tasks into the systems. Even UI programs become interactive workflow steps, which allow me to attach from anywhere back to a task in an environment optimized for the task.
Dependency updates for example, a workflow. A subgraph from a security scanner expert checks each change in the dependency tree.
I don't mean to be that guy, but your website feels inscrutable to me. I know that a lot of that might be because it's written by an LLM, but the page seems like it's full of private language and is the product of a deep context conversation with your agent that I don't have enough context to understand.
Yeah. The concept is quite large and hard to understand - beeing the inventor does not make me the best explainer of the system, and english is not my native language. People grasp it more in a personal conversation and seeing it in action.
tix.im combines conecepts of expert systems with LLMs and other AI systems. Everything is composable via nix flakes. Any change is modeled via workflows that run in isolation. Each step type, is composed from the nix flakes defined and installed in the environment. Not only the projects nix flake (devshell), but also the tix project enabled experts.
vx-maintainer is my software development expert - does only know about conecept of software development. Each workflow implemented is steps and workflows.
For example, each change lands via land-feature workflow, it has ~40 steps. Workflows have complex parameters that define the flow inside the workflow DAG. In this case, rebase is mechanical, if it fails, medium smart rebase fixer is spawned, then mechanical step checks if all commits arrive in the rebase. Then it builds a collections, spawn a review swarm, open-code-review, etc... everything is tracked in an own issue tracking system and workflows can be restarted with minimal overhead.
Then I have an optimized queue-manager, an own agent prompt with an goal that can never be fulfilled. He manages that items from the tracker get done and land, extra workflows mechanically later check the landing.
rust expert, knows about rust specifics, has snippets, agents, skills etc.
security expert has workflows with red-teaming, cyber models that get registered at the internal LLM gateway for usage, ...
I start to model everything in my daily live as an expert system now, with workflows that can be used by other expert flakes.
Workflow steps can be shared and also run wayland and x11 apps, rmux multiuser sessions etc. So, my goal is to move most of my tasks into some specialized environment.
And this is just a small part of the architecture - it is fully decentralized and user owned.
you can build workflows without agents. Giving them highly isolated environments where they can't break stuff and having human gates where it makes sense - game changer.
And you can use local LLMs - stata is awesome.
I have a strata tix flake, I start it, it registers the model locally, and it becomes useable everywhere.
It's my strong opinion that the problem isn't a language or application problem, but rather an OS design flaw. Relying on ambient authority was fine back in the days of stand alone systems with a few users and no networks.
It's insane that we haven't yet migrated to capabilities based Operating Systems with default deny instead of default permit.
Maybe this will be the push to get us over the hump?
I'm personally not sharing the connotations of negativity towards software development and the term technical debt. I keep reading implications that most of this has always been in some way preventable, but it really is not that simple. How did nobody find these types of exploits 40 years ago? Why are we suddenly shocked and blame the field for this? I think the majority of people severely underestimate the complexity and seriousness of software. Once that perception stops and the economic incentives are right, we can start to look closer.
Just consider how laughable some working conditions in software are and then come to realize how architecture is shaped by the organization communication patterns and not reality. You will see it in a different light then.
> Just consider how laughable some working conditions in software are and then come to realize how architecture is shaped by the organization communication patterns and not reality.
I've never considered this problem from this perspective, but damn, I think you're dead on.
That's so true. Nobody gave a damn about those bugs because they were too hard to exploit, and companies had a mindset of "move fast and break things." Bugs were given low priority, and developers had no time to fix them since they were buried in higher-priority feature work as part of a cost-optimization effort. Almost all of the smart people who could actually exploit them were afraid of criminal charges. Now, lots of script kiddies are having fun with AI, and state-sponsored actors in different countries are using it to accelerate the discovery and exploitation of vulnerabilities. But instead of extending validation campaigns and allocating larger budgets for hiring and funding security audits, software vendors are mostly trying to lobby for limitations on models' capabilities and regulation of the field, like Amazon reportedly did[1], despite even OpenAI and Anthropic offering subsidized[2,3] access to their frontier cybersecurity models, which are significantly better than those malicious actors have.
[2] https://openai.com/index/coordinated-disclosure-of-critical-... - "To help more defenders use these capabilities, we’ve committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, focused on organizations with limited security resources protecting essential services."
[3] https://www.anthropic.com/glasswing - "Anthropic is committing up to $100M in usage credits for Mythos Preview across these efforts, as well as $4M in direct donations to open-source security organizations."
i dislike the term "technical debt." we don't know the trade offs someone made while building a system. often times, it's too few people to do the perfect job, so we decide to do the best we can over the whole solution. for instance, we could all probably do a better job with accessibility, but often times we can't afford the time with stakeholders wanting other things. i don't see it as "debt" but more as the typical trade offs we have make when prioritizing work.
i hope we get to a place where we keep the same number of developers employed as today, but leverage ai to make all software better across the board. hopefully the people in power realize that we've been understaffed this whole time.
I sometimes hear "We have so much technical debt! We're using Mongo when we really should be using Postgres for this data structure."
Not technical debt, just a preference for doing things a different way (which admittedly might be a better way, but just because there's a better way doesn't mean the current way is bad)
We have static software analysis tools today, they help find a lot of issues but are not infallible. Given how sophisticated new AI coding platforms are, I imagine in the near-term, we'll have radically more advanced code analysis tools that will close the majority of the security issues that slip past current generation static analysis tools. Will there be zero bugs, likely no but the attack surface is going to get smaller and smaller.
AI is capable of finding bugs and security flaws that most engineers can't, but it also creates code full of tech debt and vulnerabilities when let loose. AI is great for code reviews (of human written code) and small fixes/patches on established codebases with good practices that were built entirely by humans. Unfortunately big part of the software industry is doing the opposite: having humans review AI-generated code, and having humans work on top of unreliable PoCs built by AI.
I'm reading some takes in the comments that I'm not so sure about. We seem to be taking for granted that we can fix all the bugs and security problems of our software, and then everything will be fine. But is that really the case? Do we know if it is even possible for a non trivial software to be fully secure? Or will there always exist a way to break it, no matter how much we fix it?
Formal verification (https://en.wikipedia.org/wiki/Formal_verification) can be used to prove the correctness of computer software, and eventually most critical software will slowly move towards being formally verified. That however means that we need to get better at creating the specs for how software _should_ operate, so we can actually test that.
I think this is great. Reminds me of Y2K. I remember sometime around 1993 having a discussion with my boss why we store dates on our mainframe as YYMMDD instead of YYYYMMDD since we are approaching year 2000. He ignored the issue totally. I left the company but people told me later that in 1999 they suddenly started a huge effort to change the date format. Same with all the technical debt. It got ignored for a long time but finally we are forced to address it.
There is a saying: no decision before its time. Management is making the decision to defer action until it is no longer a decision but a necessity. It's dumb MBA thinking, but I can probably guess the company you worked for is still around after Y2K and that they made a boat-load of money selling the new features instead of not selling new features and fixing the problem.
I think what's fascinating is that the mentality of "It's too painful to attack" as a security strategy isn't working anymore in the era of AI. A lot of open issues and bugs were kept because folks assumed as long as they were less vulnerable than other folks they would be fine. However I think that paradigm is being phased out since AI can take the pain of sifting through decades of old code for us to find these vulnerabilities.
Time and desire are derivatives of money. Skill, too, largely, though less directly.
Should be something like:
> nobody is paying to find and fix
AI lowers the cost, but certainly doesn't eliminate it. I think we can hope significantly more technical debt will be paid off, but don't expect too much.
Two things are true here. Our decades of rapid-release mentality is now fuel for vulns. Those chosen mistakes we decided can live in the code have directly created holes in the Swiss cheese model. The headline eloquently stated this fact. However the scary part is the inhuman speed of chaining. This is a much bigger problem. The holes in our Swiss cheese now take hours to find instead of weeks.
> As far as anyone is aware, disaster has been averted: The hack was discovered by cybersecurity researchers who reported it to the PHP Foundation, and a patch was released before any bad actors got their hands on the exploit.
Aren't there still vulnerable services right now being hacked?
The amount of e-mails I get of the form "Important information regarding your xxxxx account" (which essentially is just code for "we've been hacked and your data has been stolen") is quite concerning, but not surprising. Security by obscurity was always big in most companies, as long as the bar to carrying out sophisticated attacks was putting a costly IT professional to the task you could be relatively relaxed as no one would bother to hack your stupid little e-shop, but now carrying out such an attack costs a few cents to a few dollars at most, that changes the game entirely and everyone is a target.
This summer I had my Docker registry poisoned with malware artefacts, which again is something that no sane attacker would do before as it required downloading my images, carefully modifying them and then overwriting them, ensuring they work as before. Now it's just a simple prompt away. I am definitely ramping up my defenses, everything that doesn't need to be Internet connected goes behind double VPN and port knocking schemes, essentially making my infrastructure invisible from the outside, all unknown packet types get hard dropped, end-to-end encryption of all internal traffic, web endpoints behind CDN proxies and WAF providers (as much as I hate doing that), double and tripe security mechanisms everywhere, maximum restriction of privileges, ultrafast automated patching and AI based continuous monitoring, audits and interventions. You should also get used to that, this will surely still get much worse as attacker tooling gets better.
Your solution has crossed my mind as well with recent attacks. Default Deny with restricted access paths whenever possible. Generally just doing things meant to be raising the bar for agents to get enough access so they can probe systems. Which unfortunately just sounds like leading us down a path of modernizing Security by Obscurity.
Internet facing devs will continue to have their constant war between defenders and attackers. Still a great deal of IOT stuff that has been connected under the need to "phone home" probably is going to be getting examined more closely. Companies who didn't think about security impacts are now getting forced to face why they needed their appliances connected to the Wi-Fi.
And that's the biggest win with AI. With old-fashioned development, it was considered acceptable to defer addressing valid feedback ad infinitum, hiding behind whatever lousy excuse you could come up with. No more.
What do you think the chance of nonzero budget and time being allocated for this is, given that almost no company has seen real consequences to the business?
This is the same cycle we always go through: big spending on a new wave of tech, something breaks it, and spending shifts to the ones doing the cleanup in the years after as the funding moves to the other side. Y2K created huge growth to the cleanup firms overseas. Y2K didn't break, but it had a clear macro deadline. More recently, cloud cost shock and cyber/ransomware accelerated FinOps and further grew zero-trust security industries respectively. But in the current case, we are waiting for the macro break to happen because AI-found bugs are not creating a visible deadline. And until that happens the spend at the front of the wave won't move to the other side of the wave.
Yep, the takeaway from this should be that we move to leaner applications that can be actually be formally verified. But what I imagine will actually happen is that we'll patch over these vulns with AI that produces 10x the amount of code, just for the next generation of AI to find vulns in that so we can patch that with more code, repeat ad infinitum.
For my part, I have my pet neglects based on observing the parade of hacks: private companies neglecting to fund open source projects upon which they rely; private companies neglecting to fund product security staffing and remediation sufficiently.
Its really the opposite, technical debt isn't bugs, technical debt is if you get AI to generate an application and have barely any understanding of how it works. AI without understanding creates infinite technical debt.
That’s legacy code, not technical debt. BTW. If you leave the company, who will understand your code though? Institutional knowledge always fades away eventually.
Technical debt is something that hinders the ability to understand the code and how changes will impact the code. A hypothetical technical debt-free piece of legacy code could be picked up by a new developer and they'd understand it perfectly after reading it.
Technical debt, as a term, predates AI code generation by at least 30 years. During the last thirty years, when people used this term, security vulnerabilities were definitely in their minds.
I'm not saying the term applies directly to AI, I'm saying AI can create technical debt, you could do the same in the past by outsourcing work with no expertise in-house
These threads with doom and gloom about the modern internet seem full of people who either never experienced or forgot what it was like at the beginning of the century. Back when the internet was fair game to anyone who kinda understood it.
Back then, you could log in as admin to any phpBB forum by copying a generic admin cookie from a shady web site. You could often then also compromise the hosting company that was running the forum, because nothing was really separated.
You would try to trick your friends into installing Sub7 so you could open their CD drive.
You could easily capture other people's data on public wifi networks in restaurants and hotels.
You could change the price of the pizza you were ordering through devtools in your browser.
You could infect half the world by emailing a picture of a blonde tennis player.
Sure, there have been quite a lot of pretty serious zero days recently. But many of them have been pretty hard to actually abuse, in part thanks to all these layers we've added over time. So I guess I'm not as pessimistic as many of you are. Especially because we all seem to be incredibly aware of what's happening and are acting on it.
Implementation of early PayPal was horrific. You would insert a piece of JavaScript which held the price of the item with the PayPal iframe.
The hack was simple enough that you could change the price in the HTML and it could be purchased for that amount. You were suppose to implement verification yourself on checkout but no one did.
Yeah... sorry but that's not a technical problem, that's a business problem.
Everybody wants a $1 Website, avoid security updates, pay nothing for maintenance, and done yesterday.
It has nothing to do with AI or a specific language or stack. As long as cost cutting will be the culture, driven by the economical model of competition, then we will accumulate technical debt BECAUSE it is the strategy.
I was down voted a lot months ago for saying that a lot of open source software had a false sense of being secure with the assumption that someone else would have audited the code. And this AI auditing is going to make the promise of open source software getting audited by others actually real. Nice to see others waking up to this reality.
We were getting routine audits from security companies as well as public universities around the world on our OSS healthcare project. I would say it did give us in some way a false sense of security as we had the belief that a lot of the major bugs were addressed. The last 6 months have been very eye opening as the slew of reports have been difficult due to how many there have been, even with all of the false positives there's been a lot of legitimate vulnerabilities. This has been taxing for us to go through (and humbling as well).
That said, if we were a closed source project, I don't know that our own tooling would have discovered all the issues using LLMs as we are seeing more and more creative ways of people exposing exploits that I never would have thought to put into the LLM prompts.
I always found Linus' Law -- note, coined by ESR, not Linus -- quite... uh... shallow. It seems trivially obvious but is subtly misleading because it makes a quantitative argument ("enough eyeballs") without addressing the qualitative aspect, i.e. whose eyeballs they are matters more than anything.
A 1000 of us regular devs scanning a piece of code is not as effective as a single review by, say, Tavis Ormandy. So "enough eyeballs" is only "enough" when one of those set happens to belong to a Tavis O. or the likes.
Not to mention, this assumes a 1000 of us even look at the code, which is statistically never true. Approximately 100% of us just install the software without looking at a single line of code. Hence the code auditability aspect of open-source software never really applied. And hence, "supply chain attacks."
Unfortunately, this misguided "law" was taken as gospel by many, and as you found out, still is.
If making things in the open was more secure, everyone would post their tank designs online.
Instead they court martial anyone who talks about the designs. Because obviously, telling everyone every aspect of your security isn’t actually more secure. How would you know how to do a 24-step process to exploit something if you have no idea what code is running on their server?
Imagine trying to build a cheat for CS:GO if you had no access to the game and could only play it via a remote connection. Good luck.
There was always, in my mind at least, a tension with Linus's Law ("given enough eyeballs, all bugs are shallow").
It's true but the problem is assuming, just because something is open source, it has received sufficient eyeballs. AI now gives us near unlimited eyeballs so, if we survive the bumpy transition, open source should indeed become very secure compared to closed source.
Except we won't get the expected benefit, because all those eyeballs are attached to a very small number of different "brains" (LLM models.)
The original saying depends on an implicit assumption that eyeballs are proportional to minds, and that among those varied independent scans, different people will catch what others miss.
In other words, we shouldn't assume 5.5x review thoroughness when we hire 11 QA eyeballs but they all belong to Bobby the Beholder.
>and that among those varied independent scans, different people will catch what others miss.
My point was more that very few brains were looking deeply at the long tail of open source code/projects (other than the maintainers of the code themselves); and for the marquee projects that did get proportionally more varied eyeballs (e.g. postgres), it seems even that level of attention was insufficient for code deep inside the project's core.
LLMs change this. They make it much easier for maintainers and motivated users to amplify the power of their eyeballs.
I was thinking about this too, and think it will come down to incentives for attackers and defenders.
Assuming offensive and defensive capabilities are similar, and incentives scale roughly with project size but start from a non-zero value for attackers, I'd expect larger open projects to be well defended by plenty of motivated people, and smaller ones less so (depending on maintainers). Closed source will mostly just depend on maintainers.
Also assuming closed source is less exposed to AI auditing overall, I'd guess large open projects end up more secure than large closed projects, but small open projects possibly less secure than small closed projects, since attackers might have more incentive to target them than defenders do to audit them.
Attackers are always far better resourced. You get six billion if you hack a crypto exchange, you get PIP if you spend time fixing bugs rather than pushing new features.
I doubt this seriously. You're as vulnerable as your worst piece of software.
I'd lean more towards systems that only install diamond-hardened software at all - once you have one project in a class of software that has been analyzed to death, that's the one everybody is going to use.
The vast majority of the development of all projects is going to be (already is) LLM-assisted, so they're going to get analyzed every time they're touched. The odds that huge bugs are going to be lying everywhere to be exploited are bad imo.
I'm starting to rewrite an open source project just because I don't want it to be buggy anymore. I barely want to change anything about it (especially not the licensing.) All I'm doing is porting it to rust from c++ and refactoring it like crazy. I just want to make it easy to audit and extend, and hard to crash, that's it. Once I'm done, I'm already have another (buggy) project in mind to do the exact same thing to. Great UIs and usability, just thwarted by the time that the developers had to invest in them. You could think of them as almost purely security-oriented rewrites.
I think the game theory of relying on open source infrastructure is more complicated and ambiguous than most people have considered.
Using open source source software lets you share responsibility and oversight with a large number of people. But it brings with it a much larger attack surface than you'd have if you only implemented the part of that software that you need, and a much more complicated threat model for supply chain risk.
If a large number of people collaborate on open source software for something, especially if it's security or infrastructure related, that makes the project itself a much higher value target than any individual company's home grown mail server or http proxy client would be. Participation makes your vulnerabilities more public, since interacting with the public open source project, making blog posts or hiring ads mentioning it, hosting it (and thus serving traffic in a way that signals or directly tells clients what implementation it's using), bundling it with your site or binaries, etc. tells prospective hackers 1. how to find potential exploit targets for a general open source vulnerability 2. where to look for or introduce vulnerabilities to pwn a particular target.
AI auditing isn't really a silver bullet because it costs a non-trivial amount of money for each commit or PR, and scales with the number of contributors to a project and the project's size. Normally you want more of those with a software project, but in this case it makes AI auditing more expensive unless it's shared across the project and basically part of its CICD (and I don't think that's really been fully adopted yet). But then that introduces other risks like adversarial payloads where the attacker verifies that the AI security checks in place for a project don't trip when they actually send the malicious code for review, because they can run the same checks offline and tweak the payload until it passes.
Personally I think we're headed toward an outcome where only very challenging, well-resourced, and critical open source software is worth using for developers. For smaller things it makes more sense to just use AI to implement your own version of it, or fork/take inspiration from a project and mold it to fit your needs.
Now think of the advantage for intelligence services having that framing in the public mindshare. Probably all sorts of vulnerabilities in open source tooling these communities depend upon. Probably whole campaigns out there to stifle awareness of them as well and preserve the easy already found golden goose as long as possible, as well as campaigns to advertise and entrench the backdoored tools. I wonder how much collusion like this is out there? We won’t find out for 40 years in either case whenever this stuff is FOIA’ed if it even can be.
I don't think they're suggesting that, rather that the "more eyeballs" quote is a bit flawed (in that not every project gets enough eyeballs). A thing can still be better then another thing and not be perfect.
I don't agree that it was an assumption as part of open source, but that it was a possibility with open source. However, there are lots of assumptions made about computer software in general - part of the problem is having cognitive models of software that aren't necessarily reflected in how the hardware runs code.
Also, closed source software can similarly be analysed with AI, but there's no guarantee that the company involved will deal responsibly with disclosures.
I do not have an example for this, but the most ridiculous argument for open source software (at lease for most people) has always been that if the software has a bug you could simply fix it yourself. Funny enough this has actually become kind of true with new LLMs.
Did you not fix bugs in the oss you run, pre-LLM? Or not bugs, just your own changes? Being able to just grab the source and tweak it without needing to try to RE or wait around or convince the owners/developers to do something I wanted to happen was one of the biggest selling points.
I can't help but feel a lack of investment in new product and feature work.
Instead we're spending the time churning out busy work fixing bugs that were too low value to care about a year ago. We have a new street lamp so we're working on anything it illuminates.
I haven't really seen the same kind of push towards verifiable software. It's mostly around solutions that will perpetually burn tokens and justify usage of the new toys.
Mine is a cynical take for sure but I honestly really miss meaningful feature work but that's not what the market's interested in right now, I guess
And PHP is developed by humans, at least it used to be. No idea about now. Now imagine the security landscape when all code is generated. AI will find dozens more vulnerabilities in the code that only robots are responsible for. If the bubble doesn't pop soon, it's going to be a nightmare in a year or less. Hackers win, everybody loses.
Another way to look at it is that companies who have let their software development teams go while keeping their software alive are bound to face a reckoning, as AI will inevitably expose their skeletons.
It's not technical debt. It's lack of engineering rigor.
Bridges don't get driven on until they're inspected. And they only pass inspection if they were built according to standards, and meet design specifications that have to take safety into account.
How we get there, how we enforce it, is another conversation. The point is that we have to start getting serious and be real engineers. The bare minimum standard should be that you can drive a truck over it without worry. How much software can you confidently say that about?
The framing of using PHP as a legacy technology is the greatest sin of this article and they can't be freed of it.
I'm not a PHP person, but so much of the world actively runs on it silently.
All technologies have gaps. PHP was affected differently not because it's old, but because it's so ubiquitous. Python is as old, so is Javascript, and many others.
Maybe now developers will stop fighting tooth and nail to not update libraries and programming language runtimes and so on.
At my current day job, if I mention “hey, how about you update PHP to at least a supported version” people start whining about how that takes a lot of time and if really anyone would try to attack our public facing services written in… PHP.
Next time we get hit I can sit back, eat some popcorn and say “told ya’”.
It also inflated almost all of that debt away, though. So in a way people who built "just ship it" buggy things in the last few years, made the right bet.
I think we'll look back at this moment as peak C/C++ before they begin a long, slow decline into irrelevance.
I've been bullish on Rust for years because memory safety is simply too important and Rust can essentially prove an implementation correct and solve a certain class of very important bugs. It doesn't solve every problem and there is a complexity cost.
I've also said that writing multithreaded code is simply too complex. In an era of out-of-order execution, different levels of caching, asymmetric cores, hyperthreading (although this is largely dead now?), branch prediction and having to support multiple architectures it's simply too hard for most people to write correct multithreaded code. Period. If you find yourself as a non-library developer creating a mutex or spawning a thread, somebody has screwed up.
This is also why I think the single-threaded async/await model with post-request teardown of PHP is the correct choice for most people.
We're going to go through a dark period of a lot of 0days. As the article notes, this is paying 40 years of technical debt. It will result in a more secure ecosystem however. I believe this will ultimately also hamper black markets, governments and 3 letter agencies who trade in those 0days.
As painful as this all is, it will ultimately be a good thing, one of the few to come out of AI (IMHO).
I'm not going to lie, I'm having a great time thinking at the endless discussions around unsafe languages and the relentless smugness of many practitioners claiming everything was fine as long as the responsible and the skilled (them) were in charge; and let's not forget the formulaic "with great power comes great responsibility" closers.
Well now, Great Responsibles, it's clear you too were out of your collective depth and were all paying for your smug hubris. Perhaps take a bite out of that humble pie you've obviously never tasted?
Well, the title is a bit strange. People are poking fun at PHP,
I do too - but ... if PHP were totally useless, nothing would be
affected as nobody would use it. But many servers use PHP and
there is good software written in PHP too. I know that because
when servers were patched, and taken down, a lot of stuff suddenly
no longer worked. That included universities as well as some other
websites. So I think the term "technical debt" is strange. PHP
is written in C. Would PHP be better if written in Rust? That's
not so easy to answer, but all things being equal, it may be that
PHP would have fewer issues if it would have been written in Rust.
I think one should, of course, be critical of those who write C
code for PHP, but at the end of the day, some part of that criticism
also goes to C. C is both a king and a problem. And it seems very
hard to fix the problems of C.
This is like a godsent! I have been secretly wishing for everyone to take a few months, stop developing new pointless and mostly enshittifying changes, and just work on fixing current issues. I wasn't thinking so much about security, but rather old and rather well known long term bugs. If AI is finally forcing us to deal with long term issues, all the better. If we happen to end up fixing a bunch of 0-days some people were secretly sitting on, go go go!
> PHP, which originally stood for “personal home page,” is a programming language created back in 1994 and largely used by legacy sites.
Wow. Love it or hate it, but tell me you have no idea what PHP's place in the web ecosystem is without telling me you have no idea what PHP's place in the web ecosystem is.
You're joking right? I work on a place public software product and over its ~15 year life we've gotten over half of validated vulnerability reports that we have ever had on it within the last year. We basically had to stop feature development for 6 months to burn that down, even with AI providing correct fixes for 80% of the vulnerabilities that were reported.
I hope some of these backdoors and/or 0-days being kept under wraps by nation states or corporate espionage companies (Pegasus et al) are being found incidentally through all this.
It’s frustrating to have all these 0days and CVEs to patch for now, but in the long run perhaps we’ll leave with more robust software.
The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the pretense of "software engineering" into reality, making the engineering part explicit.
That only works when humans actually understand what they're doing.
> "I have only proven [my code] correct, not bug free."
> -- Donald Knuth (if I recall that exact quote correctly)
Just because you have proven the correctness of your code, that does not mean that it is infallible. Especially -- as a lot of HN users point out -- there's intricate complexity that is likely to cause erroneous behavior if several interfaces/complexities get combined. And those might be caused, for example by a 'user' setting the driver to 'db.backend.sqlite' instead of 'db.backend.sqlite3'; and then you have suddenly an unexpected configuration.
Were you aiming for this? “Program testing can be used to show the presence of bugs, but never to show their absence!” ― Edsger W. Dijkstra
Or the second one, that I would have attributed to Dijkstra, too: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” C.A.R. Hoare, The 1980 ACM Turing Award Lecture
No, it's Knuth. The exact quote is "Beware of bugs in the above code; I have only proved it correct, not tried it." [1]
[1]: https://staff.fnwi.uva.nl/p.vanemdeboas/knuthnote.pdf
Yes, you can also easily prove the wrong thing.
That's why it doesn't suffice for only LLMs to know the relevant stuff.
You can't have a zoo run by animals.
Aren't all zoos technically run by animals? :D.
apt, as we try to contain the complexity of our designs while being ourselves panarchical hyper-systems
Unrelated but "Panarchical Hypersystems" makes for a great company name
Or a rock band. (With a nod to Dave Barry.)
Dovetails with it sounding like a secret society/esoteric superweapon monopoly corp from a Daisuke Ishiwatari joint.
On that note, "Esoteric Superweapon Monopoly Corp" would also make a great band name.
Lower intelligence animals....oh wait
I once saw an interview with a guy that designed garbage cans for National Parks. When asked what the hardest part of the job was he said, “accounting for the considerable overlap between the dumbest humans and the smartest bears”.
For months after some researchers “proved” our code signing system sound I was still finding security holes in the system. To this day I’m not sure what they proved. That the architecture worked? We’d already proven that to a hundred people.
Correct, because when there was no LLMs all code was perfect and bug free.
Just because you have proven the correctness of your code, that does not mean that it is infallible.
Can god make a zero-day even he can't find?
Most bad crypto code in the world is unbreakable by it's creator.
This doesn't necessarily require proving everything mathematically, it also helps to design things in a way that doesn't rely on discipline to avoid gaping holes. For example, languages that allow pointer arithmetic, unchecked array access, or use-after-free have huge opportunities to make security errors that don't exist in languages without them.
A problem I frequently have with setting up testing policies is in convincing people to test what they can reliably test with the tools, and know what they cannot test.
Inconclusive tests to increase automation and coverage accomplish less than nothing. The opportunity cost, the loss of trust, the conflation of the manual testing surface area, are all worse than doing nothing.
The point of testing is to establish a level of trust. That level doesn’t need to be 100%. It can’t be 100% regardless. So you do what you can, and you solve the remaining problem a different way. But you need to know it’s there to address it, and the smoke and mirrors fight that.
I used to work for a company that enforced 80% code coverage for our CI/CD pipelines. Both teams I worked with there, in wildly different parts of the company, were playing games with excluding most files in the repo and writing dozens of tests that didn't actually test anything, just ran the code in the testing container so the lines would count as having been tested. I think LLMs have probably cleaned it all up a lot in the end, because the tests they write do actually test the code (against the code at the point you told the LLM to write the test a lot of the time, rather than a third party spec, but at least it's not just return true all the time).
Every 6 months there was a new testing initiative, which seemed to all be responded to by writing wrappers that returned true to the test automation system we were ordered to use.
Seems like a culture problem at both ends of the org.
Using these languages is pretty close to a mathematical proof.
> For example, languages that allow pointer arithmetic, unchecked array access, or use-after-free have huge opportunities to make security errors
All languages are built on top of an ISA, whether directly (assembler), or by mapping it to an abstract machine. The you have the dreaded “eval” function. Then because a lot of software lives on top of an OS, there’s all the virtualization that is going on (timesharing, virtual memory, filesystems,…). Memory safety is nice, but it doesn’t help you when the attacker send valid, but malicious data from a compromised source, or by exploiting a logic error.
And for kernel code, where everything is accessible to everyone, it’s much a matter of discipline, especially with so much hardware interrupts and syscalls from userspace going around. Most kernel code has very short lifecycle, it’s the data that is long lived, and it’s a shapeless blob in memory that you have to trust the other party kept in good shape.
Play a bit with it, I started feeling like verification is just a slightly more aggressive fuzzer.
There will also be compiler bugs, etc.
The point is fewer bugs.
At least in some cases it is easier to verify bytecode/assembly than source code.
> Just because you have proven the correctness of your code, that does not mean that it is infallible.
Yes, but it gets you pretty far already.
Just because it works doesn’t mean it’s not broken.
Anyone who has ever wielded a wrench should know that implicitly.
If the user is capable of setting an option which breaks everything then your code isn’t correct.
That’s the whole point, you can find all of these things which would take far too much manual effort.
The zero, one, infinity rule isn't directly relevant here but it's close enough to be worth mentioning IMO.
https://en.wikipedia.org/wiki/Zero-one-infinity_rule
The rule is about data structures but I feel it has wider applicability user choices in software. You should either give the user no choices, give them individual binary choices, or let them pick anything that could theoretically be valid and design your system to assume they'll sometimes pick invalid options which will need to be handled appropriately.
Here the user was the deployer and presumably owner of the deployment. An overall setup is only correct if they and the software define a setup that happens to be correct. The software is incorrect if it doesn't support the incorrect setup they require.
> The software is incorrect if it doesn't support the incorrect setup they require.
Is that what you intended to type?
Software is not required to support the requirements of every potential user. Only the ones they mean to support. That’s why Porsche and BMW ignore people complaining about how expensive they are. You aren’t their customer and they don’t want you.
A family of eight who buys a (classic) Porsche bought an incorrect car unless it is for an expensive gag like putting sugar in the gas tank then an EV would be incorrect, no?
As written you have stated that Porsche is wrong for ignoring this family's complaints. Because they didn't support an unsupported configuration.
You are confusing the wants of a manufacturer with a system that is being used by a person. The person owns the system that is either correct or incorrect for their needs and the manufacturer takes money and screws off. Or, you have the "soup Nazi" as proposed with the manufacturer makes sure you use the system as they imagined and not with a database setup beyond their control.
The user may be capable of undervolting the logic, issuing directed EM attacks, accessing JTAG, etc. Good luck.
The user doesn't have to be someone that grew up on Defcon talks and CTFs anymore though. Any Joe/Jane off the street can ask an LLM what is a JTAG or what is a 90 nop and keep asking until they're satisfied. So we have to assume the user is capable of all of those things.
I mean, he wasn’t using, or even envisaging, a language that could natively support proofs.
Personally I think proving Kubernetes, for instance, would be an exercise in pure frustration. There’s just too much to do.
Knuth seemed more interested in Tony’s notion of “obviously no bugs”. There always seemed to me to be a self-evident flavor to his literate code notions.
I say that as someone who sees Knuth as problematic in other respects starting in the 2010’s. Physics governs so much of computational complexity now that I think the idealized form he presents has transitioned from merely holding us back to being crippling. Only game designers, hyperscalers, and an esoteric few of the rest of us seem to understand the vast gulf between theory and practice that has developed in the five orders of magnitude that compute power has experienced since his first edition.
Many, many things that are considered constant in his world are instead logarithmic to the size of the data being managed, or in the case of very large data sets, order n^1/2 because of speed of light and thermodynamics. That vastly reorders the toolbox, because second shelf algorithms now rival or beat the top shelf ones and some options even farther down now become interesting for novel situations.
huh. Interesting background. Thanks for sharing.
Regarding your remark "[...] because second shelf algorithms now rival or beat the top shelf ones [...]". That is honestly something I would never have believed back in the 2000s, Windows XP era:
I thought we needed more than the classic mathematical operations and if/else for an operating system that drives the modern world like it had been envisioned by sci-fi in the past 100 years.
That turned out to be wrong: Your modern android with a couple of simple apps is everything a man from 1900 might ever conceivably want from technology.
And it is all if/else/while and mathematical operations.
It turned out you just needed enough of these, to get everything working nicely.
Watching in awe. Watching in awe.
Maybe that says something about kubernetes. Software systems that are complex enough to be intractable should probably be regarded as too complex to operate safely.
No, most software is this way.
https://www.galois.com/articles/specifications-dont-exist
I don't fully understand what you're objecting to. Are you saying it's not possible to build a formally verified container orchestration thing?
I do think that most software out there is unsafe. That doesn't make it useless, but if the effort required to exploit vulnerabilities is decreasing we will probably need to stop building things that way.
Which implies that software engineers in the future won't be so cavalier in allowing mod-able or unix-like systems. There won't be an db.backend.sqlite since your software likely won't use a db, and if it does it will be a custom design. It won't be "if several interfaces" it will be "there are no interfaces" no programmer interfaces and certainly no user ones.
> The only way to do that is to make your code provable. That again is only realistically doable using AI.
I think that LLMs actually cannot do this right now while people can?
Also there is a lot of defensive programming that has been left to application and runtime layers because of dated security models in our OS and permissions that are way too coarse. It's a lot easier to write a correct program when you don't have to check every path and do that perfectly when the permission system can ensure that no files that haven't been whitelisted cannot be read
My intuition is the opposite? The math results we are seeing lately are done with theorem provers. LLMs are getting very good at this and surpassing what humans have been able to prove. Verified code is traditionally very expensive and only applicable in niche areas when done by humans.
> LLMs are getting very good at this and surpassing what humans have been able to prove.
But if the reverse were true it would be impossible to prove. AI is trained on all of humanities solutions - LLMs stand on the shoulders of giants, not the other way around.
As of today, the training data the originates from humans represents a vanishingly small portion of the total training. The vast majority of training - how many 9’s is a trade secret - of a frontier model is synthetic RLVR data. That’s how they got good at this.
I thought only like a third (maybe 2/3?) of the training was RLVR?
We do, too, as we have also been trained from the same prior solutions.
LLMs can, in principle, do everything humans can. And arguably more. "Right now" is how long? People are slow.
"Provable" essentially means, you have explicit operators acting on explicit states in an exhaustively defined way that preserves "truth", explicitly defined invariants.
A finite thing you can argue over deterministically.
Obviously, "you" there is an LLM, the machine your code is run on has to be defined in that very same exacting manner and so on.
That still isn't enough, you need abstraction, a hierarchy of categories that preserve your intent and accurately describe the problem space.
"Programming" then is solving an inverse problem over that hierarchy, filling in the blanks sensibly on your way down through the model hierarchy, all the way to atomic instructions your (proven) hardware understands.
Those layers of proper abstraction is what's largely missing currently. Or rather, is merely vaguely approximated.
All of which is to say: yes, the current state is a mess. Resolving that is far from easy.
But you really have no choice, that mess is transparent to large-enough LLMs. Security by obscurity only goes so far.
> But you really have no choice, that mess is transparent to large-enough LLMs.
It's transparent to large-enough LLMs given enough resources. Which is the thing that was always true. The difference now is that the level of resources is lower, so we're finding a bunch of things it wasn't previously economical to find.
But the cost still isn't zero. On top of that, the same LLMs are now generating enormous volumes of new code, which both nobody has verified to that level of exaction and nobody has even considered how it interacts with existing and other new code.
> Those layers of proper abstraction is what's largely missing currently. Or rather, is merely vaguely approximated.
This I can agree with, and my perspective would be that we have theoretical solutions with no ergonomics, and rely on unproven (as in formally proven/validated) mechanisms. WASM + capability passing is enough, but the WASM layer is still built on an OS or runtime that is not proven and you'll have a heck of a time trying to build a product on it
LLMs can't do a backflip. I can.
I can’t do a backflip. I guess I’m subservient to LLMs then.
Unitree's H2-X can.
https://youtu.be/Y3zb4o47yqA
is unitree h2-x an llm?
> LLMs can, in principle, do everything humans can.
I think narrowing the scope of this statement would better support your argument, as it is easily disproved in its current form.
> LLMs can, in principle, do everything humans can.
Oh yeah? slides baton Pick up that can, Clanker.
Jokes aside, I do want to see the first news of AI going out of its way to acquire and make use of actual currency and hiring a meat proxy. I don't even care what for, can be making paperclips.
The first such news is pretty old: In ARC's 2023 eval of GPT-4, it hired a TaskRabbit worker to bypass a CAPTCHA out of the small research budget allocated to the agent. Even the rentahuman.ai site which forms a market for meat puppets is kinda old now.
https://bend-lang.com/
Folks are creating some interesting stuff in this space
While I whole-heartedly support the goal of actually bug free software and treating software engineering as a serious engineering discipline, as an experienced software engineer who also studied physics, I have to challenge your base premise about what it means to make engineering explicit.
Namely:
> The only way to do that is to make your code provable.
Proofs are a mathematical concept. They only work in the abstract world of mathematics where everything is perfectly logical.
Engineering exists in the real world. The physical realm where our mathematics are only imperfect models of what actually exists. Removing bugs through physical engineering requires persistent trial and error until you have found all the places where our mathematical models don't adequately represent the real world.
It's the same in software engineering, which involves cobbling together a myriad of systems not all designed to talk to each other and massive, ever changing codebases where perfect knowledge is impossible.
So yes, we should be trying to engineer bug free code. But that's really more a matter of changing our resource allocation, spending more time and money on QA and doing away with mottos like "Move fast and break things". It's a cultural shift and will only come when the bosses -- the venture capitalists who ultimately control our industry -- are held accountable when things break, and given strong incentives to ensure they don't break.
> It's a cultural shift and will only come when the bosses -- the venture capitalists who ultimately control our industry -- are held accountable when things break, and given strong incentives to ensure they don't break.
The problem here is that the correct amount of resources is context-dependent.
Suppose you're a small business and you're putting up a website to display the menu for your restaurant and directions to get there. Do you want it to get compromised? Of course not. Does it matter very much if it does? Eh. Should you spend $50M in formal verification to make sure it doesn't? Definitely not.
Whereas if you're developing the software that keeps planes from falling out of the sky, that's an entirely different context.
The problem comes when someone grabs the awful WordPress junk that was suitable for displaying static menus and wants to use it to process credit cards. But even that isn't really the fault of the awful WordPress junk, it's the fault of the credit card companies for designing their financial technology in such a ridiculous way that Merchant A has to be given a secret that allow purchases to be made against the same card at Merchant B, instead of using the decades-old cryptography that would prevent the customer from ever needing to give anyone a secret that enables that wide a scope of compromise.
It comes down to how much work is justified to ensure that the thing not have problems, which is not at all the same across different domains.
The physical world is actually part of mathematics. Look into John Archibald Wheeler and his "It from bit". In particular, the physical world is finite. Therefore, mathematical proofs very much apply to physics.
You're right about approximations: we gather data and improve theoretical models in an attempt to exhaust that complexity reality poses.
You're wrong about exhaustive knowledge about codebases being impossible. LLMs enable exactly that.
The trick then is to transfer that knowledge in a usable way to what we know about the codebase.
I agree with the necessary cultural shift.
Keep in mind, a mathematical proof is just "an argument that convinces a mathematician".
It doesn't actually give you the truth of a statement, it just convinces a mathematician of its truth.
That doesn't actually change when computers are brought into things. You can convince a mathematician that an automatic theorem prover constructs correct proofs with another proof, but it's "I think this looks right" all the way down.
No, you're incorrect. A mathematical proof actually is a program by the Curry-Howard correspondence.
Mathematicians are trained to act as the compiler, verifying the code, doing the type checks, and to a degree the state machine "running" those programs.
Human mathematicians use introspection to tell you whether a proof/program does what it is supposed to do. They keep those programs small enough to be run on human brains by modularization, abstracting away complexity behind defined interfaces. They mostly rely on other mathematicians to have checked those sub-modules properly.
By defining that state machine, compiler and the tree of "all" known proofs as programs explicitly on a computer, you get Lean and the according libraries of verified proofs.
A proof-program there is verified when it compiles and passes the deterministic structural type-checks built into the language while fulfilling the requirements stated for its interface.
It all reduces to a few thousand lines of trusted code, the Lean kernel, being correct. It's mostly what humans do too, but actually considerably more thorough.
In many other engineering disciplines there is also an element of licensing and personal liability that I don’t see happening in software.
A PE for software engineering was available for a while: https://ncees.org/ncees-discontinuing-pe-software-engineerin...
But there wasn't enough demand and it was discontinued.
The legal framework for software liability is tightening. The Cyber Resilience Act is one such example that forces developers to get their act together.
Back when I worked at Boeing, I was encouraged to get a PE license. I looked into it. I was not impressed with the exam (it was too basic), nor the requirements, and so did not bother.
This is a zero-value post.
"I decided for myself that X wasn't worth me pursuing as a path for my career." Good for you.
I made the same decision for professional photography and cardiac surgery, but both of those careers still hold value to society.
The point was that the PE cert is a low bar as an indication of competence.
Engineering is the discipline of designing and implementing solutions that achieve desired outcomes, using limited resources, while satisfying a defined set of constraints and minimum acceptable standards.
We have way more resources now to achieve way higher standards.
As a general rule, building things as an engineering project (according to engineering, whatever you want to call it) doesn't prove they work. Rather, it proves they don't fail in specific known/defined ways. There's always ways they can fail that aren't known/checked, and frequently ways that aren't considered important.
Kind of like automated tests in software development. Except the people that pay for the engineering stuff are more likely to pay for the extra tests, because of liability.
You’re twisting words here.
If a new jet completes extensive flight testing and has flown around the world but has undiscovered engineering flaws, “it’s working”.
Meeting verification and validation requirements in a sound engineering development program should certainly get you to “it’s working”, whether there are undiscovered engineering flaws or not.
Anything men build is subject to failure and unknown unknowns - so nothing works?
Engineering is the application of science and mathematics to solve problems and create solutions… that “application of science and mathematics” is what’s been missing from the majority these last 20 years.
I don't think so. The article refers to formal verification, but also notes that proof checking should be done by humans. We don't have enough capable humans for that.
Looks like AI is finally proving Linus's Law[1]: "given enough eyeballs, all bugs are shallow"
Open Source was supposed to prove this, but as it turns out, there weren't enough human eyeballs, and those eyeballs weren't looking for bugs. LLMs eyeballs see the entire codebase at once.
1: https://en.wikipedia.org/wiki/Linus%27s_law
The corollary is that given shallow enough eyes, all bugs are deep.
A mostly useless platitude since the solution is to simply not include only terrible reviewers as 100% of your staff in 100% of situations.
make no mistakes
No software of normal complexity can be "provable". There will always be bugs no matter the strength of the AI.
Normal in some cases might be far from what was really needed. Perhaps the two kinds of software can grow further appart?
The quote was, "Beware of bugs in the above code; I have only proved it correct, not tried it."
The quote captured the fact that a human reviewed proof could have mistakes in it. This is very different from a Lean verified proof.
> That again is only realistically doable using AI
The opposite. The amount of bugs that I've seen AI add to software is tremendous, some bugs are things that even a 18 years old that starts working as a developer right after school wouldn't do.
Also they are unable to fix them, if you ask them to fix a bug they probably introduce 3 other more, and so on, and you arrive quickly at the point that the code is a mess of spaghetti that needs to be rewritten completely (by a human, this time).
On the opposite side AI is good at finding bugs, so I use it more as an advanced linter that tells me if I'm doing something wrong.
You’re describing vibe coding and GP is describing systems for proving correctness.
If you ask an AI to generate a novel math proof, it will inevitably produce garbage. If you give it the tools to do this (e.g. Lean), evidence is that it can in fact generate meaningful proofs.
To the extent that we cannot prove software correct, this is probably largely a tooling problem.
“tooling problem” makes it sound trivial, its a tooling problem like building a quantum computer is a tooling problem. Ie something that probably won’t be solved in our lifetime
> something that probably won’t be solved in our lifetime
If you told me five years ago that AI would eventually be generating novel math proofs, I probably would’ve said that it’s not happening in my lifetime. And yet here we are.
I don’t know what it looks like to get to fully provable code, but I don’t see that it’s fundamentally impossible in my lifetime. Especially depending on scope. Will an entire operating system and everything on it be fully proven correct in my lifetime? Maybe not. Could the authentication stack for a product be entirely proven correct? Sure. I can’t believe that.
> If you told me five years ago that AI would eventually be generating novel math proofs, I probably would’ve said that it’s not happening in my lifetime. And yet here we are.
A single PC can solve a very complex simulation model in seconds, something that would require years using humans to do. Same as solving a very complicated maze. So if coupling a text generator with a proof verifier is now capable of coming up with a proof, I’m not particularly surprised. But given the cost, and the actual usefulness of the proof, I’m not particularly excited either.
But code is not a closed system, even if we do prove a lot of the internal mechanism, we still can’t know the input (noise), and whether the axiomatic foundation will hold. That’s the reason people don’t bother. The theory of computation is just too loose in its constraints. You just write enough tests to catch egregious errors.
> we still can’t know the input (noise)
Doesn't matter. Just like you can prove something is true for all numbers, you can prove something is true for all possible inputs.
> But code is not a closed system
Code is absolutely a closed system.
"Software" might not be, and definitely not software systems -- but code can have each part of it atomically proven to be correct, assuming you test it with a sufficiently complex simulation model (which you've already granted is within the possibilities for LLMs).
Prove all the code in the software system correct, then prove their interactions are correct, and you've achieved your goal.
(I won't claim this is inevitable with the current tools, but it's at least within the realm of possibility)
You should try AI out, it’s a lot more capable than it was when most people formed their opinion a few years ago.
What model are you talking about when you say this? "AI" is not one thing, and if you think frontier models are at all comparable to a typical 18yo SWE, you've never actually worked with one of those two.
Most bugs are not security issues and most potential security issues aren’t exploitable. So you can have plenty of bugs in your code without getting hacked.
> The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
> The only way to do that is to make your code provable. That again is only realistically doable using AI.
If you're code is "provable" doesn't that only mean you've proved the code meets its specification? The specification can still have bugs.
Yes, that's where the "engineering" part comes in.
Engineering builds models that approximate the real world under practical considerations. You e.g. have to weigh costs vs risks and apply good judgement.
In essence, you try to achieve the best possible with the resources you've got.
You are describing the difference between Verification (Does this do what we explicitly said it would do?) and Validation (Does this do what we wanted to achieve?). One is about compliance of design promises, and the other covers the issue that the various levels of design documents might have failed to completely capture intent.
If mathematics serves as a example, the tools were there, but so tedious and unenjoyable to use it took AI to actually make their usage a reality.
Clanker doesn't care it's boring or too much work. Clanker just grinds 24/7.
How do you prove the correctness of your theorem prover?
Depends which way you mean. It is possible to provide a formal specification for a proof verification engine and prove, in the same language that the engine is for, that the engine implements that specification.
Proving that the system it implements is like, logically sound, is a different issue, and for that you do need stronger axioms.
Software could be bug-free without being proven?
>> The only way to do that is to make your code provable.
Extreme naivety alarm... Explain how code provable allows for bug free software. Would love to understand the intellectual jump there.
Just like we make bridges and buildings “provable”?
People aren't using AI to relentlessly attack bridges and buildings with adversarial earthquakes from the other side of the country.
But also I would bet those undergo more rigorous testing than a lot of software.
Buildings and bridges have very large safety margins, to account for design errors, construction errors, damage, poor materials, etc.
Airplanes have much smaller safety margins, meaning a lot more calculation is done, and there's a high emphasis on double checking everything.
Spacecraft have tiny safety margins, which amps up the design rigor to 11.
Airplanes and srarcrafts are operated by a trained trusted crew. Software is operated continuously by lots of hostile people and machines.
When terrorists take the control of a plane, it's a catastrophe.
On the contrary - this is explicitly the mission of most military organizations. There are countries in the world today where every day their bridges and buildings face adversarial attacks from state level threat actors.
The difference is, people who build civilian bridges and buildings are not actually generally expected to build structures that can withstand such attacks because preventing those attacks is considered the government’s job.
So no, they typically don’t undergo ‘more rigorous testing’ than software against security threats. The fact that governments make no effort to protect networked systems from being attacked places the burden of withstanding those attacks fully on the private civilian operators.
In an important way bridges and buildings are indeed proven to be sound by applying the mathematical tools of structural engineering, materials science, etc. Software Engineering also has analogous formal tools at its disposal (Lean is one gaining a lot of exposure these days), but many were being neglected because it wasn't worth the bother. In this new adversarial world, we'll be forced to reach for them more often. Luckily the models are also a big help in making these tools more approachable.
> It’s frustrating to have all these 0days and CVEs to patch for now, but in the long run perhaps we’ll leave with more robust software.
I'm skeptical; every line of code is a liability. Humans regularly make the trade-off between adding lines of code vs doing without the incremental feature addition. LLMs don't; everything gets added.
The recent brotli attack should have been a wakeup call - few people use it, no one actually needs it, but the exploit that it carried was present on every system. Everything from IIS to Caddy and in-between, and yet no one was actually using the thing.
It's a liability to add code, whether you're duplicating existing code in the codebase or adding a feature 1% will use.
> LLMs don't; everything gets added.
LLMs can run with whatever directive you give them. If the directive is lots of code that's what you get. But when everyone gets repeatedly burned by vulnerabilities the directive becomes building bullet-proof code. With the right prompting an LLM can be a lot more diligent about that than we ever could.
This is like saying humans just shouldn't gamble or drink or have sex with the wrong people.
It might be true but it's also a pointless statement that doesn't impact the problem, because it won't happen. And "it won't happen" isn't some unsupported prediction that no one can say. The aggregate behaviour of humans is a known thing, and it's not productive to the actual problem to pretend otherwise. It's only productive an individual looking for an easy excuse to avoid dealing with the problem.
Uh, I'm literally asking LLMs to shorten code daily. Sure not everyone will but I think the point is that LLMs likely do make it possible to write far more robust and secure software, including short code, if the user wants to.
I was really surprised that "sudo" command depends on "protobuf": https://ubuntu.com/security/notices/USN-5811-1
> LLMs don't; everything gets added.
By default, yes. But you don't have to let them, and enforcing some code quality was shown to use significantly fewer tokens (can't find the link now).
Hopefully we'll also see us back to KISS principles too. But who am I kidding
What I have heard from AI it is anything but KISS... More features and more code as fast as machinelly possible.
It doesn't have to be that way. You can use llms to greatly improve the quality of the code. You do this by focusing on one part of the design use the LLM to explore alternatives, use it to poke holes in what you have. I think the engineering cultures that embrace this way of using AI will far outperform everyone else in the long term.
I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later - because the time to test the possible regression cases of the original code wasn't available right now.
I could have worked through all that on my own, but having the AI as a rubber duck to talk to - plus the edge cases it was able to point out - was really helpful.
> I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later
I wonder if a refactor is even necessary.
Concepts like KISS, DRY, etc. are largely human-centric. They're meant to make code easier to write, understand, and maintain - for people.
Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
But with coding agents, some of those tradeoffs start to change. An agent can find and update duplicate implementations in seconds. It doesn't need to maintain the same mental map of a codebase that a human does.
And if we have good specifications and comprehensive tests, behavioral divergence should be detectable and correctable. In fact, duplication can offer an advantage over shared abstractions: isolation. Changes to one implementation don't risk breaking unrelated consumers of shared code, and each implementation can evolve independently.
Maybe we won't need as many high-level abstractions, or eventually even some of the architectural patterns we consider best practices today.
If the cost of writing and maintaining code approaches zero, perhaps we should optimize less for human readability and more for runtime performance, memory efficiency, isolation, and correctness.
We might even regain some CPU and memory efficiency by eliminating layers of indirection, virtual calls, and abstractions that primarily existed to make code manageable for humans.
Perhaps the optimal architecture for AI-maintained software is fundamentally different from the optimal architecture for human-maintained software.
A lot of our software engineering best practices are based on the economics/ergonomics of human maintenance. What happens when those fundamentally change?
> Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
Until proven wrong by coding agents, this is still the case even for agents. Not sure why you are assuming this doesn't apply for the machine
I cannot read a 50-page T&C document. I mean, obviously, I can physically do it, but I don't have the patience, and I'd lose track of what I'd read. Getting an LLM to summarise a 50-page T&C document is simple, it doesn't lose track, and it spits out a summary in seconds.
I cannot read a 50K LOC code base at once. I mean, obviously, I can physically do it, but I don't have the patience, etc. I need mental shortcuts like abstractions layers to hold even parts of the code base in my head. LLMs don't. They can read that in seconds and hold the whole thing in context.
This doesn’t really support the argument that KISS et al don’t apply to LLMs. They may not ‘need’ these principles for the same reasons as humans, but will still benefit from the context having higher information density.
>because the time to test the possible regression cases of the original code wasn't available right now.
The models don't know that they're not human when they estimate. It's worth telling them that all estimates need to be made in the context of an agentic AI doing the work.
It's funny, I've had similar conversations, where the agent would recommend the 'lazy' solution because the robust one took too long. More often than not, it was assuming human-hours of work though. Once reminded that a clanker would be doing the work it's conclusion shifted to the robust one.
Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.
It’s jarring when the bot tells you something will take a “week of work”. A good reminder I guess that it doesn’t have self awareness as we usually think of it.
Sounds like Reddit and Stackoverflow leaking out the training set
Yeah, I've seen that, too. In my case it was less about the dev time and more about the regression testing time (much of which would fall on QA and involved reading from external feeds, etc - so, complicated). But your point is fair. The AI is ... notoriously bad at LOE. Not that it's always wrong, but frequently enough (and by a large enough amount) that tradeoffs like that really need humans considering them.
People complain about LLMs not respecting KISS, but fail to address why = LLMs being defensive and coding for situations that either do not happen or are unlikely to happen. That doesn't absolve you from deciding using your human brain if given change makes sense or doesn't. You can also tell LLMs to not program defensively.
Same with any other acronyms - if you don't set up guardrails on when given principle should apply you'll get code that you can only complain about.
My complaint is that LLMs’ approach to making code robust is something we used to pejoratively describe as “enterprisey”.
Oftentimes there are two broad ways to fix a gap in the logic. You can eliminate the source of it, which often involves refactoring but tends to result in less code and cleaner, more comprehensible logic. Or you can leave the gap there, but attempt to render it safe by adding extra logic to detect and handle the error condition. This reduces changes to existing code, but makes the overall system more complicated.
You can’t just indiscriminately favor one approach. Which one of those is best depends on the situation. The deciding factor is often something like a time constraint that you can’t know just by reading the code. You might need to talk to your team before deciding.
But LLMs don’t do that. They always choose option B: slap a bandage on it. Keep on adding more epicycles. In the 2000s we learned that, over time, always choosing this approach inexorably leads to codebases that are brittle, bloated and expensive to maintain.
So the problem, from my perspective, isn’t that we shouldn’t be coding defensively. It’s that LLMs encourage us to do it in a way that we’ve already learned is unsustainable.
Agree. It should fall on to developers to decide what to do = whether tackling tech debt is viable solution (whether making decision on their own or talking to people that can make such decision) or not. If, however, you're told "here is a codebase that you're seeing for first time, fix this error" and you simply cannot make the decision, even prior to LLMs you'd put a bandaid on it. Or at least - that's the standard approach = fix now, refactor later, where later in my experience never happens (sorry for this train of thought).
I don't think this is anything new, nor LLMs are to blame here. Although - LLMs want to make you happy, or maybe they don't think about what user actually needs, just how to accomplish the goal that was stated; they do stuff without asking questions (unless you constrain them or plan first). I've actively put in a hook for my agent to not make decisions on their own and ask me when it detects it's about to make a decision.
Agreed, it is not at all a new problem. The enterprisey codebases I’ve encountered are ones that have chronically had no clear owner, or constant ownership churn. I have been in that position before, and I also decided to make the code even more bloated for the same reason: I did not and was not going to have the time to learn the system well enough to safely do a better job.
I think where a lot of people run into problems with the KISS principle is they conflate simple and easy. More often than not, simple is hard. Which is maybe a soft reason why agentic coding, which is all about trying to make every task easy, leads so consistently to complexity and bloat.
Nobody else is likely to see this comment but I want to make it anyway. Yes, simple is hard. Thank you for articulating it so well.
And yes, that's also why LLM code is usually (unless driven by someone who really knows what he's doing) full of unnecessary complexity. Because although LLMs can get a much broader "understanding" of a code base than I would have given them credit for a couple years ago, their "understanding" is still shallow. And what you need to truly be able to achieve that hard simplicity (I heard someone refer to it once as "the simplicity on the other side of complexity", e.g. when Kepler figured out that orbits were ellipses, not circles, and that allowed getting rid of epicycles) is deep understanding. Which LLMs are not capable of, hence why their code is full of the kind of needless complexity that one produces when one has only a shallow understanding of the code. (E.g., you in that enterprisey codebase when you weren't going to be given time to reach deep understanding).
So true! And it goes hand-in-hand with a different problem: You being able to try and brute-force solutions.
If you write your prompt as a request, and not carefully as an idea or suggestion, the bot can blindly agree to 'help'. And if you are stubborn about it, you can lose hours on something that cannot work, or make the code infinitely worse.
However, it's also the path of getting better at programming. To learn to take a step back, to ask yourself if it's really sensible. Just that now it also involves questioning the bot's help, as well as writing your prompts to prevent it.
Very well stated
> coding for situations that either do not happen or are unlikely to happen.
Not coding for situations that “do not happen” is exactly what creates vulnerabilities. But I also don’t think that such code is the main source of complexity in LLM-generated code.
An example to what I'm talking about: I have application that takes two inputs from request. I've put in validation on request values to deny values that are greater than 100. In my code I'm adding these values. LLM can say "cater for addition of these two numbers, because they might go over MAX_INT and result in overflow". This is a situation that won't happen. LLM can recommend - add assertions. That's unnecessary.
And the day you add a way to batch import request through another code path, you may forget the validation.
Having it in the lower layer is correct, a proper optimizing compiler should be able to detect there's a single code path to the function and that the checks have already been done, skipping the second check.
Alternatively, the code could be written in the style of parse, don't validate[1]. However I've never had a coding LLM preemptively suggest that.
[1]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Well - this would be an example of defensive programming and by that logic catering for this "what if" is the way to go. LLMs were correct all along!
Arguably it’s only unnecessary when the value range is enforced by the programming language (types). The structure of who calls what in the code can change, and suddenly larger values can appear. You don’t want to have to perform whole-program analysis on every change to check whether all assumptions made in the past still hold. That’s also a source of vulnerabilities: assumptions that held when the code was written, but stopped holding sometime later.
That’s why I think code needs to document all its assumptions, and in a way that is checked by the compiler to the extent possible. If you document that the values have restricted range, then the AI should be taking it into account.
Types is an option. Another option would be tests (and in this case mutation testing).
My main point still stands = LLMs code defensively catering for unknowns that are not loaded into context.
Idk I routinely see the LLMs repeat validations that already happen in another layer or it imagines things that don't exist
I vibe-slopped a small and local forms application for my family. I explicitly mentioned that fact to the LLM.
Yet, I removed 2/3s of the code, because it triple-checked that every file really existed and was valid, that the input form was less than a million bytes in size, that there were propper HTTP status codes for everything, that every possible error from reading data was eagerly checked and caught, and so on.
Like come on, three people will ever look at it. So keep it small and tidy so I can understand it better!
> ... More features and more code as fast as machinelly possible.
i am going to quote that a lot...
I think 'clankerly' has a better ring to it.
Depends on your incentives, most people and companies are measuring Lines of codes and features as the metric so ofc it will increase it, but AI can create small KISS applications. It might have a little difficulties in doing so sometimes because it sometimes likes to overengineer things but I have to wonder how much of it is because it is RLHF'd to solve questions at any costs in terms of lines of code rather than training it in solving it in KISS principles. Also I wonder how AI will perform if we explicitly treat KISS as the only principle and have checks running on it and have it discard all the code which wouldn't follow KISS principle if it doesn't follow the principle.
Dunno about your company, mine measures in lines of code removed.
> have checks running on it
We don’t have effective objective measures of what would constitute KISS.
Yeah, so far coding agents haven't been good at reducing entropy at a large scale. That's the area where we need to push hardest in my opinion. Writing code is cheap now, but that makes it easier than ever to inflate codebases to millions of lines of unnecessary complexity that are impossible to work with and maintain. I want to see an LLM reduce a complex multi-million line codebase to 1/10th of its size or less without breaking functionality. That would be impressive!
> but that makes it easier than ever to inflate codebases to millions of lines of unnecessary complexity that are impossible to work with and maintain.
Impossible for you, me, and other humans maybe. But not hard to understand for LLMs
> I want to see an LLM reduce a complex multi-million line codebase to 1/10th of its size or less without breaking functionality. That would be impressive!
They can and do, if you ask them to.
If you have tests to validate functionality, it can easily reduce and refactory.
But, why are we caring about LOC again?
Well, with fewer architecture astronauts overdoing things, all those extra abstractions and dimensions of extensibility that never get used never get written, so one might hope the code is simpler in the long run. But right now coding agents just love writing code, and they don't have a lot of taste for boundaries and architecture, so we have the loop-unrolled, big-pile-of-ifs kind of logic that isn't good.
I may be ignorant, but what do you mean with this and why is it upvoted so much?
To me KISS is basically about how you’d write the code, the architecture, which is something that - at least currently - humans need to oversee when writing new code with LLMs.
But what does it have to do with AI discovering a ton of bugs in a lot of (open-source) software?
Software that does less is easier to understand and reason about, and typically requires less code. Less opportunity for bugs to appear.
Maybe, when they build a pomodoro timer, people will consider the possibility that the entirety of a browser engine as well as 30 000 javascript dependencies from random unvetted sources introduces unnecessary complexity and a practically infinitely fractal attack surface.
that people will finally start solving issues by simplifying the software rather than generating even more edge cases.
A lot of these bugs are in rarely exercised code paths that probably shouldn't have been written into the software in the first place.
KISS usually leads to less surface area.
Someone not following KISS, might install Windows Server + tons of bloated applications, in order to serve a .asp server, which serves JSON that never changes, or something similarly stupid.
Meanwhile, the KISS developer would put static .json files on a CDN or self-hosted Varnish or whatever, and call it a day.
The first opened up a whole can of potential venues for exploitation, while the second might only have opened up one potential venue for exploitation.
Plain http 1.0 is KISS. Does not really work that well.
Systems should be made as simple as possible, and no simpler.
That doesn't mean every simple system solves the problems we intend for it to solve. It means that all else being equal, we should prefer parsimony.
Could the global economy survive what that would do to the B2B SaaS industry?
As a testing tool, yes, post AI software is going to be more robust in the face of attack. We saw this when Metasploit became a thing, it provided an easy way for web site owners to test their stack against 'known problems.' I think that as a rule, we won't get a lot of action on this until we change the laws around incidental damages liability with regards to software.
It is also unfortunate than in more than half the cases where AI provides a 'fix' that fix breaks something else, so my guess is this is going to be 90% human labor to correct, at least initially.
It's interesting that no-one talks about writing new systems and base languages that don't inherit anything from the current toolchain. That's the first step, then new architectures / fully open auditable hardware basis. With html you don't need any of this dependency chain. As long as you can write a browser you can be running on anything underneath.
While it's hard to point to a fully top bottom initiative to create new platforms from the ground up, the Chinese appeared to be making an effort to reduce their non-native surfaces with things like Harmony OS.
A complete plan to reduce vulnerability from untoward influences is more feasible now with agent assisted engineering. You have to be carefully selective about what matters and what doesn't, or the cost and time balloon out of control.
That's also weird, in this reality, isn't it? You've got russians, chinese, etc, supposedly antagonistic to the western cultural hegemony, but then they just rely on western technology tool-chains. If I was guiding any of these countries a close to number 1 priority, technologically speaking, would be to create a completely independent software tool-chain. And talk through adaptors.
I think China uses NeoKylin, and Russia Astra Linux, both based on Linux.
I don't see China antagonistic to the west - they want autonomy, and don't share many of the values, but they're open to a wealthy West spending lots of money in Chinese goods.
Russia, at least its government, is a bit more, especially recently. But anyway, why reinvent the wheel when a battle tested FOSS is there for the taking?
At this point, a browser is a significant part of the way to being an OS virtualised inside the OS it's really running on. Complete with occasional leaks through the virtualisation to the real host OS/machine.
Yes, chrome for instance is more lines of code than the entirety of Linux, I think this just makes the case stronger for what I said. Although I understand why it might be so.
> As long as you can write a browser
One does not simply "write a browser"...
What do you mean with "don't inherit anything"? Using the existing binary ABI is mandatory for interoperability so yes, in that sense every new programming language inherits something. Other than that, there's plenty of languages that have fully self-contained toolchains and runtimes, e.g. Erlang and Rust come to mind. Guix bootstraps its entire environment from a minimal Lisp implementation. There's also Microsoft's CLR and its entire ecosystem of programming languages, but I don't know if the runtime exists next to the Win64 C/C++ base or on top of it.
HTML is entirely the wrong comparison as it's a document format and not a programming language, and "as long as you can write a browser" is not a simple condition. Do we have any browser (even in development) that isn't written with current toolchains? Or a headless javascript runtime perhaps?
HTML as the "transport"/"dialect" to keep compatibility with the existing computational world. What I mean is from the ground up, no C, no erlang (which Im a big fan of in terms of application organisation), no Rust, no Javascript. Start from first principles, OS'es closer to uni-kernels, sane sharing/privacy policies, ability for instance to start an "executable" (already an abstraction tied to the current mode of software production, albeit a perhaps useful one) with a narrow set of scoped access. Then it only has to implement a browser/subset of it to parse HTML and it can "access" most of the relevant parts of the existing software world (internet). Ditch anything complex, if necessary make a browser that just uses flexbox, no other things, no backwards, compatibility, if you need compatibility buy a normal laptop with a normal OS, that comes with all the cruft, but design this new one from the ground up.
But I also don't understand why (without compatibility layers) a browser should be as complex, or remotely as complex, as currently, specially with all the knowledge in hindsight.
I'm not saying this is easy, doable, or whatever, but that was what I meant.
We will leave with more robust software if there are people understanding how this software can be build. Don't forget that the industry as whole stopped hiring new people who wants to enter this field, also skill degradation is a real thing.
https://en.wikipedia.org/wiki/Hanlon%27s_razor
It would be the opposite. While old backdoors will be patched (if easier ones are not switched off or upgraded already), new far more sophisticated ones will be added with AI that only few states will have.
Shannon's entropy theory disagrees. No matter how good the best AI is, its ability to hide a backdoor is limited by the information density within the programming language, and the complexity of possible backdoors will plateau, allowing much lesser AIs to discover them. Consider that binary software is just a more dense form of code, too. A much less dense form, Javascript, makes finding backdoors easy because they all have to use obfuscation via base64 or something to avoid static analysis, which itself immediately draws suspicion.
I was thinking that intelligence agencies and "security" companies like Celebrite must be worried. If eventually all vulnerabilities are patched there will not be any avenue for them to gain access to adversaries' computers.
I predicted long ago that when computers become totally secure intelligence and LEA will lobby for mandatory backdoors, possibly through secret courts.
more likely the bugs will shift complexity. this has happened before, but slower. then that added complexity will make the new backdoors and 0days even more expensive again.
in the beginning, ppl didnt know a lot, and default passwords and stack overflows were 0days.
then awareness came and a lot of that is actually fixed. Writing a modern exploit more often now requires many stages and a shit ton of skills and knowledge.
that will increase.
nothing will be 'fixed' in that utopian sense.
I'm more annoyed by the fact the fixes and exploits themselves are being artificially delayed in misguided attempts to coordinate disclosure, in world where anyone can just point AI at vague direction of the bug and just find it
Right, it entertaining to me to prompt an LLM with a build error or a runtime dependency error and it will literally start reverse engineering things before even attempting to look at docs.
I would be shocked if there isn't a big team of people at the NSA/GCHQ, etc, right now monitoring all the advanced-LLM discovered holes in commonly used software that they might have already been using for 10 or 15 years without anyone knowing about it. And writing daily reports basically saying "cross this one off the list, it's getting patched by debian, RHEL, etc".
This is the real reason for the vulnpocalypse, not "technical debt".
NSA spent 20 years stockpiling vulns and pushing the industry towards half-assed solutions like address sanitization and pointer tagging when they could have put the industry on memory-safe languages instead.
They managed to get the IME/PSP/TrustZone into 99% of the CPUs out there by mandating it for government purchases; they could have done the same thing with memory-safe languages. But instead they chose to stockpile vulns. Hope they burn in hell for this.
Why do you think the NSA could have put the industry on memory-safe languages?
Even if they wanted to, I highly doubt they could push the industry to do that. The industry does what it wants to do, and rewriting tons of software was far from its priorities. There were no LLMs back then to help with such a massive migration.
There's also the fact that rewriting software tends to introduce a lot of new bugs.
The U.S. government could have required all new software for any government-procured system to be written memory-safe languages, thus making it ubiquitous. This could have been phased in slowly with a few years of on-ramp time to allow for industry to acquire the relevant skills.
The DoD tried that with Ada and largely failed. That was with defense contractors whose primary customer mandated it. That was despite Ada being proven to work in its first projects.
The U.S. government had pushed Ada for years and it never worked out. The government was forced to accept C++ because industry was rebelling against ADA, even though ADA was memory safe. Well, Ada did have the ability to be memory unsafe. It was much better by default.
I mean, the government could have just stopped working with those rebellious, incompetent contractors, but I guess the pork barrel was just too enticing.
But even in memory-safe languages, compiler bugs are still an issue. The theory is perfect but the implementation is flawed. In such case once the compiler bugs are found, the software would have to be rewritten to compile. For example an 11 year old memory bug was discovered recently in the rust compiler: https://www.penligent.ai/hackinglabs/rust-borrow-checker-bug....
Memory safe languages are not a silver bullet either.
Definitely not a silver bullet (consider also that memory management isn'the only source for vulns), but still much better than C/C++.
I think we'll have flying cars before we have to start focusing on compiler bugs. Most software is already written in memory safe languages and their vulnerabilities are unrelated to memory safety, they're just plain old logic bugs.
No, you are wrong. Rust compiler bug uncovered this month was aboıt memory safety: https://www.penligent.ai/hackinglabs/rust-borrow-checker-bug....
Basically, the borrow checker allowed writing memory unsafe programs without using the keyword unsafe.
Compilers for C, C++ etc. are well established but Rust is a relatively new language. There are many bugs to come just like this.
Using a memory safe language is not a silver bullet for writing memory safe code. The implementation of the memory safe language introduces bugs as well.
You misunderstood, I'm not saying that compiler bugs don't exist or that they're unrelated to memory safety.
I'm saying that these compiler bugs are extremely low on our list of priorities. If we want to eliminate all vulnerabilities in all of software we have about a century worth of logic bugs that are likely more critical and easily exploitable than compiler bugs.
The DoD have even created their own language: ADA. Massive contracts power, but different markets to incentivize.
The distance between the usual consumer/b2b tech startup and the kind of company that sells software to the air force is even bigger than the distance between Google and the kind of company who hires Accenture.
Why do you think the NSA could have put the industry on memory-safe languages?
Did you even read my comment? I very explicitly answered this.
Government purchasing requirements have an immense effect on industry. IME/PSP/TrustZone have 99% CPU coverage because NSA put "owner-inaccessible oversight processor with disjoint physical address space" into federal sourcing requirements.
They could easily have done the same with "memory-safe language". Note this is not the same as "must use Ada" which is obviously dumb. The IME/PSP/TrustZone req worked so well because they specified the feature not the implementation (and indeed it has been implemented three different ways).
But instead, NSA actively pushed in the opposite direction and funded all sorts of kludges to try to keep memory-unsafe languages kicking as long as possible.
They have actively sabotaged the national security of their own country.
>IME/PSP/TrustZone into 99% of the CPUs
Yeah, about that. Its the biggest vulnerability in the industry. Nobody wants to confront this fact, though.
Too much profit to be made in subversion and human rights abuses.
Sometime the profit made by the companies for inserting backdoors can be quantified:
" In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program. In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm. "
https://en.wikipedia.org/wiki/Dual_EC_DRBG
Yeah.
People seem to be fine with it as long as their own team seems to be profiting from it - but for those of us who are not subject citizens of the NSA's government, it is a truly heinous state of affairs.
Aside: I think I need some help here.[0]
I remember reading Godel Escher Bach back in the day, and there is the parable of the record player between the tortoise and the rabbit. And the tortoise keeps building more and more secure record players that the rabbit keeps finding ways to break.
GEB then goes on to teach you that, no, in fact, you cannot have a perfectly secure system. Not just practically or economically, but even in theory, all systems are fundamentally breakable. GEB, after a lot of chapters (what a doorstop!) ties that parable into Godel's Incompleteness Theorem, and essentially proves that no, you can't make unbreakable things, as a fundamental point of logic.
So, when I look at all this, I see that yes, there is an economics point of view here, that fixing code is just expensive, like making a less and less breakable record player. And that AIs push that breaking and economics point much further along than what we have had.
But then I also see a lot of comments here that seem (to me) to be arguing that there is an unbreakable code out there.
Am I reading this right? Is there such a thing as 'perfect' code? Or is my outdated reading of GEB still valid or not?
[0]Note, I'm not a CS person, more a biophysics person.
The record player thing is a clever analogy for Godel’s theorem, but the “strange loop” is not especially relevant to the security scenario.
Godel’s theorem says that unprovable true statements exist. Fortunately there is a vast set of provable true statements that are quite useful in real life.
Similarly, the halting problem is that you can’t write a program that always determines whether absolutely any program you give it will halt. But in real life compilers can still detect infinite loops in your code unless you try really hard to fool them.
In practical terms a software system can never be “perfect”, because first you have to define “perfect” (i.e., specify correct behavior in every possible state), which is practically impossible, and even if you manage that, the hardware has to implement the software abstraction perfectly, and that never happens. (See prefetch attacks, cache timing attacks, supply glitch attacks, rowhammer, etc.)
The security issues come about when someone finds where you failed to specify desired behavior, or (at any level) your system failed to implement it in some circumstance. No strange loop required.
>But in real life compilers can still detect infinite loops in your code unless you try really hard to fool them.
Having never written compiled code, this intriques me. I often write one offs that I actually want to loop infinitely until I tell them to stop.
How does the compiler know whether it's just really long or infinite? Like, if I write a progressive approximation of pi or prime search algorithm, both are never going to halt because we're certain there are infinite digits of pi and prime numbers. The program could technically halt, but not as a function of the program but rather the hardware.
Or, being silly, if I write a "flip bits in target directory until all bits are flipped" and target /dev/null as a user of the software, it wouldn't halt, so the compiler would detect that?
Is there some --don't-mind-the-recursion flag for developing a program like ycruncher? I get the feeling that there's a list of "this typically causes infinities" that it checks against and if your use isn't on there well then... So it's just the mouse/mouse trap thing but in a compiler?
Or is there some unique CS going on that the compiler employs to determine certain classes of loops?
I think it's worth pointing out the compiler usually won't do much (if any) of this kind of check unless you tell it to.
When you tell it to, you usually have good control around what kind of thing you want it to consider a problem, how much effort you want it to spend trying to prove that, and what should happen with code it can't prove that property for. Most commonly, people just use the "tell me if I've made an obviously dumb infinite loop which does nothing useful while it runs".
E.g. y-cruncher does something other than infinitely loop for no reason so it wouldn't trigger the loop detection logic on most anyone's compilation settings.
On the other hand, a loop which does nothing but run until the last digit of pi would either trigger the compiler to say this is a useless infinite loop or to say it isn't able to prove this loop stops (almost certainly the latter, as such a loop is a great example of going out of your way to fool the compiler).
A loop which sometimes terminates and sometimes doesn't depending on runtime input would depend on your compiler settings, but almost always nobody sets it in a way to say that's a problem (and when they do almost always it's not possible for the compiler to prove one way or the other) if their compiler even supports that kind of analysis.
Interestingly, in C++, a trivial infinite loop is undefined behavior. So the compiler not only doesn’t have to detect it, it is allowed to assume you didn’t do it. [0] This is inconvenient when you actually want a trivial infinite loop. (C++26 was going to fix this, but it seems we may not ever get a C++26…)
[0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28...
to my knowledge, they detect some common intentional and unintentional infinite loop patterns, but not much more:
in C infinite loops with no side effects are UB, so detecting them is useful for diagnostics.guaranteed termination also is needed for some optimizations. but since side-effect-less infinite loops are UB in C, a compiler doesn't have to prove that such a loop terminates, it can just assume it does. other languages may differ, but I don't think any of them prove convergence of algorithms.
a don't-mind-the-recursion flag can be `-fno-finite-loops` on clang, or a read or write to a `volatile` variable in standard C.
How does the compiler know whether it's just really long or infinite?
One straightforward approach is to use Hoare logic [1], specifically the method of loop invariants and loop conditions. If you have a loop where the conditions are expressed only in terms of invariants then the conditions will never change truth values during iteration of the loop, thus you have an infinite loop.
Now, some loops are written deliberately like this, i.e. "while (true)", and so there you need to look at whether the body of the loop contains any side effects (reading input, printing, etc). Then you have what is called a "productive infinite loop", such as an event loop or a REPL. Of course you can't prove this sort of loop will ever halt, since the user may never elect to issue the quit command, but these sorts of loops often tend to spend most of their time with the process sleeping until the operating system wakes them up to handle an event.
[1] https://en.wikipedia.org/wiki/Hoare_logic
That’s the point of the halting problem You can’t know if it will halt absolutely
A specific system could be proven to be secure. There is no general mechanism to prove all software secure however.
Perfect security is actually pretty easy to achieve, for example, if you turn off your computer, it's impossible to hack over the internet. But it's also useless - you want some people to access the machine some of the time.
Another way you have very good (and fake) security, is by reducing the scope of the problem - if you check every request against a very strong crypto signature, it's also practically unbreakable.
But then you have issues like who signs these tokens, who decides which user gets what permissions etc. etc. which mean you have to weaken practical security to make it useful.
Another example is the L4 microkernel, which 'proven' to be bug-free and secure. But it also doesn't do like 99% of the stuff a regular kernel like Linux does, and sort of pushes the issue to the user.
So even defining 'perfect' security in a way that the system remains practically usable is very difficult and potentially impossible.
We come down to to the permissions problem - each person should have as much permissions to do their work as necessary and nothing more - which is essentially a reformulation of Gödel's incompleteness theorem.
This is a misconception of what is being said in GEB.
Gödel's Incompleteness, very roughly, says that not every true statement (in a formal system) can be proven. In particular, it says that for a logic equipped with arithmetic the statement holds; how you get to security I do not follow.
Again, not a CS person.
The idea is that since you can make every security program turing complete, I thiiiiink?, then you can have it be a formal system. So, you can then get the code, in very tortured ways, to execute a paradox, thereby breaking it. Likely in enough ways to let you gain access, though not always.
Godel's Incompleteness Theorem basically says "any system complicated enough to give you basic math is either 'incomplete' or broken."
Clearly our math system gives basic math, so we should conclude that it is either 'incomplete' or broken. Before the incompleteness theorem, it was exciting to imagine that it might be complete, but we had no idea. Now it seems likely to be incomplete. The odds of it being broken haven't really changed.
If it is broken, 2+2 still equals 4 (we didn't really learn that fact from abstract math), but we'll need to fix up set theory. In a world where math isn't formally verified (and even lean itself isn't formally verified), the Incompleteness Theorem is permission to be awed by how huge the space of all logical deduction is, not an argument that logic is a fiction.
To come at it another way, do you believe that there is an 64-bit integer which, any time it is inserted into register 8 on any computer, will immediate convert the raw mass of the earth into a black hole? No, because even if you suspect there is a hole in the foundation of math, you still believe in brute-force case-analysis, and you know that every 64-bit integer has been inserted into register 8 on a computer before.
The important distinction in the book that was made is that it was for a sufficiently advanced reproducer of the original sound, a thing that would make the perfect sound based in the record would cause its own destruction. Something lossy or without that property is actually less susceptible to damage.
Thank you for reminding me of this. What. Wonderful book. I wish my memory were better at recalling it as yours was.
That’s pretty interesting about the parable you mentioned. Maybe I’ll give GEB a try.
It is a literal brick, FYI.
But yes, a hard recommendation. Absolutely worth the time. It's also pretty easy to read.
It's Goedel, not Godel. The umlaut is shorthand for "e".
The article takes PHP2Shell as the worst offender of the present wave of vulnerabilities but HTTP2Shell/Brotli2Shell was arguably worse. The consequence over at Brotli may very well be the same, but the timeline shows, if anything, that at least part of reality is actually still very much "humans just sitting on vulnerabilities for months or even years". From the timeline: 8 years in the code, 8 months unreleased (but fix in Git) and at least 4 independent researchers finding the problem and pointing it out.
[0] https://www.bugsink.com/blog/http2shell-timeline/
Google also authored libwebp which contained the high severity buffer-overflow vulnerability used for the zero-click hack that made the Pegasus weaponized spyware famous worldwide for targeting journalists, human rights activists, etc.
The article is full of non sense, starting at the description of the vulnerability
I'm always amused when people have a distillation of all human knowledge at their fingertips and all they can do is complain.
Yes, we're going to see the bugs exposed by AI and it's going to suck a bit for a few months.
But when this is all over, software will be more secure than it has ever been before.
That'd be true if companies were approaching AI responsibly, and not attempting to YOLO vibecode entire platforms. But as core utilities go, I do see the value in hardening against vulnerabilities by using AI. And when sanity returns and companies start approaching its use rationally when it comes to development...develop best practices around how to build with AI, and ensure code remains reviewable and understandable by humans, limit scope creep and sprawl, and slow down a bit to think through these issues - yes, it could yield some very positive outcomes in the long run.
The problem is there is no way that you won't have someone, somewhere videcoding platforms, accumulating technical debt and benefiting short-term thereby. And once such approaches work and get semi-reliable, they'll spill over onto other areas, gradually becoming universal.
I mean, LLMs themselves come from exactly this phenomena. They are a product of finding a technology that scales and going with that no matter what. And parts of this will hit a wall and have to retrench, current players may implode but the genie isn't going back into its bottle so disruption within disruption will continue.
I also feel like this is true. We are going to see a massive explosion of CVE's being found and patched, then it will gradually slow down. But there is also the possibility, the code being written now is written so fast, and by people that might not even understand it in the first place, that the pace of adding new vulnerabilities might explode at the same time. I'm not sure which is faster.
Well it's more like generated not written.
I feel that while it's plausible that AI progress in making existing software less shitty will outweigh the increasing capabilities to exploit software and so make the existing software more secure; however, I feel that the trend is that the rate of making existing software less shitty is far, far outpaced by people releasing vast quantities of new shitty software.
> But when this is all over, software will be more secure than it has ever been before.
Maybe? I’m not 100% on this one.
Not trying to be a downer, but it could become a mixed bag is all I’m saying.
Ai only reliably returns whats in the training set with sufficient power. As you can imagine, this is a supremely limited scope of all of human knowledge and depends on data that were both recorded and made available for training.
> But when this is all over, software will be more secure than it has ever been before
I don't see sufficient evidence that this is not going to be a perpetual race between people/AIs fixing existing software and more advanced and powerful next generation AIs finding new vulnerabilities and exploits.
sooner or later we'll converge to proof-backed code
It's only a race if the defender can afford the tokens
> all human knowledge
I know how to ride a bike.
Does your chatbot?
While no chatbot can ride a bike currently, that doesn't invalidate OP's point. "Distillation of all human knowledge" here is not a scientific claim, it's a colloquial exaggeration to emphasize its actual capabilities vs the complaint people have against it.
> While no chatbot can ride a bike currently
Let us skip the strawman.
The point is knowledge not ability.
> not a scientific claim
Ain't that the truth.
> it's a colloquial exaggeration
Agreed.
Yes, but it cannot ride one.
Odd. Claude says it does not.
Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work? Collectively, we just won't know for a while.
It totally feels like the former if you watch it find and fix vulnerabilities or other debt-tasks one after another.
But only so many of these "technical debt" issue are little off-by-one errors that get remedied by a surgically narrow patch.
Many enough require some kind of restructuring or redevelopment of their own and it's going to take time to figure out if AI faces the same dilemma as human developers: where each non-trivial change carries the risk of some new issue, ad infinitum.
If that happens to be the case, and AI isn't able to magically produce perfect software in finite time, then what's really happened is that the threat of hostile AI exploiting our technical debt will force us to always be burning and churning code just to remain a moving target.
It's another "we'll see" thing for now, I think.
"Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work? Collectively, we just won't know for a while."
Yes, let's fix the foundation. It will make adding features easier once the debt is paid off. And we will probably learn how to do better in the future. It reminds me of settings compiler warning to be treated as errors. Once you do that, you have a ton of work to do. But if you are smart (not all devs are), you learn why the warnings are there and avoid these problems in the future.
> It will make adding features easier once the debt is paid off.
I'm not so sure: DJB-style secure microkernel/microservice architectures are hard to extend, and I have little hope that today's monolithic code bases are securable without retreating to a small, proven, and well-tested TCB--even by ASI.
The original technical debt, which cannot be paid off, was the decision to use a Von Neumann architectures instead of a Harvard architectures for CPUs.
Explain? (Genuine question because I wanna know)
Basically, have an explicit distinction between data and code at the architectural level, to enforce "Write xor Execute" in hardware. In this way, you would prevent e.g. a buffer overflow letting an attacker injecting shellcode that gets executed later by somehow pointing at it. AFAIK the issue would still remain with some programming languages though.
don't we already have the NX bit?
and it's not sufficient anyways. even with NX you could have the attacker control a function pointer you call. in any sufficiently complex program you'll have enough widgets to build anything you want just out of data.
code and data are the same thing. whatever inputs your system receives is "code" that your application interprets, just like your application is the code that the CPU interprets. turtles all the way down.
In a Harvard architecture, it's not possible to point the CPU at data.
But that's just irrelevant confusion of terms.
There is no fundamental distinction between code and data. This separation does not exist as category in actual reality (and I vividly remember that being one of the bigger points GEB made, early on). They're fundamentally one and the same, and classifying some bits as data and some as code is a point of view that really depends on what you're doing and why.
As for Harvard architecture - every time you branch on your "data", you're effectively executing it, and your "code" can be seen as emulating a system where your "data" is the actual code.
So JIT is not possible on a Harvard architecture?
What about return oriented programming?
But.. alter data that gets executed (interpeter?), I mean, how does this work even in theory? All data is potentially code?
To clarify what intrasight is talking about: A Harvard architecture CPU has two physically separate memory busses for code and data. This makes it possible to build a computer with a program memory that cannot be altered through the data bus. In practice, this isn't normally done -- even on Harvard architecture microcontrollers, the flash and RAM are connected to both busses because memory is expensive. And having inalterable program memory doesn't save you from stack-smashing attacks that alter a return address.
All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.
Code and data being equivalent is a consequence of Turing completeness; you can always write a Python interpreter, point it at "data" and have it execute that via interpretation.
> All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.
Says you. I wrote a program for a Hardvard architecture chip (PIC) that read bytecode from the data memory and executed it. Updates were made by replacing the data block with a new data block.
In practice, there is no way to separate data and instructions. After all, JS downloaded inside a webpage is literally data, and it gets executed.
and we don't believe a sterilized virtual machine creates a similar situation?
any respective machine doesn't require full Turing completeness?
any ad-hoc machine allows for mutations and flexibility, which I'm sure is an added strength.
2nd edit,
Also, didn't we have a weaker model of this with segmented non-flat memory models on i386-
How do you turn text into code in this architecture? Through the kernel?
you don't. I also believe that JITs would be impossible under strict Harvard.
Wait, how do you create programs then? How do you compile?
That doesn't even make sense, to be honest. Interpreted languages like Python aren't running machine code. They are taking data and executing machine code based on the data. Is Python safe?
According to Wikipedia, Modified Harvard Architecture is a common thing and appears to have properties of both Harvard and Von Neumann architectures. It's probably worth discussing a specific device, OS, and programming language rather than having a vague discussion where both parties are constantly describing different goalposts.
It's not that hard to imagine that in a specific embedded device the kernel / compiler have access to write to the instruction memory space while user space programs don't have any API / permissions to do that.
I see. I guess this does solve the issue of a program managing to insert arbitrary machine code on an address and point the CPU at it, or replacing the memory where the machine code already exists. But I think there already exists OS-level protections against writable executable memory?
It also doesn't solve one important attack vector: the existing executable has logic that can be used maliciously (e.g. a function that sends a file to the internet), and this logic is executed based on data on memory. In this case you only need to manipulate the data, without manipulating the "code", in order to exploit it.
I'm not sure I understand why would you need special hardware for that.
I think that the principle of "code is data" is that data influences the algorithms either way, so there is not much of a point in separating the two.
My understanding is that all hard-Harvards are special-purpose ROM-driven systems with static payloads developed on von Neumann computers.
This sort of thing is much more common in microcontrollers, where the code is cross-compiled on another computer and written to flash memory through a debug interface.
In practice, it's usually possible to write to the embedded flash memory via software, but it's much more difficult and disruptive than a simple CPU memory access.
A compiler writes machine code do a file. The OS then loads the code from the file into executable memory before it runs the program. The compiler isn't actually trying to execute the machine code it produces. This is why a JIT wouldn't work - the JIT bypasses the interpreter and produces machine code _that executes directly on the CPU_ inside of the same app.
I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.
Yes, and that's my doubt. Compiling is turning data (text) into code (something executed by the CPU). I thought the point of the hardware is that data can't become code. If data can become code, then data is code, and it doesn't matter if the data is compiled first or interpreted at runtime. There doesn't seem to be a way to prevent "data" from becoming "code".
> why a JIT wouldn't work
Uh? It would work via a file - as AOT.
That won’t help with Lisp programs. ;)
Good point, but not much infrastructure runs on Lisp
This argument is much worse than "we should have made functional programming the standard back in 196X" (which might some merit but overdone imo). The Harvard architecture is just a hardware separation of instructions and data - the argument is virtually an urban legend. Hardwave code/data separations are relatively easy, have existed at time but change nothing since dynamic language just makes its code into data and the self-modification is unhindered.
see: https://www.computer.org/csdl/magazine/an/2022/03/09779481/1...
Separating the call stack (and probably inventing a very specific "the only valid reads/writes in this area are the ones made by the CALL/RET instructions" permission bit for it) from the data stack would make almost all buffer overflows useless for taking over the control flow: the normal STORE instruction simply can't overwrite the return address, period.
Of course, the interpreters would still be vulnerable, but even for them having separate (and distant) stacks make this particular vulnerability much harder to exploit. And again, a generalized technique having different processor instructions for manipulating differently "painted" memory regions would help there too — at least, it would be there so the implementers of the interpreters could reach for it if they decided to.
In the end, of course, nothing can save you from having a program that insists on literally doing eval(fetch(url=input())), or curl "$(read ; printf "%s" "$REPLY")" | "$SHELL", or something else to this effect.
PHP would still be a C interpreter even if you disabled JITs.
Really, we never should have left the Garden of Eden. Things were great there, other than the maternal mortality rate.
Given that there were no mothers in the Garden (other than arguably Adam who gave birth from his rib), the maternal mortality rate was undefined behavior (0/0). Which checks out -- what did they do during all their time in the Garden, anyway? I guess now we know that we cannot know, and that Lilith must have been of the nasal variety.
Modern CPUs already split code and data between two types of L1 caches. So they are technically both "Von Neumann" and "Harvard" simultaneously.
It's also missing the point because modern buffer overflow exploits no longer write code into the stack, they overwrite the return address on the stack and assemble jumps to the end of functions known as "return oriented programming", but the underlying issue still applies to function pointers on the heap.
the equilibrium state would be having found a good pattern for making patterns good. we probably aren't too far from that, so i think your worry may show up in the short term but not the long one
You're thinking of provable code? Or something else?
that would do it too, and i suppose people are working on that. but even without that, there arent infinite low hanging fruit problems to find, and any given code can just sort of be play-doh'd into other code. so the llms will need a few idk years worth of rounds of being trained on the things that pop up that wed never have the time to harden, and things will settle. like, its hard patching stuff up quick right now but we're managing and society hasnt fallen in to chaos.
it appears they are thinking of a universal 'framework' for all things we may consider insecure as of present
> Is it forcing us to "pay off" technical debt or is it starting us on a compulsory endless treadmill of feature-neutral fix-work?
My problem with even talking about this is that there's absolutely no evidence for it. The idea that coming up with a technology to find holes in the hulls of boats starts with a flurry of holes being found and a bunch of patching to be done does not even hint at the theory that there are an infinite number of holes in all boats, and now that we can find them we will have to spend the rest of our lives patching them.
Code was bad, and we knew it was bad. We would have found most of these bugs if instead of coming up with LLMs, a bunch of countries got together and decided that they were going to put $10B into hiring programmers to do nothing but review all the code in the world for bugs. With AI, we managed to do it for only a trillion dollars.
Max AI-glazing perspective in the title, as expected. We need to fix bugs that no mere humans could successfully find and exploit. Thankfully we have AI that can fix those bugs that wouldn’t be a problem without superhuman code agents.
But there are potential upsides like the already mentioned possible nation state exploits (sleeper exploits).
They would absolutely be a problem at some point, the timeline is just uncertain. That means defenders have to fix them all just in case.
While I have mixed feelings about AI's impact on my work, I am happy that I can address 5-7 years of technical debt in code bases as I come across it due to AI lowering the cost. Typically the solution is not too difficult; it just required a lot of time in research and testing which AI streamlined. I am able to verify everything at the end ran through the proper test cases and that the fix is what I expected.
I just can't understand that anyone is seriously thinking that AI is improving the situation when it comes to tech debt instead of making it way worse.
For every bug or security issue it fixes, it creates 10 more.
Sounds like a skill issue
Are we still using "you're not prompting it right" in 2026? Lol.
You're not using LLMs at all or not auditing anything if you don't see them making major mistakes on basic things every day multiple times a day.
if you have problems to "For every bug or security issue it fixes, it creates 10 more." degree then you are using it badly, or on wildly different code from where I tried it
Having worked on both sides of the table, the reality is that it is far too easy to game certs like ISO27001. The risk calculation by companies taking that route is changing right out from under them thanks to Ai tools.
> too easy to game certs like ISO27001
These certs only exist for compliance, not for security. Nobody cares they don't add any extra value, because they allow every business to say "my supplier was ISO certified, so I did my due diligence".
And nobody really ever gets prosecuted for lying during their audit.
It seems like you've never tried to get it. ISO27001 is a security certification. You will not pass the independent audit if you're bad at security. You will not be recertified if you're bad at security. You can say this for other, non-prescriptive certs, but not ISO27001.
https://consilien.com/news/what-is-iso-27001#how-do-you-actu...
> You will not pass the independent audit if you're bad at security.
I wouldn't agree with that. What I would say is that to pass the audit you must appear to be good at security. More to the point, you must appear to be doing many things that most companies don't actually want to do.
I worked at a place which got ISO27001 yet had its proprietary source code available unauthenticated from an old CVS server, including over HTTP. You just needed to connect to the wifi or plug in any Ethernet cable into any device. The company just did the magic “accept the risk” and moved on. Anecdotal but I can’t help but feel it would be common for other orgs which are bad at security getting certified anyway. https://youtube.com/watch?v=9IG3zqvUqJY
> It seems like you've never tried to get it
I have. What I wrote was based on personal experience working for an ISO 27001 certified company and being very involved in the (successful) audit and recertification.
> You will not pass the independent audit if you're bad at security.
Incorrect. You will pass if you have all required processes documented and have documentation that show you follow those processes. Whether you actually do follow the processes is irrelevant, the auditor just needs to think you do.
Also, you can be incredibly bad at security and still be ISO 27001 certified. For example:
Process: Describes that employees use an encrypted password vault for secret management. Keys in the vault are rotated each year and when employees leave.
Reality: Keepass database is sent through email, the password is "CompanyNameVault2023!", which is shared in the same email. Keys are never rotated because it's annoying.
This will 100% get you ISO certified, in my experience at least.
In my experience you are not wrong.
The auditor will require evidence of password rotation and take that evidence into their report. I don't see any way an audit could pass lacking this evidence, on either end here.
You can easily just put some dates in a rotation logbook and call it a day.
lol. lmao, even
I've been referring to this as honing a codebase (like a knife). I've used AI to vibecode sloppy one-off scripts, demos, and proof of concepts. But then I've turned around and used it to hammer in actual projects to a level of quality I just would not have had the time or motivation to achieve previously.
That is a choice I make every day when I get into an argument with Claude about the chosen design and how I find it insufficient. Does it slow me down? Sure, a little. But at least I know the foundation is bedrock instead of sand.
We could rephrase it like this: “AI has removed all the excuses we had not to remove technical debt”
Yes, AI developed code might have vulnerabilities or bugs, but so already has your JSP based web server that has Oracle and God knows what else among dependencies.
I invested in an AI security seed fund started this year exactly because everyone knew that was in the know on the matter all thought we were about to hit a wall of major security problems.
The biggest monetary risk is obviously is the frontier labs, and the variability of seed companies in general, but I really just can't wrap my head around the frontier labs being able to communicate with all the businesses about their individual security needs.
Companies that just do Red Team simulated attacks to find and expose tech debt are going to be critical to literally just communicating these vulnerabilities to management.
I think the real issue we are facing isn't the 40 years of tech debt, that's obviously real, but the real issue is communicating to non-technical management of companies of basically any size that they absolutely need to prioritize this stuff. People don't understand that we're going to live in a world where every single 0-day is going to be figured out in 48 months, and it's going to be easy pickings if you don't take this stuff extremely seriously.
AI winter is coming.
We are in still in the the good ol' days of AI. Like the internet, there was usenet, irc, blogs, slashdot, slackware, archie, gopher, ncsa mosaic. Now we have reddit, discord, facebook, tiktok, chrome. The early adopters build a community, then everybody else shows up and turns it to shit.
It will happen with AI and it won't be pretty. It will stop being useful and start being annoying and turn to outright danger. Fridges spoiling food is only the beginning.
Is it a big deal considering AI is actually helping patch most of them anyways?
One thing that I find confusing is you can always prompt a model to find more bugs, and invariably it seems to always be able to
Where LLMs as a genie are being forced out of the bottle early, the size and scale of it can like only be met by the same tools, better used and equipped and directed by humans vs the LLM iterating until it seems to work.
Centaur vs. Reverse-Centaur
Bostrom touches on this somewhat pessimistically:
> The apparent safety of a tool-AI, meanwhile, may be illusory. In order for tools to be versatile enough to substitute for superintelligent agents, they may need to deploy extremely powerful internal search and planning processes. Agent-like behaviors may arise from such processes as an unplanned consequence.
In my experience it seems like it finds one bug in an area then kind of gives up and goes somewhere else, and I wonder if it has to do with how training works; if they're deliberately setting up single bugs per area, so it acts most "efficiently" when it stops work in that area once it's found "the" bug.
You know you can just ask another unbiased agent to look for more bugs right?
In the context of "after the first pass with an agent, a second pass with the same agent will still find more bugs", how is that relevant?
> Is it a big deal considering AI is actually helping patch most of them anyways?
Double side sword. If you were the creator, the owner of the source tree, easy win. Why not. You know what it will change and the states changed from it.
If you're someone with no understanding to the code has been tasked with "use ai to fix bugs" that is where the trouble starts. When you don't hold the full knowledge of the source tree then you should be shy in using LLM's to fix bugs.
How do you know that bug fix doesn't cause issues further up-stream?
It's also introducing a new kind of technical debt much faster.
I think I doubled the amount of tempermanent fixes I pushed in my whole career just in the past two weeks.
we're seeing easier PR approvals when AI is involved. Since changing the code in the future is a lot easier.
Instead of a highly structured engineering process it's more like a gardening process of figuring out what works, what doesn't, what the Business actually wants vs what their requirements were
So more debt because there's more code but it's easier and simpler to change that debt. And in 3 years the product is EOL so shrugs
Which can also then be fixed faster?
Not necessarily and most likely not. I think a lot of people's definition of "fixed" is "stop hiccuping in the previous way so that my butt is covered" and not "yes, it actually works and was given the proper time and testing to ensure that remains true."
Developers would do well to remove the word fast from their vocabulary. It has done tremendous damage to human systems (and the mental well-being of the people dependent on those systems). The whole reason the "technical debt" exists is because there's an addiction to speed. The sad part is that when you poke at that with most people, they couldn't give you a clear reason as to why they need to move fast; just that they have a sense that it's "how everyone does it."
how's the weather up in that ivory tower of yours?
Sunny but remarkably devoid of tusks.
As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Everybody in the industry knows that we've been building on quicksand. Moore's law meant that we could just sacrifice performance and add a dozen layer on top of technology from the 90s (if not older) and keep the thing chugging along.
Look at the PHP situation:
- HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays and might be better left off to higher layers. But of course, we can't break compat, so everybody still implements all the naughty parts, just in case.
- PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people. Cue the PHP fans telling me that "it's good now". Maybe, I don't really care, the effort that went into making it good should have gone into ditching PHP for a better language 20 years ago. The bandaid mentality is what got us in this situation.
- And of course to add insult to injury, PHP, this security-critical language, is still implemented in garbo C using things like setjmp/longjmp. Just to make sure to absolutely maximize the damage if a vuln is discovered, I suppose. Brilliant.
- Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.
We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.
Of course the reason things are done this way is generally to maintain backward compatibility and make transition easier. At least now that we have LLMs this excuse will hopefully vanish: porting even huge codebases to a new language/framework, something that was a tremendous undertaking mere months ago, is now vastly easier and faster. We can leave the 1990s behind us.
> We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly
I think you have things backwards. Devs aren't clowns who make it this far. But in industries where buggy code doesn't kill people, devs are expected to ship fast and iterate, because they can and more importantly, it serves the business.
Personally, I'm all about good software engineering principles, unfortunately I don't think you can last long in most companies if you're too opinionated about this and can't compromise (and it's getting even worse with AI, reading the code is no longer a requirement, go explain your teammate that there's an abstraction leak in their code...).
Yes... there are statisticians on my team, for example. They're capable, thoughtful individuals however have little exposure to the oblique and (outwardly) contradictory ways in which production software fails.
But explaining that openly, as is your duty, means surfacing something which could be read as 'bad work' by a non-technical manager unable to grasp the complexity. So in low-trust teams it very quickly becomes a game of brinkmanship, or a prisoner's dilemma for technical diligence
I am currently in a stalemate where I have written a proposal that is very technical. The only “business” outcome is that we clean up a massive security mess and rebase on a new consistent architecture.
My manager can’t understand the RFC, and knows that clean up projects aren’t palatable to his senior eng leadership so he keeps asking me to simplify or derive some business justification. I’ve proposed superficial ones like improving security posture etc but he wants a hard number that can be measured (yet another senior leadership mandate).
I’m kind of exasperated and honestly think it’s his job to figure this out.
You've uncovered the kernel of the software industry- if it works well enough, don't touch it. This is why legacy software hangs around for longer than it should.
You can remove the word software from that and apply it to almost anything. The whole earth rests on legacy temp fixes.
Yep. Just like the old saying, "There's nothing more permanent than a temporary solution."
The business value is the savings from the cost of a security issue times its probability
If you can't communicate the value of a proposal then you shouldn't be writing proposals. Find an expert and ask them to do it for you.
You first need to assess the risk of the current setup, and explain that the new setup will reduce the risk (which you may be able to express in monetary terms).
You really think it’s wrong that you need to show how it will save money in the long run? Why do you care if the software is poorly written? Because you don’t like fixing bugs? Why should they care? If you care then you need to give them a reason to care. I am not saying it doesn’t matter, I am saying you can’t just expect them to agree to do it because you don’t like it. And it seems like that is what you are saying. “Because security” is not an answer. Everything can be made more secure. Show them the risk and impact.
It never ceases to amaze me how common this situation is, where a quantifiable compromise is clearly the answer between engineering and leadership, yet none is presented by engineering. No party is ever inherently trustworthy, we all need quantifiable reasons to make decisions. I've never unquestionably trusted leadership, so I've never expected them to trust me.
I've been in plenty of meetings with non-technical folk who basically shut their ears off whenever anyone brings up explanations for things like why security matters.
I now work in a highly regulated field (payments/banking) and it's a bit better, but from prior experience if there's no regulator to beat people with, they will simply not give a shit, the only thing they want is to shove out whatever feature as fast as humanly possible.
As an example GDPR was a godsend because I could finally convince people to get rid of the 11 trillion stupid analytics and tracking bullshit we had "Because GDPR", whereas no number of arguments, no matter how well researched and presented, would ever convince anyone before
My feeling is it needs to be communicated non-technically, execs need to think 'what goes wrong if we dont do this', 'how much does it cost'.
I also think it’s fair to expect that non-technical people learn some technical reasoning. They don’t need to be engineers, but IMO it’s completely ridiculous that we just let anyone who is business-adjacent off the hook for not knowing anything.
Business people should understand, at a high technical level, how their products work and what they’re actually asking to implement.
I’ve worked with many great business analysts and product people and consistently the best ones are the ones with the “engineer brain”. They might not know how to read even a single line of code, but they understand software products from their pieces. Those people consistently propose high-quality and feasible solutions. Other business people do not.
As developers, we are expected to constantly think on our feet and adapt. We learn new products and methods on practically a weekly basis. But for whatever reason, the business folk are not even expected to understand the product they help build. There’s such a large disconnect there between dev and business.
THIS is your answer, leoqa. The business value is the $$ the company can lose if it goes wrong.
If higher-ups have no technical insight, round up and give them two numbers: $$ if a bad thing happens, and $$$$$ if the worst thing happens.
Yep. I recently had to convince management to let us fix a legacy CloudFormation template that was brushing right up against the AWS resource limit for a single stack (which also means it was WAY over the recommended limit for a production stack). It had been causing CFN to occasionally choke on a deployment for over a year, and it was just a matter of time before we either added the resource that pushed us over the hard limit, or CFN choked on a deployment and failed to roll back to the last good state.
The director of my department kept asking, "But do we HAVE to do this now?", so my final answer was this:
"Do we _have_ to? No, but it's like a bridge. Bridges have an expected lifespan when they're built, and they're supposed to be torn down and rebuilt after that. It's not a HARD limit, though. The bridge doesn't immediately collapse the day after its lifespan, but there are fault accumulating. Metal fatigue, erosion of support material, and other things. Commuters can't tell the bridge is past its lifespan, and they'll continue crossing it every day without issue. And then one day the issues will accumulate to the point that the bridge fails and people DIE. That's the situation we're in with this stack. It will continue to function just fine until the day it doesn't, and on that day I won't be able to tell you how quickly we'll be able to recover the application stack, if at all."
That FINALLY got through to him.
> The director of my department kept asking, "But do we HAVE to do this now?",
If someone says that something is a risk and we should address it, I don't expect a director to ask for a specific date the risk to become a disaster. Instead, he should just add it to some todo list and slot some time to analyze it and and budget resources. AKA, doing some "management" work. You shouldn't have to explain his job. You didn't need to learn semiconductors physical properties to know that storage can fail and you need to do backup.
And they’ll ask for the probability of these outcomes to find the expected cost. And you’ll struggle to give one without heavy caveats, and thereby lose perceived credibility.
"It's hard, so do nothing" is your advice.
Honestly, in traditional engineering firms it’s not the job of the mechanical engineer to quantify risks monetarily, and it shouldn’t be in IT either. It’s other people’s job to turn "without urgent repairs, we’ll have to put severe tonnage limits on this bridge or close it altogether or risk collapse" to the cost of inaction in terms of economic loss.
You could make an analogy to getting a flu vaccine. There's a small up-front cost, but you're making a bet that it will prevent or reduce the severity of a larger issue down the road. There's no guarantee that the larger issue would ever occur, but "getting the vaccine" makes it less likely to occur, and less costly if it does occur. Skipping the "vaccine" is a reasonable choice if the business is willing to incur substantial damages in the case of a large event in the future. To put hard numbers to it, you could always show numbers like "X% of our customers are likely to leave if we leak all their data to hackers", and base it on documented examples from recent history.
Hire a hacker to exploit the security mess.
Write them if they do not mandate basic security right their brandy or vodkas or whatever will be served with opposite temperature they expect...
The problem is the "interface" of software engineering being oblique to outsiders. It's alchemy in essence.
The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the current mere pretense of software engineering into reality, making the engineering part explicit.
That in turn only works when humans actually understand what they're doing and can communicate it to outsiders.
It seems straightforward to present the tradeoff in a formulation that statisticians can understand, eg. the expected value of an 80% correct solution that ships now is higher than a 100% correct solution that will take 3 months. The opportunity cost of the extra care often only really pays off for security-sensitive code, like crypto, where the cost of failure is potentially catastrophic.
This is why open source eventually wins out, it doenst have this pressure.
Thank you! I entered the industry a lot more meticulous, test driven development, integration tests, end-to-end.
But shipping faster was pushed at almost every company until, if it's not revenue generating, stop putting resources into it. Not all are like this but it's not all or nothing, it's always a sliding scale how much you can put into making the software correct.
I'm a software artisan deep down but I could never justify putting too much time into making the stuff I used to build "clean and fully maintainable". I tried, but eventually I realized that if I didn't get things out of the door, my company would start losing money and I'd lose my job. Who cares about perfect software in a bankruptcy auction?
There are things you buy out there that don't need Swiss quality because most people will simply not need the quality or won't have the money to pay for it.
I think the biggest problem isn't that a random webpage is sloppy, but when a critical system that could kill people is built the same way as the random webpage.
I hear you, but humans are incredibly bad at context switching like that.
Near the point where things become minorly safety critical, people will blur the line. The point where safety kicks in moves a little further out, and we start blurring the lines again.
There’s a reason the FAA is anal-retentive about things with only very minor safety implications, like the in-flight entertainment system or turning on airplane mode. It helps prevent complacency where it actually really does matter.
You either do it the right way 100% of the time, or I’m not taking bets that you’ll do it right on a particular occasion.
> eventually I realized that if I didn't get things out of the door, my company would start losing money and I'd lose my job.
This is like 90% because most tech is different enough that civil torts don’t exist for them yet, so they don’t have to care.
Eg if Google deletes all your photos they kind of just shrug and you’re out of luck. If I deposited photos at a bank who burned them without notice or approval, they’re on the hook for that.
The law will eventually catch up and acknowledge that bits can have value. Then everyone will have to care again.
You are describing my field - Systems Engineering.
We track EVERY requirement to ensure it is met. Maybe it's a safety issue; maybe it's landscaping approvals (I work in Rail). Regardless, it's bigger $ if not caught up front, and if you start grading requirements on perceived risk, you start the slippery slope to not caring. Example: mark all landscaping requirements as "Not Critical". Then scheduled clearing of the right-of-way is missed. Then pedestrians are at risk with blocked line-of-sight, and trees might drop across the rail.
So what I'm hearing is that software quality will not improve without government regulation.
I can't say I disagree. How it is with engineers they get certified as PEs due to the responsibility they have. In my mind it be similar, you don't need everyone engineer certified, but if you over X revenue or employees side it should apply, and be required to have Y numbers of certified based on company size. Then the companies like with their lawyers, will have to figure out how to follow the regulations and push forward.
I think this is good thinking. I work for a state agency that deals with construction codes and licensing of building contractors, electricians, etc. If the safety of the web is in such a critical state of vulnerability as to potentially impact what the article author terms "normal" non-tech people, maybe there should be some certification that is government-regulated like you suggest. Or maybe that'll happen after real (not potential) devastation occurs - that's how building codes came around.
I don't understand. Do you people just figured out how to write good software? Not long ago, 70% of projects just failed. Not were written badly, but just weren't completed at all. I don't know current number. But looking around me, it's so obvious that we don't know how to write good software. For a reasonable price anyway.
What that PE certification will check? That guy knows how to write unit tests? Well, that's not much. Who will write certification? Where's that genius, why he's hiding from the rest of us?
Maybe building is figured out. I don't know. I still see bridges failing and buildings crushed, so apparently it's not perfect. But I do know that programming is not figured out. Absolutely not. We can apply tremendous effort, pay billions and produce some simple firmware which can be uploaded to a martian rover. But that doesn't scale to the rest of industry.
No, it puts the company at liability, and the PE.
Then when company forces a product to skip safety checks, test units. And the PE proves the did their but the company pushed forward, the company gets wide open to fines and lawsuits.
Make a company responsible and hit their bottom line, other will think twice before they say "just ship it, or I'll hire someone cheaper to do it". And no they don't say that, that's how it's done.
When your paycheck or livelihood is on the line, you tend to slowly sacrifice the principles.
I think your being short sighted here. And a aggressive for no reason.
This must be handled at the government level.
The cost of "losing customer data" is too abstract for a company trying to survive financially. Corners will inevitably be cut.
Unless the costs to be suffered by the company for exposing private or sensitive information are made very clear through legislation.
"Forgive yourself for not knowing earlier what only Time could teach" This quote holds for both individuals and groups alike.
Shipping bad software does not serve the business indefinitely. Application/product security was expensive relative to its perceived value, so it was underfunded nearly everywhere.
2026 is saying "here is the consequence."
Completely agree, but the problem is that the execs don’t understand that. People at the leadership level don’t truly understand or prioritize technical debt. Paying down the debt can be really hard to sell to leadership.
Not sure they don't understand. They're operating in a system where they'd be replaced if they decided to repay all the technical debt.
Don't use the term "technical debt".
Explain those super human hacking AIs like the ones that broke containment and hacked outside sites are coming for your infrastructure too.
All the business people have heard about the Huggingface incident by now (or are living under a rock).
If only it were that simple!
Look at the solo projects from professional devs with nobody overseeing them. Look at what so many of your colleagues submit despite the frustration of your thoughtful team lead and manager. Look at what your so many of your team leads asks for even when they've been granted full discretion. Some select few are great, but most are disturbing if you have any sense of quality or preparedness yourself.
Even for decades before AI, there was lazy naive misguided slop everywhere. During the social coding era of the last 15 years this even amplified itself, streamers and influencers and conference presenters -- professional developers themselves -- would share horrid practices to wide applause. Moving fast and breaking things was what developers were excited about. Rigor was dead. Correctness was a problem for later. Code was presumed best written by a rando on github who'd accumulated a lot of stars rather than by a known responsible hand. Security was a copy and paste job from Stack Overflow, not something to be comprehended and considered.
If only it were a top down problem from outsiders!
But the truth is that the call has been coming from inside the house all along, and the outsiders giving direction have had no problem finding celebrated industry "experts" and "thought leaders" affirming and encouraging all the clowning they could imagine.
Developers could always move fast and do things right but most just didn't have any interest in learning how, and many of those who might have just gave up on bothering.
Thanks for the counterpoint. It's true that being sloppy and taking shortcuts isn't always a calculated business decision and it can be a lack of skills.
Businesses would definitely love great code if they could have it fast and easy. The problem is that they can’t. Developers tend to believe that they could generate perfect code if just they were given enough time. Well I have given my team infinite time. I tried it, do you think they delivered perfect code? Of course not. First of all if you don’t stay really close to everything they do, they will spend all their time on useless stuff like setting up their editor instead of using a readytogo IDE that actually speeds their work up, or testing things that will probably be thrown away a few weeks later when we decide that the strategy we were trying to use didn’t really work, but still require lots of time to “refactor” into the completely different thing we now need. Even when they do build the right thing and focus, more time simply does not equal more quality, it can even get worse at some point as you again get lost and start veering off on a tangent and forget what the business is actually about.
In fact, I have myself spent years on solo projects with the goal of making perfect software. You know, nothing like getting a few users to quickly destroy that idea from your naïve brain. You can’t write perfect code because that is nearly impossible for most of us, no matter how hard and how long you try. Think of it like this: can you beat the greats in your favorite sport or hobby? Probably not, you may be good at a small team level, but at a large city level you are almost certainly mediocre. This goes for your coding skills too. How many great developers out there creating great software we all know and use and love? I know a couple of names, that’s it. Most of us are writing shit enterprise applications everyone who is forced to use hates and that has more bugs than PHP in the early days. And when we try our own thing it’s even more horrible. Show me your repos and let me se if you’re the genius you think you are. Oh of course, you don’t have time to spend on hobby projects since you have a life… great, enjoy that, but don’t pretend you’re able to paint the Mona Lisa just because you spend all day with a brush in your hand striking on a canvas that no one can really see and if they did, it would most likely be a repulsive, incomplete, bug hidden piece of shit.
They will hate you for you tell them truth.
This - 100%.
Just take a look at some of the opensource academic, infrastructure or "passion-projects", where there is no management pressures to "move fast & break-things" and ship-ship-ship. They tend to be very stable, very predictable - and very high quality.
Care to name any?
I've seen software that academics write. It's no better than average. It's often cut-and-paste code, or these days AI slop. Software is a means to an end in academia, rarely a product in itself.
Anki
TeX
I don't think we can rationally extrapolate anything from Knuth's career. His entirely CS presence is a pursuit of perfection unlike, well, anyone.
You read my mind...
> They tend to be very stable, very predictable - and very high quality.
Some of them are, most are not.
Actually, most FOSS stuff is anything but stable or predictable. Instead it is constant treadmill, broken compatibility, and recently, thousand of commits from claude et al.
I agree... many people seem very purist. But I think it depends on what you're doing. Some things make sense to do fast and cheap. I work helping fundraising, and it's often better to have 95% solution that is delivered on time than a 100% solution that comes out after the campaign has ended for example. Management should warn us ahead of time and give us the time and the space to do it right, sure, but how often is that reality? As long as it's a conscious trade off I think it's fine.
You are assuming that garbage code makes us more productive.
That might be true on the margin, but highly doubt it was ever true once you escape a very shitty local optimum.
you mean industries where software can kill people like pacemakers?
https://ijcionline.com/paper/13/13224ijci12.pdf
Wow, it’s almost like it’s really hard to get everything perfectly right and this is endemic to software, particularly when the language accepts incorrect code.
The only two things we know mitigate this are proofs (eg rust borrow checker, lean, etc) and DST which is basically the equivalent of accelerated time testing which is done in other industries too. Most people don’t even bother with property testing
> Devs aren't clowns who make it this far.
simias referred to the industry and you took it personally.
Why is it whenever someone mentions the shortcomings of software industry, there is always a comment saying "no no no, developers were just following orders!"
> “always been frustrated by the tendency of software devs, and in particular web devs”
Sounds like they’re talking about devs
Because systemtic problems are often better explained through structural relationships rather than personal failings?
I don't disagree with the point that a lot of software that isn't pressured to be shipped quickly still ends up following bad practices, but I don't think we can ignore that the quality issues in software aren't also found all over in many industries because of profit motives?
Because by that rationale all industries are circuses filled with clowns. It's incentives not ineptitude. It's a clumsy take.
He spoke of a clown industry. That means the industry as a whole. That includes, but by far isn't limited to, the devs. Which of course have to operate in an environment, most of them set by their employers. And of course, responsibility scales with the position in the hierarchy. So yes, to a large part it is the management setting deadlines, budgets, staffing and planning allowing for technical soundness and of course safety and security.
But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
> But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
Yeah, but money.
It's coordination problems and large scale distributed action, not some moral character of how serious the people are. Effort is not fungible. To make php good, you only have to act at one point, in a localized way, at the php foundation. To ditch php, you have to act in a coordinated way across any resource strapped companies and individuals. Just see how hard it was to ditch Python 2 or how ipv4 is still not ditched.
Trying to understand underlying reasons and incentive structures is much more productive and useful than simply venting about the worse moral character and seriousness of people in one industry vs the next. Curiously, the grass seems always greener - when you ask people in other industries, you'll often hear endless complaints about the state of things there too.
It's a market thing too. Company A tries to write perfect code. Company B tries to write something that the users don't hate. Company B wins in the vast majority of cases. Especially when company A these days is stuck with a huge space to investigate.
This isn't unique to coding, but coding has been built on it for decades, with the "safety valve" of "who has the time to check all that?". So defcon speakers and intelligence agencies burn time investigating for weak links that might take months to find, and the rest of the world churns on.
Now you have companies throwing thousands or millions in compute at problems just checking EVERY possible problem and yeeeeup, looks like there's a lot of "good enough, ship it" which is now a major problem for all those companies using that tech.
It's still going to be interesting to see how this develops because, yes, there's a lot of code being written by people who haven't even read it (although the amount of enterprise production level code I've seen that's bad stack overflow copy paste makes me less worried about this), and there's maybe better tools and standards to catch these things (why not spin up a test suite if it's an afternoon of AI poking rather hiring a dev and getting them up to speed?).
There's a PHP implementation written in Rust.
This is incredibly interesting. Thanks for mentioning it. Unfortunately it’s not yet ready:
https://phprust.com/status/
I’ll keep checking
It runs everything that any software I've ever written needs - and I've been doing PHP since dates began with `19`.
But since php isn’t complied, how would I know if something is broken until every code path is exercised? Genuine question
You exercise every code path with a unit or integration test.
I tend to write integration tests for the paths users take through the application (website), and fill in the holes with unit tests. I'll also write unit tests for methods that change often or are critical, such as business logic.
I wonder if PHP compiled with Fil-C would have stopped that bug. My guess is it would have.
My tests show that it would. The post-patch integration tests trap under Fil-C, and the StealMyBitcoin exploit chain traps too.
https://mbrock.github.io/filnix/docs/php.html
It’s also compatible with most PHP native extensions.
Fully agree.
> PHP was a joke language from the start.... Cue the PHP fans telling me that "it's good now".
First, I am not a PHP fan, but I will absolutely stick up for the "its good now".
Yes, absolutely no debate the old PHP 4.x/5.x was shocking. However to give PHP their due, they absolutely did make serious efforts in 7.x/8.x. They deserve due recognition for that.
Unfortunately lots of people – I'm guessing you're one of them – still have battle-scars from 4.x/5.x and they think (incorrectly) that 7.x/8.x is "more of the same".
Second "joke language", well, cast your mind back to what else was available at the time... ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
Sure, to borrow your terminology, the Java fans will be along soon to tell us all how awesome Java is for the web. But many of us still bear battle-scars of the horrors of Java stacktraces, messing around with incomprehensible XML config files, Java's penchant for eating RAM for breakfast, and generally trying to figure out why the hell Tomcat is not working (again !).
> ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
Pffft. VRML is the whole game, baby! Once everyone runs out and gets an SGI oxygen, Nobody is going to use freaking web browsers ever again. I mean, HTML, what a joke.
Also, ASPX (so ASP.Net) was a vastly superior technology to PHP. It was my first love, and I ditched it for Ruby on Rails, but ASP.Net was really good. Especially when you ran it on Linux using Mono.
The previous post probably should have said classic ASP, not ASPX.
Classic ASP was the more direct competitor to PHP, while ASP.net came along later, as part of a next generation of web server languages/frameworks/platforms.
I remember VRML being a possible PhD topic for me in 1997, I think that was about the last I heard of it!
The other option I was actually offered was in machine learning and categorisation, but I avoid it as it was obviously a dead end lol.
> the Java fans will be along soon to tell us all how awesome Java is for the web
well, there's no Java2Shell at least.
> well, there's no Java2Shell at least.
Ahem, cough....
Log4Shell (CVE-2021-44228)
That’s not java2shell that’s “log4j2shell” which you even had to type..
Don't clutch those straws too tightly, you might drop them. ;)
Seriously. You're moving goalposts. I think we both know how popular Log4j is and how many millions of Java deployments that Log4j vulnerability affected.
Wait a second, in very recent years the major Java projects I touched were still messing around with incomprehensible XML config files. Has that actually changed in some part of the industry?
Yes, when I started getting into Spring(Boot?) in 2013-14 I was complaining about the annotation magic that you needed to sprinkle around the code, so that you could have a Java project take a long time to start up and fall over. The response at the time was that it was so much better than the old XML way that you "had" to do. So that kind of XML hasn't been needed for 10+ years.
Unless you count the XML dependency management with Maven, which isn't too bad.
You can use annotations to get rid of a lot of XML in server side Java. See Spring Boot for example.
> Has that actually changed in some part of the industry?
I suspect the only thing that's changed is that Oracle now charge you for the pleasure. ;)
More seriously though, its been a long time since I've touched Java, but I suspect the only thing that's changed is that its all hidden in magical kubernetes containers these days.
Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle. Many things have changed in the Java world. Kubernetes doesn't have any special relation to Java.
> Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle.
Congratulations Java Fan on missing BOTH the smily-face at the end of the first phrase AND the "More seriously though" at the start of the second.
I'm glad someone still loves Java though. ;)
P.S. The kubernetes reference was – since that one appears to have gone over the top of your head too – that in todays world Kubernetes is extraordinarily popular and therefore it is likely most people now hide the complexities of Java deployment into a container that is magically generated and deployed through CI/CD. Hence I was inferring that life is probably "easier" today with Java because you just deploy the magical container.
Congratulations for posting your humorous hot takes on something you haven't touched in 10-15 years.
I remember when that exact line of argument was made about '3/4 was silly, but they're putting a real effort into 5'
Also "3 was silly, they got 4 done right".
Although that was more connected to the performance improvements through Zend Engine than language sanity or robustness, at the time.
> ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
You’re missing the point. Those are all dead. The implication is that PHP should have had the same fate.
PHP had a super power - it was pretty stateless before that was cool. Thus, it is easy to understand and it's easy to scale. And a lot of it is basically transforming SQL columns into JSON or XML text. I used to laugh at it but now I just shrug. There's much worse things in Node-land.
CVE-2026-109618 is evidence that it is absolutely not "good now". To make a pro-PHP argument the week that PHP's shortcomings just cost half the internet millions of dollars of lost time panic-patching an RCE is... an interesting choice.
>CVE-2026-109618 is evidence that it is absolutely not "good now"
That's a C language error, not a PHP language error. I don't see that CVE as particularly different from when they showed python's dictionaries could be attacked using dictionary hash-collision (something that also affected PHP). It's worse in being remotely executable, rather than merely a denial of service, but it's ultimately a facet of the C implementation rather than something wrong with the language itself. CVEs, even remote ones, will happen. Even java had its logging execution attack.
I've made fun of plenty of things in PHP over time, but the language hit the mark it was aiming for initially. It was easy. A 12 year old could sit down and write an ugly little forum and it would work. Because it was easy for amateurs, a lot of amateurs wrote in it, and there's a ton of clumsy code out there. Because it was easy to setup and run with minimal setup, popular packages were very popular. Wordpress vulnerabilities matter because it was very easy for programming chop shops to hack out tons of websites for all the millions of little businesses out there that didn't often follow up on patching etc once that was done. PHP was bad largely for the same reason BASIC was bad. It was easy.
PHP being easy gives it a huge blast radius for anything that goes wrong with its implementation or popular frameworks and libraries.
Perhaps C isn’t the right language with which to implement PHP. C is bristling with foot-guns. That implementation choice is still the responsibility of PHP.
(I say this as someone who enjoys C programming)
No fan of php either but that bug was in C code.
> We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance.
What industry do you think is different?
I've had a decent amount of construction work done on my house, and if I had a pound for every shortcut that the guys doing the work took, it would pay for the work they did. And these are the _good_ ones. The bad ones don't even bother following the legal requirements. Somewhat recently [0] it was found that less than half of healthcare workers followed recommendations on _hand washing_.
[0] https://www.cambridge.org/core/journals/infection-control-an...
Residential construction isn’t much better. But the people who build the really tall stuff, the structures that would kill people if they collapse, that’s real engineering. The odd bridge that collapses is usually a political problem (lack of funds for maintenance).
Go hang out on a subreddit for electricians, or plumbers, and in any thread where they talk about the professional side of it, you'll see a consensus that all the work is awful, done with no regard for professionalism, and that if there was just more support for doing it properly they would. Just like here.
There are plenty of software projects that are managed to an incredibly high standard professionally - OpenBSD, PostgreSQL, Curl all come to my mind pretty much immediately. Linux is probably the closest thing to "skyscraper" development and has been going for 35 years at this point.
Have you heard of 432 Park Avenue?
Doesn't look like it's collapsed and killed people.
I use to joke about PHP in the early 2000s, but now that I see the "better languages", I am starting to like PHP.
If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.
PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.
As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.
Yeah PHP was the first time web applications really "clicked" for me because there were not a hundred layers of abstractions between the html page and the application code. I was new to programming, and I took a look at J2EE and its literal million lines of code pet store that was supposed to be the shining example of how to do J2EE right, and I was like wtf is all of this... PHP though it was so easy to just make a page that gets some stuff from a DB, does some stuff with it, and outputs the result. I didn't need to read a 500 page book to get started with it.
In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
Having lived through that era, J2EE was ultimately a disaster. I remember an "entity bean" (terrible name for a class that manages data persistence) requiring multiple java files and at least a couple XML configuration files. It was complete madness. It was slow to build, slow to deploy, slow to run.
PHP's other advantage is deployment: it's simple. In the 2000's, I used to work at an enterprise Java shop but also did PHP freelance work. The amount of bullshit you had to go through to deploy a Java app on JBoss was insane.
> None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now.
Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.
Verbosity and architectural complexity matter to a coding agent. LLMs have limited context windows, and the less verbose the code, the more you can fit in there.
Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.
I have a soft spot for PHP but these days I would reach for https://pocketbase.io/ by default for a crud app. It’s really great. :)
Yes, I never totally understood why the PHP execution model wasn't copied by frameworks in other dynamic languages like Ruby and Python.
PHP is hard to beat for development velocity. Edit a file, refresh a page in your browser, see the results.
You could always write CGI scripts in Ruby and Python, but other than catering to the PHP-infected, why would you want to?
Ish. I remember when the earliest versions of Rails used a CGI runner. Development didn't carry on long before application startup time became so horrendously slow that it was no longer viable. That is when it started to become popular to add a server in the application.
Now that people are back to writing their applications in languages that aren't as slow as Ruby they've, in many cases, taken the server back out of their application and have returned to the CGI model again; what is often marketed as "serverless".
>We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people
Another industry does even better: the medical/health industry. It's both a clown industry AND kills people AND they have made it way beyond what software can only dream.
Having 25+ years experience straddling both disciplines, i.e. in both CS (Dev) and Medicine (as a licensed provider) -- and who currently works in frontier drug discovery, can wholeheartedly confirm both industries are a joke.
The big fun factor is the place in the Venn diagram where they both intersect. I used to work for a medical device manufacturer who's biggest and most popular product routinely had stack traces at inopportune times.
I have actually gotten a tremendous amount of value from PHP and WordPress: the via negativa! They showed me, in remarkable detail, how things should not be designed.
(I'm not kidding. If you take each element of their designs and invert it, you end up with a very solid design.)
On that note, I misspoke somewhat: I assert that PHP and JavaScript were not "badly designed", because that would imply that someone sat down, carefully considered how the different parts of the system interact, second order consequences etc. — and then somehow came to all the incorrect decisions. Rather, it's quite clear a serious design process has simply not occurred to begin with.
Once I recognized this phenomenon, I began to see it in all areas of life. Things are much worse than they could be, simply because nobody has designed them to be good. They just ended up the way they are now, by accident of history.
--
Polemic aside, I am fond of JS and PHP in many respects. I just think we should clean them up! "This mess has always been here, so it's too late to clean it now" would be laughed at in any other context.
We already broke compat with "use strict". Now we just need a "use sane" :)
> Rather, it's quite clear a serious design process has simply not occurred to begin with.
I don't think it holds with
> If you take each element of their designs and invert it, you end up with a very solid design.
The rule of thumb is "the inverse of stupidity is not intelligence". So, if we have an example where you can get a good design by inverting the bad one, we can't then state that the bad one was a result of a chance. The probability is very low.
I worked at a kitchen job one time. The place was, to use the tired phrase, full of toxic narcissists. People who didn't care about what was true, or good, but cared about shitting all over each other.
For example, in one case, the toilets were flooded, and they spent nearly an hour arguing about whose fault/responsibility it was. I snuck off quietly and solved the problem. (This offended them, presumably because then they couldn't bitch about it anymore!)
Anyway, I started keeping a list of complaints — all the ways that job violated my standards. At first, naively, thinking "surely if I show this to mgmt they will fix things!", and later, "ok, red flags list for next job."
At some point I realized I had actually created a spec for the perfect job, but with each term inverted:
Abusive assholes -> respectful colleagues
Total lack of process and communication -> a place that's actually functional and well thought out
Everyone hates their job -> people actually want to be there and enjoy what they're doing
Mindless drudgery -> creative and technical challenges
And so on. Amusingly, inverting the shitty kitchen job produced an almost exact description of VALVE corporation.
Anyway, I'm sure there's a term for this. Maybe "negative space"?
Oh I assure you, all industries are clown-driven, clown-built, and clown-maintained. Nobody has time to do things according to a retrospective analysis of "best" which will just be re-evaluated next generation. We build with what we have and fix when we must.
Another thing that has bothered me for a long time: we have far too many data isolation mechanisms, each with their own idiosyncrasies and trying to cover up for each other's gaps. Very very roughly, from source code up:
- Variable naming conventions (_field in Python).
- Lexical scopes.
- Visibility annotations (public, private, protected).
- Coroutines, threads.
- Packages/modules.
- Sandboxes.
- Processes.
- OS capabilities (pledge/unveil, SELinux, etc).
- Local user accounts.
- File permissions.
- Containers/chroot.
- User mode vs kernel (Ring 0 vs ring 3).
- Virtual machines.
- Cryptographic measures (secureboot, attestation, memory encryption, etc).
On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.
If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.
You have a point that there are a lot of separation mechanisms and that, if things were designed better, fewer would be needed but by the same argument it also seems unwise to increase the number of mechanisms to share data. Sockets by themselves are quite big enough on their own to quite literally drive the whole internet through.
A socket is just a raw byte stream. It's a solid base layer, but you'll have to implement your own communication protocol on top, and it'll require copying the data from one process to another. A "stream" is the wrong metaphor for local data sharing.
The data is already in memory and the source program knows its "shape"; there should be an easy mechanism to provide access to that by default, like /proc or gdb but for arbitrary data structures and with better UI.
One idea would be that the data structures that a program uses declare if and how they want to be protected/accessed. E.g., access levels could be: only accessible in a local code block, only accessible in one thread, accessible by a limited number of threads, persistent or not between program runs, accessible over the network by certain machines/people, accessible to the whole world. A tree of all data in a program/computer could be exposed subjected to such access control. I would think that this does not even need to cost performance because 'only accessible in one thread' would not have to be implemented in a way that is different from current local/global variables.
Non-technical managers don't want to wait for the 'nerds' to 'do it right' because that takes a long time and the nerds don't agree on how best to solve the problem because most capable nerds (who sort of know what they are doing) are working on lower-level problems and making the big bucks (they are not running WordPress for the local News Paper).
So that leaves non-technical managers telling non-technical nerds to just install WordPress. Then, AI comes along and wipes them out. And everyone is like... how did this happen?
It's pretty obvious.
And, we know how to write code properly if that's what is required. There are methodologies from avionics and other critical code where every line of code has an audit trail back to a requirement. Where malloc is disallowed. If you want to compare it to other engineering, there are skyscrapers and there are doghouses. Most software is doghouses.
> Most software is doghouses.
This is not completely a bad thing. Using skyscraper techniques for dog houses is not sustainable.
The key is to identify when you are working on a skyscraper and when you're working on a dog house and act accordingly. To my mind, the boundary between the two is whether or not you are handling sensitive personally identifiable or financial data.
>Non-technical managers don't want to wait for the 'nerds' to 'do it right' because that takes a long time and the nerds don't agree on how best to solve the problem because most capable nerds (who sort of know what they are doing) are working on lower-level problems and making the big bucks (they are not running WordPress for the local News Paper).
>So that leaves non-technical managers telling non-technical nerds to just install WordPress.
Good summary of how the world operates generally everywhere. It's a clown world.
> We're a clown industry.
I'll generally agree, and I include myself in this industry, but we've simply have been bound by compatibility. I don't think anyone chose intentionally to keep the crap around; it was simply never worth it to pay the "break compatibility" cost, until now.
> Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.
The interesting thing is that memory bandwidth has become a big issue. CISC instructions take up less space than the equivalent RISC instructions, so you can effectively get more instructions per cache line. Effectively the CISC to RISC conversion acts as a type of decompression. Because if that, stopping the CISC messiness without moving to a compressed instruction stream would actually hurt performance.
One of the reasons the M series of processors from Apple can manage such a high instruction throughput is that the instructions are fixed length, which allows them to just be slotted into the multiple instruction decoders. The instructions compression provided by CISC in the amd64 instruction set means that the instructions do not start at predictable places, which makes it much harder to decode many instructions per clock cycle.
> CISC instructions take up less space than the equivalent RISC instructions
In theory CISC instructions take less space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
> we're not serious people
Absolutely. The industry could have moved towards safer languages, better coding methodology and formal verification years ago (see for example MISRA C as at least a partial movement in this direction). It didn't, because it was cheaper not to.
We've had Ada since the 1970s yet it was never widely adopted outside of DoD and even DoD has moved away from it. Why? Whatever that answer may be, and I think it is as much about the novelty-seeking of the software world as anything else, would likely tell us a lot about how we ended up where we are.
Your desire is not to build things on quicksand but your solution is to just throw LLMs at everything and rewrite it all? That's not the solution and causing even more rapid churn by ditching backwards compatibility is just going to exacerbate the problem.
This goes double when you add in the same non-technical-sourced pressures that caused developers to take shortcuts are still there, and now even worse with their unrealistic expectations for LLMs.
It's simply not realistic to expect the entire world rewrite its entire technology stack from scratch, starting at the transistor level on up every time there's a new industry innovation in security or performance.
LLMs might make this somewhat easier, but you're still going to have to deal with backwards compatibility and legacy systems. Completely eliminating the use of architectural cornerstones like x86 or HTTP or even PHP across the entire industry isn't going to happen anytime soon, let alone overnight, especially if the only argument for doing so is "we could design this better if we implemented it from scratch".
> to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
There's only one area I sorta give a pass, and that's mainframes. It takes an insane amount of physical servers to replace a mainframe. Why IBM didn't invest more into making mainframes a drastically better platform for devs is beyond me. I don't know that any other server platform has ever achieved the level of uptime a mainframe has.
Still, it is no excuse to leave them with ultra legacy code that remains unmaintained for decades.
...because Mainframes were not thought for Devs & Tech People, but Business and Compliance Clowns enabled to do some stuff without CS degrees :-D
Sure, but IBM could have changed all of that and made mainframes drastically more approachable and viable.
(SRE here)
Exactly. There was even a whole domain of expertise (SRE) that exploded because of the lack of engineering rigor. That's not to say if everyone did all the right things all the time there would be NO need for SREs, but there would be fewer of us - something that I've tried to communicate to everyone I've worked for in the past ~14 years of being one.
But we had to deliver. We had to increase shareholder value.
SREs became a thing because management realized the DevOps mindset of making your programmers DBAs and sys admins wasn't really working but management were too ashamed to admit they were wrong so they invented a new term.
Well, to be fair, having separate DBAs and sysadmins wasn’t working either.
Mainly because they kept telling the developers "No". SREs just do that at scale.
> PHP was a joke language from the start
I am no fan of PHP but it wasn't really a joke language. Its goal I think was to add some dynamic snippets to your homepage for which I guess it served its purpose pretty good. PHP even originally stood for Personal Home Page iirc. The problem seems to be that the rest of the language was built on top of that. I haven't used PHP in over a decade, so I don't know if it's still the case, but you used to start a PHP file with a PHP opening tag, which is such a weird "feature", but I guess kinda makes sense in a world where everything outside of PHP tags used to be HTML.I remember seeing PHP files that were impossible to work with: thousands of lines with HTML mixed in with PHP classes etc.
It's been a while for me as well, and I don't know what's original and what's a backronym, but the well-known "PHP Hypertext Preprocessor" name is sort of part of the answer. The "weird \"feature\"" is central to the point of PHP, which you sort of mentioned, just overspecified as dynamic snippets instead of reusable snippets generally. Since a php include() could (and very often did) pull in things like HTML (page templates) or CSS (pre-SASS/LESS/variables) it was necessary, or rather natural, to explicitly invoke PHP (invoke it again, even, separately from the tag preceding the include statement).
This was the tradeoff (or should I say trade-up) for going from
to (Of course, as you point out, we promptly recreated the former situation in PHP -- but maybe there was some rationale to it? I wouldn't know; I did my best to avoid that kind of overwrought PHP project)Happy to see people who still know Perl around. Mojolicious is still a thing, by the way.
Lol, thanks, but I only wish I could pull off wearing the P.I.M.P. shirt.¹ I've always been fascinated by the whole culture of it, but I wouldn't say I really know Perl, even if I once cobbled together a working irssi extension.²
Anyway, for (hopefully) your enjoyment, here's my best fizzbuzz golf (but not the best):
1. https://i.vgy.me/X8Rdpk.jpg2. Really cobbled, and in all seriousness that's why I say I don't know Perl (I only did any of this stuff with very heavy reference to documentation and no real sense of orientation at all)
bonus: https://i.vgy.me/Q5qIIP.png
Not sure if I disagree with all your points, but this one caught my attention:
> HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays
HTTP 1.x is that, perhaps. But I was in the trenches when HTTP/2 came out, brand new and running on binary. It was so new that there were very few implementations around, and my team had to code one. The people who worked on the spec had a lot of learning to apply from HTTP 1.1. That resulted in many nice bits in HTTP/2, but HTTP/2 also had serious issues at a spec level. Which is my way of saying that "modern" doesn't necessarily mean "bug free".
Just goes to show how quality never is and never was a key to success. Same with JS. That trash only became successful (widely used and popular) because it was conveniently available in the browser and hit a user need.
> As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Not sure why you would. It seems like the people who made these compromises were roughly right and the problem only escalated when it also came with a solution.
FYI For all your smurky jabs at human's coding abilities, AI would not know how to program or even exist if weren't for humans.
The reason PHP and other, "joke languages" are still in use is because business needs power businesses, not engineering wants. Plenty of businesses are still run on pen, paper, and custom spreadsheets because those things just work or work well enough. Could they do a better job or scale up more with a SaaS offering or two? Possibly, but why?
SaaS... the thing where you have to shutdown your business for the day because AWS us-east is down even though your application runs on Azure?
> We're a clown industry.
Who's we?
The issue is simple: YOU work for clowns who prioritize financial success above all else, including quality of output. You usually don't have the ability to say "No" to a bad decision made by a senior person. Deadlines, managers dumping more work, feature creep, etc. Then, when you can't deliver they taunt you for their incompetence. So you eat shit all day long churning out crap. That or management hires the bottom of the barrel because its cheap and maybe one or two seniors who eat turd sandwiches all day, give up and ship shit. Enjoy workplace hell. Fire your incompetent boss.
> HTTP, naughty bits
It's especially fun when not implementing the naughty bits is its own source of vulns. Your code is simpler and less prone to RCE, but your proxy mishandling or whatever allows for credential smuggling attacks, identity spoofing, request smuggling, cache poisoning, and all the normal issues at the application layer.
I get your drift but... This sounds a bit like advocating "why not ditch all progamming languages and build some super language that makes no exploits possible". While we are at it, ditch the Von Neumann architecture. Or saying "why not ditch all natural languages in favor of Esperanto".
No, we don't need the "perfect language". But we definitely need to switch to better methods - which were available for decades already - more quickly. There are plenty of memory-safe languages. They have been available for decades. And here we are, a huge amount of servers affected by a memory bug, in especially badly written C. There are probably many more fundamental design bugs in PHP.
PHP itself is "memory safe", you are criticizing that it runs on C but that's a C problem.
Don't all industries work this way? Construction has "old work" and "new work" versions of many parts. For instance, replacing windows on a finished house is a different job from installing windows on a house that's still under construction, so they build "replacement windows" and "new windows." We don't demolish functional homes unless they are unsalvageable; we cut into drywall and patch over the hole. The drywall would look bad if you looked at the backside of it, but the homeowners can't see the inside of the drywall and don't care.
This is a good analogy! Another similar analogy would be construction codes for earthquake proof, or fire proof or whatever safety feature new building must have to be compliant. We don't go and fix everything currently built unless we have to, or can.
The risk is of course, an earthquake where it could destroy all houses built before year X.
But we do the same in all industries, path of least resistance.
> PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people.
Don't forget the other half of the web development stack: Javascript. The absolute worst scripting language ever desi--well no, it wasn't designed, it just kind of happened accidentally. At least PHP solved a problem of the day, Javascript was nonsense from the start, and somehow managed to become critical infrastructure.
I'm seeing this claim all over this sub-thread and I will stick up for JS here.
While yes, PHP begun as a collection of macros and was never intended to be a programming language, JS was made by someone with intention. To quote from wiki,
> [Eich] originally joined intending to put Scheme "in the browser", but his Netscape managers insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.
I've seen quotes before from Eich himself I believe that he was combining these influences at the time - Scheme's closures, Self's prototypes. It didn't "just happen".
Yup. Another reminder of how far software engineering lags behind other engineering disciplines in rigor and accountability. The chickens are coming home to roost.
This is also a result of consumers putting up with every kind of shit they've been dealt. The application layer has been the biggest resource hog.
Maybe… it’s about money? As long as companies get away relatively small fines for massive private data leaks, who cares? Equifax anyone?
Still, I pray you’re right.
Everything is legacy garbage, except the new hot thing, which is next year’s legacy garbage
I hope that the current enclosure of hardware + the help of AI means that we might finally, finally have an era of optimization in which software is made to run much better on existing and older hardware. How nice it would be to have an OS and basic software that opened instantly, responded as soon as I clicked, etc.
If you think we are a clown industry, I would like to introduce you to.......gestures broadly across the horizon.
> the tendency of software devs, and in particular web devs
Software devs absolutely love to create a mess, and are never challenged by business, product, management, or you name it, to increase speed to market, cut down cost estimates and, to say it crudely, deliver half-assed work.
Systemic issues have systemic consequences.
Any effort towards a perceived best practice or bug fix that doesn’t have a measurable impact on the business is a wasted opportunity cost. Engineers only have jobs because the software they build makes money. It’s not art work.
There quality should be there, but it should only ever be “good enough”
Have you ever watched Ken Burns' Brooklyn Bridge [0]? That doc struck me as straight-jacket-in-a-padded-room insane. The bridge's designer John A Roebling [1] was a Prussian who seems mostly self-educated (who wasn't in 1820? lol) and kind of learned by doing / invented "on the job". Successfully built a couple bridges, dreamed up the mega-project and started building it using caissons [2], then died with it unfinished due to personal injury and hubris. His son took over and completed the bridge, but was plagued by poor health as a result of caisson disease from the Brooklyn Bridge project until his death. Throughout its history, there were concerns about safety, repairs made, upgrades made .. and as a result, there it still is today, as good as it ever was and used daily by zillions of people.
I bring this up because it's the first thing that popped into my head thinking about PHP's legacy. And, admittedly maybe it's not the best analogy, but when people shit on the caissons that bridged the internet because it seems crazy in hindsight to continue use those techniques, shit dreamed up by wacky people to do the impossible, or maybe said we should tear it down and build it a different way, the reality is that sometimes you just leave the bridge in place and improve where you can. It's still standing, you know?
I might be stretching here with all this, but despite you making some very defensible points, I just don't buy into the whole narrative. Just because retrospection has blessed us with the ability to intellectually point out that we built things on quicksand doesn't mean that there were real alternatives to build on at the time. The ease and speed that things like PHP provide(d) allowed enough things to be created to make the web as we know it coalesce into existence in the first place. Pedantic or more expensive or arguably safer choices easily could have slowed progress to a crawl, OR you just build the bridge and see if it's still standing 143 years later.
And in some cases, it is.
[0] https://www.pbs.org/kenburns/brooklyn-bridge
[1] https://en.wikipedia.org/wiki/John_A._Roebling
[2] https://en.wikipedia.org/wiki/Caisson_(engineering)
Was it software devs? I've always had the impression it was management that didn't want to give us time to address technical debt, but just focus on shipping more features.
I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.
When I did the EM role my biggest fights were pushing VPs to give the team more time. Features rushed because some VP told some board member it would be delivered by X. The first mistake is setting an aggressive schedule.
With AI you can actually start fresh, don't know if its that easy in CPU design, but you can literally rewrite something from the ground up with rust or whatever you want now, and make it reproduce the behavior of your old program
Not only, the fashion driven culture, rebuilding just because, ships fast and break things, offshoring,....
The Morris worm was already a sign, but alas, as long as there is no punishment, no one cares, like buying at those 1 € shops.
What language was a better choice than PHP in 2006? Or in 2001? Some times what we see (now) is a choice that looked like the best option (then) and only became less good over time. Humans do that pretty often?
Perl.
Maybe he was a fan of cold fusion?
I just shuddered reading that line.
The thing that pisses me off about people who complain about PHP is that all these smarty pants people have pointed out the flaws in PHP, but never really understood why it was successful, and because of that they never created a language that could succeed it. The things that made PHP successful were:
1. It just werked. You could write incredibly shitty code and it, like HTML, would work as long as there wasn't a fatal error. And sure you could just say "git gud", but that's not going to happen. People will just use the best language that works for them, and in this case, it was PHP.
2. It required very few resources to run low to medium traffic websites. Because of the Apache mod_php module, PHP sites wouldn't use any resources if they weren't being served, unlike every other language at the time. So it meant places could host thousands of websites on the same server no proble.
The guy who created PHP, Rasmus Leerdorf, never wanted and never expected that PHP would become as popular as it has. He has mentioned that he thought that at any moment, someone was going to come around and create a language that would succeed PHP. But it never happened. People are just better at pointing and complaining instead of solving the issues that people want solved.
>to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet
It's totally the devs fault and not the environments devs have to work in. Deadlines forced down on you until you have to make compromises, 24/7 having to compete with people who actually don't care because you have to meet months end payments somehow. Whole businesses blinded by a tech gold rush.
>We're a clown industry.
I do agree here, but that includes every non dev person.
Time for me to drag this old chestnut back up.
You don't see the same problems in say, structural engineering as you do in software engineering. I suggest this is due to needing to go through the formal training required of a structural engineer, and membership bodies like chartered institutions, with standards and codes of ethics. We might want to reflect on that
The state space of what you must check to ensure correctness in physical engineering is infinitesimal compared to ensuring correctness in software. Correctness in software is qualitatively more difficult by nature and an open problem at a theoretical level.
No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.
It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.
I think being legally liable for any failures that pop up probably also has something to do with their more cautious culture...
Structural engineering, is engineering (though mechanical engineers would disagree), 'software engineering' not so much. It just happens to be a word that's a useful synonym for 'building things'.
I rarely call myself an 'engineer', preferring developer or programmer.
Isn't software "engineering" or shouldn't it be considered that? Creating a new painting program might not be considered that and a software failure would have little impact, but there is a huge amount of software which is essential for the operation of complex systems. We just had large parts of the internet impacted by the PHP bug - a lot of businesses were harmed in their fundamental processes by it. Like if a roof of a warehouse had collapsed.
In Europe, a lot of supermarkets were hit by a remote exploit which allowed attackers to switch off cooling of food. A blood bank in France was attacked the same way.
So how would building software for important or even safety-relvant systems not be considered "engineering"?
Especially, as faulty software might not only cause a product or device to fail in a dangerous manner, faulty software in this day and age often makes it possibly to remotely attack the faulty product.
I agree with you but I would extend that observation to include the age of the industries. We have been making structures for thousands of years. Software is an infant compared to that.
I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".
You do. Structures fail. Less so in parts of the world where serious regulations are in place.
We don’t have time to tinker about for months on regulatory processes and making the our screws are “B6”. Software is a different industry.
Sometimes software is a public works project but sometimes it is a backyard shed. You just have to know the difference.
And I could get a structural engineer to check the integrity of a shed in very little time indeed. Sounds fine to me
But would you? Why or why not?
The people who set the deadlines are trying to stay competitive so there are contracts with clients so your salary can come from somewhere.
competing with others doing the same thing in a zero sum game. We all just have to simultaneously coordinate to agree not to set unrealistic expectations or deadlines! Sounds easy, right?
Quality software is out there, but you have to pay for it.
You forgot NPM. Whereby we download code from unknown authors on GitHub and run in with full access to our filesystem on our machines. No vulnerability, it's been designed like this, we even have designed scripts to autoupdate vulnerabilites, that's the proof that vulns are not common.
It's okay, Perl, Python, Go, and Rust do the same thing with their respective package managers.
Well, you certainly should check your Perl knowledge - it's older and do not use Github as a repo :) There is CPAN and testers, etc. Other languages do not invested into that "intemediary" infra.
So "downloading" part is just looking similiar.
Not to worry, Linus said that given enough eyeballs, all bugs are shallow. So it sorts itself out, because we all review the code we download, right?
The amount of begging I've had to do as a Ruby on Rails dev to be given time to refactor debt was unreal. This was pre-AI, around 2018.
I basically just worked extra unpaid hours with a colleague to do it since it was frustrating. Not even from a security standpoint as it is now, but just plain developer happiness.
But while we were cleaning the Swamps of Dagobah the other team was extending them.
Our deliverance came when the other team got woo-ed by React and started coding less in Ruby.
For my mental sanity I treat the React project as a black box.
Just heard they had to update the Redis connection configuration in 6 places, after we had switched to Sentinel based connections.
I seriously can't with my people sometimes.
You are not industry at all.
Also, path-dependency is a real issue everywhere. You would know that if you would actually experience true industries. All in all, software world is far more malleable than anything.
> the effort that went into making it good should have gone into ditching PHP
What effort? PHP foundation has one employee!
> The bandaid mentality is what got us in this situation.
> We're a clown industry.
We are clown industry becauee nobody would sponsor solid research, infrastructure and fixing all those bugs! PHP is junk literslly written over nights by some volunteers!
I suspect you're being intentionally obtuse here but the PHP Foundation isn't where PHP gets written. Zend are the closest we have to the PHP company I guess, and they have approximately 100 employees, then you've got however many people are employed either as contractors or by other companies with a primary focus of working on PHP itself.
> PHP is junk literslly(sic) written over nights by some volunteers!
And yet everyone knows this, and millions of people still continue to use it and develop new software with it, to avoid learning from our mistakes. The software industry is just not interested in fixing these problems; I've heard people upset that AI is pointing out flaws, instead of being upset that flaws exist. Deeply unserious.
To me this is just yelling at clouds.
Things have moved on from PHP, but at the time, the alternatives had many more tradeoffs in a wide range of cases. Without PHP the internet would have unfolded much differently, much more slowly.
The "bandaid" mentality you decry exists of course, and is outright bad in some cases, but is just good business in many others.
Rewriting everything makes no sense. And, of course, in the vast majority of cases is never going to happen, so advocating for that is effectively advocating doing nothing at all for 90%+ of sites. A much more efficient and effective approach to using AI here would be to find and fix issues in the PHP runtime, and to assist in automating the deployment of the runtime. Time spent on this fixes thousands and millions of sites at a time, in a consistent, improvable way, rather than one at a time, in a piecemeal way.
> We're a clown industry
I think if we want to bring more engineering discipline to software development, we need sober analysis, not outraged rants.
Just for my curiosity could you name a non-clown industry?
My guess is aviation or .. defense?
We don’t have billions to throw away on making sure our about-dialog is memory safe.
There is no upper limit on the definition of "clown." It all depends on how much money you have to play with and how many nines you're willing to accept.
>Just for my curiosity could you name a non-clown industry?
The real clowns union paradoxically is the least clownish industry one can find.
> We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.
Ironically, the opposite is the case with LLMs. Now those on your teams that wanted to stop the clownery will be overruled by the vast amount of bullshit code from their less skilled peers. Of course, those that care can use LLMs to faster clean up, but there's no way they are able to keep up.
Managers always favored outcome over correctness, and not giving two shits about the internals was, and will always be, incentivized.
On the RISC stuff specifically: It sounds like you're saying CISC is just RISC with a microcode translation layer. It's not wrong, but then RISC is also RISC with a microcode translation layer.
The CISC vs RISC debate hasn't been interesting in a quarter century at least. The only real difference is that the instruction decoding (which CISC and RISC both have) is likely going to need more transistors on x86 than other contemporaries.
But I'm not sure what you mean by "stop doing things like that". The ISA is "the API". Sometimes the best CPU implementation (for whatever definition of "best") will need to change the ISA-to-microcode translation.
It's not reasonable to assume that a decades old ISA will have a 1:1 instruction to microcode mapping. Hell, it's not even 1:N. Macro-op fusion makes the mapping N:M. So you could say that RISC also has variable length instructions, in a way.
And RISC-V has two sizes of instructions, with RVC. So it's not even "super transistor efficient because all instructions are 32bit".
Then there's the "reverse micro-op" that is instructions intended to cause traps for software to handle. E.g. Alpha's PALcode that handled (among other things) unaligned memory accesses.
>frustrated by the tendency of software devs, and in particular web devs Are you sure that's not the typical cost optimisation of management/c-levels rather than a developer problem?
What you wrote reads a bit like ye olde typical "nyeeeh javascript! you're only a dev if you write everything in assembly! kids these days!"
sorry, but you are really naive. php was peak engineering compared to the contrived layers of llm generated executable pseudocode we are about to build upon for the foreseeable future. php is opcode running in a C/C++ driven virtual machine. what llms are spitting out is statistically inspired plagiarisations void of sense that linguistically abstract non-linguistical concepts chaining all that crap then build towers of it and nobody will be able to even reason about what's going on without adding more llm to the mix. think apollo guidance computer but 1TB of code.
Haha, so how do I become a palace clown? Just kidding. I like and trust AI, but I don't think AI can solve the debt, because AI code creates a different type of debt than code written by humans.
We can now leave the 1990’s behind us by generating code non-deterministically.
At least put some formal verification on top of that GenAI pile.
"We're a clown industry."
How can even call these people an "industry"
Yeah, I just don't see how every chrome or even firefox tab has to consume 500 mbs each, it's actually insane, even for basic websites like HN
...and not forgetting that there are always 10+ spare threads on the shelf which each consumes 300MB+ while doing nothing...
It seems "coding AIs" can enable the final form of coding (end game): binary specs with direct assembly implementations. No more compilers.
I think we need to start over with safer languages and runtimes.
That’s what I started to do 10 months ago.
You want a safer language AND transpilers from PHP, JS, Python etc. into it? So you can find issues in your original code using source maps, or just speed up your PHP by 10x and your Python by 100x? Here you go:
https://ulanguage.org
We all know software is swiss cheese. Now it wil be swiss cheese with duct tape on it. So what.
Or have the devs been Vindicated as AI is the newest scaffold
This sounds like "I told you so".
What the heck have you been doing instead of pointing out the obvious?
> As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.
Your analysis is severely flawed and naive.
Software devs often patch and sidestep the root issues for the same reason why every single engineering field resorts to patching ans sidestepping root issues.
Why do you think there is such a thing as aviation duct tape? This is a field where people's lives are on the line.
There is a very puerile belief around opinionated junior devs which an inconvenience in the code justifies redesigning whole systems, even if they are still quite capable of performing their functions. Things need to be clean and ideally elegant, and any minor deviation is cause to tear everything down and start over.
In the meantime, experienced and competent engineers instead get the system back in working order and downgrade the criticality of existing issues until it's convenient to address them.
Go ask a project manager if all bugs should block a release, or if it is ok to release something with a known bug. Listen to them. Perhaps then you'll understand why patching works.
> We can leave the 1990s behind us.
I'll believe it when I see it.
Otherwise, I completely agree.
Are you sure you are senior? Because in my 22 years of experience in 3 countries and host of employers (banking, telco, insurance, military, municipality, energy distribution, retail etc) it was always management setting the tone and only fools ignore the hand feeding you and go against it due to some 'higher principles'.
No we don't need to have documentation and keep updating it what you can't read code? No we don't need to rewrite system that was patched ad absurdum so codebase became fragile and its hard to navigate layers of abstractions. We need to deliver this project yesterday at all costs since somebody up there slept on requirements for 6 months and didn't do their basic job, and we will never pick up half-assed pieces we were forced to deliver. No we don't need to update those 12 years old libraries, too much work and testing. I could go on and on.
It seems like you consider engineering to be delivery of perfect things, or utter failure. Thats not how things are anywhere, sw dev is more unstructured but you also don't have 5 million ways to build a good wall using every possible substance in the universe, do you.
As someone who went into electrical and computer engineering in the 90s and was noodling with toy neural nets in the 90s; yeah agreed with the joke/clown knowledge job
Been saying to boos and rotten veggies "it's just electrical state in a machine; yall are deluding and debasing yourself for money." And "if you want to improve security stop using leaky abstractions to configure your machines".
Even better is that AI is replacing all knowledge work it just reinforces how absolutely bonkers the US "services economy" is and giving social stature to credentialed randos whose skills are whittled down to cooking frozen meals, grubhub, and Excel Sheet expert; unserious country peddling before the eyes of the poorest manual workers all these years that their degree in accounting earned them the right to wander through someone's home town across the world via resource intensive travel
Or better yet just being born rich earns them that!
This is an unserious country and social culture top to bottom to continue to assume modern people of nations rebuilt since Murica bombed them to the stone age don't see how Americans are drinking their own piss since the end of WW2; refusal to acknowledge externalities like generational churn (among all the others) makes it clear America is an unserious country.
HR and accounting and even a law degree do not make the individual worker bee irreplaceable themselves; whole lot of arrogant low skilled "knowledge workers", biological fuzzy VHS of often debunked pseudoscience studies now 30 years outdated... can pound sand.
Set aside the circumlocutions inherent to old thinkers like Marx and Adam Smith and capitalism is a social/communal discovery of services and prices; seems pretty fucking social and communal. But that's not "the Sacred Jedi Texts!"[1]
Top to bottom American society is a clown car stuffed full
[1] will take to my grave Luke screaming about Jedi Sacred texts was a metaphor for dogmatic people in general
We are not a clown industry - we are an evolved industry - both parts of that matter. We evolved in an environment where these kind of attacks were not possible or were freak, state sponsored events. Kind of like moving from a sheltered lagoon to the Pacific Ocean. And we are an industry - where profit matters. Open source was lead by people like you who cared and did not have profit to constrain them. Which is why it’s better engineered (and frankly if open source like Linux or FreeBSD had not existed in our lagoon, the profit would have failed earlier and commercial Linux would have had to been built and built to same standard (god knows how)
But we are out in the pacific now, and boats that sink make no profit, so we will evolve again, and again.
But it’s hard to blame Moana standing on a pacific island for not inventing a nuclear powered battleship.
(Trying not to be too blame-y on either side)
These attacks aren’t freak, and nor did they take state money. It’s more so that security by obscurity really did work because it didn’t cost a few dollars to attack people. Now we’re having to reckon with security debt, not code debt. It’s still quite fashionable to increase code debt to buy velocity and efficiency.
So I was saying that prior to AI say 2025, complex multi layered attacks were so hard to do that the resources kept it at a low frequency. Now layering ten different vulnerabilities to capture a flag is just five prompts away. This used to be so hard it could be ignored as a “likely” security risk.
That’s changed - we are in stormier weather and need better boats, but it would have been unlikely to have built battleships to sail the lagoon just in case…
Every line of code you make is a line of code you must maintain.
It's like anything else in life: a house, a car etc.
There's no debt about it though. I hate the term 'tech debt'. It's very vague and has these negative connotations that are ambiguous.
ironically, AI is also making us create a new whole new level of technical debt - where _no one_ has actual understanding of the code being written and we're just trusting the machine
Multiple times in my career my teams have received ownership of large projects, often the legacy kind, either though reorgs or layoffs or acquisitions, that we had absolutely no understanding of the code of. It was just chucked over the wall with some docs and runbooks -- maybe a short handoff meeting if we were lucky enough to have the previous owners around. And given that this was typically on top of our existing workload, we did not have the luxury of understanding the new code at all.
The world didn't end. It was a complete black box, but we followed the runbooks and kept things running, and only learnt enough of the code as needed to fix any issues or add any enhancements that popped up. Diving in, doing some software archaeology, and spot-changing relevant code became a skill we had to develop.
At scale and over time, I would guess that the percentage of code running on machines that is actually understood by anybody approaches 0. Yet the world does not end.
right, but the scale was MUCH smaller. And there's usually someone who know someone who has context, so you had someone to call.
I'm working on a repo these days that's larger than _entire companies_ I worked with in the past. A 10-person team maintaining more code than 100s at a previous job. The _scale_ makes this wildly different from what we're used to, no matter how much "legacy code" you had to maintain before.
I used to work on Visual Studio 20 years ago. At the time it was 30M lines of code with a history going back over a decade and about ~1k people working on it. Product cycles were measured in years. Time spent working on new features was measured in months, since no one understood how it all fit together we then had to spend years playing whack-a-mole with bugs, to stabilize it before shipping it. I regularly had to debug through large parts of the stack I'd never been in before. So did lots of other people.
Being able to work effectively in large amounts of unfamiliar code was an expectation for mid-level engineers (L62 if I recall correctly). Its not a new skill, but it is increasing in value again.
Focusing on the scale feels wrong.
These legacy codebases could be incredibly massive and documenting how to run them alone could be a multi month reverse engineering project.
Now ai can do all that part. Dealing with a legacy or unknown codebase is so much easier…
Yes but you are talking about code which you can do archeology on. A given code base may seem a complete mess but you can often understand it by deciphering which programmer created what and what their style and intentions were. I haven't tried to understand reams of vibed code so I am just curious and perhaps skeptical whether any kind of similar process could be used.
It is possible, but I it will be really difficult if the code is not reviewed stringently for simplicity.
What I've found is that even the best models can write very good code "in the small", and the code is mostly correct, but they can be highly problematic in their design, architecture and abstractions they use. The most common problem is that there is a strong tendency to overcomplicate things, and often this can be traced (ironically!) to the agents not having enough context.
E.g. a very common failure mode is that agents are unaware of some invariant in the architecture (or the fact that they could potentially stipulate a new invariant) and write code to handle a dozen edge cases that would never occur. The code is correct, but there's a ton of unnecessary slop.
My suspicion (confirmed by friends and posts on HN) is that at most places, people don't bother reviewing the code and blindly ship all this slop. The reason things haven't imploded yet is a) the code is usually technically correct, and b) all that additional complexity is never exposed to humans -- it is just outsourced to even more agents to manage. Which explains Anthropic's exploding revenue, I suppose.
That said, it's not like things were better before AI. I once had to go Indiana Jones-ing into a humongous legacy Python codebase so full of magic that there were some code paths I could never figure out even with a debugger. I could only tell that if I got a row written to a specific table, some completely disconnected code path elsewhere would get triggered. I suspect what was happening was a function name was being constructed out of 3 different strings from 3 different sources, one of which was a column in the DB row that was getting written, and that function was being eval'd in some thread somewhere.
This was to fix a bug, which I managed to do without ever figuring this flow out. I still spent an inordinate amount of time trying to figure this out before I realized I was being too idealistic and closed the ticket and moved on. I bet an agent would have figured it out though.
Not really. One of my coworkers has been using it more recently, and just pushed a merge request last week that mixes a bunch of different styles with little abstraction. And I don't mean styles like linting, it looks like it was done by three different devs who couldn't agree on functional or object oriented style, or whether "spooky action at a distance" was good or not (extra effort to avoid it in some places, relying on it in others). Plenty of things aren't named well either so you have to look at the implementation to figure out what they're doing. And this wasn't even very big, around a thousand lines greenfield.
I like to think of it as a new abstraction layer on top of something we've been comfortable with for years. The developers of the past had to trust that human-readable code would compile to the machine-level bytecode they were used to write, and that even though it wasn't as efficient as they could make it, one day the benefits would outweigh the negatives. Today most developers don't understand compilers well enough to even begin questioning if the code doesn't work because the compiler has a bug or because their code has a bug. They have to trust the abstraction layer beneath their current domain, and they have to find ways to prove that their work is correct in that domain (e.g., writing a sufficient number of unit- and integration tests, compiling with different compilers to different targets, etc.).
We, too, have to adjust to this change, this new abstraction layer, because whether we like it or not, the code an LLM will produce in no more than five years will arguably be much, much better than the code any 10x developer could produce even if given months of time and an infinite supply of caffeine.
We "just" need to find a way to confirm that our work in this new abstraction layer - primarily prompt engineering - results in the code functionality that we had in mind, not necessarily the code implementation that we had in mind.
I'm still unsure if we won't figure out that the right abstraction level to describe what code means is, well, code.
I've spend the past month-or-two on developing a platform scroller game for smartphones using nothing but AI. It has created everything given my instructions, to my liking, from the way the game is played to graphical assets to sound effects. It looks and feels like any other typical studio-developed game you could find in the store, the difference is that I didn't have a studio of professionals working fulltime for months or years with various levels of project management and what not. It's just me. Me and my agentic coding subscription.
Vibe coding originally meant giving an LLM an instruction, having it regurgitate something potentially wholesome, testing it and feeding back the errors for it to fix it. What I've done in the past couple of months is so, so much more than that. I'm a puppet master and my coding agent is my puppet. I don't need to understand the code when I can describe the problem I want solved and it will do it 100x faster than I ever could.
I didn't use code to describe this level of abstration. I used English prose - and a heck of a lot of software engineering theory, mind you. If you know the solution requires a quad-tree and binary search because in this case, that is the best option, then that's an instruction, not a block of code.
Is it faster because you are using English prose or because you don't actually have to do a great job of specifying your game. If you say, make it look like X or have the controls like Y; you are just reusing the work of someone who has specified all that, probably in code. If you actually had to spell out every rule in English, you would find code is a much better language.
You are probably right, and then I would most likely copy solutions to specific problems from StackOverflow like in the glory days of the 2010’s.
My first lead developer was an old school developer who preferred to look up guidelines and solutions in physical books he had on his desk. Nobody should waste time reinventing the wheel.
To answer your first question, it’s faster for me because I can formulate my request as a developer as if my AI agent was also a developer (in a sense it is) faster than I can figure out how to implement it on my own, especially in a new language and ecosystem. I didn’t just prompt Claude Fable at Max thinking capacity “yo dawg make me a game for iPhone that will make me rich just pick whatever style and stuff” and let it run for a week or two. I brainstormed the idea of the game with my AI agent (Opus 5.5 mostly at High), asked for suggestions, adjusted its proposal to my liking, asked it to flesh out an implementation plan for each milestone of the development journey, worked on different topics as we progressed (introducing complex graphics was sometimes challenging which required a bit of guidance for it to get the assets right), had it create a level editor for me because explaining every single thing was taking too long when I could just drag the sprite a little on my screen and tell it to compile my changes, we worked on ambience audio and sound effects at multiple levels (background, middle, foreground), and the list goes on.
A LOT of work has gone into this project, but without an AI I would not have gotten any further in the time spent than barely figuring out how to get even a simple round ball bouncing on a flat surface in Unity. With AI I’m looking at a feature complete game ready to ship to the App Store after the last bit details have been settled (advertisement laws and whether to monetise one way or the other or not at all, mostly).
AI is an incredibly powerful technology and when you wield it correctly you can go from 1x or 10x engineering to 100x or even 1000x at minimal risk (because you mitigated it along the way).
If you don't particularly care how the code works or specifically what it does it seems pointless to worry about abstraction. Since, as you say, it solved the what you wanted solved and did so quickly.
But when you do care, it becomes important.
And, I suppose, computer code in general is terrible about writing things at the right level of abstraction, or at least human generated code is and I think LLMs do worse, somehow. So there is something to be said for prose as a specification language in most cases.
But I still think we're going to end up with some kind of code to reason about programs. Same way mathematicians have been using mathematical notation to reason about maths. But maybe it will be different code. Who knows, literary programming might catch on.
Is it a challenge to Agile methodologies? I mean is most software today designed at all? If we want a pm to be able to write half baked feature ideas and expect the devs to sort it out, rather than just paste the ticket into Claude, don't we make this chaos inevitable. Maybe there is a missing formal engineering layer missing between feature request and prompt. Llms seem to do much better when they are told exactly what to do, vs when they are given room to...express themselves
I note you're downvoted but I strongly agree. Forcing humans to speak machine language is inherently inefficient. Having them speak a language we're already comfortable with is an obvious evolution in abstraction and control. I suspect you've ruffled some feathers because speaking machine language has been a knowledge and skill gate which is rapidly becoming redundant. It doesn't feel good when one's career and skillset become much less valuable. Never-the-less, this technology is not going anywhere. Opus 5.5 already codes better than most of my developers at about 100x the speed. Architecture is still valuable, but I have no doubt that this is also going to be done better by AI soon.
Some people react to harsh realities and truth with negativity and the only the only things they have control of here on HN: a downvote. :)
I, personally, never downvote people I disagree with. Who am I if I don't use another perspective as an opportunity to learn and grow? I can tell that many people agree, too, because my "comment score" is still mostly neutral at the time of writing.
Human speech is inherently inefficient and ambiguous. Humans rely on non-verbal clues and context to distill the exact meaning of phrases, and even then the potential for miscommunication is non-negligible. It is a huge leap to assume that artificial intelligence can succeed in flawlessly divining intent from regular human speech to the point where it can generate debt-free code. And if your solution to that is to say "no, you need to issue specific instructions to guide the machine to the correct solution" then you have not removed the skill requirement, you have merely redefined the skillset.
I think you mistakenly believe that the existing abstraction layers don't already contain ambiguity. It's true that formal languages are built to reduce ambiguity, but there is still much ambiguity. For example, gaps in the specification still leave room for interpretation. [They list some in Cambridge's free C course:](https://www.cl.cam.ac.uk/teaching/1516/CandC++/lecture10.pdf)
- Implementation-defined: the compiler documents its choice, e.g. sizeof(int).
- Unspecified: the compiler picks from options, e.g. argument evaluation order.
- Undefined: no requirements at all, e.g. signed overflow.
The notes take you through compilers deleting an overflow check and a kernel null check because of undefined behaviour.
There are also abstraction leaks. Spolsky’s Law of Leaky Abstractions says all non-trivial abstractions leak. SQL is one example. Logically equivalent queries can differ in speed by thousands of times.
Also, the translator must be trusted. [See this lecture.](https://www.cl.cam.ac.uk/teaching/2223/R209/Reflections-Trus...) It explains how behaviour can live in a compiler binary and appear in no source.
In other words, formal languages are no different to spoken languages. They exist on a spectrum of ambiguity, assumption, and implied meaning, depending on the domain. Human language has the potential to introduce more ambiguity, assumption, and implied meaning, but that's not a predetermined quality. You can be as detailed as you like in your communication with your AI. To a degree of precision equal to or better than a formal language. You reference this in your last sentence. The distinction is fairly obvious: being specific in English has a much lower skill bar than being specific in C.
One of the more interesting topics in research and philosophy right now is this question of alignment. To what degree to these models understand our meaning when we're not extremely detailed. We can see in research that they're becoming extremely competent at inferring meaning. They can often understand our intent with very few words.
The worry for me is, we talk about future super-intelligence altering the economy and financial system and others to such a degree humans simply won't have the capacity to understand the complexity. It's a fear people are raising currently for the future.
But software powers so much of our modern world, seeing companies decide "well maybe we don't understand the code but trust the governance and harness will allow AI to always fix it" is essentially that above hypothesis in action today.
Indeed, and it's just going to end up as a zero-sum game where the winner is the one who can most adeptly manipulate the machine to cause harm to the other.
Basically whoever has the deepest pockets to burn the most AI time.
This is exactly what has happened the past 50+ years, too, your toolbox was just different in the 90's than it is today.
So if it has happened, should we now proceed with even more powerful and dangerous tools, with a much tighter integration with society?
Is a nuclear power plant dangerous? Or an airplane? Both are examples of an advanced form of what other entities in their category do.
Of course we should proceed with even more powerful tools. We also need even stronger governance of said tools. We don't want an AI-version of the Chernobyl incident but we do want the AI-version of the benefits that nuclear power gives.
Yup. Feels very much it's creating a mess on purpose IMHO.
It's like an over-eager junior engineer that will implement whatever pattern they read about last week. It just doesn't feel trained on high-quality enterprise, battle-hardened codebases.
Even Opus 5.5 on High thinking still littered a root directory of a JS project with source files without thinking to put it in a 'src' directory. It had to be told to use a testing framework. Had to be told to also test with Firefox (the project already had established Chrome /and/ Firefox targets).
I have to continuously burn tokens and effort correcting it.
I imagine it performs a bit better with a huge corpus of architecture and style guides. But I did expect to get some that for free with the "leading" model.
Or to restate another way, most modern programming languages are a highly specialized and specific dialect of english. Perhaps it's possible that with AI we will find a new but equally specialized and specific enough dialect of english for interacting with it when generating code. But then you just re-invented a new programming language for people to learn.
So, It is the same quality as a team of outsourced developers asked to do the same task (at least back in the day; I say this from experience evaluating said "code" that the team delivered -- it did function, I suppose).
Same with that situation. One shot code from prompt is still not great. Maybe if you had a prompt with highly detailed requirements for structure and code formatting it would be ok.
I generally hate the look of AI gen code, so I have some pretty detailed code formatting rules for even small edits. And the AIs still ignore them some of the time.
I don't know what I'm getting at here; other than. It is acting pretty human like at this point in the code delivery phase. Human as in asking someone to do your work for you and you not always getting back what you want; as opposed to being good enough to replace your actual work (assuming you are good at the task you are asking from the Agent -- does work pretty fast though. which makes it a trade off worth considering; but then your time is in picking through the code to confirm it is correct).
the worst case for this is if that doesnt cause sufficient problems to force a reckoning. it has to hurt badly enough that we put significant effort into training legibility into the process.
Meanwhile it's creating 4000 years of technical debt.
Other AI's will patch that, other AI's will find new holes, other AI's will patch that, etc.
Might have some back and forth going on there without ever reaching the state of fast, clean and elegant software
This reminds me of a slightly different take. AI will allow us to deliver on promises made over the past 20 years. For instance, CI/CD is actually happening now like evangelists claimed before and it really does unlock tremendous value, mostly through efficiency.
Software bugs are always a cat and mouse game with the mouse improving with time and the cat elevating its defenses. Now there comes a supermouse demanding supercat skills. But the massive difference now is that the defender has the exact same tools as the attacker.
Every SW developer must use AI to test the security in existing and future projects before deploying. I cannot believe it has not been done yet for all public facing software. And a system must be deemed insecure if it does not pass an LLM stress test. This should also become standardised and maybe included in OWASP.
We can always laugh when we see the famous "PHP is dead" posts after this incident.
It's called Black October https://en.wikipedia.org/wiki/Black_October_(information_sec..., but I think it's just a beginning.
Then what about November? Vantablack November?
It's gonna turn into an Eternal September kind of thing.
https://en.wikipedia.org/wiki/Eternal_September
What's hillarious is people vibe coding massive AI apps thinking its not creating tech debt and security holes. If anything, AI is discovering existing holes, and creating them faster than ever before in history.
All those "paying down" technical debt with AI, I would advise reading the code _very_ carefully. Sometimes the "solution" which passes some test or adheres to some described functionality is incredibly narrow / brittle, and/or has failure cases that are non-obvious.
Yes I'm using $latest_model on high, its still not there. Unless your threshold for "fixed" is "the 1M line lean proof runs, we don't know how it works", it still requires a lot of attention, hand-holding, and scrutiny, especially when fixing issues / working around failures (where it tends to shortcut or invent workarounds).
A developer on my team introduced new features behind feature flags despite concerns about whether we should have those features and how they are going to be maintained. Changes touched 200+ files which is half of the files.
Turns out nobody wants to use them, they caused many subtle bugs in existing features and is a distraction for many things we do.
The developer left the team, and I am left with purging all of this.
Now imagine if he had 100x the speed! I'm sure AI will help him thoughtfully pay off tech debt at his next company!
The same can be said with human-written code. LLM code is by far better than the average developer’s code at this point, and there’s not enough top percentile developers to go around, so it’s a wonderful tool.
Also, those very average developers are also the ones doing the code review.
Below-average developers generating bugs now will be submitting AI created security holes at 10x the rate going forward. Hah, people are literally on this forum debating whether to use openSSL because they can vibe-code it with a smaller surface area (just have AI only create what you need).
Anthropic is literally creating their own git alternative because they are slopping so much code. You think its 100% secure? Even if it has bugs at 10% the rate, there is 10x more of it to go around.
Do you think Anthropic's git alternative tool is more secure and better written than git? Hah, I bet it was just some vibe-coded thing they did over a couple of days, when it starts bogging down, dropping commits, or getting unstable, they just have to prompt harder! I wonder why they won't open source or release to the public, its probably too dangerous to release!
In a few years we'll be able to look back and compare the technical debt in code written since 2026 vs code written in the 40 years prior. We'll then have another metric to quantify the impact and usefulness of AI.
If AI's code is sloppy but bug-free, is it better than the alternative?
I honestly think there are some kind of laws of physics at play here... in the statistical limit of the massively participatory interaction of engineers, there is some kind of least action principle where the system is seeking lower energy (i.e. less code complexity, better foundations, etc), but only locally. The path towards a radically better foundation for the entire industry is outside of the "energy well" that it is currently in---at least that's how I see it. I feel like that's why we see more things like elegant scripting languages rather than ground-up reimaginings of computing itself.
There is a concept of the hourglass model [0] of internet protocols, where IP sits at the waist. I believe that similar things are probably true in any "stack" based structure, such as computing, where the protocol at the waist has the most staying power (which at the current moment could be e.g. x86, or something) because it's essentially the universal translation layer that enables all the language protocols built above it to be agnostic to all the transport protocols below it. So, I see it as an open question as to what the best way to affect change in a situation like this is. I'm interested in if anyone else has any thoughts along these lines.
[0] https://en.wikipedia.org/wiki/Hourglass_model
Earlier this year, the cybersecurity firm Calif offered to independently audit PHP, sponsored by OpenAI. Within two weeks, a researcher at Calif, aided by AI tools, found a way to use the out-of-memory bug to run arbitrary code on the host server, allowing a malicious actor to install malware or read critical data. Now, it was no longer a minor bug—it was a critical vulnerability, and the Calif team alerted the PHP foundation to start working on a patch immediately.
So, the headline should read,
"AI is helping us eliminate 40 years of technical debt."
Since AI found the bug, and probably also generated the patch at this point.
An abundance of solutions is a problem for people who sell solutions.
AI is also helping us pay that debt off too. Going to be a bumpy ride, but we'll come out much stronger assuming we get through it!
fun anecdote from yesterday:
AI removed 80k lines of code and nothing broke. much of this code was written by AI few months earlier.
Does the phrase technical debt suggest that the “debt” could’ve been dealt with if enough resources were allocated or a different engineering paradigm was followed? I feel it to be an inevitable consequence of deploying tireless ai robots dedicated to find issues
It's not just security. When Opus 5.5 got more capable in September (anybody know why? they definitely did something), we suddenly got flooded with a bunch of old debt that it kept finding and suggesting we fix. And it was right, in a majority of cases. Ate us 2-3 frantic weeks easily just to get from a deluge to a ... well, not yet a trickle, but something more manageable.
Opus 5.5 was released at the end of September, could you have switched from 5 to 5.5 without thinking much and noticed how much better 5.5 is?
> As far as anyone is aware, disaster has been averted: The hack was discovered by cybersecurity researchers who reported it to the PHP Foundation
Thanks to The Lord everytime someone discovers the vulnerability he reports it right to the owners/maintainers and there are no bad actors out there keeping it as secret and using for years.
It is observer bias... Everyone reported it the proper way, for all the cases we know of.
Maybe you were sarcastic, then forgive me my denseness.
The strain from the amount of bugs is visible in bug bounty programs. A run on many targets will turn up exploits, but if you report them on any of the platforms a majority are instantly marked duplicate. It's so overloaded that companies are shutting down their programs from the volume of reports.
Anthropic is arguing for formal verification [0]. This is an excellent idea on the edge of feasibility, but it's hard to see how this can work for the majority of software that has to adapt rapidly and are so open ended that it's difficult to even conceptualize all the input modes. It's an easy prediction that we will see verification on large trunks of fundamental software in the next few years, and a sub-verification confidence scheme for the software on top of it.
[0] https://www.anthropic.com/research/formal-verification
There's also a new startup[0] that came out recently from stealth with mission to auto formally verify all of open source in Lean.
[0] https://andtruth.com/the-proof/
personally have started going the other way: AI-assisted microkernels, and only the programming that is actually needed for the problem at hand
my webserver never needed a million lines of code just to pass bytes to other people
Do you have an example in public? Or are you interested in sharing more here? Very curious about this.
currently following some other posts made here on HN with a similar goal; inspired honestly by that mini-firmware project a few days ago
nothing i'm proud enough to open to the world yet, but my personal public server will be my first deployment, and will definitely "Show HN" then too :)
In my opinion, the whole paradigm how we use computers needs to be replaced. It is like the 80s, but now with internet and a thread larger then anything in computer history before. I remember boot sector viruses and stuff.
My approach is https://tix.im/ - not launched yet. But from expedience: modeling everything as workflows of composeable nix flakes (expert systems from programs, skills, agents, workflows and their snippets, DBs blobs, service descriptions, ...) and then run everything in highly isolated environments. It is not only so much more efficient, reduces errors, increases quality, reduces unnecessary cognitive load, ...
I start to move more and more daily tasks into the systems. Even UI programs become interactive workflow steps, which allow me to attach from anywhere back to a task in an environment optimized for the task.
Dependency updates for example, a workflow. A subgraph from a security scanner expert checks each change in the dependency tree.
I don't mean to be that guy, but your website feels inscrutable to me. I know that a lot of that might be because it's written by an LLM, but the page seems like it's full of private language and is the product of a deep context conversation with your agent that I don't have enough context to understand.
Yeah. The concept is quite large and hard to understand - beeing the inventor does not make me the best explainer of the system, and english is not my native language. People grasp it more in a personal conversation and seeing it in action.
tix.im combines conecepts of expert systems with LLMs and other AI systems. Everything is composable via nix flakes. Any change is modeled via workflows that run in isolation. Each step type, is composed from the nix flakes defined and installed in the environment. Not only the projects nix flake (devshell), but also the tix project enabled experts. vx-maintainer is my software development expert - does only know about conecept of software development. Each workflow implemented is steps and workflows. For example, each change lands via land-feature workflow, it has ~40 steps. Workflows have complex parameters that define the flow inside the workflow DAG. In this case, rebase is mechanical, if it fails, medium smart rebase fixer is spawned, then mechanical step checks if all commits arrive in the rebase. Then it builds a collections, spawn a review swarm, open-code-review, etc... everything is tracked in an own issue tracking system and workflows can be restarted with minimal overhead.
Then I have an optimized queue-manager, an own agent prompt with an goal that can never be fulfilled. He manages that items from the tracker get done and land, extra workflows mechanically later check the landing.
rust expert, knows about rust specifics, has snippets, agents, skills etc. security expert has workflows with red-teaming, cyber models that get registered at the internal LLM gateway for usage, ...
I start to model everything in my daily live as an expert system now, with workflows that can be used by other expert flakes.
Workflow steps can be shared and also run wayland and x11 apps, rmux multiuser sessions etc. So, my goal is to move most of my tasks into some specialized environment.
And this is just a small part of the architecture - it is fully decentralized and user owned.
>In my opinion, the whole paradigm how we use computers needs to be replaced.
>But from expedience: modeling everything as workflows
No thanks. I like private computing. I like all the fun stuff you can do with Computers. I'll never want agent based computers.
you can build workflows without agents. Giving them highly isolated environments where they can't break stuff and having human gates where it makes sense - game changer. And you can use local LLMs - stata is awesome. I have a strata tix flake, I start it, it registers the model locally, and it becomes useable everywhere.
I dont want LLMs in my devices.
It's my strong opinion that the problem isn't a language or application problem, but rather an OS design flaw. Relying on ambient authority was fine back in the days of stand alone systems with a few users and no networks.
It's insane that we haven't yet migrated to capabilities based Operating Systems with default deny instead of default permit.
Maybe this will be the push to get us over the hump?
I'm personally not sharing the connotations of negativity towards software development and the term technical debt. I keep reading implications that most of this has always been in some way preventable, but it really is not that simple. How did nobody find these types of exploits 40 years ago? Why are we suddenly shocked and blame the field for this? I think the majority of people severely underestimate the complexity and seriousness of software. Once that perception stops and the economic incentives are right, we can start to look closer.
Just consider how laughable some working conditions in software are and then come to realize how architecture is shaped by the organization communication patterns and not reality. You will see it in a different light then.
Would your last statement be Conway’s Law?
https://en.wikipedia.org/wiki/Conway%27s_law
> Just consider how laughable some working conditions in software are and then come to realize how architecture is shaped by the organization communication patterns and not reality.
I've never considered this problem from this perspective, but damn, I think you're dead on.
That's so true. Nobody gave a damn about those bugs because they were too hard to exploit, and companies had a mindset of "move fast and break things." Bugs were given low priority, and developers had no time to fix them since they were buried in higher-priority feature work as part of a cost-optimization effort. Almost all of the smart people who could actually exploit them were afraid of criminal charges. Now, lots of script kiddies are having fun with AI, and state-sponsored actors in different countries are using it to accelerate the discovery and exploitation of vulnerabilities. But instead of extending validation campaigns and allocating larger budgets for hiring and funding security audits, software vendors are mostly trying to lobby for limitations on models' capabilities and regulation of the field, like Amazon reportedly did[1], despite even OpenAI and Anthropic offering subsidized[2,3] access to their frontier cybersecurity models, which are significantly better than those malicious actors have.
[1] https://www.theverge.com/ai-artificial-intelligence/949601/a...
[2] https://openai.com/index/coordinated-disclosure-of-critical-... - "To help more defenders use these capabilities, we’ve committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, focused on organizations with limited security resources protecting essential services."
[3] https://www.anthropic.com/glasswing - "Anthropic is committing up to $100M in usage credits for Mythos Preview across these efforts, as well as $4M in direct donations to open-source security organizations."
i dislike the term "technical debt." we don't know the trade offs someone made while building a system. often times, it's too few people to do the perfect job, so we decide to do the best we can over the whole solution. for instance, we could all probably do a better job with accessibility, but often times we can't afford the time with stakeholders wanting other things. i don't see it as "debt" but more as the typical trade offs we have make when prioritizing work.
i hope we get to a place where we keep the same number of developers employed as today, but leverage ai to make all software better across the board. hopefully the people in power realize that we've been understaffed this whole time.
I sometimes hear "We have so much technical debt! We're using Mongo when we really should be using Postgres for this data structure."
Not technical debt, just a preference for doing things a different way (which admittedly might be a better way, but just because there's a better way doesn't mean the current way is bad)
Sure it's debt if the choice to use mongo causes the bad decision to seep out into other parts of the codebase.
We have static software analysis tools today, they help find a lot of issues but are not infallible. Given how sophisticated new AI coding platforms are, I imagine in the near-term, we'll have radically more advanced code analysis tools that will close the majority of the security issues that slip past current generation static analysis tools. Will there be zero bugs, likely no but the attack surface is going to get smaller and smaller.
This is actually good, because it ensures that software is strong and secure, especially in a rapidly changing digital landscape.
AI is capable of finding bugs and security flaws that most engineers can't, but it also creates code full of tech debt and vulnerabilities when let loose. AI is great for code reviews (of human written code) and small fixes/patches on established codebases with good practices that were built entirely by humans. Unfortunately big part of the software industry is doing the opposite: having humans review AI-generated code, and having humans work on top of unreliable PoCs built by AI.
I'm reading some takes in the comments that I'm not so sure about. We seem to be taking for granted that we can fix all the bugs and security problems of our software, and then everything will be fine. But is that really the case? Do we know if it is even possible for a non trivial software to be fully secure? Or will there always exist a way to break it, no matter how much we fix it?
Formal verification (https://en.wikipedia.org/wiki/Formal_verification) can be used to prove the correctness of computer software, and eventually most critical software will slowly move towards being formally verified. That however means that we need to get better at creating the specs for how software _should_ operate, so we can actually test that.
With no apologies to esr:
With enough tokens, all bugs are shallow.
I think this is great. Reminds me of Y2K. I remember sometime around 1993 having a discussion with my boss why we store dates on our mainframe as YYMMDD instead of YYYYMMDD since we are approaching year 2000. He ignored the issue totally. I left the company but people told me later that in 1999 they suddenly started a huge effort to change the date format. Same with all the technical debt. It got ignored for a long time but finally we are forced to address it.
There is a saying: no decision before its time. Management is making the decision to defer action until it is no longer a decision but a necessity. It's dumb MBA thinking, but I can probably guess the company you worked for is still around after Y2K and that they made a boat-load of money selling the new features instead of not selling new features and fixing the problem.
I think what's fascinating is that the mentality of "It's too painful to attack" as a security strategy isn't working anymore in the era of AI. A lot of open issues and bugs were kept because folks assumed as long as they were less vulnerable than other folks they would be fine. However I think that paradigm is being phased out since AI can take the pain of sifting through decades of old code for us to find these vulnerabilities.
You could just as easily headline this as:
AI is enabling us to fix longstanding software security issues that nobody had the time, skill, or desire to find
All a matter of perspective, I suppose.
> that nobody had the time, skill, or desire to find
They've always had the first two to varying degrees - it's the desire that killed most motivation.
Time and desire are derivatives of money. Skill, too, largely, though less directly.
Should be something like:
> nobody is paying to find and fix
AI lowers the cost, but certainly doesn't eliminate it. I think we can hope significantly more technical debt will be paid off, but don't expect too much.
Two things are true here. Our decades of rapid-release mentality is now fuel for vulns. Those chosen mistakes we decided can live in the code have directly created holes in the Swiss cheese model. The headline eloquently stated this fact. However the scary part is the inhuman speed of chaining. This is a much bigger problem. The holes in our Swiss cheese now take hours to find instead of weeks.
If it forces us to fix bugs and discover backdoor, I'd say it is a tremendous "win", as the modern PM likes to say.
> As far as anyone is aware, disaster has been averted: The hack was discovered by cybersecurity researchers who reported it to the PHP Foundation, and a patch was released before any bad actors got their hands on the exploit.
Aren't there still vulnerable services right now being hacked?
Better sooner than later, to be honest.
The amount of e-mails I get of the form "Important information regarding your xxxxx account" (which essentially is just code for "we've been hacked and your data has been stolen") is quite concerning, but not surprising. Security by obscurity was always big in most companies, as long as the bar to carrying out sophisticated attacks was putting a costly IT professional to the task you could be relatively relaxed as no one would bother to hack your stupid little e-shop, but now carrying out such an attack costs a few cents to a few dollars at most, that changes the game entirely and everyone is a target.
This summer I had my Docker registry poisoned with malware artefacts, which again is something that no sane attacker would do before as it required downloading my images, carefully modifying them and then overwriting them, ensuring they work as before. Now it's just a simple prompt away. I am definitely ramping up my defenses, everything that doesn't need to be Internet connected goes behind double VPN and port knocking schemes, essentially making my infrastructure invisible from the outside, all unknown packet types get hard dropped, end-to-end encryption of all internal traffic, web endpoints behind CDN proxies and WAF providers (as much as I hate doing that), double and tripe security mechanisms everywhere, maximum restriction of privileges, ultrafast automated patching and AI based continuous monitoring, audits and interventions. You should also get used to that, this will surely still get much worse as attacker tooling gets better.
Your solution has crossed my mind as well with recent attacks. Default Deny with restricted access paths whenever possible. Generally just doing things meant to be raising the bar for agents to get enough access so they can probe systems. Which unfortunately just sounds like leading us down a path of modernizing Security by Obscurity.
Internet facing devs will continue to have their constant war between defenders and attackers. Still a great deal of IOT stuff that has been connected under the need to "phone home" probably is going to be getting examined more closely. Companies who didn't think about security impacts are now getting forced to face why they needed their appliances connected to the Wi-Fi.
Good. It's about time.
I hope the effects of AI result in a massive reduction of PHP and Python prevalence.
And that's the biggest win with AI. With old-fashioned development, it was considered acceptable to defer addressing valid feedback ad infinitum, hiding behind whatever lousy excuse you could come up with. No more.
No software of normal complexity can be "provable".
"pay off technical debt", haha
What do you think the chance of nonzero budget and time being allocated for this is, given that almost no company has seen real consequences to the business?
This is the same cycle we always go through: big spending on a new wave of tech, something breaks it, and spending shifts to the ones doing the cleanup in the years after as the funding moves to the other side. Y2K created huge growth to the cleanup firms overseas. Y2K didn't break, but it had a clear macro deadline. More recently, cloud cost shock and cyber/ransomware accelerated FinOps and further grew zero-trust security industries respectively. But in the current case, we are waiting for the macro break to happen because AI-found bugs are not creating a visible deadline. And until that happens the spend at the front of the wave won't move to the other side of the wave.
Tiny nitpick: on the pricing page the "Unlimited guests" is mentioned twice in the Free forever plan (under usage and limits)
I’m wishful that AI auditing will make bad software effectively negligence from a legal perspective (I know I used the term “wishful” on purpose).
"Disaster has been averted"
Yeah, hmm a lot of people don't actually auto update their PHP so.. it's not like the vulnerability disappeared from the wild.
I wonder if new technology debt could fall on the lack of literacy.
Isn't it obvious that developers should use AI the same way the hackers do - tell the AI to look for exploits?
AI is finally allowing us to pay off 40 years of technical debt!
Don't worry, AI is generating plenty of brand new technical debt too.
We've patched more bugs and more vulnerabilities in the last 3 months than entire years at my last job.
I fear it's only going to get worse.
Worse?
Does it feel like you are happier with your codebase as a result?
Better you mean? Or are you saying you prefer having unfixed bugs?
Worse as in having to stay up late patching more bugs.
That's a weird way to say creating 40 years of technical debt per year.
The most pessimistic interpretation is that AI is superhumanly good at exposing technical debt and not that good at avoiding it.
We'd be replacing decades of technical debt with debt we'd have no hope of paying.
Yep, the takeaway from this should be that we move to leaner applications that can be actually be formally verified. But what I imagine will actually happen is that we'll patch over these vulns with AI that produces 10x the amount of code, just for the next generation of AI to find vulns in that so we can patch that with more code, repeat ad infinitum.
Everyone’s levered to the tits in tech debt.
Now the interest rate is going up.
And you know how are those technical debts created in the first place? More than 40 years of negligence in IT infrastructure.
What does that mean exactly?
For my part, I have my pet neglects based on observing the parade of hacks: private companies neglecting to fund open source projects upon which they rely; private companies neglecting to fund product security staffing and remediation sufficiently.
So the technical debt in the article is about companies not giving enough money to open source projects?
I'm sure the NSA has an eye on the groups that are asking AI about security issues in various popular softwares ...
Its really the opposite, technical debt isn't bugs, technical debt is if you get AI to generate an application and have barely any understanding of how it works. AI without understanding creates infinite technical debt.
That’s legacy code, not technical debt. BTW. If you leave the company, who will understand your code though? Institutional knowledge always fades away eventually.
Technical debt is something that hinders the ability to understand the code and how changes will impact the code. A hypothetical technical debt-free piece of legacy code could be picked up by a new developer and they'd understand it perfectly after reading it.
I haven’t seen such high quality, ever, in a production codebase.
Technical debt, as a term, predates AI code generation by at least 30 years. During the last thirty years, when people used this term, security vulnerabilities were definitely in their minds.
I'm not saying the term applies directly to AI, I'm saying AI can create technical debt, you could do the same in the past by outsourcing work with no expertise in-house
These threads with doom and gloom about the modern internet seem full of people who either never experienced or forgot what it was like at the beginning of the century. Back when the internet was fair game to anyone who kinda understood it.
Back then, you could log in as admin to any phpBB forum by copying a generic admin cookie from a shady web site. You could often then also compromise the hosting company that was running the forum, because nothing was really separated.
You would try to trick your friends into installing Sub7 so you could open their CD drive.
You could easily capture other people's data on public wifi networks in restaurants and hotels.
You could change the price of the pizza you were ordering through devtools in your browser.
You could infect half the world by emailing a picture of a blonde tennis player.
Sure, there have been quite a lot of pretty serious zero days recently. But many of them have been pretty hard to actually abuse, in part thanks to all these layers we've added over time. So I guess I'm not as pessimistic as many of you are. Especially because we all seem to be incredibly aware of what's happening and are acting on it.
I remember stuff like getting an email from a colleague: "Run this exe to get a free CD holder". Innocent times...
Implementation of early PayPal was horrific. You would insert a piece of JavaScript which held the price of the item with the PayPal iframe.
The hack was simple enough that you could change the price in the HTML and it could be purchased for that amount. You were suppose to implement verification yourself on checkout but no one did.
Yeah... sorry but that's not a technical problem, that's a business problem.
Everybody wants a $1 Website, avoid security updates, pay nothing for maintenance, and done yesterday.
It has nothing to do with AI or a specific language or stack. As long as cost cutting will be the culture, driven by the economical model of competition, then we will accumulate technical debt BECAUSE it is the strategy.
I was down voted a lot months ago for saying that a lot of open source software had a false sense of being secure with the assumption that someone else would have audited the code. And this AI auditing is going to make the promise of open source software getting audited by others actually real. Nice to see others waking up to this reality.
We were getting routine audits from security companies as well as public universities around the world on our OSS healthcare project. I would say it did give us in some way a false sense of security as we had the belief that a lot of the major bugs were addressed. The last 6 months have been very eye opening as the slew of reports have been difficult due to how many there have been, even with all of the false positives there's been a lot of legitimate vulnerabilities. This has been taxing for us to go through (and humbling as well).
That said, if we were a closed source project, I don't know that our own tooling would have discovered all the issues using LLMs as we are seeing more and more creative ways of people exposing exploits that I never would have thought to put into the LLM prompts.
But would they be able to find those obscure exploits if they had no idea what your code looks like?
If all you had was an API endpoint, you wouldn’t realistically have any way of figuring out how the internals work and finding obscure exploits.
I always found Linus' Law -- note, coined by ESR, not Linus -- quite... uh... shallow. It seems trivially obvious but is subtly misleading because it makes a quantitative argument ("enough eyeballs") without addressing the qualitative aspect, i.e. whose eyeballs they are matters more than anything.
A 1000 of us regular devs scanning a piece of code is not as effective as a single review by, say, Tavis Ormandy. So "enough eyeballs" is only "enough" when one of those set happens to belong to a Tavis O. or the likes.
Not to mention, this assumes a 1000 of us even look at the code, which is statistically never true. Approximately 100% of us just install the software without looking at a single line of code. Hence the code auditability aspect of open-source software never really applied. And hence, "supply chain attacks."
Unfortunately, this misguided "law" was taken as gospel by many, and as you found out, still is.
If making things in the open was more secure, everyone would post their tank designs online.
Instead they court martial anyone who talks about the designs. Because obviously, telling everyone every aspect of your security isn’t actually more secure. How would you know how to do a 24-step process to exploit something if you have no idea what code is running on their server?
Imagine trying to build a cheat for CS:GO if you had no access to the game and could only play it via a remote connection. Good luck.
As much as people rail against it, security through obscurity is actually a valid defence.
There was always, in my mind at least, a tension with Linus's Law ("given enough eyeballs, all bugs are shallow").
It's true but the problem is assuming, just because something is open source, it has received sufficient eyeballs. AI now gives us near unlimited eyeballs so, if we survive the bumpy transition, open source should indeed become very secure compared to closed source.
> AI now gives us near unlimited eyeballs
Except we won't get the expected benefit, because all those eyeballs are attached to a very small number of different "brains" (LLM models.)
The original saying depends on an implicit assumption that eyeballs are proportional to minds, and that among those varied independent scans, different people will catch what others miss.
In other words, we shouldn't assume 5.5x review thoroughness when we hire 11 QA eyeballs but they all belong to Bobby the Beholder.
>and that among those varied independent scans, different people will catch what others miss.
My point was more that very few brains were looking deeply at the long tail of open source code/projects (other than the maintainers of the code themselves); and for the marquee projects that did get proportionally more varied eyeballs (e.g. postgres), it seems even that level of attention was insufficient for code deep inside the project's core.
LLMs change this. They make it much easier for maintainers and motivated users to amplify the power of their eyeballs.
> open source should indeed become very secure compared to closed source
I don't understand how you get to that conclusion.
Do you think that an open source project will receive more AI eyeballs than a closed source project?
The token budgets will be extremely unevenly distributed in scanning open source.
Linux kernel will get an insane amount of tokens burned on analyzing it. Most other open source, not so much.
I was thinking about this too, and think it will come down to incentives for attackers and defenders.
Assuming offensive and defensive capabilities are similar, and incentives scale roughly with project size but start from a non-zero value for attackers, I'd expect larger open projects to be well defended by plenty of motivated people, and smaller ones less so (depending on maintainers). Closed source will mostly just depend on maintainers.
Also assuming closed source is less exposed to AI auditing overall, I'd guess large open projects end up more secure than large closed projects, but small open projects possibly less secure than small closed projects, since attackers might have more incentive to target them than defenders do to audit them.
Attackers are always far better resourced. You get six billion if you hack a crypto exchange, you get PIP if you spend time fixing bugs rather than pushing new features.
I doubt this seriously. You're as vulnerable as your worst piece of software.
I'd lean more towards systems that only install diamond-hardened software at all - once you have one project in a class of software that has been analyzed to death, that's the one everybody is going to use.
The vast majority of the development of all projects is going to be (already is) LLM-assisted, so they're going to get analyzed every time they're touched. The odds that huge bugs are going to be lying everywhere to be exploited are bad imo.
I'm starting to rewrite an open source project just because I don't want it to be buggy anymore. I barely want to change anything about it (especially not the licensing.) All I'm doing is porting it to rust from c++ and refactoring it like crazy. I just want to make it easy to audit and extend, and hard to crash, that's it. Once I'm done, I'm already have another (buggy) project in mind to do the exact same thing to. Great UIs and usability, just thwarted by the time that the developers had to invest in them. You could think of them as almost purely security-oriented rewrites.
>Do you think that an open source project will receive more AI eyeballs than a closed source project?
Net net, yes.
I think the argument was that it was more secure than the closed-source equivalent.
I think the game theory of relying on open source infrastructure is more complicated and ambiguous than most people have considered.
Using open source source software lets you share responsibility and oversight with a large number of people. But it brings with it a much larger attack surface than you'd have if you only implemented the part of that software that you need, and a much more complicated threat model for supply chain risk.
If a large number of people collaborate on open source software for something, especially if it's security or infrastructure related, that makes the project itself a much higher value target than any individual company's home grown mail server or http proxy client would be. Participation makes your vulnerabilities more public, since interacting with the public open source project, making blog posts or hiring ads mentioning it, hosting it (and thus serving traffic in a way that signals or directly tells clients what implementation it's using), bundling it with your site or binaries, etc. tells prospective hackers 1. how to find potential exploit targets for a general open source vulnerability 2. where to look for or introduce vulnerabilities to pwn a particular target.
AI auditing isn't really a silver bullet because it costs a non-trivial amount of money for each commit or PR, and scales with the number of contributors to a project and the project's size. Normally you want more of those with a software project, but in this case it makes AI auditing more expensive unless it's shared across the project and basically part of its CICD (and I don't think that's really been fully adopted yet). But then that introduces other risks like adversarial payloads where the attacker verifies that the AI security checks in place for a project don't trip when they actually send the malicious code for review, because they can run the same checks offline and tweak the payload until it passes.
Personally I think we're headed toward an outcome where only very challenging, well-resourced, and critical open source software is worth using for developers. For smaller things it makes more sense to just use AI to implement your own version of it, or fork/take inspiration from a project and mold it to fit your needs.
Now think of the advantage for intelligence services having that framing in the public mindshare. Probably all sorts of vulnerabilities in open source tooling these communities depend upon. Probably whole campaigns out there to stifle awareness of them as well and preserve the easy already found golden goose as long as possible, as well as campaigns to advertise and entrench the backdoored tools. I wonder how much collusion like this is out there? We won’t find out for 40 years in either case whenever this stuff is FOIA’ed if it even can be.
Perhaps it will also challenge the assumption that open source is something you can run a billion dollar business on without re-investing a penny.
> ... a lot of open source software had a false sense of being secure with the assumption that someone else would have audited the code ...
I agree on this part, but what's your point here? Are you suggesting closed source is better?
I don't think they're suggesting that, rather that the "more eyeballs" quote is a bit flawed (in that not every project gets enough eyeballs). A thing can still be better then another thing and not be perfect.
I don't agree that it was an assumption as part of open source, but that it was a possibility with open source. However, there are lots of assumptions made about computer software in general - part of the problem is having cognitive models of software that aren't necessarily reflected in how the hardware runs code.
Also, closed source software can similarly be analysed with AI, but there's no guarantee that the company involved will deal responsibly with disclosures.
a lot of open source software had a false sense of being secure with the assumption that someone else would have audited the code
Do you have examples of people saying this? I don't think I've come across idea being espoused...
I've certainly seen people interpret Linus's law to mean this. (https://en.wikipedia.org/wiki/Linus's_law).
I do not have an example for this, but the most ridiculous argument for open source software (at lease for most people) has always been that if the software has a bug you could simply fix it yourself. Funny enough this has actually become kind of true with new LLMs.
Did you not fix bugs in the oss you run, pre-LLM? Or not bugs, just your own changes? Being able to just grab the source and tweak it without needing to try to RE or wait around or convince the owners/developers to do something I wanted to happen was one of the biggest selling points.
Most people did not do this, no. Or even if you did, upstreaming the patch was even more uncommon.
Yeah but AI also helps in lowering the debt ...
luckily it will help us paying it off too
I can't help but feel a lack of investment in new product and feature work.
Instead we're spending the time churning out busy work fixing bugs that were too low value to care about a year ago. We have a new street lamp so we're working on anything it illuminates.
I haven't really seen the same kind of push towards verifiable software. It's mostly around solutions that will perpetually burn tokens and justify usage of the new toys.
Mine is a cynical take for sure but I honestly really miss meaningful feature work but that's not what the market's interested in right now, I guess
Actual title: The PHP2Shell Vulnerability Heralds Cybersecurity Hell
And PHP is developed by humans, at least it used to be. No idea about now. Now imagine the security landscape when all code is generated. AI will find dozens more vulnerabilities in the code that only robots are responsible for. If the bubble doesn't pop soon, it's going to be a nightmare in a year or less. Hackers win, everybody loses.
While we're at it, I'd appreciate easy secure authentication of a device without having to pull in a third party authentication provider. Thanks.
The real slop was the human slop we made along the way.
> PHP, which originally stood for “personal home page,” is a programming language created back in 1994 and largely used by legacy sites [...]
... "by legacy sites"? :O
That's a pretty spectacular mischaracterisation of PHP's place on the web.
<cough> Wordpress <cough>....
Another way to look at it is that companies who have let their software development teams go while keeping their software alive are bound to face a reckoning, as AI will inevitably expose their skeletons.
And generating another 40 years of technical debt in the process.
It's not technical debt. It's lack of engineering rigor.
Bridges don't get driven on until they're inspected. And they only pass inspection if they were built according to standards, and meet design specifications that have to take safety into account.
How we get there, how we enforce it, is another conversation. The point is that we have to start getting serious and be real engineers. The bare minimum standard should be that you can drive a truck over it without worry. How much software can you confidently say that about?
Considering I've been using open source software without issues for around twenty years. I would say confidently around 90%.
It's only been the latest years where software has had a hard crash in quality.
The framing of using PHP as a legacy technology is the greatest sin of this article and they can't be freed of it.
I'm not a PHP person, but so much of the world actively runs on it silently.
All technologies have gaps. PHP was affected differently not because it's old, but because it's so ubiquitous. Python is as old, so is Javascript, and many others.
And this is only the beginning
and creating 40 years more
At least it can potentially help close the bugs too at scale.
Maybe now developers will stop fighting tooth and nail to not update libraries and programming language runtimes and so on.
At my current day job, if I mention “hey, how about you update PHP to at least a supported version” people start whining about how that takes a lot of time and if really anyone would try to attack our public facing services written in… PHP.
Next time we get hit I can sit back, eat some popcorn and say “told ya’”.
It also inflated almost all of that debt away, though. So in a way people who built "just ship it" buggy things in the last few years, made the right bet.
I think we'll look back at this moment as peak C/C++ before they begin a long, slow decline into irrelevance.
I've been bullish on Rust for years because memory safety is simply too important and Rust can essentially prove an implementation correct and solve a certain class of very important bugs. It doesn't solve every problem and there is a complexity cost.
I've also said that writing multithreaded code is simply too complex. In an era of out-of-order execution, different levels of caching, asymmetric cores, hyperthreading (although this is largely dead now?), branch prediction and having to support multiple architectures it's simply too hard for most people to write correct multithreaded code. Period. If you find yourself as a non-library developer creating a mutex or spawning a thread, somebody has screwed up.
This is also why I think the single-threaded async/await model with post-request teardown of PHP is the correct choice for most people.
We're going to go through a dark period of a lot of 0days. As the article notes, this is paying 40 years of technical debt. It will result in a more secure ecosystem however. I believe this will ultimately also hamper black markets, governments and 3 letter agencies who trade in those 0days.
As painful as this all is, it will ultimately be a good thing, one of the few to come out of AI (IMHO).
Spawning a thread can be pretty safe, if there's no mutable shared state.
I'm not going to lie, I'm having a great time thinking at the endless discussions around unsafe languages and the relentless smugness of many practitioners claiming everything was fine as long as the responsible and the skilled (them) were in charge; and let's not forget the formulaic "with great power comes great responsibility" closers.
Well now, Great Responsibles, it's clear you too were out of your collective depth and were all paying for your smug hubris. Perhaps take a bite out of that humble pie you've obviously never tasted?
Well, the title is a bit strange. People are poking fun at PHP, I do too - but ... if PHP were totally useless, nothing would be affected as nobody would use it. But many servers use PHP and there is good software written in PHP too. I know that because when servers were patched, and taken down, a lot of stuff suddenly no longer worked. That included universities as well as some other websites. So I think the term "technical debt" is strange. PHP is written in C. Would PHP be better if written in Rust? That's not so easy to answer, but all things being equal, it may be that PHP would have fewer issues if it would have been written in Rust.
I think one should, of course, be critical of those who write C code for PHP, but at the end of the day, some part of that criticism also goes to C. C is both a king and a problem. And it seems very hard to fix the problems of C.
This is like a godsent! I have been secretly wishing for everyone to take a few months, stop developing new pointless and mostly enshittifying changes, and just work on fixing current issues. I wasn't thinking so much about security, but rather old and rather well known long term bugs. If AI is finally forcing us to deal with long term issues, all the better. If we happen to end up fixing a bunch of 0-days some people were secretly sitting on, go go go!
> PHP, which originally stood for “personal home page,” is a programming language created back in 1994 and largely used by legacy sites.
Wow. Love it or hate it, but tell me you have no idea what PHP's place in the web ecosystem is without telling me you have no idea what PHP's place in the web ecosystem is.
Of course no vulnerability has ever been found by a human or by fuzzing.
AI does find things, but it is a small percentage the overall vulnerabilities.
IEEE is of course and industry owned organization that shills for BigAI, NSA and any other entity with money or influence.
You're joking right? I work on a place public software product and over its ~15 year life we've gotten over half of validated vulnerability reports that we have ever had on it within the last year. We basically had to stop feature development for 6 months to burn that down, even with AI providing correct fixes for 80% of the vulnerabilities that were reported.
> Of course no vulnerability has ever been found by a human or by fuzzing.
Who do you shill for? because that sounds like someone who want to fuel the flamewar.
Why are there so many accounts on HN that only post one-liners?
These are happy macOS and Windows users that mastered Cloudflare OS.
It has the same answer to why your account was recently registered 2 hours ago has a username with a random mash of characters; bots are the reason.
Why are we even discussing this article? Do you know who Dina Genkina is and what are her contributions to the field?