For over 70 years, software development has been built around the following assumptions:
- Code is the most precious asset produced by developers
- All software must be written in text-based English-imitating “code”
- Coding is a skilled craft, not meant to be understood by users
This led to serious problems that the world accepted as unavoidable until the AI disruption:
- Developers are attached to code, not system design
- Writing mature software is like writing all 7 Harry Potter books twice
- Most software is a black box for users, even with detailed documentation
As developers, we use sophisticated versioning systems, review and QA pipelines, talk about good and bad code, maintain code like heirloom. Legacy code is treated as accumulated wisdom, an expensive and precious commodity that has incredible intrinsic value.
AI shatters all these assumptions.
Writing code has become extremely cheap. The dynamics of software development have been completely flipped on its head. It doesn’t make programmers obsolete, it just exposes that these assumptions were always wrong and we were protecting the wrong thing.
Everyone has backups of backups of their codebases. If you ask a team what would happen if somehow their entire implementation disappears one morning, you’ll hear terms like ‘years of work’, ‘institutional knowledge’, ‘irreplaceable’, ‘edge cases we’ll have to rediscover’. Then if you ask them what they would do if they were told they must replace the old codebase, you’ll hear ‘compare to the old code’, ‘write tests based on the previous version’, ‘copy some pieces from the legacy repo’.
None of these responses are about the actual code itself. They’re about intent — what the system must do, how it should behave, what must not fail, what invariants must always hold, what edge cases should be handled.
Right now, the ‘code’ is doing too many jobs — it’s the specification, the test suite, the documentation, the bug database and more, all at once. Even when these things exist separately, the code informs them rather than the other way around.
This is not unusual, nor is it the team’s fault. This is a result of those assumptions creating an environment where code is at the center of everything.
Historically, code has just been the shortest path to making computer language more accessible. It evolved from Assembly language, FORTRAN and COBOL only to turn into Python, C# and Rust. If you think about it, that’s not a lot of progress considering the timespan and all the progress that has been made on the backs of these languages.
What’s funny is how we teach programming to children — we give them toy programming languages like Scratch that are extremely visual and intuitive, but then they soon realize that the real world uses code that’s anything but visual and intuitive.
AI’s ability to turn natural language into code is a massive rug-pull in this context. Suddenly our computers understand our languages far better than we could ever understand computer languages. That’s an uncomfortable thought.
In a nutshell, all this means that ‘code’ is dead. Soon nobody will ever need to read or write any code manually and we will all rely on AI to do it for us. So let’s take a look at where AI-enabled coding is headed to get a glimpse of the future of programming. Every popular IDE now has an AI chat sidebar slapped on to it, with AI auto-complete and agents running automations. The core IDE has remained unchanged still — code is at the very center of everything.
A typical IDE with AI today looks like this.
Clearly, there’s a problem here.
Typically, software development never starts with code. It starts with software architecture and system design. That’s a process done on whiteboards with sticky notes, diagrams, flow charts, roadmaps and to-do lists. It then evolves into a product requirements document, feature specifications, sprints and tasks. Only then does the implementation begin. As code is written, the team starts to discover edge-cases, bugs, missing features and gaps in the specification. Sometimes they go back and re-think the software architecture, start over and refactor everything.
Systems built for the next decade need Oracles; explicit, durable, single-source-of-truth foundations to judge correctness and evolve the design without referring to the implementation.
These oracles contain:
- Contracts: Precise shapes and obligations at boundaries
- System design: Detailed descriptions of the design concepts and intent
- Behavioural checks: Given this input, check for this output
- Invariants: “Balances never go negative”, “Denominator cannot be zero”
- Live signals: Production metrics that tell you whether reality matches intent
The code is just the output — disposable and regenerable when stale.
The real asset is everything that lets you delete the entire codebase without fear.
That said, not all the layers of the codebase need to regenerate at the same pace. Some pieces will regenerate daily or weekly, changing rapidly as the oracle evolves. Other parts will be conservatively regenerated — public APIs, behavioral promises, interfaces that should change slowly and deliberately with careful judgement. This requires an extremely structured and modular approach to build agile systems with confidence and trust. Prompts that regenerate the implementation cannot be chat threads emulating conversations that nobody will be able to read in six months. Instead they must be explicit commands, scripts for the AI to follow without deviation or question.
The development environment itself must treat architecture, behavioral intent and evaluation as the center of the system, not the code. The oracle must be a first class object that the developers build over time — not as a collection of markdowns in a folder nobody opens, not as a wiki junior developers discover when something breaks, not as a messy Miro board that’ll leave your team lost looking for where to start. You should be able to see clearly how data and events flow, where boundaries are, what must never break, why certain decisions were made — and construct a well structured oracle in detail.
Another critical consideration is how the unit economics of software development are rapidly changing. At this point, every developer has gone through the bell curve of token usage — try out AI generated code with small granny-text prompts, become a token-hogging vibe-coder sending massive logs and codebase contexts in prompts, then finally gain enlightenment by understanding the importance of judicial token economics for sustainable AI use. Still, providing sufficient context to most capable models for complex tasks can prove extremely expensive when the context includes implemented code as-is. Even providing information from the oracle directly could cost a lot of tokens. The solution is compartmentalization and composability. When individual modules are specified in a way that does not require encoded context of any of the systems outside the module, they can be regenerated with very little context. All that’s needed to ensure reliability is a well defined contract and interface.
This is where I’d like to take your attention back to Scratch — that toy visual programming environment used to teach toddlers about computers. Each block, every connection and parameter all have explicit descriptions that are easy enough for a kid to understand. Put together they can be serialized to a very small description of a program that could be doing something fairly complex. The actual code and implementation of the blocks are always hidden from the kid developers, yet they’re able to write programs with them. What we have here is exactly what adult software engineers need today — an interface to develop software by visually describing architecture and behavior without worrying about the implementation.
Decode — the next-gen visual programming environment. Each component contains the AI generated code implementation.
An environment where you compose systems visually — like you would on your whiteboard with diagrams and flow charts — is what next-gen IDEs need to become. Boundaries, flows, evaluations, provenance, contracts and intent authored in a visual graph by a human, code and implementation handled by AI in a modular and efficient manner. Deleting a module is boring because the spec and the oracle survives, the module can be regenerated with the same amount of effort it took to delete it — one click. The reasoning that led to design decisions is all part of the visual graph on a surface above the implementation, not lost in a closed AI chat tab. This is spec-driven design, test-driven design, behavior-driven design all rolled into one and dialled up to 11. These are not new concepts, they were just willfully sidelined by the industry as management-level jargon until AI came along.
Earlier, software development was focused more on the materialization of code and the implementation. The system design and stewardship of intent was not a developer task but a manager task. Now, implementation is automated and temporary but the system design and intent is what must be encoded durably — not by a manager but by the developer. Teams that cling to code as identity will feel this as loss of purpose. Teams that relocate rigor successfully from implementation to specification will feel this as liberation.
If you’ve ever commented out legacy code rather than deleting it, feeling like it has the ego of a senior developer and some sort of wisdom attached to it — wake up. This is not just a tooling upgrade, it’s a profession being reborn.
At ARPM, we’ve been working at this problem of bad assumptions for the past decade, before AI became mainstream. We’re building the next-gen visual programming environment that you need.