The AI Engineering Guide
How to ship real features with AI coding agents. The workflow, what to delegate, the context that makes agents reliable, and a full worked example you can follow.
How features get built now
The job has shifted. You used to write every line. Now, increasingly, you describe an outcome, an agent writes most of the code, and your time goes to framing the work, giving the agent the right context, and reviewing what comes back. The hard skill is no longer recalling an API. It is knowing what to delegate and how to set the agent up so its output is correct, not just plausible.
This guide is the practical version of that: a repeatable loop for shipping a feature with an agent, an honest read on what agents are and are not good at, the context that makes them reliable, and one real feature carried all the way through as a worked example.
The loop for shipping a feature
Almost every feature an agent ships well follows the same five steps. The work is front-loaded into framing and context, and back-loaded into verification. The middle is where the agent earns its keep.
We call this loop engineering: set a high-level /goal, let the agent use skills, steer it as it works, and review the result with skills. For the full pattern and the skills we reach for on every run, read Loop Engineering: Building With AI Agents the Right Way.
1. Frame the work
Write a short brief or use plan mode. Define the outcome and acceptance criteria before any code. The clearer the target, the less the agent wanders.
2. Give it context
Point the agent at the right knowledge: a project conventions file, a skill for an API it would otherwise guess at, live docs. Context is what separates a confident correct agent from a plausible wrong one.
3. Let it implement
The agent writes the code and a runnable example. For anything non-trivial, have it plan first, then execute, so you catch a wrong direction before it writes 300 lines.
4. Verify
Run it. Read the diff the way you would review a teammate. Check the edge cases and the security-sensitive parts yourself.
5. Ship
Open the PR, pass your normal review gate, merge. The agent can draft the PR. You own the merge.
What agents are good and bad at right now
This tells you where to let the agent run and where to stay hands-on. It shifts with every model release, so treat it as a snapshot. As of mid 2026, with frontier models, the split looks like this.
Let the agent run
- Boilerplate setup: install the right package, read keys from the environment, scaffold a client.
- The unglamorous plumbing: auth headers, retries, pagination, and webhook handlers.
- Translating an integration from one language or framework to another.
- Generating tests and example requests so you can confirm the happy path quickly.
- Reading logs and stack traces to localize a bug faster than you would by hand.
Stay in the loop
- Security calls: where secrets live, what runs server-side, what an event is allowed to trigger.
- Verifying a webhook signature before trusting an event, rather than assuming it is genuine.
- Edge cases beyond the happy path: declined, expired, partial, or duplicate states.
- Architecture decisions: where state lives, what is idempotent, what happens on retry.
- Anything legally or financially sensitive, where "looks right" is not the same as "is correct."
Set the agent up to succeed: context
The biggest lever on whether an agent gets a feature right is not prompt cleverness, it is context. A model with no context guesses at your API and your conventions. The same model with the right context stops guessing. Four tools do most of the work.
A conventions file
A short CLAUDE.md (or AGENTS.md) the agent reads every session: your stack, commands, and house rules. Keep it minimal and let it grow only when the agent goes off track. CLAUDE.md guide.
Skills
A SKILL.md gives the agent ground truth for a specific task, so it stops guessing at an API surface. This is the single biggest reliability lever for integration work. Claude Skills guide.
MCP servers
Live access to systems and documentation so the agent works against reality, not its training-cutoff memory of an API. MCP servers.
Plan mode
Make the agent design before it codes. One sentence of "plan first, do not write code yet" is cheap insurance against a confident wrong direction. plan vs spec.
This is why the worked example below installs a skill rather than pasting API docs into the prompt. The skill is the context that turns a plausible integration into a correct one.
Worked example: adding e-signatures
To make the loop concrete, here is a typical real feature: letting your app send a document for signature and react when it is signed. We use the TurboDocx Quickstart Skill as the example because it ships an Agent Skill, which is exactly the "give the agent ground truth" move from the previous section. The same five steps apply to any well-documented API.
Step 2 is one command, run once in your project:
npx skills add TurboDocx/quickstart
Frame it
In your agent: "Add a route that sends a contract PDF for signature and notifies us when it is signed." That is the outcome and the acceptance criteria in one line.
Give it ground truth
Install a skill so the agent knows the real API instead of guessing. Here that is the TurboDocx Quickstart Skill, which is the "give it context" step made concrete.
Let it implement
The agent detects your stack, installs the matching SDK, reads the key from .env, and writes an integration module plus a runnable example.
Verify and harden
Read the diff, confirm the key is server-side, add a webhook handler for completion, and cover the decline and expiry paths yourself.
Ship
Run it, send a real signature to yourself, confirm the signed file and audit trail come back, then merge.
In Claude Code
Follow the worked example step by step in Anthropic's terminal agent.
In Cursor
The same example inside the AI-first editor.
The full narrative
The end-to-end story, from blank project to first signature.
Prefer to see the hand-written code the agent generates? The SDK guides have it for JavaScript, TypeScript, Python, Go, Java, PHP.
Scaling to bigger features
The same loop runs in parallel. For larger work, spin up sub-agents with fresh, uncorrelated context to research or implement independent pieces, then integrate the results. Aiming more context at a problem is a form of test-time compute: it tends to raise the ceiling on what the agent can build, as long as you keep the pieces genuinely independent so they do not step on each other. Start with one agent and the five-step loop, and reach for sub-agents only when the work clearly splits into parts.
What to verify before you ship
An agent hands you a working happy path in minutes. These are the things worth slowing down for, because they are where features actually break. They map directly to the "stay in the loop" column.
- Secrets are read from the environment and never reach the client bundle.
- Inbound events (webhooks) are verified before they are trusted.
- Results you must not lose are stored durably, with their audit trail.
- Failure and edge states are handled, not just the happy path.
- You read the generated diff the way you would review a teammate's pull request.
In the e-signature example, the heavy compliance work (tamper-evident audit trails and ESIGN, UETA, and eIDAS alignment) runs on the API provider, not in your code. That is part of why a hosted API is a good fit for agent-built features: the risky parts are not yours to implement. See the US and European compliance guides.
Go deeper
How I Use Claude Code to Ship Features in One Session →
A repeatable workflow for going from idea to merged feature with an agent.
Vibe Coding vs Spec-Driven Development →
When to let the agent run versus when to write a spec first.
Claude Skills: The Complete Guide →
How to give an agent ground truth with a SKILL.md.
Cursor vs Claude Code vs OpenCode →
Which agent fits your workflow, compared honestly.
Automate Product Documentation with AI Agents →
Guidewright writes and reviews product docs by driving your live app.
Frequently asked questions
How do you ship a feature with an AI coding agent?
Frame the work with a short brief or plan mode, give the agent the right context (a conventions file, a skill, or live docs), let it implement and write a runnable example, verify the result and the edge cases yourself, then ship it through your normal review gate. The agent does the mechanical work; you own the decisions and the merge.
What should I let an agent do, and what should I review myself?
Let it own boilerplate, plumbing, translations, tests, and first-pass debugging. Keep yourself in the loop for security decisions, webhook verification, edge cases, architecture, and anything legally or financially sensitive. The rule of thumb: delegate the mechanical work, reserve your attention for what is expensive to get wrong.
How do I stop an agent from hallucinating an API or library?
Give it ground truth instead of hoping. A skill (SKILL.md), a conventions file, or an MCP server that exposes the real docs all anchor the agent to how the API actually works, rather than its memory of it. Context is the biggest lever on reliability, more than prompt wording.
Can I use this workflow to add e-signatures?
Yes, and it is the worked example in this guide. Install the TurboDocx Quickstart Skill so the agent knows the real signing API, then prompt it to add the feature. The same workflow applies to any well-documented API.
Alex Martinez
Developer Relations & Automation Lead
Try the worked example
Run the skill, prompt your agent, and ship the e-signature feature end to end. It is the fastest way to feel the loop in your own codebase. Your first 5 signatures each month are free.