The finite-element program is not usually the only part of a structural workflow that requires software.

There may also be scripts for:

• extracting geometry from a CAD model;
• converting or validating IFC data;
• preparing geometry for finite-element analysis;
• assigning materials, sections, and structural identities;
• creating load cases and combinations;
• processing analysis results;
• generating reports and coordination models;
• checking whether input files still satisfy project requirements.

These integration scripts can have a large influence on the final engineering result. A small mistake in a coordinate transformation, unit conversion, or element mapping can affect the model before it ever reaches the analysis program. This is where I see the practical value of agentic coding. The AI agent helps with the software work surrounding established engineering applications. It does not need to become a replacement for those applications.

CAD / Rhino ──▶ Python preparation ──▶ FE program ──▶ results
      │                  │                  │
      └────── IFC ◀──────┴──── tests ───────┘
                         │
                  Git, DVC, audits

The purpose is to make these connections more explicit and reproducible.

My workflow is gradually developing around the following sequence.

A specification is not necessarily a large formal document. It can be a focused statement of the conditions that a script must satisfy. In structural engineering terms, it is similar to defining the design basis before carrying out the calculation.

For a geometry-preparation script, a specification might say:

• the source is the analytical model, not the physical coordination model;
• only exact layer paths are accepted;
• construction and reference sublayers are excluded;
• structural identifiers must be preserved;
• objects without identifiers are allowed only for explicitly exempt analysis elements;
• the output audit must record counts and validation status.

For a wind-load calculation, the specification might define:

• the source of the building height;
• the applicable wind zone and terrain profile;
• the permitted height range;
• the accepted roof regions;
• the expected load cases;
• the required coverage and overlap checks.

These requirements can be implemented with ordinary Python. I do not currently use a large data-validation framework for this purpose. For example, the FE builder rejects invalid wind geometry instead of continuing with a plausible-looking result:

height = maximum_roof_z - GROUND_DATUM_Z

if not math.isfinite(height) or height <= 0.0:
    raise ValueError(
        f"Wind building height must be in (0, 25 m], got {height!r}"
    )

This is not a structural proof. It is a guardrail against an invalid input silently entering the calculation.

I use different documents for different kinds of knowledge. An Architecture Decision Record captures a decision, its rationale, alternatives, and consequences (ADR GitHub Organization, n.d.).

In the project repository:

• AGENTS.md contains instructions for the coding agent;
• README.org describes project structure, data policy, and reproducibility;
• .llm/.adr/ contains accepted architectural decisions;
• .llm/.plans/ contains implementation plans;
• .llm/.notes/ contains research and investigation records;
• tests/ contains automated checks.

These documents are not interchangeable.

An agent instruction tells the coding agent how to work. An ADR records why an important decision was made. A plan explains how a decision will be implemented. A test checks whether the implementation still satisfies a defined behaviour. The distinction is important when an AI agent is involved. Without explicit project knowledge, the agent may produce locally plausible code that violates a decision made elsewhere.

Git is commonly associated with software development, but its basic purpose is familiar to engineers: it records changes to files over time so that specific versions can be recovered later (Git, n.d.).

In this project, Git tracks:

• Python scripts;
• configuration files;
• design registries;
• pipeline definitions;
• decision records;
• implementation plans;
• small provenance records.

This makes it possible to ask:

• Which version of the script was used?
• When did a modelling rule change?
• Which decision justified the current implementation?
• Which configuration was active when an output was generated?

The project also contains large binary files: Rhino models, IFC files, meshes, finite-element models, and generated results. These are not well suited to being stored directly in Git. DVC, or Data Version Control, addresses this problem. It stores large data and model files separately while Git tracks small pointer files and the relationships between inputs, scripts, and outputs (DVC, n.d.).

Git tracks:
  scripts, configuration, decisions, metadata, DVC pointers

DVC manages:
  Rhino models, IFC files, meshes, FE models, and results

Together they record:
  which inputs + which code + which configuration
  produced a particular engineering output

DVC is not a replacement for an office document-management system or a Common Data Environment. In this workflow, it is the reproducibility layer for computational work. The purpose is not merely to recover an old file. It is to recover the relationship between the file, the script, the assumptions, and the generated result.

I am testing these concepts in a real structural-engineering project containing scripts, analysis workflows, design documentation, exchange models, tests, and DVC-managed data.

