🔁 Workflow & Quality

Real process events that can trigger automatic work: approved issue, CI failure, vulnerable dependency, open PR, coverage drop, API change, incident, production error.

Automation without a clear event becomes a bot running for no reason. The trigger defines the value: the more predictable the event, the more reliable the automation.

Event → classification → agent → validation → decision → delivery · Not every event is worth automating.

Connect the agent to the tools where the work happens—issue tracker, repository, CI/CD—instead of creating a parallel workflow in some chat.

Automation that lives outside the team’s workflow dies in two weeks. Inside the PR, it’s seen, reviewed, and held accountable.

The PR is the review surface · Event→change traceability · The agent has its own identity in the systems.

A pipeline failure starts an automated investigation: the agent reads the log, reproduces the issue locally, proposes a fix, and opens a PR with evidence.

It’s the ideal case to start with: the trigger is objective, the verifier already exists (CI itself), and the result is reversible.

Ready verifier = safe automation · Propose in a PR, never push directly · Intermittent failure requires diagnosis, not a blind retry.

A vulnerable dependency triggers an update proposal, with the agent reading the changelog, adjusting broken code, and proving the fix with tests.

It’s recurring, tedious, well-defined work — exactly the kind of work that’s worth automating first.

Breaking change requires reading the changelog · Updating without testing is a gamble · One dependency per PR.

An incident triggers an automated initial diagnosis: log collection, timeline correlation, suspected recent changes, and ranked hypotheses.

In the first few minutes of an incident, the bottleneck is gathering information. That’s where AI helps a lot—and applying a fix on its own is where it gets in the way.

Initial diagnosis is safe; mitigation in production is not · Preserve evidence before making changes · A prioritized hypothesis speeds up the human.

The cutoff criterion: automate what is frequent, verifiable, and reversible; require approval for anything involving production, databases, infrastructure, permissions, and security.

Without this explicit cutoff, automation grows until it touches something nobody wanted it to touch—usually on a weekend.

Not every task should be autonomous · Frequency × risk determines the level · Automation needs an owner too.

A review agent can explore related files, verify contracts, analyze tests, find duplications, and compare against repository standards—not just look at the changed lines.

Expensive defects are rarely in the changed line; they’re in how it interacts with the rest of the system.

Diff is the starting point, not the scope · Semantic duplication only shows up in a search · The repo's conventions are a criterion.

The recommended flow: implementation agent → deterministic tests → independent review agent → security analysis → quality gates → human review.

The reviewing agent shouldn’t rely on the implementer’s conclusions—the separation reduces the risk of both repeating the same incorrect assumption.

Independence > capacity · Reviewer gets the spec + diff, not the author's reasoning · Clean context for each review.

The check that the change respects module boundaries, doesn't create improper dependencies, duplicate existing capabilities, or bypass layers.

It’s the kind of defect no test catches and that becomes costly six months later.

A boundary violation is a review finding · Semantic duplication > textual duplication · An architectural rule can become a test.

Explicitly reviewing security failures, performance impact, and future maintenance costs—each with its own checklist.

A generic reviewer (“review this PR”) finds style issues. A reviewer with a defined focus finds what hurts.

One lens per pass · Exposed secrets and injection are blockers, not suggestions · Maintenance is a real future cost.

What the automated reviewer can’t see: business intent, historical context, unwritten agreements—as well as its tendency to generate large volumes of low-value comments.

A reviewer who comments on thirty trivial things per PR trains the team to ignore reviews — including good ones.

Precision > recall in review · Findings without severity are noise · False positives cost trust.

Human review focused on what only a human can decide: intent, priority, business risk, and acceptance of the consequences.

AI filters and prepares; responsibility remains with whoever approves. This isn't a formality — it's what keeps someone thinking about the problem.

Responsibility cannot be delegated · Humans review intent, machines review form · A small PR is truly reviewable.

The central principle: a rule written in text is useful; the same rule turned into an automated test is much more reliable.

With AI generating volume, rules that depend on someone remembering stop working during the first busy week.

Gate = mandatory condition, not a recommendation · Automation > discipline · Code advances only if it passes.

The first three gates: it compiles, follows the conventions, and unit and integration tests pass.

These are the gates the agent can use on its own within the loop—the faster they are, the more useful the automatic correction cycle.

Slow tests don’t belong in the loop · Flaky tests destroy trust · Automatic linting eliminates style debates.

Tests that lock down the contract with API consumers, plus a minimum coverage threshold that blocks drops.

As the volume of changes grows, the contract is the first silent casualty—and the customer is the one who finds out.

Coverage is a floor, not a target · Preserving the contract is required · A drop in coverage blocks the merge.

Automatic checks for critical vulnerabilities, committed secrets, dependencies with CVEs, and dangerous code patterns.

These are objective, high-cost findings—the perfect kind of rule to turn into an automatic block, without depending on an attentive reviewer.

Never put secrets in the repository · Critical vulnerabilities block progress · Scanner noise needs calibration.

Performance gates within an agreed limit and the requirement that every migration have a tested rollback path.

Degradation creeps in, one change at a time; and an irreversible migration is what turns a small mistake into a long incident.

Explicit performance budget · Reversible migration is a gate · An untested rollback doesn’t exist.

The complete pipeline: build → lint → tests → coverage → static analysis → security → review → approval → deploy. Code only moves forward when all required gates are met.

A gate that can be skipped “just this once” isn’t a gate—it’s a suggestion. And the exception becomes the rule in two weeks.

Required means required · Exception documented with a deadline · The gate protects the team; it doesn’t get in the way.