AAIF Live · Published 2026-03-24

Everything We Got Wrong About Research-Plan-Implement - Dexter Horthy

Open on YouTube ↗

Summary

Overview

  • Speaker: Dexter Horthy
  • Channel: AAIF Live
  • Main topic: Lessons learned from rolling out Research-Plan-Implement (RPI) and QR-SPI methodology for AI coding agents to thousands of engineers.
  • Purpose: To share hard-earned production lessons on how to effectively use AI coding agents without sacrificing code quality or overwhelming instruction budgets. Dexter Horthy discusses the mistakes made over six months of building and deploying AI coding agents using the Research-Plan-Implement (RPI) and QR-SPI methodologies. He examines Stanford developer productivity studies, instruction budgets for LLMs, why monolithic prompts fail, the danger of bad research and bad plans, the difference between horizontal and vertical planning, and the importance of human-agent mental alignment.

Topic Map

Stanford Developer Productivity Study

  • Explanation: Reviewing Igor's Stanford study on AI developer productivity, showing that while AI increases output volume by ~50%, it also significantly increases rework and fixing mess from last week, especially on high-complexity brownfield tasks.
  • Key claims:
    • AI increases code output volume
    • AI use in software engineering increases rework
    • Great for low-complexity greenfield tasks, poor for high-complexity brownfield tasks
  • Examples:
    • Greenfield vs brownfield task execution
  • Terminology:
    • rework
    • greenfield
    • brownfield
    • task complexity
  • Why it matters: Understanding the limits of AI productivity prevents teams from shipping buggy code under the illusion of speed.

What Went Wrong with RPI

  • Explanation: Examining why initial RPI (Research, Plan, Implement) prompts and commands failed for many teams when deployed broadly.
  • Key claims:
    • People were getting bad research because tickets were mixed with research context
    • Plans were low quality due to giant monolithic prompts with 85+ instructions
    • Models cannot follow hundreds of instructions reliably
  • Examples:
    • Passing full ticket context directly into research step
  • Terminology:
    • instruction budget
    • monolithic prompt
    • compression of truth
  • Why it matters: Highlights why prompt engineering alone is insufficient without proper structural workflow design.

The Instruction Budget

  • Explanation: Referencing research showing frontier LLMs can only follow 150 to 200 instructions with reasonable consistency.
  • Key claims:
    • Exceeding 150-200 instructions drops adherence significantly
    • Combining system prompts, claudemd, tools, and MCPs exhausts the instruction budget
  • Examples:
    • 85+ instructions in a single create_plan prompt
  • Terminology:
    • instruction budget
    • frontier LLMs
    • consistency
  • Why it matters: Explains why agent frameworks break down as instructions grow.

Horizontal vs Vertical Plans

  • Explanation: Contrasting horizontal plans (doing all DB, then all API, then all frontend) with vertical plans (phases touching small vertical slices with continuous testing).
  • Key claims:
    • Models love writing horizontal plans which are hard to debug
    • Vertical plans provide checkpoints and enable early detection of broken assumptions
  • Examples:
    • 1200 lines of code written horizontally vs partitioned into vertical phases
  • Terminology:
    • horizontal plans
    • vertical plans
    • checkpoints
  • Why it matters: Vertical planning drastically reduces rework and makes agent output reviewable.

The 7-Step QR-SPI Process

  • Explanation: Introducing the evolved Q-R-S-P-I (Questions, Research, Design, Structure Outline, Plan, Worktree, Implement, Pull Request) acronym known as Crispy.
  • Key claims:
    • Splitting monolithic prompts into 7 distinct steps keeps instructions per prompt under 40
    • Encourages human-agent mental alignment before writing code
  • Examples:
    • Using structure outlines as C header files equivalent for AI plans
  • Terminology:
    • QR-SPI
    • Crispy
    • structure outline
    • design concept
  • Why it matters: Provides a robust, scalable engineering framework for AI-driven development.

Key Points

Do not outsource the thinking

  • Explanation: Engineers must remain actively involved in design and alignment rather than relying on a magic prompt.
  • Evidence: User feedback across thousands of engineers showing poor results when agents make all decisions autonomously.
  • Practical implication: Engineers should use agents for leverage while retaining ownership of architectural intent.

Read the code

  • Explanation: Despite initial thoughts that plans eliminate code reading, teams must still read code and plans.
  • Evidence: Six months of not reading code led to systemic failures requiring major rewrites.
  • Practical implication: Maintain code ownership and review intermediate markdown artifacts.

