Build for the people who use it

Understand the problem space first

Every piece of work starts the same way. Read the actual regulation, not the sector's folklore about it. Read the code, not the diagram of the code. Sit with the people who do the work, not the people who report on it. Most of what passes for a requirement turns out to be a habit somebody upstream built, and you only find the difference by going all the way down: to the three fields the federal rule actually demands, to the one customer call that decomposes into twenty-three scoped tickets, to the design written and argued to closure before any code exists.

Small changes, tested continuously

Once I understand the space, I move through it in small steps. The smallest change that can be verified, watched as it lands, kept if it survives, killed if it does not. Quality bars are ratchets that only rise rather than thresholds someone eventually negotiates down; agents get eval suites with deliberately hostile entries; and a feature that fails its field test gets killed in public, trade-off documented, so the next person inherits the reasoning and not just the absence. The loop is the discipline. Everything else is tooling.

AI makes the loop faster, not different

AI has not changed how I work. It has collapsed the cycle time of it. Understanding a problem space that used to take weeks of reading takes days. The most useful thing I do with a model is point it at my own work and ask what is wrong with it. Adversarial review, on every project, constantly, and disclosed: when a review finds real defects in my draft I enumerate them in the thread and say where they came from, because a review you hide is one nobody can calibrate against. The agents themselves get narrow powers, read access and one job each, and the guardrails around all of it are structural: generated code cannot be hand-edited, one component holds the write path, machine confidence has a ceiling only a human can cross. The wrong action is not discouraged. It is unavailable.

The bridge between business and tech

I have always been the translator between the people who fund a product and the people who build it. Stakeholder engagement is something I build deliberately, not something I assume: the funder, the partner, the customer, and the engineer each hear the same argument in their own terms, early enough to shape it, and that is how people get onboard. I hold one distinction at the center of that role: the people who use a product are usually not the people who buy it. The buyer gets a dashboard; the user gets the intake screen, and most software in most sectors is built for the buyer because the buyer writes the check. I build the other way. Validate with the person who will actually touch the thing, build for the median case rather than the showroom, and let the reporting flow from work that already serves the user instead of taxing the user to feed the reporting. The dashboards still get built. They just stop being the point.

Leading people through change

Products change organizations, and the change is the harder half of the job. I hold a Post-Master's Certificate in Leadership and Change from The New School's Milano School, and I apply it the same way I apply the engineering loop: small reversible steps, tested with the people affected, adjusted before the next one. Internally that has looked like moving an engineering function in-house from a long-standing agency and raising a team's spec discipline ticket by ticket. Externally it has looked like onboarding and training hundreds of partner sites, walking funders and government agencies from the reports they were used to onto the aggregates that actually respect the end user, and getting rooms of stakeholders onboard by showing the small working step rather than pitching the big future one. People adopt change the way systems absorb it: one verified step at a time.