The viable model is probably not “hire expensive senior engineers to lecture full-time.” Lecturing is a poor use of them.
Instead:
- AI handles explanation, drills, routine code review, test generation, and individualized feedback.
- Students learn in teams by operating realistic systems.
- Senior engineers design scenarios, calibrate evaluations, conduct periodic reviews, and intervene at important moments.
- The curriculum captures each expert intervention so it becomes reusable.
- Customers or partner organizations supply bounded, noncritical projects and possibly pay for delivery or recruiting access.
The scarce instructor becomes more like the designer and supervisor of a flight simulator. One strong engineer might oversee several cohorts if the environment makes student progress legible and escalates only ambiguous cases.
The central principle should be:
Do not teach students to produce code. Teach them to acquire justified confidence in systems they are responsible for.
Curriculum goal
A graduate should be able to take an ambiguous request and:
- Discover what actually needs to be built.
- Model the domain and identify important constraints.
- Direct AI tools without surrendering understanding.
- Evaluate generated work adversarially.
- Deploy and operate a system.
- Diagnose failures under uncertainty.
- Communicate tradeoffs to technical and nontechnical people.
- Improve the performance of teammates.
- Know when to escalate.
- Produce evidence supporting their claims.
The final credential should mean something like:
This person has repeatedly owned services, handled incidents, found flaws that automated evaluations missed, and made defensible engineering decisions.
A six-month apprenticeship
A possible structure is 24 weeks, with teams of four to six. Each team operates one evolving business system rather than completing unrelated toy assignments.
There could be several domains:
- Scheduling, calendars, and workforce management
- Point of sale, inventory, and purchasing
- Insurance claims processing
- Logistics and delivery routing
- Subscription billing
- Laboratory sample tracking
- Property management
- Municipal permitting
The domain should be mundane but deceptively difficult. Mundane systems contain identity, money, time, authorization, concurrency, compliance, and human exceptions—the material of real engineering.
Phase 0: Diagnostic and foundations — 2 weeks
Students inherit a small but functioning service.
They must:
- Run it locally
- Explain its architecture
- Trace several requests through it
- Fix a few bugs
- Add an observable feature
- Identify a security flaw
- Deploy a change safely
The purpose is not to normalize everyone’s language or framework knowledge. AI can help with that. It is to establish how each student reasons.
Initial exercises might include:
- Predict the output before running the code.
- Find a bug without asking AI for a solution.
- Compare a human diagnosis with an agent diagnosis.
- Explain why a passing test does not establish correctness.
- Recover from a deliberately broken deployment.
- Identify which credentials and data an agent should be allowed to access.
Each student gets a skill map covering:
- Code comprehension
- System modeling
- Debugging
- Testing
- Security
- Operations
- Product reasoning
- Communication
- AI supervision
Phase 1: Build the naïve version — 3 weeks
Give teams a deliberately underspecified request:
Build appointment scheduling for a small network of clinics.
The obvious product appears straightforward: users, calendars, appointments, notifications. Students interview simulated stakeholders, played primarily by AI personas grounded in a consistent private scenario.
Different stakeholders reveal conflicting requirements:
- Patients want easy cancellation.
- Clinicians have variable appointment durations.
- Administrators want high utilization.
- Compliance staff restrict sensitive information in notifications.
- Some appointments need rooms and equipment.
- Recurring availability crosses daylight-saving changes.
- Minors and guardians complicate identity and consent.
- The billing system recognizes different appointment states.
The team must produce:
- A domain model
- User journeys
- Explicit assumptions
- A threat model
- Service-level objectives
- Architecture and build-versus-buy decisions
- An initial implementation
- A deployment and rollback plan
The AI does not merely answer questions. It tracks contradictions, withholds information that was not requested, and behaves like real stakeholders. Students are evaluated partly on the questions they thought to ask.
Phase 2: Reality attacks the design — 4 weeks
Once the system works, the simulator introduces change:
- Two users book the final slot simultaneously.
- A clinic operates in multiple time zones.
- A clinician leaves while future appointments remain.
- Notifications are delayed and sent out of order.
- A vendor API becomes intermittently unavailable.
- A user requests deletion of personal data.
- One enterprise customer needs custom permissions.
- Traffic increases by 30× during enrollment.
- A product manager requests a feature that conflicts with an invariant.
Students must adapt the system while preserving service. This teaches that architecture is not a diagram produced before implementation; it is the set of decisions that determine the cost of change.
Important exercises include:
- State-machine modeling
- Idempotency
- Transactions and concurrency
- Queues and eventual consistency
- Schema migration
- Compatibility
- Capacity estimation
- Caching and invalidation
- Authorization
- Auditability
AI-generated tests help, but the key task is identifying which properties ought to be tested.
For scheduling, important properties might include:
- A resource cannot be allocated incompatibly to two appointments.
- Retries cannot create duplicate appointments.
- A canceled appointment cannot remain billable accidentally.
- Authorization is evaluated at access time, not inferred from the UI.
- Time-zone conversion preserves the user’s intended local-time semantics.
- Every externally visible state transition has an audit trail.
Students should write these invariants before asking an AI to generate concrete cases.
Phase 3: Operations and incidents — 4 weeks
Teams now operate their systems under a simulated production workload.
Incidents arrive without labels:
- Latency slowly increases.
- A dependency returns valid-looking but incorrect responses.
- A deployment corrupts a subset of records.
- Metrics look normal while customers report failures.
- A credential appears in a log.
- A malicious calendar invitation triggers an agent action.
- An alert fires but is unrelated to the actual problem.
- A retry storm overloads a downstream service.
Students rotate through roles:
- Incident commander
- Operations lead
- Investigator
- Communications lead
- Subject-matter liaison
- Observer who later analyzes team performance
They are evaluated on whether they:
- Establish impact before guessing at causes
- Preserve evidence
- Avoid making the incident worse
- Communicate uncertainty honestly
- Use rollback and containment appropriately
- Keep a chronological decision log
- Separate correlation from causation
- Produce effective corrective actions afterward
The simulator can accelerate time. A week of operational history can unfold in an hour; a supposedly fixed issue can recur “three months later” if the team treated only the symptom.
A human instructor should attend some incident exercises because team behavior, fixation, confidence, and communication are difficult to score entirely from outputs.
Phase 4: Security and adversarial use — 3 weeks
Students attack another team’s system and defend their own.
Topics include:
- Authentication versus authorization
- Tenant isolation
- Credential management
- Injection vulnerabilities
- Dependency and build-chain compromise
- Data exfiltration
- Abuse prevention
- Fraud and synthetic identities
- Agent prompt injection
- Least-privilege tool use
- Audit logs and repudiation
- Privacy and data retention
An especially useful format is an asymmetric exercise:
- The attackers receive a business goal, such as obtaining inventory without payment.
- Defenders receive normal operational responsibilities and incomplete alerts.
- The product team must decide which controls are acceptable without making the product unusable.
- Auditors later reconstruct what happened.
For a point-of-sale project, attacks might exploit:
- Refund permissions
- Coupon stacking
- Race conditions in inventory reservation
- Offline transaction reconciliation
- Barcode substitution
- Compromised employee accounts
- Malicious supplier data read by a purchasing agent
Security becomes a property of an operating organization, not a checklist run at the end.
Phase 5: Legacy takeover — 3 weeks
Building a greenfield application is too flattering. Each team should inherit another team’s system—or a deliberately realistic legacy system—with:
- Sparse and misleading documentation
- Weak tests
- Historical database irregularities
- Dead feature flags
- An undocumented batch process
- A fragile external integration
- A stakeholder who opposes a rewrite for good reasons
Their assignment is not “clean it up.” It is a business change such as:
Add support for stores that can sell inventory belonging to another legal entity without interrupting current operations.
Students must discover the system, decide where to trust it, characterize behavior, and migrate safely.
This phase teaches:
- Software archaeology
- Characterization testing
- Incremental replacement
- Data migration
- Observability retrofitting
- Compatibility strategy
- Deciding when not to refactor
- Working with uncertainty
A particularly important exercise would be to have an AI confidently propose a plausible but destructive rewrite. Students should be rewarded for refusing it and gathering more evidence.
Phase 6: Product and economics — 2 weeks
Many engineering failures are correct implementations of bad ideas.
Teams receive requests with hidden economic and organizational consequences:
- A dashboard that encourages employees to manipulate a metric
- A recommendation feature whose success metric creates spam
- A scheduling optimization that maximizes utilization but causes burnout
- Inventory automation that reduces working capital while making stockouts catastrophic
- A customer-specific feature whose maintenance cost exceeds its revenue
Students must estimate:
- Who benefits
- Who bears the risk
- Expected implementation and operating costs
- Reversibility
- Failure costs
- Support burden
- Which metric could be gamed
- Whether software is the right intervention
They should sometimes recommend not building the feature. A curriculum that never rewards refusal teaches compliance, not judgment.
Phase 7: Technical leadership and mentoring — 2 weeks
Each student mentors a newer participant or an AI-simulated junior through a bounded task.
They practice:
- Diagnosing another person’s mental model
- Asking questions rather than taking over
- Choosing task difficulty
- Giving actionable feedback
- Separating style preferences from correctness
- Letting a learner encounter recoverable failure
- Reviewing decisions rather than merely code
- Recognizing when intervention is necessary
- Building team documentation and guardrails
- Delegating while retaining accountability
Students are evaluated not only on their own output but on whether the learner becomes more independent.
Phase 8: Capstone ownership — 4 weeks
The final capstone should not be “build an app.” It should be:
Take responsibility for an operating system serving real or realistically simulated users.
Teams receive a goal, budget, existing assets, service obligations, and a changing environment. They must:
- Conduct discovery
- Define success
- Build or modify the system
- Design evaluations
- Operate it
- Handle incidents
- Respond to stakeholder changes
- Conduct a security review
- Transfer ownership to another team
The handoff is important. Software is not successful merely because its creators can operate it.
Final assessment includes an oral defense in which reviewers probe:
- What do you believe about this system, and what is the evidence?
- Which part do you trust least?
- Which failure would your monitoring miss?
- What did the AI propose that you rejected?
- What tradeoff would you reconsider at ten times the scale?
- What should the next team know that is not obvious from the repository?
- Which decision was reversible, and which was not?
A second example: point of sale and inventory
This project could evolve in layers:
Initial version
- Product catalog
- Checkout
- Payment records
- Stock counts
- Receipts
- Basic reports
First complications
- Returns without receipts
- Partial refunds
- Discounts and tax rules
- Weighted goods
- Multiple store locations
- Employee permissions
- Offline operation
Distributed-systems complications
- Card terminal succeeds while the application times out
- Two stores transfer the same inventory
- Delayed events arrive out of order
- A product changes SKU
- A supplier sends duplicate shipment notices
- Physical stock disagrees with recorded stock
Business complications
- Inventory may be owned by different legal entities.
- Some products expire or have serial numbers.
- Managers manipulate shrinkage metrics.
- Demand forecasts cause self-reinforcing overordering.
- A store must continue operating during a network outage.
- Refund controls reduce fraud but punish legitimate customers.
Security incidents
- Cashier credential sharing
- Fraudulent refunds
- Malicious barcode data
- Compromised supplier integration
- Customer data accidentally included in model context
- An inventory agent orders from an attacker-controlled vendor
This one project can teach databases, distributed systems, payments, UX, security, observability, operations, and organizational incentives because those concerns naturally interact.
How the AI instructor should work
A single friendly chatbot is insufficient. It would tend to answer too quickly, flatten ambiguity, and help students create work they do not understand.
The instructional system should have several distinct roles.
Tutor
Explains concepts, generates exercises, uses Socratic questions, and adapts to the student’s current model.
It should have modes such as:
- “Explain”
- “Give me a hint”
- “Challenge my reasoning”
- “Do not reveal the answer”
- “Quiz me later”
- “Ask me to predict before running anything”
Reviewer
Reviews artifacts against explicit criteria, identifies risks, and asks for evidence. It should distinguish:
- Definite defects
- Likely risks
- Stylistic preferences
- Unverified speculation
This prevents the familiar problem of AI code review generating a large quantity of authoritative noise.
Stakeholder simulator
Represents customers, operators, legal staff, managers, and vendors. Each persona has private goals and knowledge. The personas should not spontaneously volunteer every requirement.
Environment simulator
Produces traffic, failures, anomalous data, dependency behavior, security attacks, and longitudinal consequences.
Adversary
Attempts to violate declared invariants and exploit the difference between what students claim and what the system actually guarantees.
Assessor
Maintains a longitudinal evidence model of each student. It should not infer competence simply from polished output. It needs evidence such as:
- Predictions made before experiments
- Explanations given without assistance
- Debugging paths
- Decisions and reversals
- Incident behavior
- Peer reviews
- Which AI suggestions were accepted or rejected, and why
- Performance after assistance is removed
Escalation system
Flags situations for a human instructor:
- A team is stuck for too long.
- A student repeatedly produces correct output but cannot explain it.
- Reviews conflict.
- Team participation is highly unequal.
- A consequential design decision has no clear answer.
- A student may be using AI to conceal rather than close a knowledge gap.
- An interpersonal or ethical issue is emerging.
That escalation layer is what makes scarce human judgment economical.
Assessment must go beyond generated test suites
AI can generate enormous test suites, but volume is not validity. Tests generated from the same specification and assumptions as the implementation may faithfully reproduce the same mistake.
Use several independent forms of assessment:
Hidden scenario tests
Test unanticipated combinations and boundary cases. Useful, but insufficient by themselves.
Property and invariant evaluation
Students state what must always be true. Evaluators attempt to falsify it.
Mutation and sabotage
Introduce plausible defects and measure whether students’ tests, monitoring, and reviews detect them.
Oral defense
Ask a randomly selected team member to explain a subsystem or decision. This reduces the ability to hide behind teammates or generated artifacts.
Prediction
Before running a change, students predict behavior and failure modes. Calibration improves only when predictions are recorded.
Transfer tasks
After learning a concept in scheduling, apply it to inventory or claims processing. This distinguishes understanding from memorization.
AI-off exercises
Students occasionally debug, design, or explain without assistance. The point is not to recreate pre-AI work, but to verify that they retain an independent model.
Longitudinal operation
Evaluate what happens weeks after implementation. Many bad decisions pass every immediate test.
Peer and subordinate outcomes
A more advanced student should improve the work and independence of others.
Making senior instruction economically plausible
A hierarchical model could look like this:
- One principal curriculum designer per domain
- One senior reviewer for 40–80 students
- One experienced facilitator for 15–25 students
- AI tutors available continuously
- Near-peer mentors for each team
- External experts conducting occasional design and incident reviews
The senior engineers’ time goes toward:
- Creating high-value scenarios
- Reviewing ambiguous decisions
- Calibrating AI feedback
- Leading postmortems
- Assessing judgment
- Coaching facilitators
- Updating the curriculum from real industry failures
It does not go toward explaining syntax, repeatedly finding simple bugs, or manually grading routine assignments.
A flywheel could reduce costs further:
- A senior instructor reviews a difficult case.
- The session, rationale, and outcome are captured.
- Variations become future scenarios.
- The AI learns when analogous cases should escalate.
- Near-peer mentors learn to handle that class of problem.
- The senior focuses on a narrower set of novel cases.
AI should multiply expert attention, not impersonate expertise and eliminate oversight.
Possible business models
A tuition-only academy would face adverse selection and skepticism. Stronger models connect training to work.
Employer consortium
Several companies jointly fund the program because none wants to bear the full cost of rebuilding the junior pipeline. They receive recruiting access while sharing infrastructure and instructors.
Paid apprenticeship studio
The program performs bounded, low-risk client work. Revenue subsidizes training, although delivery must never depend on unsupervised learners.
Internal corporate academy
Large companies use their own systems, incidents, and retired projects as training environments. This may be the easiest initial market because the return is retention and succession, not tuition.
Assessment and simulation platform
Instead of employing every instructor, sell the curriculum, simulation environment, and competency evidence to companies and universities. Human experts can contribute scenario packs and receive royalties.
Talent underwriting
The academy charges employers for successful placements or promotions. It publishes unusually rich evidence of ability, making hiring less risky.
Continuing education for existing developers
The initial market may not be beginners. Mid-level developers and companies have money and an urgent need to learn agent supervision, security, and operations. Revenue from that market could fund junior apprenticeships.
Training yourself to become the mentor who designs this
Mentoring is not primarily explaining what you know. It is engineering another person’s learning loop.
Practice this sequence:
-
Ask for their model.
“What do you think is happening?”
-
Ask for a prediction.
“If that model is correct, what should we observe?”
-
Choose the smallest discriminating experiment.
Avoid random changes and solution dumping.
-
Let them execute it.
-
Compare prediction with result.
-
Ask them to update the model.
-
Only supply missing information when it unlocks the next reasoning step.
-
Revisit the concept later in a different context.
You can begin immediately:
- Mentor one junior or peer weekly.
- Keep notes on misconceptions, not just bugs.
- Conduct debugging sessions where you are forbidden to touch the keyboard.
- Ask mentees for feedback on when you intervened too early or too late.
- Turn production incidents into sanitized exercises.
- Write scenario branches: “If they try X, reveal Y.”
- Compare independent code reviews and examine reviewer disagreement.
- Practice assessing explanations without relying on whether the final answer is correct.
- Build a small repository of deliberately broken services.
- Run incident games with friends or coworkers.
- Teach mentees how to mentor the next person.
The deepest indicator of mentorship skill is not that your students can solve today’s task. It is that, over time, they need you for fewer classes of decisions while becoming better at recognizing the decisions for which they still need help.
That is also the likely economic moat of an AI-native academy: not content, tests, or generated feedback, all of which will be cheap, but a validated system for converting abundant AI assistance into independent, observable, trustworthy judgment.