Giving engineers access to an AI coding tool does not establish a shared way of using it. Teams also need standards for task definition, review, verification, and accountability.
Current's work training a public company's engineering organization focused on those practices. The lesson was to treat agentic development as a team workflow, with expectations that reviewers and maintainers can apply consistently.
Teach specification before prompting
A useful task brief describes the intended behavior, relevant context, constraints, and acceptance criteria. Engineers should also state what evidence will demonstrate that the change works.
For example, “add account search” leaves many decisions implicit. A better brief identifies which users can search, which fields are searchable, what happens with no results, and how access restrictions must be preserved.
Breaking work into reviewable changes makes it easier to identify mistakes and recover from them. The agent can help refine the brief, but the engineer still needs to understand the intended result.
Make review a skill the team practices
Review agent-written code against the requirement, not against the agent's explanation of what it did. Inspect the diff and verify the evidence directly.
Training exercises should include plausible changes that are wrong: an authorization check in the wrong layer, a test that misses the important boundary, or a dependency added without a clear need. These are useful exercises because they demand engineering judgment rather than familiarity with a particular tool.
Review remains more than checking syntax. Engineers need to assess architecture, maintainability, security, and operational behavior.
Put shared standards in the workflow
Use repository guidance, review requirements, and automated checks to make expectations visible. Restrict access to secrets and production systems according to the task. Require meaningful validation before a change is accepted.
A green pipeline is evidence, not proof of completeness. Tests can reproduce an implementation's mistake, and an agent's summary can omit a failure. The engineer responsible for the change must reconcile those signals.
Measure delivery quality, not tool activity
Track how work moves from a defined task to a reliable release. Useful measures include lead time, review effort, rework, and defects that escape into production.
Pull request counts can provide context, but they are a poor standalone target: splitting work into smaller changes can increase the count without increasing value. Compare similar work and examine whether improvements persist after the training period.
The original engagement established shared practices for agentic development. We do not publish a quantified productivity uplift for it; the useful takeaway is the operating discipline teams can apply.
Turn training into normal engineering practice
Use exercises drawn from the team's work, coach reviewers as well as authors, and update guidance when recurring failure patterns appear. Training should help the organization explain what good agent-assisted engineering looks like.
Read how Circuit connects requirements to delivery, or explore our organizational change and upskilling work.
