I last wrote web applications by hand roughly 20 years ago. The 10 projects on this site were built and delivered inside 18 weeks. This page is about what happened in between, because that gap is the whole story. Without an agentic coding tool, most of these applications do not get built. The question these projects answer is not how much faster a working developer becomes; it is whether someone with deep domain judgment and two-decade-old coding skills can deliver production software, and what must be true about their process for that to be safe.
Two decades, in a few lines
The background, compressed to what this page needs: two decades of enterprise reporting and database administration, which left two instincts that run through every project here. Knowing which reports resolve through an alias layer that can be repointed and knowing that a backup nobody has restored is a hypothesis, not a safeguard. The rest of the personal story is on the about page.
The AI work
It began with a chat assistant, and not with code: writing first, then troubleshooting, then production infrastructure, then a failed attempt to build an application by pasting code back and forth. That road took well over a year and has its own page, because the limits I hit there are what made the next tool choice deliberate. The short form: a chat assistant was a thinking partner with no hands, and for 8 months I was the courier between the reasoning and the code. When tooling arrived that could read the codebase, run the build, and respond to what broke, the work did not change; the courier disappeared, and the category of problem worth attempting changed with it.
The first project was taken on deliberately as a test. The industry was full of claims about vibe coding, running from revolution to myth depending on who was talking, and I would be setting direction for a team either way. I was not willing to do that from other people’s write-ups, so I used a real project to measure the tools at every stage of the work: requirements captured from Teams conversations and email replies, implementation delegated and reviewed, and at the end a requirements traceability matrix run against the finished code to find what the whole process had missed. Underneath it sat the older reason: I started out writing code, and I had missed watching something I built come alive.
How the method changed
At first I worked like a programmer with an assistant: the tool wrote, I reviewed line by line, compiled, and tested by hand. Once I could see where mistakes happened, the tool took over writing, building, and publishing, because my line-by-line review caught very little that a compile and a real test would not catch faster. What I kept was everything requiring judgment about the problem: testing against what staff do, boundary conditions, deciding something was wrong even when it worked. Most of the implementation was done by the tool, and I have been the developer, architect, product manager, and database administrator throughout. Both statements are true at once.
Four phases across 18 weeks
| Phase | Projects |
|---|---|
| 1. Build real applications | Residential Client Portal, Legacy Ticket Archive |
| 2. Take on harder infrastructure | Sluice, and the BI platform migration plan |
| 3. Systematize the practice | Application Template, Job Scheduler, Shared AI Skills Library |
| 4. Evaluate and govern the tooling itself | On-Premises AI Evaluation, Medallion Hub |
Phase one shipped real applications with real users, because only real work proves a tool can produce code you are willing to maintain. Phase two attempted what was previously out of reach: Sluice is not a project I would have taken on solo two years earlier, not because the concepts were beyond me but because the volume of careful implementation would have made the timeline indefensible. Phase three consolidated, because building fast in nine slightly different ways is the real failure mode, and the template and the skills library are the cure. Phase four turned the same scrutiny on the tools themselves: 16 models measured, 2 kept, and 3 of my own documented conclusions overturned by proper multi-sampling.
What the arc shows
Adoption was gradual and staged, not a leap. Eight months passed between first use and the first application built this way, and each stage established enough judgment to justify the next. Things get dropped on the same evidence they get adopted: 14 models deleted after measurement, a fully diagnosed authentication fix deliberately not applied because the component was being retired anyway.
Delivery is not the same as development. Getting an application to the point where an operational team fully relies on it takes roughly a year in an organization this size, and none of that got faster: review cycles, security approval, training, and waiting for a safe moment in an operational calendar are independent of how the code gets written. I would be suspicious of anyone claiming otherwise, and I would rather say so here than have someone discover the caveat after taking my word for the rest.
The bottleneck moved from capability to adoption. Once the tooling was proven, the limiting factor stopped being whether the work could be done and became whether a team would take it up. That is the problem I have made least progress on.
Mistakes are recorded, including my own published ones. Three conclusions in the model evaluation were wrong and are corrected in place, not quietly replaced. That is the mechanism that stops a mistake from recurring, and it is why the failure catalog on this site is as detailed as the successes.
What the work turned into
Partway through, the projects stopped being applications and became infrastructure for the next project: a template, a shared instruction library, a scheduler. None of those have users in the ordinary sense; their entire purpose is that the next person does not repeat something, and that is the kind of work I have found myself drawn to.
The test I set out to run returned an answer broader than the question. The tools held up at every stage I measured, and they failed in specific, findable ways that a process can catch. What that gave me is not enthusiasm but measured confidence that AI can be enabled across most kinds of work an organization does, provided someone does for each activity what these projects did for coding: test it on real work, find where it breaks, and put a person at those points. That division of labor is the idea the front page leads with, and how these projects were built is the record of practicing it.
Where this is going
The direction is ownership of how an organization adopts AI capability, not just the use of it: which work stays on infrastructure we control, which can use a stronger external model under a defined agreement, and which should not involve AI at all. The projects are the evidence that the technical side is real. The honest gap is that I have demonstrated the practice and not yet made it normal across a team, and that is the achievement I am now most interested in.