Control flow over prompt instructions

  • Explanation: Instead of putting all control logic inside long prompts, use deterministic control flow (if statements, loops) to manage agent pipelines.
  • Evidence: Splitting a single mega-prompt into discrete agent steps reduced instructions from 85+ to under 40.
  • Practical implication: Build agent pipelines with structured code rather than complex prompt steering.

Frameworks, Models & Processes

QR-SPI (Crispy)

  • How it works: A multi-step agentic workflow breaking down software engineering tasks into discrete, verifiable phases.
  • Components:
    • Questions
    • Research
    • Design
    • Structure Outline
    • Plan
    • Worktree
    • Implement
    • Pull Request
  • When to use: When building complex software systems with AI coding agents to ensure high quality and alignment.

Examples & Case Studies

Teams giving monolithic prompts with 85+ instructions to coding agents.

  • Illustrates: Instruction budget exhaustion leading to skipped steps and low-quality plans.
  • Lesson: Split prompts into smaller, focused sub-tasks and use control flow.

Writing 1200 lines of horizontal code across database, services, and frontend in one go.

  • Illustrates: Difficulty in localizing bugs when nothing is tested incrementally.
  • Lesson: Use vertical plans with intermediate checkpoints.

Actionable Takeaways

  • Immediate:
    • Keep instructions per prompt under 40
    • Use structure outlines before writing full implementation plans
    • Hide the raw ticket from research context to maintain objectivity
  • Strategic:
    • Avoid monolithic mega-prompts
    • Embrace human-agent mental alignment through design discussions
    • Design agent pipelines using programmatic control flow
  • Questions to investigate:
    • How do we formally verify agent-generated plans?
    • What is the optimal instruction budget for domain-specific coding agents?
    • How do we measure developer productivity improvements accurately with AI?

Claims Worth Verifying

  • Frontier LLMs can only follow 150-200 instructions with reasonable consistency. (empirical)
  • Using AI in software engineering increases rework by 50%. (empirical)

Notable Quotes

"I am humble enough to admit when I was wrong." "Do not outsource the thinking." "If you built a tool that requires 7+ hours of training to wield, go fix the tool."

Compressed Summary

  • RPI methodology evolved into QR-SPI (Crispy) to handle instruction budgets.
  • Monolithic prompts exceeding 150 instructions fail consistently.
  • Vertical planning and intermediate markdown docs prevent agent drift and rework.
  • Human-agent mental alignment requires collaborative design before implementation.
  • Keywords: coding agents, rpi, qr-spi, context engineering, instruction budget
  • Core insight: To make AI coding agents reliable, engineers must manage instruction budgets by splitting monolithic prompts into structured, vertical workflows with continuous human-agent alignment.

Core insights

7
Mechanismhigh noveltymoderate evidence

The instruction budget is a single finite resource shared across system prompts, CLAUDE.md-style context files, tool definitions, and MCP integrations — not a per-prompt limit. Frontier LLMs follow roughly 150-200 instructions consistently, so every added tool schema or context file consumes budget that the task workflow needs.

Why it matters

It reframes context/tool/instruction design as a zero-sum allocation problem: adding an MCP or a memory file silently degrades compliance with existing workflow instructions, which explains non-local agent failures as frameworks grow.

Generalization

Any agent runtime that stacks system prompt + project context + tool schemas + retrieved instructions should budget total instruction count globally and treat each addition as spending from the same account.

Referencing research showing frontier LLMs can only follow 150 to 200 instructions with reasonable consistency.
Open source video
Combining system prompts, claudemd, tools, and MCPs exhausts the instruction budget
Open source video
Architecturemedium noveltystrong evidence

Agent orchestration logic should live in deterministic control flow (if statements, loops, discrete steps) rather than inside long prompts. Splitting one mega-prompt into discrete agent steps cut per-prompt instructions from 85+ to under 40.

Why it matters

Moves sequencing, branching, and retry responsibility out of natural-language instructions and into code, where it is inspectable, testable, and not subject to instruction-budget decay.

Generalization

Pipeline structure belongs in the harness; prompts should specify only the narrow task for the current step. This applies to any multi-step agent workflow, not just coding.

