Questions,
answered.

No. TDD is a unit-level rhythm for a developer to design code. Spec-driven development is the BDD / acceptance-test-driven lineage: the product's acceptance criteria, expressed executably (Gherkin's Given/When/Then), gate whether the work is done. Different layer, different author, different purpose.

Full context: What is spec-driven development? →

Writing criteria costs minutes. Shipping a green-but-wrong feature costs hours or days downstream. On the measured tasks it removed the genuine-bug rate entirely.

Full context: What is spec-driven development? →

No. You can do it by hand. A tool helps when you want the criteria and the execution gate on every task without remembering to.

Full context: What is spec-driven development? →

No. The agent wrote the code and, in the same pass, wrote the tests around it, so green means the code agrees with itself, not that it matches what you wanted. Across 120 runs on this benchmark, with only a one-line request, 40% shipped a genuine correctness bug with the build green and tests passing. Compiling and being correct are two separate claims, and a green build only checks the first.

Full context: Spec-driven development: a green build is not a correct feature →

Because LLMs are not deterministic, even at temperature 0; floating-point order and provider-side batching see to that. Run a task three times and you can get correct, correct, broken. On this benchmark 15% of cells disagreed with themselves between runs. So "it worked when I tried it" is a single draw from a distribution you cannot see, and the run you eyeballed is not the run you shipped.

Full context: Spec-driven development: a green build is not a correct feature →

Not on its own. A stronger model fails less often but more plausibly, which makes the wrong runs harder to catch, not easier. Even the strongest config measured still shipped a genuine bug in a share of raw runs and flipped between runs on the hard feature. None reached zero without a gate. What drove every model to 0% genuine bugs was writing the acceptance criteria up front and checking them by execution.

Full context: Spec-driven development: a green build is not a correct feature →

By turning the product's acceptance criteria into an execution gate. You write what "done" means before the agent starts, ideally executably, then verify against it by running the code after it finishes, every time. On this benchmark the raw arm shipped a bug in 40% of runs and the arm with criteria up front in 0%, and a cheap model with a spec matched a frontier model without one. Not spec-driven, where criteria sit in a document, but spec-gated, where they decide.

Full context: Spec-driven development: a green build is not a correct feature →

Not exactly. Spec-driven development defines the acceptance contract before implementation. Portability makes that contract able to move between tools while retaining its connection to the code and verification that followed.

Full context: Software specifications should be portable →

No. It preserves the contract; runtime validation and acceptance evidence are still what establish correctness.

Full context: Software specifications should be portable →

It gives another agent, teammate, or future maintainer the intent, decisions, tasks, and verification context behind the code rather than forcing them to infer it from a diff.

Full context: Software specifications should be portable →

It is a different shape. Normal debt is usually code you understood and chose to defer cleaning. Vibe coding adds comprehension debt on top: code you never read, so you owe understanding before you can assess the rest.

Full context: Vibe coding debt: what you actually owe and when it's due →

No. Add them to the paths that would hurt a user if they silently broke, and add them before you change those paths. Full coverage on a throwaway prototype pays down a debt that is not charging interest.

Full context: Vibe coding debt: what you actually owe and when it's due →

Pay comprehension debt first because everything depends on it, verification debt next on load-bearing paths, and architecture debt last and only where it blocks the change you actually need to make.

Full context: Vibe coding debt: what you actually owe and when it's due →

No. It is unreviewed, which is different. The same agent writes secure code when security is part of the contract and leaky code when the only requirement is that it runs. The risk comes from skipping review, not from the model.

Full context: The security holes vibe coding leaves behind →

Secrets. Make sure no API keys or credentials live in your source or git history, because that hole is the easiest to exploit and the easiest to close. Then move to input validation and dependencies.

Full context: The security holes vibe coding leaves behind →

For most vibe-coded apps, no. Getting secrets out of source, validating input at the boundary using established guidance, and scanning dependencies closes the common holes. A specialist matters once you handle sensitive data at scale.

Full context: The security holes vibe coding leaves behind →

Usually not. A rewrite throws away a working, validated definition of your product and forces you to rediscover it by breaking things for real users. Rewrite only when you have learned the product should be fundamentally different, not because the code looks messy.

Full context: Your Lovable prototype is now the product: surviving the promotion →

Follow the users. The paths that handle their data, their money, or their core workflow are load-bearing and need tests and hardening. The rest can stay scrappy until it earns the attention.

Full context: Your Lovable prototype is now the product: surviving the promotion →

When someone depends on it in a way that would hurt them if it broke. There is rarely a launch moment. The dependency is what changes the requirements, whether or not anyone announced it.

Full context: Your Lovable prototype is now the product: surviving the promotion →

Usually not. Early code is exploratory and mostly disposable, and testing code you are about to delete is wasted effort that also makes you reluctant to delete it. Wait until a path becomes load-bearing.

Full context: When to add tests and architecture to an AI-built project →

A path is load-bearing when breaking it would hurt a real user and you are going to keep changing it. Both conditions have to hold. High stakes with no change, or high change with no stakes, do not urgently need the investment.

Full context: When to add tests and architecture to an AI-built project →

Tests first, as characterization tests that pin down current behavior, then architecture using those tests as a safety net. Refactoring without tests reintroduces the regressions you were trying to prevent.

Full context: When to add tests and architecture to an AI-built project →

No. It is an accurate signal that a load-bearing path has no safety net. The right response is not to push through the fear or freeze, but to build the net where the fear is pointing.

Full context: Scared to touch it: turning fear of your own codebase into a safety net →

A test that pins down what code currently does rather than what it ideally should do. On AI-built projects you rarely have a clean spec, so you lock in the existing behavior first, which lets you change the code and immediately see if you altered anything.

Full context: Scared to touch it: turning fear of your own codebase into a safety net →

Start where the fear is sharpest. The paths you least want to touch are the load-bearing, unprotected ones. Recover their behavior, pin it with tests, and require evidence on changes, then move outward.

Full context: Scared to touch it: turning fear of your own codebase into a safety net →

It can build something that looks like one. In this experiment the Codex app delivered a nicer-looking home screen than PaellaDoc, then died on the first click: four of five sections and every create form crashed with a Svelte error, while its one check, svelte-check, passed with zero errors. You can have a green build and an app nobody has ever seen start. The demo wins in ten minutes; the working software is a different question.

Full context: I asked the Codex app to build an app twice. Neither made it to tomorrow. →

Because a fast build hardcodes the moment it was made. The second Codex attempt verified on the same Saturday it was generated, so it bought "works today" literally: the date "11 de julio" and a "good morning" greeting were baked into the template, the expense form sent a fixed date so every later expense booked on July 11, and the today-panel filtered on a literal date string and went empty from the 12th on. The failures never show in the demo, only the day after.

Full context: I asked the Codex app to build an app twice. Neither made it to tomorrow. →

No. Asked to verify, the Codex app did, and it helped: clicks worked, forms validated, it shipped a few passing tests. But it was one manual pass on the day of generation that missed two widgets contradicting each other on the same screen, and it left no script to run again. Verification that depends on the user knowing to ask for it, and on a fifteen-minute pass catching everything that can fail tomorrow, is not verification.

Full context: I asked the Codex app to build an app twice. Neither made it to tomorrow. →

Because the tokens go into the loop, not the code. Of 582 million tokens, writing code took 2.39 million; the rest was running the app, looking at it, and going again, 541 times, leaving 59 e2e cases, 218 commits, and a screenshot plus JSON of evidence per acceptance criterion. That is the cost of running an agent inside a gate that re-checks every change instead of trusting its own one-time sign-off. The gates stay in the repo, so the next change takes the same exam.

Full context: I asked the Codex app to build an app twice. Neither made it to tomorrow. →

No. It is the right mode for exploration, prototypes, and any work where being wrong is cheap. It becomes a problem only when you stay in it after the code starts mattering, which turns skipped verification into accumulated risk.

Full context: Vibe coding vs AI-assisted engineering: the line that matters →

Acceptance. Vibe coding accepts generated code because it appears to work. Engineering accepts it because it has been shown to meet a contract defined in advance. The tools, models, and speed are the same.

Full context: Vibe coding vs AI-assisted engineering: the line that matters →

No. The mode is a per-change decision. Prototype a feature on vibes, then switch to engineering when that feature becomes load-bearing. The skill is knowing which the moment calls for.

Full context: Vibe coding vs AI-assisted engineering: the line that matters →

Start by refusing to let the agents build until you know what behavior you're installing and why. The code is the cheap part now; deciding what to build is where the cost moved. Define intent you can defend, turn it into a specification with acceptance criteria a machine can check, and only then point agents at the task.

Full context: Building software with AI agents: the operating guide →

Something outside the agent to hold the contract, because the agent can't judge whether its own code counts. That means a spec that says what must change and stay true, memory that persists decisions and invariants outside the chat, and gates that prove work is done. With one agent in one chat, that something is you.

Full context: Building software with AI agents: the operating guide →

Not by trusting "done" and not by a green build. Done means the behavior passes the acceptance criteria that existed before a line was written, with the evidence attached. At agent speed you get too many claims to check by reading, so verification has to become gates the system runs against the real behavior, not eyeballing a summary.

Full context: Building software with AI agents: the operating guide →

The moment you go from one to several, the work becomes operations: splitting the product into tasks, running parallel sessions, fighting context loss, persisting shared memory, and reconciling agents that can't see each other. It only scales when the same contract flows through define, specify, execute, verify and learn, instead of living in your head.

Full context: Building software with AI agents: the operating guide →

A strong developer can run Claude Code well by hand, acting as the scheduler, memory, gate and recovery loop. A delivery runtime moves that orchestration off the developer so work can span many tasks, repos and hours without a human holding it all in their head.

Full context: You do not have a Claude Code problem. You are the runtime. →

In a four-episode recovery benchmark, prompt-only and skill-only Claude Code plateaued at 66.67%, and bigger models in n=1 controls did the same. A governed recovery runtime reached 100%. The gap was not raw intelligence, it was holding the contract and recovering across episodes.

Full context: You do not have a Claude Code problem. You are the runtime. →

Not when the agent says so, and not when the build is green. Done is the behavior passing the acceptance criteria that existed before a line was written, with the evidence attached.

Full context: You do not have a Claude Code problem. You are the runtime. →

Some orchestration will get absorbed. PaellaDoc does not compete to be the best executor; it is the portable, local-first, multi-engine layer where the product contract, gates, evidence and run memory live, above any single agent or vendor.

Full context: You do not have a Claude Code problem. You are the runtime. →

It depends on the model. A context pack lifted a cheap model from 0.56 to 0.83 quality at the same cost and about 2.4x faster. On frontier models that already explore well, it mostly added cost and little or no quality. The value of context is inversely proportional to the power of the model. Measured in Claude Code.

Full context: Context engineering for coding agents: when it helps and when it hurts →

Yes. On the hardest task, tracing an end-to-end flow, a partial context pack made a strong model leave parts out: quality dropped from 0.83 to 0.47. A partial map can blind a model that would explore better on its own. n=3 per cell, high variance.

Full context: Context engineering for coding agents: when it helps and when it hurts →

The experiment used cloud models, so this is an extrapolation, not a measurement. The clearest result was that a context pack lifts a cheap model to frontier quality. Local models sit further down that capability axis, so context should help them more, not less. That is the next test and the sovereignty bet: your code and your model on your machine, with a map good enough that you do not need to rent frontier intelligence.

Full context: Context engineering for coding agents: when it helps and when it hurts →

No. Across 19 headless runs with --print, the path CI and SDKs use, the auto router chose the strong model zero times. It only escalates in interactive plan-mode. In automation, auto behaves like the cheap model.

