AI-assisted implementation

• MCP (Model Context Protocol) — an open protocol for connecting a model to external tools and data sources.
• Vibe coding — accepting generated code with little review, steering only by running it.
• Characterization test — a test that records current behavior of legacy code before changing it.
• Typosquatting — publishing a malicious package whose name resembles a popular one.
• Scaffolding — generating the boilerplate skeleton of a project, module or endpoint.

• Completion for boilerplate and well-known patterns inside a function.
• Chat for explaining code, exploring an API, or drafting a snippet to adapt.
• Agent for multi-file changes, refactors and tasks that need running tests; it can iterate against failures on its own.

Strong: boilerplate, glue code, well-known frameworks, translating between languages, writing tests for clear behavior, explaining unfamiliar code. Weak: novel algorithms, cross-cutting design in a large codebase it has not read, subtle concurrency, performance-sensitive code, and anything depending on undocumented team knowledge.

Ask for one coherent change at a time, run the tests or type check after each, and commit working states. A loop of change, run checks, fix lets the agent self-correct; a single huge generation does not. Frequent commits make any step easy to revert.

Models invent functions, flags and even package names. Mitigations: compile or type-check immediately, point the agent at the real docs or source, and verify any new dependency exists, is maintained and is the one intended (typosquatted packages are a real supply-chain risk).

Left alone, a model writes generic code. Point it at an exemplar file (“follow the pattern in OrderService”), reuse existing helpers instead of re-implementing them, and check that it did. Duplicated utilities and style drift are the typical symptoms of missing context.

Agents are strong at mechanical, well-specified transformations (rename, API upgrade, framework migration) when characterization tests pin current behavior first. Without those tests there is no way to know the “mechanical” change preserved behavior. Migrate in slices, one module at a time, verifying each.

Start from architecture and interfaces you decided, not from “build me an app”. Have the agent scaffold the skeleton, then fill in modules against the spec, with tests at each seam. Without a human-held design, generated systems tend to grow tangled, with logic duplicated across layers.

MCP servers let an agent read tickets, query a database schema, or call internal services, grounding its work in real data instead of guesses. Grant the least privilege needed and prefer read-only access by default.

Vibe coding is fine for throwaway prototypes. For production code, the developer remains the author of record: understand and review every change, because incidents are attributed to the team, not the tool.