The Better Question Was Not Which CAD Program to Learn

I started this rabbit hutch project thinking I needed CAD software. What changed pretty quickly was not the project itself, but the way I was beginning to think about using AI.

I have been influenced by Geoff Woods and others discussing a similar idea: instead of deciding on the solution first and then telling AI to execute it, ask a broader question. How could we do this? What are the options? What are the tradeoffs? What would work with the tools I already have?

That is a different way of using AI. If I start by saying, “I need CAD,” I have already narrowed the problem down to one category of solution before the conversation even begins. If I explain what I actually need drawings that are consistent enough to build from, dimensions I can refer back to, something close to a cut list, and documentation I can reuse later then AI has a much larger body of knowledge to work from than the handful of solutions I happen to know about.

That was really the practical question behind this project. I already had a ChatGPT subscription. Could we use the tools I already had to create a design process that was accurate enough for what I needed without turning learning another piece of software into its own project?

AI Was More Useful as a Design Partner Than as a Drawing Tool

The rabbit hutch itself started with inspiration from a simple design published by The Rabbitry Center. I had a general structure in mind, three removable cages to support, and a growing list of decisions about framing, roofing, access, weather protection, and how the whole thing should actually work once it was outside.

What surprised me was how much value came from the conversation before there was anything resembling a finished drawing. I would explain what I was trying to accomplish, ChatGPT would ask questions or offer several ways to approach it, and those options would expose decisions I had not realized I needed to make yet.

That is where AI brings out something useful in me that I do not get working alone. I can come into a project with a very specific idea of how I think something should work. Sometimes that idea is good. Sometimes it is just the first solution I happened to think of. Having a design conversation forces me to explain the goal, compare alternatives, reject what does not fit, and whittle a broad idea down into something practical.

The value is not that AI somehow knows what I want better than I do. It is that the combination of my knowledge of the actual project and AI's much broader range of possible approaches gives us more material to work with than either side has alone.

A Pretty Picture Was Not Going to Solve the Problem

One limitation became obvious as soon as drawings entered the conversation. Generative images can make something that looks convincing, but looking like a technical drawing and functioning like one are two different things.

A construction drawing needs relationships to stay put. If a support is supposed to be a certain distance from an edge, it needs to remain there. If three cages share a frame, the framing cannot quietly change proportions every time the drawing is regenerated. Dimensions, labels, lines, and reference points need to behave consistently enough that I can critique them and then expect the correction to survive the next revision.

That is exactly the kind of problem CAD is built to solve, which is why CAD had seemed like the obvious answer in the first place. But I did not need a professional architectural workflow. I needed something relatively scalable, consistent, editable, and good enough to help me build one rabbit hutch and reusable enough to support future builds.

SVGs Changed What We Could Do

Somewhere in those early design conversations, SVG files started coming up as a practical option. I knew what an SVG was, but I had not started the project thinking, “I should use SVGs for construction drawings.” Once that solution surfaced, though, it immediately made sense.

An SVG is still a visual drawing when I open it, but underneath the drawing is structured information. Lines have coordinates. Shapes have defined sizes and positions. Text can be placed deliberately. Codex can edit those instructions directly instead of trying to regenerate an image and hoping the same relationships survive.

That was the point where the drawing process became much more useful. We were no longer asking AI to create a picture that looked approximately right. We had a programmatic drawing that could be inspected, changed, compared, and revised in specific ways.

It still was not CAD, and I do not want to pretend it was. The drawings required plenty of correction. I would find a support in the wrong position, a framing relationship that did not make sense, or a dimension referenced from the wrong place. Then we would correct it, look at the result, and go around again.

But that was a process I could work with.

The First Reconciliation Happened Before I Built Anything

That back-and-forth became the first reconciliation phase. I had an idea in my head, there was a representation of that idea in the drawings, and the job was to keep bringing the two closer together.

This is also where one of the biggest dangers of working with AI shows up for me. The process can keep going almost indefinitely. There is always another question to ask, another detail to refine, another drawing to tweak, another possible improvement to discuss. I enjoy that process enough that it can become productive procrastination without looking like procrastination at all.

You can keep polishing a turd until the polishing becomes the project. At some point I had to stop improving the plan, pick up the lumber, and let the build tell me what still needed work.

The drawings were not perfect when I started construction. I knew that. They did not need to be perfect. They needed to be useful enough to move the project into the next phase, because the next information I needed was not going to come from another conversation.

The Physical Build Became the Test