Full context: Context engineering for coding agents: when it helps and when it hurts →

No, verified by execution. I extracted the function from all 28 edit runs and ran each one against 7 canonical test cases. All 28 passed 7 of 7, Sonnet included. The frontier model produced the same correct result at 5 to 6 times the cost.

Full context: Context engineering for coding agents: when it helps and when it hurts →

A frontier model is the right tool when you cannot supply context: less technical users, or anyone for whom raw intelligence is the cheapest path to a good answer. A developer who can bring the relevant files and symbols stops needing to pay that premium, as the cost-versus-verified-correctness data shows.

Full context: Context engineering for coding agents: when it helps and when it hurts →

Because the reasoning lived in the chat, and the chat is a working surface that gets erased. The code survives as a file; the decisions, invariants and intent behind it don't, unless they were written somewhere durable. A new session starts cold and knows what the code says and nothing about why it says it.

Full context: Context loss between sessions: the productivity killer nobody budgets for →

No, and they need different fixes. Within a session, the window fills and compaction summarizes lossily, dropping the specifics you cared about most. Between sessions, nothing carries over at all, because the window is per-session. One is a compression problem, the other is a persistence problem.

Full context: Context loss between sessions: the productivity killer nobody budgets for →

Only at the margin. A larger window is more room to fill, not a guarantee of keeping the right things, and a long run compacts eventually regardless of size. More fundamentally, the window is per-session: no window, however large, persists after you close it. Between-session loss is not a capacity problem.

Full context: Context loss between sessions: the productivity killer nobody budgets for →

Stop using the chat as storage. Write decisions down when they're made, keep invariants in a rules file the agent reads at the start of every session, and let a task's intent travel with it as an artifact. When those live in the repo instead of a closed transcript, a cold session stops being a cold start.

Full context: Context loss between sessions: the productivity killer nobody budgets for →

Not everything. Three kinds of thing earn a place: decisions (a choice among alternatives, with the reasoning that rules out re-proposing them), invariants (rules that must hold across changes), and state (the current status of the work). Remember everything and you rebuild the context-window problem in a database; remember nothing and every session starts cold.

Full context: Memory for coding agents: what should persist outside the chat →

In different shapes, because the form is half the content. Decisions want an append-only log where history is the value. Invariants want the rules file the agent reads first, so they bind every write. State wants a single overwritten snapshot with no history. Cram all three into one document and each corrupts the others.

Full context: Memory for coding agents: what should persist outside the chat →

Because they require a human to maintain them, so they die the moment the human gets busy, and a decision log nobody updates lies with authority. The only version that survives is memory the work writes as a side effect: a decision logged in the session it's made, an invariant landing in the rules file as part of finishing the task.

Full context: Memory for coding agents: what should persist outside the chat →

Not all of it. That's exactly where the three kinds collide: invariants get buried under state churn, decision history flattens into a current-status blob, and the agent reads a soup it honors none of reliably. Keep invariants in the rules file, decisions in a log, and state in its own snapshot.

Full context: Memory for coding agents: what should persist outside the chat →

Three disciplines. Isolate each agent in its own worktree so they cannot corrupt each other's files while they work. Give them a shared contract — the interfaces and invariants both read from outside either session — so the parts that span them are specified, not improvised. Then reconcile at the merge, checking the combination is coherent, not just each branch alone. Skip any one and collisions eat the speedup.

Full context: Orchestrating multiple coding agents without them poisoning each other →

Not on the same working surface. Two agents writing to the same files corrupt each other's state constantly, because neither can see the other's uncommitted changes. The fix is isolation: each agent gets its own checkout, branch and directory through git worktrees. Collisions are deferred to the merge, where they can be handled deliberately instead of racing. Isolation buys safety during execution, though not coherence — that needs a shared contract and reconciliation.

Full context: Orchestrating multiple coding agents without them poisoning each other →

Contamination is when two locally correct changes combine into a broken whole. Agent A refactors an interface; Agent B, in its own session, builds a feature against the old shape because nothing told it the shape changed. Both pass their own checks, yet together they produce code that will not compile, or worse, compiles and is quietly wrong. It happens because no single agent's context contains the fact that another agent edited something.

Full context: Orchestrating multiple coding agents without them poisoning each other →

With reconciliation, not git merge and hope. Reconciliation deliberately brings parallel branches together and checks the combination: does B's feature still work against A's refactored interface, did anyone break an invariant that only mattered across the boundary, does the integrated result pass the criteria the pieces passed alone. It is verification aimed at the seams, which is exactly where parallel agents fail, because the seams are where no individual agent was looking.

Full context: Orchestrating multiple coding agents without them poisoning each other →

Drift is the gap that opens between what you intended and what the agent is doing. An agent steers by its context, which is always a partial, decaying picture of your intent — some never written down, some compacted away mid-session, some inferred slightly wrong. It fixes the thing in front of it, which shifts what "the problem" means, then fixes the next thing against the shifted meaning. Step by step, each locally reasonable, it walks away from where you pointed it.

Full context: Agents will drift: engineering for divergence instead of praying against it →

No, not reliably. The prompt is a snapshot; drift is a process. You can point the agent precisely at the target at time zero, but you cannot make that precision persist, because what erodes it — compaction, inference, the accumulation of small local decisions — happens after the prompt is delivered and keeps happening. A perfect prompt reduces the initial error and does nothing about the accumulation over a long run.

Full context: Agents will drift: engineering for divergence instead of praying against it →

Not on its own. Drift is not a smartness problem, it is a distance-from-a-fading-target problem. A smarter model can still drift, because the intended behavior lives in the specification and the agent's connection to that specification degrades over the run. The durable answer is to re-anchor the agent to something that does not fade — a spec that exists before a line is written and stays readable throughout.

Full context: Agents will drift: engineering for divergence instead of praying against it →

You do not prevent drift, you catch it early and cheaply. Break work into chunks small enough that the agent cannot wander far before it is re-anchored to the contract. Use checkpoints that measure distance from intent, not just whether the code works. And treat reconciliation as a first-class step where divergence is brought back deliberately. A coordinator built this way gets steadier as you add agents, not shakier.

Full context: Agents will drift: engineering for divergence instead of praying against it →

There is no fixed number; the limit is where the coordination cost outruns your attention, and it is different for everyone. What is predictable is the shape: five sessions can feel productive and eight can feel like drowning, even though it is only three more. The cost is superlinear because the switching between sessions grows faster than the session count. You extend the ceiling by moving the scheduler's jobs into the system, not by being more heroic.

Full context: Running eight sessions: worktrees, parallelism and the cost of being the scheduler →

Use git worktrees: one worktree per task, a branch per worktree, an agent per branch. A worktree is a second working directory backed by the same repository, on its own branch, so each agent edits at full speed without touching another's files. The naive setup — several agents in one directory — corrupts itself immediately, because agents cannot see each other's uncommitted changes. Worktrees give the isolation that everything else depends on.

Full context: Running eight sessions: worktrees, parallelism and the cost of being the scheduler →

Because you become the scheduler, and five concurrent jobs land on you at once: priority, context, recovery, routing and integration. They are interrupt-driven, so you are pulled to whichever pane demands you mid-thought on another, and every switch pays the cost of reloading what you were doing. That reload is context loss hitting you in real time, eight ways at once. The sessions scale linearly; the coordination running on you does not.

Full context: Running eight sessions: worktrees, parallelism and the cost of being the scheduler →

A worktree is a second working directory from the same repository on its own branch. Agents need them because isolation is the precondition for parallel work: without it, two agents writing to the same tree overwrite and confuse each other constantly. Worktrees do not make collisions vanish, they move them to the merge, where you can handle them deliberately. This is the mechanical floor under all multi-agent orchestration.

Full context: Running eight sessions: worktrees, parallelism and the cost of being the scheduler →

Both, for different jobs. Keep the operational facts (build, test, layout, safe commands) in AGENTS.md so every engine can read them. Keep Claude-specific behavior in CLAUDE.md if Claude Code is one of your executors. Do not duplicate the same content into both, or you inherit the drift problem the moment one copy changes.

Full context: AGENTS.md, CLAUDE.md, cursor rules: where your decisions should actually live →

In an artifact that carries the reason and can be verified, close to the work it governs: a spec, a decision record, or the acceptance criteria on the task. Rules files compress decisions into commands and lose the why, and they are bound to one tool. A decision needs to outlive both the session and the engine.

Full context: AGENTS.md, CLAUDE.md, cursor rules: where your decisions should actually live →

If you use Cursor and want its scoping and per-glob application, yes, for tool-specific behavior. Just do not let it become the only place a real decision is written down, because it is invisible to every other agent you might route work to.

Full context: AGENTS.md, CLAUDE.md, cursor rules: where your decisions should actually live →

Continuously for the mechanical parts and on a schedule for the rest. Wire a check that fails your build when a path or command in the file no longer resolves, so dangling references get caught the day they appear. Then do a deliberate audit of the conventions every few weeks, ideally by having an agent compare the rules against the current code.

Full context: Your rules file is lying to your agents: keeping instructions alive →

Three signals: it references a path or command that no longer exists, it describes a convention the recent commits contradict, or you cannot say why it is there. The first is scriptable, the second an agent can audit against the codebase, and the third means the rule has no provenance and should not be trusted until it does.

Full context: Your rules file is lying to your agents: keeping instructions alive →

Use the agent to detect drift, not to rewrite the file unsupervised. "Which instructions does the code contradict?" is a good question with a checkable answer. "Rewrite my rules to be better" produces plausible slop. Keep the human deciding what stays; let the agent do the finding.

Full context: Your rules file is lying to your agents: keeping instructions alive →

Resume from the last checkpoint where the work was known-correct, not from the beginning, and give the resumed run the record of what was already green so it can tell continuation from regression. This only works if you checkpointed at episode boundaries and kept the plan and constraints outside the agent's context. If the only artifact is a long transcript, you are reconstructing, not recovering.

Full context: The run died at 2am: recovery as a first-class workflow →

Re-running works for transient failures like a rate limit, but a lot of long-run failures are drift, not crashes: the agent lost a constraint and kept going. Re-running from the top often loses the same constraint the same way, and it throws away all the correct work to escape the incorrect tail. Recovery needs a last-good state and a way to score the resumed work against the original contract.

Full context: The run died at 2am: recovery as a first-class workflow →

Three things: a last-good checkpoint at each episode boundary, the plan and constraints stored outside the run so compaction cannot erase them, and a record of which gates were passing before the failure. With those, a resumed run can continue from a known point and detect if it just broke something that used to work.

Full context: The run died at 2am: recovery as a first-class workflow →

Model routing treats the task, not the model, as the unit of work. When a task comes in, a router picks which engine runs it and at what profile — cheap, balanced, strong or frontier — based on the kind of task, which engines are actually available, the cost and latency you accept, and what worked before. A copy edit and a database migration are not the same job, so they should not default to the same expensive engine.

Full context: No vendor lock-in: route every task to the right engine →

Treat engines as a fleet under one contract instead of wiring your work to a single model. When a provider changes pricing, adds a rate limit, or a model gets pulled — as happened the week an export-control order disabled one mid-week — you route to another engine and the work keeps moving, turning an outage into a config change. The floor under it is open source: a local model through Ollama that no vendor or government can switch off.

Full context: No vendor lock-in: route every task to the right engine →

For one-off work, a single CLI routing inside its own vendor is plenty — Claude Code plans with one model and executes with another. It stops being enough when you want a product across engines: none of them will send your cheap task to one engine, your migration to a frontier model, and your offline work to a local one, or answer availability, cost and fallback across vendors. The decision layer across engines is the product.

