Written for engineers who already use an agent every day.
Two to eight years in, comfortable generating code, and less comfortable explaining, reviewing or maintaining it at the pace it now arrives. Also for tech leads who need a method they can hand to a team of four and expect them to follow.
Not for you if
- You are learning to code. This course is not where that happens.
- You want a job guarantee or an income claim. There is neither.
- You want an application without engineers. That is a different problem and this will not solve it.
Prerequisites
- Two years of professional experience.
- Comfortable in one language and one framework.
- Already using an AI coding agent daily.
Take an unspecified feature, write requirements an agent can build from, design and sequence the work, and verify the result without reading every line.
That is the whole promise, stated as narrowly as it can honestly be stated. It is not a path to becoming an AI engineer and it is not a career outcome. If the sentence above is not something you want to be able to do, this is not worth your money.
Six modules and pre-work. Every one ends in something committed.
Roughly eight to nine hours of video and reading, and twelve to twenty hours of work if you do the exercises properly. Lessons are capped around twelve minutes. Every lesson has a full transcript, every artefact downloads as text, and the code lives in a public repository with a branch per module, because a good share of the intended audience is on metered data.
- 00
Setup
Pre-work, not a lessonA checklist. Agent installed and configured, a repository ready, a hook that runs the test suite, and the sample project cloned. Learners who reach module 1 with nothing working do not finish.
Artefact A working environment and a green test run
- 01
Why specs beat prompts once a system outgrows one file
The failure mode before the method. A demo that works, then the same approach on a four-feature system, and a look at where it collapses: contradicted decisions, forgotten conventions, a rewrite of code that was already correct. Then what a spec actually consists of, and the three approval gates.
Artefact A decision inventory
- 02
Requirements an agent can build from
EARS notation taught as a constraint rather than a formalism. When to reach for WHEN, WHILE, WHERE and IF-THEN, why “the system should be fast” is not a requirement, and the requirement most people forget, which is what happens when the thing fails.
Artefact requirements.md for the capstone feature
- 03
Design that constrains rather than decorates
Data model first. Then every state, including empty, loading, partial, error, offline and success, because an undesigned state is a state the agent invents. Failure modes, idempotency, and the judgement call this module exists to teach: what to decide up front and what to leave to the agent.
Artefact design.md with a data model and a state table
- 04
Steering, the conventions that outlive the conversation
Which rules belong in every conversation and which belong in some. Inclusion modes, and the failure nobody notices, where malformed front matter silently loads thousands of tokens of irrelevant conventions into the wrong conversation. Writing steering that reflects a codebase as it is rather than as it was meant to be.
Artefact A steering directory, committed
- 05
Tasks, sizing and sequencing
How big a task should be, which is the most common thing people get wrong in both directions. Dependencies and build order. Traceability from each task back to the requirement it satisfies, and why tests belong with the task rather than in a later phase.
Artefact tasks.md
- 06
Verification, and reviewing what you did not write
Automating the boring half, so typecheck, lint and affected tests run after every completed task and a broken tree surfaces in seconds. Guarding the dangerous half with a confirmation step before edits to money, auth or migration paths. Then the human half: reading a diff you did not author, property-based tests for the edge cases that pass unit tests and break in production, and knowing when to reject and respecify instead of patching.
Artefact Hooks committed, and a written review of a seeded change
One non-trivial feature, built spec-first, in your own repository.
Not a toy. It has to include persistence, at least one failure path, and tests. You submit the repository URL containing the specs it was built from, the implementation, the tests, and a short description of what you built.
Reviews happen in fortnightly windows rather than on demand, so a review gets proper attention instead of being squeezed between other work. A submission that misses a criterion is rejected with the reason, and you can resubmit at no cost. Nothing is waved through, including for people who are pleasant and nearly there. The first exception is the one that makes the whole thing decorative.
The five review criteria
Published here before you can buy anything, and worded identically on the verification page. This is the standard, and it is applied to everyone.
- 01Requirements are written in EARS and every criterion is testable.
- 02Design covers the data model, the failure states and the trade-offs that were considered.
- 03Every task traces to a requirement it satisfies.
- 04Tests were written with each task, and the suite passes on a clean clone.
- 05Money and identity paths, where present, are reviewed line by line and defensible.
Same lessons in both. The difference is whether a human reviews your work.
Course
Every module, transcripts, the code repository and the capstone brief. No review, and no certificate.
Course and review
Everything above, plus your capstone reviewed against the five criteria, and a Certificate of Completion with the reviewed project published as evidence.
Reviewed places are capped at twelve a month. A review done properly against five criteria takes an hour or more, and that ceiling does not move because more people want in. When the month fills, the reviewed tier closes and the material tier stays open. A five-seat team option will exist at launch.
Prices are not published yet, and there is no discount code, no countdown and no launch offer on this page. When prices are set, the waitlist is emailed first.
A Certificate of Completion, with the reviewed project attached to it.
It records that you completed the course and that a named person read your project against criteria published before you paid. It lives on a verification page on this domain, alongside a link to the work itself, so anyone can check it without taking your word or mine.
Issued by Emmanuel Akinfulubi, Software Engineer, Lagos, Nigeria. Only the reviewed tier carries one.
What it is not
- Not an accredited qualification, and not a licence to practise anything.
- Not issued or endorsed by any tool vendor or their employer.
- Not a job outcome, and not evidence of one.
Certificate of completion · Not an accredited qualification
Emmanuel Akinfulubi. I run this method on client deadlines, not in a sandbox.
A software engineer in Lagos, currently architecting a twenty-four week platform programme planned as specs with steering and verification hooks, covering a storefront, an in-person till, a learning platform and a back office. Before that, a Flutter application live on both stores across six App Store regions, and five documented client engagements.
The method is what I am teaching. Client deliverables are not mine to publish, so every example in the course is purpose-built for it. You can read the thinking first and decide whether it is worth paying for.