AI can write code. Teams still need to review and decide together

Suppose one AI changes a purchase-order approval screen while another changes the authorization service. Both return passing tests. Once the changes are combined, managers can no longer approve orders: the screen still sends the company identifier under the old field name, while the service expects a renamed field.

The team could restore the button by skipping the company check when the new field is missing. That quick fix could let someone approve an order for a company they are not authorized to act for. This is a hypothetical situation, not a customer incident or a system I have deployed.

The speed of each task leaves a question unanswered: will all this work fit together? My view is that the faster AI helps us build, the more deliberately a team needs to bring the work together, inspect assumptions, and make shared decisions.

The earlier article asked whether a working demo was ready for other people to use. This follow-up asks what happens across a team. When several people delegate to AI at once, how do those streams of work become one system that people can maintain?

Agree on the boundary before splitting the work

An integration point is a moment when the team checks work from different sources against a shared agreement, with evidence and someone able to make the next decision. It might be a short conversation, an automated test, or a review by someone authorized to accept a particular risk.

For our purchase-order example, the team should first agree who may approve, which amount determines authorization, and what must be checked again if the amount or company changes. Then it can define an API contract: what the screen sends, what the service returns, and how a denied request is handled.

The contract must cover meaning. Matching field names can still hide incompatible assumptions. One side may interpret "manager" as permission to approve for every company; the other may mean a manager for the company on that order. Hiding a button helps guide the user. The service receiving the request must derive permissions from the authenticated user and check access to the requested record, rather than trusting a role sent by the screen.

Put the agreement somewhere both people and agents can reference, and define how it changes. If someone revises the contract midway through the work, the team needs to identify affected changes, reviewers, and any temporary compatibility requirement. A daily meeting cannot replace an agreement people can find and test.

Keep changes small enough to understand

AI can produce more code than a reviewer can comfortably absorb. A large submission makes it harder to see where the business rules changed. Prefer a pull request (PR) with a coherent reason for existing, such as changing one authorization case and explaining its effect on callers. Combining interface, authorization, and schema changes needs a reviewable boundary.

DORA describes small batches as a way to get feedback and revisit assumptions quickly. I would judge a useful batch by whether a reviewer can understand its consequences, rather than line count alone. Splitting a change into tiny PRs that cannot be tested or used independently still leaves the team responsible for their integration order.

Component tests need to be followed by tests across the boundary. In this example, send the screen's actual request format to the real service in a test environment. Check authorized and unauthorized users, including a user from the wrong company. Tests that replace the service with the same old canned response may miss a contract mismatch.

I would want the PR to state the rule used, the changes made, the checks actually run, and the remaining unknowns. A reviewer should not have to reconstruct an entire AI conversation to discover what "done" means.

Give reviewers context and the authority to stop

A person's review is useful when it asks questions the tests may not yet address. Should this permission exist? Should this group see this information? Which existing workflow changes as a result? Clicking Approve without understanding the scope adds no evidence.

GitHub can require reviews and passing checks before merging. A team still needs to configure those rules for its work, consider who can bypass them, and decide how changes made after review trigger another review. A platform feature does not establish that every repository uses it.

Agents should also receive only the access needed for their task. Separate the ability to read, propose changes, merge, and release according to risk. Where an account or environment can enforce a boundary, a prompt saying "do not do this" should not carry that boundary alone.

A change owner, reviewer, and release owner may be the same person on a small team. It should still be clear which decision that person is making. Another person's approval does not transfer all accountability away from the person doing the work. Saying "AI wrote it" does not remove it either.

Familiar practices work when people can speak up

Agreeing before starting, reviewing together, and handing work to the people who will operate it are established teamwork practices. AI gives us a reason to take them more seriously: new work can arrive faster than people can understand it.

A team needs a shared definition of done at the appropriate level. A wording change may need a meaning and display check. A purchase-order approval change should bring evidence about authorization, integration, and data effects, along with someone responsible after release. This agreement tells contributors what to deliver and helps reviewers avoid changing expectations afterward without explanation.

Review culture matters. If saying "I don't understand this consequence yet" makes someone look obstructive, doubts may stay hidden until users encounter them. I would want reviews that question assumptions and evidence, allow reviewers to be wrong, and recognize people who find problems early.

DORA links a high-trust culture with good information flow to software delivery performance. That supports asking how quickly bad news reaches the people who can act. It does not guarantee that holding more meetings improves a team. Psychological safety should help people report mistakes, alongside clear ownership of the response.

A green dashboard answers a limited question

An Argo CD screen showing Healthy and Synced tells us something about deployment state. Those labels have a specific scope. Synced means the live state matches the target state as Argo CD compares them. Healthy comes from the relevant resource health assessments, which depend on resource types and configuration.

An application can show those statuses while applying the wrong spending limit or authorizing the wrong person. The change needs additional business and security evidence. A manual Sync control, or a merged PR, does not establish that every approval took place or that recovery was tested. One screenshot cannot establish production readiness.

Before release, test the intended version in staging, a preparation environment, under conditions representative of the risky part of the change. Record the differences from production. The release owner should decide from the evidence, with more to go on than a status color.

Know what can stop and what can be reversed

An incident runbook should say where to stop new actions after an unauthorized approval, who responds, which evidence identifies affected records, and who decides between rolling back and fixing forward. The person on call should be able to follow it without finding whoever wrote the first AI prompt.

Rolling back an application does not roll back its data. If a new version changes a database schema, removes a field, or sends a purchase order externally, old code may no longer work or may leave effects that need separate correction. Test migration compatibility, plan the sequence carefully, and obtain evidence that data can be recovered within the required scope. Possessing a backup file alone does not show that recovery will meet the business's time constraints.

Argo CD's documentation says rollback cannot be performed on an application with automated sync enabled. The incident procedure therefore needs to fit the team's sync policy and source of desired state. Selecting an older revision does not automatically reverse database changes or external transactions. That latter limit is an engineering reason to design a separate recovery plan, not a capability established by a dashboard.

After release, return to the actual outcome. Alongside technical failures, look for events that matter to the workflow: unusual approval rejections, users unable to continue, or records entering states that violate the agreed rules. Collect only necessary information, restrict access, and feed findings back into the agreement and tests.

Put decisions where the risk warrants them

An integration point does not always require someone to click an approval button. Low-impact work with dependable automated evidence and a workable recovery path may proceed under an agreed policy. Changes to authorization, sensitive data, or effects that are difficult to reverse deserve review by someone who understands the consequences and can make the decision.

If everything waits for one person, the queue grows and that person has less time for each review. Revisit which checks uncover real problems, which duplicate existing evidence, and which decisions still have no owner. Removing steps solely to ship faster is a poor reason; adding steps without knowing the question they answer is poor process too.

For the next change, choose one boundary where work from two people or agents meets. Write down the agreement, the evidence that the parts fit, who decides when they do not, and who listens to users after release. Those answers help a team use AI's speed while continuing to understand one another's work.

Reading and scope

This article proposes a way of organizing team work, following the demo-to-pilot discussion on this website. Official Argo CD and GitHub documentation establishes the limits of the tools discussed; DORA provides context for small batches and team culture. The purchase-order example, diagram, and table were created to explain the argument. They are not reports of a deployed system, test results, or certification of any system's security.