Full context: No vendor lock-in: route every task to the right engine →

It should not, and a good one does not. A router that offers an engine that cannot launch is worse than no router. Before any smart decision, the candidates are filtered to engines the runtime can genuinely start on this machine: the adapter exists, reports available, and is authenticated. And when a smart router does run, it only picks the agent and profile — the model, effort and context come from verified config, with a deterministic rules fallback if anything breaks.

Full context: No vendor lock-in: route every task to the right engine →

It is the emerging practice of building and tuning the loop a coding agent runs inside: how context is assembled, which tools the agent can call, how output gets verified, and how failures get recovered. The term is used loosely across the agent-operations community, including Anthropic's engineering writing, to name the system around the model as opposed to the model itself.

Full context: Harness engineering: the discipline forming around agent operations →

Once the model is good enough to write correct code from correct context, yes, the harness becomes where reliability is won or lost. In a controlled recovery test, the same coding agent plateaued or reached 100% depending only on the loop around it, not the model. Below that threshold the model still matters; above it, the harness dominates.

Full context: Harness engineering: the discipline forming around agent operations →

A prompt is one input to one call. A harness is the whole loop: it assembles context across many calls, runs tools, verifies output against gates, recovers failed runs, and moves work between sessions. Good prompting is part of it, but a prompt with no verification, no recovery and no context management is not a harness, it is a single throw of the dice.

Full context: Harness engineering: the discipline forming around agent operations →

Five things: the contract (what is being built and what counts as done, as checkable criteria), the current state (what is done, in progress, or untouched), the decisions already made with their reasons, the dead ends already tried, and the single open question the next agent should resolve. Notably not the full transcript, which is mostly noise the receiver has to re-filter.

Full context: Handoffs: passing work between agents without losing the plot →

Because a transcript is a replay of events, not a summary of state. It contains every dead end and correction with no signal about what still matters, so the receiving agent either re-explores rejected paths or mistakes an abandoned approach for the plan. It also burns context budget you need for the real work. A distilled handoff transfers understanding; a raw transcript transfers noise.

Full context: Handoffs: passing work between agents without losing the plot →

They are the same problem in three directions. A handoff passes state sideways between agents, recovery passes it forward in time to resume a dead run, and memory persists it so it survives when no one is actively passing it. All three depend on the state that matters living outside the session in a form the next reader can act on.

Full context: Handoffs: passing work between agents without losing the plot →

Because the context window is a fixed size, and when it fills the session compacts by summarizing older turns. Summarization is lossy and biased toward keeping recent detail, so an early one-line constraint you never repeated is exactly the kind of thing that gets erased, while recent implementation chatter survives. The agent then keeps working without the instruction, unaware it is gone.

Full context: Compaction eats your decisions: managing the context window on long work →

It raises the ceiling but does not change the mechanism. A larger window still fills on long work, and compaction still erodes the early anchoring decisions first. More tokens also is not the same as more understanding, past a point extra context degrades the agent's focus. The durable fix is to keep must-survive constraints outside the window and re-supply them, not to rely on a bigger warehouse.

Full context: Compaction eats your decisions: managing the context window on long work →

Keep them out of the transcript. Store constraints and acceptance criteria in an artifact the window does not own, re-state the live ones at each episode boundary, checkpoint before you hit the ceiling, and load only the files a step actually needs instead of flooding the window. The window should hold the working set; the source of truth lives outside it.

Full context: Compaction eats your decisions: managing the context window on long work →

Because "done" means different things to each of you. To the agent, done means it produced code that looks like it satisfies the request. To you, it means the behavior changed, nothing else broke, and there is proof of both. The agent clears its own bar in good faith and reports success, leaving you to cover the distance between "looks finished" and "is finished."

Full context: Done means done: making agents prove completion →

Take away its role as judge of its own work. Define, before the work starts, what would demonstrate completion: what command run against the result, printing what output, against which contract. Then have something other than the agent run that check and capture the result. The agent can still write "done," but it no longer gets to decide whether that sentence is true.

Full context: Done means done: making agents prove completion →

Three things captured together: a command that actually ran, with its exit code; the real output it printed, not a summary like "looks good"; and the version of the acceptance contract it ran against. A checkbox is a claim wearing the costume of proof. A demonstration carries information about whether anything actually happened.

Full context: Done means done: making agents prove completion →

Past the first few tasks, it speeds it up. The expensive work is not producing proof, it is not having it: re-reading diffs, re-running tests by hand because you don't trust the last green, catching breakage in production a captured run would have caught. When each "done" carries its demonstration, you trust the report and spend attention only on the few that fail.

Full context: Done means done: making agents prove completion →

A language model generates the most probable continuation of its context. After an implementation that looks finished, the probable next sentence is a report of success, because that is how nearly every transcript it has seen ends. The claim is generated from the shape of the situation, not observed from a real run. Unless the harness actually executed the suite and fed the result back, there is no execution for the model to consult.

Full context: "Tests pass": anatomy of a false success claim →

No. Lying requires knowing the truth and stating the opposite. The model has no internal record of test runs it is choosing to misrepresent, only a next-token prediction that lands on "success" because success is how these stories usually end. Calling it stupid is worse, because the same mechanism writes excellent code the rest of the time. It is one behavior, producing probable text, with no built-in link to a real event.

Full context: "Tests pass": anatomy of a false success claim →

You cannot prompt it away, because the model has no reliable way to introspect whether it ran anything. The fix lives outside the model: the party that does the work should not certify the work. Have the harness invoke the tests, capture the real output and exit code, and use that to decide completion. The agent can still write "tests pass," it just no longer decides whether that is true.

Full context: "Tests pass": anatomy of a false success claim →

No, the opposite. The more capable the model, the more plausible its prose, and plausibility is exactly the property that gets a false claim past a tired reviewer. A false success reads identically to a true report because mechanically they are produced the same way. The problem does not shrink as models improve, it grows, which is why the durable answer is a real run, not a better prompt.

Full context: "Tests pass": anatomy of a false success claim →

Because the intent does not travel with it. A teammate's pull request comes with shared context: the standup, the ticket, a commit message carrying a person's reasoning, an author you can ask. Agent code arrives stripped of all that, so you have to reconstruct from the diff alone both what it was meant to do and whether it does it. Multiply that heavier per-diff cost by agent throughput and fatigue is the guaranteed steady state.

Full context: Review fatigue: when code arrives faster than you can read it →

You cannot, by reading faster or harder, because your reading capacity is fixed and the agent's output is not. Read differently instead: spend your fixed attention where it buys the most certainty per minute. Approve scope before the agent builds, read the diff against that scope, then confirm the evidence of what ran. Three bounded checkpoints replace one unbounded reading task.

Full context: Review fatigue: when code arrives faster than you can read it →

Not equally. Reading a one-line copy fix with the same intensity as a change to the authentication path means over-reading the trivial one and under-reading the dangerous one. Sort by blast radius: changes touching money, auth, data deletion, or shared interfaces earn a slow line-by-line read every time. An isolated leaf with tests around it can often be trusted at the scope-and-evidence level.

Full context: Review fatigue: when code arrives faster than you can read it →

Two things. The scope has to exist as something you actually approved up front, not something reconstructed after the fact. And the evidence has to be captured automatically as a byproduct of the work, or you are back to re-running things by hand and the fatigue returns through the side door. When completion already requires a demonstration, the evidence is waiting at the final checkpoint.

Full context: Review fatigue: when code arrives faster than you can read it →

Assurance is the work of knowing that produced code is correct, safe, and coherent with everything around it, and being able to show how you know. It is the larger question that testing serves: can this output be trusted, including whether the tests ran at all. Agents made producing code cheap. Assurance costs what it always did, so it became the constraint on how much finished software actually ships.

Full context: From production to assurance: the new bottleneck in software →

When one station on a line speeds up enormously and the next does not, the constraint moves to the slower station. Agents turn a description into a working implementation in minutes, across parallel sessions. Deciding whether to trust that implementation still takes a human the same careful hour. Production collapsed in cost, assurance did not, so the scarce resource is no longer generating code but establishing that the generated code can be trusted.

Full context: From production to assurance: the new bottleneck in software →

No. Tests are a tool inside assurance, not the whole of it. Assurance is the discipline of turning claims into evidence at the rate the claims arrive: whether a green build proves the feature is correct, whether completion cost a real demonstration, whether the tests ran at all, and whether the proof survives past the terminal it printed in. Testing is one instrument; assurance is the station.

Full context: From production to assurance: the new bottleneck in software →

Stop estimating build time and start estimating trust time. "How long to write this" is nearly free to answer now and nearly useless. A change an agent writes in five minutes but that touches a payment path is not a five-minute change, it is however long assurance takes. Planning around build time commits you to a velocity you cannot sustain, because the unverified work just queues in front of the one human who can trust it.

Full context: From production to assurance: the new bottleneck in software →

It is the discipline of closing every unit of work with its proof attached: what ran, what it produced, and against which version of the contract, stored where the next person and the next agent can find it. It exists because most workflows keep the diff and throw away the proof, the green scrolls out of the terminal and vanishes. When the author is often a model nobody watched line by line, captured evidence is the only durable account of whether the work works.

Full context: Evidence-based development: closing work with proof attached →

Status is a completed checkbox, a merged pull request, a green badge. It tells you a state was declared and carries almost no information about whether the underlying thing is true, because it is trivially easy to set without the thing being true. Evidence is what actually happened, recorded: the command that ran, its real output, the contract version. You can reconstruct the truth from evidence; from a checkbox you can only reconstruct that someone checked it.

Full context: Evidence-based development: closing work with proof attached →

Three things, plus a place to keep them. The actual commands and invocations, not a summary. The output and exit codes as they came out, not compressed into "looks good." And the acceptance criteria at the revision they were at, so a green cannot silently drift to yesterday's requirements. Then attach it to the change so it travels with it. Proof you cannot retrieve is indistinguishable from proof you never had.

Full context: Evidence-based development: closing work with proof attached →

It goes stale visibly, which is the point. A checkbox that goes obsolete stays checked and announces nothing. Evidence that names the contract version it ran against becomes self-evidently questionable the moment the contract moves, so the system can flag it: this proof refers to requirements that have since changed, re-verify. Staleness you can detect is a solved problem, you re-run and re-capture. Staleness you cannot detect is how a codebase fills with greens referring to a world that no longer exists.

Full context: Evidence-based development: closing work with proof attached →

One thing changes: the intent was never in anyone's head. When you write code, the intent lives in your mind and the test is a second, independent expression of it. With generated code that second witness is missing, so if you write tests after reading the implementation, they encode what the code does instead of what it was supposed to do. Almost everything else about testing stays exactly the same.

Full context: Testing AI-generated code: what changes and what doesn't →

Because you wrote them after reading the code, so they describe the implementation rather than the requirement. The code says X, the test asserts X, they agree, green. You have proven the code does what the code does and nothing about what you wanted. The fix is to write assertions from the specification, not the diff, so the test is defending a behavior that exists outside the code it checks.

Full context: Testing AI-generated code: what changes and what doesn't →

Not in the same step from the same context. If the model misunderstood the requirement, it misunderstands it consistently, and the tests encode that misunderstanding as the expected result. The green is real, the correctness is not. Separate them: specify the behavior yourself and pin it before the implementation exists, then generate against it. Keep at least one test the agent never saw. The exam has to predate the answer.

Full context: Testing AI-generated code: what changes and what doesn't →

