DEV Community: Philip Hern

the struggle is where the posts come from

Philip Hern — Sat, 19 Sep 2026 12:32:18 +0000

thesis

most of my post ideas do not come from brainstorming. they come from the work when something fails. a ci job goes red, an agent diff almost slips through, a query behaves differently in production than it did in my head. i write to capture the struggle while it is still fresh. right now i am in a lull between major projects, watching production after months of build, and i am writing less because there is less struggle. this is uncomfortable for me, but it is also what i wanted from the build, no compromises on the way up, so now i get to sit back and let it run.

context

for the last few months the work was heavy, layered, and full of decisions that had to be right the first time we turned things on. that work is paying off now. we are seeing production results, and my job for a little while is mostly monitoring, letting everything cook, and trusting what we shipped.

in that mode the editorial calendar goes quiet. not because i have stopped caring about writing, but because my pipeline was never "think of a topic on tuesday." it was "something just happened and i need to understand it out loud." when the fires are fewer, the posts are fewer. that correlation only became obvious once i had enough distance to notice the pattern.

argument

incident-shaped posts

look at the posts i am proudest of from the last stretch of work. the missing memory of generated code started when i accepted an agent edit too fast and paid for it in debugging time. when ci fails, investigate first started when a red check forced me to slow down and read instead of guessing. neither began as a lesson plan. both began as an incident i could not ignore.

that is the method for my writing that i keep returning to. the struggle surfaces the question. the post is me answering it on the page so future me does not have to relearn the same lesson in the dark.

the ideas meeting is a trap

when work is smooth, sitting down to invent a topic feels hollow. i stare at a blank doc and wonder if i have run out of ideas. what i have run out of is immediate pressure. the model and the calendar do not hand me a problem that must be solved today.

brainstorming harder does not fix that. it just produces generic takes i do not believe yet. my better posts come from capturing the struggle, writing while the confusion is still warm, not from scheduling creativity like a standup.

the lull is earned

this is where i have to separate two feelings that arrive together. one is "i am not writing much" and the other is "the system is stable." those are related, not contradictory.

i wrote room to breathe about the need to let a solution run before piling the next change on top. monitoring mode is that idea at team scale. fewer incidents means fewer incident posts. that is a tradeoff i accept when the alternative is a production story i would not want to tell.

the lull feels like confirmation that we did the slow work right and that we did not shortcut the parts that would have made good blog fodder later at the cost of reliability now. i get fewer sparks for the site because we spent them upfront on the build.

what still works when nothing is on fire

the lull does not mean zero material. it means different material.

i can still write short notes about what "done" feels like in week one of production, what i am watching in metrics, or one small judgment call i would make the same way again. i can prep outlines for the next heavy season without pretending i am in the fight today. i can also admit when a post is thin and publish it anyway as a note, because little by little applies to momentum as much as to books.

the habit i am trying to keep is capture over performance. if the only posts i respect are crisis posts, i will miss the softer lessons and i will burn myself out trying to manufacture crises.

tension or counterpoint

the obvious pushback is that i am romanticizing struggle, as if pain is the only real source of insight. i am not claiming that. firefighting every week is exhausting, and "no compromises" is not an excuse to never ship.

the narrower claim is simpler. a calm production phase can still teach you things, but it teaches them slowly, and my instincts were trained on the fast feedback of something breaking while i am still in the room with it.

another doubt is personal. what if the dry spell means i only had things to say while i was grinding, and now the well is empty? i do not think that is true. the well refills when the next real problem shows up. the mistake is treating the between gap like a permanent failure of imagination.

closing

i will write less for a while, and i am trying not to punish myself for that. when the next thing fails back at work, my job is to write it down before the ideas meeting convinces me it was obvious all along.

until then, monitoring is the work, and the empty queue is partly proof that the last round of work was correct. i can live with that trade.

related on this site

when ci fails, investigate first

Philip Hern — Fri, 18 Sep 2026 13:22:59 +0000

quick answer

