A place for working notes

There is a useful middle ground between documentation and a finished essay.

Documentation explains what a system does now. A polished essay usually wants a conclusion. A lot of engineering work lives somewhere between the two: a decision made with incomplete information, an experiment that exposed the wrong abstraction, or a failure whose recovery taught more than the implementation did.

This site is for those working notes.

Engineering management from practice

I have spent much of the last eight years building and leading engineering teams. The management problems I want to write about are concrete ones: deciding what a team can actually deliver, hiring under uncertainty, developing successors, controlling scope, and staying technical without making every important decision depend on the manager.

I do not expect those lessons to become universal rules. Team size, product stage, customer constraints, and the people involved all change the answer. A useful article should explain the context and trade-offs well enough for someone else to decide what transfers.

Software and AI systems

I also continue to build software. Current experiments include an Elixir and Phoenix accounting application, local multimodal search, LLM extraction and verification, and coding agents working inside real repositories.

The recurring questions are mostly about boundaries:

• what should be encoded as a domain invariant;
• where a model can help without quietly becoming the decision-maker;
• how background work reports durable failure instead of spinning forever;
• when a small service boundary is better than forcing everything into one language;
• how agent work remains isolated, testable, reviewable, and under human control.

Structured output is not proof of correctness. Human review is not a failure when uncertainty is intentional. For these systems, I treat production readiness as part of the product, not as cleanup after the interesting work.

A deliberately small website

Articles are Markdown. Astro turns them into static HTML. Cloudflare serves the result. There is no database, CMS, client-side framework, or comment system to maintain.