Mike's Checks
Checks

Mike's Checks/google-gemini-3.8-flash/04 thematic

04 thematic

google-gemini-3.8-flashOpenCodehigh effortrun 9 Sep 202672,905 tokens

Compare models
8/8
checks passed
100%
▸Instructions — the case's current instructions; none were saved with this result

help me synthesize what to focus on in our AI engineering training for this company based on meeting notes with three engineers

Answer

ANSWER.md the model's output · 29.2 KBdownload

AI Engineering Training Synthesis & Curriculum Strategy for Northcove


Executive Summary

Northcove stands at an inflection point. The engineering organization has scaled rapidly to 100 engineers (doubling year-over-year) across three primary silos: Consumer, Business, and Platform. Tooling adoption is already remarkably high: the organization has enterprise licenses for Cursor, engineers have transitioned from "authors" to "editors" (rarely writing more than 20 lines of code manually), and informal sub-communities like #cursor-nerds and #background-agents have emerged.

However, Northcove’s AI adoption is currently hitting a hard organizational ceiling characterized by three critical tensions:

  1. The Monolith Context & "Plausible Bug" Paradox: While engineers use AI for scaffolding, scripts, and rough drafts, they hesitate to use AI on core production features. The codebase is a coupled Python/TypeScript monolith riddled with startup-era technical debt, legacy antipatterns, and stale documentation scattered across Google Docs, Confluence, and Slack. Models hallucinate outdated patterns, and code that looks syntactically plausible introduces subtle logic regressions—an acute risk given Northcove's 20–30 minute CI pipeline and 40 minute to 2 hour deploy cycles.
  2. The "Vibe-Tweaking" Trap in Feature Development: Teams building user-facing AI features (e.g., the document interpretation system) rely on manual, labor-intensive prompt tweaking and hand-labeling (100–250 documents) without systematic evaluation pipelines, regression harnesses, or automated optimization (e.g., DSPy), leading to non-deterministic behavior and fragile iterations.
  3. High Stakes, Regulated Data, and Senior Skepticism: Northcove handles correctness-critical financial business logic (multi-party calculations, invoicing, Stripe, loss-per-transaction metrics) under strict compliance boundaries influenced by past third-party data-sharing incidents. Experienced engineers (4–10 years experience) remain rightfully skeptical of AI code generation in regulated and mission-critical domains without deterministic guardrails.

The Strategic Recommendation

To maximize ROI and move Northcove from "AI-second codegen" to "Systemic, Resilient AI Engineering," the training program must not simply teach basic prompting or tool features. Instead, it must be structured around a Dual-Track Curriculum:

  • Track 1: AI-Augmented Software Engineering (For All 100 Engineers): Context engineering in complex monoliths, rigorous AI-assisted verification and test synthesis (offsetting slow CI/deploy cycles), agentic task delegation (background subagents, CLI-first workflows), and rapid directional prototyping for technical scoping.
  • Track 2: Production AI Systems Engineering (For Engineers Building AI Features): Systematic offline/online evaluation harnesses, moving from manual labeling to automated prompt optimization (DSPy/proxy metrics), handling unstructured document variations, and strict data isolation/compliance patterns.

1. Deep Synthesis of Perspectives Across Interviewees

A comprehensive analysis of the interview notes reveals three distinct archetypes and operational vantage points within Northcove:

Dimension Nina Park (Full-Stack / Product Feature Engineer) Ben Walsh (Senior Business Platform / Power User) Raj (Engineering Leadership / Org Perspective)
Primary Domain Full-stack feature development (TS/Python); document interpretation system; UI/PM collaboration via v0. Correctness-critical business logic (multi-party calculations, Stripe, invoicing, loss metrics); CI/CD & DevX. Org-wide engineering health (100 ICs, Consumer/Business/Platform); deployment infrastructure; governance.
AI Adoption Stage Intermediate / Task-specific: Uses Cursor chat for boilerplate, tests, and debugging; non-power user. Advanced / Power User: "Never rough drafts by hand"; runs background agents; experiments with subagents and DSPy. Org-wide oversight: Cursor enterprise roll-out; observes shift from authoring to editing (<20 lines written manually).
Biggest AI Frustrations Manual evaluation bottleneck (hand-labeling 100–250 docs); prompt drift; over-engineering on complex tasks. Monolithic coupling prevents AI use on production features; brittle MCP servers; bloated planning specs. Stale, siloed tribal knowledge (Confluence/Slack); 20–30m CI / 2h deploy delays; senior developer skepticism.
Verification & Risk Fear of plausible-looking bugs slipping through; lack of robust e2e/integration test safety net. High paranoia around business logic correctness (loss per transaction); need for absolute deterministic accuracy. Severe sensitivity to regulated data leakage (past third-party incident); litigation risks; database migration fears.
Key Aspirations Background agents for long-running incremental feature tasks; automated evaluation for LLM features. Standardized Northcove rules/commands; automated prompt optimization (DSPy); directional visual prototypes. Prescriptive internal standards (.cursorrules); unblocking senior IC meeting overload; safe, compliant workflows.