when a pull request check goes red, the most expensive mistake is asking an agent to start editing files right away. generation is fast, but unguided fixes often edit unrelated code, hide cascading failures, or break surrounding contracts. treat the agent as a diagnostic tool first. isolate the exact failing job, map the error log to changed paths, and only then apply a fix.

who this is for

audience: developers, analytics engineers, and technical leads using ai coding agents in pull-request workflows
prerequisites: familiarity with continuous integration (ci) checks, pull request reviews, and command-line execution
when to use this guide: when a pull request check fails and you need to resolve the failure without generating unnecessary code churn

context

when a continuous integration run turns red on a pull request, the natural impulse with an ai assistant in your editor is to ask it to fix the build immediately. it takes two seconds to paste a snippet of a failing log and ask the agent to make it green.

but when you tell an agent to fix a build without isolating the failure first, the agent treats the red check as a license to touch anything in sight. it refactors adjacent models, tweaks test configurations, or rewrites helper functions that were not part of the problem.

as i wrote in reading the diff is the whole job, human review capacity is the sole bottleneck in ai-assisted engineering. unguided fixes flood your pull request diff with low-intent changes, making review harder and hiding the original bug behind new ones.

the rewrite trap

when an agent attempts to fix a ci failure blindly, the failure usually compounds in one of three ways:

the shotgun edit: the agent edits business logic, documentation yaml, and CI configuration files in a single pass because the log tail contained a generic error message.
the wrong layer: a failure in a downstream view causes the agent to rewrite upstream models or warehouse schemas that were completely sound.
the environment disconnect: the agent modifies code locally to pass a test without recognizing that ci failed due to state selection, missing secrets, or workflow ordering.

the investigation loop

instead of letting an agent edit code on the first prompt, use a structured loop that treats the agent as a diagnostic tool before giving it write access.

1) freeze writes and isolate the failure

stop all code changes. do not allow the agent to edit files until you identify the single highest-order failed check. if a deploy step failed, downstream test failures are secondary noise and should be ignored until the deploy issue is understood.

2) classify the error type

ask the agent to categorize the exact nature of the failure from the log output into one of four buckets:

parse or compile error: syntax bugs, missing references, or macro failures
data quality or test failure: assertion failures or row-count mismatches
environment or configuration failure: missing environment variables, permissions, or secret mismatches
workflow or state failure: invalid state selection flags or missing upstream artifacts in slim ci

3) map log lines to changed paths

match the error message directly back to the files changed in your pull request diff. if the error occurs in a file you did not touch, ascertain whether your change caused a breaking side effect or if the test failed due to an external dependency or stale target state.

4) apply one fix and re-run

once the root cause is isolated, prompt the agent to apply a minimal fix targeting only that specific cause. change only one variable at a time so you know exactly which modification resolved the issue. review the resulting diff carefully before committing and pushing the change.

reading the diff is the whole job

Philip Hern — Sat, 05 Sep 2026 13:44:25 +0000

thesis

less than a year ago, ai assisted around the edges while i still hand-wrote most of my code. today, working completely solo, my workflow has flipped entirely. i rarely write code by hand anymore. instead, i interact almost continuously with an ai chatbot and spend my time reading the diffs produced by agents. this shift arrived exactly as predicted, and it exposes the real constraint of modern software engineering which is that generation costs have dropped to near zero, so reading the diff has become the whole job, the human reviewer is the only remaining bottleneck, and deep domain mastery is the only thing standing between acceleration and production failure.

context

a year ago, writing code was still a manual process where an ai tool helped auto-complete a function, generate boilerplate, or suggest a regex. the mental model was simple: i wrote the code, and the tool accelerated my typing.

today, my daily interaction model is almost exclusively conversational and review-driven. i state intent to an agent, evaluate the proposed file changes in a diff viewer, and accept or reject the output. what used to be a future prediction about how engineering workflows would evolve inside a single year is now my everyday reality.

this shift changes where leverage lives. when you no longer spend hours typing out logic, you do not automatically ship features faster. you simply reach the review step sooner. as i wrote in the missing memory of generated code, generation time has shrunk to near zero, but verification time remains constrained by human limits.

