Essays
What I am thinking through.
Essays on engineering, product systems, parenting, judgment, and one current obsession: how AI can compress the loop from idea to evidence without weakening judgment.
Current chapter · Six-part field guide
Building an AI-first development system
One current obsession: designing the path from an idea to a rapid prototype, meaningful evaluation, real user evidence, and the next better release without losing functional intent.
- Part 1
AI-first development is a system, not a coding trick
Code generation is useful, but reliable AI-first development needs requirements, context, boundaries, verification, release discipline, and a feedback loop. - Part 2
Functional requirements are the control plane
AI-assisted delivery stays aligned when functional behavior, constraints, exceptions, and acceptance evidence are treated as durable engineering inputs. - Part 3
Context routing only works when the source of truth is boring
AI workflows get useful when the right Markdown files stay refreshed, routed, and accountable to one source of truth. - Part 4
Parallel agents need boring contracts too
Multiple agents create leverage only when scopes, ownership, dependencies, invariants, evidence, and stop conditions are explicit. - Part 5
If the agent cannot prove it, the work is not finished
A generated diff is a proposal. Completion requires risk-aware evidence that connects functional requirements to tests, browser behavior, and known limitations. - Part 6
The real measure of AI-first engineering is the second change
The first implementation can demonstrate speed. The next changed requirement reveals whether the system can adapt without losing its existing guarantees.
Independent essays
Ideas that stand on their own.
Parenting, engineering, and the practical judgments that shape how I build and live.
I let my daughter be cautiously dangerous
Parenting, to me, is not removing every sharp edge. It is giving my daughter small, honest encounters with risk so she can build capability, judgment, and the confidence to repair what goes wrong.
AI will improve the product cycle, not erase engineers
AI will tighten the loop between product design, customer feedback, and front-end delivery, but systems still need engineering judgment.
The best front-end architecture is a promise about future change
I judge architecture by how calmly it lets a team change its mind after the first release.
I want Angular components to speak the language of the product
A component API should read like the product decision it represents, not like a bag of styling switches.
Loading states are where a product tells the truth
A spinner often means the interface has avoided saying what is really happening.
AI interfaces should admit uncertainty instead of hiding it
AI SaaS products need UI states for partial answers, missing context, low confidence, and human review.
How I review complex front-end pull requests
I review behavior, ownership, and missing states before I spend energy on stylistic preferences.
Designing Angular components that survive product complexity
Components last longer when their boundaries match responsibilities users and teams already recognize.
My bias toward boring state management
Large Angular apps usually need clear ownership and typed transitions more than dramatic state machinery.
Dense enterprise UI deserves more respect
The hardest screens are often the quiet ones where users scan, compare, filter, and act all day.
The browser is still the most interesting application platform
I keep coming back to browser-native experiments because they make invisible systems feel tangible.