Introduction
A few months ago, I wrote about a shift happening on our engineering teams: AI codingassistants were giving engineers hours back every week, and that time was flowing into betterproduct thinking, faster validation, and tighter partnership with product and design. We called itproduct-first engineering, and the thesis was simple. As code gets cheaper to produce, thevalue shifts to what's harder to automate: understanding problems, making tradeoffs, andbuilding the right thing.That first wave, Boilerplate reduction, quicker prototyping, and faster validation, is simply how alot of our engineers work now by default. But, something has shifted again. We are no longeronly talking about individuals using AI to move quickly. We’re starting to operationalize agentsinside the engineering workflow itself as planners, implementers, reviewers, and investigatorswho 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 workthey 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 goinganywhere anytime soon.
Calendly's Friction Reduction Model, Reapplied
Calendly's original product insight was about removing friction. Scheduling a meeting used tomean a back-and-forth of proposed times, calendar checks, and reply-all threads. We built aproduct 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 thecoordination 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 ameeting. For our engineering teams, agentic systems are starting to reduce the coordinationcost of getting from a defined problem to a validated implementation. We are now seeking toremove 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 therepetitive, context-heavy, delay-prone parts of the job so our talented people can spend moretime where they add real value: judgment, tradeoffs, architecture, product thinking, and userexperience. 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 termgets 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 operateacross 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, andimproved over time, rather than inside a single chat window that disappears the moment thesession ends.Just as important is defining what agentic engineering isnot. It is not a case where "AI writes allthe 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 thatwork. Full stop. The core thesis is this: the real change isn't just faster code generation, it’s amore automated engineering loop with durable state and human checkpoints built in at themoments 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, theacceptance criteria, and known risks. An agent critiques that ticket for ambiguity, missing edgecases, or missing implementation detail before any code gets written. A planner agentdecomposes the approved work into PR-sized tasks. Implementer agents execute those scopedtasks, often in parallel, in isolated worktrees or self-hosted workers. A QA or reviewer agentverifies 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. GitHubstores the code review and change history. CI stores verification. Repository instructions andshared rules store the behavioral constraints agents have to follow. This is a closed-loop systemwith 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 donecomes from my own team, Contacts. We built an internal tool led by Max Conrad calledCalTown. It lets teammates enrich Jira tickets with AI, assign the ticket to an agent, and havethat 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 outisn't just the automation, it's who can use it. Two of our teammates who had never shipped codebefore—our designer and our product manager—have already used CalTown to put up and shippull requests. That's a meaningful signal about how the model can expand who is able tocontribute safely, provided the guardrails and review process are solid. The value isn't primarilyspeed. It's a clearer, safer pathway from context to execution, with a real reviewer and real CI inthe loop every time.
Beyond Feature Work: Operational Investigation
Feature delivery isn't the only place agentic workflows show up. The Contacts team has startedleaning on agents for operational work too. We use them to take a first pass at productionissues, correlating an alert against recent changes, tracing through the likely code path, andsurfacing a root-cause hypothesis, before anyone has to start digging through dashboards andlogs 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'supfront that it couldn't investigate far enough to be confident, which is exactly the kind ofhonesty that makes us comfortable letting it take the first look. Either way, it changes the startingpoint for whoever picks up the work next, from a blank investigation to a hypothesis they canquickly 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 thesame underlying approach. Our Identity and Access Management (IAM) team is running ourmost measurable example of agentic execution. In about a week and a half, agents generated64 pull requests, 37 of which have already been merged, with another 27 in review—completingroughly 30% of a project to decouple IAM's data model from our monolith. The work runs undera dedicated service identity and still requires two human review gates, so accountability nevertransfers to the tool.
Across Platform, Reliability, and Beyond
Another team has built a similar planner-implementer-QA loop of its own, plus automations forticket refinement and bug triage. Our platform team is working toward an agentic design systemthat 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 everyconsuming repo. Another team is piloting a daily pass over the production bug backlog that onlyproposes a fix above a high confidence threshold, deferring to a human otherwise. Our reliabilityteams are building reusable skills that teach agents to do well-defined tasks, like scaffoldingload tests. Some of these have already produced real, merged test suites in productionservices.
Shared Infrastructure Underneath It All
Underneath all of our agentic workflows sits shared infrastructure. We maintain a company-widerepository of AI rules and skills that any engineer can contribute to and pull from, an evaluationframework that checks whether AI-assisted code review is actually catching real issues, andorchestration 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 toremove the most repetitive, context-heavy, and delay-prone work inside each team's ownversion 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 toalignment: the meetings, documentation, and back-and-forth required to get everyone on thesame 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 deservesescalation 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 qualityof 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. Itproduces 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 newengineering principle, but agentic workflows make it unforgiving in a way that manualdevelopment sometimes let us get away with.Strong agentic systems need clear problem framing, good acceptance criteria, taskdecomposition 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 tointernalize: tickets now need to be written to be read well by both humans and AI. A ticket thatreduces 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-assistedPRs surfaced roughly 1.7 times as many issues on review as fully human-authored ones, withlogic errors specifically appearing about 75% more often. Separate security research has foundthat a large share of AI-generated code samples introduce a known vulnerability class—and thatusing a larger or more capable model doesn't reliably fix that. None of this is an argumentagainst using these tools. It's the argument for why review gates, scoped permissions, andhuman ownership of outcomes aren't optional overhead, they're the thing that makes autonomyusable at all.Put simply: good guardrails are what make speed trustworthy. Reliability comes less from aclever prompt and more from strong operating rules that don't depend on the prompt beingclever 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 knowenough to trust, correct, or override whatever an agent hands back before it ever reachesproduction. But leverage is shifting toward framing the right problem, constraining executioncorrectly, and validating output rigorously. In an internal pilot spanning dozens of engineersacross more than a dozen teams, we saw exactly this pattern play out: the tools changedhowpeople worked more than they simply sped up what people were already doing. Theoverwhelming majority of engineers said they still reviewed agent-produced output with thesame 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 toreinforce 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 rightway, does the system we're building it in have the right constraints, and are the right humansreviewing it at the right moments?"As software execution becomes more abundant and cheaper across the industry, the things thatwere always hard to fake like product sense, technical judgment, and organizational claritymatter even more. Execution was never really the scarce resource, good judgment about whatdeserves to be executed was.
Appreciations
Thank you to the colleagues across engineering who have been experimenting with AI-assistedand agentic workflows with curiosity, healthy skepticism, and care. That combination is exactlywhy 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, reviewedgenerated 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 helpingcreate the clarity and guardrails that make this kind of experimentation useful rather thanreckless. This shift, like the last one, is a team effort built on trust, shared learning, andresponsible iteration.
Next Steps
We're continuing to refine agentic workflows across planning, implementation, QA, andoperational investigation. That means investing in stronger task definitions, acceptance criteria,and review practices so agents can work safely inside clear boundaries, and expanding alerttriage, incident investigation, codebase research, and backlog-refinement workflows where thevalue is already clear.We're also working to make Jira, GitHub, Slack, our observability tools, and our developmentenvironments work better together, so agents can operate inside the same durable systems ourhumans already trust. And we're staying deliberate about where agentic workflows areappropriate, 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 withoutlosing accountability.The throughline hasn't changed since the day Calendly started: remove friction so people canfocus on the work that matters most.
