DEV Community: Philip Hern

one agent, one repo, one writer at a time

Philip Hern — Mon, 10 Aug 2026 11:38:53 +0000

i wrote about when parallel subagents beat regular skills and how the parent should keep shared writes serial. this post is the simpler rule underneath that pattern.

only one agent should make file edits in a single repository at a time.

that sounds conservative until you watch what happens when you break it. two agents, two unrelated files, no obvious overlap, and both still get worse at the job. the problem is not git merge conflicts alone. the problem is that agents do not snapshot the repo once and freeze it. they keep scanning for context while the tree is moving.

quick answer

treat each repository as having one write lane. let many agents read and analyze in parallel if the units are independent, but keep all file mutations on one agent at a time, usually the parent conversation that launched the work.

if agent a is editing a model file in one folder and agent b is editing metadata in another, agent b may still re-read shared config, search the repo for patterns, or infer conventions from files agent a is actively changing. the reads interleave with the writes. each agent builds a plan from a repo state that stops being true before the plan finishes.

the fix is boring and effective. workers stay read-mostly. one agent applies edits serially. finish the write lane before you open a second one.

who this is for

people running parallel subagents or multiple cursor chats against the same codebase
teams that noticed "correct but wrong" suggestions after concurrent agent sessions
builders who want parallel speed on reviews without paying for parallel confusion on writes

why this matters

an agent's plan is only as good as the repo snapshot it believes it has. that belief is fragile.

while an agent works, it searches, re-opens files, follows imports, checks conventions, and compares against neighboring examples. that is a feature. it is how the agent grounds advice in the actual codebase instead of generic patterns.

but the same behavior becomes a bug when another agent is writing at the same time. the repo is a moving target. a config file changes mid-review. a new export appears while a worker is still reasoning from the old module layout. a parent dispatches two writers and each assumes the other's changes either already landed or never will.

the failure modes are predictable.

stale context: agent b reads version 1, agent a writes version 2, agent b proposes edits against version 1
duplicated or conflicting edits: two agents "fix" the same convention in different ways because each inferred a different baseline
phantom dependencies: an agent plans around a file that another agent renamed, deleted, or never finished creating
overconfident summaries: each agent reports success against its local view while the combined result is incoherent

none of this requires both agents to touch the same path. shared config, search results, import graphs, and convention scans are enough coupling.

reads in parallel, writes in series

this is the split i use in practice.

activity	concurrency
standards review across independent folders	parallel read-only workers
documentation drift audit by doc area	parallel read-only workers
sanity check by category	parallel read-only workers
scaffolding or editing files in one repo	one writer at a time
shared config, lockfiles, catalog indexes	parent applies serially after aggregation
git staging, commits, pushes	one agent, human-gated

parallelism buys wall-clock time when the work is analysis against a stable tree. serial writes keep the tree stable enough for analysis to mean something.

if you already use the pattern from my parallel subagents post, this is the same boundary with the guardrail turned up. workers analyze. the parent decides and applies. do not hand multiple agents write access to the same repo and assume file separation is enough.

what about different files in different folders?

different paths are not different universes.

agents routinely cross folder boundaries to learn how the repo works. they read shared configuration, follow references, compare naming across layers, and search for prior work. a worker assigned to "folder x only" still pulls context from folder y when y is where the canonical example lives.

so "agent a owns sql, agent b owns yml" is not a safe split by itself if both repos share conventions, generated artifacts, or a catalog that lists both. the write lane is the repository, not the file glob you wished you had assigned.

the safe exceptions are narrow.

truly separate repositories with no shared build or release surface
read-only parallel audits where no worker mutates anything
one writer plus several readers, with readers forbidden from applying patches

everything else gets the single-writer rule.

how this fits multiple chats, cloud agents, and multitask

the constraint is operational, not philosophical. however many agents you use, count active writers per repo, not open tabs.

practical habits that work for me:

one editing conversation per repo unless the previous write pass is fully landed and verified
background review is fine if it stays read-only and you treat its output as provisional until the write lane is free
do not mix a local write session with a cloud agent editing the same repo even on different branches if both can touch working tree state you care about
queue the next write instead of overlapping it. reviews can run while you wait. writes should not

if you use worktrees to isolate concurrent experiments, treat each worktree as its own repo surface for this rule. one writer per worktree still holds. the goal is to stop interleaved mutation and re-scanning on the same logical codebase.

a simple decision table

situation	allowed
three subagents review five folders, no edits	yes, parallel
one parent edits while subagents review	yes, if subagents are read-only and you accept provisional findings
two agents edit different files in one repo	no
two agents edit two repos that share a release contract	treat as one write surface unless you truly isolate them
parent aggregates findings, then applies patches itself	yes, this is the default good pattern
trivial one-line fix while a large agent job runs	still no if the large job can write. finish or pause one lane

closing

parallel agents are good at doing the same trusted review many times at once. they are bad at sharing a write lane they cannot see changing in real time.

so i keep the concurrency on reads and the discipline on writes. one repository, one agent mutating files at a time. let everyone else look, compare, and report back. when it is time to change the tree, pick a single agent, apply the edits, verify, and only then open the lane again.

that is less exciting than letting five agents "each take a corner," and it is much closer to what actually happens when five agents are all trying to learn the same repo at once.

faq

can two agents edit if they use different branches?

only if their working surfaces are fully isolated and you accept that each agent still will not see the other's in-flight edits. for most local agent workflows, that isolation is weaker than it looks. i still default to one writer.

is read-only parallel work safe while another agent writes?

mostly yes, with one caveat. treat review output as provisional until the write lane closes. a read-only worker may analyze files that change before the parent aggregates results.

does this mean i cannot use parallel subagents at all?

no. use them for read-mostly work such as reviews, audits, and sanity checks. keep the write lane in the parent. see the parallel subagents guide for the full pattern.

what if the edits really are in completely unrelated packages?

if there is no shared config, no shared catalog, no cross-package search path, and no release step that combines them, you might get away with parallel writes. i still queue writes anyway because the exceptions are rarer than they feel in the moment.

how does this relate to guardrails?

guardrails define what an agent is allowed to do. this rule defines what you should let multiple agents do at the same time within those permissions. i keep both. see the guardrails i actually use with ai agents for the wider kit.

references

parallel subagents: when to use them vs regular skills

Philip Hern — Mon, 10 Aug 2026 11:38:52 +0000

i have been using cursor skills for a while to turn repeated work into runbooks the agent can follow on demand. that pattern still works. what changed is that some tasks are not slow because the steps are hard. they are slow because the same review or audit has to run five times across five folders, five categories, or five doc areas, and a single agent does them sequentially.

parallel subagents fix that kind of problem. they do not replace skills. they wrap them.

if you already reorganized your .cursor directory for token efficiency, think of this post as the next decision. skills stay the canonical playbook. subagents decide when to run several copies of that playbook at once.

quick answer

use a skill when one agent should follow one bounded workflow end to end, such as reviewing one file, scaffolding one model, or running one sanity check category you explicitly scoped.

use a parallel subagent when the same underlying skill applies to several independent units and wall-clock time matters. the parent agent dispatches one subagent per unit, each subagent gets its own context window, and the parent aggregates the results afterward.

the rule i use is if the units can run without reading each other's partial output, parallelize. if they share one mutable target or one sequential decision chain, keep it in one agent with one skill.

who this is for

people who already use cursor skills and notice multi-folder audits taking forever
teams with repeatable review or maintenance workflows split across layers, packages, or doc areas
builders who want faster end-of-task verification without giving up human control over writes

why this matters

a skill makes work repeatable. a parallel subagent makes repeatable work concurrent.

