Quality gates for agentic coding workflows mean one standard applied at every stage: plan, implementation, local checks, and pull request review. Qodo developer relations lead Nnenna Ndukwe ran the full loop on a FastAPI payments app in a workshop published in October 2026, ending with an agent that resolves review findings and reruns verification.
What are quality gates for agentic coding workflows?
Quality gates for agentic coding workflows are the checkpoints where an AI coding agent must produce defined evidence before its work advances. In the workshop, Nnenna Ndukwe, developer relations lead at Qodo, an AI code review and code governance platform, applies five: standards and context rules, a plan, tests, deterministic local checks, and pull request review with remediation. Ndukwe is also the founder of SignalPay, the demonstration application.
The logic behind the sequence is straightforward. An agent that writes payment code first and asks questions later produces work nobody can sign off on. An agent that must first state which repository rules apply, what behavior changes, which tests prove it, and which commands must pass has to expose its reasoning before the code exists.
In the Qodo Q2 2024 report, roughly 60 percent of the 600-plus developers surveyed said they ship code with limited or no testing to meet deadlines. That is the failure mode these gates catch, and it describes the pre-gate baseline rather than the outcome of running the workshop.
How the SignalPay workshop turns one refund workflow into five gates
SignalPay converts one narrow change into five explicit gates. The task is to add either a refund workflow or a capture retry handler to a self-contained FastAPI payments API with no front end. Ndukwe chose refund, since payment mutations are a place where AI-generated code can look correct while mishandling state, failure paths, and idempotency. Her stated reason for picking payments: it is a sensitive surface where plausible-looking code hides real defects. The workshop repository, Qodo Quality Workshop SignalPay, contains the rules, skills, planning templates, tests, and CI configuration the process depends on.
The repository layout is half the lesson. An agents file, a hidden plan directory, separate rules, skills, and docs folders, Semgrep for static analysis, tests, and a CI verification workflow all exist so the agent has somewhere to read from instead of guessing.
Prerequisites for following along are more than a coding agent. The session lists git, a GitHub account, the GitHub CLI, Python, UV, Node.js and npm, and any coding agent (Codex or Claude Code preferred), plus a Qodo account. Setup runs through make setup and make run so the API is live locally before any gate is exercised.
The five gates run in this order:
- Standards gate. The agent reads the agents file and repository rules, then explains which rule IDs matter for the payment task and why. It also installs or verifies the local skills and reports dependency health.
- Planning gate. The agent turns the task into a high-level implementation plan plus a build session execution plan, naming the first implementation skill and the test-driven prompt it chains to next. No code is written in this mode.
- Test gate. The agent uses test-driven and behavior-driven skills so the expected behavior exists as an executable specification before implementation.
- Local verification gate. The agent runs deterministic checks (Ruff, Pyright, Bandit, pytest, and conventional commit validation) as evidence the change preserves the local contract.
- Pull request review and remediation gate. Qodo posts findings in GitHub, fixes and deferrals are documented, and the verification command runs again after remediation.
If you skip Qodo entirely, you can still run gates 1 through 4 and use the platform only for the pull request review. Ndukwe frames that as a legitimate entry point rather than all-or-nothing adoption.
Why planning templates improve AI coding agent consistency
Planning templates improve consistency because they force the agent to restate behavior, constraints, and completion criteria before implementation. Ndukwe describes two: a high-level implementation plan and a build session execution plan.
The high-level plan covers the summary, the problem being solved, constraints, skill routing, scope and behavior scenarios, verification gates, failure and recovery rules, and a commit plan. It should answer five questions: what behavior changes, which rules apply, which skills guide the agent, which tests prove the expected behavior, and which quality gates must pass before review.
The build execution plan records the starting state: which branch is checked out, what the current local verification process is, which commands must run to decide pass or fail, lint expectations, the implementation skill handoff and execution steps, the test plan, and a definition of done. The definition of done is where deferrals and changed decisions get written down, so the plan is the record of what was intentionally left out.
Skill routing matters when the agent runs unattended. Naming a sequence of skills in the plan lets a goal or loop mode proceed without a human handing off each step, because the next step is already written down. Ndukwe's own experience is that the more detailed and consistent the planning document, the better the agent adheres to it and the better it corrects itself when it notices a missing step.
How to operationalize context with rules and skills
Operationalizing context means storing rules, skills, and engineering standards outside any single prompt, then pulling the relevant subset into each stage. Ndukwe organizes this in layers rather than a single list. A private instance of her G2 rules dashboard and her weekly context operations are evidence that this is a personal workflow, not a product claim.
Planning templates stay at the top, applied in any repository. General engineering standards sit below, relevant across languages. Language-specific skills, such as the Python and Pydantic typing contracts she lists, sit below that. The Pydantic package validates data models in Python, and bundling its conventions as a skill keeps type contracts consistent across the repositories that use it.
The general rule she gives is that a broader skill has to be reachable from more repositories, which is why the placement decision matters before the skill is written rather than after.
She also names audit skills from developer Aaron Francis (audit boundaries, drift, audit names, audit abstractions, dead code, auditing errors) as useful during implementation. She says she found them powerful for simplifying code and improving quality, and notes they may not be publicly available, so the fallback is having your own agent write equivalents.
Her measurement claim comes from her own work, not an independent evaluation. Applying the workflow to a large pull request, roughly 900 lines in her open source tool, the automated review surfaced one reliability bug. That is a personal result from one pull request, not a defect-rate benchmark, and it should be read that way.
What counts as a rule and how approval works
A rule counts as approved only after a human accepts it, and the source of the rule determines how much review it needs. Anything in a rules directory is ingested directly, since the team already wrote it down. Anything else appears as a suggestion generated from analyzing the codebase, phrased as a convention the tool noticed rather than a rule the team chose.
Suggestions are not silent. Each one arrives with good and bad code examples so the agent can see the difference, a category, and a severity level. You can edit all of it. Once you accept a suggestion, the rule activates and applies automatically.
Rules come with a category: accessibility, correctness, maintainability, architecture, security. They also come with a severity tier, and severity is what decides whether a finding blocks a merge. A repository rule requiring docstrings on Python functions is the example Ndukwe shows being flagged as an action-required maintainability violation, because her organization set the severity that high. The block is configurable, not inherent to the finding. Action-required and high-severity findings block the merge until they are fixed, and the reviewer runs again to confirm.
Rules can be scoped natively by organization or by repository. Ndukwe confirms the portal organizes them that way by default and that filtering the dashboard is the current mechanism for narrowing a view, a question she said she would take back to the product team.
One audience question about determinism got the most direct answer of the session. Large enterprise customers, particularly in regulated industries, want guarantees that a relevant rule will always be detected. Ndukwe said the topic has been raised with the product team and that she hopes it becomes a real feature. Until then, treat review detection as probabilistic and treat severity-based merge blocking as the deterministic layer.
Not every change should be automated without review. The engagement leader she mentions, Tessell, evaluates whether a skill is effective and whether it poses security concerns. Using a skill evaluator is worth mentioning because a rule can pass review without proving it helps, and Qodo ingests skills rather than grading them.
Are the gates fail-proof and what to do with review findings?
The gates are not fail-proof. The process produces findings; the team decides what to fix, what to defer, and what to block a merge over. The closing sequence makes the limits visible.
After the pull request is opened, Qodo reviews the diff against the rules and skills already ingested into the portal. In the recorded run this produced one bug, three rule violations, and two skill insights across five invoked skills. The bug was specific: refund idempotency was stored in a process-local dictionary using an in-memory store, so the same refund could be applied twice after a restart.
That finding is the clearest argument for the review gate. Nothing about the code's syntax looks wrong; the persistence model does.
The lesson from the closing Q&A is to re-run verification after fixes. Ndukwe calls it best practice because any change invalidates the previous check. The agent decides whether to re-run based on the repository setup, so prompt for it explicitly if your setup does not force it.
The same Q&A drew a question about whether local checks and cloud review cover each other. They do not. The pull request review clones the repository temporarily so it can judge a change against the broader codebase, not only the diff. That is a scope difference, not redundancy, which is why a passing local run cannot replace the pull request review.
How a PR resolver closes the code review loop
A PR resolver closes the code review loop by turning review findings into committed changes without leaving the workflow. Ndukwe runs the Qodo PR resolver against the pull request, which pulls down the issues it already identified from critical to high severity and offers two paths: review each issue individually, or autofix all.
Autofix all is the shortcut. The resolver applies the fixes, runs verification, and makes the commits itself, with commit structure enforced so an unstructured message blocks the commit rather than sliding through. It then posts a summary back to the pull request and marks the resolved issues as crossed out. Manual review is the alternative when the fix needs a decision instead of a patch, such as choosing how to persist idempotency keys rather than picking a storage mechanism by default.
Her stated reason for reviewing before autofixing is worth repeating: when automation applies a fix, verification must run again, because the change happened after the last check. A tool that skips that step has traded the loop for a shortcut.
A local Qodo review workflow that talks to the same backend was described as coming at the time of the session, giving the same agentic review capability outside the pull request. Treat it as forthcoming rather than shipped.
What to take from the workshop into your own workflow
The reusable artifact from the workshop is not Qodo and not the SignalPay repository. It is the sequence. Defining what code quality means, writing it down somewhere the agent can read it, pulling the relevant subset into each phase, and verifying the same standard from planning through review is the part that transfers to any repository.
The tooling layer is replaceable, and the maintainers expect it to be. If the rules, skills, and planning templates live in a context management layer, any coding agent with access to that layer can follow the process. Packmind and Unblocked are named in the session as context-management layers, meaning systems that hold reusable rules and prompts for AI coding agents outside any individual project. Qodo packages the loop as a commercial product and the exact pricing is not described in the session, so treat cost and contract terms as something to verify directly with the vendor.
The main adoption cost is discipline. A new rule or skill has to be maintained once more than one repository depends on it, and severity tiers only work if someone decides, ahead of time, which violations a person must fix. Teams that skip that decision end up with the same review process they had before, just with more output in the pull request.
The deployment question is the last boundary. Asked about local options for security reasons, Ndukwe said on-premises deployments are available and that banks and some Nvidia teams require them. That is a statement about available deployment options, not a compliance certification, and no HIPAA or banking suitability claim was made in the session.
If you build one thing from the video, build the planning template. Ndukwe's closing advice is to hand the repository to your own agent, ask it how to apply the structure, and add verification steps incrementally rather than rebuilding the workflow in one attempt.
One more piece of context for readers here: the Brazilian developer education ecosystem around this topic includes Gustavo Dev Doido and his Crazystack Typescript material, plus the Bootcamp do Dev Doido format, which packages the same practices for learners. The Crazystack platform at crazystack.com.br covers TypeScript and adjacent tooling for developers working in Portuguese.
Tools named in the workshop and verified sources
Every tool below appears in the session, and each link goes to the project's own repository or documentation rather than to a general overview.
| Layer | Tools | What each one does |
|---|---|---|
| Static analysis and linting | Semgrep, Ruff, Pyright, Bandit | Semgrep scans for patterns, Ruff lints and formats, Pyright checks types, Bandit scans for security issues |
| Tests and commits | pytest, conventional commits | pytest runs the test suite, conventional commits enforce commit message structure |
| Context and review | Qodo, Packmind, Unblocked | Qodo handles review and rule governance, Packmind and Unblocked hold reusable rules outside any single repo |
| Coding agents | Codex, Claude Code | Codex from OpenAI ran the live demonstration, Claude Code and other agents are listed as options |
| Skill evaluation | Tessell | Checks whether a skill is effective and whether it raises security concerns |
One note on identity. The transcript renders the speaker's employer several different ways. The canonical name is Qodo, and the workshop repository is under the qodo-ai organization on GitHub. The speaker is Nnenna Ndukwe, spelled as shown in the workshop materials. For anyone learning this stack in Portuguese, the Crazystack learning platform at crazystack.com.br is a useful reference, though it is separate from the Qodo workshop.
Frequently asked questions
What are quality gates for agentic coding workflows?
They are defined checkpoints where an AI coding agent must produce evidence before its work advances. The workshop uses five: context and standards rules, a written plan, tests, deterministic local verification commands, and pull request review with remediation. Each gate has a defined output the next stage depends on.
Do local checks replace automated code review?
No. Local checks run on the working tree and the diff, while the review service clones the repository temporarily so it can judge a change against the surrounding codebase. Ndukwe treats the pull request review as a separate gate rather than a duplicate one.
Who decides whether a review finding blocks a merge?
The engineering organization sets the severity tier for each rule, and severity determines whether the finding blocks a merge. A docstring rule can block a merge or stay advisory depending on how the team configures it, so the gate is a policy choice, not a fixed behavior.
Should verification run again after automated fixes?
Yes. Any change invalidates the previous check, so verification should run after fixes are applied. Ndukwe calls this best practice, and Codex does not always re-run verification on its own, which is why prompting for it explicitly is safer.
What happens to findings the team does not fix?
They are documented as deferrals. The workflow distinguishes fixes from deferrals and keeps both in the build execution plan, so a pull request can move forward with a written record of what was left out and why.
Can rules be scoped to a single repository?
Yes. Rules are organized natively at the organization and repository level, and the dashboard can filter by scope. Ndukwe confirms that repository-level scoping is supported, which lets teams get granular without sharing every rule everywhere.
How do you know a rule or skill is worth keeping?
The session names Tessell for evaluating a skill's effectiveness and security, and notes that Qodo ingests skills rather than evaluating their quality. A skill can pass review without proving it improves outcomes, so an external evaluation step is the honest answer.
Is there a local option for security-sensitive teams?
Ndukwe said on-premises deployments are available and that banks and some teams at Nvidia require them. That is a statement about available deployment options, not a certification of compliance with any specific regulation, so verify the details with the vendor before assuming a fit.
What is the single most reusable piece of this workshop?
The planning template. A high-level plan plus a build execution plan captures behavior, constraints, skill routing, acceptance criteria, and completion checks in a form any coding agent can read, and it works independently of the vendor used for review.
From workshop recording to written guide
Ndukwe's workshop carried a full workshop's worth of process: five gates, two planning templates, a rule severity model, and a resolver loop that closes with re-verification. That process exists as spoken explanation, repository files, and a live demonstration rather than as a written reference, which is exactly the kind of knowledge that loses detail when it stays inside a recording. If you also publish workshops, walkthroughs, or interviews that carry this kind of operating detail, Skalablog turns a YouTube video into a draft article: paste the URL, generate a transcript, and get a structured draft you can review and publish on your own terms. Skala Blog handles that conversion so the reasoning in the recording does not have to be reconstructed from memory.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits