When to Override the AI: A Platform Engineer's Guide to Maintaining Architectural Judgment Under AI Acceleration

The Coinbase outage is the clearest recent illustration of this: nearly ten hours of trading downtime traced back to a missing automated zone failover — not a complex bug, but a gap in operational assumption that nobody stress-tested under the actual failure mode. When AI tooling accelerates infrastructure provisioning, it can just as easily accelerate the propagation of that same class of unchecked assumption. The suggestion looks complete, the Terraform plan passes, the deployment succeeds — and the reliability hole is now in production. Source: [Reliability fail: No automated zone failover for Coinbase's global trading service] — Gergely Orosz (https://blog.pragmaticengineer.com/coinbase-fail/)

AIA useful decision heuristic for platform teams: treat any AI-generated infrastructure or architecture suggestion as a speculative draft that needs verification against three axes — failure mode coverage (what breaks and how does the system recover), observability surface (can you see what's happening when it misbehaves), and operational ownership (does your team actually understand this well enough to debug it at 2am). If the answer to any of those is unclear, the suggestion needs human elaboration before it gets committed.

// TypeScript: lightweight override decision evaluator for platform review pipelines

type OverrideAxis = 'failureModes' | 'observability' | 'operationalOwnership';

interface OverrideCheck {
  axis: OverrideAxis;
  passed: boolean;
  rationale: string;
}

function evaluateAISuggestion(checks: OverrideCheck[]): {
  decision: 'accept' | 'override' | 'augment';
  gaps: OverrideCheck[];
} {
  const gaps = checks.filter(c => !c.passed);

  if (gaps.length === 0) return { decision: 'accept', gaps };
  if (gaps.length >= 2) return { decision: 'override', gaps };
  return { decision: 'augment', gaps };
}

// Usage in a code review automation hook
const result = evaluateAISuggestion([
  { axis: 'failureModes', passed: false, rationale: 'No zone failover defined' },
  { axis: 'observability', passed: true, rationale: 'CloudWatch alarms present' },
  { axis: 'operationalOwnership', passed: false, rationale: 'No runbook linked' },
]);

console.log(result.decision); // 'override'
console.log(result.gaps.map(g => g.rationale));

The MTP approach Google ships on Pixel is architecturally elegant because the acceleration never comes at the cost of correctness — the frozen main model acts as the arbiter, and speculative tokens that diverge from it are discarded. The model doesn't retrain to be faster; it adds a verification layer on top. That's the pattern worth borrowing. Source: [Accelerating Gemini Nano models on Pixel with frozen Multi-Token Prediction] — Google Research (https://research.google/blog/accelerating-gemini-nano-models-on-pixel-with-frozen-multi-token-prediction/)

AIPlatform teams that have shipped AI-assisted development tooling successfully tend to have done something equivalent — they haven't removed human architectural review, they've made it faster and more targeted. The AI generates the speculative draft, the senior engineer pattern-matches it against known constraints, and the override happens at the point of divergence rather than after the fact. The failure mode to avoid is treating the verification layer as optional overhead when velocity pressure is high.

// TypeScript: frozen architecture verifier — checks AI proposals against codified constraints

interface ArchConstraint {
  id: string;
  description: string;
  test: (proposal: Record<string, unknown>) => boolean;
}

const frozenConstraints: ArchConstraint[] = [
  {
    id: 'zone-failover',
    description: 'Multi-AZ failover must be explicitly configured',
    test: (p) => Boolean(p['multiAzEnabled'] && p['failoverPolicy']),
  },
  {
    id: 'observability-required',
    description: 'All services must declare a metrics endpoint',
    test: (p) => typeof p['metricsEndpoint'] === 'string',
  },
  {
    id: 'runbook-linked',
    description: 'Operational runbook URL must be present',
    test: (p) => typeof p['runbookUrl'] === 'string',
  },
];

function verifyProposal(proposal: Record<string, unknown>): {
  passed: boolean;
  failures: string[];
} {
  const failures = frozenConstraints
    .filter(c => !c.test(proposal))
    .map(c => c.description);
  return { passed: failures.length === 0, failures };
}

// AI-generated proposal gets run through before any engineer reviews it
const aiProposal = { multiAzEnabled: true, metricsEndpoint: '/metrics' };
console.log(verifyProposal(aiProposal));
// { passed: false, failures: ['Operational runbook URL must be present'] }

HashiCorp's Terraform MCP server patterns demonstrate that AI agents can meaningfully accelerate provisioning, automate governance checks, and reduce the expertise barrier for routine infrastructure tasks. The architecture worth building on top of this is one where the MCP server acts as the execution interface but every apply action passes through a policy evaluation step that runs independent of the agent — think of it as the frozen verifier layer from the MTP analogy applied to infra. Source: [Terraform MCP server: Four real-world AI infrastructure patterns] — HashiCorp (https://www.hashicorp.com/blog/terraform-mcp-server-four-real-world-ai-infrastructure-patterns)

AIThe specific failure mode to guard against is the agent confidently generating a valid Terraform plan that satisfies no security constraints your team cares about — correct syntax, wrong semantics. The model doesn't know your cost envelope, your data residency requirements, or your internal network segmentation rules unless you've explicitly encoded those as evaluable policies. Treating AI-generated infra proposals as speculative drafts — and running them through automated policy gates before any engineer even looks at them — is the pattern that keeps the acceleration without accumulating silent compliance debt.

// TypeScript: policy gate wrapper for MCP-based Terraform agent
// Ensures every AI-generated plan is evaluated before human review queue

interface TerraformPlan {
  resources: Array<{ type: string; region: string; publicAccess: boolean }>;
  estimatedMonthlyCostUsd: number;
}

interface PolicyResult {
  allowed: boolean;
  violations: string[];
}

function evaluatePlan(plan: TerraformPlan): PolicyResult {
  const violations: string[] = [];

  if (plan.estimatedMonthlyCostUsd > 500) {
    violations.push(`Cost threshold exceeded: $${plan.estimatedMonthlyCostUsd}/mo > $500 limit`);
  }

  for (const resource of plan.resources) {
    if (resource.publicAccess) {
      violations.push(`Public access on ${resource.type} violates network policy`);
    }
    if (!['us-east-1', 'eu-west-1'].includes(resource.region)) {
      violations.push(`Region ${resource.region} outside approved data residency zones`);
    }
  }

  return { allowed: violations.length === 0, violations };
}

// Hook this into the MCP tool call handler — before plan gets queued for human review
export async function onPlanGenerated(plan: TerraformPlan): Promise<void> {
  const result = evaluatePlan(plan);
  if (!result.allowed) {
    throw new Error(`Plan rejected by policy gate:\n${result.violations.join('\n')}`);
  }
  await queueForHumanReview(plan);
}

The AWS MCP-based PDF extraction architecture — extracting text from S3 documents on demand using a protocol-based server — is a clean example of solving what looks like an AI problem with deterministic tooling. The value is in real-time availability and structured output, not language understanding. That's the right call, and it's the same judgment Chip Huyen documents as a persistent failure mode: teams reaching for GenAI on problems where a regex, a structured query, or a document parser would be faster, cheaper, and more reliable. Source: [Build interactive PDF text extraction from Amazon S3] — AWS (https://aws.amazon.com/blogs/machine-learning/build-interactive-pdf-text-extraction-from-amazon-s3/) Source: [Common pitfalls when building generative AI applications] — Chip Huyen (https://huyenchip.com//2025/01/16/ai-engineering-pitfalls.html)

AIFor agentic platform tooling specifically, this anti-pattern surfaces when teams build agent pipelines that route everything through an LLM — including classification, data extraction, and format conversion tasks that have perfectly good deterministic solutions. The architectural principle worth encoding in your team's review process: GenAI earns its place in a pipeline by handling genuine ambiguity or natural language variation; everything else should be a structured tool call. When an AI agent is generating suggestions about where to use AI in your system, that judgment should be the first thing you override.

// TypeScript: routing helper to prevent LLM over-use in document pipelines
// Use this at the agent tool-selection layer to enforce deterministic-first routing

type TaskType =
  | 'extract_structured_fields'
  | 'classify_intent'
  | 'summarize_freeform'
  | 'answer_ambiguous_query';

const DETERMINISTIC_TASKS = new Set<TaskType>(['extract_structured_fields']);
const CLASSIFIER_TASKS = new Set<TaskType>(['classify_intent']);

function routeTask(taskType: TaskType): 'deterministic' | 'classifier' | 'llm' {
  if (DETERMINISTIC_TASKS.has(taskType)) return 'deterministic';
  if (CLASSIFIER_TASKS.has(taskType)) return 'classifier';
  return 'llm';
}

// Agent tool selector — override AI suggestion if it routes structured extraction to LLM
export function selectTool(taskType: TaskType, aiSuggestedRoute: string): string {
  const correctRoute = routeTask(taskType);
  if (aiSuggestedRoute === 'llm' && correctRoute !== 'llm') {
    console.warn(`[OVERRIDE] AI suggested LLM for '${taskType}', routing to '${correctRoute}' instead`);
  }
  return correctRoute;
}

The architecture that makes agent-generated compliance outputs safe in production is one where every claim in the output is traceable to a specific data point in a specific source system — not just 'here's the report' but 'here's the report, and here's the evidence chain for each figure.' That's an observability problem as much as an AI problem: your agent pipeline needs to emit structured provenance records alongside its outputs, so a human reviewer can spot-check any cell in the compliance report against the underlying record without trusting the agent's reasoning. Source: [How a Leading Fintech Cuts Weekly Compliance Reporting from 2 Days to 2 Hours] — CrewAI (https://blog.crewai.com/how-a-leading-fintech-cuts-weekly-compliance-reporting-from-2-days-to-2-hours/)

AIThis connects directly to the broader override framework from block_1: the 'operational ownership' axis in a compliance pipeline means your team must be able to reconstruct how any output was produced, not just validate that it looks correct. Human-in-the-loop design here isn't a checkbox — it's a final verification step where a qualified analyst reviews a structured diff between this week's AI-generated report and last week's, with anomalies flagged by the pipeline, not identified manually. The agent accelerates; the human certifies.

// TypeScript: provenance record emitter for agentic compliance pipeline
// Each computed field in the report references its source evidence

interface ProvenanceRecord {
  fieldName: string;
  computedValue: number | string;
  sourceSystemId: string;
  sourceRecordIds: string[];
  computedAt: string;
  agentStepId: string;
}

class ComplianceProvenanceLogger {
  private records: ProvenanceRecord[] = [];

  log(record: ProvenanceRecord): void {
    this.records.push(record);
  }

  getEvidenceForField(fieldName: string): ProvenanceRecord | undefined {
    return this.records.find(r => r.fieldName === fieldName);
  }

  exportForAudit(): ProvenanceRecord[] {
    return [...this.records];
  }
}

// Usage inside a CrewAI task or LangGraph node
const logger = new ComplianceProvenanceLogger();

logger.log({
  fieldName: 'totalSuspiciousTransactions',
  computedValue: 142,
  sourceSystemId: 'ledger-service-prod',
  sourceRecordIds: ['txn-001', 'txn-002', 'txn-003'],
  computedAt: new Date().toISOString(),
  agentStepId: 'reconciliation-step-3',
});

// Human reviewer can pull this before certifying the report
console.log(logger.getEvidenceForField('totalSuspiciousTransactions'));

Addy Osmani's framing of the new software lifecycle points to a real structural shift: AI tooling is changing not just how fast engineers work, but which cognitive steps they actually perform. When generation is cheap, the temptation is to skip the deliberate design work and iterate toward correctness instead — which is a fine strategy for UI components and unit tests, and a dangerous one for distributed system boundaries, data contracts, and failure recovery logic. Source: [The New Software Lifecycle] — Addy Osmani (https://addyosmani.com/blog/new-sdlc-vibe-coding/)

AIThe practical implication for platform teams is that architectural judgment doesn't atrophy gradually — it atrophies task by task. Every time a senior engineer accepts an AI-generated system design without genuinely engaging with it, they've skipped the deliberate practice that keeps their judgment sharp. The override framework isn't just about catching AI mistakes; it's about maintaining the engineering discipline that makes override decisions reliable in the first place. Teams that thrive with AI acceleration tend to be those where senior engineers have explicitly protected certain design conversations from automation — not as a policy, but as a practice.

// TypeScript: AI-free zone classifier for PR review automation
// Flags changes in protected design areas before AI review tools run

const AI_FREE_PATTERNS: Array<{ pattern: RegExp; reason: string }> = [
  { pattern: /\/adr\//i, reason: 'Architecture Decision Record — human review required' },
  { pattern: /failover|circuit.?breaker|retry.?policy/i, reason: 'Failure mode logic — human review required' },
  { pattern: /security.?boundary|iam|auth.?policy/i, reason: 'Security boundary — human review required' },
  { pattern: /data.?contract|schema.?migration/i, reason: 'Data contract change — human review required' },
];

function classifyChangedFiles(filePaths: string[]): {
  aiFreePaths: Array<{ path: string; reason: string }>;
  aiAssistedPaths: string[];
} {
  const aiFreePaths: Array<{ path: string; reason: string }> = [];
  const aiAssistedPaths: string[] = [];

  for (const path of filePaths) {
    const match = AI_FREE_PATTERNS.find(p => p.pattern.test(path));
    if (match) {
      aiFreePaths.push({ path, reason: match.reason });
    } else {
      aiAssistedPaths.push(path);
    }
  }

  return { aiFreePaths, aiAssistedPaths };
}

// Run this in your CI pipeline before routing to AI code review
const changedFiles = ['src/api/auth-policy.ts', 'src/handlers/user.ts', 'docs/adr/0012-retry-strategy.md'];
const classification = classifyChangedFiles(changedFiles);
console.log('Requires human review:', classification.aiFreePaths);