What is the difference between a coding agent and GIIP FDE Ops?
Published 2026-08-13 · Updated 2026-08-13 · Last Verified 2026-08-13
Answer
The difference isn't how many features each has — it's the unit of work. A coding agent's unit of work is a code change in a repository, and the job is done once the change is merged. An operations service's unit of work is the state of a live production system, and the job is done only as long as that state keeps matching what's expected. That leaves approval of production changes, management of permissions and secrets, the monitoring intake, first response to incidents, rollback mechanisms, audit logs, on-call, and SLAs outside the former's scope.
Applicability of This Document
| Product | GIIP FDE Ops (compared against a general-purpose coding agent) |
|---|---|
| Verified Versions | A design-level explanation independent of product version |
| Environment | AWS, Azure, on-premise |
| Required Permissions | Repository read access for the checks below, plus read access to your monitoring and access-management systems |
| Execution Impact | Read-only (the commands in this article do not change state) |
| Restart | Not required |
| Last Verified | 2026-08-13 |
Ready-to-Run Commands
- 対象
- Your application repository and production deployment
- 権限
- Repository read access
- 変更作業
- None (read-only)
- Production実行
- N/A (run locally or in CI)
# 対象: 自組織のアプリケーションリポジトリと本番デプロイ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（参照のみ）
# Production 実行: 該当なし（手元またはCIで実行）
# 1) 本番ブランチに入った変更が、レビュー（マージ）を経ているか
git log --first-parent --since="90 days ago" --date=short --pretty=format:"%h %ad %an %s" origin/main | head -n 50
# 2) レビューを経ずに直接積まれたコミットが残っていないか
git log --no-merges --since="90 days ago" --pretty=format:"%h %an %s" origin/main | head -n 50
# 3) いま本番で動いているリビジョンを即答できるか
# デプロイ時にコミットハッシュを埋め込んでいなければ、この問いには答えられない
curl -s https://example.com/healthz | head -n 5If you can't answer item 3 — "what revision is actually running in production" — then even if code changes are tracked, the state of production is not. This is the classic point where a coding agent's definition of "done" diverges from operations' definition of "done."
- 対象
- Your operational infrastructure (monitoring, permissions, on-call, audit)
- 権限
- Read access to each system
- 変更作業
- None (checking only)
- Production実行
- N/A (a review exercise)
# 対象: 自組織の運用基盤（監視・権限・オンコール・監査）
# 権限: 各基盤の参照権限
# 変更作業: なし（確認のみ）
# Production 実行: 該当なし（確認作業）
[1] 監視と通知の受け口
- 本番が停止したとき、最初に気づくのは人か仕組みか
- アラートは誰の端末に届き、誰も応答しない場合に次へ渡る仕組みがあるか
- 通知が届く先は個人のアカウントか、退職しても残る共有の受け口か
[2] 本番変更の承認
- 本番への変更に承認者がいるか。承認は記録に残るか
- 承認なしで本番に適用できる経路（手動デプロイ、直接SSH、DB直接接続）が残っていないか
[3] 権限とシークレット
- 本番の認証情報はどこに保管され、誰が参照でき、いつ更新されたか
- 退職・契約終了時に権限を剥奪する手順が文書化されているか
[4] 障害時の一次対応
- 深夜に落ちたとき、最初の30分で誰が何をするかが決まっているか
- 切り分けの手順（どのログを見るか、どのクエリを流すか）が書かれているか
[5] ロールバック
- 直前のバージョンに戻す手順が、実際に試された状態で存在するか
- データベースのマイグレーションを戻す手順があるか
[6] 監査ログ
- 誰が・いつ・何を・どの承認で本番に適用したかを後から再構成できるか
[7] オンコールとエスカレーション
- 一次対応者が判断できない場合の連絡先と判断権限者が決まっているか
- 対応時間の約束（SLA）があり、その根拠となる監視間隔が定義されているか
[8] 複数システムにまたがる影響判断
- あるサービスを停止したとき、連鎖して止まる下流を一覧できるかWhichever of the 8 items above has "no one assigned" is the area that stays blank even after you adopt a coding agent. The more blanks there are, the more code productivity improves without production stability changing at all.
How to Read the Results
| Column | Meaning | What to Check |
|---|---|---|
| Unit of work | A code change in a repository (diff/PR/commit) | The state of a live production system (processes, data, configuration, dependencies) |
| Definition of done | The change is merged and tests pass | The state keeps matching what's expected — there is no single point of completion |
| Approval of production changes | Largely out of scope; depends on human reviewers and merge permissions | Design an approval gate: define and record who approves what, under what conditions |
| Permission and secret management | Out of scope; scanning the repo for leaked keys can be part of it | Operate storage, issuance, revocation, and auditing of production credentials as a standing procedure |
| Monitoring and alert intake | Out of scope; can write the monitoring config code | Operate the actual intake that receives alerts, responds, and escalates when no one responds |
| Incident first response and triage | Out of scope; can propose a hypothesis from pasted logs | Carry out detection through triage to confirming the scope of impact, under time pressure |
| Securing a rollback path | Can revert code; reverting data or schema is out of scope | Prepare a pre-change snapshot and rollback procedure before applying the change |
| Change history and audit logs | Commit history exists, but it is separate from a record of what was applied to production | Record who ran what, when, with what input/output, and under whose approval, at the unit of each production change |
| On-call | Out of scope; only engages once paged | Fill every time slot, including rotation, handover, and backup coverage |
| SLA and escalation | Out of scope | Define response/recovery commitments and the escalation path to a decision-maker |
| Judging impact across multiple systems | Only has visibility within the given repository | Estimate the cascading impact of stopping or changing something, based on configuration and dependency data |
When to Use This
- After adopting a coding agent, development velocity went up, but the number of production incidents and the time to resolve them haven't changed.
- "The code is written" but the work to get it into production never seems to finish.
- No one can immediately answer which version is currently running in production.
- It's undefined who responds to a late-night alert.
- The record of what was applied to production only exists in someone's personal chat history.
Possible Causes (Most Likely First)
01
Comparing things with different units of work as if they differ only in feature count
A coding agent is a tool that completes code changes; an operations service is a duty that keeps a state running. Adding the latter's features to the former doesn't fill in elements that belong to people and organizations, like on-call duty or approval authority.
02
No permission design exists for the production environment
Automating production changes first requires deciding what may be executed under whose approval. Without that design, the safe default is to push everything back to manual work.
03
The alert intake is tied to an individual
If alerts only reach one person's account, monitoring effectively stops whenever that person is unavailable. This is a problem with how the intake is designed, not whether a monitoring tool exists.
04
Rollback stops at "it should be reversible"
A rollback procedure that has never actually been tried only reveals its failures during an incident. Database schema changes and data deletions in particular cannot be undone by reverting code.
Diagnostic Steps
- 1
Check the revision currently running in production
Read-onlyPull the commit hash running in production from deployment records or the app's health endpoint. If you can't, change tracking doesn't actually cover production.
- 2
Check for production changes that bypassed review
Read-onlyUse the git command above to surface commits that landed on the production branch without going through a merge.
- 3
Check whether an audit log exists
Read-onlyCheck whether who ran it, when, what it did, and who approved it can all be reconstructed after the fact for production changes. Missing even one of these makes it an insufficient audit log.
- 4
Check the on-call roster and alert routing
Read-onlyFor alerts from the last month, check who responded and when. An alert with no recorded response may mean no one noticed it.
- 5
Verify that a rollback can actually be performed
MediumIn an environment equivalent to production, run through reverting to the previous version and rolling back a migration once.
Solutions
Low-risk action that can be done immediately
Make the production revision visible
LowEmbed the commit hash and build time in the app at deploy time and have the health endpoint return them. This secures a starting point for tracking.
Consolidate production change approvals into one place
LowReplace chat- or verbally-given approvals with approvals recorded in a PR or a ticket. The goal is to close off any path that leaves no record.
Move alert destinations to a shared account
LowSwitch notifications away from personal accounts to a shared intake that can be rotated among on-call staff.
Change requiring advance review
Close off direct paths to production
MediumConsolidate manual deploys, direct SSH to production servers, and direct connections to the production database into paths that require approval and leave a record. Confirm that existing operational procedures won't break before closing them.
Run rollback procedures as drills
MediumActually perform a rollback multiple times a year and record how long it takes and where it fails. An untested procedure isn't a procedure.
Maintain configuration data to judge blast radius
LowCatalog dependencies between services and the databases/external APIs each service relies on. This removes the need to re-research this every time a shutdown decision comes up.
Work requiring expert review
Audit and redesign permissions and secrets
HighReview where production credentials are stored, who can read them, and how they're revoked. Existing integrations may stop working during this work, so investigate impact first.
Design the scope of automated execution with approval gates
Expert Review RequiredDefine which operations may run automatically and where human approval becomes mandatory. Getting this boundary wrong lets irreversible operations run without approval, so this requires expert review.
!Warnings
- This comparison isn't a knock on coding agents' capabilities. They're an effective tool for the unit of work that is code change — think of this as a division of labor, not a replacement.
- Filling operational gaps involves changing production permissions. Permission changes can break existing integrations, so investigate impact and prepare a rollback procedure before making them.
- The premise that "automation means you don't need people" doesn't hold. Approval, escalation, and judging business impact are matters of accountability, not technical correctness.
- This article organizes design and division of labor — it does not mean adopting any particular product will eliminate incidents.
Differences by Version and Environment
If This Doesn't Resolve It
Re-read the first-response record from a recent incident
Check how many minutes passed from detection to triage, and where it stalled. Wherever it stalled is the gap that needs filling.
Count every path into production
CI/CD, manual deploys, SSH, DB clients, cloud console, admin screens. Identify which of these paths leaves no record.
Check whether a backup is defined for when someone is unavailable
Verify the same procedure still runs when the primary owner is on vacation. If it doesn't, that's reliance on a specific person, not automation.
Check whether monitoring covers "what it takes for the service to actually work"
Verify monitoring looks beyond whether a process is alive, to whether the path users actually take still works.
Basis and Limitations of This Document
Content verified through real-world operations
The comparison table and checklist are a general operational design, independent of any specific product. Only the "GIIP's scope" paragraph describes GIIP's own operating model — it is not a customer case study. Figures such as recovery time, incident counts, or cost savings are not included anywhere, since they cannot be verified.
FAQ
Does this mean coding agents can't be used for production operations?
It's less that they can't, and more that the unit of work is different. They're effective for producing code changes. Keeping production in its expected state, though, requires elements that sit outside the repository — approval, permissions, alert intake, on-call.
If we use both, where should we draw the line?
The practical line is "can it be undone." Code changes and pre-review proposals can be undone. Anything that touches production data, schema, permissions, or secrets is hard to undo, so put it on the side that requires approval and a record.
Do small teams need an approval gate too?
Yes. The smaller the team, the more likely the approver and the executor are the same person. Even then, keeping the form of "write down the procedure and rollback before executing" preserves both the record and reproducibility.
How much should an audit log record?
At minimum five things: who executed it, when, what it did, input and output, and who approved it. With all five in place, you can reconstruct "what happened" after the fact. Missing even one forces root-cause analysis to rely on guesswork.
How far can we let AI handle production operations?
Up to operations where the impact is reversible, the scope is explicitly limited, and a rollback procedure exists before execution. Irreversible operations like data deletion or schema changes should be designed to require human approval. See the article on approval and rollback for automated execution for more detail.
Questions This Document Covers
- Can a coding agent automate operations too?
- After AI writes the code, who handles production operations?
- What's the difference in scope between FDE Ops and a coding agent?
What the Risk Labels Mean
- Read-onlyDoes not change data or settings.
- LowImpact is limited, but permissions and load should be checked.
- MediumMay affect performance, locking, or cost.
- HighMay cause an outage, data loss, or require recovery work.
- Expert Review RequiredRequires a separate review before applying to production.
GIIP's Scope of Support
Everything above is a general design discussion that doesn't assume any particular product. As for where GIIP itself fits in: GIIP has AI agents and human experts continuously monitoring and operating multiple databases and roughly 30 web services on AWS and Azure. AI agents run continuous monitoring and routine checks, while irreversible operations or decisions with business impact are executed only after a human operator approves them. Which of the gaps discussed in this article your organization keeps in-house versus hands off to someone else depends on how you design your own operating model.
Author & Technical Review
GIIP Production Operations Team
About 30 years of experience in designing, migrating, and operating large-scale web services, SQL Server, Oracle, AWS, and Azure. Experience includes 12 sets of x12large-class AWS RDS for SQL Server environments, an Oracle environment with roughly 120,000 tables, and migrating roughly 3TB from TiDB to Aurora MySQL. AI agents and human experts currently continue to monitor and operate multiple cloud databases and about 30 web services.
What it takes to bring an AI-generated application to production
We organize the remaining work between "the code works" and "it can run in production" into 14 items, with commands for detecting hardcoded keys and auditing dependency vulnerabilities.
ai-operationsWhy AI automated execution needs approval and rollback, and how to design for it
Design elements for automated execution — snapshots, approval gates, dry-run separation, allowlists, idempotency, audit logs, staged rollout, and a kill switch — are summarized, along with where to draw the line on what can run without approval.
incident-responseWhat database incidents AI agents can handle, and what humans must decide
We split incident response into phases to separate what AI can own (detection, triage, limited initial response) from what requires human judgment (irreversible actions, shutdown decisions), and provide read-only triage queries.
monitoringWhat to Configure When Monitoring Servers and Databases 24/7
A checklist, organized by layer, of what to monitor, how to think about thresholds, the escalation structure, and why synthetic monitoring is necessary when designing 24/7 monitoring.
Related Services
Map out where the gaps in your operations are, together
If you need to repeat the same checks across multiple environments, we can discuss your entire operations setup.
Map out where the gaps in your operations are, together