Prickles
Prickles
Case file P4
PProcess

Continuous Quality Feedback

The feedback loop is the gate.

Fail in the editor, not at PR review. The cost of a defect grows with the time between writing it and learning of it. The corrective is to move every check as close to the keystroke as the toolchain allows.

ByAdam LewisPublished3 May 2026Revised13 Oct 2026Reading12 minVersionv1.2ConfidenceHigh
§0b

Opinion

The editor is the cheapest place to fail and the PR is the most expensive. Boehm's curve is forty years old and the data underneath it has not improved with age: a defect found at design costs one unit, ten in code, a hundred in test and a thousand in production.1 The team that runs the lint-and-types loop on save is the team that releases cleaner PRs. The team that runs them only on push is the team whose PRs sit in review until Friday because someone has to read past the noise.

I want to plant a flag on this: the principle survived the IDE upheavals of the last decade. ESLint started as a one-shot CLI. It now runs in the editor with a server, with the LSP, with watchers, with hooks, with MCPs the agent reads at edit time. Each step closer to the keystroke is the same point made finer: the gate that fires inside the keystroke is the gate the engineer never argues with. Pair this with P3 Definition of Done and the loop has both ends: the editor catches the easy failures, the DoD verifies the hard ones at merge time.

For the agent the principle is harder still. An LLM will generate plausible code at machine speed and treat the PR review as the first feedback. The fix is to make the lint, type-check and tests available to the agent as it writes (the eslint MCP, the type-check MCP, the test runner). The model that has run the lint server before declaring the work done is the model that produces a PR a human can read in two minutes. The model that has not run the lint is the model whose PR is rejected at the gate.2

Copy a note and link

Grab this short comment and drop it into a PR comment or an LLM chat to prompt the right change.

Fail in the editor, not at PR review. Lint while you write, type-check on save, run the test against the file you just edited, pre-push gates close the loop. Defect cost grows with feedback latency. The corrective is to move every check as close to the keystroke as the toolchain allows.

/tenet/continuous-quality-feedback/P4
Copy for paste
§0c

AI eyes only

Rule: the feedback loop is the gate. Run lint and tests after every edit, not at the PR.

Reject: editing multiple files before running the linter. Reject: writing tests at the end of the change. Reject: treating CI as the first signal.

Generate: after every edit, run the lint MCP (or equivalent) and the affected tests. After every batch of edits, run the full quality script. Paste the failures back into the plan and fix.

Diagnostic: time between edit and check should be measured in seconds, not minutes. A batch of edits without checks is pattern-matching, not engineering.

§0d

Why?

  • Defect cost grows with feedback latency. Boehm's 1981 curve has not aged. Every minute earlier you fail is a multiplier on the eventual cost.
  • PRs move through review faster when the editor caught the easy failures. The reviewer spends the hour on the design, not the trailing whitespace.
  • With editor-level MCPs the agent grounds itself in lint, types and tests as it writes. The agent gets the same loop the human does; CRITIC and the evaluator-optimizer pattern make this load-bearing.
  • The loop closes at the merge boundary via P3 Definition of Done. The continuous loop catches the small. The DoD verifies the large. The team merges with confidence on Friday afternoons.
  • The continuous loop is the proving ground for new lint rules. The rule that fires three times this week is the rule that adds value. The rule that never fires is debt to remove.
  • The continuous loop is the operationalisation of P5 Shift-Left Quality. Every check earlier is a check cheaper. The loop is how shift-left happens.
  • The loop is habit-forming. The engineer who lives in the loop stops noticing the lint warnings as friction. They become the rhythm of the work, not interruptions to it.
The receipts
Origins, quoted passages, evidence, the strongest counter-argument and the reply.
§1

Origins

The intellectual root is Barry Boehm's Software Engineering Economics (1981). Boehm's data set the cost-of-defect curve that every modern feedback-latency argument cites: a defect found at design costs one unit, ten in code, a hundred in test and a thousand in production.1 The implication is direct: every minute of feedback latency is a multiplier on the eventual cost. The corrective is to compress latency at every stage.10

