Field Notes
I write about architecture, working with AI, and the decisions that keep software useful and practical to maintain. These are explanations, field notes, and lessons from building data systems and applications.
2026-10-30
A data warehouse is a map: one shared picture of the business, with older editions for history. Live systems are the street, and automated reactions are the traffic lights. Agents make checking the street cheap, so a question about right now rarely needs a continuous feed. How fresh data needs to be should follow the decision it serves.
Read field note
2026-10-29
Data teams often build the factory before the prototype works: pipelines, warehouses and schedules for a question nobody has answered once. With DuckDB on a laptop and an agent doing the building, the workbench is where data work should start, and the factory should be earned.
Read field note
2026-10-20
Building software used to mean driving every mile yourself in a car that needed constant repairs. Agents are a car that drives itself, with a pit crew on call. Each old constraint has turned into a new one: direction, understanding, verification, measured cost and ownership. Get those right, and you can reach far more destinations than before.
Read field note
2026-10-16
An agent works more independently when attempts are cheap, the task stays inside the project's existing patterns, and every attempt shows what to fix next. A data integration explored in local DuckDB and an iPhone app whose sharing feature outran its tests show what that setup involves.
Read field note
2026-10-16
An agent's "done" and a passing test suite show that the code exists. Three iPhone apps show why I check which path actually ran, on the real device, before I trust a feature, and why the answer is sometimes plain code.
Read field note
2026-07-31
Operational software used to need a crew a data person didn't have, so workflows stayed stitched together by hand. A telehealth platform built by two co-founders and their agents shows the job that remains: producing, deciding what the workflow should do, watching it run, and deciding what ships.
Read field note
2026-06-07
A dashboard is a wine list: accurate, organized and silent about what any of it means. Agents can now read the tickets, code, logs and conversations behind the numbers and help build the report as a web experience that explains what changed and what to do about it.
Read field note
2026-02-01
Git rarely felt worth the effort in solo, UI-driven data work. Agentic coding changed both sides of that calculation: agents make more changes than one person can track from memory, while also making version control almost effortless to operate. Git becomes the team’s memory, review surface, work ledger, way back when a change breaks something, and record of how the system evolved.
Read field note
2026-01-11
Buying software used to give people a head start they couldn't afford to build themselves. My WordPress site shows how that trade looks once agents make building practical, and when buying is still the better deal.
Read field note
2025-11-30
As organizations grow, they transform from solo musicians into full orchestras — and that's when the real challenge begins. Data doesn't stop being collected; it stops being aligned. Systems drift, meanings diverge, and interpretation fragments. Data engineering exists to keep the orchestra playing the same piece, in the same key, at the same tempo. In this post, I explore why coordination becomes essential at scale, and why a coordinated data layer is now the foundation custom software gets built on — including an application built on top of a request board to get decisions made faster.
Read field note
2025-09-23
An application's database stores data like sealed Lego kits: perfect for shipping one order, painful for counting every red brick. Parquet stores it like bins sorted by piece. Knowing which one you're pointing an agent at decides whether its analysis takes seconds or slows the application for everyone.
Read field note
2025-08-31
Lunchboxes, buffets, and pantries explain how operational databases, warehouses, lakes, and lakehouses organize data—and why an arrangement that suits one job can create extra work for another.
Read field note