AI-Assisted Engineering Practice

Where AI coding tools genuinely help infrastructure work and where they reliably fail, context engineering as the actual skill, reviewing generated infrastructure code, the governance a platform team must settle, and honest measurement.

Overview

A precise position, not a mood

AI coding tools moved from novelty to default tooling faster than any developer technology in recent memory, and the engineering conversation has not caught up. The useful position for a senior infrastructure engineer is neither enthusiasm nor dismissal: a precise account of what these tools do well, what they do badly, and what changes in your practice once they are in the loop.

Three shapes of tool

The landscape has three genuinely different shapes.

Inline completion — Next lines in the file you are editing — Sub-second, per-line accept decision
IDE-integrated agents — Multiple files — Proposed changes reviewed as a diff
Agentic coding tools — A whole task: Claude Code reads a codebase, edits files, runs commands, works multi-step — Can execute a test, read the failure and iterate rather than assert correctness

> [!IMPORTANT] That verification loop is the largest capability difference between the shapes, and it is also where the permission questions start.

Where value and failure concentrate

Operator scaffolding — Architecture decisions that depend on organizational facts
Translation between IaC languages — Anything requiring context nobody wrote down
Mechanical refactors across many manifests — Configuration that is plausible but wrong
Test generation, reading code you did not write

> [!WARNING] Infrastructure code fails silently in a way application code usually does not. A NetworkPolicy whose selector matches nothing does not throw; it quietly permits everything.

Context engineering is the skill

The model's output is conditioned on what it can see, so what it can see is the variable you control. Most complaints about model quality are, on inspection, complaints about context.

Repository convention files that load automatically — Conventions stop drifting
Tasks scoped narrowly enough that relevant material fits — Reviewable output
The actual failing test, not a description — No imported assumptions
The model runs the verification itself — Operates on observed reality

Review posture changes, counterintuitively

Generated code is plausible by construction: idiomatic, well-formatted and confident everywhere, including where it is wrong. Reviewers allocate attention using signals generated code does not emit.

> [!TIP] Compensate with more rigor, semantics over syntax, and mechanical verification: run the plan, run the policy engine, run the tests, rather than reading and nodding.

Where interviewers push

Failure modes — Specifics, not a gesture at hallucination
Practice — An actual approach to context and verification
Governance — Approved endpoints, secrets never entering prompts, provenance and licensing, audit of agent actions
Measurement — DORA and SPACE, not lines of code: the fastest way to tell whether someone has thought about this properly

Key concepts

Inline completion: Sub-second next-token suggestion in the editor based on the current file and nearby context, accepted or rejected per suggestion. GitHub Copilot is the archetype. Strongest on mechanical continuation where intent is already evident from surrounding code; weakest when the correct answer depends on something outside the visible window.
Agentic coding: A tool that operates on a whole task rather than a line: reading a codebase, editing files, running commands and iterating across multiple steps. Claude Code is the archetype, available in the terminal, IDE extensions, a desktop app and the web. The distinguishing capability is that it can verify by executing; the distinguishing risk is that executing means it can do damage.
Context engineering: Deliberately controlling what the model sees: repository convention files, task scoping, supplying the exact files and the failing test rather than a description of them, and requiring verification by execution. It is the highest-leverage skill in practice, because output quality is dominated by context quality rather than by model choice at the margin.
Repository convention file: A committed instructions file the tool reads at the start of every session — CLAUDE.md for Claude Code, with equivalents in other tools. It carries coding standards, architecture decisions, preferred libraries and review checklists so they do not have to be restated per prompt. Treat it as reviewed code: a wrong instruction propagates into everything the tool produces.
Plausible-but-wrong output: The dominant failure mode for infrastructure code. Output that is syntactically valid, idiomatically shaped and semantically incorrect — a selector matching no pods, a unit error in a resource limit, an overly permissive rule copied from a tutorial. It survives review because it emits none of the hesitation signals reviewers unconsciously use to allocate attention.
Provenance and licensing posture: The question of where generated code came from and what obligations attach to it. Vendors offer filters that block suggestions matching public code, and enterprise offerings differ on indemnification. A platform team decides the posture explicitly, records it, and can answer the question when procurement or an auditor asks — rather than discovering the position mid-diligence.
Agent permission boundary: The set of actions an agentic tool may take without asking: which commands it can run, which paths it can write, which network it can reach. Meaningful boundaries mean running against a checked-out branch rather than main, never holding production credentials, and producing a reviewable trail of every command and edit for after-the-fact audit.
MCP (Model Context Protocol): An open standard for connecting AI applications to external systems — data sources, tools and workflows — through servers that expose capabilities in a uniform way. For a platform team it is the mechanism for giving these tools scoped access to internal systems: an MCP server can expose exactly the read-only queries you intend and nothing else, with the boundary defined in code you own and review.

When to use it

High-volume, low-novelty code with a checkable result: operator and controller scaffolding, the tenth CRD field, table-driven tests, deepcopy and RBAC boilerplate
Mechanical translation between known formats — CloudFormation to Terraform, Compose to Kubernetes manifests, shell to a Python script with proper error handling
Large mechanical refactors across many files, such as an API version migration or a chart values-schema change, where doing it by hand is both tedious and error-prone
Reading unfamiliar code under time pressure: tracing a reconcile loop or a controller state machine in a repository you have never opened, where you verify the explanation as you go
Turning raw material into structured documents — a terminal session into a runbook, an incident timeline into a postmortem draft — where the facts are yours and the structure is the drudgery

Interview questions

Where do AI coding tools genuinely help an infrastructure engineer, and where do they reliably fail? Be specific.
What is context engineering, and why is it the actual skill?
How should reviewing AI-written infrastructure code differ from reviewing human-written code?
What governance questions must a platform team answer before rolling these tools out across an organization?
How do you measure whether AI-assisted engineering is actually helping, rather than just feeling fast?
What is MCP, and how does it change what these tools can safely do inside your organization?