Bringing AI into the team
An AI assistant can help an engineer finish a change faster. Whether that change reaches production sooner depends on what happens next: review, testing, integration, and release. If the pull request waits three days for someone who understands the affected service, faster implementation has changed only one part of the delivery process.
That is where introducing AI into an existing team becomes interesting. A coding tool enters a system of dependencies, conventions, and decisions. Some are visible in the repository. Others exist in conversations, operational experience, or the judgement of a few people. As AI takes on more work, those dependencies become part of the integration problem.
Question as task distance #
Consider a test that passes on its own and fails when the full suite runs. An engineer can paste the test and failure output into a conversation and ask for possible causes. Shared state, execution order, and incomplete cleanup are reasonable hypotheses. The engineer can inspect the fixtures, run experiments, and decide which explanation fits the evidence.
Much of the context stays with the person. They know which test command actually works, which failure is unrelated, and whether a proposed change conflicts with a convention elsewhere in the codebase. They can reject an answer immediately because they remember an earlier incident the model has never seen.
Give the assistant access to the repository and a shell, and the interaction changes. It can search for shared fixtures, run the failing suite, modify setup code, and observe the result. A suggestion becomes a sequence of actions. The engineer can still direct each step, but the tool is now participating in implementation.
Delegating the whole task moves more decisions into that sequence. The agent has to decide where to investigate, whether a failure is relevant, when a fix is sufficient, and when it needs help. “Make this test pass” leaves room for changes that defeat the purpose of the test. The intended outcome includes preserving what the test was supposed to establish.
As a person delegates more of the execution, more of their understanding has to become available through code, documentation, tools, and explicit decisions.
Repository as part of the interface #
A human developer can work around a surprising amount of missing information. They ask a colleague how to start the database, borrow a configuration file, or learn that one CI job has been failing for weeks. Over time, these workarounds become ordinary parts of the job.
An agent encounters the same repository through the information and tools it can access. If the documented test command is obsolete, it may spend its time diagnosing the environment. If two modules implement different conventions, it needs some basis for choosing between them. If an issue says “use the usual error format,” that format has to be discoverable somewhere.
This makes repository preparation a substantive part of adoption. Build commands, test fixtures, API contracts, and architecture notes affect the quality of the work an agent can complete. A reliable setup lets a run begin from a known state. A regression test gives it a way to observe the reported defect. A documented compatibility requirement can explain why an apparently simpler implementation would be wrong.
Access introduces another set of engineering decisions. An agent that can edit a working copy has different consequences from one that can publish a package or alter a production database. Credentials and execution environments determine that reach. Instructions describe the intended task; the surrounding system determines which actions are possible.
These concerns become more significant when a task runs while its owner is doing something else. The agent needs a way to stop with an unresolved question, and the engineer needs enough evidence to understand what happened without replaying the entire session.
Review problem change #
Suppose an agent produces a patch and tests. The tests pass. That result establishes something useful, but its strength depends on the tests themselves.
For example, a request validator might reject negative quantities correctly while also rejecting zero, even though zero is valid for an existing client. Tests written from the same mistaken assumption as the implementation can agree perfectly with the code. Review still needs a source of expected behaviour: an API contract, existing compatibility tests, or a product decision.
A separate review agent can help examine the change. It also needs access to that source. Two agents given the same incomplete requirement may repeat the same mistake. Separate runs create opportunities for another examination; the quality of that examination depends on the evidence and criteria available to it.
The same issue appears in other roles. A testing agent needs an environment where a failure can be reproduced. An agent analysing requirements needs a way to expose a decision that belongs to the product owner. An operational agent needs to distinguish an observation in telemetry from a hypothesis about its cause.
Review, testing, requirements, and operations individually produce a different results. Their usefulness has to survive contact with the people who receive those results.
Delivery system #
Once several roles are useful, connecting them is an understandable next step. An issue leads to an implementation, CI runs, a review identifies a problem, and the implementation agent revises the patch.
Even this small workflow has state to manage. A review refers to a particular commit. Once the agent changes the code, some earlier findings may be resolved and some checks may need to run again. A restarted task may discover an existing pull request. A failed test may indicate a defect, an unavailable dependency, or a broken execution environment. Each case calls for a different response.
The workflow therefore needs a durable account of what has happened: which revision was tested, which findings remain open, and which decision is blocking progress. Retry limits, cancellation, and recovery become ordinary parts of the design. These details determine whether the team can operate the automation when a run goes wrong.
Extending that workflow into release and production adds consequences beyond the repository. A deployment can pass its technical checks and still arrive at an unsuitable time. A rollback can restore application code while leaving a database migration in place. Production feedback can suggest a change whose business impact requires discussion.
Automating across the lifecycle means deciding how these situations are represented and who has authority to resolve them. Different teams will draw those boundaries in different places, and different tasks within one team may follow different paths.
The starting point is a conversation: what information makes it useful, how to test the reasoning it produces, and how that interaction prepares the ground for work an agent can carry further.