Instead of putting all control logic inside long prompts, use deterministic control flow (if statements, loops) to manage agent pipelines
Open source video
Splitting a single mega-prompt into discrete agent steps reduced instructions from 85+ to under 40
Open source video
Practicemedium noveltystrong evidence

Plans must be decomposed into vertical slices (small end-to-end phases with checkpoints and continuous testing) rather than horizontal layers (all DB, then all API, then all frontend). Models default to writing horizontal plans, which are hard to debug.

Why it matters

Vertical phasing surfaces broken assumptions at each checkpoint, bounding the blast radius of a wrong decision and making agent output reviewable; horizontal plans hide errors until thousands of lines are already written.

Generalization

Incremental, verifiable slice ordering is a general principle for any agent-generated execution plan, including infra and data-pipeline agents.

Models love writing horizontal plans which are hard to debug
Open source video
Vertical plans provide checkpoints and enable early detection of broken assumptions
Open source video
Writing 1200 lines of horizontal code across database, services, and frontend in one go.
Open source video
Failure Modehigh noveltymoderate evidence

Contaminating the research step with the raw ticket context produces biased, low-quality research; hiding the ticket from the research context preserves objectivity.

Why it matters

It identifies an input-hygiene failure mode: giving the agent the intended answer inside the investigation step causes it to rationalize toward the ticket rather than discover the actual system state.

Generalization

Separate the artifact that defines intent from the agent step that investigates reality; feed the investigation a neutral framing to avoid confirmation bias in any research/extraction agent.

People were getting bad research because tickets were mixed with research context
Open source video
Hide the raw ticket from research context to maintain objectivity
Open source video
Mechanismmedium noveltymoderate evidence

A 'structure outline' precursor artifact (an interface/header-file equivalent) is produced before the full implementation plan, acting as a reviewable contract between design and implementation.

Why it matters

Inserts a cheap, human-reviewable interface layer where the human-agent mental alignment check happens, catching structural disagreement before expensive plan and code generation.

Generalization

Agent pipelines for large changes benefit from an explicit interface/signature artifact as an intermediate gate between design and implementation, verifiable independently of the code.

Using structure outlines as C header files equivalent for AI plans
Open source video
Encourages human-agent mental alignment before writing code
Open source video
Empirical Resultmedium noveltymoderate evidence

AI assistance increases code output volume (~50%) while also increasing rework, and its value is complexity-dependent: strong on low-complexity greenfield work, weak on high-complexity brownfield work.

Why it matters

Gives a task-complexity selection criterion for where to deploy coding agents and cautions that throughput metrics alone mask downstream cleanup cost.

Generalization

Agent productivity should be measured with rework-inclusive metrics and segmented by task complexity, not by output volume.

AI increases code output volume
Open source video
AI use in software engineering increases rework
Open source video
Great for low-complexity greenfield tasks, poor for high-complexity brownfield tasks
Open source video
Failure Modelow noveltymoderate evidence

Six months of delegating without reading code produced systemic failures requiring major rewrites; plans do not substitute for code and artifact review.

Why it matters

Establishes that reviewing intermediate markdown artifacts and reading generated code are load-bearing, not optional ceremony, and that code ownership must survive agent adoption.

Generalization

Any agentic pipeline that removes human inspection of intermediate and final artifacts accumulates latent structural debt that surfaces only at rewrite scale.

Six months of not reading code led to systemic failures requiring major rewrites
Open source video
Maintain code ownership and review intermediate markdown artifacts
Open source video

Deep dives

5

Instruction budget accounting across system prompt, project context, tool schemas, and MCPs

Research question

How can a harness instrument effective instruction consumption per source (system prompt, project memory file, tool schema, MCP description) and correlate total consumption with per-step adherence failures on unchanged steps?

Why

If all context artifacts draw from one finite instruction-following account, then a platform team adding an MCP or a memory file is silently spending the budget the workflow needs. Without per-source accounting and adherence telemetry, that degradation is invisible until agents start skipping steps, and no allocation policy can be defended.

Combining system prompts, claudemd, tools, and MCPs exhausts the instruction budget
Open source video
Referencing research showing frontier LLMs can only follow 150 to 200 instructions with reasonable consistency.
Open source video
Source video

Mechanical plan verification against a pre-code interface contract

Research question

Can a plan-checking pass validate an agent-generated plan against a structure-outline contract and stated system invariants well enough to predict downstream defects before any implementation code exists?

Why

