Faster Coding Raises the Stakes for the Developer Factory

The Augment–Harness deal points to a broader competition: how reliably an organization can turn agent output into useful software.

A coding agent can finish its part of a task while the team still has days of work left.

The code needs review. The environment needs to be reproduced. A dependency needs approval. Somebody has to establish that the change solves the original problem and can run where the business needs it.

If you are responsible for engineering outcomes, those days count just as much as the minutes the agent saved.

That is what makes the Augment and Harness announcement interesting to me.

First, congratulations to the Augment team. Building useful developer tools takes technical depth, persistence, and a lot of listening to customers. I’m glad the team will get to continue that work in its next chapter.

Harness’s announcement names Cosmos, Auggie CLI, the Code Context Engine, and related technology as the assets it is acquiring. Its stated direction is to connect agentic development with the broader process of delivering and operating software.

My read is that the competition is expanding. The quality of the coding agent still matters enormously. Increasingly, so does the quality of the system in which that agent works.

Faster code can create longer queues

Think about what happens when one part of a development process gets much faster.

If a team can produce changes faster than it can validate them, the review queue grows. If agents can start work faster than environments can be provisioned, more tasks wait for setup. If every new dependency requires somebody to reconstruct why it was selected and whether it is allowed, the organization repeats that investigation more often.

Some of the time saved writing code gets spent coordinating everything that follows.

Hiring more people to manage those handoffs is one response. Another is to make more of the process repeatable.

That is the purpose of a developer factory: a system builders can use to turn an idea into tested, delivered software, with a reliable way to learn from what happens after it ships.

At Anaconda, our AI Dev Factory approach connects that development process with the packages, models, environments, security controls, and infrastructure underneath it. The enterprise defines the outcomes and requirements. The factory makes it easier to meet them consistently.

Make good decisions reusable

A practical example makes this less abstract.

Imagine an agent adds a Python library to solve a problem. The change works in the environment where the agent wrote it. During review, the team discovers that the selected version does not meet its package policy. A replacement requires code changes. Those changes need another test run, and the environment used by the reviewer differs from the original.

The agent may have written perfectly reasonable code given what it knew. The process still created avoidable work.

Now give the agent access to the relevant package information before it makes that choice. Establish an environment another builder can reproduce. Make the required checks available while the work is happening. Preserve the evidence so the next person can understand what was tested.

You have improved the conditions under which the agent works. That improvement can help every subsequent task that uses the same foundation.

This is where I think a lot of the enterprise value will come from: making good decisions reusable and reducing the amount of context people have to reconstruct.

For organizations building AI applications, that foundation also has to account for the behavior of the models and agents being shipped. Functional tests alone cannot answer every question about how an agent will use a tool, handle sensitive information, or respond to an unexpected instruction. Those questions need their own testing and controls.

What we’re building at Anaconda

This is the work we are bringing together at Anaconda.

Kilo provides the environment where builders work with coding agents. Anaconda Platform provides trusted packages and environments with orchestration for repeatable AI workflows. Enkrypt AI brings testing and guardrails for AI systems. Our recent platform announcements extend those capabilities across development, security, and operation.

You can see a concrete connection in Kilo Desktop, which brings agentic development, notebooks, and conda environment management into the same application. That puts more of the working environment within reach of the builder and the agent.

Bringing products together creates the opportunity. Making the whole process easier for customers is the work.

That also means preserving customers’ ability to choose the components that fit their requirements. A useful factory needs to accommodate a better model, a different deployment environment, or an existing tool the team already depends on. Its value should grow as the customer improves those choices.

Measure the whole workflow

For engineering leaders, I would start with one workflow that matters to the business. Follow it from request to production. Measure the time spent doing the work, waiting, rebuilding context, and correcting things that could have been caught earlier.

Then improve the part that is holding the outcome back. Sometimes that will be the coding agent. Sometimes it will be environment setup, dependency selection, testing, or a handoff nobody has taken responsibility for fixing.

The measures should follow the work all the way through: how long a useful change takes to reach users, how often it needs rework, how reliably it runs, and what it costs to get there.

That is the standard I want us to build toward at Anaconda. A builder should be able to take on more ambitious work because the system around them handles more of the routine work dependably.