that distinction sounds small until you run a standards review across five model layers, a sanity check across five categories, or a documentation audit across five doc zones. one agent can do all of it correctly and still feel painfully slow, because each unit waits for the previous one to finish.

parallel subagents change the timing. wall-clock cost becomes closer to the slowest unit instead of the sum of all units. you still pay token cost across multiple agents, so this is not free. it is a trade. you spend more tokens to buy back waiting time on work you already trust enough to decompose.

definitions: skills vs subagents

before choosing, it helps to know which artifact does what.

artifact	lives in	job	typical trigger
skill	`.cursor/skills/<name>/SKILL.md`	step-by-step runbook for one workflow	parent agent loads it when the task matches the skill description
parallel subagent	`.cursor/agents/<name>.md`	orchestration wrapper that dispatches the same skill across independent units	parent agent launches subagents when scope spans multiple units

skills answer "how do i do this task correctly?"

subagents answer "how do i run that task many times at once without losing control?"

neither one replaces rules. rules stay passive guardrails. skills and subagents are active workflows.

when to use a regular skill

reach for the underlying skill directly when the scope is one unit or when the work is inherently serial.

good skill cases:

review one sql file or one yml file
scaffold one new model and its metadata
run one documentation update for one page
sanity-check one small change where formal multi-category review would be ceremony
any task where the next step depends on the output of the previous step

skills are also the right place to keep the canonical checklist, references, done criteria, and acceptance language. the skill is the source of truth. the subagent should not duplicate that content. it should point to it.

if you are unsure whether the scope is truly one unit, start with the skill. parallel orchestration adds coordination overhead. only use it when the parallelization is obvious.

when to use a parallel subagent

reach for a parallel subagent when all of these are true:

the same skill applies to multiple units
the units are independent enough to review or audit separately
you want results aggregated into one report
the task is substantial enough that serial execution takes too long

good parallel subagent cases:

standards review across every layer in a data platform repo
yml review across the same layers as the paired sql review
end-of-task sanity checks split by category such as correctness, compatibility, edge cases, conventions, and overall review
documentation drift audits split by doc area
dependency audits split by surface such as runtime, packages, ci, and container base image
entity sync work when several new backend entities need the same scaffolding pattern at once

bad parallel subagent cases:

a one-line typo fix
a single-file edit where you already know the answer
a workflow that must mutate the same shared file from multiple angles at once
anything where step two genuinely requires step one's write to exist first

the last point matters. parallel subagents are for read-mostly or analyze-then-decide work. when multiple units need to edit the same shared config, the parent should collect findings first and apply shared writes serially afterward.

the pattern i use: one skill, one orchestrator, many workers

my parallel setup has three layers.

layer 1: the underlying skill

this is the real playbook. it contains the checklist, canonical references, output format, and done criteria for one unit of work.

examples in my repos include skills for sql standards review, yml standards review, sanity checks, documentation audits, and entity sync scaffolding. each one knows how to handle one scoped slice.

layer 2: the parallel subagent

this file lives in .cursor/agents/ and does not replace the skill. it defines:

the default unit breakdown, such as one subagent per model layer or one subagent per sanity category
which underlying skill each worker should follow
the output contract each worker must return
when not to use parallel mode

naming helps. i use a -parallel suffix on orchestrator subagents so the choice is obvious in the catalog.

layer 3: shared orchestration mechanics

i keep one small shared skill for dispatch rules every parallel wrapper follows:

use the explicit scope from the user. if the scope is one unit, call the underlying skill directly and skip orchestration.
dispatch one self-contained prompt per unit in a single parent message. each prompt should include paths, the canonical skill, the expected output format, and write boundaries.
aggregate results in the parent. label failed or partial units clearly. retry a transient failure once if that is useful.
apply changes only when authorized. keep shared-file writes serial in the parent. never let workers mutate git state on their own.
run proportionate final verification once at the end. skip formal orchestration for trivial edits.

that shared layer keeps every parallel subagent consistent without copying the same coordination instructions into five different files.

how the parent should dispatch work

the parent agent is the conductor, not another worker.

a good dispatch prompt for each unit includes:

the exact scope for that unit only
a link or name for the canonical skill to follow
read-only vs write permission for that unit
the response format you want back, such as pass or concern, file list, violation counts, or missing coverage

a bad dispatch prompt says "review everything" and hopes the subagent guesses the boundary.

i send all dispatches in one parent turn when possible so the units actually run concurrently. then i aggregate in a fixed order. for reviews, i surface correctness and compatibility findings before style nits. for audits, i surface missing files and contract breaks before commentary.

what should stay serial

parallel subagents are not an excuse to let five agents edit the same shared file at once.

keep these in the parent:

writes to shared source files used by multiple units
git staging, commits, pushes, or merges
choosing which findings become actual code changes
final compile, lint, or check commands that validate the combined result

workers analyze. the parent decides and applies.

that boundary is why parallel mode works well for reviews, audits, and sanity checks, and why i still use a single skill for a straightforward write workflow unless the units truly touch different files with no overlap.

a practical decision table

situation	use
one file, one model, one doc page	underlying skill
trivial edit, docs-only change, formatting	no formal workflow, or a very small inline ask
same review repeated across independent folders	parallel subagent
end-of-task verification across multiple categories	parallel subagent
several new entities needing the same scaffold pattern	parallel subagent, with shared files updated serially in the parent
step b requires step a's write to exist	single agent, single skill, serial steps
background merge-ready pr hygiene	cloud or babysit workflows, not this pattern

how to build your first parallel subagent

you do not need a perfect fleet on day one. this sequence worked for me.

1) stabilize the underlying skill first

if the single-unit workflow is still fuzzy, parallelizing it will just produce five fuzzy answers faster. get the checklist, references, and output contract right in the skill before you wrap it.

2) identify real units of independence

ask where the task naturally splits. model layers, doc areas, sanity categories, dependency surfaces, and service entities are all common unit boundaries. the split should be obvious enough that you can write one paragraph of scope per unit without overlap.

3) create the orchestrator file in `.cursor/agents/`

frontmatter should answer when to use it and when not to use it. point to the underlying skill and the shared orchestration skill instead of restating both.

4) define the default scope table

a small table in the subagent file beats prose. one row per unit, with the path or category and what the worker should return.

5) test on a medium-sized real change

run the parallel subagent once at the end of a substantial change set, not on every keystroke. check whether aggregation is readable and whether any shared-file write would have collided if workers had been allowed to edit freely.

6) link it from your local cursor index

add one row to your .cursor catalog so future sessions route correctly. "use the skill for one unit, use the parallel subagent for many" should be discoverable without remembering filenames.

how this fits with cursor's `/multitask` direction

cursor has been moving toward async subagents and better multitask orchestration in the product itself. the repo pattern i describe here is the durable part regardless of ui changes.

skills remain the canonical instructions. subagents remain explicit orchestration boundaries. the parent remains responsible for aggregation and shared writes. whether the platform dispatches workers through /multitask, the agents window, or a manual multi-launch in chat, the decision rule stays the same.

parallelize independent units. keep shared mutation serial.

closing

skills taught my agents how to do repeatable work well. parallel subagents taught them when to do several copies of that work at the same time without turning one conversation into a queue.

default to the skill. escalate to a parallel subagent when the scope spans independent units and the wait time starts to hurt. keep orchestration rules in one shared place, keep workers read-mostly, and let the parent own the merge.

that is the split that has saved me the most time on reviews and end-of-task checks without giving up control.

faq

should i duplicate my skill checklist inside the subagent?

no. the skill stays canonical. the subagent should only define unit boundaries, dispatch instructions, aggregation order, and when to skip parallel mode.

do parallel subagents cost more?

