Reading Adam's 'The Bitter Lesson of AI CAD': are two tools enough for engineering?

Adam is a US start-up building AI for CAD. It was in Y Combinator's Winter 2025 batch and closed a USD 4.1 million seed round in October 2025 [3]. Its products include a Copilot that edits models in Onshape and Fusion from prompts, a cross-system migration service that keeps feature history, and the open-source text-to-CAD app CADAM; we covered the company in a separate article.

In May 2026 Adam's CEO, Zach Dive, published a blog post titled "The Bitter Lesson of AI CAD", explaining why the team tore down its early technical approach [1]. This article first summarizes the post's main points, then tests them against several public cases, and finally adds our own view.

1. The main points of the post

First, early models did not understand 3D, and the team compensated with many custom tools. The author recalls that over a year ago models could not reason about space or tell which face was which, and Adam's first version could just about put a hole through a cube from natural language. The team wrote thousands of lines of abstractions, including a CAD-specific language, to turn 3D information into text for the model [1].

Second, general methods eventually beat specialized ones. The author had previously trained computer-use models at the AI lab Adept, and concluded that the best results now come from the strongest general models — the "bitter lesson" of machine learning. He is therefore bearish on competitors training CAD foundation models: no one can out-scale the large model vendors, and the next model will unlock their use case as a side effect [1].

Third, the work is mostly in the model, and harnesses get in the way. In the author's view the model does nearly all the work, not the feature graph or a custom 3D reasoning module; each abstraction the team wrote was something the model had to fight around, and each custom tool a failure mode to maintain forever [1].

Fourth, only two tools remain. Adam removed hundreds of feature-specific tools and its custom language, leaving the agent with code generation and screenshots; in the post's words, "Two tools. Code generation and view screenshot." The agent writes code, looks at the screenshot, decides what to build or fix next, and writes more code [1]. The example in the post is typing "a robot arm" into Adam's Fusion extension and having the agent generate the whole model [1].

Fifth, it works because models can code and can see. The author notes that models have been trained with reinforcement learning mainly on math and coding, so they should be used for what they are good at — writing code; and the latest models can understand images, for example noticing that a hole is on the wrong face [1]. His conclusion is that the more CAD-specific harness a product builds, the more brittle it becomes when the next model ships [1].

Figure 1: Our summary of the post. Left, the early approach; right, the current approach. Drawn by CADFrontier.

2. Testing against public cases

Model progress is indeed the main driver. In CADBench V3, which we covered earlier, switching from Opus 5 to Opus 5.5 with the same Claude Code agent raised the drawing-to-3D score by 22.02 points while cutting cost by 43.3% [5]. That fits the view that a stronger general model unlocks capability, although the test did not isolate every factor.

"Writing code" is already the common choice across routes. In RWE-bench's crankshaft task, the agent models with CadQuery, meshes with Gmsh and solves with CalculiX [4]; the open-source desktop app SOMA has command-line agents such as Claude Code write CadQuery code, while the user measures and marks up the view as feedback [6]; and text modeling in China's CrownCAD has a large model generate a parametric script that its own kernel then builds [7]. The toolchains differ, but all three use generated code as the interface between model and geometry.

But single attempts are not yet reliable. In RWE-bench the best model's average single-attempt pass rate was 37%; Claude Opus 5.5 scored 29% on a single attempt and passed 70% of tasks when allowed five attempts [4]. The loop of writing code and checking results can complete full engineering tasks, but the success rate does not yet support unattended delivery.

3. Our view

Where we agree. Our earlier articles also argued that having a model write executable modeling instructions is more workable than having it generate geometry directly, and CADBench showed that model capability accounted for the largest score differences [5][8]. On this point Adam's view and ours agree.

What we would add. We consider that the "two tools" solve getting the shape built, while engineering delivery needs more:

• A screenshot shows shape, not accuracy. A hole on the wrong face shows up in a screenshot; whether tolerances, fit clearances and wall thickness are met does not. RWE-bench uses deterministic programs and physics solvers for scoring precisely because visual checks are not enough [4]. In Reliable CAD agents we argued for turning design requirements into checkable acceptance criteria and verifying every step [9].
• A code model is not a hand-over-ready feature tree. Companies need models they can modify in mainstream CAD, with properties, drawings and a place in PLM [8][10]. Notably, Adam's own commercial product also edits native models in Onshape and Fusion and says it keeps the existing feature history [2], which suggests that writing code is the means and mainstream CAD remains the destination.
• The interface determines how far AI can go. In our Drawing-to-CAD workflow article we argued that mainstream CAD exposes structured information — sketch constraints, feature order, parameter names, parent-child dependencies — through MCP or APIs, so that AI can create and modify features like a designer instead of leaving a dumb solid [8]. If the code an agent writes calls these interfaces, it lands on an editable model.
• Cost and dependence cannot be ignored. On the general-model route, costs are set by model vendors: in RWE-bench the best model cost about USD 59 per run, and runs averaged 3.4 hours [4]. For companies this is a question of cost, and also of whom the data goes to and whether it can run locally.
• People still finish the job. While single-attempt success is below 40%, the safer division of work is that AI drafts and engineers check [4][8].

4. Conclusion

The Adam CEO's post makes a clear judgment: AI capability in CAD comes mainly from general large models, so products should build fewer custom harnesses and let models write code and look at the results. CADBench and RWE-bench support the view that model progress is the main driver, and several technical routes have chosen code as the interface. We consider that this route solves "getting it built"; getting it delivered also needs checkable acceptance criteria, editable feature trees in mainstream CAD, and an engineer's final sign-off.