2. Key Themes & Root Causes Identified

Theme 1: The Context Architecture Gap in a Monolithic Codebase

  • The Symptom: Engineers avoid using AI for complex production features because "if you turn one knob, something else falls down elsewhere." Cursor frequently cherry-picks deprecated patterns from legacy code.
  • The Root Cause: LLMs lack codebase-wide situational awareness unless context is actively structured. Northcove has no standardized system prompts, repository-level .cursorrules, or architectural boundaries exposed to the AI.
  • Training Implication: Training must treat Context Architecture as an Engineering Discipline. Engineers must learn how to construct bounded contexts, utilize explicit tagging (@file, @folder), write modular interface contracts that AI can ingest cleanly, and maintain executable repository rulebooks.

Theme 2: The "Plausible Code" Verification Gap & Deployment Latency

  • The Symptom: AI generates syntactically clean, plausible-looking code that conceals edge-case bugs, silent failures, or financial calculation regressions. Because integration/e2e testing is sparse and CI takes 20–30 minutes (with deploys taking up to 2 hours), catching bugs late in the pipeline is devastating to engineering velocity.
  • The Root Cause: Engineers use AI to generate code without using AI to generate rigorous verification harnesses. The "editor" mindset has led to passive acceptance of plausible output rather than active, test-driven validation.
  • Training Implication: AI training must pivot from code authoring to test-driven verification. Engineers must learn to prompt models for adversarial edge cases, property-based tests, synthetic test vectors for multi-party calculations, and local integration suites before accepting generated code.

Theme 3: The "Vibe-Tweaking" Trap in Production AI Features

  • The Symptom: In feature development (such as the document interpretation pipeline), engineers manually label 100–250 documents, manually evaluate outputs, and iterate via ad-hoc prompt tweaking. A small change to fix one document format breaks three others.
  • The Root Cause: Lack of formal LLM evaluation (evals) methodology. The team is treating LLM engineering like traditional manual QA rather than implementing automated evaluation pipelines, proxy metrics, LLM-as-a-judge harnesses, or programmatic optimization frameworks (such as DSPy).
  • Training Implication: Dedicated training modules on LLM Evaluation, Benchmarking & Systematic Optimization are essential for all engineers working on AI features.

Theme 4: Agentic Workflows & Tool Fragility (CLI vs. MCP)

  • The Symptom: Early attempts to use Model Context Protocol (MCP) for Jira, GitHub, and Confluence suffered from latency and reliability problems. Meanwhile, engineers express strong desire for background agents to handle incremental chores (test coverage, feature flag removal, database migrations).
  • The Root Cause: Over-reliance on heavy, experimental protocols rather than deterministic CLI tooling that models already understand natively.
  • Training Implication: Teach practical, robust agentic workflows: leveraging CLI-first interfaces, deterministic scripts, subagents for scoped background tasks, and structured human-in-the-loop review checkpoints.

Theme 5: Compliance, Regulated Data, and Overcoming Senior Skepticism

  • The Symptom: Senior developers (4–10 years experience) are hesitant to trust AI, particularly given past company trauma around third-party data sharing and strict regulatory/litigation boundaries.
  • The Root Cause: Without explicit corporate guardrails and clarity on what is safe versus unsafe to feed models, experienced engineers default to avoidance—limiting AI to throwaway scripts.
  • Training Implication: Establish and teach clear compliance boundaries: data sanitization, zero-data-retention contracts, local execution patterns for sensitive financial logic, and safe patterns for database migration planning.

3. Core Training Pillars & Focus Areas

Based on Northcove’s specific architecture, tooling, and organizational challenges, the training program must center around five core pillars:

