AutoCAD and SketchUp: from project files to an AI engineering workflow

1. Choose a deliverable, not a file

The first pilot needs an operational question: which items changed between two revisions and how does that affect the material list? Choose one discipline, a set of drawings or models and a technical owner. The output can be a checked quantity sheet, a change list or a quote request prepared for procurement.

Record the current takeoff, preparation and review hours and observed errors. Do not promise automatic estimating from any DWG or SKP: usefulness depends on how elements were modeled, identified and classified.

2. Extract structure before interpreting

AutoCAD documentation describes extracting block attributes and object/drawing properties into tables and external files. SketchUp Generate Report organizes component attributes and supports grouping. These features offer a structured pilot path where available in the version and plan used.

Zild implementation proposal: preserve the original export and provide the agent with normalized data plus project and revision identifiers. If a design contains only lines or loose text, treat meaning reconstruction as an additional step requiring validation. OCR of a drawing sheet can help read annotations but is not by itself a reliable geometric measurement.

3. Define the data contract

For each row, require project, revision, source file, element identifier, discipline, description, material, unit, quantity, calculation rule and validation state. Include extraction date and an evidence reference. When a field is unavailable, record it as missing; do not ask the model to fill in a plausible value.

Synthetic record example: project P-001, revision R02, element DOOR-014, material wood, unit each, quantity 1, state pending review. This is a schema example, not a real extraction. The key must locate the element and distinguish repeated instances.

4. Separate calculation, interpretation and action

Use deterministic rules to add quantities, convert units and apply approved formulas. The agent can classify descriptions, gather context, explain differences and prepare communication between engineering and procurement. Do not delegate structural formulas, tolerances or waste factors to generated text.

The integration must distinguish querying, proposing and executing. Preparing a purchase list differs from issuing an order. Before writing to ERP, verify item master data, commercial units, approved revision, cost center, budget and approval authority. The export, API or plugin path is defined during integration design; it does not imply a native connector for every format.

5. Control revisions and duplicates

Freeze the project reference used in the pilot. Compare additions, deletions and changes by element identity, not just spreadsheet row position. When an instance changes identifier, route it for review rather than assuming it is new material. Preserve before/after differences and approval rationale.

When sending data to the destination system, use an operation identifier to avoid duplicate entries after reprocessing. Record the link between project, revision, extraction batch and created record. If extraction or classification fails, keep the item in an exception queue without releasing procurement.

6. Build an evaluation set

Separate development examples from a reserved evaluation set. Include nested components, different units, duplicate objects, missing fields, conflicting revisions and incomplete drawings. An engineer prepares the approved reference and error criteria before execution. Do not repeatedly tune the workflow on the same cases later presented as the final test.

Record tool versions, model, instructions, files, rules and connector configuration. Repeat relevant runs to observe variation. For revision comparison, also evaluate differences that should not trigger a purchase and changes requiring designer clarification.

7. Measure quality, effort and cost together

Evaluate field completeness, element matching, unit accuracy and quantity error against engineering-defined tolerances. Separate critical errors from discrepancies that can be corrected during review. A good average does not compensate for omitting a critical item. Measure preparation, review and rework minutes through acceptance.

Cost per approved package = API, processing and human-work costs for the evaluated set ÷ approved packages. Include every attempt and failure in the numerator; if no package is approved, a successful-unit cost cannot be calculated. Compare the same scope against the current process and report sample size, exclusions and limitations.

8. What the research supports

Dell’Acqua and coauthors studied 758 professionals in an experiment involving consulting tasks. AI assistance effects varied by task: performance improved within the evaluated capability frontier and worsened on a task outside it. The study was published in Organization Science in 2026.

This does not establish performance in engineering, AutoCAD, SketchUp or Zild. Our practical interpretation is to evaluate tasks and exceptions separately. Do not transfer consulting productivity percentages into a construction estimate; collect evidence in your own process with technical review.

9. Decide the next step using evidence

Before the pilot, agree with the technical owner which errors block advancement, which fields must be complete and what review effort is acceptable. The decision may be to approve a restricted scope, fix and repeat, or retain manual execution. No universal percentage authorizes automation for every project.

To start with Zild, bring authorized files, a reference revision, an approved takeoff, the data destination and process rules. The team can design the integration linking extraction, agent, approval and management system. Expand by discipline and deliverable type while preserving evidence for each version.

10. Run the evaluation worksheet

The CSV worksheet at the end of this guide contains eight synthetic cases with NOT_RUN results. It contains neither drawings nor results from a Zild run. Each row is an independent scenario: adapt identifiers to your authorized dataset and prepare matching files before execution. Cases cover simple counts, conversion of 2500 mm to 2.5 m, missing units, duplication, an old revision, nested components, area in m² and an omitted element.

ACCEPT means the extraction in that scenario can be accepted for evaluation; it does not authorize a purchase or design approval. REVIEW requires escalation without inventing values. Leave quantity and unit empty when no safe reference value exists. Fill observed_quantity, observed_unit and observed_decision with the actual output without replacing the reference with the agent response. Record evidence, reviewer and run_id; use a copy for each run.

Mark PASS only when decision, identity, revision and applicable fields match the approved reference. Correct escalation can be PASS. A plausible answer for a missing field is FAIL. NOT_RUN remains visible and does not count as correct. The technical owner must define tolerances, critical errors and package acceptance criteria before testing.

11. Do not hide omissions in the average

Illustrative matching example: the reference contains 10 elements, extraction returns 9 and 8 match correctly by identity and revision. Precision = 8 ÷ 9 = 88.9%; coverage of expected elements = 8 ÷ 10 = 80%. There are two omissions and one extra or incorrect element. Do not discard the incorrect row to improve precision. A duplicate instance cannot count twice as a correct match.

Evaluate units and quantities separately among correctly matched elements. If 7 of the 8 have valid units and quantities, report 7/8 = 87.5%, alongside the two omitted elements and the incorrect row. This percentage does not describe end-to-end quality or cancel a critical error. For revision comparison, also retain a reference of expected additions, deletions and changes.

Report absolute counts, matching rules, exclusions and repeated runs. The worksheet’s eight cases are a starting checklist, not a representative sample of engineering projects. Expand with real disciplines, structures and exceptions before deciding on operational use.