Standardize review paths and cut software team waste

Why separate approvals miss the real risk

Teams lose money when every kind of change follows a different approval habit. A pull request gets reviewed, but a Terraform edit, a firewall rule, or a prompt tweak goes live after a chat message. On paper, each part looks fine. In production, users get the whole release at once.

That gap creates blind spots. Engineering often reviews application code because Git makes it easy. Infrastructure changes are more likely to live in scripts, cloud consoles, CI settings, or admin panels, so people treat them as routine operations work. The label does not matter. A small config change can break login, billing, routing, alerts, or storage just as fast as a bad code change.

AI adds another weak spot. A prompt edit can change what users read, what an internal agent decides, or how support replies are drafted. If the team keeps prompts in a dashboard or a note instead of versioned change records, nobody has a clean history. When behavior shifts later, people argue about what changed: the model, the data, or the prompt.

The problem gets worse when each team approves its own slice. Product signs off on prompt changes. Engineering signs off on code. Ops signs off on deployment settings. The release still has no single record that shows how those parts interact.

A release can collect separate approvals like this:

• code review completed
• deployment plan approved
• prompt updated by product
• model setting changed by AI team

Those checkmarks look neat, but they hide the real risk. A reviewed feature may depend on an unreviewed secret rotation. A safe prompt can become unsafe after a model setting changes. A clean deploy can hide an infrastructure edit that doubles cost overnight.

As teams grow, this gets easier to miss. More specialists mean more local rules, more tools, and more chances for someone to assume another team checked the risky part. Oleg Sotnikov saw this firsthand at AppMaster, where the company moved from a full sized team to a much smaller AI augmented operation while keeping near perfect uptime. That only works when every production change stays visible and follows a consistent path.

Teams do not need more meetings. They need one shared record of what changed, who approved it, what might break, and how the team will respond if it does.

Put the right changes into the same flow

Most teams already know how to review code. The trouble starts when they treat everything around the code as separate. A cloud setting, CI tweak, schema migration, prompt edit, or model switch can have the same effect on users as a bad commit.

A simple rule works well: if a change can affect production behavior, customer data, cost, access, or uptime, it belongs in the same flow.

That usually includes application code, feature flags, config files, database migrations, data backfills, cloud settings, IAM roles, secrets, storage rules, prompts, model choices, retrieval settings, tool permissions, deployment jobs, and CI rules that can change what ships. These are all production changes, even when nobody touches the app itself.

Most exceptions should stay narrow. A typo in an internal note does not need full review. A comment only edit usually does not either. But once a document changes a runbook, a security step, or customer facing behavior, it stops being harmless.

This is where many teams waste time. They keep asking, "Does this count?" That question should not come up ten times a week. A shared approval workflow for software changes works best when people already know the answer before they ask.

One quick test helps. Ask two questions:

• Can this affect users?
• Can this be hard to undo?

If the answer to either question is yes, send it through the same review path.

That rule is plain, easy to teach, and hard to argue with.

Rate risk by impact, not by team

Department names do not tell you much about danger. A copy update, a cloud setting change, and a prompt edit can all ship on the same day. One is harmless. One locks users out. One exposes private data. The team name attached to the work does not help. Impact does.

This is why separate habits across engineering, ops, and AI teams create so much friction. One group asks for three approvals on a safe change. Another pushes a risky change after a quick glance. A better approach is to use the same risk labels across every change type.

A simple model is enough:

• Low risk: text edits, comments, small visual fixes, logging changes, internal docs, and config changes with no production effect.
• Medium risk: routine feature work, normal infrastructure updates, and prompt edits that do not touch sensitive data or user permissions.
• High risk: authentication, billing, permissions, production database changes, API behavior, data access rules, and anything that affects stored data or trust.

Then tie each level to one approval rule. Low risk moves through a fast lane with one reviewer. Medium risk gets one reviewer plus automated checks. High risk gets a second reviewer, a rollback plan, and a named owner who watches the rollout.

