How AI supports our development workflow

From scheduled backlog work and model cross-checks to behavior-driven tests, test deployments and final engineer approval.

AI is useful when it operates inside a well-designed development system. It can take on implementation, analysis, documentation and routine testing, but it does not own the architecture, product trade-offs or release decision.

Our workflow gives agents enough context and freedom to produce meaningful work while keeping every important decision reviewable. The objective is not to generate more code. It is to shorten the path from a clearly described need to maintainable software that an engineer is prepared to stand behind.

From backlog to production

  1. Work starts in a structured backlog. Each ready task describes the intended behavior, relevant context, constraints and what “done” means. Scheduled agents inspect that queue and pick up eligible work without waiting for someone to copy the task into a chat.
  2. The agent works from the codebase, not from an isolated prompt. Before changing anything, it reads the repository instructions, existing architecture and nearby implementation patterns. It then makes a scoped change and runs the checks defined for that project.
  3. Expected behavior becomes evidence. New behavior is expressed through examples and automated tests. A confirmed bug starts with a reproducible case and, where practical, a failing regression test before the implementation changes.
  4. Another model challenges the result. A separate review pass looks for incorrect assumptions, edge cases, security concerns, maintainability problems and missing tests. This cross-check can find issues early, but it is evidence for the reviewer—not an approval.
  5. The candidate is deployed to test. Continuous delivery builds the agent’s branch and places it in an isolated test or preview environment. The change can be exercised as running software before it is merged.
  6. An engineer reviews the complete change. The engineer reads the diff, the tests and the model-review findings, then checks the deployed behavior. They can request changes, reject the approach or approve it. No agent approves its own work.
  7. Only approved work moves forward. After the human gate, the same automated pipeline produces the releasable artifact and promotes it through the agreed production process.

The codebase is the instruction manual

Useful agent instructions are versioned beside the code. They describe architectural boundaries, naming and import conventions, component patterns, accessibility expectations, data-handling rules, test commands and acceptance checks. Project-specific decisions stay close to the project instead of living in somebody’s prompt history.

This matters because code written quickly can still be expensive to own. Agents are expected to follow the same standards as an experienced contributor: prefer existing abstractions, explain non-obvious decisions, avoid unnecessary dependencies and leave code that another person can read and change. If a task conflicts with the architecture or requires a product, security or privacy decision, the agent must surface that decision rather than improvise it.

Clear instructions also make reviews more objective. The question is not whether a reviewer likes the generated code. It is whether the change follows the documented system and satisfies the behavior agreed for the task.

Review is layered, not delegated

Automated checks answer deterministic questions: does the project type-check, do the tests pass, does the build complete, and does the change comply with the repository rules? A second model can then review the implementation from a different angle and call out suspicious logic or gaps in the evidence.

The engineer performs the final review after those passes. They judge whether the solution belongs in the architecture, whether the trade-offs make sense for the product and whether the test suite proves the right behavior. Architecture, security-sensitive choices and release approval remain human responsibilities even when much of the preparation is automated.

Environments define the limits of automation

Development

Agents may inspect the repository, implement scoped changes and run the project’s checks on their own branch. The work remains disposable and isolated from users while it is being shaped.

Test and preview

Test environments are where the feedback loop becomes automatic. A bug report can enter the backlog with its environment details, logs and reproduction context. An agent can triage it, reproduce it, add regression coverage, implement the fix, run the checks and deploy its candidate back to an isolated preview. The updated behavior is available for verification without giving the agent a path to production.

Production

Production is a separate authority boundary. Agents do not make direct production changes or promote their own work. A reviewed merge and an explicit engineer-approved release are required before the delivery pipeline can deploy the tested artifact.

Behavior drives the tests

Behavior-driven development gives people and agents a shared definition of success. Concrete scenarios describe what should happen from a user’s or system’s point of view before implementation details take over. Those scenarios become acceptance checks and, where useful, executable tests.

They sit alongside a broad automated suite: focused unit tests for business rules, integration tests for boundaries between systems, and end-to-end tests for critical journeys. Every confirmed defect should strengthen that safety net with a regression case. Tests are not a coverage performance; they are the executable record of what the product promises to do.

That record is what makes AI-assisted changes safe to repeat. An agent can move faster because failures are visible, reviewers can see the evidence, and future contributors can change the system without reconstructing every old decision.

Continuous delivery without continuous risk

Continuous delivery keeps changes small, reviewable and ready to release. Every candidate goes through the same build, test and preview process, so production is not the first place where the pieces meet.

Automation removes waiting and repetitive hand-offs. It does not remove accountability. Agents keep the queue moving, models broaden the review, tests protect the agreed behavior, and engineers remain responsible for what is merged and what reaches users.