The argument in one line.
Good output from AI coding agents comes from the system built around them, not from smarter models or cleverer prompts — a five-step loop of explore, plan, implement, verify, and commit that every serious harness converges on.
Read if. Skip if.
READ IF YOU ARE…
- You're already running Claude Code, Codex, or Cursor daily and want a repeatable system instead of ad-hoc prompting.
- You manage AI agents on a team and need conventions for CLAUDE.md/AGENTS.md files, commit messages, and PR review.
- You're a non-technical 'vibe coder' building an app with these tools and want to know where you still need to make the calls.
SKIP IF…
- You've never touched an AI coding agent — this assumes you already know what Claude Code, Codex, or sub agents are.
- You want a step-by-step tutorial for a specific framework or language — this is workflow and process, not syntax.
The full version, fast.
Good output from AI coding agents comes from the system around them, not from smarter models or better prompts. Every serious harness converges on the same five-step loop: explore with sub agents to protect the context window, draft a reviewable plan, implement across parallel sub agents or git worktrees, verify with tests and adversarial review, then commit in small, well-documented chunks. Keep CLAUDE.md/AGENTS.md files lean, log recurring mistakes so agents stop repeating them, and spend roughly 80% of your time planning versus 20% supervising execution — the bigger the feature, the more decisions need to be nailed down upfront. Use skills for repeatable pipelines, dial reasoning effort up for anything that matters, and mix harnesses by task: cheap fast models for small UI tweaks, expensive frontier models for complex plans.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:16
01 · Cold open: the trust gap
Getting good output from Claude Code or Codex isn't about smarter models or better prompts — it's the system built around them. Cites adoption data: nearly 90% of developers use AI tools, but only 29% trust the output, and about 1 in 5 Codex users aren't developers at all.
01:16 – 07:52
02 · The five-step core loop
Every serious harness converges on the same loop: explore with sub agents to keep the context window clean, draft a plan for human review, implement across parallel sub agents, verify with tests, browsers, or other models, then commit in small, well-documented chunks. Claude Code's 'dynamic workflows' already automate most of this.
07:52 – 10:26
03 · Instruction files: CLAUDE.md & AGENTS.md
Keep these files lean and hand-written, not AI-generated — a bloated instruction file fills the context window on every single prompt. Log recurring mistakes in a memory file linked from CLAUDE.md so agents stop repeating them.
10:26 – 14:28
04 · Plan mode: catch mistakes while they're cheap
Plan mode explores the codebase then hands back a plan to review, often surfacing questions (export format? worker or inline? queueing?) the requester never considered. Spend roughly 80% of the time planning and 20% supervising execution; bigger features with more decisions fail far more often if under-planned.
14:28 – 17:46
05 · Skills: package workflows, pay for them only when used
Skills teach an agent new tools or APIs and load via progressive disclosure, only pulled into context when a matching keyword or tag appears. Contrasts with MCP servers, which inject tool definitions into every session and burn far more tokens.
17:46 – 20:20
06 · Sub agents and parallel fleets
Each sub agent gets its own context window and reports a summary back to the orchestrator. Git worktrees let multiple orchestrators work on fully separate copies of the codebase at once, so five or ten tasks can run concurrently without cross-contaminating context.
20:20 – 22:54
07 · Effort dials: spend reasoning where it pays
Reasoning effort levels, from low to extra-high, trade speed for accuracy. Dropping effort to save tokens usually backfires — re-prompting to fix mistakes costs more than just running high effort in the first place. Reserve low or medium effort for trivial, fast commands only.
22:54 – 24:44
08 · Verification loops, TDD & guardrails
Deterministic guardrails, write the test, implement, run the test, self-heal, matter regardless of effort level, since every model produces buggy code sometimes. Adversarial reviewer agents help because models are agreeable by default and will admit mistakes once directly challenged.
24:44 – 26:34
09 · Headless CI and the autonomy ladder
Harnesses support a headless mode for CI/CD, so a script can trigger an automated review on every new pull request. Full pipelines can run end-to-end in the cloud: an agent opens a PR, another reviews it, tests run in a sandbox, a preview URL gets verified, then it merges.
26:34 – 28:02
10 · Cross-harness patterns
No single model wins everywhere. The presenter uses fast, cheap models for quick UI tweaks and expensive frontier models for complex plans, sometimes chaining models so one adversarially reviews another's output.
28:02 – 29:19
11 · The scoreboard
Closes with adoption data: AI writes about 22% of shipped code at a mid-size company, 20-30% at Microsoft and Google, and roughly 95% at most startups. Developers using AI file about 60% more pull requests per week, though the presenter is skeptical PR and commit counts are a meaningful productivity signal.
Lines worth screenshotting.
- Almost 90% of developers now use AI coding tools, but only 29% trust the output those tools produce.
- One in five people using Codex aren't developers at all — they're non-coders building entire apps by vibe coding.
- The five-step loop every serious AI coding harness converges on is: explore, plan, implement, verify, commit.
- Sub agents exist mainly to protect the context window — the more sub agents doing the exploring, the less unnecessary information pollutes the main session.
- About 80% of the time on an AI-assisted feature should go into planning upfront, and only 20% into supervising execution.
- A feature with only two or three real decisions is safe to run with a single prompt; a feature with 20 decisions needs heavy planning or it will likely get built wrong.
- MCP servers inject their tool definitions into every session's context window, which is why skills — invoked only when needed — burn far fewer tokens.
- Reasoning effort levels trade speed for accuracy: dropping to a lower effort level to save tokens usually costs more in re-prompting and wasted time than it saves.
- Models are agreeable by default — challenged with 'you did this wrong,' they'll often admit the mistake, which is why adversarial review agents catch more bugs than a single confident pass.
- Git commit history doubles as an AI memory system: a well-documented commit lets an agent git-bisect its way back to exactly where a bug was introduced.
- At most startups, AI now writes about 95% of shipped code, versus roughly 20-30% at large, legacy-heavy companies like Microsoft and Google.
- Developers using AI file about 60% more pull requests per week, though PR count is a shaky productivity metric since commit granularity varies wildly by developer.
- One presenter reports spending over $200 on a single prompt using a frontier model's API tokens — reasoning effort and model choice have real cost consequences.
Five habits decide whether an AI agent ships good code or garbage.
WHAT TO LEARN
The output quality of Claude Code, Codex, or any other agent comes down to the loop and guardrails wrapped around it, explore, plan, implement, verify, commit, not which model or prompt you use.
02The five-step core loop
- Treat AI coding as a five-step loop, explore, plan, implement, verify, commit, rather than a single one-shot prompt, and expect the harness to have already automated most of it.
- Delegate the exploration step to sub agents specifically to keep your main context window free of code-base clutter.
- Route the implementation step through parallel sub agents when a feature splits into independent front-end, back-end, or API pieces, so unrelated context doesn't need to load.
03Instruction files: CLAUDE.md & AGENTS.md
- Keep your CLAUDE.md or AGENTS.md file hand-written and short; every line in it gets reloaded into every single prompt's context window.
- Log the mistakes an agent has made before in a memory file and link it from CLAUDE.md, so the same error doesn't repeat session after session.
04Plan mode: catch mistakes while they're cheap
- Let plan mode interview you before code gets written; the questions it asks about export format, worker vs. inline, or queueing surface decisions you didn't know you had to make.
- Budget roughly 80% of your time on planning and 20% on supervising execution, since a wrong plan that runs unsupervised for hours wastes far more tokens than the planning phase costs.
- Scale planning effort to the number of real decisions in the feature; two or three decisions is safe to run with one prompt, twenty decisions needs a reviewed plan or the odds of getting it right drop sharply.
05Skills: package workflows, pay for them only when used
- Reach for a skill, not an always-on MCP server, when you want a repeatable pipeline; skills only load into context when invoked, while MCP tool definitions load on every session regardless of use.
- Version-control skills so a whole team gets the same standard approach to a recurring task instead of everyone reinventing it per session.
06Sub agents and parallel fleets
- Give each sub agent its own context window so it can explore or implement a bounded piece of work and hand back only a summary, not its full working context.
- Use git worktrees to run multiple independent orchestrators on the same codebase simultaneously, each kicking off its own sub agents without cross-contaminating context.
07Effort dials: spend reasoning where it pays
- Default to the highest reasoning effort level available unless you're running a trivial, fast command; tokens saved on a lower setting are usually spent again on re-prompting to fix mistakes.
08Verification loops, TDD & guardrails
- Build a deterministic verify loop, write the test, implement, run the test, let the agent self-heal, regardless of effort level, since every model still ships buggy code sometimes.
- Have a second agent or model play adversarial reviewer; models are agreeable by default and will readily admit a mistake once directly challenged on it.
09Headless CI and the autonomy ladder
- Wire a headless-mode review into CI so every new pull request gets one more automated pass before a human looks at it.
10Cross-harness patterns
- Match the model to the task's cost and speed tradeoff, a fast cheap model for a small UI tweak, a frontier model for a complex plan, instead of defaulting to one harness for everything.
11The scoreboard
- Don't over-index on PR-count or commit-count stats as a productivity signal; they vary wildly by how granular a given developer's commits are.
Terms worth knowing.
- CLAUDE.md / AGENTS.md
- Project-root instruction files that AI coding agents read automatically before working in a codebase, covering conventions like commit message format, test requirements, and architectural decisions.
- Sub agent
- A separate AI agent instance spun up by an orchestrator to do a bounded piece of work, like exploring a codebase or writing tests, in its own context window, then reporting a summary back.
- Git worktree
- A complete, separate checkout of a codebase's files in another folder, letting an agent work on a fix or feature without touching the main session's active branch.
- Plan mode
- A mode in coding harnesses like Claude Code where the agent explores the codebase first and proposes a written plan for the human to review before any code gets written.
- Effort dial / reasoning effort
- A per-model setting, such as low, medium, high, or extra-high, that controls how many tokens a model spends 'thinking' before acting; higher settings cost more but make fewer mistakes.
- Headless mode
- Running a coding agent from the command line with a single prompt and no interactive session, typically wired into CI/CD so pull requests get an automated agent review.
- Architectural Decision Record (ADR)
- A short document that records why a particular technical decision was made, such as choosing Postgres over another database, referenced by agents before they touch related code.
- MCP (Model Context Protocol)
- A protocol that lets an AI agent call external tools or services directly; its tool definitions load into the context window automatically, which is more token-expensive than a skill.
Things they pointed at.
14:13toolMatt Pocock's "grill me" skill
Lines you could clip.
20:41
“If tokens were free, I would say use extra high for everything you do. Literally everything you do.”
24:01
“They think that what they're doing is 100% correct. You go back and say, hey, you're doing this wrong. They're like, oh yeah, by the way, yeah, I messed up.”
24:30
“The worst is when you spend two or three hours waiting for these things to finish and you load up the UI and it's just broken.”
27:28
“I've used over like $200 with one prompt before with Fable five API tokens.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphor
00:00The information I'm gonna give you may fundamentally change how you think about agent decoding because getting better results from these tools like Claude Coding Codex is not just about using smarter models and using better prompts. It's all about the systems that you build around these tools. And once you understand better systems such as managing context, delegating tasks with sub agents, or having harnesses or skills in place to make your output even higher quality, you'll stop thinking about these tools as simple chatbots and instead as that you can use at your disposal.
00:28Now if we were to look at these statistics almost 90% of developers are using AI tools which is increasing every year, but only 29% of them actually trust the output. So there is a fundamental issue with using these tools but using good structures around them can actually increase the output and give you more confidence that what they're producing is of higher quality.
00:47And you can also see over here Codecs and ClaudeCode is still growing. One in five people using Codecs aren't even developers so people who have no coding experience are able to vibe code entire applications which if you are a vibe coder this talk will also be very relevant to you. So let's move on to talking about the core loop that all these harnesses basically follow.
01:05So if you want the best output from these tools you should probably follow a similar type of structure and honestly most of these tools probably do this for you without you thinking about it and the output of these harnesses are getting better over time. But out of all the cool features and all these different harnesses the thing that you should focus most on is how to manage the context window.
01:24The models are built with limitations. They do have a cap of how much information you can provide them and as that context window fills up they will become less and less intelligent. Luckily we have ways to delegate sub agents so that the context windows stay short and fresh.
01:40Also, making sure that you don't prompt too much at a time and clearing the window is another strategy that you can do. But overall, if you're trying to add in like a new feature or build out an application, here are the five steps that you should be taking to make sure that the output in the structures around your harnesses and your models are actually high quality.
01:57So the first step is you should be delegating sub agents or even just using a plan mode to go off and find as much relevant information in your code base, maybe it needs to read over documentation files or go read your agents m d or maybe have skills that are set up, it needs to go off and explore and the more sub agents you have doing this the faster it can kind of give back relevant results.
02:17You don't want to pollute the context window with a bunch of unnecessary information which is why sub agents can kind of keep the context window as lean as possible. After you let the harness explore you can go and then create a plan.
02:29This could be creating an MD file, this could be multiple MD files split up into different phases and for each phase you can have different tasks. This allows replayability if your computer were to crash you can come back and resume the session and even have different models work on different tasks at the same time. So planning obviously if you're using Cloud Code it has a plan mode built into it.
02:47Some people like to do their own approach and have their own MD files. Now the key takeaway with the plan mode is reviewing the plan.
02:54If you are technical, if you're an engineer, should review it for technical decisions so that you can tweak the plan to meet the needs of your business or your product.
03:03But if you're a vibe coder you're not technical you should be reviewing the plans for at least business decisions, product decisions. Should the button be over there? When you click it, what should it do?
03:12Right? These are things that should be included in the plan and you need to have some type of control to make those decisions about where your products going. Granted, the models can basically plan it all out.
03:21They can design the system for you. They can pick the the best design if you let it. They can pick the best user experience if you let it, and you provide it enough skills to do so.
03:29But at least trying to be in the loop a little bit, having a human in the loop can make the outputs that much better so that you don't have to go back and re prompt because you didn't fully understand the plan of what the model is about to build and now you have to go back and reiterate and reiterate, burn through tokens, waste more time.
03:45The third step of this loop is the implementation stages. So this is kicking off many sub agents that go off and work on smaller parts of the code base often if you're building out an API endpoint. Why does the context window need to know about the front end in that, uh, scenario?
03:58Right? Maybe it needs to know about some type of interface, they can share communication across that interface or adapter, but you can have sub agents go off and build out different parts of the system so you can increase the throughput and not have to wait as long.
04:10The more sub agents you can use typically the faster this will run. Now granted, Blogcode has something called workflows, dynamic workflows which kind of does all this for you.
04:18This is why they added this feature. They have a way, a system that basically does all this for you and if you're not going to build your own type of core loop you should probably just leverage the harnesses loop because they kind of done the heavy thinking upfront for you to get the stuff to be as accurate as possible. Now the fourth step, this is by far the most important, this is the verify step.
04:38You should have these agents run into in test, they should load up puppeteer, they should load up a browser, they should be clicking through the UI and verifying that what they're doing is actually accurate. And often in this stage, the verify stage, you'll see it go back and fix. Like it basically if you imagine there's a loop here, it's gonna go and verify and then go back and implement.
04:56Go back and verify, go back and implement and you can take the verify stages as far as you want to. You can give it API keys for your deployed staging environment. You can say, hey, get this deployed out to a staging environment.
05:07I want you to go then get a browser and click through it, make sure it's all set up, make sure the database is actually persisting properly and reading back values. The more robust your verify stages are, the the better it's gonna be. You can also have agents, other models come through and verify.
05:21So if you're working with Claude code or let's say Fable five, you can then have SOL, GPT 5.6 SOL go back and verify all the work that Fable did. And again you can just do this in a loop depending on how much money you have, , you can have these agents and burn through tokens to verify, to reimplement, to redesign, to check for security audits, to check for performance issues, make sure the code is clean and clear and concise.
05:47These are all things you can add in with skills to actually go through make sure the code is the highest quality as possible. Now the last step is committing. You should be committing or at least telling the agents to commit small chunks of work every step of the way.
06:00These commits have useful history inside the commit message and they can let the agent go back in time and try to understand and debug how the system has changed over time. Typically .
06:13It has all of the changes and if you let the AI commit really useful concise messages of why we changed the thing, this is the change. If you run into a bug in the future, it can use a git bisect, it can go back and dive through the changes and try to figure out where exactly it broke that particular thing. Or maybe it was an actual business change that you made that can be documented in commits or you can just have those be documented in like a memory MD file.
06:36You can have these agents also build out architectural design decisions and it can put that in a folder so that later on you can have a Claude MD file or an HSMD file reference those to say, hey, before you add in any code to the code base, make sure you go and look at the decisions we made in the architectural design records so that in the future it doesn't maybe change the design or understands with more context how it all works.
06:58Now you can also hook in your loop to actually go and look at GitHub issues. Often a lot of teams will use GitHub issues to define the user stories and what needs to be done, the acceptance criteria, and you can link the stories with the poor requests with a tag like an ID and then you can also have that ID be in the commits.
07:14So the more information you can give in terms of your commits, your GitHub issues, your poor request, it allows your agents to go and explore your code base and find the relevant context. So this is the loop that honestly a lot of this is abstracted away from you at this point but understanding how it kind of works under the hood is extremely important to become the best agent decoder that you can be.
07:33Alright. So let's move on to the next section which is the Claude MD and the agents MD file. You've probably heard about this, there is some difference in opinions on if these are useful or not.
07:42I think these are very useful but you need to make sure that they're clean and concise. Do not let AI generate these things, you should just go through and add small bullet points of what exactly you want the agents to understand when they're building on this code base. A lot of the times these agents are smart enough now to go and explore your package JSON file to understand what scripts they can run off the bat, but if there's any edge cases or caveats you should point maybe put that in your Claude MD file.
08:08Right? For example, if you want to make sure that all work that's done from an agent does test driven development, you should put that in the Claude MD to say, hey, do test driven development.
08:18Make sure you have unit test integration test end to end tests written before you actually start implementing the code changes or the fixes. You can define how the commit messages should look here. So you could say every commit message must have a GitHub issue in the commit.
08:31All pull requests must have that GitHub issue number. Any new GitHub issues that the agents create must follow a certain pattern. Now just keep in mind that these files, if you have too much information in them, they are going to fill up your context window.
08:43And so I would keep these lean and concise so that every single agent that runs on your code base follows a very similar approach. For example, what you can put in here is your exact build test and link commands which even this is a little bit too much. It can read the package JSON and understand how to do this stuff.
08:58But like I mentioned, you could do code styles in here. You can do repo etiquette, branch naming, PR conventions, architectural decisions. So going back to the ADRs I talked about, you can have in the CloudMD a link to your ADR docs file so that every time before the agent starts planning or exploring the code base, it knows that you have a whole list of documents that explains why you're using Postgres, why are you using this for your queuing mechanism, why are you deploying this stuff to AWS RDS.
09:25Right? These things help guide the agents so they can become a lot more accurate with the output that they're making. Okay.
09:30This one's important. Mistakes the agent made before log so that they don't repeat. Now some people use like a memory dot MD file and most of these harnesses have memories built in, but you could have a skill that automatically runs at the end of every session to summarize the things that it messed up on and put that in an MD file and link to it from the Claude MD or the agents MD so that next time when you do something in the agent it's not gonna repeat that same silly mistake.
09:55One thing that I've seen for certain when you're kind of using these tools is if you read through the output as they're running you will see that they will consistently make very similar mistakes and unless you have a system in place to let it learn from these mistakes it'll just keep on making them. Okay?
10:09So I recommend using these but keep them clean, them concise, don't let AI just automatically generate a 5,000 line agents md file. Put the things that you want to direct the agents in this and that's it.
10:23Alright. The third important thing to talk about is the plan mode and like I mentioned with the core loop, plan mode typically will go off and explore your code base with sub agents. So it kind of takes care of that and it'll come back and it'll generate a plan for you that you should review.
10:35If you're a vibe coding you should still review the plan, you can have the agent summarize it and be less technical if you want, but I think the true benefit of the plan mode is that often it starts to ask you questions. Right? If you ask for a very feature like, hey, I want you to add in a way for users to export all their data from my application, there could be five or six other questions that it needs to ask you.
10:58What format should the export be in? Should it be in a CSV? Should it be a zip file?
11:02These are things that sometimes you don't think about until you kick off a plan mode, and then the agent will guide you to build out a better user experience, plan out a better architecture because let's say you have gigabytes of data.
11:15You can't just put that all in a zip. You have to do that in a worker, which means you might need an SQS queue or some type of queuing system in a in a background worker to even handle all that data. What if the user decides to click that button and spam your system and it keeps grabbing 10 gigabytes of data and putting that in a zip and then after 100 runs, it crashes your services.
11:33These are things that you sometimes don't think about especially if you're a vibe coder you're not technical that the plan mode can potentially help with and honestly when you're planning out you should probably have some type of MD file that helps guide you through these performance decisions, the technical decisions, also the user experience decisions, uh, the business requirements.
11:52Because often if you just give a very simple sentence of hey, I need the ability to export data, you're gonna miss eight or nine different really important things that you didn't think about. Now another reason you should be using plan modes is because once you kick off that plan and tell these agents to go off and implement it, this can take a long time.
12:09This can take hours. And so if you let this plan be implemented for four or five hours and you come back and realize, oh crap, I didn't properly describe what I wanted, now you just burn through a ton of API tokens or AI tokens and now you just wasted a bunch of time and if you just take the due diligence upfront to verify the plan, make sure it seems like it's good, even have other agents review the plan is a good strategy.
12:32Sometimes I'll make the plan and clog code, I'll have Codex go back and review the plan and then I'll have one more pass through with like another agent to go make sure the plan is as thorough as possible because once you kick this thing off like I mentioned it's gonna burn through a lot of tokens. So let's take a quick peek at this graph.
12:45So this graph is basically showing you the larger the feature is and the more decisions that the AI makes for you, often the higher the chance that it's gonna get it wrong. Right?
12:54So if you have a feature that's 20 decisions like I mentioned, how was the export format? Where is this export going to run? Is it in a worker?
13:01Do you want it to run-in the API? If you don't clarify those decisions and really think through them, there is a much lower chance that it's going to get the stuff right. If it's a really simple feature like let's say it's only two or three decisions, the chance of it actually building what you want is much higher.
13:17So you should think about this. If the feature you're adding in is huge, you need to spend more time upfront planning it.
13:23If the feature adding in is very small and simple, you might not even need a plan. You can just kick off a single prompt, no plan mode, YOLO it, and it's gonna implement probably what you want 100%, 95%, or 90% of the time. Now from my research it's saying that about 80% of your time should be spent upfront on the plan mode and then 20% should be supervising the execution.
13:43Okay? And like this chart kind of demonstrates, the more time you spend upfront in the plan the better the outputs and the results are gonna be. Okay?
13:50A good strategy is to have the agent interview you so it can ask you a bunch of questions. There's skills out there like Matt Pocock's grill me skill. This is basically what it's saying.
13:59Most people do not think about all these edge cases before they start building out the feature. Having the agents ask you question after question after question so it has a really clear understanding what you want built, this is one of the keys to having better outputs from these harnesses and agents.
14:14Alright so let's move on to skills. Skills are very important. These are things you can add in to your ClaudeCode instance.
14:20You basically teach it how to do new things. These models are trained with a certain subset of data and that data has a particular cut off.
14:27It could have been cut off a year ago. So if there's a new service that you're working with, these models may have no context of how that service works. They might not know how to use the API, etc.
14:36So one thing you can do is create a skill file and put it in your dot claud folder so that when claud runs and you prompt it, hey I need you to connect to this API and do something, it can actually learn about how to exactly talk to that API. Granted, there are other approaches too.
14:50You can just give it the documentation of the API and it could probably figure that. Give it the swagger docs, give it some type of schema and it could probably understand how to connect to the API, but the cool thing about skills is something called progressive disclosure.
15:03So you have all these skill files in your project and basically they will only kick in when you say certain keywords. Right?
15:10Let's say you're working with a service called fleet. If in your prompt you say I need you to connect to the fleet API, that's when I'll go and kick in the skill with progressive disclosure and then pull all that information into your context window.
15:23Like I mentioned at the very start, the context window and managing context is very important so you don't want these things to be included in every single prompt, want these harnesses to pull them in only when they're needed to keep the context window very slim and clean. So I want to point something out that's kind of important with this table.
15:39As you can tell using an MCP server is going to burn through a ton of extra tokens every single session. The way it works behind the scenes is the MCP is gonna automatically inject its information into your context window so that the agent knows it can call certain tools.
15:54Now the issue with this is it burns through a lot more tokens. It fills up your context window. So skills came out to try to mitigate that issue and now the skills are only invoked when they're needed and you typically have something called front matter in the skills like a little header at the top of the file that describes when the skill should kick in or as a agentic operator you can just tag it.
16:15Right? You can just tag the skill and say, hey use this skill, I need you to go and figure out how to interact with this API. So when do you use a skill?
16:21A skill is very useful when you want some type of repeatable pipeline. So I have a skill that I use that basically is a complete workflow of from planning to implementation to auditing. I kick it off every single prompt.
16:32It's called my ship skill. I say use the ship skill and that's gonna go off and kick off a bunch of different things to make sure that the code that's being written by Cloud Code and Codex is of a higher quality.
16:42I tell it to look for security issues, I tell it to look for performance issues, I tell it to make sure that stuff is cleanly decoupled, we have adapters and interfaces, stuff like that. So if you want a repeatable approach to how the agent should work, can provide the skill and then invoke it when you need it because sometimes you don't need it.
16:58Sometimes you just want to make a simple little UI tweak. Why would it need to go through and do a security audit and a performance audit for a simple little text change in the UI. Right?
17:06So now some other good things to point out about how teams use skills is that they're version controlled. So you can have a skill that's shared amongst your whole organization, your whole team, so that you can all have a standard way of interacting with different tools or have a standard output of how these agents kind of work.
17:23Like I mentioned my skill, if you install it it's gonna go ahead and try to make the quality and the output of your code much higher. Alright.
17:30Let's scroll down to module five. So this is sub agents and parallel fleets. So you've probably seen this when you prompt Claude code.
17:36At the bottom it's gonna say it's running a certain sub agent to go explore your code base. Right? Now you can have different custom agents.
17:43You can have a test writer sub agent that's really smart at how to write tests, to run those tests, how to verify those tests against your code base. You can have a research agent, it knows how to go online and find stuff and aggregate that together and give it back to the orchestrator.
17:57And then the orchestrator can have a plan agent that really knows how to write plans that match your type of output. For example, let's say you're a vibe coder, you don't want all this technical jumbo in the plan, you just want like a high level overview at the bottom of what you need to read.
18:10You can have your own agent that customizes how the plan actually looks like when it writes it out. Now the benefit of this is that the agents all get their own context window. So you can feed it a bunch of information from the orchestrator directly into the agent, the agent can go and explore and read in files and do different things, and then finally it's gonna give a summary at the very end which will go back to the orchestrator and the orchestrator can decide what to do with that small summary to kick off more sub agents to do more work.
18:37Now one great use case of sub agents is to make the work run faster Instead of just having one session window go through and implement all these different file changes, you can kick off 10 or 20 sub agents going through your code base modifying the code concurrently and then when it's all done you can come back and then kick off more sub agents to go off and do code reviews or code audits etc and keep going back and forth between that.
18:58Now one of the key unlocks to sub agents like I mentioned is concurrency and if you were to use git work trees you can have many different orchestrators working on different sub trees kicking off many different sub agents on those work trees so you can get five or 10 tasks done at the same time.
19:14If you don't know what a git work tree is basically it's a complete clone of your code base that's put into a directory and then you could have Cloud Code work on that work tree. So like let's say you run into a bug when you're kind of clicking through the UI you can kick off a quick prompt and say hey I need you to do some work in a work tree to fix this bug.
19:30It's going to kick all that off, it's not going to modify the existing context window of your orchestrator session. I'm going to do that work in a work tree, it's going to use sub agents to keep the context windows clean, it's gonna get the work done, you can prompt it to make a pull request when it's done and then you can have other systems in place to review the pull requests.
19:46Finally you can have that be merged in by human or even AI merge it in when it's verified that it's actually good. But some of the cool things that we're seeing today are like sub agent teams, the dynamic workflows. I'm sure you've tried this in Claude code where a lot of the things you don't even need to think about at this point like the the harnesses will take care of this, they will kick off many different sub agents, they'll have specific sub agents that are good at doing different things and honestly the models are smart enough where they know what a good senior engineer is.
20:11Right? It can find the context that's needed to make the output of the agents be better. Alright.
20:15Let's talk about effort dials. This is very important when it comes to using these models because it's a lot of information. You have Claude code, it has low, medium, high, extra high, max, it has the workflows, you have codecs, it has soul, it has Luna, it has, uh, what's it, Terra.
20:30There's a lot of stuff going on. A lot of different models. Every model has different reasoning effort levels.
20:36Which one do you pick? Now this is a hard one to answer because if you had an infinite amount of budget, like if tokens were free, I would say use extra high for everything you do.
20:46Literally everything you do. And the reason I recommend that is because when you start trying to use like a medium because you're trying to save on some token costs, basically what happens is if there's a chance that it's gonna get the thing wrong, you end up spending more time and more money re prompting it, wasting time, letting it run, and try to fix what it messed up on.
21:04So the only time I probably drop into lower effort modes is if I want it to run a little bit faster. Let's say I just wanted to run a really quick CLI command to spin up my service, maybe I'll drop into medium or low and say, hey, just run my app. And that's gonna spend less time thinking and more time just doing the work, but for most work or bug fixes, honestly my best opinion to you guys is just keep it on extra high.
21:27If you're using Claude code with opus 4.8, I always keep it on extra high. If you're using fable five, maybe keep it on high because like I mentioned there is a trade off with the effort levels.
21:38And how it works behind the scenes is that there's an allocation like there's like a max limit of how many tokens can go into thinking. So as you use a higher level, it's gonna spend more time and more tokens thinking about the work before it actually starts doing the work.
21:51I guess another thing I could recommend trying, if you're new into AI coding and agent decoding, try doing the work with low effort on everything. Just try it with low, you'll start to see how it's messing up stuff.
22:02It's like edge cases are getting missed. There's a bug that it didn't fixed. Now try on medium, you'll notice that okay, it did a much better job but it cost a decent amount more money and then try high and try extra high just as an experiment.
22:13But if you just want to kind of like screw it, just want like stuff, I want good outputs, probably just use a higher reasoning, uh, effort level. I found that even for like small UI tweaks, I've tried lower effort levels and it still like doesn't fix it and then I re prompt it again, it can't fix it. I switch it to an extra high effort level and it fixes it.
22:30So just from experience myself, I don't even mess with the low effort levels. I just don't think it's it's worth your time. You're gonna end up re prompting and trying to fix it multiple times.
22:38So module seven, this is the verification loops in test driven development and deterministic guardrails. This is by far out of all the things I've talked about if you're trying to do autonomous coding and you want to make sure that the code is actually working before you go and load up your local web browser to test it, you need to have good guardrails in place to basically try to write tests, let the agent implement the code, run the tests, and then the agent will basically self heal and try to fix the mistakes that it's gonna make.
23:05Without a doubt it doesn't matter what effort level you're on, these agents will churn out bad code, broken code, buggy code, but having the verification loops in place to make it go back and double and triple and quadruple check its changes will make the output much better when you come around and actually test it manually yourself.
23:23Now one of ways you can kick this in is by saying run the test after implementing. Now I like to use a goal like in clog code you can say slash goal and I will say continue to run the test until everything is passing.
23:37Okay? Give it a goal condition. Tell it to run the test.
23:40Tell it to go through and audit the code. The adversarial reviewer, this is also very good where it tries to find reasons as why the code it wrote is bad. It should go through the code, should nitpick it, it should say no this architecture is bad so that you can at least have more agents understanding the code that's being written and really challenge it because a lot of these agents and models are very agreeable.
24:01They think that what they're doing is 100% correct. You go back and say, hey, you're doing this wrong. They're like, oh yeah, by the way, yeah, I I I messed up.
24:07So the more models and agents you have basically reviewing and picking apart the code changes, the higher quality output will be at the end by the time you come around and review the pull request if you're a developer or technical or just if you wanna load it up locally and click around. The worst is when you spend two or three hours waiting for these things to finish and you load up the UI and it's just broken.
24:26You're like, okay, AI sucks. No, it's because you don't have proper guardrails in place to very verify the code that's being written is actually good. So module eight is headless CI in the autonomy ladder.
24:37So like I mentioned when these agents are done running they can create pull requests. You should probably have some system in place to see when a new pull request is opened up. It should go through and do one more review on all the code to make sure that it doesn't have particular issues.
24:52And the way you do this is by using the headless mode. So Claude code, codecs, all these harnesses have a headless mode option where you can just run it with a prompt and so if you're using CICD like GitHub actions you can just write a custom script to review the code changes using a Claude headless mode just to give that one extra certainty.
25:09But honestly I think that if you are just better at doing all these checks while you're coding, you don't even need the whole pull request unless you're working with a team of other engineers and you still have some engineers who are like manually coding which is honestly, lot of people are still manually coding. There's some people still copying and pasting code from the Claude web into their IDE.
25:28If you're watching this, you're probably ahead of the game, like you're probably at the the tip of the iceberg of agent decoding because there's a ton of engineers who do not touch this stuff. They don't care about this stuff, um, but they will eventually need to care about this. There's really not much I wanna talk about here.
25:41I mean like you can basically have with the headless mode, can have autonomous agents running nonstop reviewing code. You can have a a product owner agent who goes through and tries to understand what you should add next to your product and then you can have that hook into a get of action to automatically pull that issue and work on it and then it can make a pull request.
25:58You can have a headless runner go and review the pull request and then that can trigger more agents to go through and open up a sandbox to run the code in, verify it with real tests, it can load up a preview URL that you as the developer can click into and you don't even have to run this up locally, this could all be in the cloud at this point, you can verify all the results in the cloud and then click button to merge it into main and it gets deployed up.
26:20Okay? So pretty crazy times we're living in and then of course I did mention this a couple times in my talk, this is the cross harness pattern. So don't just use cloud code, I use cloud code, I Codecs.
26:31I use Cursor CLI. I use different models. Like I like to use Grok 4.5 for simpler tasks.
26:37Often a UI change, I use Grok 4.5 because it's fast and it's cheap. For the more complex plans, I use Cloud Code Fable.
26:45For some work in between, maybe you'll use 5.6 Sol. Right?
26:49I would say that learn all these different harnesses because they all have their strengths and they all have their weaknesses. Some models are extremely slow. Like, I don't wanna wait thirty minutes for ClaudeCode to make a UI change.
26:59I would rather kick that off in the composer 2.5 or Grok 4.5 because it's gonna run much faster and I don't want to sit there waiting for so long to verify the results. And then also this can be done by like a an adversarial review.
27:12You can have one agent review the output of others. You can tie them all together in a giant chain. Uh, this is very very important to kind of understand where the models shine in the cost analysis of them.
27:21Some models are extremely expensive. Fable five, I've used over like $200 with one prompt before with Fable five API tokens. So you need to keep that in mind unless you're using subscriptions which I was at the time.
27:32Some people are not able to use subscriptions, they're at work, they're using API costs. Some of these models and harnesses are just not possible for them to use. So definitely keep that in mind as you're going through.
27:43Then finally the scoreboard. Okay. So where does the adoption of all these tools actually stand?
27:48Maybe you're currently all in on a genetic coding, maybe you're not. But from the research that I found it says that a share of ship code written by AI is 22% for a medium company, for Microsoft is about 20 to 30%, from Google is 30%, and for most startups they're saying it's 95%.
28:05K. So a lot of startups are basically letting AI write all the code. The bigger the company you're at, the more legacy code there is, the more red tape and process there is in place where you can't just let these agents run autonomously.
28:16Right? You do have to be a human in the loop verifying this stuff because because the systems can get very complex and not having a human there to review this stuff is kind of scary when you drop production or you break production and now millions of users can't use the app because the AI just did something, uh, that you could have caught.
28:33Right? Now this graph over here is basically saying the people who are using AI are doing about 60% more poor requests per week. Now I don't think the analytics around poor requests and commits are very useful.
28:44You can have one developer is doing a 100 commits a day because they make their commits very small and isolated versus one developer could do one commit a day, but they have 50 file changes in their commit. Okay? So some of these stats are kinda silly, honestly, but I would agree that the people using AI are moving much faster.
29:01K? I feel much faster. I move much faster.
29:04I can work on many different projects currently using AI. And then at the very end, we have some sources of all the information that I found to basically make this article. So yeah, if you guys like this, uh, talk, let me know.
29:14Leave a comment below and I can make more videos like this in the future if you guys are interested. Have a good day and happy
The Hook
The bait, then the rug-pull.
Nearly everyone writing code with AI is doing it without a system. This is the five-step loop, from context management to commit discipline, that separates agents that ship real work from agents nobody trusts.
Named ideas worth stealing.
01:50list
The Five-Step Core Loop
- Explore
- Plan
- Implement
- Verify
- Commit
The repeatable loop every serious AI coding harness converges on: sub agents explore the codebase to gather context without polluting the window, a plan gets drafted and reviewed by a human, implementation runs across parallel sub agents, verification (tests, browser clicks, other models reviewing) catches mistakes before commit, and small well-documented commits close the loop.
Steal forany internal process doc for how to brief an AI agent on a new feature
13:50concept
The 80/20 Planning Split
Roughly 80% of the time on an AI-assisted feature should go into upfront planning, and only 20% into supervising execution, because a plan that's wrong burns hours of unsupervised agent time and tokens before anyone notices.
Steal forscoping any AI-delegated project, code or otherwise
How they asked for the click.
VERBAL ASK
29:12subscribe
“If you guys like this talk, let me know. Leave a comment below and I can make more videos like this in the future.”
Soft, low-pressure engagement ask in the final seconds — no on-screen pitch for the paid/free offers linked in the description.
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