usually yes, because several agents run at once and each carries its own context. you are trading token spend for wall-clock time. use them on substantial tasks where that trade is worth it.

can i parallelize writes?

only when units touch completely separate files with no shared contract surface. even then, i prefer read-first parallel analysis and serial application in the parent. it is slower to apply than to analyze, but much safer.

what if one subagent fails?

the parent should mark that unit failed or partial, continue aggregating the rest, and retry once if the failure looks transient. do not silently treat a missing unit as a clean pass.

when should i skip parallel mode entirely?

skip it for trivial edits, single-file work, docs-only formatting, and any task where formal verification would be more expensive than the change itself. parallel orchestration is for substantial scope, not habit.

references

low thinking mode is actually better

Philip Hern — Tue, 04 Aug 2026 12:58:03 +0000

quick answer

when working with top-tier reasoning models, defaulting to low or minimal thinking mode usually yields better results than maxing out reasoning effort. my experience indicares that max thinking budgets often lead models down rabbit holes where they overthink simple requests, hallucinate broader context, and perform unprompted refactors outside your task scope. keeping powerful models on a leash gives you faster execution, lower cost, cleaner scope control, and tighter feedback loops.

who this is for

developers using reasoning models inside cursor, vsc, or api tools who keep catching models changing code they were not asked to touch
builders who want faster iteration cycles without sacrificing the baseline intelligence of top-tier models
anyone looking to reduce model latency and token costs while improving output predictability

why this matters

when reasoning models first arrived, the common assumption was that more thinking time always meant higher quality. in practice, giving a model several minutes to contemplate a request often changes its behavior in an unwanted way.

after minutes contemplating a simple file edit, the model seems to feel obligated to justify all that processing time. it begins inspecting surrounding methods, rewriting styles, "cleaning up" code that was not broken, and refactoring contracts you deliberately wanted preserved. by treating every small prompt like a multi-stage architecture problem, extended thinking degrades task precision and introduces scope drift.

the trade-offs: low thinking vs deep reasoning

minimal thinking mode (default)

fast responses that preserve fast feedback loops
strict adherence to prompt scope with minimal side effects
lower API cost and reduced token consumption
requires clear, well-bounded human instructions

deep reasoning mode (opt-in)

necessary for subtle logic bugs, ambiguous specs, or greenfield architecture
higher latency and noticeable waiting periods between iterations
prone to unprompted refactoring and scope expansion on small tasks
expensive to run repeatedly on routine edits

when to switch up to deep thinking

low thinking mode should be your default starting point, but deep thinking still has a place. switch to higher reasoning tiers only when:

you are diagnosing a subtle concurrency or state bug where quick pattern matching fails
you are drafting an architecture spec or designing a new data vault contract from scratch
the initial low-thinking output missed a core logical dependency that you do not want to hand-guide

for 90% of daily coding, refactoring, and file maintenance, pairing a top model with its lowest thinking preset gives you the intelligence you need without the unsolicited rewrites you do not.

faq

does low thinking mode mean using a smaller or cheaper model?

no. the strategy is to use the strongest, most capable model available, but run it with its lowest reasoning effort preset. you keep the model's underlying knowledge and instruction-following quality while disabling the extended internal monologue that leads to overthinking.

what should i do if low thinking mode misses something?

if a fast response misses a subtle requirement, try sharpening the prompt with explicit constraints first. if the underlying problem is genuinely complex, that is your signal to deliberately toggle the model into a deeper thinking tier for that specific prompt, then switch back once the barrier is cleared.

references

im on a boat

Philip Hern — Mon, 03 Aug 2026 13:48:42 +0000

thesis

i am on a boat, and the first thing i notice is not the scenery. it is how badly i needed to be unreachable from my regular work. this website is my hobby, so do not conflate the two. i am not writing this to perform productivity on vacation. i am writing it because sitting in an internet cafe on day one of an alaskan cruise made something obvious that i keep avoiding at home. i talk about giving things room to breathe, but i rarely give them the space i know they need. an extended vacation is one of the few ways i can force the disconnection i am bad at choosing on my own.

context

i have argued for this before. in room to breathe i wrote about stepping off the improvement treadmill so i could understand what i shipped before piling on the next change. in what room to breathe makes room for i followed up with the idea that the pause is not idle, it is where bigger, slower ideas finally get air. i believe all of that. i just do not live it consistently. at my desk, there is always one more thing i could tweak, one more pass that feels cheap because the tools make it feel cheap. the cruise did not fix my personality. it removed the option to pretend i will disconnect later.

argument

i preach the pause but skip it

the gap between what i know and what i do is embarrassing. i can describe brain defrag time, protected space, letting a solution run before i rework it again. i can explain why little by little beats an endless sprint. then i go right back to hovering over the same projects like a gardener who cannot stop watering and trimming long enough for anything to actually grow. you cannot constantly fuss with a plant and expect it to develop roots. sometimes you have to step back and let it grow on its own schedule, not yours.

forced disconnection is the tool i need

that is why real disconnection matters, and why an extended vacation is not a luxury for me, it is a structural requirement. i am not good at disconnecting in small doses. a free evening turns into "just one more hour." a weekend turns into catching up. only something as blunt as a cruise, days away from my normal setup, makes the boundary stick. the forced disconnection is not punishment. it is the only reliable way my projects get the room to breathe that they desperately deserve and need, because i will not grant it voluntarily often enough.

the work gets time away from me too

yes, i can sit here and reflect on my time away from work. that part is easy to narrate. the more striking realization is the time alone my work will have away from me. my projects do not only need me to stop touching them. they need stretches where i am not re-reading, re-scoping, or "improving" them every day. without that distance, i am the constant weather. with it, they get to settle, surprise me, or fail in ways i would never see if i never left the room. the vacation is not just rest for me. it is rest for the work from my restlessness.

tension or counterpoint

the obvious objection is that needing a cruise to disconnect is a personal failure, not a lesson worth publishing. fair. a healthier person might protect boundaries without leaving the continent. i am not arguing that everyone needs a boat. i am admitting that i do, or something like it, because softer boundaries do not hold for me. there is also the irony of posting from an internet cafe about disconnecting. i see it. this post is the exception that proves the rule, a short note from the edge of offline, not proof that i have mastered balance.

closing

so i am trying to treat the next stretch as protected time, mostly for everything that is not this page. the day job gets silence. the hobby projects get silence too, even the ones i love, because love is exactly what makes me hover. when i get back, i expect some of them to look different in my head simply because i was not in the room every day telling them what to become. that is the point. i needed time away from work, but my work needed time away from me just as much.

related on this site

chapter 4 of ai-assisted data engineering is live

Philip Hern — Mon, 20 Jul 2026 14:00:41 +0000

thesis

chapter 4 of ai-assisted data engineering is live. it is called the editor and the workspace, and it opens the setup part of the book, where judgment gets an environment that can carry context instead of starting from a blank prompt every time.

context

after three chapters about ownership, judgment, and production standards, chapter 4 gets practical. the fastest way to work with agents is to shape the workspace once so the agent sees the system the way the work actually crosses it. it follows chapter 3, continuing the weekly release cadence for the book.

argument

what chapter 4 covers

this chapter covers:

why a multi-repo workspace makes the agent more useful
which editor settings and shortcuts matter more than tool fashion
how one rule and one skill can raise the quality floor
why setup should be verified before serious work depends on it

why it belongs here

chapter 4 sits here because the book is building one layer at a time. the early chapters established judgment and ownership. each release after that adds another practical surface where those standards either hold or fail.

it is easy to dismiss setup as tinkering. the chapter argues the opposite. setup is where repeated judgment becomes reusable context, and that makes every later agent run less fragile.

closing

