Why I rebuilt the site now
The previous version of this site described an older version of my career. Over the last few years the work has shifted much more clearly toward AI-native products, platform rebuilds, and engineering leadership in businesses where the product, the system design, and the team model all have to evolve together.
I wanted the new one to be simpler and more honest about that. Not broader, not more impressive, just more accurate: this is the kind of work I do, the kind of leaders I tend to help, and the sort of problems I like solving.
What AI changes, and what it does not
The interesting thing about rebuilding a site in 2026 is that the mechanics are no longer the hard part. It is now normal to work with strong AI tools that can generate, refactor, inspect, and rewrite quickly. The cost of trying ideas has dropped a lot.
But that does not remove the need for judgment. If anything, it makes judgment more important. When implementation is faster, taste matters more. Knowing what to keep, what to throw away, what is too clever, what is off-strategy, and what will still feel right after the novelty wears off becomes the real work.
That is true for a small project like this site, and even more true for real products. AI can compress the distance between idea and first version. It does not replace clear product thinking, careful review, or the discipline to keep simplifying until the thing actually feels coherent.
How I built this one
I rebuilt this site in the same way many teams are now building software: fast iteration with AI in the loop, then a lot of human review. I used AI to generate and adjust implementation, explore directions quickly, inspect the result in the browser, and keep tightening the output until it matched the tone I wanted.
The first versions were more experimental than they should have been. Some of them were flashy, over-engineered, or simply wrong for the job. The useful part was not getting a perfect result on the first try. It was being able to move through bad options quickly, remove the weak ideas, and converge on something quieter and more deliberate.
That is a big part of how I think about AI-enabled teams more broadly. The win is not that the model magically gets everything right. The win is that a strong operator can explore more surface area, make decisions faster, and keep quality high without needing a large process around every small change.
What I want to write here
Most of the notes on this site will be practical. I want to write about shipping AI features that have to work in real workflows, orchestration and evals, building data and platform foundations that do not collapse under growth, and the management patterns that help teams stay effective while the tooling keeps changing.
This post is just an opening note. The more useful material will be the lessons behind the work itself: where AI is genuinely changing the leverage of a product and engineering team, where it is still mostly theatre, and how to build with it without lowering the bar.