2026 - The Year when Great Rewrite with agentic engineering starts and what it means to software development companies
SHGrowth liberates software development companies from commoditization by providing proven paths to become scalable, IP-based market leaders.
The Great Rewrite is a term coined by a few people in the past few years to describe the fundamental shift in the way we approach software development. It is a response to the rapid pace of change in the field, driven by the increasing complexity of software systems and the need to deliver value to customers at an ever-increasing rate.
For software development companies, the Great Rewrite is a shift from building software to orchestrating AI in building software. This is a huge paradigm breakthrough that signals the approach of what Geoffrey Moore calls a Tornado. We are not there yet, but the winds are picking up.
AI is eating almost every niche of our lives, from the way we learn, write, and share knowledge to more complex tasks like medical diagnosis, drug discovery, self-driving cars, etc.
This is all very obvious to everyone. However, what is not so obvious is where the niche applications of AI are going mainstream. This is where the old paradigm experiences friction with the new paradigm so intensively that they find a perfect spot to hit the ground and start a devastating tornado.
This is where the Tornado begins to form. When the technology of industry gorillas (market leaders) starts shifting permanently to AI, the rest of the market must decide: seek shelter or build a windmill. For the owners of software development companies, this choice is existential. It is a choice between being a dying Software House or a thriving Agentic Studio.
The “Time & Material” model didn’t die with a bang, but with a whisper generated by an LLM token. Unless you pivot to delivering IP instead of hours, you risk running a “Zombie Company” walking, but dead.
ROI is the key metric for AI adoption.
Firstly, let’s look at where AI failed to deliver its value. When we read the MIT report from mid-2025, we can see that 95% of corporate Generative AI (GenAI) pilot projects fail to deliver measurable financial returns, often stalling after six months with no impact on profit and loss. It was caused not by AI’s weakness but by poor integration and a lack of context retention in tools. The study revealed a “GenAI Divide” term, where companies struggle to move beyond basic pilots, despite a thriving “shadow economy” of employees using personal AI tools effectively.
Some analysts have challenged aspects of the study’s methodology, arguing that its definition of “failure” is narrow (ROI measured in short timeframes) and doesn’t capture efficiency improvements or other non-P&L (profit and loss) benefits.
What is my key learning from this report? The lack of a strong, revenue-led use case for AI is the main reason why AI adoption is failing.
There is, however, one very revenue-led use case where AI is delivering direct, tangible, and monthly visible value. It’s in software development.
Billion-dollar use case is ready: ROI from transforming software development life cycle to agentic engineering
In 2024 and 2025, we saw many attempts to apply AI to software development, and we see a huge battle between sceptics and visionaries. Sceptics are trying to apply AI to software development in a way that is not disruptive to the existing workflow, often being very critical about its ability to write complete, secure, scalable code.
Visionaries are trying to apply AI to software development in a way that is disruptive to the existing workflow.
The senior technical leadership teams are making a choice. Which side they choose will determine the future of software development companies. The choice is between scepticism and vision. The business stakeholders are in the same boat but feel the tension is high.
The sceptics are against the great rewrite.
The companies with sceptical senior leadership teams are often arguing against using AI to write code, claiming it’s not ready for production. They use hard-to-resist and very revenue-based fears like sudden crashes of code spoiled by AI or security threats. They claim the delivered code is hard to read and bloated with AI slop in its purest form. They have plenty of evidence in the market to prove their point.
Business stakeholders invested millions of dollars in their software and in their teams. They are not ready to let go their entire technical team although they feel more and more, that the above story is not true. They look for other technical experts to help them make a decision in a safe way. They will try to eat the cookie and have it too.
The visionaries are for great rewrite.
The companies with visionary senior leadership teams are in a totally different position. They are jumping every day from one innovation to another, trying to grasp the best way to apply AI to software development.
A great example is the exchange of thoughts between three product and technical leaders, one of them is Peter Yang from Roblox, who wrote an extensive article about the future of AI in software and product development.
He points out how Product Management is going to be transformed by AI, in short he sees that product managers will work directly with AI agents like software engineers do, on the same artifacts.
He also posted on Linkedin a Tweet from Andrey Karapathy, ex AI Director at Tesla:
A crucial part of his post:
"Clearly some powerful alien tool was handed around except it comes with no manual and everyone has to figure out how to hold it and operate it, while the resulting magnitude 9 earthquake is rocking the profession. Roll up your sleeves to not fall behind.”
Andrey confirms that agenting engineering is the future, but there is no manual which points us directly to third group of technical leaders.
The pragmatists are in the chasm.
On purpose, I left a huge gap between sceptics and visionaries. In Moore’s terms, the early market is defined by pragmatists who are selecting the bullet-proof whole product solution. They are not ready to let go of their entire technical team just because they are hesitant about AI. They are willing to try to find a way to apply AI to software development to an extent where they can justify the investment.
They know AI is here to stay and deliver PoC and even ready systems in days, but they can’t see the new path. They look to their network to find confirmation of the first signals of the whole product solution (the manual) , and they can’t find any. Why?
The whole product for agentic software development is under construction.
Every day we see technical leaders writing about agentic software development. They pitch their new cool approach, new framework, new tool. They are on a single-man mission (transformation project) to find a way to apply AI to their development teams and to create their own agentic software development process.
Here is a recent example from Peter Steinberger, who wrote on the 28th of December 2025, where he outlines from the top to the bottom how he works on multiple projects at the same time with AI.
Also, the technology gorillas (market leaders) in agentic engineering like Google, Anthropic, and OpenAI are working on the AI-native software development process by educating leaders on the best way to approach it.
Antropic has created a repository where they tackle this challenge from the prompt engineering side, which is a step forward in the AI-native software development process, especially for engineers.
Google offers the Agent Development Kit (ADK), a modular framework for building scalable agent architectures on Vertex AI.
OpenAI provides the OpenAI Agents SDK, an experimental framework exploring ergonomic, lightweight multi-agent orchestration.
It’s clear that the leaders are trying to duct-tape a whole product for agentic software development, but there is no standard that is accepted by the market. Yet...
100xProductivity boost: The key metric used by technical leaders to justify the investment in agentic software development.
The pragmatist has to find a metric that can justify his bet on agentic engineering. The most important metric that technical leaders use to justify the investment in agentic software development is productivity boost. Fabian Wesner has recently visualized the productivity boost in agentic software development in a very clear and concise way.
The challenge is that the productivity boost is not linear and persistent. Depending on the scaffolding you hold your agents to, the productivity boost is different. If you simply “vibe-code” in a vanilla way with tools like Cursor, Windsurf, Antigravity or Codex, your initial speed will eventually hit a wall of complexity and technical debt. You are just typing faster, but you aren’t engineering better.
Agentic Engineering is about Software Development Life Cycle, not just coding
The real game-changer for agentic engineering is when you start to think about the Software Development Life Cycle (SDLC) as a whole and how agentic engineering rewrites it.
We are in the new era of Agentic SDLC where agentic IDEs and agents become main collaborators with all members directly involved in SDLC. This means that the feedback loop between all members is much shorter and agents are assuring proper requirements gathering, architecture design, code review, and testing.
Agentic SDLC is currently the single most important use case that every technical leader is thinking about. The evidence is clear. Andrej Karpathy in the tweet I’ve already mentioned above highlighted the emergence of a new programmable abstraction layer. Complex ecosystem of agents, contexts, and tools that demands a new mental model.
Similarly, Peter Steinberger describes his solo agentic engineering SDLC as ”shipping at inference speed ” where the bottleneck shifts from typing code to “hard thinking” and AI feedback loops, fundamentally compressing the traditional development cycle.
The interesting fact is that most of the SDLC parts will be soon standardised by the market leaders. AWS has already introduced the AI-Driven Development Lifecycle (AI-DLC), replacing traditional sprints with rapid “bolts” and introducing concepts like “Mob Elaboration” where teams and AI co-design specifications. Frameworks like Microsoft’s AutoGen and methodologies from consulting firms are creating the new standard: a continuous, AI-orchestrated loop rather than a linear human relay in the old-fasioned SDLC.
However, there is no standard for agentic SDLC that is accepted by the market. Yet ...
BMAD - a candidate for the “manual” for the agentic engineering
This is where Brian BMad enters the stage with his BMAd Method (Build More, Architect Dreams). He realized that to sustain the “Tornado” velocity, we need more than just a smart autocomplet. We need a structured, agentic architecture. His method treats AI not as a tool, but as a workforce, orchestrating specialized agents (Product Managers, Architects, QA Engineers) through rigorous workflows.
This is the “Whole Product” approach for the AI era: a framework that transforms raw intelligence into reliable, scalable engineering. It bridges the gap for the pragmatists.
Check out the project that is defining this new standard, it got 27k starts on Github starting on April 2025.
The BMAD method from the Software Development Life Cycle perspective is a Cognitive Process OS. It redefines the SDLC not as a linear handoff, but as a continuous loop of 4 distinct phases (Analysis, Planning, Solutioning, Implementation) where specialized agents (from Test Architects to Product Managers) must mutually agree on specifications and architectural decisions before any code is committed. It forces the “human-in-the-loop” alignment at the “Why” and “What” stages of SDLC, ensuring that the “How” (execution) is protected from context drift.
It seems like a very interesting bet on how to approach our manual for SDLC, however…
There are five problems with BMAD Method.
It lacks successful big implementations by tech gorillas (market leaders). This is a crucial sign for pragmatists who are in the chasm. They use this signal to convince their engineering teams and their stakeholders that “other, well-known companies are already using it”.
It is not meant to be a natural extension to agentic IDEs. The start of our journey should be from the agentic IDEs, and then we can build on top of it. It should address non-technical stakeholders too, to actually become a whole product for the AI era and to be a layer on top of agentic IDEs.
It relies on an opinionated approach to architecture assuming it knows the right architecture for the right system. This is also an issue with vanilla agentic IDEs.
Underneath, it still generates whole code for the project using pre-AI written frameworks and libraries.
Legacy code - agentic engineering is much better in green-field areas and in integrations with AI-generated code on mutually understood artifacts.
Let me explain the last three points because they are the place where our agentic engineering tornado has to be untangled to get a full wind power.
The agentic software architecture is not standardised, and it will never be standardised.
The software is written to fulfill the business case of the company. Never other way around. This is why fintech companies with millions of transactions per second use f.e. Akka with their Actor Model to run concurrent scalable applications
You don’t need this architecture to build an ERP system. This will be an overkill. With agentic engineering, AI might quickly jump from too simple architecture to too complex architecture. The architecture of the software inside companies is not so well disclosed on the Internet, the knowledge is fractional and again - very opinionated. This means the LLMs have no high quality of data to learn from on how to design the architecture of the software.
This is a first and very strong fear of every pragmatic technical leader - can I trust the agentic engineering approach to such extend that it will not destroy my company business case by applying incorrect architecture and security principles?
The massive rewrite caused by agentic engineering is not a solution to daily software development
Agentic engineering lets agents go back and forth through your code and mess with it. This is not a solution to daily software development with multiple teams. That’s why we see tons of solo developers who are using agentic engineering to build their products, but not so many of them working at such high speed as a team.
The teams need to feel control over their codebase even when AI is at the steering wheel. Otherwise, when the code goes to production and there is an urgent issue to fix, the pragmatist technical leader who convinced the entire board to go to the agentic engineering era at full speed will be fired the next day after such a big incident occurs and the team fails to understand the codebase.
The legacy code written by humans can’t be easily migrated to AI-native code.
The code written by humans is like painting, with specific scratches performed by multiple different brushes held by different painters over a long period of time using different paints. It is hard to migrate to AI-native code because it is not a standardized codebase. When AI enters such a codebase, it tries to smoothen it like AI does to our images. The smoothing of images is sometimes acceptable and desired, but when the code that is run on production is smoothened by AI, it can be a disaster.
The agentic supportive frameworks - a bridge in the agentic engineering chasm that leads directly to a massive tornado of productivity.
The above issues mean that the pragmatic technical leader has to get a whole product that assures him that the architecture written by AI is aligned with his business, the codebase is maintainable and that the agentic workflow is able to plugin to existing codebase with success.
Here is where Agentic Supportive Frameworks come into play. What is it?
Agentic Supportive Frameworks (ASFs) are standardized, highly opinionated architectural foundations designed specifically to be respected and understood by AI agents. Unlike traditional frameworks built solely for human maintainability, ASFs provide a strict “contract” often in the form of explicit documentation (like AGENTS.md) and a modular structure that allows agents to generate code with high confidence, predictable structure, and zero hallucinations.
I used the earlier drawing made by Fabian Wesner and enriched his productivity chart with a new axis - complexity and draw a green blocks that visualize how agentic engineering concepts, from very basic to the most advanced with ASF are changing the productivity persistence while code base gets bigger. With ASF we build on the shoulders of agentic supportive modules, specs, guardrails, tools and MCP’s which promises the highest productivity boost possible with the current agentic engineering technology.
A prime example of this new category is Open Mercato. It is one of the first open-source frameworks to treat AI agents as first-class developers. It provides them with a clear map of the territory: a headless, modular architecture where every business function is encapsulated, auto-discovered, and strictly typed.
By adopting an ASF, the pragmatist leader solves the “blank canvas” problem. They don’t have to trust the agent to invent the architecture. They only trust the agent to FILL it. This allows the “Tornado” of agentic engineering to finally touch the ground, turning potential chaos into a scalable, maintainable business asset. And most importantly - a sellable Asset.
Here is how ASF and on Open Mercato as example, specifically addresses the five fears of the pragmatist:
Tech Gorilla Validation for Pragmatists
Open Mercato is smart about its signaling. It doesn’t ask you to bet your company on a new, unproven language. Under the hood, it runs on Next.js, MikroORM, and TypeScript - standard technologies validated by millions of developers and enterprises. It uses Awilix to provide a standard dependency injection pattern similar to what enterprise developers expect from languages like Java or C#. The innovation isn’t just the stack, it’s the Context Engineering. By standardizing the stack, Open Mercato gives your AI agents a predictable map of the territory. This provides the safety pragmatists need:
“We aren’t letting AI guess - we are giving it a strictly typed environment to operate within.”
2. A Context Layer for Agentic IDEs
It works with, not against, your tools. Open Mercato effectively acts as a server-side context engine for client-side tools like **Cursor, Windsurf etc.. By providing a dedicated AGENTS.md and strict type definitions, it gives your Agentic IDE the “map” it needs to function effectively. It doesn’t try to be an IDE itself. It provides the environment for your IDE to operate in, reducing the cognitive load on the agent.
3. Standardized, Yet Flexible Architecture
Critics argue that opinionated architecture is risky. Open Mercato flips this:
Lack of opinion is the risk for AI. By establishing a rigid, standardized module structure (Headless design), it removes the “opinion fatigue” from the agent.
Moreover, Open Mercato focuses on a specific category: CRM and ERP systems. In Geoffrey Moore’s terms, this simplifies the “whole product” search. The technical leader doesn’t need a generic “do-it-all” framework. They need the right tool for their specific business domain. By choosing an ASF designed for their category (e.g., Commerce/Operations), they inherit an architecture that already “speaks the language” of their business challenges, drastically reducing the complexity the agent has to manage.
This leads to a crucial risk reduction benefit: Safety Sandboxing. Because the ASF guarantees strict contracts between modules, you can “sandbox” your Agentic IDE to work only within a specific module. The AI assumes the surrounding modules work as advertised (the contract), preventing it from wandering into the “forbidden zones” of core infrastructure or unrelated business domains during a refactor. It keeps the “tornado” contained.
4. Reliability of Established Libraries
This is a feature, not a bug. Generative AI is great at logic, but terrible at reinventing wheels. Open Mercato leverages proven libraries (MikroORM for data, Awilix for DI) because they are deterministic. We want our AI to write the business logic, not the plumbing. Using established libraries ensures that the core reliability of the application remains high.
5. Migration Path for Legacy Code
Because Open Mercato is modular by design, it enables a safe “Strangler Fig” migration strategy. You don’t have to rewrite your monolith overnight. The framework allows you to easily “flag” specific modules as legacy-connected, telling the AI to respect existing database structures rather than trying to reinvent them. The strict contracts allow AI/Agentic teams to build new features rapidly in the new system while maintaining necessary, safe links to the old data.
Why ASF are the key to successful agentic software development?
Because they are a whole product for agentic software development for a given category of applications. If you need to build your own ERP/CRM with AI - you will use Open Mercato. If you need to build your own e-commerce platform with agentic engineering approach - you will choose... and here is good information for any software development company out there.
The ASF category is just starting. Open Mercato is a serious attempt to define how we should tackle the agentic engineering chasm to open the tornado for agentic software development in ERP and CRM. It’s not just a framework, it’s the foundation of your new IP.
The end of the “SaaS vs Custom” era
Tomek Karwatka, a person who in polish Software Development Agencies world has achieved a lot by building several successful agencies is betting on ASF and Open Mercato. Why?
Because the productivity boost isn’t the only KPI and use case where agentic engineering is hitting the tornado phase. He sees the early signals for tornado in the great rewrite for the SaaS vendor-locked enterpises. Instead of paying millions of dollars yearly on SaaS and other licenses they can use Open Mercato and write their own CRM/ERP in weeks.
He wrote about it in his latest tweet:
Agentic engineering kills the justification for rigid, boxed SaaS and the pain of paying for expensive licenses while maintaining legacy code. Clients today demand the speed of SaaS but the perfect fit of Custom Development. They don’t want to pay for time spent of developers anymore they want results, instantly.
ASF and Open Mercato as example is the engine for this new reality. It allows you to stop selling code lines and start selling pure business value by software development companies.
Why is this a game-changer for Software Development Companies?
1. Build Product, Not Infrastructure: Logic, multi-tenancy, billing, roles, audit, security, it’s all ready. Your team focuses only on what generates unique value.
2. Open-Source “SaaS” with safe framework: Your changes sit on top of the core, protecting you from “Upgrade Hell”. You get the stability of a maintained platform with the flexibility of custom code. No forks.
3. AI-Native Foundations: Data, workflows, and permissions are designed for AI agents from day one.
4. Enterprise-Grade Security: Tenant-scoped encryption out of the box. You can rewrite their exisitng software without fear of compliance issues.
Are You Ready for the Great Rewrite?
You understand the shift. You see the Tornado forming.
Many Software Development Companies will try to pivot and fail because they will treat this as a technical upgrade, not a strategic overhaul. They will adopt Cursor, but stay in the “deliver hours, not results” mindset. They will fail to become a true Agentic Studio.
Don’t pivot blindly.
I am opening 3 spots this month for a IP Radar.
We won’t just “audit” strategy. We will dig through your “Digital Waste” to find the one Asset that can become your IP, resistent and growing on the agentic engineering tornado.
You will get a brutal, honest verdict: Go or No-Go on your IP bets including validation steps to reduce the risk of false positives to zero.
If you are ready to stop selling hours and start building IP for your clients and yourself, let’s talk.