A small team of AI assistants does the research, CAD and planning. Mauricio approves every key decision and does the physical build. Here is how it works, and why.
1. The process at a glance
Every AI Make project is built by a small team of AI assistants and one human, Mauricio. The assistants research, sketch, model in CAD, plan prints and check each other's work. Mauricio decides: he approves the goals, the key parts, the designs, every purchase and every physical test, and he does all the hands-on work at the printer and in the shop.
The idea underneath is simple: a mistake is cheapest to fix while it is still on paper. So the process moves in five phases, from "what problem are we solving?" to "does the finished build actually work?", and it checks the risky fits early, before many other parts depend on them.
- 1Specify
- 2Concept
- 3Embodiment
- 4Detail
- 5Verify
Each phase ends with my decision: approve, revise, or close.
An "AI assistant" here means a computer program you give instructions to in plain language; it reads, writes and reasons through text, and can operate software tools when it is connected to them. Each assistant on the team is given one job, so its attention stays on that job.
2. The five phases, step by step
Phase 1 · Preparation and Specification
Understand the brief and what the video needs to show. Look at what already exists, including parts and designs AI Make already owns. Write down measurable requirements, what is out of scope, and the budget. The result is a short research report and a Product Design Specification (PDS): the written list of what the build must do, each item with a way to check it.
Why: If the target is fuzzy, every later step drifts. Writing it down with a test for each item means "done" has a clear meaning.
Phase 2 · Concept
Describe what the machine must do as verbs (hold, dispense, sense, signal) and trace how material, energy and signals flow between them. Draw the system boundary without picking every part yet.
Why: Thinking in functions first keeps the team from locking in a part before knowing whether the job needs it.
Phase 3 · Embodiment Design
Compare a few realistic ways to build it, reusing or adapting existing hardware where possible, and pick the simplest one that works. Agree on the critical bought-in components and their interfaces. Then settle the few uncertain fits that could break the design, using data sheets, measurements or a small test print (a coupon) before detailed CAD is built on top of them.
Why: A shaft bore or a heat-set insert boss is cheap to check in a coupon and expensive to discover wrong in a full enclosure print.
Phase 4 · Detail Design
Working in order of what depends on what, specify the bought-in parts, then model the custom parts in Fusion together with assembly order, appearance and print orientation. Review each complete subassembly, check the full bill of materials (BOM) before anything is made, then slice and print only the approved revisions.
Why: Assembly access, screwdriver and heat-set tool reach, wire routing and bed orientation shape the part while it is designed, not after it fails.
Phase 5 · Verification and Validation
Test the build as it was actually made against the approved requirements and the intended use. Record any fixes made during assembly as as-built notes next to the part they affect, and update the build instructions so someone else can replicate it.
Why: The real build is the proof. Recording what changed keeps the published files honest.
3. How the plan stays on track
One short active plan file is the single source of truth for the project: the current phase, the decisions already made, what is still open, what counts as finished, and the next action. Every assistant reads it before working. A quick "yes" from Mauricio approves only the item being discussed, and settled decisions are not reopened without new evidence or his instruction.
The process also separates three kinds of knowledge: a value taken from a source, a value that is only assumed, and a value that passed a physical test. They are never mixed up, and an assumption is never promoted to "verified" just because a render looks right.
4. The team: who does what, and why
Each role is a set of written instructions, called a role contract, that tells an assistant when to step in, what to deliver and when to stop. The team lead brings in only the roles a question needs, not the whole roster.
Kelly · team lead
Plans the work, picks the smallest useful team, weighs trade-offs and merges everyone's input into one recommendation for Mauricio.
Why: One clear recommendation beats eleven competing opinions.
Adrian · mechanical
Works out loads, motion and critical interfaces before shape detail, and builds the mechanical geometry with the calculations and fit evidence behind it.
Why: Shape follows load paths and fits, not the other way around.
Woz · electronics
Uses what the existing board or module can already do, justifies every extra sensor, and produces the minimal circuit and pin map.
Why: A second Hall sensor or terminal block needs a reason, not just availability.
Bill · control software
Defines inputs, states and transitions, then writes firmware that is easy to read and tests the required behavior.
Why: Clear firmware with real error handling is easier to fix than clever, short code.
Nikola · power and wiring
Closes the path from power source through the load and back, and plans the harness, ratings, connectors and routing.
Why: A connector that physically fits is not the same as one that is electrically right.
Elon · manufacturing and assembly
Removes unneeded print and assembly operations, sets print orientation, and makes sure tools and wires can reach. Produces the actual slicer setup.
Why: Assembly order and tool access are design inputs.
Jamie · cost and time
Compares the cost and time to finish, including reprints and Mauricio's hands-on time, and tracks spending in the BOM.
Why: The cheapest part is not always the cheapest build.
Jeff · sourcing
Starts with parts already owned, confirms the exact variant and whether it is specified, ordered or in hand, and stops once a solid choice exists.
Why: No silent substitutions.
Steve · form and use
Turns what Mauricio wants into concrete form and interaction targets, and reviews silhouette, contours and junctions on the actual revision.
Why: Specific, fixable feedback instead of vague polish.
Filter · independent reviewer
Checks the submitted design against the evidence and can mark it NOT READY. Filter never edits the design it reviews. Only Mauricio can override.
Why: A reviewer who did not build it catches what the builder misses.
Bookworm · research
Answers one unknown that matters for a decision, with sources and stated uncertainty, then stops.
Why: Research sized to the decision, not a literature survey.
Mauricio sits above the whole team. He approves phase goals, design-driving components, schematics and CAD, purchases, any added protection, and every test involving physical objects, and he does the physical work: measuring parts, printing coupons, assembling and testing.
5. Current revision
Version 1.8 is the current method. Projects move to a new revision only when Mauricio directs it; nothing switches over automatically.
6. What changed from the last revision
The previous published revision was v1.6. (A separate 1.7 draft was never merged into the method.) v1.8 builds on v1.6 and changes how the plan is kept:
- One active plan per project. A single, short plan file now owns the current phase and deliverable, settled decisions, open dependencies, the definition of done and the next action. Status notes and handoffs point to it instead of keeping their own to-do lists.
- Read the plan first. Every assistant reads the active plan before engineering work and before proposing a next step.
- Acknowledgments approve only one thing. "Yes" or "perfect" approves only the item under discussion, not the whole package.
- Check before declaring done. The deliverable is compared with its completion criteria before anyone reports it finished or moves to the next phase.
- Role contracts updated to 1.2.0. The team lead keeps the shared plan; specialists get only the relevant slice and send their changes back to the lead.
- Unchanged: the five phases, Mauricio's approvals, the full BOM check before manufacturing, optional low-cost fit prints and the CAD tool responsibilities.
Why: in practice the assistants could lose track of the next step between sessions, which left Mauricio acting as the project's memory. One plan file read at every turn fixes the cause instead of the symptom.
See it applied
Reward Rocket
The full process on a real build, from spec to a 38-step guide. Read the build journal →
Fusion MCP
The tool the CAD steps run through. See the Fusion MCP →
Next build
New builds land on YouTube first. Subscribe →