The PHP2Shell incident highlights something important: AI is making it easier to discover vulnerabilities, but fixing legacy security issues still requires time, expertise, and resources.
For businesses, this is a reminder that cybersecurity cannot be treated as a one-time task. Regular updates, security audits, and responsible maintenance matter just as much as adopting new technology.
As professional communities become more connected, sharing technical knowledge and learning from security experts will become increasingly valuable. That's also why platforms like Lobox focus on bringing professionals together to exchange knowledge, build connections, and discover relevant communities.
The bigger question is: are organisations investing enough in fixing their existing technical debt before adopting more AI-powered systems?
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.
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.
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.
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.
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. Then there's 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?
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.
Well 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 in 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'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
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.
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.
> "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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
>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
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".
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.
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'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.
> 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.
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 error.
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.
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.
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.
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.
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.
> 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.
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.
>We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people
Another industry is 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.
> CISC instructions take up less space than the equivalent RISC instructions
In theory CISC instructions take les space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
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".
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?
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.
Yup. Another reminder of how far software engineering lags behind other engineering disciplines in rigor and accountability. The chickens are coming home to roost.
>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!"
> 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...).
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
>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.
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.
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.
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 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.
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:
- Secureboot, attestation, encryption of data-in-use, etc.
On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory?
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 "channel" 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.
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.
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.
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.
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.
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…
> 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".
> 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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
> 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).
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".
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.
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.
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.
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
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”
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?
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.
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).
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!
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.
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
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.
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.
Human speech is inherently inefficient and ambiguous. Humans rely on non-verbal clues and context to distill the exact meaning, and even then the potential for miscommunication is still non-neglibigle. It is a huge leap to assume that artificial intelligence can succeed in flawlessly divining intent from regular human speech. 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.
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.
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.
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.
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?
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.
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).
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
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.
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.
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 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 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.
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.
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.
267 comments
[ 0.18 ms ] story [ 49.9 ms ] threadFor businesses, this is a reminder that cybersecurity cannot be treated as a one-time task. Regular updates, security audits, and responsible maintenance matter just as much as adopting new technology.
As professional communities become more connected, sharing technical knowledge and learning from security experts will become increasingly valuable. That's also why platforms like Lobox focus on bringing professionals together to exchange knowledge, build connections, and discover relevant communities.
The bigger question is: are organisations investing enough in fixing their existing technical debt before adopting more AI-powered systems?
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.
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.
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.
" 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
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.
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?
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.
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 in time balloon out of control.
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.
We have way more resources now to achieve way higher standards.
> -- 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.
my webserver never needed a million lines of code just to pass bytes to other people
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.
https://consilien.com/news/what-is-iso-27001#how-do-you-actu...
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.
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.
I fear it's only going to get worse.
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.
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
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."
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.
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.
[0] https://www.bugsink.com/blog/http2shell-timeline/
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.
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
I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".
I rarely call myself an 'engineer', preferring developer or programmer.
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.
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'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.
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 !).
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.
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.
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.
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 error.
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.
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.
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.
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.
https://phprust.com/status/
I’ll keep checking
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!
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.
Another industry is 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.
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.
In theory CISC instructions take les space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
> 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".
(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.
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!"
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...).
2026 is saying "here is the consequence."
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.
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
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.
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.
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.
But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
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.
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
That might be true on the margin, but highly doubt it was ever true once you escape a very shitty local optimum.
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.
And to scale up meant moving all our shit into the cloud and asking devs to take on all the roles that were removed in the move.
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.
>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.
What the heck have you been doing instead of pointing out the obvious?
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.
My guess is aviation or .. defense?
We don’t have billions to throw away on making sure our about-dialog is memory safe.
The real clowns union paradoxically is the least clownish industry one can find.
- 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.
- Secureboot, attestation, encryption of data-in-use, etc.
On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory?
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.
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.
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.
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.
That’s what I started to do 10 months ago.
You want a safer language AND transpilers from PHP, JS, Python etc. into it? Here you go:
https://ulanguage.org
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)
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…
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.
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".
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.
Still, I pray you’re right.
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.
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.
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.
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.
I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.
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.
In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
I'll believe it when I see it.
Otherwise, I completely agree.
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.
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...
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".
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.
How can even call this an "industry"
At least put some formal verification on top of that GenAI pile.
There quality should be there, but it should only ever be “good enough”
We'd be replacing decades of technical debt with debt we'd have no hope of paying.
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).
Also, those very average developers are also the ones doing the code review.
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!
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.
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, 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.
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.
I've never considered this problem from this perspective, but damn, I think you're dead on.
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?
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.
But there are potential upsides like the already mentioned possible nation state exploits (sleeper exploits).
I agree on this part, but what's your point here? Are you suggesting closed source is better?
Can you qualify this? I don't think I've come across idea being espoused...
Also, closed source software can similarly be analysed with AI, but there's no guarantee that the company involved will deal responsibly with disclosures.
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.
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.
Or maybe everything goes closed source and we all spend tons on 'ai defense'.