The toolchain root is older than the term. Stephen Johnson's Lint, a C program checker (Bell Labs, 1978) is the original.5 ESLint (2013) is the modern incarnation, but the lineage is straight: a side-by-side analyser that runs while the engineer writes. Research from Microsoft (Murphy-Hill, Zimmermann, Bird and Nagappan's 2015 study of how engineers choose between alternative fixes to a bug) sharpens the point: feedback the developer can act on at the keystroke is the cheapest correction available.4

The continuous-integration tradition is the team-level version. Kent Beck's Extreme Programming Explained (1999) names the ten-minute build as the load-bearing practice.6 Martin Fowler's “Continuous Integration” (2006) generalises the idea.7 Humble and Farley's Continuous Delivery (2010) extends it to the whole pipeline.8 The DORA / Forsgren research programme makes feedback latency one of the measured drivers of delivery performance.9

Agents are the recent extension. Editor MCPs (eslint MCP, sonar MCP, a11y MCP) put the linter in the agent's hands mid-edit. Pre-tool hooks on the Edit tool can block on lint errors and the CLAUDE.md tells the agent to run the loop after every change. Anthropic's evaluator-optimizer pattern formalises the loop.2 CRITIC and Reflexion provide the empirical evidence that the agent grounded in a tool signal improves where the agent grounding itself does not.

§2

Quotes

Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.

Barry Boehm & Victor R. Basili · Software Defect Reduction Top 10 List (2001)

Continuous Integration is a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily. Each of these integrations is verified by an automated build (including test) to detect integration errors as quickly as possible.

Martin Fowler · Continuous Integration (2024 revision)

Shorter product delivery lead times are better since they enable faster feedback on what we are building and allow us to course correct more rapidly.

Forsgren, Humble & Kim · Accelerate (2018)
§3

Evidence

