Hands-on architect. Engineering leader.
I'm a hands-on architect and engineering leader, the kind who still opens the PR and reads the diff. Sixteen years across data systems, machine learning, and full-stack work: eight of them running an independent consulting practice, and most recently Director of Engineering at a US digital-health startup. Seven services, three web apps, five mobile apps, and AI-generated code shipping into a HIPAA and SOC2 production stack every day.
I ran into this problem before I started consulting on it. The agents could produce more code in a day than the team could read in a week. I know what it feels like to approve a PR you did not fully read, hoping the other reviewer does the real pass. We had the rules written down. The models are probabilistic, and the rules did not hold every time. Getting that under control, hands-on, in production, is where this practice comes from.
What I work on now
Rules are the half of the system every team already has. Under a probabilistic model they hold only sometimes: the same prompt on the same codebase can land five different ways in five runs. Most teams respond with more rules. Almost nobody builds the other half, the half that makes results hold no matter how the prompt was worded. That is the half I work on. What it looks like depends on the team and the stack; no two get the same installation. I study how teams across the industry are attempting this, and I test everything on real codebases before I write a word about it.
The same issues repeat across the organizations I have studied and helped. I track them as 20 areas across three categories of an AI-assisted development workflow. The diagnostic scores you on all 20.
Consulting
I take a small number of engagements with Series A/B engineering teams: hands-on, in your codebase, handed off to your senior engineers. Every engagement starts with a paid diagnostic; the way in is a written application.
Start with the application →