┌────────────────────────────────────────────────────────────────────────┐
│                   NORTHCOVE AI ENGINEERING CURRICULUM                  │
├───────────────────────────────────┬────────────────────────────────────┤
│ TRACK 1: AI-AUGMENTED SOFTWARE    │ TRACK 2: PRODUCTION AI SYSTEMS     │
│          ENGINEERING (All 100 ICs)│          ENGINEERING (Feature Eng) │
├───────────────────────────────────┼────────────────────────────────────┤
│ 1. Context Engineering & Monolith │ 4. Systematic LLM Evaluation &     │
│    Navigation                     │    Benchmarking (Evals)            │
│ 2. Test Synthesis, Verification & │ 5. Programmatic Optimization       │
│    Regression Guardrails          │    (DSPy, Structured Outputs)      │
│ 3. Agentic Workflows & Background │ 6. Compliance, Data Isolation &    │
│    Delegation (CLI-First)         │    Deterministic Wrappers          │
└───────────────────────────────────┴────────────────────────────────────┘

Pillar 1: Context Engineering & Monolith Navigation

  • Objective: Eliminate hallucinations and legacy anti-pattern propagation in Northcove's Python/TypeScript monolith.
  • Core Topics:
    • Constructing and maintaining hierarchical .cursorrules (global, directory-level, and domain-specific rules).
    • Effective context window hygiene: explicit tagging (@file, @symbol), slicing relevant interfaces, and excluding legacy/deprecated modules.
    • Creating lightweight "Context Manifests" for complex domains (e.g., transaction lifecycles, invoicing, Stripe state machines) that can be loaded on demand.
    • Transforming stale Confluence/Google Docs knowledge into living, machine-readable repo specs (docs/ai-context/).

Pillar 2: AI-Assisted Verification & Test Synthesis

  • Objective: Prevent plausible but buggy code from entering the 20–30m CI and 40m–2h deploy pipeline; restore trust for senior engineers.
  • Core Topics:
    • Test-Driven Generation (TDG): Prompting the model to write adversarial, boundary-condition, and property-based test suites before generating implementation logic.
    • Local regression prevention: Using AI to mock complex multi-party calculation states and Stripe webhooks.
    • Synthesizing integration and end-to-end tests for legacy flows lacking coverage.
    • Guardrails against common LLM hallucinations in Python (e.g., subtle mutability bugs, type coercion, async/await edge cases) and TypeScript (e.g., unsound type assertions).

Pillar 3: Agentic Workflows & CLI-First Automation

  • Objective: Move from synchronous back-and-forth chat to autonomous, reliable background execution for tedious engineering chores.
  • Core Topics:
    • Background task delegation: Setting up autonomous tasks for dead-code pruning, feature flag cleanup, documentation generation, and unit test expansion.
    • Tool-use strategy: Why CLI tools outperform brittle MCP servers in existing training sets, and how to build lightweight CLI wrappers for internal Northcove tools.
    • Scoping subagents: Defining constrained boundary conditions, acceptance criteria, and rollback scripts for autonomous agents.
    • AI-assisted migration planning: Generating safe, multi-step database migration scripts with explicit rollback steps.

Pillar 4: Production AI Systems Engineering & Systematic Evals

  • Objective: Replace manual prompt tweaking and 100–250 hand-labeled document reviews with rigorous ML engineering practices.
  • Core Topics:
    • Building automated offline evaluation harnesses: ground truth curation, dataset stratification, and programmatic assertion checks.
    • Developing effective proxy metrics and LLM-as-a-Judge validation pipelines with calibration.
    • Handling non-deterministic model drift across updates: measuring regression rates across diverse document layouts and non-standard terminology.
    • Automated prompt optimization: Practical introduction to DSPy (Declarative Self-improving Python) to compile and optimize prompt signatures automatically against metric thresholds.

Pillar 5: Safe AI, Compliance & High-Stakes Logic

  • Objective: Protect Northcove from legal, financial, and compliance exposure while building confidence in regulated business domains.
  • Core Topics:
    • Data isolation architectures: Operating safely under enterprise data privacy contracts (Anthropic/OpenAI) and preventing PII/financial data leakage.
    • Deterministic wrappers: Why pure business calculations (multi-party calculations, invoicing, loss metrics) must remain deterministic code, using AI only for orchestration, parsing, and interface mapping.
    • Automated sanitization: Scrubbing user-uploaded documents and production payloads before passing them to LLM context windows.

