From Group-Drive to Unit-Drive
The productivity paradox of agentic software. A century-old lesson from American manufacturing, and the architecture decision every engineering organization now faces.
I. Electrification
In the 19th century, American factories relied on group-drive systems for power transmission. A single steam engine transmitted power via an intricate system of rotating shafts, belts, and pulleys. Factories were architected, manned, and capitalized around the needs of this engine.
In the 1890s, as factory owners began to adopt the electric motor, they retrofitted existing systems for simplicity. The improvements proved numerous: continuous power, quieter machines, reduced energy needs, improved speed control, and cooler working environments. On paper, they had achieved all the wins that electric motors had to offer.
In reality, the Total Factor Productivity (TFP) stagnated. The output of the factory was only marginally improved, while the capital input increased significantly (a new engine). It took 2 decades to realize electric motors facilitated the unit-drive which enabled independent machine placement. The result: modular layouts that adapted to rapidly changing manufacturing processes which beget exponentially compounding output.
This sort of overlaying of one technical system upon a preexisting stratum is not unusual during historical transitions from one technological paradigm to the next. Paul A. David, 1990
II. Market
Organizations using coding agents to build software are experiencing this same productivity paradox. Most organizations today are replacing hand-written code with agent-generated code without modifying the factory: release processes, documentation, observability, local development, developer onboarding, etc.
They are bolting agents onto an architecture optimized for legacy technology.
- Better coding agents / harnesses
- Better memory recall
- More context optimization
- Cheaper VMs running existing Containers
- Create more abstraction (hosted vibe coding)
The illusion of immediate productivity makes these businesses attractive when in reality customers need to be retooled.
III. Agent-Centric Development
Some top-tier engineering organizations have figured this out, and have published their thoughts:
The commonalities are clear:
- Agents must be infused with the business’ technical “taste”.
- Organizational context / business processes must become visible to the agent.
- Agent’s work must be verifiable in hermetic environments that operate concurrently.
- New context must remain visible to both humans and agents.
- Cultural shifts were required to begin adopting a workflow that’s truly AI native.
The result is that TFP skyrockets. Output compounds exponentially, while the cost is fixed: setting up a background agent.
This is summarized nicely by Stripe’s Alistair Gray:
As it turns out, parallelism, predictability, and isolation were also very desirable properties as well for Stripe engineers to be able to work most effectively. What’s good for humans is good for agents, and building on this infrastructural primitive paid dividends as a natural home for LLM agents. Alistair Gray, Stripe
What’s implicitly buried in this thought leadership is the human intelligence behind it. This style of work requires what we canonically call a 10× engineer. A whole team of them.
Attracting this kind of talent is inherently impossible for the majority of firms. We believe we can address that gap.
IV. Where We Fit
It’s our belief that businesses should have access to truly autonomous background agents to build software in a safe, reliable, and maintainable way.
We do this by providing the opinionated tools, infrastructure, and processes (collectively, the stack) that enable any organization to achieve an end-to-end autonomous development workflow.
The benefits to our customers are numerous:
- Network effects of shared infrastructure driving lower unit costs.
- Optimizing output per-token value through improving code quality and imbuing taste.
- Transparent workflows that benefit existing human engineers. (“what’s good for agents is good for humans”)
- Accessibility for non-technical team members to contribute idiomatic code.
- Product knowledge captured systemically for training.
- Out of the box compliance readiness and heightened security posture.
Our version of meeting our customer where they are is through Forward Autonomously Deployed Engineers. An opinionated stack allows us to train and maintain highly proficient agents acting as FDEs to truly augment and upskill our customer’s workforce while helping continuously maintain their software.
V. The Future
Our vision is a world where the Ivory Tower is achievable and software is vertically integrated.
A business that adopts Karya’s technology can reasonably build any software that it needs bespoke. The decision to buy vs. build truly turns into a business decision surrounding alpha. We believe that our agents should be able to deeply understand the context of a business and offer maintainable software solutions to their problems without requiring third-party vendors.
Standardizing the stack also allows for a true network externality effect as we can observe and heal the tooling and infrastructure based on the collective issues faced by a larger cohort of businesses. Paul David referred to this as compatibility standardization.
VI. Our Positioning
Regarding the evolution of SoTA LLMs, Karya’s model positions us to benefit from advancements in frontier intelligence. A better underlying LLM means better service from our agents.
On adoption, there is a valid criticism regarding applicability to existing code bases. Those are a “known quantity” to an agent. Through standardizing what high quality output looks like however, we believe our agents can assist customers in migrating brownfield projects fully autonomously. The input is already constrained, we constrain the output.