No. Coverage tells you a line executed, not that an assertion would have caught it breaking. You can run every line of a generated module and assert almost nothing while the number looks great, and agents are very good at producing tests that raise coverage and check nothing real. Treat coverage as a floor with teeth, a gate nobody can drop below, not a trophy on a dashboard. If tests that assert nothing satisfy the gate, the gate is decoration.

Full context: Testing AI-generated code: what changes and what doesn't →

It is a four-part mechanism that takes the "did it succeed" decision away from the agent: a trigger fires a check automatically, a check the agent cannot edit produces a verdict from its exit code, a gate acts on that verdict by blocking or passing the work, and a return path feeds real failures back for a fix. It repeats until the check passes or a limit calls in a human. "Tests pass" becomes something the agent has to make true, not something it says.

Full context: Verification loops: hooks, gates and the end of self-reported success →

Because that leaves the agent as the last thing between the check and your decision, so it can still summarize a failure as "mostly passing, one minor issue, done." That is self-reported success with an extra step, not a loop. The loop only works when the gate acts on the raw verdict directly: the exit code blocks the merge and the unedited failure output re-enters the context. The moment anyone paraphrases the verdict before it takes effect, the gap reopens.

Full context: Verification loops: hooks, gates and the end of self-reported success →

A hook runs your command automatically on an event, with no cooperation required from the model. Use several layers: a harness hook that fires when the agent finishes a turn or writes a file (tightest, so it self-corrects in-session), a pre-commit or pre-push hook before the change enters history, and integration CI that re-runs on every push independent of anyone's local setup. Same checks at three distances from the keyboard.

Full context: Verification loops: hooks, gates and the end of self-reported success →

Something the agent did not author. "It compiles" clears while shipping the wrong behavior, and "tests pass" is only as strong as the tests, which are worthless if the agent wrote them alongside the code. Check against acceptance criteria written before generation, a test suite the implementation never saw, a security scan with your rules, or a build that must produce a running artifact. The rule that separates a real gate from theatre: it has to be able to fail. If you cannot describe the input that turns it red, it verifies nothing.

Full context: Verification loops: hooks, gates and the end of self-reported success →

It is the distance between code existing and code you are willing to put your name on. When you wrote code slowly by hand, you trusted it as a byproduct of building it. Agents removed the slow writing, and the trust no longer comes free. It stands there unpaid for, and it turns out to be the expensive part: the code arrives in seconds, believing it takes the rest of the afternoon.

Full context: The trust gap: why output stopped being the bottleneck →

Because generation got faster while verification did not. You can produce ten implementations of a feature before lunch, but you cannot trust ten before lunch. The bottleneck did not vanish when production got cheap, it moved to the next scarcest thing, which is trust. The time relocated from writing to verifying, and verifying is harder, because now you are vouching for code you did not write and do not fully understand.

Full context: The trust gap: why output stopped being the bottleneck →

Stop trying to earn trust subjectively by reading the diff harder, because that only manufactures a feeling a fluent agent is good at producing. Trust the process instead: a specification of correct written before the code, a check the agent cannot edit that passes or fails on its own, and a recorded run with real output. That chain of evidence is inspectable and it scales, because verifying a claim against fixed evidence is fast.

Full context: The trust gap: why output stopped being the bottleneck →

At the seams, where new code meets old, where an assumption here contradicts an invariant there. A model writes each piece to be locally correct, which is exactly what it is good at, so the diff looks clean while the incoherence hides in what the change was supposed to respect. Reading the changed file tells you least here. Trust at the boundaries comes from integration tests and contracts that span the seams, not from staring harder at one file.

Full context: The trust gap: why output stopped being the bottleneck →

In the opposite order to a colleague's pull request: widest question first. Confirm scope, whether this is even the right change in the right places. Then blast radius, what existing behavior it could have altered, checked by tests rather than by eye. Then, and only then, read the lines, and only the ones that carry risk. Each stage can stop the review, and the cheap early stages catch the expensive errors line-reading never finds.

Full context: Reviewing code you didn't write: scope first, diff last →

Because the assumptions that make diff-first reading work are gone. A teammate was in the standup, respects the architecture, and mentions why they touched an unrelated module, so intent and scope are answered by shared context. An agent has none of that. It will refactor a file you never mentioned and not tell you. The questions you skip with a human, "is this the right change" and "what did it touch," are wide open, and the diff answers them last and worst.

Full context: Reviewing code you didn't write: scope first, diff last →

Scope, in about thirty seconds. What was this supposed to do, and does the shape of the change match? Which files should a correct version touch, roughly how big should it be, has it sprawled into unrelated places? This catches errors of the whole, an agent that rewrote an existing feature instead of adding one, a diff touching auth when the task was export formatting. If scope is wrong, stop and send it back. Reviewing the quality of a change that shouldn't exist is pure wasted attention.

Full context: Reviewing code you didn't write: scope first, diff last →

No. Reading all four hundred lines with equal attention is not diligence, it is how you exhaust yourself into missing the ten that matter. Spend attention where a defect is both likely and costly: boundary code, the security-relevant surface, input handling, auth, anything touching data that leaves the machine, and the parts the specification actually cared about. Skim the boilerplate the tests already cover, and pour your reading into where locally plausible and actually correct come apart.

Full context: Reviewing code you didn't write: scope first, diff last →

It describes code where each individual change is right on its own terms but the system as a whole stops making sense. Every function does what it was asked to do, yet the pieces contradict each other's assumptions, duplicate concepts, and drift from the architecture. The model optimized the next step, which is exactly what it was handed, so it produced a locally correct step with no view of the whole it belongs to.

Full context: Locally correct, globally incoherent: the real problem with AI-generated code →

Because the rest of the system almost never travels inside its context. Every session starts blank. The decisions you made yesterday, why a layer exists, what invariant a module protects, live in your head, not in the material the model sees when it touches the code again. You ask for a local step without the blueprint of the building, and you get a locally correct step. It is literally what you asked for.

Full context: Locally correct, globally incoherent: the real problem with AI-generated code →

No, because the incoherence is not inside the model. Coherence was never a property of intelligence, brilliant, incoherent people exist. It is a property of process. You get a coherent system by making the architecture, the specification, and the definition of correct travel with every change and verifying each step against them. More parameters do not supply the missing layer between your intentions and the model's context.

Full context: Locally correct, globally incoherent: the real problem with AI-generated code →

Coherence is imposed, not invoked. Make the architectural decision, the spec, and the definition of "correct" first-class artifacts that travel with each change, and gate every change against them so nothing reaches "done" without proving it. This is the move from spec-driven to spec-gated: the specification is not a document rotting in the repo, it is the gate that decides. Scaffolding, not talent, is what makes even a junior or an agent produce coherence.

Full context: Locally correct, globally incoherent: the real problem with AI-generated code →

When a human said "done," they were vouching that they had run the thing, understood the change, and would own the bug if they were wrong. That assurance lived in the person's judgment and stakes, not on the checklist. An agent emits "done" as the most probable word after a task-shaped interaction. It stakes nothing and arrives with total confidence whether the feature works or not, so every process built on trusting the word is now trusting nothing.

Full context: A definition of done that survives AI speed →

Take each line of your old definition and ask: what is the evidence, and who produced it? If the answer is "the agent says so," rewrite it. Not "tests pass" but "the suite ran and its output is attached." Not "meets requirements" but "checked against acceptance criteria that existed before the code." Not "reviewed" but "blast radius verified mechanically, scope confirmed by a human." Replace the agent's word with an artifact and name the process that made it.

Full context: A definition of done that survives AI speed →

A status is a label, "complete," "passing," "ready," that an agent can produce instantly, and it looks identical on both sides of the boundary between working and broken. Evidence is an artifact you can inspect that would look different if the work were not actually done: a test process that exited zero with its output saved, a build that produced a running binary. You cannot generate evidence by being confident. It exists because something real happened, or it does not exist.

Full context: A definition of done that survives AI speed →

Yes, or it does not get collected. When one person ships a week of code in a day, "we'll gather the evidence at release" means nobody reconstructs proof for forty merged changes after the fact. Done means the proof is attached at the moment of completion, per change, by the process that does the work. A definition that needs a human to assemble evidence later assumes a slow, staffed loop that no longer exists.

Full context: A definition of done that survives AI speed →

No. AI lowered the cost of building, which moved the bottleneck from building to deciding what to build and with what evidence. The product manager's judgment matters more, not less. It shifts from writing requirements to designing the decision loop: what to explore, what to validate, and what evidence has to back a call before agents turn it into shipped code.

Full context: Product management in the AI era: building got cheap, deciding got expensive →

Deciding and learning. When agents build in hours, the advantage is no longer producing features faster, it is deciding better what to build and validating it before you accumulate product debt. Cheap building lets you generate more screens, more epics, more experiments, and more debt. If the decision system does not improve at the same rate, all that speed just accelerates the dispersion.

Full context: Product management in the AI era: building got cheap, deciding got expensive →

Evals define what a good product behavior is, which failures are unacceptable, and what evidence supports a recommendation. They act like living PRDs: instead of describing a feature once, they continuously check whether the product behaves as promised. Every recommendation becomes checkable, did it keep provenance straight, separate evidence from hypothesis, and propose a concrete next validation.

Full context: Product management in the AI era: building got cheap, deciding got expensive →

No. Claude Code is excellent for ad-hoc repo diagnosis: read raw code with precision, surface sprawl and debt, answer a sharp local question. Its limit is continuity, the context rebuilds every chat. Compass is the layer that persists: provenance, history, a product graph and product evals, so a team does not re-analyze its product from scratch every time.

Full context: Product management in the AI era: building got cheap, deciding got expensive →

A product decision log is a lightweight record of the choices a team makes, captured as they happen. Each entry states the decision as a claim you could disagree with, the context that forced it, the alternatives that lost, and who owns it. It is not meeting minutes, which record what was said. A log records what was decided, close enough to the work that it stays true.

Full context: Decision logs: ending the "I never agreed to that" problem →

Four things per entry, no more. The decision itself, stated as a claim ("we ship three tiers, not usage-based billing, for launch"). The context that forced it, in a sentence or two. The alternatives that lost, named, so nobody reopens them as fresh ideas. And who owns it, so there is a person to ask. Skip the long rationale and the fifteen-field template, or the log stops getting kept.

Full context: Decision logs: ending the "I never agreed to that" problem →

Next to the work it governs, not in a wiki page nobody opens. A decision about an API contract belongs beside that contract; a decision about what a feature does and does not do belongs attached to that feature. When the record is one click from the thing it governs, people actually write decisions down and actually read them. Distance is what kills a log.

Full context: Decision logs: ending the "I never agreed to that" problem →

Minutes record what was said; a log records what was decided. Minutes are a transcript of a conversation, so they preserve the ambiguity that caused the "I never agreed to that" problem in the first place. A log resolves it into a single claim with its context and rejected alternatives, durable enough that a teammate, a new hire, or an agent can build against it without re-asking.

Full context: Decision logs: ending the "I never agreed to that" problem →

Not laziness, and not because it is too long. Nobody reads it because a PRD is finished the moment you write it and sits where the work does not live. Within a week it disagrees with the product; within a month everyone knows it is stale, so they stop trusting it. Reading a document you know is out of date is worse than not reading it.

Full context: You write PRDs nobody reads. The artifact is the problem. →

The document, less and less. The job it did, more than ever. What changes is the artifact: a static PRD is now dangerous because an agent reads its ambiguity and resolves it silently with the wrong guess, then ships fast. The requirement still has to exist, but as a small living decision wired to the code and the evidence, not a snapshot nobody keeps current.

Full context: You write PRDs nobody reads. The artifact is the problem. →

