Technical Brief is a series from Candidly’s AI product team. Written for builders, evaluators, and anyone who wants to look under the hood, these posts go deeper on the architecture, research, and design decisions behind our AI-native platform.

Written by Michael Rodriguez, Vice President of Product at Candidly, and Ben Levine, Chief Product Officer at Candidly

Last month, Anthropic published its AI-Native SDLC Playbook. The core argument: code generation is no longer the bottleneck in software delivery — the steps that still require people (planning, review, deployment) are.

We agree. We reorganized our company around that conclusion.

Candidly has spent the last year building the AI application layer for the enterprise. We are poised to serve 1 in 2 working Americans through some of the largest financial institutions in the country. Everything we ship has to clear the compliance hurdle of enterprise finance.

Earlier this summer, we broke the entire product development side of the company into small mission teams of three to five people, each with its own lead. Teams plan in 45-day windows instead of quarters. In the first window, throughput went from 1.8 completed projects per week to 6.8 — a 3.7x increase.

Anthropic’s playbook gets the engineering fundamentals right. Writing code isn’t the slow part anymore. You need review gates in place before you give agents autonomy. And codifying institutional knowledge as skills that agents can follow is the right model. But if your product operates inside the enterprise — as ours does — you inherit constraints this playbook doesn’t account for: external timelines you can’t compress, organizational accountability you can’t shortcut, and regulatory architecture that shapes how you build. That’s why we’d propose three additional chapters.

Chapter One: The dependencies you don’t own

Most of the conversation about AI development speed focuses on what happens inside your own company: planning, review, deployment. But when your product ships into an enterprise, much of the work doesn’t stay inside your walls.

Here’s what that looked like for us. In our first cycle, one mission team was fully staffed on day one, with a scoped plan in hand. But their work depended on a contract with an external distribution partner, and that partner’s legal review was still in progress. The team spent half its cycle window waiting on factors it couldn’t control.

These are dependencies you don’t own. Counterparty legal review, security questionnaires, budget allocation, and release windows all run on their own timelines. Once you remove the engineering bottleneck, these external timelines are actually what determine how fast you can actually ship.

The fix is treating cross-company dependencies as part of the lifecycle, planned with the same rigor as the engineering itself.

In practice: put every external dependency — contract execution, security review, partner kickoff — on the project plan before work begins. Each one gets a deadline and a named owner. When one slips, treat it like any other blocked milestone, not something the team absorbs halfway through.

Chapter Two: Planning is org design

Enterprise clients plan in calendar years. They have annual compliance reviews, budgeting cycles, risk assessments, board reviews, and release dates that don’t move. When you build products that operate inside those institutions, the commitments you make about what you’ll deliver and when carry real weight. Miss a deadline and your partner may not have another window for six months.

Before our team changes, roughly 70 percent of the work we finished each quarter was unplanned. After our first cycle with small mission teams, unplanned work was down to 17 percent. Committed work rose five-fold — from 10 planned projects to more than 50 — and the completion rate held steady. We planned five times more and delivered at the same rate, while cutting the planning cycle from 13 weeks to six.

What changed wasn’t better documentation or more rigorous specs. It was the organization itself. We made teams small — three to five people — so there are fewer dependencies and less room for unplanned work to take over. We shortened planning windows from quarters to 45 days, because the smaller the window resulted in fewer unknowns between the commitment and the delivery. And we gave each team one owner (mission lead) who stands behind the plan in front of peers every week.

In practice: restructure into small teams with short planning windows. Give each team a goal tied to a deliverable your enterprise client is actually waiting for — something that can ship within one window. At the end of the window, the deliverable either shipped or it didn’t, and that feedback makes the next window’s plan better and more predictable.

Chapter Three: Regulation is the spine

Most AI development frameworks treat regulation as a constraint to work around. For a company building consumer financial products, regulatory requirements shape the architecture itself. Here’s what that looks like for us.

The production gate. Our agents write, test, and stage code, but they cannot deploy it. Every release to production requires approval from a human on our team. We built it this way to meet our regulatory obligations, and we have no plans to change this.

Skills and hooks. A skill is a written instruction the agent reads and generally follows. A hook is an automated check that runs on every agent action and blocks anything that violates policy. Skills make violations rare, but rare isn’t enough. For an auditor, “the agent usually follows instructions” is not a control they can test, but “this check runs on every action” is. We built the skills layer first and then hardened it into hooks, in that order deliberately, because governance you rush is governance you rebuild.

AI as a control. During our first 45-day window, an AI audit of pre-release code surfaced several issues that human review caught before deployment. Companies usually treat AI as a risk their controls need to manage. It can also work the other direction: an AI reviewer never gets tired, and it can read every line of code before it ships. For fintech platforms, a single bug can impact real money movement, so catching issues earlier is a meaningful result.

In practice: decide where your production gate sits before your first agent ships, and write that decision down, because your customers’ security and risk teams will ask for it. Put your policies in skills first, then harden the ones that prove out into hooks. And add AI audits to your release process for the code where mistakes cost the most.

Where to start

If your teams are fast but your quarters aren’t, start with the dependencies you don’t own. If your roadmap keeps getting overwritten by reality, start with org design. If you’re regulated, start with the spine — because everything else depends on it.

The Anthropic playbook gives you the engineering. This enterprise edition is everything you build around it, and that is the part that moves the numbers.