Notes from the factory floor.

Memoranda, technical notes, and arguments from the team building the infrastructure beneath autonomous engineering.

Memorandum · 001 May 2026 10 min read

From Group-Drive to Unit-Drive

A century ago, factories bolted electric motors onto steam-era shafts and belts, and productivity flatlined for four decades. Today's organizations are doing the same thing with coding agents. The way out is not better agents. It's a new substrate.

Read the memorandum
"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
Memorandum · 002May 20268 min read

From FDE to AFDE

The productivity ceiling, the four levers that raise it, and why the forward deployed engineers of the future won’t be human.

Read the memorandum
Coming soon

The Forward-Deployed Engineer, retrained.

How Karya trains autonomous FDEs on top of an opinionated stack, and what it takes to make them safe enough to ship.

In draft

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.

  1. Better coding agents / harnesses
  2. Better memory recall
  3. More context optimization
  4. Cheaper VMs running existing Containers
  5. Create more abstraction (hosted vibe coding)
We believe this is the wrong approach.

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:

  1. Ramp Inspect
  2. Stripe Minions
  3. Coinbase Forge

The commonalities are clear:

  1. Agents must be infused with the business’ technical “taste”.
  2. Organizational context / business processes must become visible to the agent.
  3. Agent’s work must be verifiable in hermetic environments that operate concurrently.
  4. New context must remain visible to both humans and agents.
  5. 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

Karya’s mission is to enable companies to build high-quality, vertically-integrated software autonomously.

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:

  1. Network effects of shared infrastructure driving lower unit costs.
  2. Optimizing output per-token value through improving code quality and imbuing taste.
  3. Transparent workflows that benefit existing human engineers. (“what’s good for agents is good for humans”)
  4. Accessibility for non-technical team members to contribute idiomatic code.
  5. Product knowledge captured systemically for training.
  6. 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.

From FDE to AFDE

The productivity ceiling, the four levers that raise it, and why the forward deployed engineers of the future won’t be human.

I. The Productivity Ceiling

Every new product brings the same inevitable question: how long until it’s ready to release? It’s a simple question on the surface, but at its heart sits a fundamental tension: speed of development vs. quality of development.

Think of the decision like a chart of productivity. Speed is on the y-axis and quality on the x-axis. The curve bows outward. You can have moderate amounts of both, but at the extremes the trade-off becomes punishing. Inherently, there is a maximum productivity that can be achieved without changing underlying variables: talent, tooling, process, or environment.

0Quality →Speed →Traditional ceilingAgentic ceilingcompounding effect

The productivity ceiling. Every organization picks a point along the curve: pure speed, pure quality, or somewhere in between. Agentic development pushes the ceiling outward.

II. Four Levers: A Golf Analogy

I find golf to be an easy analogy here. Think of your organization as a professional golfer and your productivity as golf score.

  1. Talent: Better players have better scores. No sugarcoating this one: an organization is the sum of its parts, and talent is objective.
  2. Tooling: Modern equipment makes the ball go farther and straighter. Frontier AI models and agentic development tooling have resulted in higher quality code faster — a true game changer.
  3. Process: Professional golfers use a range finder to find distance, consult their caddy, and take a practice swing all before actually taking a shot. Software development requires careful thought, collaboration, and planning before any code is written.
  4. Environment: Strategy and scores differ depending on the difficulty of the course, weather, etc. The composition of a codebase and the quality of a dev environment impact the quality of code written.

Historically, raising the ceiling of productivity meant pulling these levers one at a time. You hired a better engineer, adopted a new tool, tightened your process, or cleaned up your codebase. Each change was only marginally additive.

III. The Compounding Effect

When deployed effectively, agentic development changes that math. It collapses the tooling stack into something faster and more capable, absorbing process grunt work so that high-judgment tasks receive more attention. This in turn raises the effective skill of every engineer on the team and allows a small team to navigate, refactor, and maintain a codebase that previously would have demanded twice the headcount. The four levers can now be moved together, resulting in a compounding, rather than merely additive, effect.

IV. The Rise of the Forward Deployed Engineer

This then begs the question: how does an organization unlock agentic development? In response, the market for FDEs (Forward Deployed Engineers) has exploded. Organizations that lack the expertise are turning to industry experts who advise them on this new path.

FDEs install tooling and processes that optimize both speed and quality by leveraging the latest frontier AI models.

The FDE model works. Just look at the success of Palantir alongside the new enterprise AI services ventures from Anthropic and OpenAI. But is it optimized? It requires massive capital expenditure, and when the engagement ends, the expertise walks out the door. Still, the agentic development space continues to evolve rapidly. FDEs install tooling and processes optimized for today, but environments slowly degrade without the expertise to maintain them as best practices change and new code is written. The compounding effect is lost.

V. Autonomous Forward Deployed Engineers

So the next step is clear: FDEs must remain in place to avoid losing expertise or degrading the environment. The economics of keeping a human FDE on retainer indefinitely are out of reach for most organizations. This is where Autonomous Forward Deployed Engineers come in. An AFDE is an AI agent that lives inside your codebase and tooling, continuously maintaining and evolving your environment as the frontier shifts and your software grows.

Unlike their human counterparts, AFDEs don’t churn. They stay current with best practices automatically, integrate directly into your tooling and repo, and operate continuously, which means the compounding effect doesn’t decay the moment an engagement ends. And they do it at a price point that finally makes the math work.

Karya is building autonomous forward deployed engineers, making the compounding effects of agentic development accessible to every organization, not just the few that can afford to rent the expertise. The ceiling on productivity is still there. We just made it a lot cheaper to push through it.