4. Structured Curriculum & Syllabus

The training should be delivered across four modular tiers to accommodate all experience levels, from junior full-stack developers to senior platform architects.

┌─────────────────────────────────────────────────────────────────────────┐
│                    CURRICULUM ARCHITECTURE & TRACKS                     │
├─────────────────────────────────────────────────────────────────────────┤
│ TIER 1: Foundations of AI-Assisted Engineering (All 100 Engineers)      │
│         Duration: 2 Half-Days | Hands-on Labs in Monolith Codebase      │
├─────────────────────────────────────────────────────────────────────────┤
│ TIER 2: Advanced Context, Agentic Chores & DevX (Senior ICs & Leads)   │
│         Duration: 1 Full Day | CLI Agents, .cursorrules, Tech Specs     │
├─────────────────────────────────────────────────────────────────────────┤
│ TIER 3: Production AI & LLM Systems Engineering (Feature Engineers)     │
│         Duration: 2 Full Days | Evals, DSPy, Document Ingestion, Guard  │
├─────────────────────────────────────────────────────────────────────────┤
│ TIER 4: AI-Assisted Scoping & Technical Architecture (Leads & PMs)      │
│         Duration: Half-Day Workshop | Directional Prototyping, v0, Specs│
└─────────────────────────────────────────────────────────────────────────┘

Tier 1: Foundations of AI-Assisted Engineering

  • Audience: All 100 Northcove engineers (Consumer, Business, Platform).
  • Format: Two 4-hour interactive workshops with live coding in Northcove’s stack.
Module 1.1: Modern Context Engineering in Northcove's Monolith
  • Dissecting the Cursor context engine: How symbols, indexing, and @ references work.
  • Navigating legacy antipatterns: Explicitly instructing models to ignore legacy Python patterns in favor of modern team standards.
  • Writing modular .cursorrules: Creating folder-scoped rules (e.g., services/billing/.cursorrules vs. frontend/components/.cursorrules).
  • Hands-on Lab: Refactoring a coupled monolithic module by providing AI with an explicit interface boundary and curated context.
Module 1.2: Adversarial Verification & Test-First Codegen
  • The "Trust but Verify" workflow: Why plausibility is the enemy of correctness.
  • Generating comprehensive test matrices: Edge cases, null states, boundary conditions, and mock API failures.
  • AI-assisted debugging: Feeding Python stack traces, TypeScript compiler outputs, and failing tests to Cursor for root-cause diagnosis.
  • Hands-on Lab: Given a buggy financial calculation module, prompt the AI to discover the edge case, write a reproducing unit test, and generate the minimal correct fix without side effects.

Tier 2: Advanced Context, Agentic Chores & DevX

  • Audience: Senior Software Engineers, Platform Engineers, and DevX Enthusiasts (e.g., Ben Walsh and peers).
  • Format: One 6-hour intensive workshop.
Module 2.1: Background Agents & Scoped Autonomous Delegation
  • Designing tasks for background agents: Feature flag removal, dead code elimination, and upgrading framework dependencies.
  • Subagent patterns: Breaking monolithic tasks into discrete planning, execution, and verification steps.
  • Guarding agent execution: Setting up deterministic git branch workflows, pre-commit validation checks, and automatic test runs for agent PRs.
  • Hands-on Lab: Build an automated agent script to identify, remove an expired feature flag across frontend and backend, and update the associated test suite cleanly.
Module 2.2: CLI-First Tooling vs. Fragile MCP
  • Why MCP struggled at Northcove (network overhead, schema bloat, context saturation) and when to use CLI instead.
  • Wrapping Northcove's internal APIs, database queries, and deployment commands into CLI tools that LLMs invoke natively.
  • Developing custom terminal-based workflows for local environment diagnostics and AWS spend analysis.
  • Hands-on Lab: Create a lightweight CLI helper that lets Cursor safely query local database schemas without exposing production customer data.

Tier 3: Production AI & LLM Systems Engineering

  • Audience: Feature developers, AI engineers, and full-stack engineers building customer-facing AI capabilities (e.g., Nina Park, document processing teams).
  • Format: Two full-day intensive sessions (with a 1-week break for project implementation).
