01Finite learning path
Learn the method
Untacit · Structured thinking for the age of AI
Make tacit knowledge visible.
In the age of AI, execution gets cheaper. Judgement becomes the advantage. Untacit uses System Design as a practice ground for structured thinking—turning experience, intuition, and judgement into reasoning you can see, test, explain, and improve.
- Make judgement visible
- Make methods practicable
- Make experience transferable
Learn the method, then practise real problems
One stable path. One growing case library.
Build the complete System Design reasoning method first, then practise it across an expanding set of real cases. New cases never move the finish line for your core curriculum.
02Continuously updated
Practise with real cases
System Design Case Library
Practise the same reasoning method across AI systems, social feeds, transactions, and consistency problems. Every case can be started independently.
Explore cases →The Untacit method
Turn experience and intuition into a method you can practise
Great engineers often know more than they can explain. Untacit makes that tacit judgement inspectable and practicable, with System Design as the practice ground.
- 01
Think · See the judgement
Move actors, outcomes, assumptions, boundaries, and trade-offs out of one person’s head and into a shared model.
- 02
Make · Produce evidence
Use sorting, comparison, simulation, and canvases to turn understanding into something testable.
- 03
Explain · Transfer the method
Explain why the decision holds, what would overturn it, and how someone else can reuse the reasoning.
Tacit → Untacit
Good judgement should not live in one person’s head
The course does not hand you conclusions. You expose your default assumptions first, then inspect the structure behind expert judgement.
Select a card to turn intuition into inspectable reasoning
Thinking exercise preview
InteractiveUse it in real work
The hard part happens before the boxes and arrows
Untacit focuses on the judgement that precedes an architecture diagram: what the problem is, where the boundary belongs, and which cost is worth paying.
Handle ambiguous requirements
See the user, outcome, scale, success criteria, and assumptions nobody said aloud.
Draw system boundaries
Decide what this design will solve, what it will not, and where responsibilities should separate.
Explain architecture trade-offs
State why this option wins, which costs it accepts, and what change would overturn the choice.