The work left after the tool finishes
By Janusz Nowakowski · Product at Graftd
Originally published at Graftd. This copy includes my accompanying thoughts and the original article.
My thoughts
We recently reviewed our Revit automation at Graftd through an architect’s eyes — someone preparing drawings for issue who needs to understand the result and move forward.
That led us to improve how the tool communicates: keeping the information needed to locate existing references visible even when a check fails.
This connects with KP Reddy’s recent point about the burden on the person receiving AI-generated work.
I want our tools to make the next step clear, so architects can put their attention where their experience matters most.
Related reading: KP Reddy, We Gave the Sender a Firehose and the Receiver a Straw.
Original article
The work left after the tool finishes · Graftd
The last person you want debugging new software is the architect trying to get a drawing set out the door. Yet that's where the work can end up when a tool reports a problem without giving them enough information to deal with it.
A review of our Revit automation at Graftd brought this home. We found a case where a failed final check could strip useful information out of the report. The software still had the identifiers of older reference markers. The person reading the report could lose the information needed to find them.
That sounds like a small reporting bug. Follow it into someone's working day and it gets bigger. They have to open the model, locate the affected elements and work out what the tool has done. Then they have to decide how much of the rest they can trust.
The investigation lands with someone who already has a project to deliver.
We corrected that reporting path. It also sharpened a question I now bring to this work: how much effort will the next person need to understand the result?
In one of our tests, running the tool again preserved over a hundred references it had already placed. It created no duplicates. That's useful evidence that the tool can respect work already in the model. It is also only part of what an architect needs to know. The report has to make unresolved conditions understandable and show where a decision is still needed.
An architect can act on a specific problem: a reference couldn't be placed here, or an existing one couldn't be verified. Give them the location and the reason, and they can bring their knowledge of the project to it. A vague warning asks them to reconstruct our work first.
When you try a tool with your team, watch this part closely. Let someone use the result to do their next task. See what they can confidently continue with, what they need to check, and what sends them back to ask for help. That tells you something a stopwatch misses.
Someone still has to review the drawings. Good software should make it easier to focus that review. A senior architect may spot a construction problem in an apparently tidy drawing, or remember why a similar detail failed on another job. Their attention is valuable because they can see beyond what the program checked.
I use AI to help write and review code. It lets me move faster, which makes this question more pressing. If I save an hour building a feature and leave someone else with an hour of investigation, the practice hasn't gained much. If that uncertainty follows the drawings to another team, the cost can travel further.
This is why I care about what happens on the second run, what survives reopening a model, and what remains visible when a check fails. Those are ordinary working conditions. They deserve as much care as the first successful result.
When your team tries a new tool, stay for the part after it finishes. That's where you'll see how much work it actually took off their hands.