What is AI-assisted engineering?

The workflow owns the quality

A model can draft code quickly. Engineering begins when the task has a boundary, the repository supplies constraints, changes stay reviewable, and feedback can reject a wrong proposal.

flowchart LR
  G[Goal and constraints] --> C[Inspect current system]
  C --> P[Small proposal]
  P --> E[Execute checks]
  E --> R[Review evidence and diff]
  R -->|repair| P
  R -->|meets contract| D[Release decision]

The same model output can be safe in a disposable prototype and unacceptable in authentication code. The difference is not whether AI was used. It is whether the workflow supplies suitable context, authority, evidence, and review for the consequence level.

Give the agent an engineered environment

Repository instructions should state architecture, commands, conventions, protected areas, and the definition of done. Tool access should be narrow enough for the task. Tests, type checks, linters, build steps, previews, and runtime logs turn important properties into feedback the agent can observe.

Prefer small, coherent changes. A focused diff is easier to understand, test, revert, and repair than a broad rewrite. Ask the agent to inspect existing patterns before inventing a new abstraction. Use a plan when order, risk, or scope is uncertain, but keep planning proportional to the work.

Context is a maintained input, not a one-time dump. Large generated plans and transcripts can become stale. The durable state belongs in code, tests, decisions, issues, and concise repository documentation.

Human ownership moves, but does not disappear

An engineer may delegate searching, drafting, mechanical edits, or test execution. They still own the requirement, sensitive decisions, permission boundaries, evaluation strategy, and acceptance. For unfamiliar code, the correct response is to increase inspection and verification—not to accept the output because it is polished.

“Vibe coding” is useful language for intentional experimentation where understanding and durability are not yet the priority. Problems arise when prototype habits silently become the release process. Name the mode: exploration, internal tool, maintained product, or high-consequence system.

Feedback must match the failure

A type checker can catch shape errors but not a wrong business rule. Unit tests can cover logic but miss a broken browser download. A visual check can reveal layout but not cross-tenant authorization. Diff review can catch an unrequested API change that all tests tolerate.

Layer independent signals around the contracts that matter. Generated tests are valuable only if they would fail for plausible defects. Passing checks show that observed properties held under tested conditions; they do not transfer responsibility to the tool.

Keep authorship and accountability visible

AI-assisted engineering is not autonomous correctness, and an agent transcript is not a review. More generated code is not more progress if it increases unexamined surface area.

It is also not a single product or interface. Chat, inline completion, command-line agents, review agents, and custom harnesses can support the same engineering loop with different control and observability.

Evaluate the engineering workflow

Evaluate the workflow on representative repository tasks with frozen starting states. Measure accepted task success, severe regressions, human correction time, review findings, test strength, latency, and cost. Record the model, harness, instructions, tools, and checks.

Seed tasks with missing context, contradictory instructions, misleading tests, architecture constraints, and tempting shortcuts. Verify that the workflow asks for clarification or finds evidence instead of maximizing visible output.

Review both the artifact and the process: files inspected, assumptions made, commands run, permissions used, failures repaired, and checks omitted. Compare against an existing human or tool-assisted baseline before claiming productivity improvement.