AmouAI Hub/Courses /Software Engineering for AI Engineers
Twenty-four chapters built from Andrew Ng’s AI Engineering Skills Map. A coding agent will write the code. It will not tell you which of latency, availability, consistency, reliability, maintainability, simplicity and cost this application is allowed to sacrifice — and it made that decision anyway. This course teaches the decisions: real SQLite running in your browser, architecture choices graded against stated constraints, and thirty instruments you operate rather than diagrams you look at.
Nothing to install. SQLite compiles into the page, your queries run locally, and nothing you write leaves your machine.
Source material
Built from “AI Engineering Skills Map: Software engineering fundamentals” by Andrew Ng (DeepLearning.AI, 28 August 2026), the second of four skill areas in his map of AI engineering. The five parts below are his five areas, weighted the way he weights them — data gets six chapters because the article argues data deserves the attention. Everything beyond the article’s outline — the instruments, the exercises, the worked examples — is built for this course. Read the original →
Ng names five things you have to be good at once an agent is writing the code. Each one becomes a part of this course, and each part ends with you having built or broken something.
The request path, API contracts, where state lives, and caching. The layer every AI feature is eventually delivered through.
Six chapters, because a poor data architecture means your AI system does not know what it does not know. Real SQL, real query plans, real transactions.
Turning requirements into numbers, drawing boundaries, choosing a stack by experiment, and writing the decision down where the next agent will read it.
A testing strategy worth its runtime, designing for the failure you will actually get, threat modelling, and the supply chain an agent introduces.
Delivery pipelines, observability including the model calls, scaling under real load, and keeping a system nobody fully wrote.
Most system-design material is text you read and flashcards you memorise. Three of the four exercise types here execute something and check the result, and the fourth grades a design against constraints rather than against taste.
Availability arithmetic, retry policies, cursor pagination, cache rules. Checked against what your code does, not against the text you typed, so more than one answer is usually right.
Schema design, constraints, indexes, EXPLAIN QUERY PLAN, transactions. The row counts
and the plans on your screen are the ones SQLite produced, not numbers we wrote down.
A scenario, its constraints with weights, and the decisions that answer to them. You configure the design and write the justification — naming the tradeoff out loud is what is being assessed.
Short multiple-choice checks where the explanation is the point. Every one of them is a mistake somebody has actually shipped.
Three outcomes. Every chapter maps to at least one, and the capstone in Chapter 24 assesses all three at once.
The same rhythm every time, so it becomes a habit rather than a decision. Roughly two to three hours if you do the exercises, which is the only version that works.
Five or six sections of real teaching. Every technique arrives with what it buys and what it sells, because the second half is the half nobody writes down.
≈40 minSeven to ten things you drive: a tradeoff board, a query planner, a failure injector, a retry storm. They compute; they are not illustrations.
≈30 minThree real failures per chapter. Symptom first, you guess the cause, then the fix and what it teaches. All of them have shipped somewhere.
≈15 minWarm-up, core and challenge. Checked in the browser with feedback that says what was expected, what was found, and why the difference matters.
≈60 minFive parts, twenty-four chapters. Open any part to see its chapters; each one lists what it covers and what you build.
Everything is graded in your browser and stored there. Architecture exercises will not accept a configuration without a written justification, because the justification is the skill.
The chapters stand alone. These are where the depth is, and Kleppmann in particular is the book this course keeps pointing at.
The SQL chapters ship a real build of SQLite compiled to WebAssembly, loaded the first time a page needs it. Your schema is created, your rows are inserted, your query is planned and executed by SQLite itself. When Chapter 8 shows you that a query examined 50,000 rows without an index and 3 with one, those are counts derived from the plan SQLite actually chose — not numbers written into the page.
It is a genuine engine, so genuine errors come back. A missing comma produces the same message it would produce on a server, which is the point.
Judgement, yes — arbitrary, no. Every architecture exercise states its constraints and weights them, and the grading asks whether your configuration serves the heavy constraints or the light ones. A choice that sells a weight-5 constraint to buy a weight-1 constraint is wrong for that scenario, and the feedback says which constraint you spent.
The same feature appears more than once across the course with different constraints, and the correct answer changes. That is the lesson, and it is why memorising patterns does not survive this course.
No. The runnable exercises are JavaScript and SQL because both run in a browser with nothing installed, but almost nothing here is about either language — the availability arithmetic, the isolation levels, the retry policies and the sharding tradeoffs are the same in Python, Go or Java.
No cloud provider is assumed. Costs are modelled in generic units so the arithmetic transfers.
It will help, and it is not built for it. Interview material optimises for producing a plausible whiteboard diagram in 45 minutes. This course optimises for making a decision you can defend six months later, which means it spends much more time on what a choice costs and much less on reciting reference architectures.
If you want the interview drill specifically, work through the exercises and skip the bug clinics. If you want to be good at the job, the bug clinics are the part to do twice.
It teaches the half that most AI applications actually fail on. Ng’s point in the source article is that the AI core is expressed through a broader software application, and that a poor data architecture leaves the model unable to know what it does not know. So: retrieval-ready data structures, vector stores placed sensibly, token cost modelled per user, model calls traced with the rest of the request, and the injection surface a tool-using agent creates.
For the model side itself — attention, training, sampling — that is LM Playground.
Two to three hours per chapter if you do the exercises, so roughly 60 hours end to end. It is self-paced with no deadlines, and the curriculum drawer on every page lets you jump straight to the part you need. Parts 2 and 5 stand alone reasonably well if you already have the rest.