{ "source_file": "0930", "source_platform": "Ghost", "author": "Louis-François Bouchard / What's AI", "title_listed": "How We Actually Use AI to Ship Code", "keywords": "", "domain": "大模型算法", "content_type": "深度技术解析", "is_paid_flag": "否", "url": "https://www.louisbouchard.ai/ai-coding-workflows-that-ship/", "publish_date": "2026-08", "corpus_stage": "", "notes": "", "id": "956ac6920bb5", "collected_at": "2026-10-02T12:32:23", "title": "How We Actually Use AI to Ship Code | What's AI", "body_markdown": "The short version\nTo 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.\nThe core rule is simple: you do the thinking, and the AI does the typing.\nHuman judgment should decide the architecture, constraints, and acceptance criteria. Coding agents are most useful when they handle the typing and execution.\nPush lean project rules into CLAUDE.md or AGENTS.md, then pull only the files, logs, and task context needed for the current change.\nAsk for tests, inspect boring diffs, restart degraded sessions, and turn repeated successful loops into reusable skills.\nEvery week, someone online claims their entire product was built 100% by AI agents. No humans involved.\nYeah. We know. We have tried it. It sucks. Congratulations.\nBut 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.\nSo 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.\nThe 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.\nThis article is about closing that gap.\nI 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.\nI 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.\nPrefer to watch the complete walkthrough? Watch the video here, then use the rest of this article as the practical reference.\nYou do the thinking. The AI does the typing.\nOne rule sits behind every workflow in this article. You do the thinking. The AI does the typing.\nYou 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.\nYour setup has three layers: interface, brain, and context.\nInterface\nThe 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.\nBrain\nThe brain matters more, and it should be split into two buckets.\nUse 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.\nWaiting 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. ;)\nFor 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.\nContext\nThe third layer is context. It decides whether the first two matter.\nThe framing we use is: rules are pushed, content is pulled.\nPush is what auto-loads every session. Put a lean\nCLAUDE.md\nor\nAGENTS.md\nfile 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.\nPull 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.\nSkills 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.\nMy 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.\nIn 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.\nProtect the context window\nYou 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.\nTreating\n/compact\nas 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.\nKeep tasks atomic. Prefer\n/clear\nover\n/compact\nin 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.\nThese 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.\nWorkflow 1: Context first\nUse context first when you know what to change but the model does not know your system.\nAttach 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\nCLAUDE.md\nso you are not re-explaining the project.\nRead @README and @main.py to learn about the project.\nRead carefully @business_logic_1.py and @business_logic_2.py.\nYour task is to edit @business_logic_2.py so that:\n- change 1\n- change 2\n- ...\nFollow the conventions in README. Do not modify other files unless necessary.\nExplain any extra changes you make.\nWorkflow 2: Plan, then code\nUse plan then code when you do not know what the implementation should look like. A new feature. A new domain. Maybe several valid paths.\nTell the agent to interview you before it plans. Literally:\nI want to build [feature or project description].\nBefore we plan or write any code, ask me questions one at a time.\nFor each, give me your recommended answer and explain your reasoning.\nStop when we have enough to write a spec.\nThat surfaces decisions you did not know you were making. It makes you think and understand what will be done.\nIf 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.\nThen 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.\nWorkflow 3: Smart decides, fast implements\nOnce the design is settled, drop down to a faster model and let it type.\nKeep that prompt deliberately mechanical:\nYou are a coding assistant. The design and fix are already decided.\nHere is the current code for function_x and the related types:\n[paste code]\nHere is the exact change I want:\n[describe logic, conditions, and expected output]\nImplement this change inside function_x only.\nDo not introduce new concepts or redesign anything.\nDo exactly what is described and nothing more.\nIf 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.\nEverything sounds smooth until something breaks.\nDebug from raw evidence\nThe 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.\nThe second step is to ask for a diagnosis and rewrite in the same prompt:\nHere is the function and the full error message:\n[paste function and full stack trace]\nExplain why this is happening.\nThen rewrite the function, keeping it efficient and readable.\nThen write a test that would have caught this bug.\nDiagnosis forces real reasoning. The rewrite is the fix. The test is your insurance against seeing the same bug again in three weeks.\nThe 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.\nWhen 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.\nBake tests and browser checks into the workflow\nTo 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.\nModels do not write testable code by default. You have to ask explicitly. Encode it once in\nCLAUDE.md\n: always write tests for new functions. Now you never have to remember.\nOnce 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.\nAs 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.\nWe 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.\nFight over-reliance\nEveryone 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.\nThis is the biggest habit you have to fight: over-reliance.\nYou 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.\nHere 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.\nI 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.\nSix guardrails to implement now\nKeep tasks atomic.\nOne function, one file, one or a few related features, one concern. Do not overload the context. Use\n/clear\nbetween tasks.\nUse the best model to plan.\nAsk it to spawn fewer thinking-heavy subagents with fresh context for multiple subtasks.\nAsk questions.\nQuestion your model and your system. Ask the agent to verify current approaches online, then verify the result yourself.\nReview everything.\nEspecially the boring diffs. AI-generated pull requests need more scrutiny, not less.\nTest by default.\nEncode “always write tests” in your rules so every generation is verified, not merely generated.\nAutomate what you repeat.\nRun 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.\nThe 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.\nEmbed the implementation process into agents\nThe 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.\nThe 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.\nTwo agents. One writes, one verifies. Both have clean context. That alone catches more bugs than a single-agent setup running ten times longer.\nThen 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.\nI 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.\nStart this week\nFocus first on the six guardrails and the three workflows. Evolve toward a setup like Paul’s over time.\nTry it on an actual project this week. Create a\nCLAUDE.md\nwith 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.\nWhatever 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.\nIf you want tailored help growing as an AI engineer,\nlearn about the Towards AI mentorship program\n. We can help with your career and your projects.\nFAQ\nWhat is the core rule for coding with AI agents?\nYou should own the thinking, including the architecture, constraints, and review. Let the agent handle typing, mechanical implementation, and repeatable execution.\nWhat context should I give a coding agent?\nKeep 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.\nWhen should I use a strong model instead of a fast model?\nUse 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.\nHow should I debug code generated by an AI agent?\nStart 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.\nWhy can AI coding make a team slower even when individuals write more code?\nMore 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.\nWhat should I automate after a workflow starts working?\nWhen 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.", "metadata": { "title": "How We Actually Use AI to Ship Code | What's AI", "description": "The three AI coding workflows, context rules, debugging habits, tests, and review guardrails the Towards AI engineering team uses to ship reliable code.", "keywords": null, "author": "Louis-François Bouchard", "og:site_name": "Louis-François Bouchard, aka What's AI", "og:locale": "en_US", "og:locale:alternate": "fr_CA", "og:type": "article", "og:title": "How We Actually Use AI to Ship Code", "og:description": "The three AI coding workflows, context rules, debugging habits, tests, and review guardrails the Towards AI engineering team uses to ship reliable code.", "og:url": "https://www.louisbouchard.ai/ai-coding-workflows-that-ship/", "og:image": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/hero.png", "og:image:secure_url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/hero.png", "og:image:alt": "How We Actually Use AI to Ship Code, with the Towards AI logo and an AI coding illustration", "twitter:card": "summary_large_image", "twitter:site": "@Whats_AI", "twitter:creator": "@Whats_AI", "twitter:title": "How We Actually Use AI to Ship Code", "twitter:description": "The three AI coding workflows, context rules, debugging habits, tests, and review guardrails the Towards AI engineering team uses to ship reliable code.", "twitter:image": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/hero.png", "twitter:image:alt": "How We Actually Use AI to Ship Code, with the Towards AI logo and an AI coding illustration", "article:published_time": "2026-08-21T12:00:00.000Z", "article:modified_time": "2026-08-21T12:00:00.000Z", "article:author": "Louis-François Bouchard" }, "paywall": { "listed_paid": false, "detected": false, "marker": "", "public_only": false, "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙" }, "crawl": { "success": true, "status_code": 200, "error": "" }, "code_blocks": [ { "file": "attachments/956ac6920bb5/code/body-000.txt", "chars": 310, "language": "text" }, { "file": "attachments/956ac6920bb5/code/body-001.txt", "chars": 228, "language": "text" }, { "file": "attachments/956ac6920bb5/code/body-002.txt", "chars": 374, "language": "text" }, { "file": "attachments/956ac6920bb5/code/body-003.txt", "chars": 231, "language": "text" } ], "images": [ { "status": "ok", "url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/ai-stack-three-layers.png", "bytes": 111018, "reused": false, "local_path": "attachments/956ac6920bb5/images/body-565aef46adc2e60da377.png", "src": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/ai-stack-three-layers.png", "alt": "The three layers of the AI coding stack: interface, brain, and context", "downloaded": true }, { "status": "ok", "url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/context-push-pull.png", "bytes": 100104, "reused": false, "local_path": "attachments/956ac6920bb5/images/body-cc86e4758835f8e7378e.png", "src": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/context-push-pull.png", "alt": "A push and pull context model for CLAUDE.md, AGENTS.md, README files, source code, logs, and skills", "downloaded": true }, { "status": "ok", "url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/engineer-tester-loop.png", "bytes": 97778, "reused": false, "local_path": "attachments/956ac6920bb5/images/body-4f63d66a89c2a98d9e9e.png", "src": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/engineer-tester-loop.png", "alt": "A two-agent coding loop where an engineer implements tasks and a tester verifies them in fresh context", "downloaded": true }, { "status": "ok", "url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/multi-agent-development-loop.png", "bytes": 176841, "reused": false, "local_path": "attachments/956ac6920bb5/images/body-487d1a5241a1135be0f6.png", "src": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/multi-agent-development-loop.png", "alt": "A complete multi-agent software development process with planning, engineering, testing, Git, pull-request review, human acceptance, release, and on-call feedback", "downloaded": true }, { "status": "ok", "url": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/takeaway-cheat-sheet.png", "bytes": 66933, "reused": false, "local_path": "attachments/956ac6920bb5/images/body-f556b5b85dd93b0833d0.png", "src": "https://www.louisbouchard.ai/media/posts/ai-coding-workflows-that-ship/takeaway-cheat-sheet.png", "alt": "A takeaway cheat sheet for trying one workflow, creating three project rules, encoding successful patterns as skills, and repeating the loop", "downloaded": true } ], "audio": [], "videos": [ { "url": "https://www.youtube.com/watch?v=9SCkcVKPEy0", "src": "https://www.youtube-nocookie.com/embed/9SCkcVKPEy0", "status": "ok", "kind": "single_video", "local_path": "attachments/956ac6920bb5/videos/repair-9SCkcVKPEy0.mp4", "bytes": 167914613, "valid": true, "height": 1080, "width": 1920, "duration": "1230.041000", "reused": true, "reused_from": "xinxing-zimeiti-corpus/attachments/a6bdfd7b0a18/videos/9SCkcVKPEy0.mp4" } ], "links": [ { "href": "https://www.youtube-nocookie.com/embed/9SCkcVKPEy0", "label": "", "type": "iframe" }, { "href": "https://www.louisbouchard.ai/towards-ai-mentorship-for-ai-engineers/", "label": "learn about the Towards AI mentorship program", "type": "a" } ], "repair_version": 2, "repaired_at": "2026-10-14T10:47:49Z", "source_url": "https://www.louisbouchard.ai/ai-coding-workflows-that-ship/", "papers": [], "actual_video_files": [], "body_chars": 17470, "expected_body_images": 5, "discovery_status": "ok", "delivery_status": "ok", "missing_reason": "", "raw_html": "attachments/956ac6920bb5/pages/source.html", "local_html": "attachments/956ac6920bb5/pages/article.html", "body_base_path": "attachments/956ac6920bb5/pages/", "body_markdown_path": "attachments/956ac6920bb5/pages/article.md" }