this is another monday release in the serialized run. chapter 5 is next in the queue, and it will publish the following monday if the schedule holds. the full book landing page stays at ai-assisted data engineering, and the companion channel stays at philliant on youtube for any longer explanation that works better out loud.

related on this site

capability is not a reason to act

Philip Hern — Mon, 20 Jul 2026 13:56:34 +0000

thesis

having an ai agent at my side can feel like having a genie with unlimited wishes. i can ask it to adopt the newest pattern, add another automation, reorganize a system, or squeeze one more improvement out of something that already works. the old cost of turning an idea into action has fallen dramatically, but that does not make every idea worth acting on. capability is not a reason to act. before i use another wish, i still need to decide whether i need what i am asking for, whether it fits my situation, and whether i am prepared to understand and own the result.

context

scarcity used to impose restraint for me. a change took enough time and effort that i naturally asked whether it was worth doing. ai weakens that filter. when an agent can research a trend, draft an implementation, update the documentation, and check the result in one sitting, trying the idea feels almost free.

almost free is not free. every generated change creates something for me to review, learn, maintain, and eventually troubleshoot. the agent can keep producing without rest, but i cannot keep absorbing without limit. the genie has unlimited wishes. i still have one human-sized mind.

argument

the ability to do something says nothing about its value

an agent can make an idea possible without making it useful. those are separate judgments. the model answers "can this be done?" very quickly, but only i can answer "does this need to be done here?"

that second question should come first. what problem am i solving? who benefits? what happens if i leave the current system alone? what new responsibility will the change create? if i cannot give a clear answer, implementation speed is irrelevant. i am using capability to manufacture work rather than solve a need.

unlimited wishes encourage careless wishing

the genie metaphor matters because unlimited wishes change how i value each wish. when implementation was expensive, i chose carefully. when implementation feels abundant, it is easy to ask for things simply because i can.

that is how useful assistance turns into an improvement treadmill. one more abstraction, one more automation, one more layer of agent configuration. each addition may be defensible on its own, but together they can leave me with a system that has grown faster than my understanding of it. the agent did not overextend itself. i overextended the amount of generated work i could responsibly own.

trends are options, not instructions

ai makes following a new trend unusually easy. i do not need to master the tool before experimenting with it because the agent can read the documentation, scaffold the integration, and explain the unfamiliar parts as it goes. that can be valuable, but it can also remove the pause where i would normally ask whether the trend belongs in my work at all.

new does not mean necessary. popular does not mean relevant. a pattern that helps another team at another scale may add nothing to my situation except complexity. i want to treat each trend as an option to evaluate, not an instruction to obey. the right question is not whether the agent can bring it into my system. the right question is whether my system has a real problem that the trend solves better than what i already have.

consideration must come before action

the faster action becomes, the more deliberate the decision before it needs to be. my filter is simple:

what specific need exists
what evidence says the current approach is insufficient
why this change fits my situation
what i will have to understand and maintain afterward
what would tell me not to proceed

if those questions do not produce a convincing case, i do not need another prompt. i need to leave the system alone.

sometimes the best use of capability is restraint

restraint is not a rejection of ai. it is how i keep ai useful. the point of an agent is not to maximize the number of things i ask it to change. the point is to help me act well when action makes sense.

i have already written about giving work room to breathe after it ships. this is the decision that comes before that. room to breathe says to stop squeezing once the useful work is done. capability is not a reason to act says not to begin merely because the squeezing has become easy.

tension or counterpoint

there is a risk in becoming so cautious that i use "consideration" as an excuse never to experiment. some useful ideas only reveal their value after i try them, and ai makes small experiments cheaper than they have ever been.

the distinction is intent and containment. an experiment should test a specific question, within boundaries i understand, with a clear way to stop. chasing a trend because everyone is discussing it is not the same as running a focused experiment to learn whether it solves one of my problems. consideration does not prohibit action. it gives action a reason.

closing

the agent beside me may never tire, run out of ideas, or ask me to stop. that does not mean i should match its appetite for action. i am still the person who has to understand the changes, carry their consequences, and decide whether they made anything better.

so i am learning to leave wishes unused. i do not need to follow every trend, automate every process, or improve every thing that could be improved. the genie can wait. when a real need appears and the change makes sense for my situation, the capability will still be there. until then, not acting is also a decision, and often it is the better one.

related on this site

an efficient .cursor directory: less context, better agents

Philip Hern — Thu, 16 Jul 2026 20:27:42 +0000

i spent time recently reorganizing how my repositories load cursor context. the old setup worked, but it was heavy. every agent turn started with a large bundle of rules, duplicated guidance, and inventories the model did not need for most tasks.

the new setup is deliberately smaller. agents still find what they need, but they pay for less context up front. that means lower token cost, less time waiting for the model to "read the room", and answers that stay closer to the task i actually asked for.

if you already have my cursor setup in place, think of this post as the next layer. that post covers the full toolkit. this one covers how to arrange the toolkit so it does not eat your context window before work begins.

quick answer

treat your .cursor directory like a library with a card catalog, not like one giant PDF pasted into every prompt. keep a thin always-on layer for guardrails, route everything else through links, scope detailed rules to the file types they apply to, and load skills on demand. the agent can always open more context when the task requires it, but the default should be the minimum useful baseline.

who this is for

people who already use cursor rules, skills, or AGENTS.md and notice agents getting slower or noisier over time
teams whose .cursor folder grew organically and now repeats the same instructions in three places
builders who care about token cost and want cleaner first responses without giving up deep project knowledge

why this matters

context is not free. every always-on rule, every paragraph in AGENTS.md, and every skill description the system injects up front consumes tokens before the agent writes a single useful line.

that cost shows up in three places:

money, because larger prompts cost more per turn
latency, because the model spends time absorbing context you may not have needed for this task
focus, because a bloated baseline makes it easier for the agent to wander, repeat itself, or "helpfully" expand scope

the counterintuitive part is that less default context often produces better results. when the baseline is tight, the agent has fewer conflicting instructions to reconcile. when it needs sql conventions, it loads sql conventions. when it needs a release checklist skill, it loads that skill. the fetch is intentional instead of accidental.

the problem with a "kitchen sink" .cursor folder

most .cursor directories start sensibly. you add one rule for coding standards. then a skill for your most common workflow. then AGENTS.md grows because you keep answering the same architecture questions. then another rule duplicates half of the first one because you wanted sql-specific guidance.

soon every chat begins like this:

a long always-on rule with architecture, naming, validation, git policy, and documentation philosophy
a second always-on rule with overlapping standards
an AGENTS.md file that restates the same material in prose
a skill inventory table with fifteen rows, even when you only needed one skill

none of this is wrong in isolation. together it is expensive noise.

the pattern i use now: route, do not restate

the organizing principle is one canonical document per topic, indexes that route rather than restate.

think in layers:

layer	job	load profile
`AGENTS.md`	entry point, hard constraints, route-by-task table	small, always present
`.cursor/README.md`	local index of rules, skills, and subagents	small, linked from entry
`.cursor/rules/*.mdc`	enforceable standards	thin always-on + glob-scoped detail
`.cursor/skills/*/SKILL.md`	procedural runbooks	on demand when task matches
`.cursor/reference/*.md`	catalogs, contracts, long inventories	only when maintaining or choosing

layer 1: a thin `AGENTS.md`

AGENTS.md should answer two questions quickly:

what must never be violated on this repo
where do i go next for the task at hand

a useful layout:

# my-repo agent entry

one-paragraph architecture invariant.

## hard constraints

- link to the always-on behavior rule
- link to task-scoped rules
- one line on validation expectations

## route by task

