From conversation to implementation
Clear requirements for developers. Clear explanations for everyone. I connect the business need with the technical decisions and keep the people using the solution in the conversation.
Listen to the people doing the work. Find what’s getting in their way.
Turn the problem into clear requirements: what to build, why and how we’ll check it.
Build the software, connect the systems and check what happens when things go wrong.
Review the result with the client, explain the tradeoffs and document how it works.
In practice
A better form, an API connection or AI—chosen for the problem at hand.
Find the information in emails, documents and spreadsheets. Identify what the business needs.
Interactive example with invented data.
Keeping a project aligned
Most of my code is written with AI tools. What makes that work is the discipline around it: what an agent is told, what it may touch, and how drift gets caught.
Every piece of work is a ticket with machine-readable scope, an approval envelope, hard dependencies and a closeout that states what is not claimed. More than 460 have shipped on the Keystone platform.
How the ticket system worksDurable orientation files with pointers, replaceable snapshots, agent-harness contracts with hard constraints, and a do-not-claim file that overrides everything. Any model or person can be oriented from the filesystem in minutes.
How the brains are organizedHard gates block false public, live or runtime claims; everything else ships as the largest useful safe slice. Generated status with a drift check, lockstep fixture tests and an offline verification gate catch what documentation alone would miss.
Where these run todayUsed in my projects
Each tool links to the project where I used it. Nothing here is a certification; it is what the work was built with.
I use Claude and Codex alongside my own review and testing: they draft, I read every line that ships, and the offline test gates decide.
Have a project or a question? I’d like to hear it.
In practice