Agentic Software Systems: Applying LLMs to Production Spatial & Web Engineering
Specification-driven agent workflows, repository-level governance, deterministic test harnesses, and human verification across spatial data and web platforms.

- Governance
- AGENTS.md & Strict Specs
- Validation
- 100% Deterministic CI
- Workflow
- Spec → Agent → Tests → PR
- Scope Control
- Mandatory Human Review
- agentic-engineering
- llm-harnesses
- test-driven-development
- agents-md
- ci-cd
- python
- astro
Evidence
Overview
Software engineering with Large Language Models (LLMs) has shifted rapidly from interactive browser chat boxes to automated terminal agents and IDE runtimes (such as OpenAI Codex, Claude Code, and Cursor). While these tools can accelerate implementation, deploying them in production engineering environments introduces specific operational risks: architectural drift, hallucinated dependencies, silent logic regressions, and sprawling diffs.
In my consulting practice and engineering leadership roles, I treat autonomous agents not as independent architects or decision-makers, but as high-velocity junior implementers operating strictly inside closed, test-driven harnesses.
This case study documents the governance framework, specification patterns, and deterministic verification pipelines I use to integrate agentic workflows across production spatial data pipelines (such as Geoneon’s wildfire evacuation models) and modern web architectures (such as the GRIP Sport Australia rebuild).
Repository-Level Governance: The AGENTS.md Standard
The public APEMAP case study provides an inspectable example: repository instructions, development checks, tests and scoped issues. Its Python/DuckDB pipeline and versioned research releases show the workflow on a maintained data project. Architecture and evidence interpretation remain human responsibilities.
Autonomous coding agents typically read repository files and generate code based on localised prompt context. Without clear operational boundaries, agents default to inventing patterns, pulling in unvetted third-party packages, or mixing conflicting programming paradigms.
To prevent this, every managed repository incorporates a standardised AGENTS.md (or equivalent instruction file) at its root. This document serves as the runtime operating contract for any model executing in the codebase:
- Architectural Invariants: Explicit rules prohibiting unauthorised architectural decisions. For instance, forbidding the introduction of client-side JavaScript frameworks in static content pipelines, or requiring that geometry calculations remain decoupled from host CAD/BIM API runtimes.
- Dependency Constraints: Strict whitelists of permitted libraries and runtime tooling. Agents are prohibited from modifying
package.json,pyproject.toml, orrequirements.txtunless explicitly assigned a dependency upgrade task. - Coding Standards & Banned Idioms: Explicit patterns for error handling, type definitions, and file layouts. Banned antipatterns (such as untyped dictionaries, silent try/except blocks, or mutating function arguments) are specified up front.
- Editorial Tone & Documentation Rules: Directives enforcing factual, calm technical documentation (the “Bro, Chill” rule), eliminating hyperbolic marketing adjectives, breathless prose, and exaggerated failure modes.
By codifying these invariants into the repository’s file tree, every agent invocation starts with grounded organisational context.
The Five-Stage Agentic Lifecycle
Rather than issuing open-ended conversational prompts, development is structured into a reproducible, five-stage cycle:
1. Issue & Specification
Every task begins with an explicit issue or written specification defining:
- The exact input parameters, return signatures, and failure modes.
- Allowed file paths to modify (preventing out-of-scope refactoring).
- Acceptance criteria and target test cases.
2. Scoped Agent Context
Agents are invoked against the minimal set of files required for the task. Flooding agent context with entire codebases degrades reasoning quality and increases hallucination rates. Targeted tool definitions and file-scoping ensure the model focuses solely on the relevant module.
3. Agent Implementation
The agent executes the defined task: writing utility algorithms, implementing data transforms, or refactoring layout components within the bounds set by the specification.
4. Deterministic Test Validation
Before any diff is presented for human review, it must pass deterministic test fixtures:
- Unit tests (
pytest,nunit, ornode:test) validating algorithmic edge cases. - Static type checking (
tsc --noEmitormypy) ensuring strict interface conformity. - Automated linters and formatters enforcing repository syntax rules.
If a test fails, the agent must inspect the failure traceback and repair the implementation against the original specification—not modify the test assertions to make them pass.
5. Mandatory Human Code Review
The software engineer conducts line-by-line diff review. The engineer checks for subtle semantic errors, performance regressions, security boundaries, and architectural fit. No agent-generated pull request is merged without human sign-off.
Production Implementations
1. Spatial Hazard Modelling: Wildfire Evacuation Routing (Geoneon)
At Geoneon, calculating the Wildfire Evacuation Exposure Index (WEEI) required converting disjoint road centrelines into routable topological graphs and snapping thousands of building parcel centroids to the nearest accessible road segment.
- The Problem: Road network datasets frequently contain topological errors—dangling dead-ends, overshoots, duplicate vertices, and disconnected cul-de-sacs. In addition, geometry calculations must be computationally efficient across statewide datasets.
- Applying the Agent: An agent was tasked with implementing pure mathematical helper functions for geometric edge snapping and vertex distance calculations using Shapely and NetworkX.
- Deterministic Test Harness: Prior to generation, I established a comprehensive test fixture containing synthetic GeoJSON topologies: closed loop roads, complex cul-de-sacs, parallel dual-carriageway splits, and isolated network islands. The agent iteratively ran
pytestuntil all topological edge cases resolved correctly. - Human Verification: The human engineer verified coordinate reference system preservation (ensuring conformal metric projections like UTM Zone 55S / EPSG:32755 rather than unprojected geographic degrees), audited spatial index memory consumption under large loads, and validated the scoring output against ground-truth municipal road networks.
2. High-Performance Static Web Architecture (GRIP Sport Australia)
Migrating GRIP Sport Australia from a legacy GoDaddy site builder to Astro required restructuring hundreds of unstructured product specifications into clean, typed components.
- The Problem: Converting unstructured HTML widgets and tables into modular Astro components and TypeScript data models without introducing client-side JavaScript overhead.
- Applying the Agent: The agent was assigned discrete component conversion tasks: transforming raw HTML pricing grids and towbar clearance tables into typed Astro components governed by strict Zod schemas.
- Verification Pipeline: Every component was validated using
astro check, TypeScript strict mode (tsc --noEmit), and automated link integrity tests. - Human Review: Reviewed accessibility tree outputs, keyboard navigation patterns for mobile menus, and validated that zero client-side JavaScript bundles were emitted to production.
Scope Controls & Human Accountability
Agentic software engineering significantly accelerates bounded tasks—boilerplate generation, test case expansion, mechanical refactoring, and data model mapping. However, engineering integrity depends on firm scope controls:
- No Autonomous Architectural Decisions: Agents do not determine system architecture, database schemas, or core operational patterns. Those decisions are made by experienced engineers based on system requirements.
- No Self-Validating Systems: An agent cannot be the sole author of both a feature and its validation criteria. Acceptance tests and boundary conditions are formulated or explicitly reviewed by human engineers.
- Accountability Remains Human: LLMs do not own outcomes. The engineering practitioner remains entirely responsible for code correctness, security vulnerabilities, edge cases, and operational stability.
By pairing strict repository-level governance (AGENTS.md) with automated, deterministic testing, agentic tooling becomes a reliable multiplier for thoughtful software engineering.