Something pretty fundamental is changing in how software gets built. Not just the tools, which are always evolving, but the structure of the work itself.
We’ve focused heavily on agentic development across our engineering, product, and design (EPD) org. The result has been a significant increase in product velocity across every metric we track. But the raw numbers aren’t the most interesting signal.
What’s most interesting is how people are spending their time.
There’s noticeably less mechanical execution and far more emphasis on architecture, product thinking, and user experience. As the cost of building software drops, the importance of deciding what to build increases. In that sense, the craft of engineering, the art of product, and the creativity of design are becoming more important in an agent-driven world.
Access to frontier models is table stakes. The real advantage comes from how those models are embedded into workflows and the discipline built around using them well.
This post outlines how we’re approaching that shift at Fieldguide.
Our workflow for routine, well-defined work mirrors assigning tickets to teammates: a ticket is tagged, an agent generates the code, CI validates it, and a human reviews and merges. The goal is that anyone in EPD can invoke a background agent for this type of work.
This is already changing who can contribute to production code. PMs and designers at Fieldguide are shipping production code, which has been one of the most striking outcomes of this shift. Dispatching an agent to handle a straightforward ticket is as natural as assigning it to a teammate.
A double-digit percentage of our tickets already flow through background agents, and that share continues to grow. Next, we're expanding them to handle increasingly complex work.
Production issues always come with an opportunity cost. Engineers are pulled away from feature work to triage errors, trace root causes, and write fixes. Much of that process is repetitive and mechanical.
For known error patterns, the north star is full agent autonomy. We’re building an autofix agent workflow on top of our background agents so when an error is detected, the agent generates a fix, opens a pull request, prepares it for human review, updates documentation and runbooks if needed, and leaves the system in place that is better than it was previously.
For more complex or novel issues, agents handle the investigative groundwork. They gather logs, trace error paths, identify likely root causes, and determine where the work should be routed. Engineers shift from investigation to validation.
We track what we call “distraction minutes,” which measure how much time engineers are pulled away for triage. That number has been declining steadily. At the same time, our ratio of bugs to new features is also improving, showing that agents maintain or improve code quality while also increasing output.
As agents generate more code, code review becomes the primary bottleneck.
Pull requests are now created faster than humans can reliably review them. Addressing this is not a matter of asking reviewers to move faster. It requires changing how review itself works.
Our approach is evolving in stages.
Today, agents assist in authoring pull requests and perform an initial pass against our coding standards and practices. Humans still own the end-to-end review, but the focus is moving away from verifying implementation details and toward evaluating higher-level concerns such as architecture and the overall system impact of the change.
In parallel, we're introducing specialized review agents across distinct domains: security, performance, observability, code quality, and more. Each operates with a defined evaluation rubric and produces structured feedback. These agents help determine how reviews are routed, confidence in the changes, and where human attention is most needed.
Taken together, this creates a clear separation of responsibilities. Agents handle mechanical validation and domain-specific checks. Humans focus on judgment, tradeoffs, and final approval.
The goal is to make human review higher leverage by systematically eliminating the lowest-value portions of the process.
Background agents and review agents handle steady-state work such as tickets, bugs, and maintenance. The more significant shift is using agents for zero-to-one work: new features, new services, and entirely new product surfaces.
This requires a different level of discipline.
The primary failure modes in agentic engineering are systems that work in isolation but fail within the complexity of a larger codebase.
To address this, we’ve standardized a planning-first workflow. Every meaningful task begins with a research phase, where the agent reads deeply into the relevant parts of the codebase and produces structured findings in a persistent document. This document is reviewed before any planning begins.
From there, the agent generates a detailed implementation plan that includes the proposed approach, relevant code snippets, file paths, and tradeoffs. This is where human input is most critical. Engineers review the plan, correct assumptions, reject approaches, and add domain knowledge that the agent does not have. The plan is iterated on until it is sound.
By the time implementation begins, the process feels straightforward. The important decisions have already been made.
This separation between planning and execution has proven to be one of the most important disciplines in our workflow. It keeps humans in control of system design and produces more reliable outcomes than jumping directly into code generation.
None of this works without focused ownership and shared infrastructure.
We've established “AgentOps” as a new discipline within our Application Platform team. This group is responsible for the underlying systems that make agent-driven development reliable and scalable.
Their scope includes agent infrastructure and shared configurations, measurement systems such as cycle time and defect rates, developer experience and onboarding, and security and governance for internal agent workflows.
As agent usage grows, this layer becomes increasingly important.
This shift is not limited to engineering. PMs and designers are already contributing directly to production code, our Customer Support team uses tools like Claude Code to troubleshoot issues, and we expect to see an even greater number of non-engineering contributors to code throughout the year.
When the interface to building software becomes directing an agent rather than writing syntax from scratch, the barrier to contribution drops significantly.
PMs who deeply understand the product can describe desired behavior and rely on agents for implementation. Designers who are focused on user experience can make changes directly rather than routing everything through engineering.
More broadly, our go-to-market teams are also writing code and building internal apps, many of which are proving to be more useful for the needs of our business than general SaaS applications.
Supporting this shift requires intentional enablement. We run regular sessions where teams share what is working, incorporate agent workflows into onboarding from day one, and bring in external practitioners who have deployed similar systems at scale.
The day-to-day work of engineering, product, and design is changing. Tasks that once required direct implementation are increasingly about judgment, direction, and evaluation. That is a meaningful shift in how work gets done.
We don't see this as diminishing the craft of engineering, product, or design. If anything, it raises the bar. The people who thrive in this environment are those who understand complex systems, define problems clearly, and have strong judgment about what good looks like.
Those skills become more valuable as agents take on more of the execution.
We're still early in this transition, but have a strong foundation. The next phase is about scaling these systems and continuing to build internal capabilities that compound over time.
If this sounds interesting, check out our open positions. We're hiring!