20 external sources, ranked by author authority. The first five are the canon; expand to see the rest, including the qualifiers and the named opposers. Each links out to its primary source.

  1. 01
    Software Engineering EconomicsSupports
    Barry W. Boehm · 1981
    The cost-of-defect curve. Forty years on the data has not aged. The principle still drives every modern feedback-latency argument.
  2. 02
    Lint, a C Program CheckerSupports
    Stephen C. Johnson · 1978
    The original lint. The lineage every modern editor-loop linter inherits. One of the oldest tools whose principle survives unchanged.
  3. 03
    Extreme Programming ExplainedSupports
    Kent Beck · 1999, 2004
    The ten-minute build. The team-level version of the editor loop. The practice that proved a fast feedback cycle was operationally possible at scale.
  4. 04
    “Continuous Integration”Supports
    Martin Fowler · 2006
    The canonical generalisation of Beck’s ten-minute build. Frames CI as a continuous-feedback discipline at the team scale.
  5. 05
    Continuous DeliverySupports
    Jez Humble & David Farley · 2010
    Extends CI to the whole pipeline. Each pipeline stage is a feedback loop. The discipline is to compress the latency of each.
  1. 06
    Accelerate: The Science of Lean Software and DevOpsSupports
    Forsgren, Humble & Kim · 2018
    Ch.4 “Fast Feedback”. Names feedback latency as a 24-capabilities driver. High performers compress every loop in the chain.
  2. 07
    Lean Software Development: An Agile ToolkitQualifies
    Mary & Tom Poppendieck · 2003
    The “amplify learning” and “see the whole” principles. Names the qualifier: feedback that produces learning is worth more than feedback that produces noise.
  3. 08
    “The Design Space of Bug Fixes and How Developers Navigate It”Qualifies
    Emerson Murphy-Hill et al. · 2015
    Empirical evidence that feedback the developer can’t act on is feedback that produces frustration, not behaviour change. The qualifier inside the row.
  4. 09
    “Do Developers Read Compiler Error Messages?”Qualifies
    Titus Barik et al. · 2017
    Eye-tracking study of compiler error messages. Quality of feedback matters as much as latency. Long messages get skimmed.
  5. 10
    ESLintSupports
    Nicholas C. Zakas et al. · 2013 onwards
    The most-installed linter in software history. The operational instance of the principle for the JavaScript and TypeScript world.
  6. 11
    Deep WorkOpposes
    Cal Newport · 2016
    The deep-work steelman. Every editor notification is a context switch. The team optimised for constant feedback is the team that produces shallow PRs.
  7. 12
    A Philosophy of Software Design, 2nd ed.Opposes
    John Ousterhout · 2018, 2021
    The broader critique: constant feedback substitutes for design thinking. The reply is that the loop serves the design, not the other way round.
  8. 13
    “Verifiability”Supports
    Andrej Karpathy · 2025
    Three conditions a task must satisfy to be agent-optimisable: resettable, efficient, rewardable. The continuous editor loop is the canonical setting in which all three hold.
  9. 14
    Reflexion: Language Agents with Verbal Reinforcement LearningSupports
    Noah Shinn et al. · 2023
    Empirical case for grounding the agent in machine-checkable feedback. The continuous loop is the canonical machine-checkable feedback in code work.
  10. 15
    CRITIC: Large Language Models Can Self-Correct with Tool-Interactive CritiquingSupports
    Zhibin Gou et al. · 2024
    Tool-interactive critiquing. The verification signal must come from running tools: exactly the loop the editor MCPs give the agent.
  11. 16
    Building Effective AgentsSupports
    Anthropic · 2024
    Names the evaluator-optimizer pattern. The continuous editor loop is the canonical evaluator surface for the agent.
  12. 17
    Microsoft Engineering Fundamentals PlaybookSupports
    Microsoft · 2020 onwards
    The CI section codifies the row-by-row continuous-feedback model. Useful as the operational template for industrial teams.
  13. 18
    DORA: State of DevOps Report 2024Supports
    DORA / Google Cloud · 2024
    Continues to list fast feedback as one of the technical capabilities that drive software-delivery performance.
  14. 19
    TypeScriptSupports
    Microsoft · 2012 onwards
    Type-checker as continuous-feedback channel. tsserver runs in the editor and surfaces contract failures at the keystroke. The canonical type-level instance of the principle.
  15. 20
    HuskySupports
    Typicode · 2015 onwards
    The dominant pre-push gate framework. Operationalises the team-level second loop after the editor-level first loop.

Twenty sources, three stances. The supporters are Boehm, Johnson's lint paper, Beck, Fowler on Continuous Integration, and Humble & Farley: the cost-of-defect / continuous-integration canon. The qualifiers further down push the line that feedback quality matters as much as feedback speed. The opposers argue that constant feedback fragments attention. The steelman the case has to address.

§4b

Enforcement

Viewing: TypeScript.

Apply these rules in eslint.config.mjs. The full enforcement across every tenet lives on the implementation page.

RuleToolCatches
ESLint Language ServerESLint Language Serverlint failures at the keystroke level. The editor underlines them; the engineer fixes them before the file is saved.
tsserverTypeScript LSP (tsserver)type-level contract failures at the keystroke. The canonical instance of the principle for typed JavaScript.
vitest --watchvitest --watchtest failures on save. Re-runs only the tests affected by the changed file.
Prettier (format on save)Prettier (format on save)format violations at save time. Removes the format conversation from PR review entirely.
lint-stagedlint-stagedthe per-commit subset. Runs ESLint, Prettier and the affected tests on the staged files; sub-second loop.
Husky pre-pushHusky pre-pushthe team-level second loop. Runs npm run quality on every push; the merge button doesn’t accept a red pre-push.
eslint MCPeslint MCPthe agent-level loop. The model runs the linter mid-edit and corrects before declaring done.
@typescript-eslint/no-floating-promisestypescript-eslintpromises returned without an await. The classic class of bug that surfaces only at runtime; surfaces in the editor.
eslint.config.mjsconfiguration snippet
import { defineConfig } from 'eslint/config';
import tseslint from 'typescript-eslint';