A living decision connected to the work, not a better document. Make it small and addressable, so you can revise one behavior without republishing fifty sections. Wire it to the code that satisfies it and the check that proves it, so a change on either side is visible. Keep it alive as part of the flow of work, so its current state is the current truth.

Full context: You write PRDs nobody reads. The artifact is the problem. →

A human engineer read a vague PRD, filled the gap with judgment, and came back with a question. An agent does not. It resolves the same ambiguity silently with the most probable interpretation, often not yours, and builds it fast. The vagueness a person would have flagged becomes a shipped feature that matches the words and misses the intent, with no one in the loop to catch it.

Full context: You write PRDs nobody reads. The artifact is the problem. →

For behavior, yes, and better. A prototype is not a description of the interaction, it is the interaction, so it cannot be read three ways. It pins timing, state and edge behavior, and layout, the things prose reliably fumbles. But it only replaces the part of the spec that says what the product does. The reasoning and the constraints still need a written record.

Full context: Prototype as spec: impossible to misinterpret →

Three things. It does not say why the flow works this way, only that it does, so the intent evaporates unless you record it separately. It does not capture the non-functional contract: performance under load, scale, security, failure modes. And it quietly implies a thousand incidental choices, colors, copy, ordering, that a reader cannot tell apart from the deliberate ones. It specifies everything with equal confidence.

Full context: Prototype as spec: impossible to misinterpret →

Yes, a thin one. The prototype answers "what exactly does it do," which prose does badly. A short written decision answers "why, what must hold, and which parts here are load-bearing versus incidental," which the prototype cannot answer at all. Together they are a complete spec that is hard to misread. The prototype without the intent is a decision with no memory of why.

Full context: Prototype as spec: impossible to misinterpret →

Be explicit about what it is specifying and what is just scaffolding. A prototype makes a thousand incidental choices and presents them all with the same confidence, so a reader promotes accidental defaults to requirements unless you say otherwise. Pair the running thing with a short note on which parts are load-bearing and which are placeholder, so the boundary is stated, not guessed.

Full context: Prototype as spec: impossible to misinterpret →

It can do the thinking half, not the deciding half. AI is superb at widening the option space, stress-testing an argument, reframing a problem, and structuring scattered observations. It is dangerous the moment it starts telling you what real users want, because it has never met them. Use it to expand and pressure your thinking; keep the decision, and the contact with reality, yours.

Full context: Product discovery with AI: partner for thinking, not for deciding →

No, though it will sound like it can. Ask a model what your users struggle with and it generates the most probable answer to "what do users of a thing like this struggle with," which is a different question from what your users struggle with. That gap is the whole job of discovery. The answer is a plausible hypothesis, not a finding, until a real user confirms it.

Full context: Product discovery with AI: partner for thinking, not for deciding →

Laundering is when a hypothesis a model generated gets cited later as if it were evidence a user gave you. It happens gradually: a Monday brainstorm becomes a Thursday doc becomes a build decision the next week, losing a little "we think" and gaining a little "we know" at each step. Nobody lied, but a model's guess ends up carrying the authority of research.

Full context: Product discovery with AI: partner for thinking, not for deciding →

Keep provenance ruthlessly visible. Tag every claim by source: model-generated, user-sourced, or data-sourced, and never let them look the same. Treat each model-suggested pain as a debt to validate, not a fact to build on. Never let a model summarize research into conclusions unsupervised, it smooths away the uncertainty and drops the contradicting quote. If a belief cannot say where it came from, it is not evidence yet.

Full context: Product discovery with AI: partner for thinking, not for deciding →

Before building a feature, you find the assumption it depends on that is both most likely to be wrong and most expensive to be wrong about, and you test that one cheaply, first. If the whole idea rests on a belief that turns out false, everything built on top of it was wasted. So you probe the load-bearing belief before you pour the foundation.

Full context: Test the riskiest assumption before the agents build the whole thing →

For each thing the feature quietly assumes, ask two questions: how confident am I that this is true, and how much of the idea collapses if it is false. The assumption that is both shaky and load-bearing is the one to test first. Usually it is not technical, since agents make that easy. It is a belief about whether users want it, trust it, or will pay for it.

Full context: Test the riskiest assumption before the agents build the whole thing →

No. A whole feature carries a tail of decisions, states, and polish you have to maintain, and it conflates a dozen assumptions into one messy signal, so when it fails you cannot tell which belief was wrong. Aim cheap building at the one risky belief instead: build the smallest probe that interrogates it and nothing else, and is cheap to throw away.

Full context: Test the riskiest assumption before the agents build the whole thing →

Because the cost of building used to force the thinking. When construction was expensive, you had to name the risky assumption before you could afford to build. Now an agent builds the whole feature in an afternoon, so the friction is gone and the default is to skip straight to construction, shipping something that rests on a belief you never checked. The experiments got cheaper; naming what to test is still your job.

Full context: Test the riskiest assumption before the agents build the whole thing →

AI slop in product management is the failure mode where the volume of artifacts climbs and the quality of decisions stays flat. More PRDs, more tickets, more polished decks, produced faster and read less. It is dangerous because it does not look like failure, it looks like a productive team, since the output is visible and well-formatted. The one thing that mattered, deciding better, never moved.

Full context: AI slop with a nice format: the failure mode of AI-assisted product work →

Ask one question of any document: what decision got better because this exists? If the real answer is "none, but it looks thorough," it is slop. Watch for the comprehensive PRD behind a five-minute choice nobody stress-tested, a doubled backlog of well-formed tickets, an analysis that concludes what you already believed, and insights nobody acts on. Each passes review because the artifact is genuinely well-made.

Full context: AI slop with a nice format: the failure mode of AI-assisted product work →

No. A model that turns a decision you actually made into a clean, well-structured PRD is doing useful work, compressing the packaging so your time goes to deciding. The slop appears only when the packaging runs ahead of the deciding, when the artifact exists and the decision behind it does not. The test is direction: is the document downstream of a choice you sweated, or standing in for one you never made?

Full context: AI slop with a nice format: the failure mode of AI-assisted product work →

Older productivity tools still made you do the thinking to produce the artifact; a better doc editor did not write the PRD's argument, you did. AI produces the whole artifact, argument and all, from a thin prompt, so it exists without the thinking that used to be its only reason to exist. Production of decision-shaped documents got nearly free while the decisions inside got no better, so the ratio of packaging to substance exploded.

Full context: AI slop with a nice format: the failure mode of AI-assisted product work →

It is the reasoning behind every feature: you learn something real about a user or market (insight), that learning forces a choice (decision), and what you ship moves a number or it does not (outcome). Product work is keeping the three tied together so the next decision is smarter than the last. When the chain stays intact, "why does this exist" has an answer.

Full context: Insight → decision → outcome: the chain AI speed keeps breaking →

Because friction used to preserve it for free. When turning a decision into code took weeks, the reasoning got written down to survive a planning meeting and the outcome got checked before the next thing shipped. Now an agent builds in an afternoon, so the decision never needs defending, the spec stops being a checkpoint, and you move on before naming what would prove it worked. Each link snaps.

Full context: Insight → decision → outcome: the chain AI speed keeps breaking →

Produce the paper trail on purpose, as a property of the work. Attach the insight to the decision, so what you learned travels with the choice. Attach the decision to the artifact, so code points back to what authorized it. Attach the artifact to the outcome: name the number to move before you ship, then record "we decided X, expecting Y, and got Z."

Full context: Insight → decision → outcome: the chain AI speed keeps breaking →

A feature you cannot connect to an insight or an outcome. One with no traceable insight was built because you could, not because you knew something. One with no measured outcome is a bet you never settled. Both are product debt, and both compound, because a codebase full of orphans is one where the next team cannot tell which parts are load-bearing and which were guesses.

Full context: Insight → decision → outcome: the chain AI speed keeps breaking →

John Cutler coined the term feature factory.

Full context: What is a feature factory? →

No. Sometimes productizing is the right call: reaching parity, keeping a customer, buying time. The problem is doing it on autopilot, without knowing it.

Full context: What is a feature factory? →

AI makes generating features nearly free, which accelerates the feature factory unless intent and verification sit upstream. The discipline that counters it is the same idea applied one level down: a green build is not a correct feature.

Full context: What is a feature factory? →

Making product means installing a new behavior: tomorrow the user does something different because your product makes it easier or more inevitable. Productizing is adding surface with nothing underneath, an integration because a competitor has it, a view because someone asked, each with its own logic and no target behavior behind it. One creates accumulated advantage; the other creates attention debt.

Full context: Making product means installing a behavior, not running a feature factory →

It means the user reorganizes part of their work or life around your product and would not abandon it even if leaving were free. Bloomberg is the example: a trader builds their whole day around the terminal, and its chat connects hundreds of thousands of professionals, so leaving is switching professional lives, not tools. If nobody changes what they do, you made software, not product.

Full context: Making product means installing a behavior, not running a feature factory →

Complete one sentence before writing any spec: "Thanks to this, [type of user] will go from doing [X] to doing [Y], and we'll know it when we see [metric Z]." If you can fill it in, you have a product idea with a target behavior and a signal. If you cannot, you have a feature idea, surface with no behavior behind it.

Full context: Making product means installing a behavior, not running a feature factory →

Because AI does two things at once: it makes any feature cheap to copy and any switching cost cheap to cross. When both collapse, you find out whether you installed a genuine behavior the user would keep even if leaving were free, or whether you were living off friction and subscription inertia. The only thing that survives both is having genuinely changed what someone does.

Full context: Making product means installing a behavior, not running a feature factory →

It is the product version of "done means done": a decision does not close until the evidence that justified it travels with it. "We chose X" on its own is a rumor with a timestamp, you know a choice was made and roughly when, but not on what basis, so you cannot later tell a good call that aged badly from a bad one that got lucky. The evidence and the decision move together or the decision is just a sentence.

Full context: Product decisions with evidence attached →

Three things that travel with it when it closes. The evidence that supported it, the actual user signal or usage data, recorded as a hunch if that is what it was. The assumption it rests on, the load-bearing belief that, if false, makes the decision wrong. And the disconfirming test, what would tell you it was wrong and when you will look. Without the third, you have made the decision quietly unfalsifiable.

Full context: Product decisions with evidence attached →

Pick a decision from a quarter ago and try to audit it cold, without asking anyone. If you can see what was known, what was assumed, and what would have proven it wrong, it was closed with its evidence attached. If you can only see that a choice was made, you have a timestamp and a rumor. Run it on ten decisions; the ratio tells you how much of your reasoning is still auditable.

Full context: Product decisions with evidence attached →

It is naming, in advance, what would tell you the decision was wrong and when you will look. A decision with no disconfirming test is one you have quietly made unfalsifiable: you will defend it forever regardless of what happens, because you never said what failure would look like. Naming it turns a decision from an opinion you protect into a bet you can settle.

Full context: Product decisions with evidence attached →

Because it is a translation. The PM has a rich model of the problem and serializes it into a ticket; the engineer deserializes the ticket back into a mental model to build from. Everything that did not fit the paragraph, the assumption being tested, the rejected alternatives, the constraints, drops at the seam. The two work in separate content worlds joined only by a ticket number and institutional memory in two heads.

Full context: The PM–engineering bridge: one system from discovery to merged code →

A handoff assumes two worlds and tries to move things between them cleanly, so meaning gets compressed each way. A bridge means the discovery artifact, the decision, the spec, and the merged code are nodes in one graph with shared identity, so the connection between them is a fact the system holds, not a memory two people maintain. Handoffs leak; a bridge does not.

Full context: The PM–engineering bridge: one system from discovery to merged code →

