Notes from building with modern language models and automation — what held up in practice, what quietly fell over, and what we would do differently.
The ground this track covers.
Prompt design, tool use, retrieval, and evaluation for real workloads — the engineering around the model rather than the model itself.
Connecting services into workflows that run unattended: scheduling, API integration, error handling, and knowing when a human still belongs in the loop.
Turning messy source material into structures worth querying, and interfaces that let a reader interrogate the data rather than take a summary on trust.
Static sites, plain files, few dependencies. Systems a single person can still understand and maintain two years later.
Language models are genuinely useful and routinely oversold, and both facts matter at the same time. The useful part is real: they compress the distance between an idea and a working draft, they read more material than a person has hours for, and they are patient with tedious structure work.
The oversold part is also real. A model will produce a confident answer whether or not it has grounds for one. It does not know what it does not know. Any system built on top of one has to assume that and be designed so a wrong answer is visible and cheap rather than silent and expensive.
The work behind this site leans on ordinary, boring infrastructure: static HTML, version control, scheduled jobs, and small scripts. Models help produce and check that material; they do not sit in the serving path. A page that renders without JavaScript is a page that still renders in five years.