| task                 | canonical source             |
| -------------------- | ---------------------------- |
| local setup          | README                       |
| cursor asset layout  | .cursor/README.md            |
| full skill inventory | .cursor/reference/catalog.md |
| domain architecture  | docs/architecture note       |

what to leave out:

full skill tables (link to a catalog instead)
long prose explanations of every layer in your data platform
step-by-step workflows (those belong in skills)

layer 2: `.cursor/README.md` as the local index

this file is the map of cursor-native assets. keep it scannable with tables, not essays.

include:

which rules exist and when they apply
which skills exist and when to use them
which subagents wrap parallel work
where maintenance docs live

tell the agent explicitly when not to load the heavy stuff. a line like "do not open the full catalog unless maintaining assets or the user asks for an inventory" saves tokens repeatedly.

layer 3: split always-on rules from task-scoped rules

this is the highest-leverage change i made.

always-on should mean "behavior and safety", not "every convention in the repository".

my always-on behavior rule covers:

question before assuming
prevent scope drift
keep git user-controlled
match verification to risk
documentation philosophy in one short section
architecture invariants in a few lines

detailed conventions move to glob-scoped rules:

---
description: "sql and model conventions"
globs: "**/*.sql"
alwaysApply: false
---

and:

---
description: "yaml metadata conventions"
globs: "**/*.yml"
alwaysApply: false
---

now a markdown edit does not load sql rules. a yaml edit does not load manuscript rules. the agent gets the right lane without reading every lane at once.

for content-heavy repos, the same idea applies across zones. one rule scoped to website posts, another scoped to book chapters, each with its own glob pattern. the agent loads voice and punctuation rules for the files it is actually touching.

layer 4: skills as on-demand runbooks

skills are powerful because they are procedural and task-bound. that also makes them expensive if you treat them like always-on policy.

keep each skill focused:

frontmatter description that says when to use it
required inputs
ordered steps
done criteria
links to canonical reference docs instead of copying them

the agent discovers skills through descriptions and loads the file when the task matches. it should not need the full text of every skill before you say hello.

if you want a template for tightening skill structure, see starter templates for ai rules, skills, and commands.

layer 5: reference files for inventories and contracts

some material is too long to inline but still valuable. put it in .cursor/reference/ and link to it.

good candidates:

full skill and subagent catalogs
model or schema contracts
maintaining-assets runbooks
shared prose contracts used by multiple rules

each reference file should say at the top when to load it. catalogs especially should warn against opening them on every task.

duplication is the silent token tax

the fastest audit you can run is a duplication pass.

search for the same ideas repeated across:

AGENTS.md
always-on rules
skills
README files inside .cursor/

common duplicates:

git policy stated in three places
architecture overview copied into every rule
validation commands listed in both a skill and a rule
full directory trees pasted into prompts

pick one canonical home for each topic. everywhere else, replace the copy with a link.

this also makes maintenance easier. when validation changes, you update one file instead of hunting for stale copies the agent may still believe.

indexing hygiene still matters

token efficiency is not only about rules and skills. it is also about what cursor indexes from the repo.

keep using:

.gitignore for generated output and dependencies
.cursorignore for extra exclusions such as build artifacts, minified bundles, and local secrets

less junk in the index means less irrelevant material during semantic search and fewer wrong-file detours.

i covered the basics in my cursor setup under context hygiene. the .cursor directory optimization and indexing optimization work together.

let the agent fetch, but make fetching intentional

a lean baseline does not mean a ignorant agent. it means the agent starts focused and expands deliberately.

patterns that work well:

@Files and @Folders when you already know where the answer lives
task-scoped rules that attach automatically when the agent edits matching files
skills the agent opens because the task description matches the skill's description
reference catalogs opened for maintenance, inventory questions, or ambiguous workflow choice

patterns that waste tokens:

pasting entire directories into always-on instructions
writing "read all docs before doing anything" into a rule
creating five always-on rules because you could not decide which one was canonical

the model is good at retrieval when you give it a map. it is worse when you give it the whole encyclopedia and ask it to find page one.

a practical migration path

you do not need a weekend rewrite. this sequence worked for me:

1) inventory what loads every turn

list:

rules with alwaysApply: true
large sections of AGENTS.md
any skill or subagent list inlined in an always-on file

ask for each item: "did i need this on a generic question about yesterday's pull request?"

2) rewrite `AGENTS.md` as a router

keep hard constraints and a route-by-task table. move everything else behind links.

3) collapse always-on behavior into one thin rule

merge overlapping guardrails. link out to collaboration preferences or behavioral skills instead of copying them.

4) extract task-scoped rules with globs

sql, yaml, typescript, website markdown, book markdown, ci workflows. each gets its own scoped rule if the guidance is non-trivial.

5) move inventories to reference files

catalogs, contracts, and maintenance guides live under .cursor/reference/. add a "when to load" note at the top.

6) dedupe and delete

if two files say the same thing, pick a winner and remove the loser. stale duplicates are worse than missing docs because they look authoritative.

7) test with three prompts

run these after the refactor:

a generic task outside your specialty rules (should stay fast and focused)
a file-type-specific task (should pull the right scoped rule without you mentioning it)
a maintenance task such as "add a new skill" (should route to the catalog or maintaining doc)

what improved after the refactor

the differences are subtle per turn but add up quickly:

first responses arrive with less preamble and less repeated policy quoting
sql tasks stop inheriting markdown voice rules and vice versa
token spend on routine edits dropped because the baseline shrank
when an agent does expand scope, it is usually because the task actually required more context, not because the repo forced it

this is the same philosophy behind cursor automations for housekeeping and hygiene, where the automation prompt stays short because the repo already contains the playbook. efficient .cursor layout makes both interactive agents and background automations cheaper to run.

closing

you do not need a perfect .cursor directory on day one. you need one that grows without accumulating duplicate authority.

start small, route aggressively, scope rules to the files they govern, and treat catalogs as reference material rather than default context. the agent will still go look when it needs to. that is the point. you are just stopping it from carrying the whole library into every conversation.

faq

how small should my always-on layer be?

small enough that you can read it in under a minute and still trust the agent on safety and scope. if your always-on material needs scrolling, move detail into glob-scoped rules or skills.

will lean context make the agent miss project conventions?

only if you removed the canonical source entirely. routing fixes that. the conventions still exist, they just load when relevant. if you see misses, tighten the skill description, adjust globs, or add one line in AGENTS.md pointing to the canonical doc.

should i optimize tokens or optimize for "the agent always knows everything"?

optimize for intentional loading. "always knows everything" sounds safe but usually means "always reads everything", which is slower, costlier, and often muddier. give the agent a map and let retrieval do its job.

references

chapter 3 of ai-assisted data engineering is live

Philip Hern — Mon, 13 Jul 2026 15:43:49 +0000

thesis

chapter 3 of ai-assisted data engineering is live. it is called from prototype to production, and it moves the book from mindset into the production bar, where ai-assisted work has to be measured, verified, and designed for real blast radius.

context

this is the chapter where the book turns from warning into operating standard. prototypes can survive vibes, but production work needs evidence, tests, and reliability thinking before the output reaches anyone else. it follows chapter 2, continuing the weekly release cadence for the book.

argument

what chapter 3 covers

this chapter covers:

what changed when ai moved from side-task novelty into operational systems
why production mistakes cost more than prototype mistakes
how verification becomes evidence instead of vibes
why reliability is a design responsibility, not a final polish step

why it belongs here

chapter 3 sits here because the book is building one layer at a time. the early chapters established judgment and ownership. each release after that adds another practical surface where those standards either hold or fail.

the tempting argument is that a prototype mindset is good enough if the model output looks right. chapter 3 pushes back on that because looking right is exactly the easiest standard for a model to satisfy.

closing