This works better than routing by department because risky work often crosses boundaries. A model swap may start as AI work, but it also changes cost, latency, and output quality. A small auth update might begin in code and end in infrastructure. If both changes carry the same label, the team gives both the same level of care.

Growing teams usually feel the benefit fast. Safe work stops waiting behind heavy process. Risky work gets more attention. Arguments about who owns approval start to fade.

Build a path people will actually follow

Review rules fail when people have to remember five different paths. If you want consistency, make the process boring. Nobody should need a cheat sheet to figure out what happens next.

Start by listing every place where someone can change production behavior. Most teams catch code merges and miss everything around them: feature flags, environment variables, cron schedules, cloud settings, prompts, model routing, tool permissions, billing settings, queue limits, and access rules. If a customer can feel the change, it belongs in the same review system.

Next, keep the labels plain. Low, medium, and high risk are enough. Fancy categories slow people down because nobody agrees where the line is. You do not need perfect sorting. You need sorting that people use the same way every day.

Use one short template for every change type. A code, infrastructure, and AI review process should ask the same basic questions every time:

• What changed?
• Why did it change?
• Who might notice?
• How will we check the result?
• How do we roll it back?

That last question gets skipped too often. If there is no rollback, say so before approval. A risky release with no easy undo can still move forward, but the reviewer should see that risk clearly before it ships.

It also helps to assign one owner and one backup reviewer for each risk level. That cuts a lot of waiting. When the main reviewer is out, the process keeps moving instead of stalling in chat.

Finally, keep the record in one place every time. A pull request, a ticket, or a release note can all work. The tool matters less than consistency. When something breaks on Friday night, nobody wants to search three systems to figure out who changed the prompt, who edited the firewall rule, and what the rollback plan was supposed to be.

What shared review looks like in practice

Picture a small SaaS team planning a Friday release. It seems straightforward.

A developer fixes billing code for a coupon edge case and changes one cloud setting so the billing worker can reach a new service. At the same time, an ops teammate raises queue limits because retries have started piling up during busy hours. A product manager updates the support bot prompt so refund questions point users to the new billing flow instead of the old one.

If those changes move through separate approvals, each person checks only one part. Engineering reads tests and code. Ops looks at capacity. Product checks bot replies. Nobody sees the combined risk.

Customers do not experience changes one by one. They hit the whole release at once. A user asks the bot for help, enters the new refund path, triggers billing logic, and adds load to the queue. If retry behavior is even slightly wrong, the team can end up with duplicate charges, delayed confirmations, or a flood of support tickets.

One shared approval note makes that risk visible. It does not need to be long. It should say what changed across code, infrastructure, and AI behavior, who reviewed each part, what might fail first, what the team will watch after release, and who owns rollback if something breaks.

For this example, the note might say that billing rules changed for coupon handling, queue limits increased from 200 to 400, and the bot now routes refund users into the new flow. It should also call out the real concern: if bot traffic rises faster than expected, retries could spike and billing might process the same request twice.

That is the point of standardizing review paths. Teams stop treating code, infrastructure, and prompts as separate worlds. They review the release people will actually feel.

Common mistakes that break the system

Most review systems do not fail all at once. They fail through exceptions.

One team gets a special rule. Another gets a shortcut for urgent changes. A third keeps using chat because "it is just a prompt update." A few months later, nobody remembers which changes need one approver, two approvers, or none at all. People guess, and risk hides inside that guesswork.

A common mistake is giving more weight to departments than to the change itself. A prompt edit can look like a few harmless words, yet it can change outputs, costs, tone, permissions, or what data the model sees. If code needs review and prompts do not, the team has created a blind spot on purpose.

Infrastructure often falls into the same hole. Teams label Terraform, CI settings, container configs, or access rules as "ops work" and move fast. Users do not care which team touched the file. They only notice downtime, slow pages, broken login, or a surprise bill.