argument

the human reviewer is the sole bottleneck

an ai agent can edit five files, refactor three joins, and rewrite a test suite in twenty seconds. but a human brain reads, evaluates, and comprehends code at the exact same speed today that it did twenty years ago.

this asymmetry creates a stark reality: if you want to accelerate your engineering output today, prompting faster or asking for larger code dumps yields diminishing returns. diff literacy, the speed and accuracy with which you can read, parse, and evaluate proposed code changes, is the primary skill that unlocks actual delivery speed. if your diff review is slow or superficial, your delivery speed drops to match your reading speed, or worse, drops to zero when you spend the afternoon debugging an unread change.

reading the diff is a proxy for code memory

when you hand-write code line by line, you acquire a mental map of the implementation for free. you remember wrestling with a specific edge case, handling a null value, or choosing one join condition over another.

when an agent writes the code, that cache does not exist. the code arrives fully formed. reading the diff line by line is not a bureaucratic formality, it is the minimal investment required to build working memory for code you did not write yourself. if you accept an edit without reading it carefully, you are operating code you do not understand, leaving you helpless when it breaks later in production.

the reject and re-prompt loop

working exclusively with agents requires normalizing rejection. it is extremely common in my daily workflow to read a diff, reject the changes entirely, and send the agent back with specific feedback.

a prompt loop usually looks like this:

issue a clear intent or task to the agent
inspect the resulting diff line by line
spot a subtle defect, missing constraint, or bad assumption
reject the edit and issue supplemental instructions explaining exactly why the first attempt failed

re-prompting effectively depends on diff literacy. if you cannot spot why the first diff was wrong, you cannot give the supplemental instructions needed to guide the second attempt.

why domain mastery still matters

some people assume that if agents write all the code, domain expertise is no longer necessary. but the opposite is true.

as i argued in ai only makes sense if you have already been through the cognitive struggle yourself, if you have not paid your dues through years of hands-on problem solving, you cannot evaluate what the agent produces. an agent will confidently generate syntactically valid code that satisfies an underdeveloped prompt while violating business rules, grain constraints, or edge-case logic.

without earned domain mastery, you cannot spot those subtle errors in a diff. you end up approving plausible-looking breaking changes, borrowing speed today against troubleshooting debt tomorrow.

tension or counterpoint

a common objection is that reading diffs carefully takes too much time and defeats the purpose of using ai for speed. why not trust the agent's test suite or rely on automated linting?

automated checks are necessary, but they only test for what you explicitly wrote checks for. they do not validate unstated business intent or subtle domain shifts. skipping diff review to save three minutes on approval usually costs three hours of reverse engineering when an unread edge case corrupts downstream data.

closing

i no longer measure productivity by how much code i write. i measure it by how quickly and accurately i can evaluate the code my agents propose. the shift to agentic coding does not eliminate human responsibility, it means reviewing is the primary engineering discipline.

master your domain, sit with the diff, and treat every line of proposed code as something you will personally have to explain and maintain when it runs in production.

when choosing an ide means choosing a model

Philip Hern — Sat, 29 Aug 2026 13:38:20 +0000

thesis

when choosing a code editor forces you into a specific set of ai models, developers lose the ability to compare tools and select the best model for the job.

context

openai recently announced that it will terminate its model supply agreement with cursor on november 12, 2026. this decision follows spacex's $60 billion acquisition of cursor's parent company, anysphere. openai cited concerns over contract compliance and terms of service, pointing to past disputes with companies under elon musk such as x and xai. while cursor will continue to operate with alternative models including grok (i expect to see this pushed harder since it is the ai offering from spacexai), claude, and gemini, direct access to openai's lineup and future releases like astra will no longer be available in cursor's built-in picker after the deadline.

argument

