Programming with AIs requires new architectural structures designed around the all-too-small context windows of the AIs themselves. Highly modular, highly semantic, highly traceable, good at deleting and refactoring/removing things they no longer need, good at identifying the core truths/principles/designs they need to uphold, good at recognizing what is mere interface from architecture from data.
This is the great orchestrator game. It might be the last game. I dont think it lands precisely in our previous "best practices" though, and I don't think it's trivial to solve for. I also don't think it's going to be a human-centric design. I think we're generally better off rethinking fundamentals and designing from the ground up on this one. I think it's also a lot of fun to start thinking in these new ways.
There will always be programming, just like there will always be oil painters and historians. But this is about to get industrialized into stable emerging factory forms, and there's a lot of ways to design those right now. And after that us artisans will either need to find new unfinished aspects of programming-like design or retire. At least take solace that the rest of the world will basically simultaneously be doing so too.
First, the "all too small context window" reminds me of GetRight, mp3pro and a lot of other artifacts we invented in the 80s and 90s to deal with the limited internet bandwidth of then. We created artifacts to "achieve things" with the limited technology at hand. In 2026, ive got a 500 mbps simetric home connection. The same way, RAGs and all related stuff are artifacts to help us deal with today's tech limitations. In 10 years, it will be a non issue.
Second, I agree on the architectural patterns. Building (commercial) software will become a real Engineering career. Engineers will define the blueprints of the functionality of software, as well as the "materials" (technology, practices to use, measurement limits, ranges, etc) of tge software to be built, the same way Architects and Civil Engineers do when designing a Skyscraper or a bridge to be built.
As you very well put it, there will still be the "artisan" programmer, who builds whatever code by hand. But that will be as a hobby or some personal project.
If you care about architecture and principles, the AI is excellent in architecting around that goal too and/or helping you articulate your own intuitions. You just need to be willing to sacrifice code delivery speed. It's far from an either/or.
I have found different, often even when doing something like coming up with a database schema, the solution it chooses is not the best and and can be even terrible sometimes. It could be I suck at prompting.
Yes but those are all semantic tasks which can be done and understood in time by the next iteration of models training at that meta-level of architectural analysis.
AI deeply understands what Bun, Zig and Rust are, how they work, can conceive of the before and after architecture (probably the hard step here), can conceive of the goal of the rewrite, and can verify (using Lean and machine-checked proofs of the before and after expected states) the final result.
They just needed us to ask. Build a sufficiently general research program that can find and iterate on ideas, and it will do the asking itself.
Sure, maybe step 2 can eventually be replaced by AI. But step 1? Why would the AI even conceive of the idea of doing a rewrite in the first place?
And rewriting is just an example. There are tons of architectural decisions that need to be made every day in the building of advanced software. This is no "correct" way to do it that the AI can know in advance, it's a technical decision to be made by an engineer.
Maybe it sees a bunch of segfaults in the Zig codebase and decides a memory safe language is better, just as the human did in Bun's rewrite. I'm not sure why you think it wouldn't have been able to conceive a rewrite.
Such an AI would be unusable in production because there is no bound on the work that can be created and external side effects that could happen. All projects have real world constraints and side effects, budget, customer requirements, etc. Imagine a non-technical person prompting the AI "make the app faster and fix all the bugs" and the AI autonomously decides to rewrite the whole production app and all its dependencies in Rust that is live and serving thousands of users. Doing a full rewrite would take days to execute, and have all sorts of side effects on the actual users during deployment (even if it was done 100% correctly, work has to be paused, affairs need to be coordinated with real customers, etc.). Even if the AI has that capability (and I do believe it is possible, even with today's models), that's not what a business owner wants. You don't want to use an AI which, if you gave it a 3 word prompt, it could suddenly decide on its own to rewrite your whole entire business. An AI that had that much autonomy could just decide on its own to pivot your whole startup and sell something else. A business owner wouldn't even want to use such an AI which could have such large unbounded side effects.
I feel like leaving it to decide everything would not produce a good end product. It feels like just having it decide how GC should work, how the function call stack should work or any of these rather simple but actually requiring lots of decision and thinking how things fit together (and pick a good solution out of many seemingly good solutions that can come back to bite you), couple this with the tendency for AI agents to tend towards adding new code and building over features I don't think you end up with a good solution.
On formal verification having done it only in an academic sense and looked over at projects like seL4 and quite interested in that project. It feels like actually proving useful properties of programs for real programs even ones with well defined domains and easier to model such as interpreters or compilers it seems that it will just prove theorems about properties that hardly matter or don't even matter at all. See how bad it still tends to be when trying to get it to write tests.
I would be interested to know if their has been an agent that has actually utilized formal methods such as Lean or Coq or Isabella to prove properties of programs in an automated way as you suggest, I have only seen it proving mathematics and or searching for counter examples, not writing Curry-Howard style proofs.
More precisely, a "perfect solution" doesn't exist. It's all tradeoffs given your goals. Someone needs to make the decision: 1. which tradeoffs are worth given your goals 2. which goals are worth defining or redefining. And do that effectively, you need to understand the problem, which goes back to engineering.
This is the great orchestrator game. It might be the last game. I dont think it lands precisely in our previous "best practices" though, and I don't think it's trivial to solve for. I also don't think it's going to be a human-centric design. I think we're generally better off rethinking fundamentals and designing from the ground up on this one. I think it's also a lot of fun to start thinking in these new ways.
There will always be programming, just like there will always be oil painters and historians. But this is about to get industrialized into stable emerging factory forms, and there's a lot of ways to design those right now. And after that us artisans will either need to find new unfinished aspects of programming-like design or retire. At least take solace that the rest of the world will basically simultaneously be doing so too.