| TL;DR: AI is helping smaller teams build more software without growing their teams at the same pace. We spoke with Bit founder Ran Mizrahi about why managing all of that software can become a problem much sooner, and why producing more code may not be the answer. |
A small software team used to have one advantage over a large company: there was simply less software to keep track of.
AI is changing that by making code much faster to produce. But as the software grows, someone still has to understand what has been built, which parts depend on one another, and what could break when something changes.
Bit founder Ran Mizrahi says this kind of complexity used to appear mainly when companies became much larger.
“AI just gave everyone else the enterprise’s problem.”
The Software Can Grow Faster Than the Team
A company’s software is rarely made up of completely separate parts. A login system, for example, might be used across several applications. As the software grows, so does the number of connections a team has to keep track of. A change in one place can affect several others.
Bit was working on that complexity years before generative AI took off. When the company raised a $25 million Series B in 2021, its focus was on reusable software components: pieces that could be built once and used across different applications.
Mizrahi told SaaSTake that a ten-person company can now generate in a year the amount of code that once made managing these connections mainly an enterprise concern.
And producing more code creates another problem: someone still has to review it. Mizrahi argues that companies cannot simply keep adding reviewers to match the speed at which AI can generate code. Time saved during initial code generation can shift into work such as auditing and verification, according to Google’s DORA research.
But how do you build more software by writing less code?
Start With What You Already Have
Take a login system. If a company already has one that works and follows its security and design rules, another team does not necessarily need to create a new one for its next application.
The same applies to other pieces of software a company already has. Instead of generating another version, teams can reuse what already works and write only what is different.
There is also evidence that AI-assisted development may be leading to more duplication rather than reuse. In an analysis of 211 million changed lines of code, GitClear found that copy-pasted code increased between 2021 and 2024, while refactoring, which can help developers reuse existing code, declined.
“By composing applications from verified pieces the organization already owns, the net-new code in any release stays small enough for a person to actually read,” Mizrahi told SaaSTake.
An AI coding agent can work the same way, starting with what the company already has before writing anything new.
For reuse to work, the agent first has to know what already exists. Bit Cloud keeps reusable pieces together with information about how they work and what they depend on, giving the agent something to work from before writing new code.
Reusing something instead of rebuilding it solves one problem. But what happens when the same piece of software is being used in several applications and someone changes it?
Reusing Code Creates a Different Problem
Say several products rely on the same service for customer orders. Someone changes the information that service sends back.
The change itself could be small. But an application expecting the old information could stop working.
Bit uses a similar example to explain how its platform handles changes. If a piece of information sent by an orders service is renamed, Bit says the platform can identify which components depend on it, rebuild and test them, and show what failed before the change is released.
For that to work, the platform needs to know how the pieces are connected.
Bit’s Ripple CI is built around those connections. When one component changes, it maps the other components that depend on it so teams can see what else could be affected.
That context becomes even more important when an AI agent is making the change.
“A model can write the code,” Mizrahi said. “It can’t run it. No database, nowhere to deploy, and no idea what already exists.”
Bit’s approach is to give the agent more context about what the company has built. Mizrahi says agents can see which components depend on one another, investigate failed builds, and use Ripple to check what a change could affect before it is released.
Seeing what a change could affect still leaves another decision: whether it should actually go live.
When AI Writes More of the Code, What Does the Human Do?
Bit does not remove people from that decision.
Bit’s Changes system gives a proposed change its own live environment where it can be viewed and tested before release. Reviews can then be sent to the people responsible for the affected components.
Mizrahi told SaaSTake that Bit organizes this ownership around different areas of a company’s software. If a developer or AI agent changes a component belonging to another area, the owner of that component has to approve it.
The reviewer can then focus on what changed, what it affects, whether it still works, and whether it should be released.
This also makes one part of Bit Cloud’s September 2026 launch easier to understand. Bit made the platform available through native iPhone, iPad and Android apps, including the ability to review and approve changes.
Building software from a phone makes for an eye-catching launch. But the ability to approve a change from one may be more revealing.
If AI does more of the building, part of the human job moves toward checking what it did and deciding whether it should go live.
AI Changed Why Bit’s Old Idea Matters
Reusable components once helped teams avoid building the same things again. AI gives that old idea another job: limiting how much new code needs human attention in the first place.
The better AI becomes at producing code, the more useful it may become to stop it from producing code the company does not need.
Code is becoming easier to produce. The time people have to understand it is not.
If Mizrahi’s argument holds, the tools once needed when a company became large may become useful long before the company itself does.