Another weak spot is approval with no rollback note. Teams review whether the change should work, but they skip the question that matters when it does not: how do we undo this in five minutes? A short rollback plan can stop one bad release from turning into a two hour scramble.

Urgent requests spread the mess even faster. A manager pings someone in chat, the change goes live, and nobody records who approved it. Fast action is fine in a real incident. Missing records are not. Even emergency changes should get a short entry afterward with the reason, the approver, and the follow up review.

A few rules prevent most of this:

• Judge changes by possible impact, not by team name.
• Review prompts, infrastructure files, and code in the same system.
• Ask for a rollback note before approval.
• Record every exception, including urgent ones.

If a change can affect users, uptime, security, or cost, it belongs in the same path.

A short change approval checklist

Approvals should feel boring. If a team needs a long meeting to decide whether a change is safe, the review path is already too heavy or happening too late.

A good check is short and direct. Before code ships, an infrastructure setting changes, or an AI prompt reaches real users, the team should be able to answer a few plain questions.

• What is the user impact in one sentence?
• Does it touch money, data, access, or uptime?
• How fast can we roll it back?
• Who looked at how it might fail, not just how it should work?
• Will logs or alerts show trouble quickly?

These questions catch more than people expect. A developer might change account roles to simplify onboarding. That sounds minor. But if the update affects admin access, audit logs, and customer permissions, the risk is much higher than the ticket title suggests.

The same test keeps review fair across teams. A code change, a Terraform edit, and an AI workflow update all face the same questions: who does this affect, what can break, how fast can we undo it, and how quickly will we know.

If the answers are clear, approval is easy. If the answers are fuzzy, stop and tighten the change before it ships.

Keep the process lean as the team grows

Growth usually breaks review systems in a dull, predictable way. The team adds one template for ops, another for security, then a separate path for prompts or model changes. Soon people spend more time picking the right form than checking the change itself.

A better rule is simple: keep one intake form for code, infrastructure, and AI work. Ask the same questions every time. What changed, who owns it, what can fail, how do you roll it back, and does it touch users, data, or money?

Low risk work should move fast. If a change only updates copy, fixes an internal typo, or tweaks a dashboard that cannot affect customers, one reviewer is usually enough. Teams lose hours when they ask three people to approve work that carries almost no release risk visibility concern.

When changes ship together, review them together. If a feature needs a code update, a database migration, and an infrastructure change, split reviews create blind spots. One person approves the app, another approves infrastructure, and nobody checks how the release behaves as a whole.

It also helps to prune the process on purpose. Once a month, look at exceptions and skipped steps. If a required approval has not caught a real issue in six months, question whether it belongs there. Keep the checks that catch mistakes. Cut the ones people click through on autopilot.

This is where teams often save real money. Less admin work, fewer handoffs, fewer missed dependencies, and fewer late surprises. It is also the kind of operating discipline Oleg Sotnikov works on through oleg.is as a Fractional CTO, especially for smaller companies trying to tighten engineering, infrastructure, and AI delivery without adding more process than they can actually use.

Start with one release this week

You do not need a full redesign to fix this. Start with one plain document.

List every review path your team uses today, including the messy ones people follow out of habit. Include code changes, infrastructure updates, model or prompt changes, emergency fixes, and anything else that can affect users, cost, or security. That exercise usually exposes the real gap right away. Many teams review application code carefully, then let a Terraform change, a new model setting, or an automation script go live through chat.

Then test a shared path on the next release. Use one ticket, one risk label, one place for approval, and one record of what changed. Keep the trial small enough that people will actually do it.

If the test feels slow, cut steps before the team starts dodging the process. Most teams need fewer branches, not more. A short path that everyone follows beats a perfect diagram nobody uses.

If you want an outside view, Oleg Sotnikov can review where your approval logic is split, where AI or infrastructure changes bypass review, and how to simplify it without losing control. In many teams, the waste sits in the rules, not the software.

The best next step is the one your team can run this week with real changes and real consequences.