04 thematic

What Northcove should focus on in AI engineering training

Focus the training on making AI-assisted work reliable in Northcove’s Python/TypeScript monolith: supplying context, scoping changes, and verifying results. Engineers already have access to Cursor and use it for useful work. The next gain is helping them complete more consequential tasks with less back-and-forth and a clear basis for trusting the result.

This synthesis uses the three interviews in context.md. Assumption: the primary audience is software engineers, with mixed levels of AI experience; training duration has not been set. The proposed format below is a starting point. Three interviews provide directional evidence, not an organization-wide assessment.

What the interviews collectively tell us

• Company-specific context is the clearest shared bottleneck. Nina sees AI copy inappropriate legacy patterns; Ben cannot convey hidden coupling and side effects; Raj says Northcove-specific implementations require prescriptive rules. Generic prompting advice will have limited value without exercises grounded in the actual codebase.
• Confidence in correctness limits delegation. Nina worries about plausible code and weak integration coverage. Ben uses AI extensively but avoids much production feature coding in correctness-critical business logic. Raj is skeptical of significant features, migrations, and regulated-data work. Training should make verification a repeatable part of the workflow.
• Adoption is uneven, and usage is different from trust. Raj describes engineers as editors who rarely write much code manually; Ben describes much of engineering as “AI-second”; Nina considers herself a basic user. These accounts may reflect different teams and tasks. Avoid designing for either universal beginners or universal power users.
• Some constraints require organizational work. Stale documentation, hidden coupling, testing gaps, and infrastructure problems will persist after a workshop. Training can establish useful habits and reusable artifacts, but owners must maintain them.

Recommended priorities, in order

How to run it

Use two core workshops, followed by optional clinics. Most time should go to hands-on work and review.

1. Core workshop 1: context and trustworthy changes. Briefly establish a shared workflow, then work through priorities 1 and 2 on a representative repository task. Pair engineers across experience levels. Experienced users can tackle hidden dependencies and stronger verification while newer users practice file selection and incremental edits.
2. Core workshop 2: delegation and planning. Work through priorities 3 and 4. Each participant delegates a bounded task and reviews another participant’s output against its acceptance criteria. Include a short brief or prototype exercise that helps clarify an engineering decision.
3. Optional clinics: background agents/subagents for engineers ready to extend delegation; evaluation and prompt optimization for engineers building LLM features. Establish a credible evaluation baseline before optimizing prompts.

Ask Northcove to supply a sanitized repository example, a known-good implementation pattern, and its approved tool/data-handling guidance before delivery. Integrate that guidance into exercises involving customer data, database access, and external tools. Do not infer company policy from these interviews.

Ben’s tolerance for directionally correct prototypes is useful for exploration. For production changes, particularly calculations and regulated-data workflows, exercises must require explicit correctness evidence. Account for the reported slow CI/deploy cycle by teaching focused local checks followed by the required integration and CI checks.

What participants should leave with

• A reusable task brief covering goal, relevant context, constraints, acceptance criteria, and verification.
• A small set of reviewed Northcove-specific repository instructions, with owners and a maintenance process.
• A delegation template covering scope, stop conditions, and required handoff evidence.
• One completed, reviewed example showing how to move from investigation to a validated change.

Consolidate these artifacts in one discoverable home. Northcove should separately assign ownership for keeping documentation and approved examples current, and for addressing the testing gaps the exercises expose.

What to de-emphasize

Keep generic AI introductions brief. Avoid making broad tool tours, MCP configuration, or autonomous large-feature demonstrations central to the course: these do not address the strongest shared blockers. Defer company-wide knowledge search and BI integration to separately scoped initiatives. PRD generation and automated user research also have weaker support in these interviews than engineering context, verification, and delegation.

How to judge whether it worked

Capture a baseline on comparable tasks, then review outcomes after two to four weeks: time to an accepted change including review and rework; correction cycles; defects or regressions; and whether reusable instructions remain useful and current. Inspect a small sample of completed tasks for acceptance criteria and verification evidence. For the LLM-feature track, assess held-out task accuracy and important error categories, with proxy metrics alongside them.

The success criterion is that engineers can complete an appropriate task with less supervision and demonstrate why the result is correct. More generated code or more agent usage alone would not establish that.