Once construction started, the hutch began producing information the drawings never could. Lumber had actual dimensions. Roofing had manufactured lengths. The cages had to physically slide in and out. Connections that looked reasonable on a screen had to make sense when I was standing there with materials and tools.

Some of the design changed because of that feedback. Planned X-bracing was replaced with horizontal rails. The roof framing evolved. I kept the manufactured roofing panels at full length instead of cutting them down, which created more covered space around the cages. Cage supports were adjusted so wider members could share the edges of neighboring cages while narrower supports reduced the horizontal surface available to catch manure.

None of those changes meant the planning process had failed. They meant the design had finally reached the environment where it could be tested properly.

That distinction matters to me. I do not want AI to eliminate iteration. I want it to make the early iterations faster and more productive, so I can reach the point where real world feedback becomes more valuable than another theoretical pass.

Then the Direction of the Documentation Reversed

Once the hutch was finished, I could have stopped. If I had drawn the project by hand, I probably would have had a functioning structure, a sketch somewhere, and a handful of measurements that made sense to me at the time. That would have been enough to accomplish the original goal.

Instead, we went back through the project again. After the build, I was no longer asking whether the hutch matched the plan. I was asking whether the documentation matched the hutch.

That became the second reconciliation phase. I measured the finished structure. Photographs helped verify visible relationships. Decisions I had made during construction were recorded. Assumptions inherited from the earlier design were checked against what was actually standing there.

We also had to deal with the places where the evidence simply was not complete. Some information was physically measured. Some could be clearly established from photographs. Some was known because I had made the decision during construction. Other details had never been recorded well enough to claim them confidently.

That led to four evidence labels in the final documentation: MEASURED AS-BUILT, PHOTO-OBSERVED, OWNER-REPORTED, and UNVERIFIED.

I particularly like UNVERIFIED. AI can fill gaps very convincingly, and humans are perfectly capable of doing the same thing. Explicitly labeling a gap instead of smoothing it over made the final documentation more useful to me, not less.

The Result Was More Than the Drawing I Thought I Needed

By the end, the project had produced a 13-page Builder Package with as-built SVG drawings, materials information, practical cut information, a build sequence, notes about changes made during construction, and a limitations section that says what the package does not establish.

I did not start out trying to produce a document. I was trying to solve a much narrower problem: how to make useful drawings for a rabbit hutch that I can build from?

That is one of the reasons this project changed the way I think about AI tools. If I had forced my original solution from the beginning, I might have spent my time learning CAD, made a drawing, built the hutch, and stopped there. Instead, the broader conversation created a design process, a record of decisions, a way to revise programmatic drawings, and eventually a method for reconciling those drawings against the finished structure.

The finished Builder Package is not professionally engineered, and I am not presenting it as a perfect construction plan. Some details remain intentionally unverified or field-fit. Somebody using it still needs to measure, think, and adapt the ideas to their own materials, cages, site, and conditions.

For me, that is not a weakness in the experiment. That is an honest description of what the tool actually accomplished.

What I Think AI Actually Did Well

I do not think this project proved that AI replaces CAD. If I needed precise engineering drawings and already knew how to use professional drafting software, CAD would still be the obvious tool.

What AI did well was help me figure out what tool and workflow made sense before I committed myself to a solution. It helped widen the options, ask questions, expose missing decisions, preserve the reasoning behind those decisions, create and revise structured drawings, and then organize the evidence when the physical project no longer matched the original design exactly.

The SVG files were important, but I do not think SVG is the main lesson either. The format was one solution that emerged because we had defined the problem well enough to recognize a good answer when it appeared.

The bigger lesson is that I get more from AI when I stop treating it like a machine that should execute my first idea and start treating the conversation as part of the design process. I bring the goals, the constraints, the physical experience, and the judgment. AI brings breadth, alternatives, questions, organization, and a willingness to keep exploring. Then we work the problem down together until there is something useful enough to execute.

There Still Has to Be a Point Where You Build

That last part matters because AI will happily keep helping me refine an idea forever. It does not know that another hour of conversation is now less valuable than going outside with a drill.

I have to make that decision.

With the rabbit hutch, the first round of planning eventually became good enough to build. Construction generated better information. Then the documentation was revised using what the real project taught me.

That loop explore, narrow, execute, observe, reconcile — is much more interesting to me now than the question I started with about CAD software.

I was looking for a way to draw a rabbit hutch.

What I ended up finding was a better way to use AI as a thought partner in solving a problem.