Moore Impact LLC
gold L2 Agent IDEcore operating rules
Every project begins with a single testable business purpose statement. No other work proceeds until this statement exists and the human practitioner has approved it.
Why: Without a grounding statement, AI generation drifts toward technically interesting but commercially irrelevant output. The business purpose is the acceptance test for the entire project.
Failure mode: Team skips business purpose definition and jumps to technology selection. AI generates an architecturally elegant system that solves no real business problem. Months of work are discarded.
Scope: All projects. The business purpose statement is referenced at Steps 1, 8, 9, and 10.
The PRD is the single source of truth for project scope. It is a living document updated at every iteration point. AI proposes PRD changes. The human practitioner approves them.
Why: Without a living PRD, scope drifts invisibly. Discoveries in prototyping or domain modeling change requirements, but those changes are lost if not captured in the PRD.
Failure mode: Discovery in Step 7 reveals a new stakeholder need. The finding is discussed but not written into the PRD. The implementation in Step 10 misses the requirement. Stakeholder is dissatisfied.
Scope: Steps 3 through 10. The PRD is created at Step 3 and updated throughout.
AI generates all artifacts (stakeholder maps, PRDs, prototypes, data models, evaluation frameworks, test criteria, implementation code). No artifact ships without human review.
Why: AI output is fast but can be subtly wrong, structurally coherent but semantically off. Human review catches misalignment with business context, stakeholder politics, and domain nuance that AI cannot perceive.
Failure mode: AI generates a stakeholder analysis that omits a politically powerful but technically irrelevant stakeholder. The project proceeds without their buy-in. They block deployment.
Scope: All ten steps. Every AI-generated artifact passes through a human review gate before becoming authoritative.
Technical sunk costs are treated as essentially zero. The methodology explicitly encourages backtracking, re-generation, and exploration of alternative approaches without regard to prior AI output.
Why: When teams feel invested in AI-generated code or designs, they resist changing direction even when evidence says the current path is wrong. Zero sunk cost mindset enables honest evaluation.
Failure mode: Team spends three days refining an AI-generated prototype. New discovery invalidates the approach. Team continues with the flawed prototype because they feel invested in the effort. The final product inherits the flaw.
Scope: All steps involving AI-generated artifacts. Particularly critical at Steps 5, 6, and 10 where code and designs accumulate.
Each iteration focuses on one or two stakeholders at a time. The full PRD defines the complete scope, but work proceeds one bite at a time.
Why: Trying to satisfy all stakeholders simultaneously overwhelms both the human reviewer and the AI generator. Single-stakeholder focus produces sharper artifacts and clearer evaluation criteria.
Failure mode: Team attempts to prototype for all five stakeholders at once. AI generates a bloated, compromised UI that satisfies no one. Human reviewer cannot evaluate because the artifact is too complex. Project stalls.
Scope: Steps 5 through 10. Steps 1-4 are whole-project scope. Steps 5+ are bite-by-bite.
human ai boundary conditions
Five mandatory human review gates exist at Steps 3, 4, 6, 8, and 9. AI-generated output at these steps cannot proceed without explicit human approval.
Why: These gates protect against the five highest-risk failure modes: scope drift (Step 3), technology lock-in (Step 4), data model errors (Step 6), assumption blindness (Step 8), and false validation (Step 9).
Failure mode: Team skips the Step 8 review gate ("What Are We Missing?"). AI-generated evaluation confirms the project is on track. A lifecycle implication (regulatory compliance, data migration, support staffing) is missed. It surfaces in production.
Scope: Steps 3, 4, 6, 8, and 9. Other steps have review expectations but these five are mandatory gates.
Technology selection (Step 4) requires human evaluation of AI-recommended options. The standard is "happy with" not "optimal." AI presents options with tradeoffs. The human decides.
Why: AI optimizes for technical criteria. Humans weigh organizational readiness, team skill gaps, vendor relationships, and risk tolerance, factors AI cannot fully assess.
Failure mode: AI recommends a technically superior framework. The team has no experience with it. Learning curve delays the project by two months. A familiar, adequate framework would have shipped in three weeks.
Scope: Step 4. Also relevant when technology decisions are revisited during iteration loops.
Business purpose validation (Step 9) requires the human practitioner to define testable hypotheses with explicit pass/fail criteria before AI generates validation artifacts.
Why: If AI generates both the hypotheses and the validation criteria, confirmation bias is structurally embedded. The human must define what "pass" looks like before AI checks.
Failure mode: AI generates hypotheses and their validation tests. The tests are subtly aligned to confirm the hypotheses. The project "passes" validation but the business purpose is not actually met. Failure surfaces post-launch.
Scope: Step 9. The business purpose confirmation gate. Proceed or return.
Data structure and domain modeling (Step 6) requires human review of AI-generated models against real-world domain knowledge. AI models from requirements. Humans validate against operational reality.
Why: AI domain models are structurally correct but can miss implicit domain constraints, edge cases, and business rules that exist only in practitioners' heads.
Failure mode: AI generates a clean data model for a scheduling system. The model does not account for a business rule that certain resource types cannot overlap. The constraint is discovered in production when double-bookings occur.
Scope: Step 6. Also applies when the data model is revised during iteration loops between Steps 5 and 6.
Step 8 (Comprehensive Evaluation) is a mandatory adversarial review. The human practitioner asks "What are we missing?" and challenges every assumption. AI generates the evaluation. The human decides what to act on.
Why: AI is poor at identifying its own blind spots. A structured adversarial review forces examination of lifecycle implications, deployment concerns, support models, and edge cases that AI-generated artifacts tend to omit.
Failure mode: Team treats Step 8 as a rubber stamp. AI reports "no issues found." The team proceeds. A data migration requirement surfaces during deployment that adds four weeks to the timeline.
Scope: Step 8. Must be performed before Step 9 (business purpose validation).
coordination patterns
Steps 5 and 6 form a tight bidirectional loop. UI prototyping and data modeling inform each other iteratively. Changes in one trigger re-evaluation of the other.
Why: UI design reveals data needs that the model did not anticipate. Data model constraints reveal UI designs that are infeasible. The loop catches mismatches early when the cost of change is near zero.
Failure mode: Team completes UI prototyping (Step 5) in isolation, then starts data modeling (Step 6). The data model cannot support several UI patterns. Rework is required on both sides. Without the bidirectional loop, this discovery happens late and costs more.
Scope: Steps 5 and 6. The loop runs until both UI and data model are stable for the current stakeholder bite.
Micro-macro seesawing is the primary discovery mechanism. Deep focus on a single stakeholder (micro) reveals system-wide patterns (macro). Macro insights feed back into subsequent micro iterations.
Why: System-wide architecture cannot be designed top-down with AI. It emerges from the patterns revealed by stakeholder-specific deep dives. AI accelerates each deep dive. The human recognizes the cross-cutting patterns.
Failure mode: Team stays at the macro level, designing the whole system architecture before doing any stakeholder-specific work. AI generates a plausible architecture that misses critical integration points. The architecture is revised repeatedly as stakeholder work reveals reality.
Scope: Steps 5 through 9. Each stakeholder iteration contributes both specific deliverables and system-wide insights.
Every discovery at any step that affects the PRD is written back to the PRD immediately. The human practitioner decides whether the discovery warrants a PRD update. AI proposes the update text.
Why: Discoveries that are not captured are lost. The PRD is the elephant. If the elephant changes shape and nobody updates the record, subsequent bites are cut from the wrong animal.
Failure mode: Step 7 reveals that a stakeholder's workflow is fundamentally different from what was assumed in Step 2. The discovery is noted verbally but not written into the PRD. Step 10 implementation builds on the original (wrong) assumption.
Scope: All steps from 3 onward. The PRD is the living document that absorbs all project learning.
AI functions as a context window manager. Encapsulation, function contracting, and test-driven development patterns from software engineering apply to how AI manages project context across the ten steps.
Why: As projects grow, the full context exceeds what any single human can hold. AI maintains the complete context (PRD, stakeholder map, data model, prototype state, test criteria) and presents relevant slices to the human at each decision point.
Failure mode: Without explicit context management, AI loses track of prior decisions. It generates artifacts that contradict earlier approved work. The human reviewer catches some contradictions but misses others. Inconsistencies compound across steps.
Scope: All steps. The AI's context management role grows in importance as the project accumulates artifacts.
operational heuristics
Feasibility spikes at Step 4 resolve technology uncertainty before committing. AI generates a small, throwaway proof-of-concept for each uncertain technology choice. If the spike fails, the technology is eliminated.
Why: Technology selection based on documentation and AI recommendation alone is unreliable. A 2-hour spike reveals integration problems that no amount of research can predict.
Failure mode: Team selects a database technology based on AI analysis of documentation. The technology has an undocumented limitation that blocks a core use case. Discovered at Step 10. Migration required.
Scope: Step 4. Each uncertain technology choice gets a spike. "Happy with" is the standard, not "optimal."
Implementation proceeds one stakeholder slice at a time (Step 10). Each slice is reviewed by the human practitioner before the next slice begins.
Why: Large-batch implementation accumulates errors that compound. Per-slice review catches integration issues, requirement misunderstandings, and scope drift before they propagate.
Failure mode: Team implements three stakeholder slices without intermediate review. The first slice has a data model error. Slices two and three build on the error. All three require rework.
Scope: Step 10. Each bite gets its own review cycle.
The scientific method applies to business purpose validation. Hypotheses are stated, predictions are made, tests are designed, and results are evaluated against pass/fail criteria. AI generates the test infrastructure. The human defines the hypotheses and evaluates the results.
Why: Without explicit pass/fail criteria, validation becomes subjective. "It seems to work" is not validation. "These three metrics exceeded these three thresholds" is validation.
Failure mode: Team "validates" by showing the prototype to stakeholders and asking "Does this look right?" Stakeholders approve politely. The system fails in production because polite approval is not the same as validated business purpose.
Scope: Step 9. Pass/fail criteria must be defined before validation artifacts are generated.
failure patterns
Skipping stakeholder analysis (Step 2) produces systems that solve the wrong problem for the wrong people.
Why: AI generates convincingly detailed stakeholder analyses from minimal input. If the human does not verify stakeholder identification against reality, the entire project builds on a plausible but incorrect foundation.
Failure mode: AI identifies four stakeholders. A fifth stakeholder (the IT administrator responsible for deployment) is missed. The system has no deployment documentation, no admin interface, and no monitoring. IT blocks the rollout.
Scope: Step 2. Stakeholder identification and needs assessment. Flows downstream to all subsequent steps.
Skipping review gates produces artifacts that look complete but contain undetected errors that compound through subsequent steps.
Why: AI generates coherent output even when the underlying logic is flawed. Without human review, errors pass through as authoritative. Each subsequent step builds on the flawed artifact, amplifying the error.
Failure mode: AI generates a PRD at Step 3 with an ambiguous requirement. No review catches it. Steps 5-10 interpret the ambiguity differently. Implementation contains contradictory behaviors. Discovered in user acceptance testing.
Scope: All five mandatory review gates (Steps 3, 4, 6, 8, 9). The cost of a missed review compounds with each subsequent step.
Treating AI output as authoritative without review produces confirmation bias at scale. AI generates what it predicts you want to see.
Why: AI language models generate plausible, coherent text. Plausibility is not correctness. Without human scrutiny, teams accept AI-generated analyses, evaluations, and validations because they read well, not because they are right.
Failure mode: AI generates a "comprehensive evaluation" at Step 8 that confirms everything is on track. The evaluation reads convincingly. The team proceeds. A critical assumption (market timing) is wrong. The project launches into a market that has shifted.
Scope: All steps where AI generates evaluative or analytical content. Highest risk at Steps 8 and 9.
Attempting to satisfy all stakeholders simultaneously in prototyping produces bloated, compromised designs that satisfy none.
Why: Each stakeholder has different priorities, workflows, and UI preferences. AI averages across stakeholders when given all requirements simultaneously. The averaged output is mediocre for everyone.
Failure mode: AI generates a single prototype serving five stakeholder groups. The UI is crowded with features. No stakeholder can find their primary workflow. All stakeholders request changes. The prototype is scrapped.
Scope: Steps 5 and 10. Single-stakeholder focus at each iteration prevents this failure.
Investing emotional attachment in AI-generated code prevents honest evaluation and necessary pivots.
Why: Even though AI generates code in minutes, humans form attachment to artifacts they have reviewed, refined, and discussed. The sunk cost fallacy applies to attention invested, not just time invested.
Failure mode: Team refines an AI-generated data model over two sessions. New discovery in Step 7 invalidates the model. Team patches the model instead of regenerating from scratch. The patches introduce complexity that degrades the system for its entire lifetime.
Scope: All steps where AI generates code or designs. The zero sunk cost principle must be actively reinforced.
Proceeding past Step 9 (Business Purpose Validation) without clear pass criteria converts validation into a formality that catches nothing.
Why: Step 9 is the final gate before implementation commitment. If pass criteria are vague ("users like it"), the gate provides false assurance. If pass criteria are specific and measurable ("conversion rate exceeds 3% in pilot"), the gate is meaningful.
Failure mode: Team defines success as "positive stakeholder feedback." Stakeholders provide positive feedback because the prototype is shiny. The business purpose (reduce support tickets by 40%) is never tested. Support tickets increase post-launch.
Scope: Step 9. The business purpose confirmation gate.
Using AI to generate the validation criteria for its own output creates a closed loop that cannot detect its own failures.
Why: AI optimizes for coherence. If it generates both the artifact and the test for the artifact, the test will be structurally aligned with the artifact's assumptions. The test passes because it shares the artifact's blind spots.
Failure mode: AI generates a data model and also generates the validation tests for that model. The tests check structural integrity but not domain correctness. The model is structurally sound but misses a business rule. Tests pass. Business rule fails in production.
Scope: Steps 6, 8, and 9. Anywhere AI generates both the work product and its evaluation. Human-defined criteria break the closed loop.
Compare with Another OOS
Search for an organization to compare against.