How We Actually Use AI to Ship Code

The short version

To ship reliable code with AI agents, keep tasks atomic, give the agent focused context, use a strong model to plan fuzzy work, use faster models for narrow implementation, debug from raw evidence, ask for tests, and review every change. The core rule is simple: you do the thinking, and the AI does the typing.

• Human judgment should decide the architecture, constraints, and acceptance criteria. Coding agents are most useful when they handle the typing and execution.
• Push lean project rules into CLAUDE.md or AGENTS.md, then pull only the files, logs, and task context needed for the current change.
• Ask for tests, inspect boring diffs, restart degraded sessions, and turn repeated successful loops into reusable skills.

Every week, someone online claims their entire product was built 100% by AI agents. No humans involved.

Yeah. We know. We have tried it. It sucks. Congratulations.

But here is the thing. You genuinely can open a coding agent right now, type a paragraph in plain English about a feature you want, walk away for ten to twenty minutes, and come back to working code with tests. Five years ago, you would have had forty Stack Overflow tabs open, copying a snippet someone wrote in 2015, trying to adapt the variables to your project, fixing indentation by hand, and praying.

So the tools work. And honestly, it barely matters which one you pick anymore. We use both Claude Code and Codex on our team at the same time, side by side. Both are good enough today. Some of our team also use Cursor. Personally, I prefer Claude Code and use the Codex MCP to spawn Codex subagents. That ends up using both subscriptions, but it is the most token-efficient way I have managed to optimize my process.

The tool is not what separates people. There is still a huge gap between the people who ship working products with agents and the people who ship demos that break the moment a user touches them.

This article is about closing that gap.

I am going to walk you through exactly how we code at Towards AI. These are the workflows our engineering team uses every day to ship our products and the courses you have taken from us. They work the same no matter which agent you run them in. By the end, you will have everything you need to run them on your own repo this week, whether you are a developer learning to direct agents or a beginner upgrading from random vibe coding to something that ships.

I am Louis-François, CTO and co-founder at Towards AI, where we turn developers into AI engineers who build and ship AI products. Let us get into how we code in 2026.

Prefer to watch the complete walkthrough? Watch the video here, then use the rest of this article as the practical reference.

You do the thinking. The AI does the typing.

One rule sits behind every workflow in this article. You do the thinking. The AI does the typing.

You have heard it a hundred times. Yet almost nobody actually does it. Even if you barely code, thinking with the agent beats letting it run loose every single time.

Your setup has three layers: interface, brain, and context.

Interface

The interface is where you work, and it is mostly preference. Use an IDE with agentic extensions or a dedicated app like Claude Code or Codex. The desktop versions of these tools got much better this year. Pick one and move on.

Brain

The brain matters more, and it should be split into two buckets.

Use smart and slow models for architecture, multi-file reasoning, planning, and subtle bugs that could be hiding anywhere in the repo. Use fast and decent models for boilerplate, mechanical refactors, and anything where the design is already locked and you just need someone to type.

Waiting two minutes for a reasoning model to confirm a decision you already made is a flow killer. And of course, please do not forget to use your own brain in your projects. ;)

For your models, turn web search on. Models will confidently call functions that were renamed two minor versions ago. With search, they can read the current documentation instead.

Context

The third layer is context. It decides whether the first two matter.

The framing we use is: rules are pushed, content is pulled.

Push is what auto-loads every session. Put a lean CLAUDE.md or AGENTS.md file at the root of your repo with the current stack, conventions, folders not to touch, deployment target, and the non-obvious gotchas a new contributor would hit. Keep it clear. Every token in there gets loaded every single time, and more tokens can mean a dumber model. The file should look like a checklist and have an index, or point to an index, for deeper details.

Pull is what you hand the agent for a specific task. The README, the two source files that matter, the test file, and the logs. This is what you are doing in most prompts: giving the agent its references explicitly instead of letting it grep around your repo for ten minutes. A good index file helps here too.

Skills are the hybrid. The agent sees the description of each skill like a table of contents. The body loads only when it decides it needs that one. A deploy skill. A release-notes skill. A test-writing skill. A tone skill.

My friend Paul says his biggest win here is referring to raw documentation directly in his skills so the agent stays consistent across sessions and across the team. I prefer to put feedback loops in my skills so they can digest the interaction and improve over time. Both work.

In short: push what is always true. Pull what is true right now. Skills should be pulled by the agent when needed, or you can ask for one directly when you know your system better.

Protect the context window

You should almost always start from a fresh session with light context. Longer sessions make the model forget decisions, contradict itself, and miss details. Past about 70% full, you can watch it get dumber in real time.