Plan quality is named as a central failure source, yet the only remedies offered are structural heuristics. A structure outline is an independently checkable artifact sitting between design and implementation, so it is the natural anchor for a verification pass that converts plan review from taste into a falsifiable gate.

Using structure outlines as C header files equivalent for AI plans
Open source video
Vertical plans provide checkpoints and enable early detection of broken assumptions
Open source video
Source video

Default horizontal-planning bias and harness-level suppression

Research question

Is horizontal planning a model default that persists unless the harness structurally forbids it, and do enforced vertical phases reduce rework and bug-localization time measurably?

Why

It determines whether planning granularity is a prompt-wording problem or a harness-constraint problem. If prompting cannot suppress horizontal plans, then phase ordering must be validated as a structural property of the plan artifact, and any review process that trusts model-authored ordering is unsound.

Models love writing horizontal plans which are hard to debug
Open source video
Writing 1200 lines of horizontal code across database, services, and frontend in one go.
Open source video
Difficulty in localizing bugs when nothing is tested incrementally.
Open source video
Source video

Do tool and MCP schemas consume instruction-following capacity like prose instructions?

Research question

Do tool schemas and MCP descriptions consume instruction-following capacity equivalently to prose instructions, or is the interference effect materially weaker for declarative schema content?

Why

The practical allocation policy depends on it. If schema content is cheap, teams can expand tool surfaces while protecting workflow instructions; if it is costly, tool proliferation becomes a first-class cause of agent non-compliance and must be gated like any other budget spend.

Combining system prompts, claudemd, tools, and MCPs exhausts the instruction budget
Open source video
Splitting a single mega-prompt into discrete agent steps reduced instructions from 85+ to under 40
Open source video
Source video

Input hygiene: withholding intent artifacts from investigation steps

Research question

Does withholding the ticket from the research step measurably improve research accuracy and downstream plan quality, or does it only change the framing of the research prose without affecting defect rates or plan revision counts?

Why

The practice is asserted as a rule but reported without outcome measurement. If it does not change downstream defects, an entire step-independent input discipline is being enforced on aesthetic grounds, which is costly and hard to sustain across thousands of engineers.

People were getting bad research because tickets were mixed with research context
Open source video
Hide the raw ticket from research context to maintain objectivity
Open source video
Source video

Article ideas

4

Your Agent Has One Instruction Budget, Not Many

System prompts, project memory files, tool schemas, and MCP integrations all spend from the same finite instruction-following capacity, so adding any of them silently degrades compliance with workflow instructions that were never edited. Context engineering is therefore budget allocation, and platform teams need a ledger before they need more capabilities.

Angle

Reframe context engineering as a zero-sum accounting problem and show why non-local agent failures appear as frameworks grow.

Source video

Move the Loop Out of the Prompt

Sequencing, branching, and retries belong in deterministic harness code, not in natural-language instructions. Control logic written in prose both consumes the instruction budget the task itself needs and is non-deterministic, which is why splitting a mega-prompt into discrete steps improved adherence more than any prompt rewrite did.

Angle

Show that the primary lever for agent reliability is architectural relocation of control flow rather than better prompt craft.

Source video

Vertical Slices Are the Unit of Agent Review

Models default to horizontal plans, which hide wrong assumptions until large amounts of code already exist. Enforcing small end-to-end phases with checkpoints is what makes agent output reviewable and bounds rework, so plan granularity should be a validated structural property of the plan artifact rather than a stylistic preference.

Angle

Treat phase ordering as a review gate, not a planning preference, and tie it directly to bug-localization cost.

Source video

Output Volume Is a Vanity Metric for Coding Agents

AI assistance raises code output while also raising rework, and its value is conditional on task complexity rather than uniform. Any productivity claim built on throughput alone will look like a win while the cleanup cost lands in a later period, so teams need rework-inclusive, complexity-segmented metrics and a rule for which task types agents should touch at all.

Angle

Attack the default measurement of agent productivity and propose deployment gating by task type.

Source video

Project ideas

4

Instruction Ledger

gatehouse

Effective instruction consumption is additive across system prompt, project context file, tool schemas, and MCP descriptions, so appending a single large tool schema measurably degrades adherence on workflow steps whose instructions were not modified.

Proof of concept

Instrument a multi-step coding-agent harness to tally instruction counts per source and per step, then run a frozen task suite under three conditions: baseline, plus a large MCP tool surface, plus an added project memory file. Capture per-step adherence (steps silently skipped or partially executed) and task outcome.

