Every 2 years I allow myself to go a little crazy. Let me make a prediction.
The last prediction I made in January 2024 in a webinar, the recording is still online - āSoftware Development will fundamentally change within 2 yearsā. Most people in the webinar thought IĀ“m crazy.
Our whole industry basically follows the same playbooks, rules and best practices. Good systems need Tests. We need good coverage. Code needs to be readable. CI/CD pipelines. Feature branches or trunk-based development. Comprehensive documentation. You name it.
All the things teams need to master to build quality software.
All hard learned best practices. We treat these like universal truths. Like laws of physics for software development.
But lately, Iāve been running some experiments that make me think all of this - every single ābest practiceā we cling to - might be completely obsolete within the next 2 years.
I know how that sounds. Crazy, right? From time to time I like to go a little crazy.
Questioning those fundamental ātruthsā and go back to first principles.. what would change if those best practices arenāt so fundamental as we all think?
Going Back to First Principles
From time to time, I start to question everything. Just to see where this leads me.
Most engineers will tell you: āWe need tests to ensure quality.ā
What if thatās not true?
What if tests are just an implementation of your specification - and once that specification is proven to work, re-running it is justā¦ waste?
Interesting thought.. letĀ“s dig deeper.
In most projects, tests are guardrails. They catch when you accidentally break something. Making invisible side-effects visible in red. Everyone celebrates when the CI/CD pipeline catches a bug before production.
But then I ask myself: what if thatās also not an essential truth? What if itās just a side effect of misaligned architecture?
The Architecture Problem
What if the need for constant testing is a SYMPTOM, not a fundamental requirement.
Think about it - what if you had one piece of functionality, completely isolated, proven to work, and it literally cannot break unless you touch it directly?
If Module A is truly isolated from Module B, why would changing Module A ever require re-testing Module B? Forget your current reality, forget side-effects.. just think for a second if that was true.
What if in a well-designed system with proper boundaries, accidental breakage would be basically impossible.
Then tests arenāt protecting from bad architecture - theyāre compensating for it.
The Necessary Cost We All Accept
Those Tests sitting in your repository eating up your LLM context windows. Force developers to wade through hundreds of lines of test code just to understand what something does. Make onboarding harder, not easier.
Why are we reading 500 lines of tests when we could just read the specification?
And thatās when the really crazy thought hit me:
What if we just regenerated the test cases from the spec - but only when we actually touch that piece of functionality?
Until then, theyāre simply not necessary. Why do we even keep them in Code?
No maintenance burden. No stale tests. The spec becomes the source of truth. Code becomes a transient side effect.
The Question That Changes Everything
What would happen if we didnĀ“t have those test-cases? Most developers will now cringe in their seats. Non-sense! Most engineers will push back: āBut what about regression?ā
And thatās the question that led me down another rabbit hole.
What if regressions donāt exist in a well-architected system?
What if we know exactly which artifacts have been touched, we regenerate the test cases for those artifacts on the fly, run them, verify them, and throw them away? Why do we need them if we know the system works?
The spec is permanent, the tests become disposable.
The Logical Conclusion
We are not done yet..
Developers (including me) said for years āthe source code is the ultimate truth.ā But that economic model just changed - radically.
If we regenerate the Specs on the fly, why not just regenerate the whole system on the fly, in whatever language you want, in whatever stack you need?
What if we validate the model as we build it, and the entire system gets generated fresh every single time? Or just the parts of the system that have changed?
Think about it:
- Your Specification is the source of truth
- Code is ājustā the implementation of the spec. generated on-demand
- Tests are generated, run as proof, then discarded
The specification is permanent. Everything else is transient.
My Crazy Prediction
Let me go crazy. I guess this will be a reality in 2 years.
Specifications will be the ONLY thing we version control.
Event Models. Behavioral diagrams. Visual specifications. Thatās what goes into Version Control. ( and no, I donĀ“t think itĀ“ll be git ).
Code will be generated on-demand in whatever language, whatever stack the deployment target needs.
Tests will be ephemeral - generated at build time, run as immutable proof artifacts, discarded after validation.
CI/CD pipelines wonāt pull code - theyāll pull specs and generate everything fresh, every time.
āSource codeā as we know it becomes an intermediate artifact, not the source of truth.
The entire system - regenerated on the fly, validated against the spec, deployed.
Why This Isnāt Science Fiction
I know this sounds insane. But hereās why I believe itās inevitable:
The technology is already here. LLMs can generate quality code from good specifications today. Iām already doing this with Event Modeling. I generate code from Event Models. I run LLMs in loops, implementing systems slice by slice.
The economics have shifted. Code generation used to be expensive and unreliable. Now itās cheap and getting better every week.
The tooling is emerging. Validation, generation, deployment from models - itās all becoming real.
The only thing holding us back is the mindset shift.
Weāre still attached to code as a precious artifact. Weāve spent decades treating implementation as the source of truth.
But once you forget what ābest practicesā told us was true and go back to first principles, this is the only logical conclusion I can come to.
What This Means for You
If Iām right ( and IĀ“m not saying I am.. just my crazy thought experiment ), hereās what matters:
The teams who learn to specify behavior clearly will dominate.
Event Modeling isnāt just a planning tool. Itās training for the future of development.
Those still attached to ātheir code,ā still thinking implementation is what matters, will be left behind.
Best practices wonāt die because we convinced people they were wrong. Theyāll die because the economics changed.
When generation is cheap and deterministic, persistence becomes optional, even questionable.
The Bridge Weāre Crossing
Look, Iām not saying we flip the switch tomorrow. This is a transition. Right now, Iām experimenting. Iām living partly in the old world, partly in the new.
I still commit code. I still maintain tests. But Iām testing the boundaries, pushing to see how far this can go.
And every experiment confirms: this is where weāre headed.
The Event Model as executable specification. Code as output. Tests as proof artifacts.
Disposable Code is the Future
For now, thatās all this is - a crazy idea Iām playing with. A vision that feels more real every day, but still sounds nuts when I say it out loud.
But I believe this is where weāre ultimately heading.
Not because I want it to be true. Because the logic is inescapable once you see it.
Are you building specifications that could survive without your code?
Or are you still treating implementation as the source of truth?
Because in 2 years, I think weāll look back at version-controlled test suites the same way we look at punch cards today.
Necessary once. Obsolete now.
It just needs your clarity about what the system should do.
What do you think? Am I crazy? Or are you seeing the same signals I am?
Drop a comment. Tell me Iāve lost my mind. Or tell me youāre seeing it too.
If IĀ“m right, that will be a fun ride. If Iām wrong? Well, at least it was a fun thought experiment.
Either way, Iām committed to finding out.
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letās have a quick, no-pressure conversation.