AI-assisted engineering: what actually stuck

I use Claude Code, Cursor and MCP servers every day, and I’ve helped bring AI-assisted workflows into a team’s daily engineering practice — code generation, code review, test authoring. The tools changed a lot about how I work. They changed nothing about who’s accountable for the result.

This is a practical summary: where these tools help, where they don’t, and the guardrails that make them safe on a team.

Where they help

Writing tests. The highest-value use, for me. Describe the behaviour and the edge cases — “empty cart, a coupon that expired yesterday, a currency with no minor unit” — and let the tool write the test scaffolding. Then read every assertion. Tests are where a wrong assumption is cheapest to catch, and where a tool’s speed matters most, because test-writing is the work engineers most often skip.

Exploring unfamiliar code. “Where is this field set, and what reads it?”, “Walk me through what happens when this endpoint receives a refund”, “Which services publish to this topic?”. In a large or old codebase, this replaces an hour of grep and guesswork with a few minutes — as long as you verify the answer against the code it points to.

First-pass review. Before a human reviewer spends time on a pull request, an AI pass catches missing null checks, inconsistent naming, an unhandled error path, a forgotten test. That leaves the human review for what humans are good at: does this change make sense, and is it the right change?

Mechanical work. Mappers, DTOs, configuration, upgrade chores (a framework version bump across many files), translating a script from one language to another. Tedious, well-specified, easy to verify.

Tools for the tools. MCP servers let an assistant call your own systems — read a ticket, query a staging database, check a deploy status — inside the same conversation. That’s why I built java-mcp-server: so Java services can expose safe, well-described tools to agents with an annotation.

Where they don’t

Design decisions. An assistant will happily produce a confident design for anything. It can’t know your team’s constraints, history, on-call burden, or the political reality of who owns which service. Use it to generate options and challenge your reasoning; make the decision yourself, and write it down (see Design docs that get approved).

Subtle correctness. Concurrency, distributed transactions, money, security boundaries. These are areas where plausible-looking code and correct code diverge, and where a bug is expensive. Generated code here needs more review, not less.

Code nobody on the team understands. If a change is too large or too clever for the author to explain in review, it shouldn’t merge — whoever or whatever wrote it.

Guardrails for a team

A human owns every line. The author of the pull request is accountable for the code in it, regardless of how it was produced. Reviews hold AI-assisted changes to the same standard as any other.
Tests prove behaviour. The tool’s confidence proves nothing. If a change isn’t covered by a test that would fail without it, it’s not done.
No secrets or customer data in prompts. Use the organisation’s approved tools and settings; keep credentials, personal data and confidential material out of conversations.
Small changes. AI tools make large diffs cheap to produce and expensive to review. Keep pull requests small enough to review properly.
Share what works. Prompts, project instructions and MCP tools that work well for one engineer should live in the repo where the whole team benefits.

How to roll it out

Start with tests and exploration, where the risk is low and the benefit is obvious.
Agree on the guardrails before broad use, not after the first incident.
Collect examples — a good prompt, a review that caught a real bug, a migration done in a day — and share them in team meetings. Adoption spreads through examples, not mandates.
Revisit every few months. These tools change fast; what didn’t work last quarter may work now.

Takeaways

AI tools are best at tests, exploration, first-pass review and mechanical work.
They’re weakest at design decisions and subtle correctness — the parts that define senior engineering.
On a team: humans own every line, tests prove behaviour, no secrets in prompts, small diffs.
MCP servers turn an assistant into a colleague that can safely use your own systems.