How to Use AI Coding Tools the Right Way
A field guide for engineers who still want to be engineers.
A lot of engineers today, junior and senior alike, are being pushed to adopt AI tools to speed up their work. There's a right way and a wrong way to do it, and the gap between them doesn't show up immediately — it shows up in twelve to twenty-four months.
The wrong way is vibe coding: prompting your way to a pile of code you don't understand, that works today and becomes an expensive, tangled liability later. The right way treats AI as a force multiplier on top of real engineering judgment, letting you scale your output while keeping your code quality and your own competence intact.
Before the tactics, it's worth naming the two hidden costs of these tools, because both are easy to ignore until they bite.
The first is money. Per-token prices keep falling, but agentic workflows consume so many more tokens per task that your effective spend per feature — and how unpredictable that spend is — keeps climbing. A useful discipline: imagine you were rationed to ten queries a day. Would this prompt make the cut? That scarcity mindset keeps you from reaching for the model on problems you could solve faster yourself.
The second cost is subtler and more dangerous: skill atrophy. The more you outsource, the more context you lose — on the codebase you're building and on your own craft. And as your understanding erodes, you get worse at catching the tool's mistakes, which is exactly when hallucinations and unoptimized code slip through. The engineer who can't spot bad AI output is the one who most needs to.
With that framing, here are the tips.
1. Maintain steering docs — for the project and for yourself
Keep two kinds of context documents. A project steering doc captures your architecture, conventions, key decisions, and the why behind them, so the tool stays coherent across many separate chats and sessions instead of relearning your project from scratch every time. A personal preferences doc captures how you work: functional over clever, early returns, pytest not unittest, no premature abstraction — whatever your style is.
Example: a repo-level CONTEXT.md that says "auth flows through the gateway service, never call the user DB directly, all timestamps are UTC," paired with a personal rules file that says "prefer explicit over concise; comment the why, not the what." The tool stops making the same wrong assumptions on every task.
2. Wire it into chat tools for async work
If you don't want a fully autonomous agent, the next best thing is to hook the tool into Slack or a similar chat interface so you can prompt it from anywhere. This lets you kick off and steer longer tasks while you're away from your desk.
Example: on your commute, you message it to scaffold a new service or grind through a mechanical refactor, and by the time you're back at your machine there's a draft branch waiting for review. The work happens in the background; your judgment gets applied when you return.
3. Tell it how to validate itself
Hallucination drops sharply when you force the model to check its own work. Give it explicit validation steps rather than trusting its first output.
Example: instead of "write this function," try "write this function, then write a test that proves it works against the real API signature, run it, and show me the result." Asking it to state its assumptions and verify them against actual docs or a running system turns a confident guess into a checked answer.
4. Have it write tests — then prune ruthlessly
AI is great at boosting coverage, but it has a strong tendency to generate bulk, low-value tests: trivial getters, tests of the framework itself, five variations that all exercise the same path. Coverage numbers go up; actual signal doesn't.
So treat generated tests as a first draft and cut hard. Keep the tests that exercise real logic and genuine edge cases; delete the filler. Worthless tests aren't free — they eat CI time and compute on every run, and they add permanent maintenance weight. A test that never fails for a good reason is just a liability with a green checkmark.
5. Lean on it for the known, not the novel
These tools were trained on existing code, which makes them excellent at things that already exist and weaker at genuine novelty. That's the single most useful mental model for deciding what to delegate.
Point it at boilerplate, scaffolding, debug logging, and general code analysis — the reinvent-the-wheel work. Keep the hard, novel parts for yourself: system design, a custom optimization, a non-standard algorithm, the specific thing that makes your product yours. The more novel the task, the deeper into hallucination territory you go, because the model has fewer real examples to draw on. Use it where the ground is well-trodden; walk the new ground yourself.
6. Use it to build tools that make you faster — and need it less
Some of the highest-leverage use is having the model build deterministic tools that speed you up whether or not the model is in the loop. This both accelerates you and saves tokens, because the tool does the work the model would otherwise redo every time.
Example: have it analyze your shell history, find your most common command chains, and generate a set of aliases and shortcut functions. Now you code faster at the terminal on your own — and any agent you run also inherits those shortcuts, making it faster and cheaper too. You've converted a recurring AI cost into a one-time tool.
7. Make it teach you what you outsource
The black-box problem — shipping code you don't understand — is how skill atrophy compounds. Counter it by having the tool produce a short learning guide for anything non-trivial you delegate.
Example: after it builds an auth module, ask for a one-page explainer of how it works and the concepts behind it. Five minutes of reading keeps the module from becoming a part of your own codebase you're afraid to touch.
8. Always review the code — and make yourself understand it
This is the non-negotiable one. It can hallucinate, and the only defense is your own eyes on every line.
A technique I've found genuinely helps comprehension: ask it to leave thorough comments explaining each step, then, as you read through, delete its comments and replace them with your own. The act of rewriting the explanation forces you to actually understand what the code does — and you end up with cleaner, human-authored comments as a bonus. If you can't write the comment yourself, you don't understand the code yet.
9. Automate scans in your pipeline
Beyond interactive use, put AI to work in CI. Automated review can catch a meaningful class of bugs and security issues before a human ever looks at the PR, and it scales across every commit without tiring.
Example: an automated review step that flags common bug patterns, risky changes, and potential vulnerabilities on every pull request. Treat it as a first-pass filter that complements human review, not a replacement for it — it catches the obvious so your reviewers can focus on the subtle.
10. Set it up for DevOps debugging — carefully
With read access to your systems, an AI tool becomes a high-value debugger: while you focus on novel code, it correlates hard-to-read logs across multiple servers and surfaces the likely culprit.
Example: hand it a stack trace and read-only access to your logs, and let it trace the failure across microservices while you keep building.
The caveat matters as much as the tip: read-only, least privilege, always. Logs shipped to a third-party AI service can contain secrets, credentials, PII, or customer data, so be deliberate about what the tool can see and where that data goes. The debugging leverage is real, but so is the governance risk — scope the access before you grant it.
The bottom line
Used well, these tools let you skip the reinvent-the-wheel work and pour your attention into the high-value, novel problems only you can solve — cost-effectively, and without hollowing out your own skills in the process. Used badly, they hand you speed today and a mess in eighteen months. The difference isn't the tool. It's whether you stay the engineer in the loop.