As we move forward it will be easier than ever to just maintain and keep your fork of software with the changes you want or need. No more approval, bureaucracy, or arguing. Just tell the AI agent want you want changed and you have it.
This will be used for huge things too. Like maybe you want a specific fork of Java that only supports for each iterators, goodby linters, hello compile time error.
Software as a list of requirements and that's it. The local LLM appliance everybody has taking in a document specifying hardware, interfaces, and requirements and spitting out software changeable locally via conversation with its users.
In the same way you have a cookbook with recipes to make dinner instead of ordering out.
For that, you'd want the list of requirements and hardware documentation to be written in a precise, formal language. That's no different than writing them in a programming language (though a declarative one, instead of the more common imperative ones).
I've in the past (way before LLMs existed) thought about automatically generating device drivers from hardware documentation. But besides the need for very precise documentation, hardware never works exactly as documented; a human-written device driver can avoid problematic areas (perhaps even by accident), while a computer-written device driver would end up exploiting every corner case of the documentation.
There is quite a bit of distance between the exactness of any human language and an sort of programming languages. When you have a language model loaded with software engineering best practices you do not need the exactness of a programming language to describe desired behavior.
Hardware documentation is indeed often lacking in plenty of ways but in a world where writing your own software through agents is commonplace, the hardware manufacturers (or the community) would make testing that documentation to find the problems an important part of hardware development.
I don't imagine this is practical or desirable for all situations. Good software is built from being battle tested by many users in many environments. Even with the advancements in AI tools, I don't imagine they'll become omnipotent anytime soon.
> No more approval, bureaucracy, or arguing
For software that can kill people or substantively affect someone’s life in a negative way, the bureaucracy is there for good reason. I don't think anyone should want someone at Phillips to vibe code the control software for an X-Ray machine or an employee at CrowdStrike vibe coding the next update before pushing it out to millions of machines.
We are forced to endure low-quality software because there is little or no accountability. I can only imagine what you propose would make an already poor situation worse.
Then you'll have the same problem everyone who forks a piece of software ends up having, sooner or later: as the original evolves, keeping your fork up to date with the upstream changes becomes harder and harder. The bigger and more invasive the changes are, the harder synchronizing with newer releases become.
Can't picture a functioning world where every piece of software is custom and requires factorial amount of AI comparisons and reviews to patch the API to communicate. In fact, it's impossible! There's not enough compute to handle a factorial explosion.
I really doubt SaaS going anywhere.
The cherry on top is that OpenAI and Anthropic brainwashed your coworkers and your company's C-suite into uploading the entirety of the "proprietary" codebase onto their servers thousands of times per day over the last three years.
Even SaaS isn't safe. I don't even have to describe your product to my system, I just have to give it a harness with access to the interface and have it replicate it locally. Frankly you can probably already prompt for that.
The only thing holding this future back right now are pricing problems and code generation quality. Both of those barriers are constantly being knocked down. We might never arrive at that future, but it's definitely a higher probability than solving AGI's scaling issues, and would arrive much sooner for technical users.
https://www.youtube.com/watch?v=V_qzqY1bb7I your sufficiently advanced code generator may generate you a high quality database system for some measure of quality, but it will not have SQLite's reliability over the extremely long tail of edge cases proven through its testing and use in real life
That's before we get into the entire non-linearity of agentic systems introducing massive decidability problems on this in the first place. A little bit of epistemic humility please.
Because SQLite has 10k requirements that wouldn't even cross your mind to write down, but 80% of which are useful to you.
This isn't anything new or particularly interesting. It's the entire basis upon which ILP demonstrated generality. A metatheory to synthesize 10 trillion rules isn't even scratching the surface of what you can reasonably do. The key was finding out the tractable semantics for actually computing it in reasonable amount of time, which right now is looking decidedly like informal semantics was the answer the whole time.
The assumption you make is the classic LLM mistake of thinking writing code === building software.
To cite your example SQL has had its tires kicked a lot it’s seen things you can’t even imagine thanks to being used millions of times by millions of people. It’s hard to just replicate all that iteration, learning, mastery, and process. If you reinvent it, users will encounter the dumbest bugs over and over and over. Sure you’ll fix them, but you’re now embarking on this big thing that SQL and others already did.
If you love the problem space definitely do it - go full steam ahead - especially if you’re actually innovating and doing things better, but don’t be fooled into thinking anyone can, or should with every side project.
The new struggle is focus, what not to build, I almost have the purely opposite view of instead of using LLMs for grandiosity, only using the LLM for tedium and making sure it doesn’t do anything too much that I haven’t planned for or want to do. I drive the thing, so every new project is still my time and energy and focus.
Not quite. I'd agree with you if you try to do code generation in one-shot, but the agentic loop importantly isn't that. Natural testing at-scale is automated as well.
> but don’t be fooled into thinking anyone can, or should with every side project.
You're right, and I hoped I had conveyed that but I guess I didn't. I'm very bearish on whether or not we're democratizing anything. What I do think is we have a very complicated and interesting tool, and within a reasonable precondition of additional scaling and structural innovation, one that promises a certain kind of person the ability to swing with the weight of an entire institution.
I have been playing around with transformers for 7 years now, and can see and qualify the improvements observationally. Innovations like thinking blocks, the agentic loop, the many architectural refinements flourishing, SAEs, steering vectors, harnesses, etc. Despite what it sounds like, I've yet to incorporate LLMs into any of my professional workflows, they're really not quite up to my standards yet. But then, in my industry I would never in a million years touch anything like SQLite either. Those kinds of things are very taboo for anything but like an internet service and that's more the kind of operations drek that gets shoved off to the IT department. All of this colors my perspective. I was never pulling in dependencies. In the future, it's looking like I'll have infinitely less reason to.