one of the most valuable aspects of modern development tools like cursor is multi-model access. i rarely rely on a single model for every task. different architectures excel at different problems, ranging from quick single-file refactoring to complex code generation or debugging. being able to evaluate multiple models side by side within the same interface helps developers stay informed about model capabilities without switching contexts.

when vendor disputes force models out of specific editors, developers lose that neutral ground. choosing an ide starts to mean choosing an ai provider rather than choosing the editor features themselves. this shift introduces artificial barriers and deepens existing biases, like brand loyalty over actual performance, in tool selection.

for developers who use multiple models daily to keep up with fast-moving technological changes, these restrictions reduce flexibility. corporate feuding between model providers and parent companies creates walled gardens that ultimately increase operational complexity and limit choices across the ecosystem.

tension or counterpoint

providers have a legitimate interest in enforcing terms of service and protecting intellectual property when corporate changes occur. change of control clauses exist to protect vendors when a customer is acquired by a competitor. however, when these corporate rivalries play out at the platform layer, developers bear the cost of reduced access and fragmented workflows.

closing

i will be monitoring how the developer tool ecosystem adapts as model access becomes increasingly tied to corporate partnerships and platform ownership.

full disclosure regarding this website and my writing

Philip Hern — Mon, 24 Aug 2026 11:41:55 +0000

thesis

i want to give full disclosure regarding this website and my writing. just like my book about ai-assisted data engineering, this website and its content are ai-assisted. i do the writing, outlines, editing, and creative steering, while the ai helps me build faster, maintain the site, and execute ideas.

context

i created this website as an ai experiment to begin with. i use ai to publish posts faster, handle technical setup, develop code, and maintain the site infrastructure.

i am not trying to pass off ai work as entirely my own without assistance. i fully admit and own that this website and its content rely on ai tools. at the same time, just like in my regular work, i review all ai changes before anything goes live. human review and judgment remain central to everything on this site.

argument

how i work with ai

my process for writing and building on this site keeps human direction at the center. i provide the ideas, outline the arguments, draft the prose, and edit the final output. the ai handles the execution steps, code generation, formatting, and technical maintenance that would otherwise slow down the cadence.

this approach gives me the speed of automated workflows without sacrificing ownership of the ideas. the ai assists, but i remain responsible for every line of code and every word that gets published.

upcoming creative experiments

in the near future, i will also be running some creative experiments with ai on this site. i plan to set up comparative runs where i let the ai make decisions independently in one branch, while i actively steer the ai in another, and then compare the resulting products side by side.

these experiments will let us see how much direction affects the quality, coherence, and voice of ai-assisted work. making full disclosure up front ensures that as these experiments launch, the context behind them is clear.

closing

full transparency matters to me. using ai does not mean handing over control, but it does require admitting where and how assistance is used.

i will continue to review every change, direct every project, and share the results as these creative experiments unfold.

related on this site

anything i can imagine

the missing memory of generated code

Philip Hern — Sat, 22 Aug 2026 12:15:19 +0000

ai models can write a complex query or function in ten seconds. that speed is impressive, but it creates a dangerous illusion. generation time has dropped to near zero, but the time to ship a working, reliable product has barely moved.

the bottleneck has simply shifted from creation to verification. and when you skip or rush that verification step, you pay for it twice: first when a subtle bug enters production, and second when you try to debug code you have no memory of writing.

quick answer

humans must stay the gatekeeper because models lack understanding of subtle domain intent. when an agent edits code for you, the review step is not a formality. if you accept an edit without scrutinizing every line, you miss quiet logic shifts, like changing a union to a union all (this happened to me two days ago).

more importantly, when you do not write the code yourself, you build no mental map of how it works. when it breaks later, you cannot search your memory for potential failure points. you are forced to rely on diffs or ask the ai to fix a bug in code neither of you truly understands.

who this is for

developers and data engineers using cursor or ai agents for daily coding
builders who notice their prompt-to-code velocity is high, but their actual feature delivery speed feels unchanged
anyone who has spent hours troubleshooting a subtle bug introduced by a accepted ai edit

why this matters