this is another monday release in the serialized run. chapter 4 is next in the queue, and it will publish the following monday if the schedule holds. the full book landing page stays at ai-assisted data engineering, and the companion channel stays at philliant on youtube for any longer explanation that works better out loud.

related on this site

bronze, silver, and gold standard data vault 2.0

Philip Hern — Thu, 09 Jul 2026 15:04:51 +0000

i finally got a data vault 2.0 data product to actual gold standard, and yes, i am going to let myself enjoy that one.

this was not a clean build from day one. the warehouse started as a mishmash. layers blurred together, business logic lived in the wrong places, and every new consumer request turned into a debate about where the rule belonged. getting from that state to real gold took time, but the definitions were always the guide. bronze is the raw historical foundation. silver is the business-enriched layer. gold is the governed consumer layer. once those jobs were clear, the architecture could finally do what it was supposed to do.

quick answer

in a proper data vault 2.0 stack, bronze is the raw and standardized historical foundation, landing first and then taking data vault structure in the raw vault layer. silver is the business-enriched layer, where the business vault materializes reusable business logic. gold is the consumer layer, where the information delivery layer serves governed presentation views for apps, BI, and other consumers, preferably over precalculated business vault tables.

gold matters because it is where the warehouse becomes usable without giving up lineage. the raw vault preserves history. the business vault makes business meaning durable. the information delivery layer turns that meaning into a contract consumers can trust.

who this is for

data engineers building data vault 2.0 beyond the raw vault
analytics engineers trying to understand where the business vault ends and the information delivery layer begins
technical leads deciding whether their warehouse has reached a real consumer gold layer
anyone who inherited a layered warehouse that still feels like a mishmash

why this matters

data vault 2.0 is excellent at preserving change, but preserving change is not the same as serving a product. a raw vault can be modeled correctly and still be too awkward for an application, BI team, or downstream consumer to use directly.

that is why the bronze, silver, and gold language is useful when it is tied to real layers. it keeps each layer clear about its job. the raw vault should not become a dumping ground for business rules. the business vault should not be skipped because a dashboard wants a quick answer. the consumer layer should not become a hiding place for duplicated logic that belongs upstream.

when the layers do their jobs, the system gets easier to reason about. when they blur together, every new request becomes a debate about where the logic belongs.

where i started

the warehouse i am talking about did not begin as a textbook data vault 2.0 product. it began as a mishmash.

some history was modeled well. some business logic lived in presentation views. some calculations were copied into reports. some tables were safe to query and some only made sense if you already knew the backstory. the raw vault existed, but the business vault was thin or missing in places, and the consumer layer kept absorbing work that should have lived upstream.

that is common in the "real world" where getting the work done quickly often overpowers doing the work correctly. the team knows data vault 2.0 is the long-term direction, but delivery pressure keeps pulling logic into whatever layer is fastest to ship. over time the warehouse grows, but the architecture stops explaining itself.

i did not fix that by renaming folders or declaring victory early. i fixed it by making the layer definitions real and then moving the work to the right place.

bronze, preserving the facts

bronze is where the platform starts preserving what arrived.

in the stack i am talking about, that begins with raw ingestion and then becomes standardized raw history in the raw vault layer. this is where data vault 2.0 earns its keep as a non-destructive historical model. hubs represent stable business keys. links represent relationships. satellites preserve descriptive context. effective satellites capture relationship effectivity when the model needs it.

bronze or raw silver is doing its job when:

source data lands without overwriting useful history
business keys are modeled consistently
relationships are separated from descriptive context
load metadata and record source are preserved
history can survive source changes and backfills
business presentation logic stays out of the raw vault

this layer is already a major win. it gives the rest of the platform a historical foundation that can be trusted. but it is still a foundation, not the final consumer product.

that distinction matters. the raw vault should be understandable to engineers, but it does not need to be the easiest thing for every consumer to query. its job is to preserve the truth cleanly enough that better serving layers can be built on top.

silver, making business meaning durable

silver is where the business vault earns its place.

the business vault is the business-enriched layer. it materializes the business rules, calculations, cleansing, and conformed logic that should not be repeated in every downstream view. in the architecture i am talking about, the business vault is built as dynamic tables, so the logic is not just a thin view someone hopes performs well enough. it is a materialized layer with refresh behavior, tests, documentation, and a clear purpose.

silver is doing its job when:

business rules live once instead of being pasted across reports
calculations are materialized where multiple consumers need them
source-specific rough edges are cleaned or conformed before serving
temporal logic is handled deliberately
reusable business tables sit between the raw vault and the information delivery layer
tests and documentation explain what the business layer guarantees

this is where the hard middle work lives. it is also the layer people are tempted to skip. the raw vault exists, the consumer wants a view, and it feels faster to jump straight to presentation.

that shortcut is how gold gets polluted. if the business vault does not hold the reusable business meaning, the information delivery layer has to carry it. then app views, BI views, extracts, and one-off models each grow their own copy of the same rules. that is not gold. that is a maintenance problem wearing a nice name.

gold, serving the consumer contract

gold is the information delivery layer.

that sentence is the center of the whole post. gold is not just "the prettiest table". gold is the governed presentation and semantic layer that apps, BI, and other consumers actually depend on.

in the gold standard architecture, the information delivery layer mostly serves views over precalculated business vault tables. that is the part i care about. the expensive and reusable business meaning has already been shaped in the business vault, so the information delivery layer can focus on naming, presentation, access, governance, and consumer contract.

gold is doing its job when:

app and BI consumers get stable governed views
column names and types match the consumer contract
business logic mostly comes from the business vault instead of being reinvented in the information delivery layer
access is applied at the consumer boundary
lineage stays readable back through the business vault and raw vault
presentation views are useful without pretending the raw vault does not exist

this is why i am comfortable calling the result gold standard. not because every model is perfect forever, but because the architecture has stopped fighting itself. each layer has a job, and the jobs are finally lined up.

how i got from mishmash to gold

the move from mishmash to gold was not one heroic refactor. it was a sequence of smaller decisions that all pointed the same direction.

first, i stopped treating the raw vault like a shortcut to consumer answers. history stayed in the raw vault. presentation logic moved out. that alone reduced a lot of confusion about which table was "the real one".

second, i stopped letting the consumer layer absorb business rules just because a view was the fastest place to ship them. when a calculation needed to be reused, it went into the business vault. when a rule only mattered to one report, i still asked whether it would matter again before leaving it downstream.

third, i materialized the business vault on purpose. reusable business meaning should not live in fragile view chains that every consumer inherits differently. dynamic tables gave the silver layer a real home with refresh behavior, tests, and documentation.

fourth, i made the information delivery layer thinner on purpose. consumer views should mostly shape and govern what the business vault already proved. naming, access, presentation, and contract belong there. duplicated business logic does not.

fifth, i wrote the definitions down and treated them as architecture, not opinion. bronze means raw standardized history. silver means materialized business meaning. gold means governed consumer views over that business meaning. once that language was stable, every new model had a clearer destination.

that is how the mishmash became gold. not by pretending the warehouse was always clean, but by making the layer jobs real and then moving the work until the system matched the definitions.

what changed when i reached it

the biggest signal was that the model stopped needing a tour guide.

before gold, even a technically correct warehouse can feel like oral tradition. someone has to explain which view has the real logic, which report copied the rule slightly differently, which table is safe to query, and which one only makes sense if you know the backstory.

after gold, the path is much cleaner. the raw vault preserves the data vault 2.0 history. the business vault materializes the business meaning. the information delivery layer serves the consumer contract. if a new consumer needs a governed view, i know where it belongs. if a calculation changes, i know where it should be fixed. if an agent helps scaffold the next piece, it has a stronger pattern to follow.

what gold is not