Module 3.1: Escaping Vibe-Tweaking: Enterprise Evals & Benchmarks
  • The LLM Evaluation hierarchy: Unit-level assertions, proxy metrics, semantic similarity, and calibrated LLM-as-a-Judge.
  • Building a continuous evaluation pipeline: Integrating evals into GitHub CI alongside standard tests.
  • Ground truth curation: Strategies for synthetic data generation to augment 100–250 hand-labeled documents into a 2,000-sample test suite.
  • Measuring prompt drift and non-determinism across Anthropic model updates.
  • Hands-on Lab: Take Northcove’s document interpretation system and build an automated test harness that scores extraction accuracy across 10 distinct document layouts using proxy metrics and exact-match schema validation.
Module 3.2: Automated Prompt Optimization with DSPy
  • Introduction to DSPy: Moving from prompt strings to declarative signatures and teleprompters.
  • Compiling prompts against concrete metric thresholds (e.g., accuracy, token cost, latency).
  • Handling non-standard layouts and ambiguous terminology programmatically without manual prompt rewriting.
  • Hands-on Lab: Implement a DSPy teleprompter on the document parsing pipeline to optimize few-shot example selection and instructions automatically.
Module 3.3: Production Guardrails, Data Isolation & Compliance
  • Implementing zero-data-retention and organizational data isolation boundaries in code.
  • PII and financial data redaction filters prior to model ingestion.
  • Structured outputs and deterministic validation: Enforcing Pydantic / Zod schemas with retry loops and graceful degradation.
  • Hands-on Lab: Construct a secure document ingestion gateway that validates compliance, scrubs sensitive data, extracts structured JSON, and verifies schema conformance.

Tier 4: AI-Assisted Scoping & Technical Architecture

  • Audience: Tech Leads, Staff Engineers, and Product Managers (e.g., Raj, Ben, PM partners).
  • Format: Half-day strategy workshop.
Module 4.1: Directional Prototyping & Spec Streamlining
  • The "Directionally Correct" planning philosophy: Using rapid visual prototypes (v0 / Cursor) during quarterly planning instead of 20-page bloated specs.
  • Transforming PRD scoping from a multi-day ops/marketing back-and-forth into rapid interactive spikes.
  • De-risking technical alignment: Using AI to surface architectural risks, monolith dependencies, and migration hurdles during the planning phase.
  • Alleviating senior IC meeting fatigue through asynchronous AI-generated technical summaries and PR reviews.
  • Hands-on Lab: Take an ambiguous product feature requirement and, within 45 minutes, produce a functional v0 interactive prototype, a concise 1-page technical spec, and a risk matrix of monolith touchpoints.

5. Organizational Rollout & Change Management Strategy

To ensure training translates into sustained operational capability across 100 engineers, Northcove should adopt a structured four-stage rollout:

┌─────────────────────────────────────────────────────────────────────────┐
│                     TRAINING ROLLOUT ROADMAP                            │
├───────────────┬─────────────────┬──────────────────┬────────────────────┤
│ WEEKS 1–2     │ WEEKS 3–4       │ WEEKS 5–6        │ WEEKS 7+           │
│ Foundations & │ Tier 1 Rollout  │ Tier 2 & 3       │ Org Embedding &    │
│ Artifact Kits │ (All 100 ICs)   │ Specializations  │ Continuous Evals   │
├───────────────┼─────────────────┼──────────────────┼────────────────────┤
│ • .cursorrules│ • 2-day cohort  │ • Power users    │ • Eval gates in CI │
│   repo kit    │   workshops     │   (Tier 2)       │ • Bi-weekly show & │
│ • CLI toolset │ • Monolith lab  │ • AI feature     │   tell             │
│ • Compliance  │   exercises     │   teams (Tier 3) │ • Quarterly hack   │
│   cheatsheet  │ • Async Slack   │ • Spec workshop  │   days for chore   │
│               │   support       │   (Tier 4)       │   agents           │
└───────────────┴─────────────────┴──────────────────┴────────────────────┘

1. Pre-Training Standardization: The Northcove "Starter Kit"

Before convening classroom sessions, seed the engineering environment with standardized, production-ready configurations:

  • Enterprise .cursorrules Library: Pre-populate the monolith with standard rules enforcing Python type hinting, TypeScript strictness, forbidden legacy libraries, and testing conventions.
  • Curated CLI Tooling Registry: Provide pre-approved, model-friendly CLI commands for local database inspection, schema querying, and CI pipeline checks.
  • Compliance Playbook: A clear, 1-page matrix detailing what data can touch Anthropic/OpenAI APIs (with isolation contracts) versus what must remain on isolated internal infrastructure.