the promise of ai-assisted engineering is speed. but there is a distinct difference between the speed of draft creation and the speed of shipping a verified product.

when you draft code by hand, the typing is slow, but your brain is actively mapping every branch, clause, and edge case. you hold a warm cache of the implementation in your working memory. if a bug surfaces during testing, your brain immediately knows which lines are suspect because you remember wrestling with that specific logic.

with ai generation, that warm cache does not exist. the code appears fully formed. if you accept it without rigorous review, you trade a few minutes of careful reading for hours of painful reverse-engineering later.

subtle changes that break systems

ai models are trained on vast patterns, but they do not understand the subtle constraints of your specific data model or domain rules. they produce code that looks syntactically clean and runs without immediate syntax errors, but subtly alters behavior.

a few days ago, i missed verifying a single line in an agent's suggested edit. the agent changed a union to a union all.

syntax-wise, the query was perfectly valid. dbt compiled it without complaint. snowflake executed it smoothly. but functionally, it duplicated records, altered downstream row counts, and broke downstream business logic.

because i had accepted the edit without inspecting that line, the change was completely absent from my memory. when the pipeline failed downstream, i could not pull from my own mental model of what i had written. i had to search line by line, inspect git diffs, and query the codebase repeatedly just to locate a flaw that a human hand would have recognized instantly during drafting.

the tax of lost author memory

when you write code yourself, debugging is an internal search. you ask yourself:

"did i handle nulls in that join?"
"did i filter out inactive status records?"
"where did i put the group by clause?"

when an ai writes the code and you skim the review, debugging becomes an external investigation. you do not remember the choices made because you did not make them. you are suddenly a third-party reviewer auditing someone else's pull request under pressure.

this creates a frustrating feedback loop:

the ai generates code in seconds.
you accept the change quickly to maintain momentum.
a subtle logic bug surfaces during testing or execution.
you have no mental model of the code, so you cannot guess where the issue lies.
you are forced to ask the ai to diagnose the bug in the very code it hallucinated or misconstructed.

this loop destroys the speed advantage of ai generation. the time saved on typing is entirely consumed by reverse-engineering unremembered code.

human gatekeeping is not optional

this is why the human gatekeeper is non-negotiable.

an ai agent can summarize files, scaffold structures, and suggest implementations. but it cannot take responsibility for the result. it does not know that a union all in your model will cause duplicate downstream joins, or that a subtle cast will drop timestamp precision needed for a snapshot.

to keep ai workflows sustainable, treat every generated line as an unverified pull request from a junior developer who works at lightning speed but lacks context:

read every line of the diff before accepting. if you do not understand why a line changed, do not accept it.
treat verification as the primary work. typing was never the bottleneck in software engineering; understanding and correctness always were.
keep the write lane strictly under human control. let agents read, search, and propose, but keep the final decision and write application strictly gated by your own judgment.

the goal is not to stop using ai agents. the goal is to realize that true speed comes from tight verification, complete ownership, and never letting code into your repository that you do not fully understand.

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.

DEV Community: Philip Hern

the struggle is where the posts come from

thesis

context

argument

incident-shaped posts

the ideas meeting is a trap

the lull is earned

what still works when nothing is on fire

tension or counterpoint

closing

related on this site

when ci fails, investigate first

quick answer

who this is for

context

the rewrite trap

the investigation loop

1) freeze writes and isolate the failure

2) classify the error type

3) map log lines to changed paths

4) apply one fix and re-run

related reading

reading the diff is the whole job

thesis

context

argument

the human reviewer is the sole bottleneck

reading the diff is a proxy for code memory

the reject and re-prompt loop

why domain mastery still matters

tension or counterpoint

closing

when choosing an ide means choosing a model

thesis

context

argument

tension or counterpoint

closing

full disclosure regarding this website and my writing

thesis

context

argument

how i work with ai

upcoming creative experiments

closing

related on this site

the missing memory of generated code

quick answer

who this is for

why this matters

subtle changes that break systems

the tax of lost author memory

human gatekeeping is not optional

related reading

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

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

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