The translation loss did not disappear, it accelerated. When an agent turns a compressed ticket into merged code in an afternoon, the code arrives faster than anyone can catch what got dropped in translation. The seam that was always leaky now leaks at agent speed, and more code arrives carrying less of its why. The connection that slowness used to preserve breaks, so it has to become a system property.

Full context: The PM–engineering bridge: one system from discovery to merged code →

You need provenance in both directions, which most tools do not give you. A repo tells you what the code does and nothing about why; a discovery tool tells you what you wanted and nothing about whether it shipped. A bridge links the discovery insight, the decision, the spec, and the commit through shared identity, so you can start at merged code and land on the reason it exists, as a traversal, not a memory.

Full context: The PM–engineering bridge: one system from discovery to merged code →

It can synthesize research you actually gathered, not replace the gathering. A model reads forty interviews and hands back six clean themes in a minute, and that is a real gain because the bottleneck in synthesis was the hours of reading, not the insight. What it cannot do is originate a fact about your users that no user supplied. That fact does not exist in anything it read, so it can only produce a well-formed guess.

Full context: AI-assisted user research without laundering your evidence →

Synthesis compresses evidence that existed before the model touched it: real people, real transcripts, patterns made legible. Substitution manufactures evidence that was never gathered: a simulated persona answering questions no human answered. They are different in kind, not two points on a spectrum. One amplifies evidence, the other fabricates it, and every serious failure of AI-assisted research is doing the second while calling it the first.

Full context: AI-assisted user research without laundering your evidence →

It is the process by which a model's guess loses its source and acquires the credibility of a finding as it moves through your documents. A model extrapolates beyond eight real interviews, the deck formats invented claims identically to real ones, a bullet moves into a strategy doc without its source, and a week later it is a decision. Nobody lied, but a guess now carries the authority of eight humans.

Full context: AI-assisted user research without laundering your evidence →

Not as evidence. A persona answering questions no human answered is the model's prior about users dressed as data, and it belongs in the hypothesis column with a note to go find out, not in the evidence column driving a decision. The rule is one sentence: every claim points at an utterance. If you can name the real person who said it, it is research; if the only source is the model, it is opinion.

Full context: AI-assisted user research without laundering your evidence →

It is three things: who does what (roles), what the work produces (artifacts), and how the team moves through time (rhythm). The traditional version, PM writes requirements, engineer writes code, work batched into sprints, was designed for a world where writing code was the slow, expensive step. When agents take over construction, all three have to change, because the assumption they were built on is gone.

Full context: An operating model for product teams that build with agents →

Typing stops being the scarce resource, so both human roles move up a level. The product person stops authoring requirements and owns the contract and the decision loop, keeping "correct" legible and current while agents build against it. The engineer stops producing code and owns the harness and the gate, the environment agents run in and the checks a change must pass. Neither role got smaller; both stopped being measured by output.

Full context: An operating model for product teams that build with agents →

Three living artifacts and a tighter rhythm. The spec, a contract the agent itself can read, replaces the PRD. The decision ledger, a memory of what was decided and why, replaces the roadmap's fixed sequence. The evidence record, proof of what ran and passed, replaces the status report. And the sprint gives way to a tight loop, discovery to spec to agent build to verification, run in hours and in parallel.

Full context: An operating model for product teams that build with agents →

Because most teams upgrade the tools and leave the operating model untouched: they buy agents but keep the PRD, the roadmap, the sprint, and measure people by output. What they get is the old model running faster, so its weaknesses compound faster too, more unread PRDs, more roadmap fiction, more unverified output. Fast flow only produces good outcomes when it runs through strong verification; without it, speed just accelerates the damage.

Full context: An operating model for product teams that build with agents →

A call graph is part of it. A call graph captures which function calls which, and that is one of the most useful relation types. A full code knowledge graph carries more: types, data flow, tests, configs, endpoints, and the links out to product artifacts and decisions. The call graph tells you the code's control structure. The knowledge graph adds why the code exists and what it is supposed to satisfy.

Full context: Code knowledge graphs: what they are and why agents need them →

Probably not yet. A small codebase fits in a head and often in a context window, and the map is cheap to rebuild by reading. The graph earns its keep when the code outgrows what one person can hold, when several agents work in parallel across it, or when the people who carried the map in their heads leave. That is also, not coincidentally, exactly when agents start breaking things they never saw.

Full context: Code knowledge graphs: what they are and why agents need them →

Yes, and you should, because a hand-maintained one rots. The graph should be built by reading the source, the call structure, and the tests, so it stays a projection of the real system. The parts that cannot be read off the code, chiefly the provenance link from code to the decision that asked for it, are the parts worth attaching deliberately as work completes, so the why is captured while it is still known. ↓ Download PaellaDoc · macOS What breaks in your codebase that a search would never have warned you about? Tell me on the forum.

Full context: Code knowledge graphs: what they are and why agents need them →

A representation of the product you built as a system: zones, relations, provenance, distance to the core, and validation, not just a list of features or a PRD-to-acceptance-criteria hierarchy. Its value is topology, the shape of what exists.

Full context: Product knowledge graph: read your product's shape, not the repo's feature list →

The real center of the built product, the expensive peripheries, the bridge capabilities between zones, what is infrastructure versus user value, where effort concentrates, and where there is heavy construction with little validation. It cannot prove that users love a feature, that a zone makes revenue, or that the market wants it.

Full context: Product knowledge graph: read your product's shape, not the repo's feature list →

Not at reading code. Claude Code is excellent for fast, ad-hoc repo diagnosis. Compass is for continuity: a persistent product map with provenance, topology and validation debt, so product questions do not start from zero each time. The strongest setup uses Compass for the map and Claude Code for concrete audits.

Full context: Product knowledge graph: read your product's shape, not the repo's feature list →

No. A graph read from the built product shows what the product suggests, not the team's original intent, not user validation, and not market demand. It must mark what is built, what is inferred, and what is actually proven, and keep them apart.

Full context: Product knowledge graph: read your product's shape, not the repo's feature list →

Usually because it lacks a map of the code's structure, not because your prompt is too short. It greps, reads a few files, and infers the relations that matter, and it misses the non-obvious ones, like a caller in another package. The failure is structural, and no amount of better wording closes a structural gap.

Full context: Codebase maps, not bigger prompts →

Not good documentation. It's the structure read off the code: the call graph (what calls what), the dependency graph, type and data flow, module boundaries, entry points, and reachability. Because it's a projection of the source, it regenerates when the code changes instead of going stale like a hand-written architecture doc.

Full context: Codebase maps, not bigger prompts →

Prose doesn't compose. Every sentence is more to read, more to potentially contradict, and structure the model has to re-derive on every run, and you inevitably skip the edges that feel obvious. A map hands the structure over as queryable facts, so a thousand edges cost almost nothing until the agent queries the ten it needs.

Full context: Codebase maps, not bigger prompts →

It handles more of it and still starts every session from zero, rebuilding the relations from pasted text each run. The relations that break you are the non-obvious ones a from-scratch read is most likely to miss. Hand the model the map and it spends its capability on the task instead of re-deriving the terrain.

Full context: Codebase maps, not bigger prompts →

Because every session they arrive like a first-day engineer with no memory and, unlike a human, no one to ask. So they grep, read a few files, and infer. Most of what people blame on the model is an onboarding failure: the agent was dropped into a system whose map lives in heads it can't read.

Full context: Onboard against the graph, not tribal knowledge →

Instead of transferring the system's map from senior heads one question at a time, both new engineers and new agents query a code knowledge graph built from the actual source. "What calls this" and "what breaks if I change it" get answered on demand, correctly, without interrupting anyone, from a map that doesn't misremember.

Full context: Onboard against the graph, not tribal knowledge →

No. It covers the structural half of onboarding, which is most of week one: what exists, what calls what, what breaks if you touch this. It's weaker at the why that never made it into an artifact, the political history and deadline-forced calls. Reserve the senior's scarce attention for that, not the hundred structural questions.

Full context: Onboard against the graph, not tribal knowledge →

Give them something to onboard against that isn't tribal knowledge. Build the graph from the repo, keep it downstream of the code so it stays true, and have agents query it before they act. A map maintained by hand is just tribal knowledge with extra steps; it goes stale and lies with official-looking authority.

Full context: Onboard against the graph, not tribal knowledge →

For a structural reason, not laziness. A traditional doc is a second copy of the truth, kept in a different place from the code and tied to it by exactly one thing: a human remembering to update it. That link is manual, nobody's explicit job, and fails silently, so the doc quietly becomes less true while still looking authoritative.

Full context: Living documentation: docs that stop rotting →

Documentation with the human taken out of the update path. Instead of writing docs beside the system, you derive them from it, so an API description generated from the real routes changes when a route changes, and an architecture view read off the code graph shows a new service the moment it exists. There's no second copy to fall out of sync.

Full context: Living documentation: docs that stop rotting →

No, docs-as-code is a half-measure. Putting markdown in the repo, reviewed in pull requests, moves the second copy closer to the code and improves the odds a human notices drift. But the copy and the human are still there. Living documentation is the step past it: for anything that can be read off the code, delete the copy and render a view.

Full context: Living documentation: docs that stop rotting →

The why. The what and the how, routes, call structure, dependencies, shape, can be read off the code. The reason a decision was made isn't visible in the code that resulted from it, so it has to be captured deliberately as the decision is made and attached to the code it governs. Derive everything else; spend your attention on the why.

Full context: Living documentation: docs that stop rotting →

Because a folder of notes has no way to know the product changed. You write the PRD on Monday; by Friday the team shipped three changes, two contradicting it, and nobody updated the doc because that's nobody's job. The AI then answers with confidence about a product that no longer exists. The problem was never the file.

Full context: The product brain that maintains itself →

A folder is a pile that doesn't know what relates to what, so it can't tell you which stories a changed decision just invalidated. Store product context as a graph and every artifact is a node with typed relations, so you can change one decision and see every downstream story and criterion it touches.

Full context: The product brain that maintains itself →

Verification against the criterion that defined the work, not a click on "done." A task marked done is an opinion: the build went green, the card moved, none of which means the code does what the story asked. Update on every click and the brain fills with confident lies faster than you can catch them.

Full context: The product brain that maintains itself →

Tie the code to the decision that asked for it, with durable typed links, and let completion mean producing the evidence a criterion demanded, not asserting it. Then the brain changes when the work changes, because the link between them is the same fact. Keeping it true stops being a chore and becomes a property of how work gets done.

Full context: The product brain that maintains itself →

The layer above the code that a team forgets: the decisions that were made, the reasons behind them, and the dead ends you tried and abandoned. The code survives because everyone's forced to keep it. That layer doesn't, unless something is responsible for holding it, and in most setups nothing is.

Full context: Product memory: what your team forgets and your system shouldn't →

Because the reason a question was settled lives in someone's head, and that person left in the spring or remembers it differently now. Without a record linked to the code it governs, a decision leaves no trace, so it looks arbitrary and gets quietly reversed by people who never knew it was a decision.

Full context: Product memory: what your team forgets and your system shouldn't →

Because an agent has no memory beyond what you hand it, and the deleted branch that proved the approach fails is exactly what your workflow tidied away. It sees a problem the abandoned approach would elegantly solve and builds it, confidently walking back down the dead end, because reasonable-given-no-memory is the failure.

Full context: Product memory: what your team forgets and your system shouldn't →

Attached to the thing it explains, not floating in a doc. A decision linked to the exact code it governs is memory you can use; the same decision in a wiki is trivia nobody finds. When the reason for a retry cap sits on the retry logic, a person or an agent reading that code sees it in time.

Full context: Product memory: what your team forgets and your system shouldn't →