gold is not permission to treat the consumer layer like a junk drawer.

that is the easiest way to ruin it. consumers see that layer first, so it is tempting to keep adding logic there until a view becomes the whole warehouse. the consumer layer should serve the contract. the business vault should hold reusable business meaning. the raw vault should preserve historical structure.

gold is also not an app-shaped serving layer.

copying operational table layouts can help when consumers need source-like access without querying production systems. that is still a different lane from governed presentation built over precalculated business tables.

legacy migration views are separate too. they may be necessary. they are not the bronze-to-silver-to-gold path.

why this feels worth bragging about

data vault 2.0 requires discipline for the payoff.

separate keys from relationships. preserve descriptive history. model effectivity carefully. keep business rules out of the raw vault. resist flattening everything just because the first report wants a convenient layout.

that discipline can feel expensive while the system is being built. then the gold layer arrives and the payoff becomes visible. consumers get usable views. engineering gets a clean place to maintain business logic. lineage stays readable. the next change has somewhere obvious to go.

that is the win. the raw vault gives me the historical foundation. the business vault gives me the business-enriched silver layer. the information delivery layer gives me consumer gold. getting all three to line up is the gold standard i was chasing, and i finally have it.

references

data vault 2.0 series

chapter 2 of ai-assisted data engineering is live

Philip Hern — Wed, 08 Jul 2026 12:16:16 +0000

thesis

chapter 2 of ai-assisted data engineering is live. it is called the danger of trusting the agent, and it is the darker companion to chapter 1, why ai rests on earned judgment. if chapter 1 is about the judgment that makes acceleration safe, chapter 2 is about what happens when you let acceleration run ahead of that judgment anyway.

context

i teased this back in something longer is coming, then named the book on philliant on youtube. chapter 1 shipped first because every other chapter depends on it. you cannot safely outsource judgment you have never built.

chapter 2 was already sitting in my head in a shorter form. i wrote about the same failure mode in march in the danger of trusting the ai agent, when an agent churned through files, left a clean git tree, and still left me with low confidence about what had actually happened. the book chapter takes that incident and turns it into a full argument about ownership, diffs, and the gap between a polished summary and the work that actually shipped.

argument

what chapter 2 covers

the chapter opens on a simple claim. speed without ownership becomes expensive very quickly. when an agent operates somewhere you do not understand deeply, you can inherit changes you cannot explain, verify, or recover from with any confidence.

from there it walks through four beats:

speed without ownership, where automation bias and a clean version-control tree can hide confidence drift
changes you cannot explain, including the net-zero diff incident that started as a post on this site
reading the diff, not the narrative, the habit that keeps the model's confidence from becoming your confidence by default
owning what ships, the standard that does not soften just because a model wrote the first draft

the chapter ends with a short practice list, the kind of checklist i actually use before i let high-autonomy work run in a system i am accountable for.

why it follows chapter 1

chapter 1 and chapter 2 are meant to be read as a pair. earned judgment is what makes ai useful. unowned acceleration is what makes it dangerous. i could have jumped straight into editors, models, rules, and dbt, but that would have skipped the part that actually determines whether any of the tooling helps or hurts.

if you already read chapter 1, chapter 2 is the warning label on the same bottle. if you have not read chapter 1 yet, start there. the book is written in order on purpose.

tension or counterpoint

the obvious pushback is that this sounds like fear of automation dressed up as philosophy. i do not think that is fair. i use agents constantly. the point is not to use them less. the point is to stop treating a tidy chat summary as proof that you understand what changed.

the other pushback is that chapter 2 retreads ground from the march post. partly true. the post was the first time i wrote about the failure. the chapter is where i finally gave it enough room for the habits, the downstream data risk, and the ownership standard that should sit behind every agent run.

closing

this is the second chapter in a sixteen-chapter book, released the same way as the rest of the project, little by little, one chapter at a time. chapter 3 is drafted and still in progress. when it is ready it will show up in the same writings section without any extra ceremony.

if you read chapter 2 and want to talk it through, the companion channel is philliant on youtube. the site stays the archive. the channel is where i can slow down and explain the argument out loud.

related on this site

model reviews coming soon to my youtube channel

Philip Hern — Mon, 06 Jul 2026 03:27:46 +0000

quick answer

i am planning a recurring model review series on philliant on youtube. the working idea is to talk through "models of the week", notable releases, and the models i am actually using for production work, with practical opinions based on use instead of launch hype.

the goal is simple. i want to give people a shortcut to understanding whether a model is likely to be useful to them, because i have already spent the time using it, grading it, judging it, and comparing it against the work i actually need to ship.

who this is for

people using ai models for real work, not only demos
engineers, data people, writers, and builders trying to choose between too many model options
anyone who wants practical model judgment from someone using these systems in production workflows
future me, when the model names change again and i need a record of what actually worked

why this matters

model announcements move faster than most people can evaluate them.

every week there is a new release, a new benchmark chart, a new context window, a new reasoning mode, a new coding claim, or a new tool-use demo. those announcements are useful, but they are not the same thing as living with a model inside real work.

my question is usually more practical. can this model help me ship something i understand and can stand behind? does it handle long context without losing the point? does it make good edits, or does it produce polished noise? does it improve my production workflow enough to earn a place in rotation?

that is the kind of review i want to make.

what i mean by model reviews

i am not trying to become a benchmark channel.

benchmarks matter, but they are not the whole story. a model can look impressive in a release post and still be awkward in a real workflow. another model can look less exciting on paper and still become useful because it is fast, predictable, good with tools, or strong in one narrow lane.

these reviews will be working reviews. i want to talk about how models feel after i have used them to write, reason, code, review, debug, plan, and move production work forward.

that means the reviews will probably cover things like:

what the model is good at in my workflow
where it breaks down
what kind of tasks i would give it again
what kind of tasks i would avoid giving it
how it compares with the models already in my rotation
whether the release changed my actual behavior

the model of the week idea

the phrase i keep coming back to is "model of the week".

some weeks that might mean a brand-new release. other weeks it might mean a model i finally spent enough time with to have a useful opinion. sometimes it might be a direct comparison between two models that are competing for the same slot in my workflow.

i am still deciding the cadence. weekly might be the cleanest format if releases keep moving this fast. monthly might be better if i want more time with each model before saying anything public. release-driven episodes might be the right answer when something meaningful ships and deserves a timely review.

the format may become a mix of all three. a regular rhythm when there is enough to say, deeper monthly roundups when the week-to-week noise is too thin, and immediate reviews when a release is important enough to change the conversation.

empirical evidence over launch hype

the part i care about most is empirical evidence from my own work.

i do not mean lab-grade measurement. i mean repeated use against the kinds of tasks i actually do. production code. data engineering decisions. writing. repo maintenance. documentation. debugging. model comparison. prompt repair. agent supervision.

that kind of evidence is not universal, but it is useful. if i tell you a model helped me with a hard refactor, i want to explain what made it useful. if i tell you a model fell apart, i want to explain where the failure showed up. if i tell you a model earned a place in my rotation, i want to explain what it replaced or what new capability it added.

that is the shortcut i want to provide. not a promise that my ranking should become your ranking, but a practical signal from someone already doing the work.

where this fits with the site

i already wrote a snapshot of the ai models i actually use in cursor. that post is a written roster, and it is useful as a point-in-time reference.

the youtube version should be more alive than that. models change too quickly for one static page to carry the whole conversation. the channel gives me a place to talk through what changed, what i tried, what surprised me, and what i would actually recommend based on current use.

this also fits the broader reason i launched philliant on youtube. the site stays the archive and source of truth. the channel becomes the place where i can talk through the work in a more conversational way.

closing

so that is the plan. model reviews are coming to the philliant youtube channel.