Treating /compact as a long-term default is a big no-no. The beginning of your session becomes a vague memory of a vague memory. Use compact intentionally, with a clear direction for what comes next, so the agent knows what to keep and what to discard. When you fully switch tasks, even in the same repo, restart the conversation.

Keep tasks atomic. Prefer /clear over /compact in many scenarios, and attach only what matters. The two minutes you save by reusing an old session can cost twenty minutes debugging a half-amnesic answer and some very weird behavior. Trust me.

These foundations already put you ahead of most engineers using agentic tools. Now let us look at three workflows that cover about ninety percent of what our team ships.

Workflow 1: Context first

Use context first when you know what to change but the model does not know your system.

Attach the README plus the two or three files that actually matter, describe the exact change, and let it execute. Five minutes of context up front saves thirty minutes of un-hallucinating code at the end. Make sure your conventions already live in CLAUDE.md so you are not re-explaining the project.

Read @README and @main.py to learn about the project.
Read carefully @business_logic_1.py and @business_logic_2.py.

Your task is to edit @business_logic_2.py so that:
- change 1
- change 2
- ...

Follow the conventions in README. Do not modify other files unless necessary.
Explain any extra changes you make.

Workflow 2: Plan, then code

Use plan then code when you do not know what the implementation should look like. A new feature. A new domain. Maybe several valid paths.

Tell the agent to interview you before it plans. Literally:

I want to build [feature or project description].

Before we plan or write any code, ask me questions one at a time.
For each, give me your recommended answer and explain your reasoning.
Stop when we have enough to write a spec.

That surfaces decisions you did not know you were making. It makes you think and understand what will be done.

If you want to add authentication to an app, the agent will probably ask about session length, refresh strategy, multi-device logout, and password reset. Each of those decisions normally hits you mid-implementation and forces a rewrite.

Then run plan mode, review the plan, and execute. Plan mode asks its own questions, but nowhere near enough of them. My workaround is to put the question loop explicitly in the prompt.

Workflow 3: Smart decides, fast implements

Once the design is settled, drop down to a faster model and let it type.

Keep that prompt deliberately mechanical:

You are a coding assistant. The design and fix are already decided.

Here is the current code for function_x and the related types:
[paste code]

Here is the exact change I want:
[describe logic, conditions, and expected output]

Implement this change inside function_x only.
Do not introduce new concepts or redesign anything.
Do exactly what is described and nothing more.

If the task is fuzzy, plan first with the best model available, then let faster subagents implement. If the task is precise, just ask for the diff.

Everything sounds smooth until something breaks.

Debug from raw evidence

The first step when something goes wrong: if you are in Claude Code, trust it; otherwise, give the agent the function, the full stack trace, and the error message. Not your theory about what is wrong. The raw evidence. Models are bad at debugging your guesses. They are good at debugging actual logs.

The second step is to ask for a diagnosis and rewrite in the same prompt:

Here is the function and the full error message:
[paste function and full stack trace]

Explain why this is happening.
Then rewrite the function, keeping it efficient and readable.
Then write a test that would have caught this bug.

Diagnosis forces real reasoning. The rewrite is the fix. The test is your insurance against seeing the same bug again in three weeks.

The third step: if you are at your third try to fix a bug, do not keep pushing. Start a new thread with a narrower question and better evidence. An agent stuck on the first thread stays stuck. I once burned a day trusting Codex and refusing to clear out of pure stubbornness.

When the agent insists a method exists and it does not, do not argue with it. Tell it to search the current library documentation. This usually happens because the version you are using came out after the model’s training data, and it blindly follows the older API.

Bake tests and browser checks into the workflow

To reduce errors from the start, bake tests into your prompts. Ask for code and tests in the same prompt. Then tell the agent to run them, not just write them. Coding agents can execute tests, so let them.

Models do not write testable code by default. You have to ask explicitly. Encode it once in CLAUDE.md: always write tests for new functions. Now you never have to remember.

Once the code works, computer use is valuable for frontends. Tell the agent to spin up the development server, browse to the page, take a screenshot, check whether the buttons are where you wanted them, click them, confirm they work, and check the mobile version. The agent can flag broken things before you open the browser yourself. Then do not forget to open it and check too.

As teams use these tools, a productivity paradox emerges. Individual pull requests go way up with agents in the loop, but review times can explode and code churn can nearly double. Teams can get slower while individuals feel faster.

We do a lot of work in parallel with agents, but humans need to make the final review. We have seen this on our own team whenever we do not enforce the review-and-test discipline. We do not want to ship shitty code that wastes reviewers’ time.

