TL;DR: The engineers getting two to three times the leverage from AI coding tools aren’t using better tools; they’re applying more craft. Most of that craft is context management: a standing instructions file, careful context selection, hooks, reusable skills, and a spec-first workflow. This guide covers eight habits that turn AI coding tools from autocomplete into real engineering leverage, and the things these tools still can’t do for you.
Table of Contents
Who this guide is for
This guide is written for:
- Software engineers using AI coding assistants’ day to day
- Engineering leaders exploring AI development workflows
- Teams adopting tools like Claude Code, GitHub Copilot, Kiro, or Codex
- Developers who want to improve productivity without sacrificing engineering quality
AI Coding Tools Reward Craft, Not Just Access
There is a gap emerging in engineering teams, and it is not about which AI coding tools you use. It is about how seriously you use them.
Some engineers are getting two to three times the leverage from Claude Code, Kiro, GitHub Copilot, or Codex. Others use the same tools and wonder what the fuss is about. The difference usually is not talent or experience. It is the invisible layer of craft that sits between having access to an AI assistant and genuinely changing how you build software.
This post covers the techniques, habits, and mental models that move you from passive user to someone who treats AI coding tools as a real force multiplier. In short, intentional use and good process are what turn these assistants into something worth the hype.
What AI Coding Tools Actually Are
Before the tactics, it helps to be honest about what these tools are and are not.
AI coding tools are context-driven text-completion engines, trained on large amounts of code and conversation. A few things follow from that:
- They do not understand your system. They infer it.
- They do not remember yesterday’s session. Each one starts fresh, or nearly so.
- They do not know your team’s conventions unless you tell them.
Most of the leverage comes down to one thing, which is managing context well. Everything else, including hooks, skills, and custom instructions, is just a structured way of doing that.
Claude Code, Amazon Kiro, GitHub Copilot, and OpenAI Codex all work on the same principle. Richer, more relevant context produces better output. The models and agentic loops differ, but the core mechanic is shared. Here is how the four compare at a high level.
Tool | How you run it | Model approach |
Claude Code | Terminal CLI, IDE extension, and GitHub | Anthropic’s Claude models |
Amazon Kiro | IDE (VS Code-based) and CLI | Claude by default, with more models available |
GitHub Copilot | IDE extensions and GitHub | Multi-model, chosen through a model picker |
OpenAI Codex | CLI, IDE, cloud, and ChatGPT | OpenAI’s Codex models |
With that established, here are the practical steps for getting real engineering leverage out of AI coding tools.
Set Up Custom Instructions as Your Permanent Context Layer
Most engineers never touch custom instructions, and that is a missed opportunity.
Custom instructions go by different names across tools, such as system prompt, project instructions, memory, or rules. They let you define a standing context that gets injected into every session. Think of it as what you would tell a new pair-programming partner before you start, covering the codebase, how the team works, and what you care about.
What to Put in Your Custom Instructions
There is no fixed format, but the most useful files tend to cover five areas, from technical constraints to how you want the tool to talk to you.
- Technology constraints. For example, “We use axios, not fetch” or “We are on hooks, so no class components.”
- Code style preferences. Explicit returns, no magic defaults, all functions typed.
- What you do not want. No boilerplate comments, no stray console.log statements, no packages you have not imported.
- Your role and context. “I am a backend engineer on a distributed, event-driven Go system. Most of my work involves Kafka, Postgres, and AWS.”
- Output preferences. “Explain the key decision, not every line. When I ask for a review, be direct about what is wrong rather than diplomatic.”
How Each AI Coding Tool Handles Custom Instructions
Each tool has its own file or mechanism for persistent project context. The table below maps the main ones.
Tool | Where instructions live | Notes |
Claude Code | CLAUDE.md at the repo root (or .claude/) | Committed to the repo, so the whole team shares the same context |
GitHub Copilot | Repository- or organisation-level coding guidelines | |
Kiro | Steering files in .kiro/steering/ | Can scope instructions by file glob |
OpenAI Codex | AGENTS.md at the project root | Analogous to Claude Code’s CLAUDE.md |
The real leverage here is consistency. Create and maintain this file in every project, and your AI coding tools start each session with clear, relevant information. That means better suggestions and less repeated explaining for the whole team.
Master Context Engineering, the Highest-Leverage Skill
If custom instructions are your standing brief, context engineering is your real-time craft.
Context engineering is the discipline of deciding what to include in a prompt or session, and what to leave out. Poor context produces generic, often wrong answers. Rich, targeted context produces responses that feel like they came from someone who actually knows your system.
Treat Context Like a Budget
Every model has a context window, which caps how much it can hold in working memory at once. Spend that budget wisely. Rather than dumping an entire codebase, include only the files, types, and constraints that matter. What matters most is strategic selection, not volume. The table below shows where to spend and where to save.
Spend budget on | Trim or skip | Why it helps |
Type definitions (interfaces, structs) | Example payloads | A model infers values from types, but not types from values |
The function, its imports, and nearby lines | The entire 2,000-line file | Focuses attention on the actual problem |
Full, verbatim error and stack traces | Paraphrased errors | Models read raw traces well, but need the real text |
A similar handler you already have | Abstract descriptions of what you want | Anchors new code to your existing patterns |
Explicit scope limits and what you tried | Open-ended, unbounded asks | Removes dead-end suggestions and unwanted rewrites |
Practical Context Techniques
A handful of habits make a noticeable difference in the quality of what you get back.
- Include the types, not just the values. Paste the TypeScript interface or Go struct rather than an example payload.
- Show the shape of the problem. For a bug in a large file, paste the function signature, the imports it uses, and the lines around the bug.
- Say what you have already tried. “I tried X and Y, both fail because Z” removes a whole category of suggestions.
- Include error messages verbatim. Paste full stack traces, not a paraphrase.
- Anchor with existing code. Show a similar handler and say, “Write one like this, but for payments.”
- Declare what is out of scope. “Do not refactor the surrounding code, just fix the bug.”
Automate Your Workflow with Hooks
Hooks are one of the less-discussed features of agentic coding tools, and they pay off for teams that invest in them.
A hook is a script or command that runs automatically at a defined point in the agentic loop, such as before a tool is called, after a file is edited, or before a response is shown. Think of them as lifecycle callbacks for your AI session.
Where Hooks Pay Off
The best candidates are the small, repetitive tasks you would otherwise have to remember to do yourself.
Auto-format on every edit. A post-edit hook can run eslint –fix or gofmt after any file write, so formatting is clean before you see it.
Block dangerous operations. A pre-tool hook can intercept risky commands (a rm -rf, a push to production, an unexpected network call) and warn or hard-stop.
Auto-run tests on change. Trigger a targeted test run on file edits, so the agent gets immediate feedback without prompting it.
Log everything. For post-mortems or internal training, hooks emit structured logs of every tool call, input, and output.
Notify on completion. A stop hook can post to Slack or fire a desktop notification when a long refactor finishes.
The mechanics differ across tools, but the pattern holds. Here is how each one exposes automation.
Tool | Hook or automation mechanism | Typical triggers |
Claude Code | Hooks (command, prompt, agent, or HTTP) | PreToolUse, PostToolUse, Stop, and other lifecycle events |
Kiro | Agent hooks (agent prompt or shell command) | File create, save, or delete; prompt submit; agent stop; pre/post tool use |
GitHub Copilot | GitHub Actions workflows for the coding agent | Issue assigned, pull-request events, and CI steps |
OpenAI Codex | Lifecycle hooks (hooks.json) plus notify | SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop |
Build Reusable Skills and Workflows
Skills, as Claude Code calls them (other tools call them templates, snippets, or playbooks), are reusable, parameterised instructions for common tasks. Instead of re-explaining what you want every time, you encode it once.
Think of a skill as a prompt template with slots, such as “Generate a REST endpoint for [resource] with [auth type] auth, following our existing pattern in [reference file].”
Where Skills Pay Off
Skills earn their keep on the tasks you do over and over, where consistency matters as much as speed.
Scaffolding. A new service, Lambda, or React component with the same structure every time.
Code review checklists. “Review this PR for security issues, missing error handling, test coverage, and naming conventions.”
Migration patterns. “Convert this class component to a functional component using our hook conventions.”
Commit messages. “Given this diff, write a commit message in conventional-commits format, specific about what changed and why.”
Documentation. “Write a JSDoc comment that focuses on the non-obvious behaviour, not the parameters.”
Each tool offers a different mechanism for capturing and reusing these. The table below compares them.
Tool | Reusable-workflow mechanism | How you invoke it |
Claude Code | Skills (SKILL.md) and slash commands | /command in the session |
Kiro | Steering files and reusable specs | Steering applies automatically; specs are run as a workflow |
GitHub Copilot | Prompt files (.github/prompts/*.prompt.md) | /prompt-name in chat |
OpenAI Codex | Agent Skills (SKILL.md) | /skills, or mention with $ |
The pattern here is simple. When you find yourself repeating a prompt, formalise it into a skill. That reduces friction and keeps output consistent across the team.
Multi-Turn vs One-Shot, and How to Choose
A common mistake is treating every AI interaction as a one-shot transaction, where you write a prompt, take the answer, and move on. That works for simple, well-defined tasks. It breaks down for anything complex. The three modes below cover most situations.
Mode | Best for | Watch out for |
One-shot | Simple, well-defined tasks and quick lookups | It breaks down on complex or evolving problems |
Multi-turn | Iterating, debugging, and building with steering | Context debt and drift over long sessions |
Start fresh | Sessions that feel confused or contradictory | Re-establish a clean, current summary first |
When to Go Multi-Turn
The important point with iteration is to be specific. Rather than “that is wrong, try again,” say what is wrong and which direction to go. “The function handles the happy path but not a null DB result, so update it to handle that” is far more useful than “fix the null issue.”
Keep the model oriented, too. In long sessions, re-anchor explicitly: “We are building the payment handler. The validation layer is done, now let us do the charge step.” This prevents drift, where the model starts acting on stale assumptions.
When to Start Fresh
Long sessions accumulate context debt, where earlier assumptions and superseded code are still sitting in the window. If responses start to feel confused or contradictory, opening a new session with a clean, current summary is often faster than correcting the drift.
Use a Spec-First Workflow for Complex Features
This is the single highest-impact change for non-trivial feature work.
Before asking the AI to write any code, ask it to write the spec:
- What does the function need to do?
- What are its inputs and outputs, and its edge cases?
- What should it explicitly avoid doing?
- What existing code does it integrate with?
Generate that spec, read it, and correct it. Only then say, “Now implement this.”
This forces clarity, because if the model cannot write a coherent spec, the task is not well-defined enough to build yet. It also gives the implementation an explicit contract to anchor to, which makes the resulting code far more likely to be correct.
The workflow is model agnostic, but the tools support it differently. Some build it in, and others lean on an open-source toolkit.
|
Tool |
Built-in spec support |
Spec-driven via a toolkit |
|
Kiro |
Native, generating requirements, design, and tasks files (EARS-style) |
Built around spec-driven development by default |
|
Claude Code |
Manual: ask for a spec, review it, then implement |
Works with GitHub Spec Kit |
|
GitHub Copilot |
Manual; prompt files can template the steps |
Works with GitHub Spec Kit |
|
OpenAI Codex |
Manual, with a plan and review step |
Works with GitHub Spec Kit |
The real leverage is the same regardless of the tool. An explicit contract, reviewed before any code is written, removes most of the rework that comes from building the wrong thing quickly.
Prompting Patterns That Make AI Coding Tools More Reliable
A few patterns produce reliably better output regardless of the tool. The table summarises them, with the detail underneath.
Pattern | Example phrasing | What it does |
Role framing | “Act as a senior Go engineer reviewing for production readiness” | Activates a sharper, more critical mode of response |
Constraint-first | “Without changing the public API or adding dependencies, refactor this” | Stops the model taking paths you would later undo |
Ask for options | “Give me three approaches with the tradeoffs of each” | Surfaces the option space faster than your own research |
Negative examples | “Here is what we are moving away from; do this instead” | Packs many implicit conventions into one prompt |
Chain of thought | “Reason through the likely root cause before suggesting a fix” | Improves answers on genuinely hard problems |
Used together, these patterns are most of the difference between a vague request and one the model can act on cleanly. They cost almost nothing to apply and compound across every session.
What AI Coding Tools Still Can’t Do Well
In the spirit of being useful rather than just enthusiastic, here is where AI coding tools fall short, and how to work around each gap.
Limitation | What it looks like | How to mitigate |
No knowledge of your domain | Treats “Account” as a user, not a billing entity | Define domain terms in your instructions and context |
Hallucinated APIs | Invents functions or signatures, often for new libraries | Verify calls against real docs before trusting them |
Poorly calibrated confidence | Confident answers to questions it cannot answer | Independently verify anything that matters |
Weak long-horizon planning | Mediocre multi-file architecture without steering | Make the decisions yourself; let the tool execute them |
Amplified technical debt | Copies your messy patterns at speed and scale | Clean the patterns first, and review generated code |
Building the Habit: Getting More from AI Coding Tools
The engineers getting the most from AI coding tools are not only using them more, but they are also using them more deliberately. For them, setting context comes before prompting. Their CLAUDE.md, or its equivalent, stays a living document rather than a one-time setup. A twenty-minute hook that saves an hour a week is worth building, and reusable prompts get captured instead of retyping.
The tooling will keep improving. Context windows will grow, and models will get better at multi-file reasoning and long-horizon planning. But the craft of working with these tools well, knowing what to include, what to leave out, how to steer, and when to start fresh, is a durable skill.
Start with one thing from this list and get good at it. Then add another. The compounding effect is real, and it is available to any engineer willing to be deliberate about it.
This post reflects patterns that apply across Claude Code, Amazon Kiro, GitHub Copilot, and OpenAI Codex. Tool-specific features evolve quickly, so always check the latest official documentation for current capabilities.
Vishal Jain is an Intelligent Modernisation Consultant with more than 15 years’ experience designing and delivering high-performance digital solutions across cloud, web and enterprise environments. He specialises in modern application development, front-end engineering, cloud-native architecture and DevOps, helping organisations move from legacy platforms to scalable, event-driven systems. Vishal brings deep expertise across React, TypeScript, AWS, Python, Node.js and infrastructure as code, with a strong focus on building intuitive, reliable and maintainable user experiences.
