AI-assisted coding needs smaller loops
Notes from Matt Pocock's advice on context limits, vertical slices, TDD, and where human judgment still matters.
Source: Matt Pocock's video.
The more I use AI coding agents, the more obvious one thing becomes: the tool is only as good as the workflow around it.
Matt Pocock's advice on AI-assisted coding is useful because it avoids the lazy version of the conversation. It is not just "prompt better" or "use a bigger model." The point is more practical: keep the model inside a small, well-shaped problem with fast feedback, then use human judgment where it still matters.
Stay inside the smart zone
Large context windows are useful, but they are not magic.
A model may advertise 200k tokens, 1M tokens, or more. That does not mean the conversation stays equally sharp as the context fills up. The more tokens you add, the more relationships the model has to track. Eventually it enters what Matt calls the "dumb zone": the place where it still sounds confident, but starts making worse decisions.
The practical rule is simple. Keep tasks small enough to fit inside the model's smart zone. In practice, that means keeping active context fresh, focused, and usually well under 100k tokens.
Compaction helps, but it is not the same as a clean reset. Sometimes the correct move is to clear the context entirely and restart from the base state. The Memento analogy is crude but accurate: damaged memory makes bad decisions look coherent.
Get grilled before code
The pure specs-to-code version of vibe coding sounds clean and usually fails in practice.
The promise is seductive: edit a spec file, hand it to the agent, and let the system compile software from requirements. The problem is that you lose your handle on the codebase. You stop designing the thing and start reviewing whatever the model happened to infer.
A better pattern is to make the agent interview you before it writes code.
Use a "grill me" prompt. Make it ask one question at a time. Force it to clarify the product, architecture, edge cases, constraints, data model, UI expectations, and failure modes before it touches the repository.
That process is slower at the beginning, but it creates shared shape. The agent is no longer guessing from a vague spec. It is helping you turn blurry intent into a design you can actually inspect.
Build vertical slices, not horizontal phases
Agents naturally drift toward horizontal implementation plans.
First they want to build all the schemas. Then all the API routes. Then all the UI. It looks organized, but it delays integrated feedback until the end, which is exactly when mistakes become expensive.
Vertical slices work better.
A vertical slice, or tracer bullet, cuts through the whole stack. One issue might include the data shape, service logic, and the smallest useful UI for a single behavior. It does not need to be complete. It needs to prove that the layers work together.
This matters because AI agents need feedback as much as humans do. A vertical slice gives you something real to run, review, and correct. A horizontal phase gives you a pile of parts and a lot of deferred risk.
Prefer Kanban over sequential plans
Long sequential plans serialize the work.
Only one agent can really follow "phase one, then phase two, then phase three" without stepping on the rest of the plan. That is a bad shape for parallel execution.
A better structure is a Kanban board of independent issues with explicit blocking relationships. If task C depends on tasks A and B, say that directly. Treat the work like a directed acyclic graph, not a long checklist.
That gives you two advantages. First, it makes the real dependencies visible. Second, it lets multiple agents work on non-blocking tasks at the same time.
The board matters because it separates planning from scheduling. You can still have a product direction, but execution becomes a set of small, independently verifiable units.
Make AFK coding earn the right to exist
Planning should stay interactive. Implementation can sometimes become AFK work.
That split only works if the codebase has strong feedback loops. Without tests, type checks, linting, smoke tests, and clear failure signals, an agent coding alone is just producing text into the dark.
TDD is one of the best ways to tighten the loop.
Make the agent write a failing test first. Then make it implement the smallest change that passes. Then run the checks. The test is not just ceremony. It gives the agent a target and gives you evidence that the behavior exists.
AFK coding is not magic autonomy. It is automation sitting inside a system that can reject bad work quickly.
Design deep modules for the agent to work inside
Garbage codebases make garbage agents.
A codebase full of tiny, highly coupled files is hard for humans to navigate and even harder for models. The agent has to chase relationships across the graph, keep too many local conventions in memory, and guess which detail is important.
Deep modules are better.
A deep module has a small, stable public interface and hides a lot of internal behavior behind it. That shape gives the human a useful design surface and gives the agent a bounded interior to work on.
This is where the human engineer should spend taste and judgment. Design the interfaces. Decide the module boundaries. Make the external behavior boring and stable. Then delegate implementation inside that box.
Do not automate taste away
The final lesson is the least convenient one: human review still matters.
AI can generate code, tests, docs, scaffolding, migrations, and review notes. It can move quickly when the task is shaped well. But manual QA and code review are where taste enters the system.
That is where you notice whether the interaction feels right, whether the abstraction is worth keeping, whether the code is merely passing checks or actually belongs in the codebase.
The goal is not to remove the engineer from the loop. The goal is to move the engineer to the highest-leverage parts of the loop: designing the work, constraining the agent, reading the output, and deciding what is good enough to keep.
AI-assisted coding works best when it looks less like blind generation and more like disciplined engineering with a faster execution engine.
The skill I use for rough notes
The same pattern applies when I turn raw notes into writing. I created my own skill for this, and I often use it to remind myself to follow the rules I care about: preserve the point, remove filler, keep the voice human, and avoid fake polish.
To install Matt Pocock's skills, run:
npx skills@latest add mattpocock/skills
Here is the SKILL.md I use:
---
name: notes-to-blog-refiner
description: "Transform rough notes into clear, structured, blog-ready writing with selectable writing styles, stronger flow, cleaner grammar, and minimal fluff."
---
---
name: voice-notes-to-blog-refiner
description: Transform rough Wispr Flow voice transcripts into clear, structured, blog-ready writing with selectable writing styles, stronger flow, cleaner grammar, and minimal fluff.
---
# Voice Notes to Blog Refiner
## Purpose
This skill takes rough input, usually exported or pasted from Wispr Flow, and converts it into polished writing for a personal blog.
It is designed for:
- raw dictation
- messy thought dumps
- repeated ideas
- broken sentence flow
- filler words
- speech-like phrasing that should become writing
The goal is not to change the core meaning. The goal is to preserve the author's ideas while making them clearer, sharper, more structured, and more readable.
---
## When to use this skill
Use this skill when:
- the input is a writing and user asks you to use this skill ("convert to blog")
- the draft is too messy to publish
- the author wants better style without losing their voice
- a transcript needs to become a blog post, article draft, note, or post outline
- the text needs stronger structure, better transitions, and more concise phrasing
Do not use this skill when:
- the user wants heavy factual research added
- the user wants a purely SEO-stuffed article
- the user wants fake personal experiences invented
- the input is already polished and only needs tiny proofreading
---
## Core behavior
When this skill is used, follow these rules:
1. Preserve the author's main ideas, intent, and opinion.
2. Remove filler speech patterns such as:
- "like"
- "you know"
- "basically"
- "kind of"
- repeated phrases
- false starts
3. Convert spoken phrasing into clean written prose.
4. Fix grammar, punctuation, clarity, and flow.
5. Reduce redundancy.
6. Keep the writing natural and human.
7. Do not make it sound generic, robotic, or "AI-written."
8. Do not overuse dramatic hooks, hype, or exaggerated claims.
9. Prefer precise language over vague motivational language.
10. Keep the output aligned with the selected style preset.
---
## Inputs
The user should provide:
- `RAW_INPUT`: the rough transcript or dictated text
- `STYLE`: the desired writing style
- `MODE`: the output mode
- `AUDIENCE`: who the post is for
- `LENGTH`: short, medium, or long
- optional `TITLE`: if they already have one
- optional `EXTRA_NOTES`: any constraints or preferences
If some fields are missing, infer reasonable defaults.
### Default values
If not specified, use:
- `STYLE: Minimal Professional`
- `MODE: Rewrite for Blog`
- `AUDIENCE: general technical readers`
- `LENGTH: medium`
---
## Style presets
### 1. Minimal Professional
Clean, concise, sharp, modern.
Use short paragraphs.
Avoid fluff.
Good default for technical blogs and portfolio writing.
### 2. Personal Reflective
More human and introspective.
Keeps some personality and internal reflection.
Useful for lessons learned, career posts, and personal essays.
### 3. Technical Educator
Clear, structured, explanatory.
Optimized for teaching.
Useful for engineering concepts, tutorials, and breakdowns.
### 4. Opinionated Expert
Stronger stance, stronger claims, still professional.
Useful for essays, critiques, or perspective pieces.
Must not become arrogant or sensational.
### 5. Founder / Builder
Practical, energetic, product-minded.
Useful for startup, product, side-project, and execution-focused writing.
### 6. Calm Academic
Careful, precise, thoughtful.
Useful for research-adjacent writing, deep analysis, or rigorous explanation.
---
## Output modes
### Rewrite for Blog
Turn the raw input into a polished blog draft.
### Keep My Voice
Preserve more of the original rhythm and personality while cleaning the text.
### Heavy Polish
Make the writing significantly tighter, sharper, and more publishable.
### Expand Ideas
Keep the original ideas but flesh them out where the transcript is too sparse.
### Condense
Compress the input into a tighter version without losing key meaning.
### Outline First
Convert the input into a strong outline before drafting prose.
### Title + Intro + Draft
Generate:
- 3 title options
- 1 strong intro
- full blog draft
---
## Required workflow
When refining text, do the following internally:
### Step 1: Understand intent
Figure out:
- what the author is actually trying to say
- the main argument or theme
- which parts are core and which parts are filler
### Step 2: Extract structure
Identify:
- the central topic
- supporting points
- examples
- conclusions
- possible title/theme
### Step 3: Clean the transcript
Remove:
- filler words
- repetition
- stumbles
- transcript noise
- awkward spoken phrasing
### Step 4: Rewrite in chosen style
Apply the selected style preset consistently.
### Step 5: Improve readability
Use:
- clear paragraphing
- better transitions
- stronger sentences
- cleaner sequencing of ideas
### Step 6: Produce final output
Return output in the required response format.
---
## Anti-slop constraints
Never do these unless explicitly asked:
- do not write like marketing copy
- do not add fake storytelling
- do not overuse rhetorical questions
- do not force a "viral" tone
- do not overuse em dashes
- do not use clichés like:
- "in today's fast-paced world"
- "game changer"
- "unpack"
- "dive into"
- "ever-evolving"
- "journey" unless truly natural
- do not make the text sound like LinkedIn bait
- do not inflate simple ideas into grand philosophy
- do not add unnecessary adjectives
- do not use obvious AI filler transitions
Prefer:
- direct language
- clean logic
- grounded tone
- specific wording
- natural rhythm
---
## Blog-specific rules
For blog-ready output:
1. Start with a strong opening paragraph.
2. Make the central idea obvious early.
3. Group related ideas together.
4. Break long thoughts into readable paragraphs.
5. End with a clean conclusion, not a generic summary.
6. If the original text has a useful insight, sharpen it.
7. If the original text rambles, tighten it aggressively.
8. Keep the author's perspective intact.
---
## Technical blog rules
If the topic is technical:
- prefer clarity over cleverness
- define terms if needed
- avoid vague claims
- keep examples concrete
- do not add technical facts that are not present unless explicitly asked
- when the logic is unclear, restructure instead of inventing content
---
## Personal blog rules
If the topic is personal:
- keep authenticity
- do not oversanitize the voice
- preserve emotional truth
- remove cringe, not personality
- keep it reflective, not melodramatic
---
## Response format
Unless the user asks otherwise, return in this format:
## Refined Draft
[final polished version]
## What Improved
- clarity
- structure
- grammar
- flow
- reduced repetition
- stronger opening or conclusion
## Optional Title Ideas
- title 1
- title 2
- title 3
If `MODE = Outline First`, return:
## Blog Outline
### Title Ideas
- ...
- ...
- ...
### Core Thesis
...
### Sections
1. ...
2. ...
3. ...
### Notes for Expansion
...
---
## Editing heuristics
Apply these heuristics when rewriting:
- replace vague words with precise ones
- split overloaded sentences
- remove repeated points
- move the strongest insight earlier
- convert rambling into progression
- turn speech fragments into complete written thoughts
- keep paragraph sizes controlled
- preserve distinct phrasing when it feels authentic
- simplify without flattening personality
---
## Handling messy transcripts
If the transcript is especially rough:
- infer likely sentence boundaries
- resolve obvious transcription noise
- keep uncertain wording conservative
- do not hallucinate missing arguments
- if a section is too unclear, lightly normalize it rather than inventing detail
---
## Good output characteristics
A strong output should feel:
- human
- intentional
- readable
- structured
- stylistically consistent
- faithful to the original message
- cleaner than the input by a large margin
---
## Example invocation
```text
Use the "Voice Notes to Blog Refiner" skill.
STYLE: Minimal Professional
MODE: Rewrite for Blog
AUDIENCE: software engineers
LENGTH: medium
RAW_INPUT:
I’ve been thinking a lot about how people want to learn too many things at once and I think that’s one of the reasons they stay average for too long because they keep switching and switching and they never really go deep enough into one thing to become dangerous with it and I’ve noticed that in myself too...