The behaviour the code enforces (user stories), the conditions it checks (acceptance criteria, richest when there are tests), and some of the decisions frozen into structure. What you cannot fully recover is intent: why a choice was made, what was rejected, and what the code does by accident rather than on purpose.

Full context: Reading a repo into product artifacts: stories, criteria, decisions →

Because most software already exists. The forward path (spec, then build) fits greenfield. Inherited code, vibe-coded prototypes and legacy systems have no spec at all, and the fastest way to get a contract you can build against is to read the one the code is already enforcing.

Full context: Reading a repo into product artifacts: stories, criteria, decisions →

Only if each one carries its provenance. Behaviour read from a passing test is evidence. A decision inferred from a folder name is a guess. Extraction is dangerous when it launders guesses into confident documentation, so the artifacts must mark what is proven, what is observed and what is inferred, and keep them apart.

Full context: Reading a repo into product artifacts: stories, criteria, decisions →

The undocumented why that lives in people's heads: the reason a module is structured oddly, the landmine nobody touches, the constraint that is obvious to whoever built it and invisible to everyone else. It is real knowledge with no external representation, so it disappears when the person does.

Full context: Tribal knowledge is a single point of failure →

Because the whole system depends on one head being reachable. When that person is on holiday, leaves, or simply forgets, the knowledge is gone and the code is left saying what it does but not why. There is no redundancy and no backup, which is the exact definition of a single point of failure.

Full context: Tribal knowledge is a single point of failure →

Because agents onboard from zero every session and cannot absorb hallway context. A human junior slowly picks up the unwritten rules over months. An agent never does. It sees the code, not the why behind it, so any knowledge that only lives in heads is permanently invisible to the fastest-growing part of your team.

Full context: Tribal knowledge is a single point of failure →

Vector RAG retrieves by resemblance: it embeds code into vectors and returns the chunks most similar to a query. A knowledge graph retrieves by relationship: it stores explicit edges (calls, imports, depends-on, decided-by) and answers by traversing them. One is good at fuzzy recall, the other at structural, multi-hop questions.

Full context: Knowledge graph vs vector search for code: when each one wins →

When you need fuzzy recall over a large, unfamiliar codebase and the question is roughly natural language: find code that does X, where is anything about billing, show me similar handlers. Vectors are cheap to build, tolerant of messy input, and strong when you do not know the exact names to look for.

Full context: Knowledge graph vs vector search for code: when each one wins →

When the answer depends on relationships the embedding throws away: what calls this, what breaks if I change it, why does this exist, trace this decision to the code that implements it. These are exact, multi-hop, structural questions, and a graph answers them by traversal instead of guessing from similarity.

Full context: Knowledge graph vs vector search for code: when each one wins →

Treating documentation like source code: it lives in the repository, changes through pull requests, gets reviewed alongside the code it describes, and passes through CI. The point is that docs move on the same track as the code, so they change together instead of drifting apart.

Full context: Docs-as-code in the agent era →

Docs stop being only human-facing output and become machine-facing input. Files like AGENTS.md and CLAUDE.md are read by agents to decide how to build. That flips the priority: stale docs no longer just confuse a new hire, they actively steer an agent to build the wrong thing, so keeping them true becomes a build concern.

Full context: Docs-as-code in the agent era →

Yes, when agents depend on the docs. If instructions can drift from the code with nothing to catch it, they will, and an agent will trust the drifted version. Generating docs from the code where possible, and gating the build when documented facts and real facts disagree, is how you keep the contract true at machine speed.

Full context: Docs-as-code in the agent era →

A local software factory is a system that keeps product, code and evidence connected on your own machine. An idea becomes a decision, the decision a specification, the specification work an agent can execute, and the result returns with proof attached — all in one connected system instead of scattered across a chat, a tracker and a repository. Local means the through-line from intent to proof is yours to own, not rented.

Full context: The local software factory: product, code and evidence on your machine →

No, it is the opposite. A feature factory measures itself by output shipped and calls that product. A software factory is a place with stations — discover, define, plan, build, verify, learn — where material enters, gets worked in order, and leaves proven. The point is not the volume of features. It is that intent, code and evidence stay connected so the system stays coherent while agents write.

Full context: The local software factory: product, code and evidence on your machine →

No. Local refers to where your product's state lives, not where inference runs. The factory sits on your machine but calls whatever AI providers you choose, and the cloud does inference better than a laptop will. What stays local is everything that defines the product: the contract, the graph, the decisions and the proof. You send tokens out when you decide to, without handing over the factory.

Full context: The local software factory: product, code and evidence on your machine →

It matters most for a solo founder or small team building something they intend to still understand in a year, because owning the through-line beats the setup a shared cloud saves. Large teams gain real things from cloud tools: shared state with no setup, heavy compute as someone else's problem, self-updating software. The choice turns on whether owning your product's memory outweighs that convenience.

Full context: The local software factory: product, code and evidence on your machine →

Local-first AI development keeps the system around the models on your machine while the models stay remote. The orchestration, state, memory between sessions, verification and recovery run on your Mac; inference is a call you make out and a result you bring back. The split is deliberate. The expensive part that scale improves can be remote, while the parts that define your product stay local.

Full context: Local-first AI development: why the factory should live on your Mac →

Privacy becomes a property of the architecture rather than a promise. Your strategy, rejected bets and acceptance criteria live on your disk, so there is nothing on a vendor's side to look at. The precise boundary: when you call a remote model, the tokens you send go to that provider under their terms. Local-first makes that a per-call decision you take on purpose, not a default where your whole workspace syncs to a server.

Full context: Local-first AI development: why the factory should live on your Mac →

No. Local-first is not offline maximalism and does not claim your laptop should do inference. Frontier models run in datacenters for good reasons. What stays local is the contract, the graph, the decisions and the proof — the parts that define your product and that you should own. The models remain remote, called on your own keys. You refuse to rent the parts you should own, not the cloud itself.

Full context: Local-first AI development: why the factory should live on your Mac →

It is usually faster where speed matters. The agentic loop reads state, decides, acts and updates hundreds of times a day. When state is a SQLite file on your disk, each read is disk-speed instead of a network round-trip through someone's rate limits. The only thing you wait on is the model, which you were always going to wait on. Everything else is instant because everything else is local.

Full context: Local-first AI development: why the factory should live on your Mac →

Neither wins outright; it is a trade, not a verdict. The cloud is better at shared state with zero setup, offloaded compute, self-updating and access from anywhere. Local is better at latency on the tight loop, cost only where it is real, privacy by construction and control that survives the vendor. The right choice depends on which side of that trade holds the pain that actually bites you.

Full context: Cloud vs local AI dev tools: what you trade in each direction →

Four things, and they are not small. A teammate opens a URL and sees exactly what you see, with no install or version skew. Heavy compute becomes someone else's problem. The version you run is always current. And you reach the same environment from any device or network. If your central pain is coordinating a team across devices with minimal friction, that is where your answer lives.

Full context: Cloud vs local AI dev tools: what you trade in each direction →

You can, but it is a migration, not an adjustment. Your state lives in their format on their servers, so moving means an export — if offered — then rebuilding the connections their system held for you. The through-line between intent and proof is often the first thing that does not survive extraction: you get your data, not always your system. Starting local and adding cloud pieces is the reversible direction.

Full context: Cloud vs local AI dev tools: what you trade in each direction →

For a solo founder or small tight group, local is usually the stronger case. The coordination the cloud makes frictionless is coordination you barely need, while local's wins — disk-speed latency, cost only on inference, privacy and vendor-proof control — hit you directly. Cloud earns its place for large teams whose main problem is shared state. Choose by who is in the workspace and where the pain hits today.

Full context: Cloud vs local AI dev tools: what you trade in each direction →

It depends on the tool's architecture. Many sync your whole workspace to their servers as the price of being helpful. A local-first tool keeps your code, product graph, decisions and evidence on your disk, and sends out only the specific context of a specific model call, when you make it. The default is that everything stays; sending becomes the scoped exception you take on purpose, not a blanket sync.

Full context: Your code never leaves: privacy as an architecture decision →

Only the tokens of that call — the code snippet, the context and the instruction you pass — go to the provider under their terms. That is real, and local-first does not make it vanish. What changes is the shape: instead of your entire workspace living on a server, one call's context goes out when you choose. You can look at sensitive context and route that task to a local engine so nothing leaves at all.

Full context: Your code never leaves: privacy as an architecture decision →

A policy is a sentence promising a company will not misuse your data; it changes with a terms-of-service update you will not read. Architecture is an arrangement where there is nothing on their side to misuse, because the data never went there. The guarantee is structural — it does not depend on their intentions, security posture, acquisition or a subpoena. It holds on the worst day, not just the marketing day.

Full context: Your code never leaves: privacy as an architecture decision →

No, and that framing undersells it. Code is the least sensitive layer. The factory around it holds the strategy behind what you are building, the bets you killed, the security-sensitive constraints, the acceptance criteria for the sensitive parts, and discovery notes shared in confidence. That is the shape of your company's thinking, and it is exactly what a workspace-syncing tool hands over. "We don't train on your data" does not address most of it.

Full context: Your code never leaves: privacy as an architecture decision →

Usually for the vendor, not you. You do not need an account to run software on your own machine. The account creates a record they can market to, a funnel they can measure and optimize, a switching cost because your work now lives on their server, and the registered-user number the business is often managed against. None of that is evil, but the wall points where the incentives point.

Full context: Tools without accounts: what no-signup design says about a product →

Yes. No account does not mean no value capture. A tool can charge for the product directly, charge for use beyond a free tier, or charge for team features where the server genuinely adds value. What it declines to do is build its business on harvesting and retaining your identity. You pay for the software rather than becoming the thing that gets monetized — the version worth looking for.

Full context: Tools without accounts: what no-signup design says about a product →

Real things, mostly tied to the cloud. No account usually means no automatic cloud sync, so moving between devices is on you. It means no vendor backup — if your disk dies without your own copy, they have none to restore. It means less frictionless cross-device continuity, and some collaborative features are harder or absent. For a team needing multi-device collaboration that just works, that is a worse fit. The trade buys ownership, privacy and aligned incentives.

Full context: Tools without accounts: what no-signup design says about a product →

Watch where the wall sits relative to the value. Registration before the tool does anything useful is acquisition work, and you are the acquisition. Registration only when you hit something that genuinely needs an identity — sharing, syncing a second device — is function work, not capture. Then check the exit: a tool confident in being good makes leaving easy; one that buries export is making the switching cost part of the plan.

Full context: Tools without accounts: what no-signup design says about a product →

Bring your own model means you supply the API key or point the tool at a local engine, and the tool treats the model as a swappable part rather than its own core. You hold the credential; the tool is a client pointed at it. It sounds like a checkbox, but it is a decision about how the product is built — one that has to be made before the first line of code, not bolted on after.

Full context: Bring your own model: API keys, local engines and staying portable →

With a bring-your-own-model tool, yes, and the difference matters. When the key is yours, billing hits your card under your terms, the rate limits are the ones you signed up for, and the data agreement is the one you accepted. Moving to another provider becomes a settings edit on your own schedule. When the key runs through the tool, you wait for it to support the provider you want, at the price it negotiated.

Full context: Bring your own model: API keys, local engines and staying portable →

A tool built for bring-your-own can, through an engine like Ollama running an open-source model on your machine with no network. It is not a downgrade path. Local is the only mode where that promise actually holds — the requirement for regulated code, a client contract about where source lives, or a prototype you are not ready to expose. A good factory treats the local engine as first-class next to frontier APIs.

Full context: Bring your own model: API keys, local engines and staying portable →