Measurement

Per-step adherence rate and step-skip rate across N runs per condition, plus the delta in adherence on unmodified steps attributable to each added source.

Source video

Plan Gate

gatehouse

A plan-checking pass that validates a generated plan against a structure-outline contract and vertical-phase constraints can predict downstream implementation defects before any code is written.

Proof of concept

Run the design-to-structure-outline-to-plan stages on a set of real brownfield change requests, run an automated plan checker that flags horizontal phasing, missing checkpoints, and deviations from the outline contract, then compare flagged plans against unflagged plans through implementation and review.

Measurement

Correlation between checker flags and (a) downstream defect counts, (b) plan revision rounds, (c) reviewer rejection rate.

Source video

De-Ticketed Research A/B

new

Withholding the raw ticket from the research step improves downstream plan quality and reduces defect rates, rather than only changing the framing of the research output.

Proof of concept

A/B the research step on matched change requests: condition A passes the ticket into research, condition B runs research on neutral context with the ticket reintroduced at design. Carry both through identical plan and implementation steps with blinded review.

Measurement

Downstream defect rate, plan revision count, and blinded reviewer assessment of research-to-system-reality accuracy.

Source video

Rework-Attributed Productivity Eval

beyond-evals

Rework introduced by coding agents can be attributed to specific upstream steps (research, plan, or implementation), and complexity-segmented rework-inclusive metrics invert the productivity ranking produced by output-volume metrics on brownfield tasks.

Proof of concept

Instrument an agent pipeline to tag generated changes by originating step, then track subsequent corrective commits touching those same lines within a fixed window, segmented by greenfield versus brownfield and by a stated complexity proxy.

Measurement

Rework-inclusive net output (shipped lines minus corrective lines) per task complexity band, compared with raw output volume ranking.

Source video

Architectural implications

3

Orchestration was embedded in a single create_plan mega-prompt with 85+ instructions.

Before

One monolithic prompt carrying research, planning, and sequencing instructions plus full ticket context.

After

A 7-step pipeline (Questions, Research, Design, Structure Outline, Plan, Worktree, Implement, PR) with per-step prompts under 40 instructions and sequencing expressed as control flow.

Consequence

Each step has a small, auditable instruction surface; failures localize to a step, and the human gets checkpoints to review before the next stage runs.

Source video

Context from the intent artifact (the ticket) was mixed into the investigation step.

Before

Research prompt receives the ticket plus system context in one blob.

After

Research runs on de-ticketed, neutral context; the ticket informs later design/plan steps.

Consequence

Reduces confirmation bias in research output and yields findings that reflect system reality rather than the requester's framing.

Source video

Planning granularity was a free choice left to the model.

Before

Model-authored horizontal plans executing all DB, then all API, then all frontend.

After

Plans constrained to vertical phases with explicit checkpoints and continuous testing.

Consequence

Errors surface at slice boundaries instead of after large horizontal batches, cutting rework and making agent output reviewable.

Source video

Tradeoffs and failure modes

5

Monolithic mega-prompts

Benefit

A single prompt keeps the whole workflow in one place and is easy to author and ship.

Cost or risk

Exhausting the 150-200 instruction budget causes adherence to drop, so steps get silently skipped and plans come out low quality.

Plans were low quality due to giant monolithic prompts with 85+ instructions
Open source video
Source video

Horizontal plan execution

Benefit

Batching by layer (all DB, then API, then frontend) minimizes context switching between subsystems.

Cost or risk

Nothing is tested incrementally, so bugs cannot be localized and a wrong assumption propagates across the whole batch.

Difficulty in localizing bugs when nothing is tested incrementally.
Open source video
Source video

Rich ticket context in research

Benefit

Passing full ticket context into research captures requirements up front and saves a handoff.

Cost or risk

It biases the research toward the requested solution instead of the actual system state, producing bad research that propagates into plans.

People were getting bad research because tickets were mixed with research context
Open source video
Source video

Agent autonomy without reading code

Benefit

Plans appear to remove the need to read generated code, freeing engineer time.

Cost or risk

Delegation without inspection accumulates structural errors that only surface as major rewrites; engineers must retain ownership of architectural intent.

Six months of not reading code led to systemic failures requiring major rewrites
Open source video
Source video

Prompt-level control logic

Benefit

Keeping branching and sequencing in the prompt avoids building harness code.

Cost or risk