2. Addressing Senior Developer Skepticism

Experienced engineers (4–10 years experience) resist AI because they fear low-quality code, unmaintained technical debt, and compliance breaches. Win them over by:

  • Framing AI as an "Adversarial Reviewer and Test Harness" rather than a code generator. Senior engineers value AI when it finds obscure edge cases in their architecture, generates tedious integration mocks, or documents legacy code.
  • Highlighting Chore Automation: Demonstrating how background agents eliminate tedious work they dislike (e.g., feature flag removal, dependency upgrades, repetitive boilerplate).
  • Empowering Them as Rule Creators: Inviting senior engineers to author the architectural rules and boundary constraints that guide Cursor across the entire 100-person organization.

3. Mitigating the Deployment & CI Feedback Loop

With a 20–30 minute CI run and 40m–2h deployment pipeline, Northcove cannot afford broken builds caused by unchecked AI commits.

  • Mandate Local Pre-Flight AI Verification: Teach engineers to prompt Cursor to run local pytest/typecheck commands and self-heal before pushing to GitHub.
  • Implement "Agent-Specific CI Lanes": For chore-automation PRs (e.g., test generation, dead code removal), establish automated test suites that run in lightweight parallel runners.

4. Institutionalizing Knowledge Sharing

  • Consolidate Channels: Formally recognize and sponsor #cursor-nerds and #background-agents, establishing a weekly "Prompt & Agent of the Week" showcase.
  • Living Recipe Catalog: Maintain an internal ai-recipes/ directory in the repository containing proven prompt templates for Northcove-specific tasks (e.g., creating a new Stripe billing endpoint, writing an integration test for multi-party calculations).

6. Key Assumptions & Boundary Conditions

In formulating this synthesis and training curriculum, the following reasonable assumptions were made based on the provided notes:

  1. Stack & Architecture: Northcove operates a unified monolithic repository with a Python backend (likely FastAPI or Django/Flask) and a TypeScript frontend (likely React/Next.js), with PostgreSQL and Stripe for billing.
  2. AI Tooling Licensing: The engineering org has active Cursor Enterprise licenses and approved enterprise access to Anthropic Claude models with zero-data-retention (ZDR) and organizational data isolation contracts in place.
  3. Engineering Roles & Silos: While engineers belong to Consumer, Business, or Platform silos, all engineers touch the core monolithic codebase or share shared platform infrastructure, making a standardized context/rule strategy broadly applicable.
  4. Compliance Context: The prior third-party data incident involved client-side tracking or external vendor data exposure on web surfaces; hence, legal and compliance teams maintain strict oversight over any technology that transmits user or financial data.
  5. Team Readiness: The transition from "code author" to "code editor" is already culturally established; the training does not need to cover basic Cursor setup, but must focus on rigor, context curation, background automation, and ML engineering.

7. Immediate Next Steps & Deliverables Checklist

To initiate this program immediately, the following deliverables should be prioritized:

  • Publish Northcove .cursorrules v1.0: Root-level and service-level rules establishing coding standards, test requirements, and legacy file exclusions.
  • Deploy Initial Document Eval Suite: Stand up an automated evaluation script for Nina’s team using 50 representative document schemas to replace manual prompt tweaking.
  • Pilot Tier 1 with Business Group: Run a 4-hour pilot of Module 1.1 & 1.2 with Ben Walsh’s team to validate the exercises against complex multi-party business logic.
  • Establish "AI Office Hours": Weekly 30-minute troubleshooting sessions hosted by internal power users to help engineers debug their prompt contexts and agent workflows.

Checks

8/8
Script checks 3/3answered by a program
pass

No AI-tell wordingai-wordingevery task

deliverable text contains none of the shared AI-tell phrases in bench/ai-tells.txt. Task checks may add narrower contractual bans, but must not repeat this shared floor.

inspected context.md, ANSWER.md

pass

Analysis existsexiststhis task

a synthesis document of >= 100 words was produced

pass

Theme counttheme-countthis task

it groups its findings into at least 3 themes. FAIL when no theme structure can be parsed out of it at all -- see the ladder in pick_themes for what counts as one.