i will keep the focus practical. less hype, more use. less "this model is best", more "this model helped me with this kind of work, failed at this other kind of work, and here is what i would use it for now".

if the format works, it should help people spend less time guessing and more time choosing the right model for the work in front of them.

faq

will this replace written model posts?

no. the written posts will still be useful for reference, links, and slower thinking. the videos should add voice, timing, and current impressions that are harder to keep fresh in a static post.

will these be rankings?

sometimes, but rankings are not the main point. i care more about task fit than a single leaderboard. the better question is not "which model is best", but "which model would i trust for this kind of work right now".

will you only cover coding models?

no. coding and agentic work will be a major part of the series because that is where i spend a lot of time, but i also expect to cover writing, reasoning, long context, multimodal input, speed, cost, and general workflow fit.

references

philliant on youtube

anything i can imagine

Philip Hern — Wed, 01 Jul 2026 16:16:53 +0000

thesis

ai is great at helping me make anything i can imagine. if i can picture the answer, the process, or the steps ahead of time, the model can usually help me move faster. but that condition matters. ai is not replacing imagination. it is amplifying the parts of my imagination that i can explain clearly enough for a machine to work with.

context

the more i use ai, the more i notice that the best results do not come from asking the model to be creative in a vacuum. the best results come when i already have a clear picture in my head. i might not know every sentence, every line of code, or every implementation detail yet, but i know the direction. i know what the answer should feel like. i know the steps i would take if i had enough time and energy to do them manually.

that is when ai feels almost unfair. it takes the thing i can already imagine and turns it into a draft, a plan, a diff, a diagram, a script, or a set of options. this is related to what i wrote in ai only makes sense if you have already been through the cognitive struggle yourself. the struggle builds the mental model. once that mental model exists, ai gives it leverage.

argument

imagination is the spec

when i say ai can do anything i can imagine, i do not mean it can read my mind. i mean my imagination becomes the specification.

if i can describe the end state, the model has something to aim at. if i can describe the process, it has a path to follow. if i can describe the constraints, it has boundaries. if i can describe what would make the answer wrong, it has a way to avoid obvious failure.

this is why vague prompts produce vague work. the model can fill space forever, but empty space is not the same as direction. the value appears when i give it intent. i am still the one deciding what matters, what order the work should happen in, which trade-offs are acceptable, and when the output is good enough to keep.

process matters as much as the answer

the most useful ai work is often not the final answer. it is the process that gets me there.

if i can imagine the steps, the model can help me execute those steps without making me carry every detail in working memory. it can draft the first version, split a large task into smaller moves, compare options, run through edge cases, or turn a rough plan into something concrete. it is especially powerful when the work is procedural, repetitive, or easy to verify once the plan is clear.

but if i cannot imagine the process at all, the situation changes. then i am not leading the work. i am asking the model to invent both the path and the destination, and that is where the risk starts. i may get something polished, but i do not have enough of a mental model to know whether it is right. that is the same trap behind the danger of trusting the ai agent. confidence in the output is not the same as ownership of the outcome.

creativity is still the source material

this is the part that gets lost in the louder conversation about replacement. ai is good at doing what i can imagine, which means human creativity is still necessary.

models are built from patterns learned from human-created material, human feedback, human preferences, and human goals. even when synthetic data enters the loop, the useful signal is still downstream of human ideas and human judgment. the model can remix, extend, compress, transform, and accelerate. it can surprise me with combinations i would not have reached as quickly on my own. but it still needs a starting signal.

that signal is human. the taste is human. the reason for doing the work is human. the decision that a result is beautiful, useful, durable, funny, clear, or worth publishing is human.

ai can help me produce more of what i can imagine, but it does not remove the need to imagine. if anything, it raises the value of imagination because the person with the clearest picture can get the most leverage from the tool.

ai-assisted still means i lead

we are still living in an ai-assisted world. that phrase matters because assistance has direction. the assistant is helping the person who owns the goal.

i do not want to become the assistant to the ai. i do not want my role to shrink into approving whatever the model happens to generate next. the useful arrangement is the opposite. i set the intention. i define the boundaries. i choose the sequence. i review the work. i decide what ships. the ai helps me move through the work faster, but the work is still mine.

this is also why i need room to breathe. when the model can produce endless next steps, i have to remember that output is not the same as progress. progress is work i understand, accept, and can stand behind. ai can increase the supply of possible moves, but it cannot replace the leadership required to choose the right move.

tension or counterpoint

the obvious counterpoint is that models can generate ideas i did not explicitly imagine ahead of time. that is true, and it is one of the reasons these tools are useful. sometimes the model gives me a phrase, structure, implementation path, or connection that i would not have produced by myself in that moment.

but even then, i am still judging the result against something inside me. does it fit the goal? does it sound like me? does it solve the right problem? does it move the work forward? the model can offer possibilities, but i decide which possibilities have meaning.

that distinction keeps me grounded. ai can expand the field of options, but it does not eliminate the need for a human point of view. without that point of view, the model is just generating plausible outputs.

closing

the promise of ai is not that i no longer need to think, imagine, or create. the promise is that once i can see a thing clearly enough, i can bring it into the world faster than before.

that is a powerful shift, but it does not make the human less important. it makes the human more exposed. my imagination, taste, judgment, discipline, and leadership become the real bottlenecks. ai can assist all of them, but it cannot own them for me.

so the question i keep coming back to is simple. what can i imagine clearly enough to lead? because that is where ai becomes useful. not when it replaces me, but when it helps me build the thing i already know how to see.

DEV Community: Philip Hern

one agent, one repo, one writer at a time

quick answer

who this is for

why this matters

reads in parallel, writes in series

what about different files in different folders?

how this fits multiple chats, cloud agents, and multitask

a simple decision table

closing

faq

can two agents edit if they use different branches?

is read-only parallel work safe while another agent writes?

does this mean i cannot use parallel subagents at all?

what if the edits really are in completely unrelated packages?

how does this relate to guardrails?

references

related reading

parallel subagents: when to use them vs regular skills

quick answer

who this is for

why this matters

definitions: skills vs subagents

when to use a regular skill

when to use a parallel subagent

the pattern i use: one skill, one orchestrator, many workers

layer 1: the underlying skill

layer 2: the parallel subagent

layer 3: shared orchestration mechanics

how the parent should dispatch work

what should stay serial

a practical decision table

how to build your first parallel subagent

1) stabilize the underlying skill first

2) identify real units of independence

3) create the orchestrator file in .cursor/agents/

4) define the default scope table

5) test on a medium-sized real change

6) link it from your local cursor index

how this fits with cursor's /multitask direction

closing

faq

should i duplicate my skill checklist inside the subagent?

do parallel subagents cost more?

can i parallelize writes?

what if one subagent fails?

when should i skip parallel mode entirely?

references

related reading

low thinking mode is actually better

quick answer

who this is for

why this matters

the trade-offs: low thinking vs deep reasoning

minimal thinking mode (default)

deep reasoning mode (opt-in)

when to switch up to deep thinking

faq

does low thinking mode mean using a smaller or cheaper model?

what should i do if low thinking mode misses something?

references

related reading

im on a boat

thesis

context

argument

i preach the pause but skip it

forced disconnection is the tool i need

the work gets time away from me too

tension or counterpoint

closing

related on this site

chapter 4 of ai-assisted data engineering is live

thesis

context

argument

what chapter 4 covers

why it belongs here

closing

further reading

3) create the orchestrator file in `.cursor/agents/`

how this fits with cursor's `/multitask` direction

layer 1: a thin `AGENTS.md`

layer 2: `.cursor/README.md` as the local index

2) rewrite `AGENTS.md` as a router