Related posts
See all
A significant change is happening in how software gets built. Not just the tools, which evolve constantly, but the structure of the work itself. The relationship between the engineer and the code is being redefined.
Over the past several months, we made a deliberate push toward agent-assisted development across our engineering, product, and design (EPD) org. The result has been a sustained, significant increase in product velocity across every metric we track. But the raw numbers aren't the most interesting signal.
What stands out is how people are spending their time. There's less mechanical execution and more emphasis on architecture, product thinking, and UX. Decisions about what to build are becoming more central, because everything can be built faster. The craft of engineering, the art of product, and the creativity of design is not diminishing in an agent-driven world. It is becoming more important.
Access to frontier models is widely shared. The advantage comes from how they are embedded into the workflow, and the discipline organizations build around using them.
Here's how we're building at Fieldguide.
Background Agents for Every EPD Team Member
We're deploying background coding agents across the entire EPD org. The workflow: tag a ticket, an agent generates the code, CI validates it, a human reviews and merges.
The goal is that anyone in EPD can invoke background agents for routine, well-defined work. PMs and designers at Fieldguide are already shipping code to production, which is incredible to see. We are seeing that dispatching an agent to handle a straightforward ticket is now as natural as assigning it to a teammate. A double-digit percentage of total tickets already flow through background agents. We expect that share to grow steadily and expand to increasingly complex work.
Eliminating Support Toil
Production errors consume real engineering time. An engineer gets pulled off feature work to triage an issue, trace the root cause, and write a fix. Much of that process is mechanical.
We're building an autofix pipeline for our background agents: error detected, code generated, PR created, ready for human review. For known error patterns, the goal is getting to full agent autonomy. For complex or novel issues, agents do the investigative groundwork (gathering logs, tracing error paths, identifying probable root causes) and determine where to route work, so engineers shift from investigation to validation.
We’re already seeing promising results here. We track distraction minutes, how much time engineers are pulled away for triage, and are seeing it drop by a substantial amount each month. Even better, our rate of bugs to new features also shows steady decline, showing that code quality is holding strong as we ship more.
Rethinking Code Review
If agents are writing more code, the review bottleneck becomes a problem. Agents are generating PRs faster than humans can review them. Solving this requires more than asking reviewers to speed up.
Our approach is evolving in stages. Today, agents assist during authoring PRs while humans still own the full review. Next, as agents author entire PRs from well-scoped tickets, the reviewer's focus shifts from "did you write this correctly" to "should this ship." We're deploying specialized review agents for security, performance, observability, and code standards, each with a tailored evaluation rubric that will determine how the review is routed.
The goal isn't removing human review. It's making human review higher-value by eliminating the mechanical portions so reviewers spend their time on decisions that actually matter.
The Discipline for Zero-to-One Work
Background agents and review agents handle the steady state: tickets, bugs, maintenance, initial code review. The bigger mindset shift is using agents for zero-to-one work: entire new features, new services, new product surfaces. This requires a specific discipline we're standardizing across the org. The failure mode with AI-assisted development isn't wrong syntax. It's implementations that work in isolation but break in complex, surrounding systems.
Fieldguide has a massive codebase, so every meaningful task starts with a research phase where the agent reads deeply into the relevant code and writes structured findings to a persistent document you can review before planning begins. From there, the agent produces a detailed implementation plan: approach, code snippets, file paths, and trade-offs. The annotation cycle is where humans add the most value. We open the plan, mark it up directly, correct assumptions, reject approaches, add domain knowledge the agent doesn't have, and send it back for revision until the plan is right. By the time agents implement, it should be boring, because the key decisions have already been made. Engineers maintain tight control over architecture and a deep understanding of how the system should work. That is not delegated to agents.
This separation of planning and execution is one of the most important disciplines in agentic engineering. It prevents wasted effort, keeps humans in control, and produces dramatically better results than jumping straight to code.
AgentOps: A New Role
None of the above works reliably at scale without dedicated infrastructure and ownership. We're standing up “AgentOps” as a new engineering discipline in our Application Platform team, owning the connective tissue: agent infrastructure and shared configurations, measurement systems (cycle time, merge rate, defect escape rate, cost per agent run), developer experience and onboarding, and security and governance for our internal agentic systems.
Our Whole Org Ships Code
This isn't an engineering-only shift. PMs and designers are already shipping code to production. Customer Support uses Claude Code to troubleshoot. The barrier to producing working code drops dramatically when you're directing an agent rather than writing syntax from scratch. PMs who understand the product deeply can describe what needs to happen, and the agent handles the implementation. Designers who are relentlessly critical of UX can make adjustments basically on the fly.
Our enablement approach: run regular sessions where people share what's working; make agent workflows part of new hire onboarding from day one; bring in external trainers who've deployed agent platforms at scale. The organizational change management piece is real and we're investing in it significantly.
What This Means for EPD
This is a significant change to daily work. Tasks that used to require an engineer's hands will increasingly require an engineer's judgment and direction instead. That's a meaningful difference.
We don't believe this diminishes the craft of engineering, product, or design. The people who thrive will be those who understand complex systems deeply, define problems precisely, and have the taste to know when something is right and when it isn't. Those skills become more valuable with agents, not less.
We have a strong foundation. The work ahead is scaling it, building new systems that compound over time into an advantage that further amplifies our EPD organization and Fieldguide as a whole.
Chris Szymansky
CTO @ Fieldguide
