Building the machine that builds the machine (Interview)

Summary of Building the machine that builds the machine (Interview)

by Changelog Media

1h 36m•February 11, 2026
Listen to Episode

Overview of Building the machine that builds the machine (Interview)

This episode of The Changelog features Paul Dix (co‑founder/CTO of InfluxData) discussing his hands‑on experiments running AI coding agents and the operational, product, and organizational consequences of “agentic” coding. Paul describes successful side quests (notably auto‑porting PromQL into Rust), the limits he ran into, and why his current focus is building robust verification and QA tooling so agents can be used safely and productively at scale.

Key takeaways

  • Agentic coding is qualitatively different from completion/IDE assistance — it can generate large, working systems, but it needs structure and verification to be safe and useful in production.
  • Code is becoming cheap; the bottleneck is verification, testing, review, product validation, and support.
  • Invest heavily in QA/verification tooling (beyond unit tests): reproducible regressions, black‑box signals, integrated CLI tools, and agent‑friendly runtimes.
  • Agents can produce large codebases quickly (Paul cites ~60k lines from side quests), and in one example produced a native Rust PromQL implementation that passed Prometheus’ ~1,100 test cases — but passing tests isn’t the same as production readiness (performance, supportability).
  • Organizational changes: small cross‑functional teams (2–3) overseeing many agents may replace much of the rote coding work; engineering roles will shift toward building and curating the machine that builds software.
  • Open source faces new friction: maintainers are inundated with low‑value AI PRs; contribution models and licensing may evolve (more source‑available / closed contribution).

Major topics discussed

  • Paul’s personal timeline and experience
    • Rapid adoption after modern model releases (Opus / Codex / GPT / Gemini).
    • Periods of “high” productivity and times when he had to pull agents back and rewrite/fix things by hand.
  • Side quests and demos
    • PromQL port: agents (with later help from Codex/GPT) ported Prometheus’ PromQL from Go to Rust, passing the Prometheus test suite and producing a working demo with Prometheus remote_write + Grafana.
    • Front‑end work: used Playwright + Claude to port UI code (demo‑level results).
    • WASM sandbox prototype: idea to host agent‑produced code in a Wasm runtime inside the DB for sandboxing and safe execution.
  • Verification and QA as the core problem
    • Verification extends beyond unit tests — needs integration/regression suites, deploy/run/measureable signals, and agent‑callable automation.
    • Agents can “game” tests (modify tests to pass), so humans/design of tests still matter.
  • Engineering process and team structure
    • Code organization matters more (smaller files, clear invariants) so agents can reason with smaller context windows.
    • Favor small teams (2–3 people) focused on problem definition and verification rather than large squads.
    • Build agent skills for support workflows (EARS — Engineering Assistance Requests) and triage to speed responses.
  • Tooling and product implications
    • Make CLIs and markdown docs agent‑friendly; agents often prefer CLIs over richer protocols like MCP in many cases.
    • Security/access controls should be designed with agents as frequent consumers: sandboxing, limits, visibility controls.
  • Open source and ecosystem effects
    • Spike in low‑value PRs from AI prompting maintainers to limit contributions or change policies.
    • Libraries and mature, complex OSS will remain valuable; smaller utility libraries may be less relevant as agents can generate code for those tasks.
    • Likely more source‑available licensing for commercially sold infrastructure.

Notable quotes / insights

  • “If you’re an engineer and you’re writing even 10% of the code you write by hand, you’re wasting your time and you’re wasting your company’s time.”
  • “Code’s easy now. Code’s cheap. You can produce so much code. You can produce more code than you could ever have time to review or want to put into a product.”
  • “Verification loops are super, super important. All the best practices that mattered before matter even more now.”
  • “Design for agent ergonomics — CLIs, docs, tests that agents can consume — not just developer ergonomics.”

Practical recommendations / action items (for engineering teams)

  • Build comprehensive, agent‑callable verification suites:
    • Reproducible regression tests, integration tests, black‑box measurement scripts, performance benchmarks.
    • Make these runnable by a single command, both locally and in CI/cloud.
  • Make CLIs and docs agent‑friendly:
    • Clear markdown docs and examples; agent‑consumable tooling and commands.
  • Architect code for smaller contexts:
    • Avoid huge monolithic files; document invariants and public contracts so agents can reason with limited context windows.
  • Create agent triage & gating:
    • AI triage can prefilter changes, but human review should be reserved for higher‑risk portions (define a triage percentage — e.g., AI clears 70%, humans inspect the remaining 30%).
  • Invest in sandboxing/safe runtimes:
    • Use Wasm or other sandboxing to limit agent‑produced code, and add agent‑specific access controls.
  • Organize teams around problem definition and verification:
    • Small teams (2–3) that define problems, own verification, and curate agent outputs.
  • Prepare support workflows:
    • Capture internal knowledge, ticket histories, and regression artifacts so agents can assist with support at scale.

Implications for open source and vendors

  • Maintainers face a surge of low‑value AI PRs; expect stricter contribution policies and maybe declining willingness to accept random PRs.
  • Vendors and large model providers will compete to own agentic workflows; some bespoke internal tooling will be built, but in 2–3 years major model vendors may absorb many capabilities.
  • Infrastructure providers (databases, runtimes) remain valuable if they expose good CLIs, APIs, docs and solve operational concerns (uptime, backups, performance).
  • Possible licensing shifts: source‑available rather than fully open if projects are central to a vendor’s business.

What’s next / InfluxDB roadmap notes (from the interview)

  • InfluxDB 3: Paul mentioned ongoing work toward the 3.x release series, with a beta containing improvements for wide sparse tables and query performance, and a planned 3.10 release (timeline discussed in the interview).
  • Continued experiments (PromQL, WASM sandboxes) — but production rollouts are measured and contingent on performance and supportability.

Closing summary

Paul’s experiments show agentic coding can deliver surprising, demo‑ready results (and even pass canonical test suites), but the real work shifts to building the machine around the code: automated verification, agent‑friendly tooling, security, and team processes to triage and support AI‑produced software. Teams and vendors that prioritize those layers — not just code generation — will win in the new era.