What if AI isn't another tool—but the organisation itself?
When Wilmington, Delaware-based software engineering company zeb unveiled its AI-native operating architecture, Substrate, in June, the announcement focused on a new way of delivering software projects. Less obvious was the fact that the company had spent the previous year rebuilding itself around the same principles.
The result, according to zeb, is a flat engineering organisation with no middle management, no non-technical hires and a delivery model in which payments are tied to agreed outcomes rather than billable hours. Rather than describing Substrate as another AI platform or enterprise copilot, zeb co-founder and CEO Mal Vivek sees it as the environment in which the company itself now operates.
The distinction may sound semantic, but it reflects a broader question that many organisations are beginning to confront. As AI systems become increasingly capable of carrying out complex tasks, is introducing another tool enough, or do organisations themselves need to be redesigned?
For Vivek, the answer is clear.
"The core change was structural. We built an environment where AI is the first responder to any unit of engineering that comes in through Substrate, rather than a tool people reach for. So the work is designed around AI actively running it, with people engaging inside that process instead of operating it from the outside.
"That required a new competency model, one that enables the flat structure and lets every person at zeb cross the boundaries that specialisations used to enforce. The result is a much higher-leverage people-to-project ratio, far fewer humans on any one engagement, which means everyone is learning faster and moving across far more variety than an old delivery pyramid ever allowed."
The difference between those two approaches sits at the heart of Vivek's thinking. Much of today's enterprise AI strategy focuses on making existing workflows more efficient by adding assistants, copilots or automation to established processes. Vivek argues that this still assumes people remain responsible for directing the work, with AI acting as an extension of human effort.
zeb's own approach begins from the opposite direction.
Instead of asking how people should use AI, the company has tried to design an operating environment around the assumption that AI carries out much of the operational work, while people contribute judgement, oversight and domain expertise where those capabilities add the greatest value.
Why many existing enterprise data architectures fall short
That philosophy also explains why Vivek believes many existing enterprise data architectures fall short. Over the past few years, organisations have invested heavily in data lakes, lakehouses and orchestration frameworks designed to make corporate information accessible to AI models. In her view, those technologies still reflect assumptions inherited from a pre-AI world.
"The traditional structures were never designed for AI. Drop AI into a traditional process and you just add layers of review and approval on top of a system that only knows how to treat AI as an extension or an add-on.
"We flipped that. We designed the process entirely from AI's perspective, treating it as a first-class citizen. Our wiki and our core are built to auto-evolve at the pace AI actually moves, and to support AI at every step: parallelisation, the hand-offs, the feedback and reinforcement loops, and the specific points where humans need to engage alongside it. The process supports the AI, not the other way around."
Substrate is intended to provide that environment. Rather than simply routing prompts to language models, it is designed to retain organisational context so specialised AI agents can build on previous work, collaborate with one another and execute longer engineering tasks without continually restarting from scratch.
That, Vivek argues, fundamentally changes the role of human engineers.
"Most enterprise copilots are just wrappers around prompts that the client could write themselves. They're completely capped by human bandwidth.
"Substrate reverses that dynamic. It is a low-human-bandwidth, high-output environment. It maintains a continuous, compounding contextual memory of the entire enterprise's workflows and allows specialised AI agents to collaborate and execute complex sequences autonomously.
"Those agents don't just spit out or suggest text or code for a human to review and fix. Substrate runs the length of the field."
Skipping the industry's focus on elite credentials
The organisational consequences extend beyond software architecture.
As zeb rebuilt itself around this model, it also abandoned many of the specialist roles commonly found within engineering organisations. Rather than dividing work between narrowly defined disciplines, the company now describes itself as a builder-only organisation, encouraging engineers to move across technologies and projects instead of remaining within traditional specialisations.
For Vivek, that decision was influenced as much by the company's own history as by its views on artificial intelligence.
"I didn't attend college. Our CTO didn't either. A significant part of our executive team jumped straight into building this company, this code, and Substrate at a very early age. We skipped the industry's focus on elite credentials, so why would we hold onto that concept within our team?
"By cutting specialised silos, we removed the friction of project hand-offs. We hire for raw, self-motivated gravitational pull and encourage engineers to take projects that make them uncomfortable. Curiosity is the input; discomfort is the medium. Experience only compounds when you start tackling massive problems early."
The philosophy is perhaps easier to understand when viewed through one of zeb's first customer projects.
According to the company, cybersecurity firm CYPFER used the model while developing Cyrface™, a platform designed to quantify cyber risk by combining multiple mathematical models into a single scoring system. zeb says the project progressed from concept to deployment in approximately four months.
Vivek believes the speed was not primarily the result of faster code generation. Instead, she argues that redesigning the development process removed one of software engineering's least visible bottlenecks: translating complex mathematical concepts into working software.
"For something as complex as Cyrface, the old bottleneck would have been translation: taking dense, rigorous mathematical patents and getting engineers to interpret them and hand-write code.
"With AI as the first responder, that translation layer collapses. AI consumes the equations directly, designs and executes the code, and designs the tests to verify that code in parallel. So our engineers interpret code, a layer they already work in, instead of moving through middlemen translating patent to technical design doc to code. That's what compresses years into months."
The end of billing for time?
The same thinking also shapes how zeb charges for its work.
For decades, software development and consulting have largely relied on a familiar commercial model. Clients pay for expertise measured in hours or days, while projects evolve through successive rounds of delivery. AI promises to make those projects faster, but it does not necessarily change how suppliers are paid.
zeb has taken a different approach. The company says every engagement comes with a 100 per cent outcome guarantee, with payments linked to agreed milestones rather than time spent.
The promise inevitably raises practical questions. Enterprise software projects are rarely static, and business priorities often shift during development. Defining success precisely enough to guarantee it is arguably one of the hardest parts of software delivery.
Vivek argues that this is exactly why the conversation has to happen before a single line of code is written.
"We define the outcome with the client, as a specific metric moving by a specific amount. We measure the baseline, implement, and prove it moved. For most clients that means deployed, working software solving the business problem, not hours billed or a deck of recommendations.
"Billing for time is a great model for the seller and an adversarial one for the buyer, because every efficiency AI gives us just becomes our margin. The guarantee is how we pass that efficiency back and show we're a partner, not a vendor.
"The real trade-off is on us: if we don't execute on the efficiency Substrate is meant to enable on a given project, we eat into our own profitability on it. That forces us to hold the line, to keep Substrate auto-evolving on every engagement, and to spend the time up front rigorously defining outcomes with the customer. That's a harder pre-sales process than the loose scoping most consulting firms settle for, and that difficulty is the point."
The guarantee is intended to do more than differentiate zeb commercially. In Vivek's view, it changes incentives on both sides of the relationship. If AI makes software delivery more efficient, she believes those gains should be reflected in customer outcomes rather than simply improving the supplier's margins.
The organisation needs to adapt to technology
By this point in the conversation, it becomes clear that Vivek is not really criticising enterprise AI software. She is criticising organisational design.
In her view, many companies are trying to fit AI into structures that were designed long before autonomous software systems became a practical reality.
"You can't graft a high-velocity technology onto a low-velocity culture. It's that simple.
"If you give an AI tool to an organization with four layers of middle management, you just help them generate bureaucratic paperwork faster. It doesn't fix the underlying systemic failure.
"For genuine ROI, executives need to stop using AI as a scapegoat for market-driven layoffs and actually design a workforce where agents and humans operate together. It would take a completely redesigned environment. But we at zeb are already seeing the payoffs to making that type of extreme pivot."
That observation reaches beyond consulting.
Across industries, organisations are experimenting with copilots, AI assistants and workflow automation. Much of the discussion centres on helping employees work more efficiently. Vivek's argument is more fundamental: if AI becomes capable of coordinating increasingly complex work, then simply improving existing workflows may not be enough. The organisation itself may eventually need to adapt to the technology rather than expecting the technology to adapt to the organisation.
Whether that thinking can be applied inside large enterprises remains an open question. Start-ups enjoy the advantage of beginning with a blank sheet of paper, while established organisations must contend with legacy systems, governance frameworks, regulatory obligations and deeply embedded ways of working. Rebuilding around AI from the ground up is a very different proposition from transforming a business employing tens of thousands of people.
Out with the old, in with the new
Vivek nevertheless believes the direction of travel is becoming increasingly clear, particularly for consulting and software delivery.
"The billable hour is dead. When your project ends and the value starts decaying the day the team leaves, that's the old model.
"A system that learns from every engagement makes the next project better, which turns delivery into an appreciating asset instead of a depreciating one.
"The unit of competition becomes the rate at which your system learns, not how many people you can put on a problem. The firms that survive will look like foundries: small, high-leverage teams of builders who stand behind their work with real guarantees."
It is perhaps the most thought-provoking idea to emerge from the interview.
Liked this article? You can support our independent journalism via our page on Buy Me a Coffee. It helps keep MoveTheNeedle.news focused on depth, not clicks.
👉 https://buymeacoffee.com/movetheneedle.news