Build the machine that builds the machine
Loading article…
Pull for previous story
(Note: this is a copy of a post I originally published on X on January 15, 2026, before this site existed. Unlike everything else I write here, I iterated with AI to finish this one. I still wrote it, but I did use AI help with editing and changes, so if it reads a bit different, that’s why. See There’s alpha in AI free writing for why the rest of the words on this site are written without AI assistance.)
Coding agents can produce the first version quickly. The difference between a demo and a deployable change is verification, and the verification stack is what actually improves agent output through rapid iteration. Build that machinery, and you get speed and quality at the same time.
There’s a manufacturing idea that goes something like: the real product is the factory. It’s the machine that builds the machine (i.e. end product).
An agent with the right tools and verification loop can build many different parts of the product. Building the infrastructure and tooling to point many agents at many different features and problems is, for software, building the machine that builds the machine. They become the way to reduce cycle time, increase velocity, and deliver the final product faster than ever before.
At InfluxData, that means investing heavily in test + validation infrastructure so agents can operate inside tight verification loops across objectives like:
The goal is to move review effort up the stack: from line-by-line scrutiny to verifying behavior, performance, and safety via repeatable checks. All of which should also be accessible by the agents doing the work.
Of course, that’s not where we are right now. We’re very much in the category of doing human review and having humans drive the agents individually. But I see that there’s an opening for more velocity and better results with more tooling built specifically for agents. It’s not always perfect and they still make mistakes, but my bet is that we’ll see another improvement on tool calling and instruction following in the next 6 months.
Practically, a lot of this work is around longer-running, systems-level tests. Tests that fall outside unit/integration scope. Some take 10 minutes; others take 72 hours (soak/perf/regression style runs). This doesn’t fit neatly into CI, and it’s not really orchestration (at least not yet). It’s more like building a toolbox so each developer can confidently run multiple agent sessions in parallel, each with real verification.
The funny part is that it feels like my career is looping back. I started in QA at Microsoft on Windows 2000 (named NT 5.0 at the time), building automation and lab tooling to load daily builds and rerun scenario suites. My gut says that same kind of automated QA leverage is going to be the multiplier in an agent-powered future.
Developers will spend more time building verification systems than writing the initial implementation.