Fight over-reliance

Everyone knows, in theory, that they need to review and maintain their judgment. The rigor still starts going down as sessions get longer. You check the first three generations carefully. Then you skim the next ten because the first ones had no errors.

This is the biggest habit you have to fight: over-reliance.

You start letting the agent build things you do not understand. It works, you ship, and you move on. Then a bug appears. You do not know the system well enough to debug it, and the agent cannot fix it either because this is the kind of bug that requires architectural understanding.

Here is my personal habit. After the agent implements anything non-trivial, I make it explain what it did, and I make sure I understand it. I ask questions and ask for confirmation that cites the code. That often exposes contradictions or broken parts.

I ask what functions it calls, what data flows where, why it chose this design instead of an alternative, and whether current state-of-the-art approaches support it. Even when everything works. The second something breaks, that explanation is the difference between a five-minute fix and a token-limit-maxing problem.

Six guardrails to implement now

1. Keep tasks atomic. One function, one file, one or a few related features, one concern. Do not overload the context. Use /clear between tasks.
2. Use the best model to plan. Ask it to spawn fewer thinking-heavy subagents with fresh context for multiple subtasks.
3. Ask questions. Question your model and your system. Ask the agent to verify current approaches online, then verify the result yourself.
4. Review everything. Especially the boring diffs. AI-generated pull requests need more scrutiny, not less.
5. Test by default. Encode “always write tests” in your rules so every generation is verified, not merely generated.
6. Automate what you repeat. Run the same cycle three times, turn it into a skill, and give the skill a feedback loop that can digest the interaction and improve the process.

The loop we keep coming back to is context, plan, code, debug and ask, reflect, encode what worked, and repeat. Tools keep changing. As long as you use your brain and neither you nor your agents get sloppy, you will be good.

Embed the implementation process into agents

The next move is embedding the entire development process inside the agents themselves. My friend Paul built exactly this: a multi-agent coding system that takes the loop above and stacks it.

The basic shape is fairly straightforward to implement. You have a list of tasks, an engineer agent that implements each task, and a tester agent that tests each implementation in a fresh context with no memory of how the engineer wrote it. If the test fails, the result goes back to the engineer for a retry.

Two agents. One writes, one verifies. Both have clean context. That alone catches more bugs than a single-agent setup running ten times longer.

Then you scale up. Add a project manager agent that writes the task list and reviews finished work. Add an automated pipeline that pushes to Git when a task passes. Add a dedicated pull-request reviewer agent. At that point, you do not have a coding agent. You have a team of agents.

I do not use this personally, but Paul is super efficient with it, and so can you be. At that point, it is a matter of personal preference and optimization.

Start this week

Focus first on the six guardrails and the three workflows. Evolve toward a setup like Paul’s over time.

Try it on an actual project this week. Create a CLAUDE.md with three rules for that project. Just three to start. Notice where the agent gets stuck and add a fourth. Whatever you repeat across sessions, turn it into a skill. Then repeat. In a few weeks, your agent setup will be doing things you could not have thought about or prompted for from scratch.

Whatever you do, stay involved enough that when something breaks at 11 p.m. on a Friday, you are the one who knows the system. Do not rely only on the agent and its current context. That is the difference between using AI to ship working products and being the person with the broken demo.

If you want tailored help growing as an AI engineer, learn about the Towards AI mentorship program. We can help with your career and your projects.

FAQ

What is the core rule for coding with AI agents?

You should own the thinking, including the architecture, constraints, and review. Let the agent handle typing, mechanical implementation, and repeatable execution.

What context should I give a coding agent?

Keep always-true project rules in a lean CLAUDE.md or AGENTS.md file. For each task, attach the README, the two or three relevant source files, the test file, and the raw logs or stack trace the agent needs.

When should I use a strong model instead of a fast model?

Use the strongest model for architecture, planning, multi-file reasoning, and subtle bugs. Once the design is settled and the change is precise, switch to a faster model for implementation and mechanical edits.

How should I debug code generated by an AI agent?

Start from the function, full stack trace, and exact error rather than your theory. Ask for a diagnosis, a rewrite, and a test. If two attempts fail, open a fresh thread with a narrower question and better evidence.

Why can AI coding make a team slower even when individuals write more code?

More generated pull requests can create longer reviews, more churn, and more code nobody fully understands. Teams need tighter scopes, stronger tests, and careful human review to turn local speed into reliable delivery.

What should I automate after a workflow starts working?

When you repeat the same successful cycle three times, encode it as a skill with the relevant rules, references, checks, and feedback loop so the next run starts from the pattern your team already validated.