My work at SITE sits at the intersection of software engineering, AI, and the operational realities of property assessment. Coding agents now help us understand systems, design, write and test code, and investigate problems. The improvement is real, but using AI does not automatically make a company AI native.
I often describe the difference as becoming 50 percent faster versus five times faster. The first comes from adding AI to an existing process. The second requires redesigning the process around what AI makes possible.
At SITE, being AI native also means responsibly connecting AI to the context where work already happens: the codebase, living specifications, Jira tickets, Slack conversations, and Magic Minute meeting notes. That continuity helps AI carry intent from discussion into implementation, review, and the next iteration.
Rethinking Customer Facing Product Development
Traditional product development begins with a product requirements document. Product writes the PRD, design creates mockups, engineering builds the software, and stakeholders interact with it weeks or months later.
That process developed because software was expensive to implement. AI coding agents change that assumption. When a working prototype can be created quickly, teams can test ideas instead of debating every detail through abstract documents and static designs.
The prototype becomes a shared language among product, design, engineering, and business. People can respond to actual behavior rather than imagining what a document will become.
Requirements and rigor do not disappear. Harrison Chase captured this tension in How Coding Agents Are Reshaping Engineering, Product and Design: “PRDs are dead” and “long live PRDs.”
One way to describe the new approach is spec driven development. Unlike a PRD finalized before implementation, the specification is a living, versioned source of truth kept close to the software. It captures intent, constraints, acceptance criteria, and important decisions. AI agents build from it, reviewers validate against it, and feedback continuously improves it.
The process becomes spec driven and prototype led:
Intent, living specification, working prototype, expert review, real world feedback, updated specification.
Product, design, engineering, and business can contribute throughout the cycle rather than handing work from one function to another. Implementation gets faster, but product judgment, architecture, security, usability, and review become more important.
At SITE, we are applying this approach while developing customer facing roof and bid workflows. Domain experts, product, design, and engineering work through diagrams, prototypes, and focused deep dives together. Living feature documents sit beside the code, record scope and open questions, and change as the team learns.
A roof workflow exposes relationships among observations, recommended repairs, and customer scope. A bid workflow must carry that work through vendor proposals, award, changes, and closeout. Those details become clearer through working software and repeated review. Agility does not mean lowering standards. It means reaching the truth sooner.
Building Internal Tools for Workflows That Keep Changing
Internal applications face a related challenge: business processes often change faster than software. Customer volume grows, needs and data types change, priorities shift, and responsibility moves between SITE teams and external partners. An application built around a fixed path creates workarounds whenever the operating model changes.
Our facade assessment application shows what this means operationally. Work may move between SITE experts and external partners, requiring different permissions, quality control gates, collaboration rules, or reports. Living specifications capture those changes through pipeline stages and internal versus shared feedback. Building in small slices lets the software follow the workflow while preserving consistency.
Pavement AI shows adaptation at the model layer. A new model or data type may require different preprocessing, expert feedback, validation, and reporting. Separating those stages lets us improve a model or change how feedback is gathered without rebuilding the entire process. Expert corrections support the next training cycle, allowing the model and its workflow to evolve together.
Making AI Adoption a Learning System
The final piece is creating an environment where AI knowledge moves across functions and the people closest to a workflow can help redesign it.
At SITE, our AI Cafe is a laboratory for peer learning. It combines demonstrations, open office hours, real work experiments, and responsible use guidance. Martha Valenzuela, our Marketing Manager, began as an early adopter. She connected AI with her existing applications, shared an automation that moved website leads through Salesforce and Slack, and became a facilitator for others.
Colleagues bring real problems involving flight rescheduling, operational status requests, and office move planning. Each session turns individual experimentation into shared organizational capability.
Becoming AI native does not mean turning every employee into a software engineer or treating every prototype as production ready. It means enabling domain experts to identify opportunities, test solutions, and work with technical reviewers. Human judgment, security, product sense, and domain expertise become more valuable as implementation becomes easier.
An AI native company is not measured by how many AI licenses it owns or how much code its agents generate. It is measured by how quickly it can turn intent into working software, learn from real users, improve its models, and adapt as the business changes.
The question is no longer simply, “How can AI make our existing process faster?”
The better question is, “What process would we design if AI had been part of it from the beginning?”