Introduction
A few months ago, I wrote about a shift happening on our engineering teams: AI coding assistants were giving engineers hours back every week, and that time was flowing into better product thinking, faster validation, and tighter partnership with product and design. We called it product-first engineering, and the thesis was simple. As code gets cheaper to produce, the value shifts to what's harder to automate: understanding problems, making tradeoffs, and building the right thing.
That first wave, Boilerplate reduction, quicker prototyping, and faster validation, is simply how a lot of our engineers work now by default. But, something has shifted again. We are no longer only talking about individuals using AI to move quickly. We’re starting to operationalize agents inside the engineering workflow itself as planners, implementers, reviewers, and investigators who plug directly into the systems we already use to ship software.
This post is about what that looks like in practice, not in theory. Where agents fit. What work they actually take on and automate. What systems they operate inside. And, just as importantly, where humans stay firmly in the loop, because that part is more critical than ever and isn’t going anywhere anytime soon.
Calendly's Friction Reduction Model, Reapplied
Calendly's original product insight was about removing friction. Scheduling a meeting used to mean a back-and-forth of proposed times, calendar checks, and reply-all threads. We built a product that removed that friction and collapsed the coordination cost to nearly zero.
We're now asking the same question about our own engineering process: what is the coordination cost from idea to validated, working software, and how much of it can we remove?
The parallel is direct. For our users, Calendly reduces the coordination cost of getting to a meeting. For our engineering teams, agentic systems are starting to reduce the coordination cost of getting from a defined problem to a validated implementation. We are now seeking to remove all friction between idea, requirement, implementation, review, and working code.
To be clear about intent: the goal is not automation for its own sake, the goal is to automate the repetitive, context-heavy, delay-prone parts of the job so our talented people can spend more time where they add real value: judgment, tradeoffs, architecture, product thinking, and user experience. That framing matters, because it shapes every guardrail decision described below.
What Changes When AI Moves from Tool to Workflow
It's worth being precise about what "agentic engineering" means at Calendly, because the term gets used loosely across the industry. In practical terms, engineers and teams define the goals, constraints, context, acceptance criteria, and safety checks up front. Agents then operate across the same systems humans use to move that work forward in a more frictionless, automated way. Execution happens inside systems that can be scoped, audited, reviewed, and improved over time, rather than inside a single chat window that disappears the moment the session ends.
Just as important is defining what agentic engineering is not. It is not a case where "AI writes all the code." It is not unbounded autonomy. It is not a replacement for real engineering ownership. Every engineer whose name is on a piece of agent-assisted work is still accountable for that work. Full stop. The core thesis is this: the real change isn't just faster code generation, it’s a more automated engineering loop with durable state and human checkpoints built in at the moments that matter.
Inside Calendly's Agentic Engineering Loop
The New Engineering Loop
Several teams at Calendly have converged, independently, on a similar shape for this loop. Teams typically start with a one-pager or Jira ticket defining the problem, the constraints, the acceptance criteria, and known risks. An agent critiques that ticket for ambiguity, missing edge cases, or missing implementation detail before any code gets written. A planner agent decomposes the approved work into PR-sized tasks. Implementer agents execute those scoped tasks, often in parallel, in isolated worktrees or self-hosted workers. A QA or reviewer agent verifies the output against the requirements, the test suite, and repository-level instructions. Only then do humans review, approve, merge, and decide what's actually safe to ship.
None of this work lives in a single ephemeral conversation. Jira stores the requirement. GitHub stores the code review and change history. CI stores verification. Repository instructions and shared rules store the behavioral constraints agents have to follow. This is a closed-loop system with durable memory, not a clever prompt.
How Teams Across Engineering Are Already Using Automations
This isn't a hypothetical future state. It's already running, in different forms, across the org.
CalTown: Expanding Who Can Ship Code
One of the clearest examples of agentic workflows already changing how work gets done comes from my own team, Contacts. We built an internal tool led by Max Conrad called CalTown. It lets teammates enrich Jira tickets with AI, assign the ticket to an agent, and have that agent build and open a pull request end to end. Before handing the branch back for review, it even runs linting, type checking, and the full test suite. What makes this example stand out isn't just the automation, it's who can use it. Two of our teammates who had never shipped code before—our designer and our product manager—have already used CalTown to put up and ship pull requests. That's a meaningful signal about how the model can expand who is able to contribute safely, provided the guardrails and review process are solid. The value isn't primarily speed. It's a clearer, safer pathway from context to execution, with a real reviewer and real CI in the loop every time.
Beyond Feature Work: Operational Investigation
Feature delivery isn't the only place agentic workflows show up. The Contacts team has started leaning on agents for operational work too. We use them to take a first pass at production issues, correlating an alert against recent changes, tracing through the likely code path, and surfacing a root-cause hypothesis, before anyone has to start digging through dashboards and logs cold. The value there is often accelerated understanding rather than automated fixing. Sometimes it hands back a diagnosis. Sometimes it proposes an actual fix. And sometimes it's upfront that it couldn't investigate far enough to be confident, which is exactly the kind of honesty that makes us comfortable letting it take the first look. Either way, it changes the starting point for whoever picks up the work next, from a blank investigation to a hypothesis they can quickly confirm or correct.
IAM: The Most Measurable Example Yet
The same pattern is emerging across other teams, each applying it in different ways but with the same underlying approach. Our Identity and Access Management (IAM) team is running our most measurable example of agentic execution. In about a week and a half, agents generated 64 pull requests, 37 of which have already been merged, with another 27 in review—completing roughly 30% of a project to decouple IAM's data model from our monolith. The work runs under a dedicated service identity and still requires two human review gates, so accountability never transfers to the tool.
Across Platform, Reliability, and Beyond
Another team has built a similar planner-implementer-QA loop of its own, plus automations for ticket refinement and bug triage. Our platform team is working toward an agentic design system that keeps AI tools defaulting to approved components instead of quietly reinventing them. They're also automating the tedious work of version-bumping shared UI libraries across every consuming repo. Another team is piloting a daily pass over the production bug backlog that only proposes a fix above a high confidence threshold, deferring to a human otherwise. Our reliability teams are building reusable skills that teach agents to do well-defined tasks, like scaffolding load tests. Some of these have already produced real, merged test suites in production services.
Shared Infrastructure Underneath It All
Underneath all of our agentic workflows sits shared infrastructure. We maintain a company-wide repository of AI rules and skills that any engineer can contribute to and pull from, an evaluation framework that checks whether AI-assisted code review is actually catching real issues, and orchestration patterns for turning a spec or epic into scoped, reviewable work.
The common pattern across every one of these examples isn't identical tooling. It's using AI to remove the most repetitive, context-heavy, and delay-prone work inside each team's own version of the engineering loop.
Where the Bottleneck Moves in an Agentic System
In the previous phase of this shift, we watched the bottleneck move from writing code to alignment: the meetings, documentation, and back-and-forth required to get everyone on the same page about what to build.
In the agentic phase, execution capacity expands again, and the bottleneck moves once more. It becomes judgment. What's actually worth building? What's safe to automate? What deserves escalation to a human, and what should remain fully human-led from the start?
This is where the story gets more technical, not less. When execution gets cheaper, the quality of your requirements, the quality of your scoping, and the quality of your review all matter more, not less. A vague ticket handed to a fast agent doesn't produce a good outcome faster. It produces a wrong outcome faster.
Good Requirements and Good Guardrails
Automation works best when the thinking work has already been done well. That's not a new engineering principle, but agentic workflows make it unforgiving in a way that manual development sometimes let us get away with.
Strong agentic systems need clear problem framing, good acceptance criteria, task decomposition sized to a single pull request, explicit non-goals and constraints, audit trails, review gates, and clear human ownership of outcomes. One practical implication we've had to internalize: tickets now need to be written to be read well by both humans and AI. A ticket that reduces ambiguity for a person reduces it for an agent too, and vice versa.
This isn't just a philosophical stance. Independent research backs up why the guardrails matter.
One industry study from CodeRabbit analyzing hundreds of pull requests found that AI-assisted PRs surfaced roughly 1.7 times as many issues on review as fully human-authored ones, with logic errors specifically appearing about 75% more often. Separate security research has found that a large share of AI-generated code samples introduce a known vulnerability class—and that using a larger or more capable model doesn't reliably fix that. None of this is an argument against using these tools. It's the argument for why review gates, scoped permissions, and human ownership of outcomes aren't optional overhead, they're the thing that makes autonomy usable at all.
Put simply: good guardrails are what make speed trustworthy. Reliability comes less from a clever prompt and more from strong operating rules that don't depend on the prompt being clever every single time
What This Changes for Engineers
Engineers spend less time as manual translators of requirements into boilerplate code. Increasingly, they spend more time as planners, reviewers, debuggers, editors of intent, systems thinkers, and risk detectors.
None of this works without deep technical expertise behind it. Someone still has to know enough to trust, correct, or override whatever an agent hands back before it ever reaches production. But leverage is shifting toward framing the right problem, constraining execution correctly, and validating output rigorously. In an internal pilot spanning dozens of engineers across more than a dozen teams, we saw exactly this pattern play out: the tools changed how people worked more than they simply sped up what people were already doing. The overwhelming majority of engineers said they still reviewed agent-produced output with the same scrutiny they'd apply to a teammate's pull request. That instinct to treat agent output like you'd treat any other collaborator's first draft is exactly right, and it's the behavior we want to reinforce as this scales.
Conclusion: The Next Bottleneck Is Still Judgment
The question our teams are asking has changed. It used to be, mostly, "can we build it?" or “how should we build it?” Increasingly, it's "is this the right thing to build, is it framed the right way, does the system we're building it in have the right constraints, and are the right humans reviewing it at the right moments?"
As software execution becomes more abundant and cheaper across the industry, the things that were always hard to fake like product sense, technical judgment, and organizational clarity matter even more. Execution was never really the scarce resource, good judgment about what deserves to be executed was.
Appreciations
Thank you to the colleagues across engineering who have been experimenting with AI-assisted and agentic workflows with curiosity, healthy skepticism, and care. That combination is exactly why the examples in this post are grounded in real, working systems rather than speculation. Particular recognition goes to the teammates who helped shape shared agent configurations, self-hosted worker setups, planning workflows, and operational patterns across Contacts, IAM, Scheduling and Availability, Frontend Platform, Ecosystems, App Platform, and SRE/DRE. Thank you also to the engineers who tested these workflows in real codebases, reviewed generated plans and pull requests line by line, and shared openly what worked and what didn't.
And thank you to our product, design, infrastructure, security, and platform partners for helping create the clarity and guardrails that make this kind of experimentation useful rather than reckless. This shift, like the last one, is a team effort built on trust, shared learning, and responsible iteration.
Next Steps
We're continuing to refine agentic workflows across planning, implementation, QA, and operational investigation. That means investing in stronger task definitions, acceptance criteria, and review practices so agents can work safely inside clear boundaries, and expanding alert triage, incident investigation, codebase research, and backlog-refinement workflows where the value is already clear.
We're also working to make Jira, GitHub, Slack, our observability tools, and our development environments work better together, so agents can operate inside the same durable systems our humans already trust. And we're staying deliberate about where agentic workflows are appropriate, where lighter-weight AI assistance is enough, and where work should remain fully human-led, while continuing to build the guardrails that let teams use autonomy safely without losing accountability.
The throughline hasn't changed since the day Calendly started: remove friction so people can focus on the work that matters most.