Judge checks 5/5judged by Claude
pass

Q1Enough depth to teachthis task

Judge's reasoning

Each of the five pillars (context engineering in the monolith, AI-assisted verification/test synthesis, agentic + CLI-first workflows, LLM evals/DSPy optimization, compliance & data isolation) is specified with concrete sub-topics, durations and hands-on labs — e.g. Module 3.1's harness scoring extraction accuracy across 10 document layouts, or Module 2.1's feature-flag-removal agent — so each could carry a real session rather than surviving as a heading.

▸Rubric

Every theme is deep enough to teach. Mike's bar: "these are actually topics that you could do a whole training on." FAIL if any single theme is a pleasant-sounding course name that is not really a real topic — a label you could not build a session's worth of exercises, demos and decisions around. Ask of each theme literally: what would you actually teach in that session, and for how long? A theme that survives only as a heading fails.

pass

Q2Goes beyond repetitionthis task

Judge's reasoning

Phrases from the notes are converted into substantive material rather than echoed: Ben's "context is king" becomes folder-scoped .cursorrules, context manifests for the transaction/Stripe domain and turning stale Confluence docs into repo specs; Nina's manual labeling becomes eval harnesses, proxy metrics, LLM-as-judge calibration and DSPy teleprompters. Even the thinnest candidate (directional prototyping) is scoped to a half-day with a concrete 45-minute prototype/spec/risk-matrix exercise.

▸Rubric

No shallow echo. FAIL if any theme "just repeats a theme it heard in the document without thinking about whether there's enough material there for a training." Mike's canonical fail is a theme like "how to build your company context" — "Okay, but that's like... What would you actually teach there, right? There's not that much to teach that is universal." Restating a phrase from the notes ("context is king", "documentation is stale", "AI-first workflow") as a theme title, without the output having done the work of asking whether there is enough substance behind it for a training, is a FAIL. Note that the underlying subject can be legitimate — "context engineering" is a good topic — so judge the treatment, not just the words.

pass

Q3Supported by the interviewsthis task

Judge's reasoning

Every pillar traces to specific interview material — monolith coupling and "turn one knob" (Ben), plausible-looking bugs and missing e2e tests (Nina), 100–250 hand-labeled docs and non-determinism (Nina), MCP failures on Confluence/Jira/GitHub vs CLI preference (Ben), regulated-data exposure, the prior third-party data-sharing incident and senior skepticism (Raj). Speculative details (FastAPI, Postgres, ZDR) are quarantined in an explicit assumptions section rather than smuggled in as claims about Northcove.

▸Rubric

Every theme is grounded in what the three engineers said. FAIL if any theme cannot be traced to specific material in `context.md` — a generic AI-training theme bolted on that the interviews do not support, or a claim about Northcove that no engineer made. Being a good idea in general is not grounding.

pass

Q4Uses all three interviewsthis task

Judge's reasoning

All three engineers visibly shape the set: Nina drives the evals/verification track, Ben drives agentic delegation, CLI-vs-MCP and directional prototyping for planning, and Raj drives the compliance/regulated-data pillar plus the org-scale framing (100 engineers, three silos, CI/deploy latency, senior skepticism). The comparison table and the per-theme symptom lines make the three altitudes distinct rather than one interview restated.

▸Rubric

The synthesis uses all three interviews. FAIL if the themes are effectively a summary of one engineer's interview, with the other two contributing nothing distinct. Nina, Ben and Raj sit at different altitudes (hands-on feature work, power-user workflows, org-wide constraints) and the synthesis should show it. This does not require every theme to cite all three — it requires that all three engineers visibly shaped the set.

pass

Q5Clear prioritiesthis task

Judge's reasoning

It is differentiated, not flat: three "critical tensions" are named as the binding constraints, a dual-track split separates what all 100 engineers need from what AI-feature teams need, and the tiering (context + verification first for everyone, specialization later) plus the weeks 1–7 rollout and the pilot-with-Ben's-team next step encode what to do first. Emphasis and urgency reasoning are explicit rather than an equally-weighted topic list.

▸Rubric

It is a set of priorities, not a catalogue. FAIL if the output lists themes without any signal about what matters most for this company — no ordering, no emphasis, no reasoning about which gaps are urgent. A flat, undifferentiated list of equally-weighted topics fails; the ask was "what to focus on."