A simplified version of its model workflow is:

Working structural model
        │
        ▼
Frozen DVC input
        │
        ▼
Validated geometry preparation
        │
        ▼
Finite-element model and structural IFC
        │
        ▼
Audit files and provenance metadata
        │
        ▼
Engineer review

The geometry-preparation stage extracts type-specific inputs and writes an audit record. Tests check object counts, structural identifiers, geometry types, elevations, and failure cases. The FE builder reads a versioned design registry rather than relying entirely on hidden mappings inside the script. It also records wind inputs, load variants, coverage areas, and other audit information.

This makes an AI-assisted change easier to review. The question is no longer only:

Does this code look reasonable?

It becomes:

Does this change preserve the engineering contract, pass the automated checks, and produce an auditable result?

The AEC industry already has tools and formats that engineers know and that form part of established review processes:

This division is deliberate.

I am not trying to replace the finite-element solver with an AI model. I am not trying to replace IFC with an opaque AI-generated exchange format. I am trying to make the software connecting these tools more explicit and reliable. This matters because trust in engineering technology is not created by a demonstration alone. It develops through familiarity, repeatable behaviour, documentation, independent checking, and successful use within an established workflow.

Two projects helped me understand this workflow more clearly. GitHub's Spec Kit provides structured processes for coding agents. Its specification-driven workflow includes specifying, planning, breaking work into tasks, implementing, and converging (GitHub, n.d.). Superpowers provides a skills-based development methodology involving brainstorming, planning, test-driven development, code review, and verification (obra, n.d.).

Amp is different. It is the environment in which the agent works. It provides threads, tools, project context, isolated orbs, and model routing (Amp, n.d.--a, n.d.--b).

I see these as different layers:

My current workflow is a project-specific adaptation of these ideas rather than a direct implementation of any one tool.

The agent is useful for work such as:

• exploring an unfamiliar repository;
• identifying relevant files and call sites;
• drafting implementation plans;
• proposing test cases;
• writing repetitive code;
• investigating error messages;
• checking whether documentation matches the implementation.

The agent should not be treated as the final authority for:

• design-code interpretation;
• structural idealisation;
• load assumptions;
• boundary conditions;
• material properties;
• numerical plausibility;
• project applicability;
• final engineering approval.

The Institution of Structural Engineers recommends treating LLM output like the work of an inexperienced junior engineer. It should be checked, and an LLM should not be treated as an independent checking engineer (Institution of Structural Engineers, n.d.--a). Its wider guidance also highlights risk assessment, data security, competence, transparency, and lifecycle management when organisations implement AI (Institution of Structural Engineers, n.d.--b). ASCE states that AI cannot replace the professional judgement of a civil engineer. NSPE emphasises verification, validation, testing, monitoring, transparency, and accountability for AI systems affecting public safety (American Society of Civil Engineers, 2024; National Society of Professional Engineers, n.d.). Automated software tests and engineering checks are complementary. Neither one makes the other unnecessary.

A structural engineer who wants to try this workflow does not need to redesign an entire office process. Start with one low-risk script.

1. Choose a repetitive but limited task.
2. Describe what the script must do.
3. Identify the authoritative inputs.
4. Record important decisions and assumptions.
5. Ask the coding agent for a plan before asking for implementation.
6. Add tests for normal cases and invalid inputs.
7. Generate an audit record.
8. Review the output independently.
9. Record the tool, version, input data, and result.

The purpose is not to eliminate engineering risk through automation. It is to prevent speed from becoming opacity.

I started using an AI coding agent because I wanted to develop structural engineering scripts more efficiently. The unexpected benefit has been that it has forced me to make more of my existing reasoning visible. The agent can help write the integration code. Git and DVC can preserve its inputs and outputs. Tests can catch implementation errors. CAD, IFC, and finite-element programs can remain the familiar engineering tools.

But the important decisions still belong to the engineer. The engineer still owns the calculation.

This post was written with the assistance of AI. I used Amp with a linked ChatGPT Plus subscription to help research, structure, draft, and edit parts of the article. Amp's model routing and subscription coverage can change over time. I remain responsible for the claims, examples, and conclusions presented here. AI assistance does not replace engineering review, independent checking, or professional responsibility. The workflow described here are works in progress. They are project-specific and should not be treated as a general-purpose verified engineering library.