Control logic consumes instruction budget that the task itself needs and is non-deterministic, whereas code-level control flow is inspectable.

Instead of putting all control logic inside long prompts, use deterministic control flow (if statements, loops) to manage agent pipelines
Open source video
Source video

Open questions

5

How do we formally verify agent-generated plans?

Why unresolved

The summary identifies plan quality as a central failure source but offers only structural heuristics (vertical slices, structure outlines), not a verification method.

Research direction

Prototype plan-checking passes that validate a plan against interface/contract artifacts and existing system invariants before implementation begins.

Source video

What is the optimal instruction budget for domain-specific coding agents?

Why unresolved

The 150-200 figure is cited as a general frontier-model adherence limit, with no breakdown per domain, model, or task type.

Research direction

Benchmark instruction adherence as a function of instruction count across domains and models, holding tool/schema surface constant, to find per-domain ceilings.

Source video

How do we measure developer productivity improvements accurately with AI?

Why unresolved

Output volume rises while rework also rises, so the summary's own evidence shows existing metrics are misleading.

Research direction

Define rework-inclusive, complexity-segmented productivity metrics and instrument agent pipelines to attribute rework to upstream research, plan, or implementation steps.

Source video

Does hiding the ticket from research actually improve downstream plan and code quality, or only change research prose?

Why unresolved

The claim is stated as a practice without reported outcome measurement across the thousands of engineers.

Research direction

A/B the research step with and without ticket context, measuring defect rates, plan revision counts, and reviewer assessments downstream.

Source video

How should the shared instruction budget be allocated across system prompt, project context files, tools, and MCPs?

Why unresolved

The summary states these sources compete for one budget but gives no allocation guidance or instrumentation for measuring consumption.

Research direction

Build budget accounting into the harness that tallies effective instruction count per source and correlates total consumption with step-adherence failures.

Source video

Key claims

8
factualVerification needed

Frontier LLMs can only follow 150 to 200 instructions with reasonable consistency.

Evidence

Referencing research showing frontier LLMs can only follow 150 to 200 instructions with reasonable consistency.

Question

Under what prompt conditions, model versions, and instruction types does adherence measurably degrade past 150-200 instructions, and is the threshold model-specific?

Source video
causalVerification needed

Using AI in software engineering increases rework by 50%.

Evidence

Using AI in software engineering increases rework by 50%. (empirical)

Question

Does the Stanford study attribute a 50% rework increase to AI use, or is 50% the output-volume increase while rework is a separate qualitative finding?

Source video
causalVerification needed

Splitting monolithic prompts into 7 distinct steps keeps instructions per prompt under 40.

Evidence

Splitting monolithic prompts into 7 distinct steps keeps instructions per prompt under 40

Question

Does the sub-40 instruction count per step hold across tasks of varying complexity, or only for the initial QR-SPI rollout tasks?

Source video
causalVerification needed

Models preferentially generate horizontal plans, which are hard to debug.

Evidence

Models love writing horizontal plans which are hard to debug

Question

Is horizontal-plan generation a default model behavior that can be reliably suppressed by prompting, or does it persist without harness-level structural constraints?

Source video
comparativeVerification needed

AI-assisted development performs well on low-complexity greenfield tasks and poorly on high-complexity brownfield tasks.

Evidence

Great for low-complexity greenfield tasks, poor for high-complexity brownfield tasks

Question

What operational definition of task complexity separates high-yield from low-yield agent tasks, and does it generalize beyond the studied teams?

Source video
causalVerification needed

Combining system prompts, CLAUDE.md, tools, and MCPs exhausts the same instruction budget.

Evidence

Combining system prompts, claudemd, tools, and MCPs exhausts the instruction budget

Question

Do tool schemas and MCP descriptions consume instruction-following capacity equivalently to prose instructions, or is the interference effect weaker than claimed?

Source video
causalVerification needed

Passing raw ticket context into the research step degrades research quality.

Evidence

People were getting bad research because tickets were mixed with research context

Question

Does withholding the ticket measurably improve research accuracy and downstream plan quality compared to including it?

Source video
causalVerification needed

Not reading generated code for six months led to systemic failures requiring major rewrites.

Evidence

Six months of not reading code led to systemic failures requiring major rewrites

Question

Can the failures be attributed specifically to lack of code reading, or to other pipeline weaknesses such as horizontal planning and plan quality?

Source video

Connections

5