Writing from inside the build
Notes from active projects, design changes, trade-offs, and technical decisions while the work is still moving.
Editorial notebook
Build in public
Think in public
OLEXIY LYSYTSYA
Development logs from the messy middle.
A personal notebook for development logs, technical essays, and conceptual writing about software, agents, and system design.
Writing tracks
Three ways this site thinks
Logs from active work, essays that search for patterns, and concepts that need language before polish.
Trying to explain the deeper pattern
Essays about software practice, tools, agent workflows, and the structures that keep showing up beneath the surface.
Naming ideas before they calcify
Early concepts, half-formed models, and frames that help make new technical territory easier to describe.
Featured essay
Start with a representative piece
The best first impression is not a claim. It is a page of writing.
You Can't Unit Test an LLM Pipeline. Try Chaos Engineering Instead.
Multi-turn AI orchestration fails in ways that no assertion will ever catch. The fix is not better metrics, but chaos engineering for LLM pipelines.
Recent writing
Latest essays and build notes
A running archive of development logs, technical arguments, and concepts still taking shape.
You Can't Unit Test an LLM Pipeline. Try Chaos Engineering Instead.
Multi-turn AI orchestration fails in ways that no assertion will ever catch. The fix is not better metrics, but chaos engineering for LLM pipelines.
Architect v0.3: tightening the discipline loop
The latest release makes the planning loop stricter, clearer, and much harder to skip when the urge to vibe-code kicks in.
Why Architect stays desktop-first
Keeping the product local changes the trust model, the UX, and the kind of features worth building.
SQLite as the memory layer for a local tool
A small local database is often enough for the kind of continuity an AI-assisted desktop app actually needs.
Manifesto
What this notebook is trying to become
A personal body of work that compounds by clarifying decisions, patterns, and language over time.
The ambition is simple: turn ongoing work into a sharper point of view.
Not every post has to be definitive. It does have to be honest, useful, and specific enough to survive rereading.
- Write before the story becomes too neat.
- Treat implementation details as evidence, not decoration.
- Prefer durable ideas over hot takes.
- Leave behind technical breadcrumbs worth re-reading.