Code-CAD with build123d

The honest framing, first, because the enthusiasm for code-CAD routinely oversells it. Real advantages: a model that diffs, reviews, tests and regenerates from parameters, and a part family rather than a part. Real costs: no direct manipulation, a slower loop for organic or exploratory shapes, and a much steeper start. Stating both up front means the rest of the path is learned with a clear idea of when to reach for it and when to open a GUI instead.

🔴 The foundational distinction, and the source of most beginner confusion. build123d produces boundary-represented solids — exact surfaces with topology — on top of a geometry kernel; a mesh format is a triangulated approximation with no topology at all. Everything downstream follows from this: why selectors can name a face, why fillets can fail, why exporting to a mesh is lossy and to STEP is not, and why importing a mesh does not give you back a model you can edit.

Practical and early, because a code-CAD workflow with no live view is miserable and most people quit here. Getting the library installed, a viewer attached, and a change-see-change cycle that takes seconds rather than a re-run and a file open. A Skill element: the assessable outcome is a working setup you can demonstrate, not a description of one.

Solids in this style are almost always a 2D profile taken into three dimensions, so the 2D vocabulary comes before anything solid. Lines, arcs, splines, closed profiles, boolean combination in 2D, and the fact that a sketch is a first-class object you can build up, reuse and transform rather than a step inside a feature.

build123d deliberately offers two interfaces over the same kernel: a context-managed builder style, and an algebraic style where shapes combine with operators. This unit exists because the two look like different libraries in tutorials, learners pick one by accident, and then cannot read half the examples they find. Covers what each is good at, how they interoperate, and why having both is a design decision rather than an inconsistency.

The four operations that account for the overwhelming majority of real parts, taught together because choosing between them is the actual skill. Includes the ones that fail in practice: a loft between profiles with mismatched vertex counts, and a sweep along a path with too tight a radius, both of which produce errors that are opaque until you know what the kernel was attempting.

🔴 The single most common source of 'my geometry is in the wrong place', and it is not a bug. Everything is positioned relative to a location, workplanes nest, and an operation inside a nested context is placed in a frame that is not the global one. Getting this wrong produces parts that look right in isolation and are wrong the moment they meet an assembly. Must be taught explicitly rather than absorbed, because the failure is silent.

The distinctive difficulty of code-CAD. To fillet an edge you must first select it, and the edge has no name — it is found by filtering and sorting on position, direction, size or type. This is powerful and brittle: a selector that picks the topmost face works until a parameter change makes a different face topmost. This is the same class of problem as the topological naming issue in GUI CAD, and it is where code-CAD models actually break.

Placed deliberately after selectors, because these operations are half selection and half geometry. Covers the ordering rule that decides whether a fillet succeeds, radii that exceed the available material, the interaction of fillets at a corner where three faces meet, and shelling with variable wall thickness. The failure messages are unhelpful, so the diagnostic reasoning is the content.

Union, difference and intersection, and the modelling strategy that comes with them: building a part as an accumulation of positive and negative volumes rather than as a single feature tree. Includes coincident-face artefacts and why a cutting tool should overshoot the material it cuts through — a trivial habit that eliminates a whole class of near-zero-thickness sliver failures.

The point of the whole exercise. Turning a model into a function of its inputs, with validation, sensible defaults and named dimensions; then composing those functions into a library. A Skill element because the assessable artifact is a part family that regenerates correctly across its full parameter range — which is a much stronger claim than one model that happens to work.

Multiple parts positioned relative to each other by defined mating relationships rather than by hand-computed transforms. Covers why an assembly built from joints survives a parameter change and one built from absolute placements does not, and interference checking, which is the practical reason to assemble in the first place.

Each output format discards something different, and picking wrong is a slow, confusing failure. STEP preserves the solid for downstream CAD; mesh formats approximate it for printing, with a tolerance setting that decides whether curves come out faceted; 2D vector formats for laser and documentation. The unit is really about the deflection and tolerance settings that nobody changes and that determine output quality.

🔴 The unit that justifies the whole approach, and one no GUI workflow can offer. A model is code, so it can have a test suite: assert the volume, the bounding box, the mass properties, the count of faces, that a part regenerates across its parameter range, and that a change did not silently break a variant. Then run it on every commit. This is the differentiating capability, and it is what makes the portfolio artifact credible rather than decorative.

The path has no certification to aim at, so the deliverable is the outcome: a genuinely parametric part or assembly family, tested, exported, physically made, and published with the reasoning written up. A Skill element that no quiz can close, and the thing an employer or collaborator can actually evaluate.