Nothing, if the work lives outside the model. The product contract, specifications, decisions, code graph and evidence must sit in local storage you can inspect, not inside a conversation with one engine. Then you change models and the memory survives: yesterday's decisions still apply, the specs still hold, the new engine reads the same durable context. If that meaning lives inside one model, swapping it throws the work away and portability is a lie.

Full context: Bring your own model: API keys, local engines and staying portable →

Move the decision from the monthly bill to the individual task. First get visibility at the task level: what a run cost in tokens, which engine it used, how much was retries. Then cap it with a per-task budget and route cheap work to cheap engines by default. Cost stops being a surprise at the end of the month and becomes a property of how each task is dispatched, with the number in front of you while you can still act.

Full context: Controlling AI costs when every task can burn tokens →

Usually it is not the task you were watching. Agents overspend on the one that went sideways — got stuck, retried itself in a loop, and ran a frontier model in circles with no ceiling to hit. The rest hides in costs you forget to count: retries, drift that has to be redone, verification loops, and context resent every turn because the tool has no memory. None of it shows up as "waste"; it looks like normal usage.

Full context: Controlling AI costs when every task can burn tokens →

Define a few tiers — cheap, balanced, strong, frontier — instead of pricing every task by hand. Each task inherits a sensible ceiling and engine from its tier, so the manual decision happens once, at the tier. When a run blows through its cap it stops and tells you, instead of silently spending your month. The budget is as much an alarm that surfaces a confused run as it is a wallet.

Full context: Controlling AI costs when every task can burn tokens →

Yes; it is the largest, most boring source of waste. A copy edit, a rename, a comment or a small refactor the tests already cover does not need your strongest engine. Let the task's profile decide which engine picks it up, so cheap work lands on cheap engines by default. Routine work that can run on a local open-source model through Ollama costs only electricity, which is often the right answer.

Full context: Controlling AI costs when every task can burn tokens →

Yes, and the old ceiling is mostly gone: agents write the code fast, so building is no longer what limits you. What replaces it is harder to see. One person now holds every role a team splits — product, engineering, review, memory, recovery, the quality gate — because agents multiply your output without dividing your roles. You can produce like a team, but you still decide like an individual.

Full context: A factory of one: shipping serious software as a solo founder →

Attention, not throughput. Eight agents can generate more code in an afternoon than one person can carefully read in a day, and unreviewed output is risk with a nice commit message, not progress. The wall is coherence: context loss between sessions, drift between parallel branches, and review fatigue where the tenth diff gets less scrutiny than the first. Judgment does not parallelize, and there is a finite amount of it per day.

Full context: A factory of one: shipping serious software as a solo founder →

A factory of one is a single person operating like a team by running several agent sessions at once, each on its own branch, while holding the schedule, decisions and quality gate alone. It works when the coordinating memory — the product contract, decisions, code graph and evidence — lives outside your head in one connected system. Otherwise you become the single point of failure in your own company, the CPU being one tired head.

Full context: A factory of one: shipping serious software as a solo founder →

They replace the throughput, not the judgment. Agents cannot decide what is worth building, whether what came back is good, or when to throw away a week because the idea underneath was wrong. Those stay with you. What a solo founder actually needs is not more agents but a place for a team's memory to live, so parallel work does not depend on you being awake and remembering everything.

Full context: A factory of one: shipping serious software as a solo founder →

For a tool that holds your code and runs all day, native comes down to three things: integration, performance and trust. It uses the machine's real protections — Keychain for secrets, the system's own permission model — runs on Apple Silicon instead of dragging a bundled browser engine, and can be verified before it launches. A web app in a desktop costume reinvents each of those, usually worse.

Full context: Why native on macOS still matters for developer tools →

Signed means the app carries a verified developer identity, so you know who built it. Notarized means Apple checked it for malware and the system can confirm it has not been tampered with since. Staple the notarization to the app and your machine verifies the whole chain before the first launch, offline. For software you are about to give your source code to, that provenance is a trust decision you can reason about rather than take on faith.

Full context: Why native on macOS still matters for developer tools →

On a quick demo you will not feel it. Across a full day, a bundled browser engine carries the weight of a rendering stack it did not need, in a runtime built to display documents. By the fourth hour, with several sessions running, the tax shows up in the fans, the battery, and small lag on every action. A heavier shell also leaves less headroom, so builds contend with the frame around the work instead of the work itself.

Full context: Why native on macOS still matters for developer tools →

It is a different trust decision. When the real work happens in a service somewhere else, what you are trusting is a connection and a privacy policy, not an artifact the OS can verify. A native app your machine has signed, notarized and checked is provable before it runs. For most software the web model is fine; for the tool you point at private code, verifiable provenance is not a formality, it is the product.

Full context: Why native on macOS still matters for developer tools →

It is an approach where context, intent and evidence are first-class artifacts alongside code. The goal is not to generate more output; it is to maintain a contract that people and agents can execute and verify.

Full context: AI-first development framework: context, execution and evidence →

A tool accelerates an implementation session. A framework organizes the full loop: how a decision is made, which context an agent receives, how its output is validated and how learning returns to the product.

Full context: AI-first development framework: context, execution and evidence →

A small testable contract, repository rules, a way to provide task-specific context and reproducible evidence at completion. Additional complexity is justified only after those basic parts work.

Full context: AI-first development framework: context, execution and evidence →

AI generates code that works and passes tests, but it rarely records why a decision was made. Months later, changing that code means reconstructing intent that was never captured: the constraints, the rejected alternatives, the business reason. The code is not low quality; the context around it is missing. That gap, not the AI itself, is what turns a quick feature into a maze nobody wants to touch.

Full context: Principles for maintainable AI-assisted development →

This article frames five: context as the primary creation rather than a by-product; intent-driven architecture organised around purpose instead of pure function; knowledge treated as a living entity that evolves with the system; human-AI collaboration as a genuine partnership; and a decision architecture that records why choices were made, not just what was decided. Together they invert the old order where code was primary and context secondary.

Full context: Principles for maintainable AI-assisted development →

It needs something better than traditional documentation: context linked to the code and kept alive as the code changes. Static docs in a separate wiki rot and get ignored. What matters is capturing the reasoning behind AI-generated decisions — requirements, trade-offs, rejected paths — close to the code, so the next person, or the next AI session, can act on intent instead of guessing it.

Full context: Principles for maintainable AI-assisted development →

Because the speed is front-loaded and the cost is deferred. AI produces working code fast, but often without captured context and with subtle flaws: insecure patterns, hidden dependencies, even instructions disguised in comments. Teams adopt the tools without adapting their review and security processes, so debt and vulnerabilities accumulate silently. The effort saved today returns later as debugging, rework and security incidents.

Full context: Why AI-generated code becomes hard to maintain →

Not by default. AI assistants reproduce patterns from public code, including outdated or insecure ones, and they can be manipulated by malicious input hidden in the text they process. They also blur the line between data and commands. AI-generated code can be made secure, but only with the same engineering discipline you apply elsewhere: human review of AI output, automated scanning, and treating prompts as executable instructions.

Full context: Why AI-generated code becomes hard to maintain →

Review AI output as carefully as any external contribution, automate security scanning in the pipeline, check for obfuscated instructions in code and configuration, and give the model only the structured context needed for the task.

Full context: Why AI-generated code becomes hard to maintain →

AI clearly speeds up code generation, but generation is the easy part. Real productivity is the total cost over a system's life: how quickly and safely a team can understand, change and extend code later. When AI produces context-poor code fast, the initial speed is often cancelled out by slower debugging, more rework and higher cognitive load. Faster typing is not the same as sustainable productivity.

Full context: When faster AI coding does not improve delivery →

Because you see the output appear in seconds and rarely see the deferred cost. AI generates locally correct, elegant-looking code without your project's specific context: the why, the architecture, the history, the dependencies. Anyone modifying it later has to reconstruct that missing context from scratch. The visible win is generation; the invisible tax lands months later, when the "quick" code becomes slow to touch.

Full context: When faster AI coding does not improve delivery →

Not by lines of code, which rewards volume over value. Look at flow and stability instead: lead time, deployment frequency, change failure rate, time to restore. Track friction signals like code churn, rework rate and how long AI-generated code takes to debug or review. And ask how fast a new developer can safely contribute. Those signals reveal whether AI is adding value or hidden debt.

Full context: When faster AI coding does not improve delivery →

Because teams treat AI systems like traditional software and guess their way through design. AI brings challenges ordinary architecture ignores: non-determinism, context decay, data drift. A prototype that looked promising becomes a tangle of technical debt nobody understands. The failure is usually structural, not bad luck. The system had no architecture built for the specific messiness of AI, so it could not survive past the demo.

Full context: Architecture patterns for AI systems →

This guide covers five battle-tested ones: the context-aware monolith, which keeps context inside the app for simpler projects; the decoupled context pipeline for scaling context handling; the agentic feedback loop, where outputs and feedback improve future behaviour; stratified systems that layer specialised logic on top of foundation models; and human-in-the-loop orchestration for high-stakes decisions. Most real systems combine several as they grow.

Full context: Architecture patterns for AI systems →

Start from your project's scale, complexity and risk, not from the most sophisticated option. A focused MVP may only need context handled inside the application; a system serving many models needs a dedicated context pipeline; high-stakes domains need explicit human review points. The constant across all of them is that deliberate structure, rather than improvised design, is what keeps an AI system alive past launch.

Full context: Architecture patterns for AI systems →

By layering complementary checks rather than trusting one scan. Static analysis (SAST) catches insecure patterns as code is written; software composition analysis (SCA) maps the deep dependency tree AI code pulls in; and DAST-style testing probes the running service and its APIs. Embedding these as automated gates across the pipeline, not as a final checkbox, is what keeps AI-generated code from shipping hidden flaws.

Full context: Securing AI code with Snyk: A practical guide →

Because they were not built for how AI development works. Many basic scanners lack the data-flow analysis to trace untrusted input into dangerous sinks like pickle deserialization, cannot properly parse Jupyter notebooks where secrets hide in output cells, do not semantically understand AI libraries, and only inspect direct dependencies while ignoring the deep transitive tree. The result is both false alarms and, more dangerously, missed real risks.

Full context: Securing AI code with Snyk: A practical guide →

Three complementary layers of application security. SAST (static analysis) inspects source code before it runs, catching insecure patterns and hardcoded secrets. DAST (dynamic testing) attacks the running application from outside to find flaws in APIs, authentication and input handling. SCA (software composition analysis) examines open-source dependencies, direct and transitive, for known vulnerabilities and license issues. Used together they cover code, runtime and supply chain.

Full context: Securing AI code with Snyk: A practical guide →

PaellaDoc is a framework for preserving context across the whole development lifecycle, born from a simple pain: AI-generated code that becomes unreadable to its own author months later. Rather than documentation kept apart from the work, it captures the reasoning, requirements and decisions behind the code and keeps them connected to it, so the "why" survives long after the AI produced the "what".

Full context: PaellaDoc and context in AI-assisted development →

It is the gap AI opens between how fast code is written and how fast its context disappears. The code flows quickly, but the reasoning behind it — the decisions, the constraints, the intent — is rarely captured. Months later that missing context makes your own code feel foreign, slows onboarding, and past decisions get re-litigated. The crisis is not code quality; it is lost knowledge.

Full context: PaellaDoc and context in AI-assisted development →

Because generation is instant and context capture is not. When an assistant writes a feature in minutes, the prompts, trade-offs and rejected options behind it usually go unrecorded. Traditional documentation lives in separate tools and rots. Without deliberately anchoring the reasoning to the code, each future change forces someone to reconstruct intent from scratch, which is exactly where the time savings quietly disappear.

Full context: PaellaDoc and context in AI-assisted development →