What does a 12-week plan for building engineering judgment with AI look like?

Scope

This plan is for a developer who can build and test small programs and wants structured practice in engineering decisions. Use a sandbox repository and disposable environment. A mentor can improve feedback, but every week still produces artifacts that make self-review possible.

Why it happens

Unstructured practice follows available tickets. The developer sees many tasks but may never isolate one judgment: interpreting an outcome, designing an invariant, choosing a retry boundary, or evaluating a risky release. AI increases throughput and can further reduce time spent predicting and debugging.

A curriculum should vary the object of judgment while repeating the learning loop. It should also test transfer, because performing a rehearsed example with AI present can overstate independent capability.

Diagnosis

Before week one, run a baseline task: integrate a small API with delayed completion and one injected failure. Write predictions, design notes, tests, incident diagnosis, and a release decision. Score the artifacts for explicit constraints, evidence, alternatives, failure handling, and unsupported assumptions.

Keep the baseline. Repeat a structurally similar but unfamiliar task in week twelve without AI during the first pass. Improvement should appear in the reasoning and recovery artifacts, not only in faster coding.

Solution

Use four phases:

• Weeks 1–3, observe: predict code and API behavior, distinguish response from outcome, and retrieve official documentation from memory and search.
• Weeks 4–6, control: model state, idempotency, retries, deadlines, permissions, and failure recovery.
• Weeks 7–9, decide: compare architecture alternatives, write quality scenarios, analyze incidents, and review evidence under uncertainty.
• Weeks 10–12, transfer: run a small production-like release, critique an AI-generated design, and complete a changed capstone with reduced assistance.

Every session uses the same loop: prediction, implementation, fault, observation, mechanism, decision, feedback, and transfer question. Rotate AI among tutor, critic, and reviewer roles. At least one weekly check is unassisted.

Artifact

Build a question bank with one row per week:

Week	Decision focus	Failure drill	Required artifact	Transfer change
1	Predict runtime behavior	Boundary input	Prediction ledger	New language/runtime
2	Read an API contract	Ambiguous 2xx	Outcome state model	Async provider
3	Test an assumption	Stale read	Evidence map	Different consistency
4	Model state	Crash/restart	State machine	New persistence layer
5	Control retries	Post-commit timeout	Retry budget	Layered client
6	Bound authority	Expired approval	Permission matrix	Different target
7	Choose architecture	Dependency failure	Constraint matrix	Changed team/scale
8	Diagnose incident	Missing telemetry	Hypothesis ledger	Different symptom
9	Review AI code	Hidden invariant	Review rubric	Unfamiliar repository
10	Plan a release	Bad canary slice	Gate record	New risk tier
11	Operate and recover	Rollback residue	Incident packet	Partial compensation
12	Capstone transfer	Combined faults	Decision portfolio	No AI first pass

Score prediction calibration, evidence quality, mechanism explanation, safe recovery, and transfer. Add one targeted practice item for the weakest dimension.

Common mistakes

• Treating the table as reading topics instead of executable practice.
• Letting AI reveal the failure before the learner predicts it.
• Repeating the same tool and context until performance becomes memorization.
• Scoring only whether the final code passes happy-path tests.
• Running failure drills against shared or production resources.