export default defineConfig({
  files: ['**/*.{ts,tsx}'],
  extends: [tseslint.configs.base],
  languageOptions: {
    parserOptions: { project: true },
  },
  rules: {
    '@typescript-eslint/no-floating-promises': 'error',
    '@typescript-eslint/no-misused-promises': 'error',
  }
});
§4c

AI rules

File.cursor/rules/p4-continuous-feedback.mdc
---
alwaysApply: true
---

## Prickles P4: Continuous Quality Feedback

Lint while you write. Type-check on save. Run the test against the file you just edited. Pre-push gates close the loop.

Every check that catches an error in PR review should run in the editor or pre-push first. The cost of catching it later is exponential.

Tune the latency, don't fragment attention: lint server runs on save, not on every keystroke. The test runner watches the file you saved, not the whole suite.

For agents: configure the eslint MCP, the type-check MCP and the test runner so the agent grounds every change in tool feedback before declaring it done.

Repo layout, CI, and ESLint wiring for these paths live on /implementation, not repeated on every tenet.

§5

Counter-argument

Counter

The strongest steelman is the deep-work reading drawn from Cal Newport: every editor notification is a context switch, every interruption is a cost and the team optimised for constant feedback is the team that produces shallow PRs.3 Murphy-Hill's research adds the qualifier inside the row: feedback that the developer can't act on is feedback that produces frustration, not behaviour change.4 Ousterhout's broader critique is that constant feedback substitutes for design thinking. The engineer who lives in the loop never steps back to ask whether the unit is the right unit.

§6

Counter-argument retort

Reply

Newport is right about deep work when the editor is configured to fire on every keystroke without batching. The reply is to tune the latency, not abandon the principle: the lint server runs on save, not on every character. The test runner watches the file you saved rather than the whole suite. The corrective is configuration, not retreat from continuous feedback.

Murphy-Hill's qualifier is the more useful warning: feedback the developer can't act on is noise.4 The fix is to read every linter rule and either turn it on with intent or turn it off. Warnings that are never read are debt. Pair this with TA1 Linter as Law and the rule is sharp: a warning is a decision the team has not yet made. An error is a rule the team has agreed to enforce.

Ousterhout's broader critique, that constant feedback substitutes for design thinking, is true for the engineer who lives in the loop and never steps back. The reply is the same as for any tool: the tool serves the design and never the other way round. The lint loop is fast feedback on the small. The spec, the AC and the architecture review are the large. Both belong in the engineer's day, not one or the other.

In production work, the row that fires the lint and the type-check on save is the row whose PR queue moves through review in hours rather than days. P3 Definition of Done closes the loop at the merge boundary; P4 closes it at the keystroke. The two compose into a single discipline whose first job is to make defects visible early.

§7

Notes

  1. [1]Barry W. Boehm: Software Engineering Economics (Prentice Hall, 1981). The cost-of-defect curve: a defect costs one unit to fix at requirements, five at design, ten in code and fifty in test, and one found after delivery is often a hundred times dearer than one found at requirements and design. Forty years on, the data has not aged.
  2. [2]Noah Shinn et al.: “Reflexion: Language Agents with Verbal Reinforcement Learning”, NeurIPS 2023. The agent grounded in machine-checkable feedback improves. The agent grading itself does not. Generalised by Madaan (Self-Refine) and Gou (CRITIC).
  3. [3]Cal Newport: Deep Work: Rules for Focused Success in a Distracted World (Grand Central, 2016). The deep-work steelman against constant feedback. The reply is to tune the latency, not abandon the principle.
Disagree? Found a hole in the argument? Take issue with this tenet →
Last revised: 2026-10-13