The Process
How two of these actually got built.
Why AI is the argument. This is what the argument looks like in practice: a simple build and a complex one, walked through.
These are not transcripts. I did not save the real back-and-forth from building these two tools. What follows is a reconstruction, representative of the kind of prompting and iteration that actually gets you from nothing to a working tool like this. The finished tools are real. This walkthrough is a faithful reconstruction of the process, not a historical record of it.
MGRS Coordinate Labeling: one command, one pass
MGRS Coordinate Labeling is about as small as these get: one plugin, one command, one feature. Here is roughly how a build like that goes.
“I need a Civil 3D plugin. User picks a point in the drawing, the plugin reads the drawing's assigned coordinate system, converts that point to latitude and longitude, then to MGRS at ten-digit precision, and labels it in the drawing. C#, one command, one clean undo.”
Specific enough to build from: the transform, the precision, the undo requirement. Vague requests get vague code back.
“That's close, but the label is landing at the wrong scale relative to the drawing. Check what unit the coordinate transform is actually returning versus what the label placement expects.”
The first draft ran. It just did not run correctly. Naming exactly what looked wrong, not "it's broken", is what got a real fix instead of another guess.
“Pick five points across the drawing, including one near the edge of the coordinate zone, and confirm the MGRS output against a known-good source before I trust this.”
This step is not optional. See "Where I do not trust it" on the Why AI page.
Outcome: One afternoon, one command, done. Small builds like this are mostly about specifying the transform correctly the first time, then not skipping the check at the end.
Project File Browser & Standards Checker: built in passes
The Project File Browser & Standards Checker is the opposite kind of build: several features added over separate passes, each one changing what the next pass needed to account for.
“Start with just the browsing piece. Autodesk Forma hub and project list, then folders, then files, using 3-legged OAuth against the Autodesk Platform Services APIs. Nothing else yet.”
Complex tools still start narrow. Trying to describe five features in one prompt produces a plugin that does five things poorly.
“Now add a standards checker. It runs against a LandXML export of the selected design and flags anything that does not match our standards. Reuse the auth and file browsing that already works, and do not touch it.”
"Do not touch it" matters. Naming what should stay untouched keeps a working feature from becoming collateral damage in the next one.
“The cross-section viewer is rendering, but it is reading the wrong station range, the whole alignment instead of the selected segment. Walk through where that range gets set and fix it there, not by trimming the output afterward.”
Fixing symptoms instead of causes gets things looking right without being right. This is where "looks like it worked" and "worked" split apart.
“Last piece: a button that generates an AI render of the current design view. Keep it optional, because nothing else in the tool should depend on it succeeding.”
By the fifth feature, isolating failure modes matters more than adding capability. One broken feature should never take four working ones down with it.
Outcome: Several passes, not one. Each one narrower than it sounds, each one checked against the previous work before moving on. That is closer to how the complex ones actually go than any single prompt could show.
Transportation Asset Generator: a pipeline, not a plugin
Transportation Asset Generator is not something you click a button in. It runs as a script, generating a batch of finished files rather than one placed object. That changes what the prompts look like.
“I need a Python pipeline that builds MUTCD accurate 3D transportation assets, signs, poles, cabinets, signal heads, in Blender, then exports each one to FBX, OBJ, and DAE. Every asset has to stay under a polygon budget, because these get dropped into large InfraWorks scenes.”
The budget was named up front, not discovered later. A batch pipeline is expensive to re-run at scale, so the constraint that matters most belongs in the first prompt, not a later fix.
“The signal heads are exporting fine, but they are well over budget once every mounting bracket counts separately. Merge what should be merged before the export step runs, not after, and check the count again.”
Same as the other builds: name what is wrong and where to fix it. "Too many polygons" would have produced a guess. Naming the mounting brackets and the export step produced a fix.
“Add optional level of detail generation, and before I trust any of this, run it across the full sign and pole set and report the polygon count for every asset, not just a sample.”
A batch tool fails quietly if you only spot check it. The check here is the whole set, because one bad asset among forty can sit in a scene for months before anyone notices.
Outcome: A pipeline, checked against its own output at full scale before anything shipped. The three builds on this page cover a command, a tool, and a pipeline, and the same habits carried across all three: name the constraint, name what broke, and check the whole thing before you trust it.
Be Better! ...specify the transform, name what's wrong, and do not skip the check at the end.