Thoughts

Notes on how I think about technical work, systems, and complexity. Not polished essays, just snapshots of understanding at a given time.

More will follow…

You are either a scientist, in which case you must know how to reason with data, or you are not. Scientists have always worked with data long before the title existed.

The tools changed, the label changed, but the core skill did not: forming hypotheses, understanding uncertainty, and extracting signal from messy reality. Calling it a new role sometimes hides a more fundamental question: do you actually understand the system you are interacting?

Specifications describe what a system should do, but they rarely constrain how low-level architecture emerges: state placement, timing assumptions, implicit coupling, data flow. What people often call “drift” is not a sudden loss of goal, but a structural drift: thousands of tiny design choices, each slightly misaligned, slowly turning the system into something you didn’t intend and can no longer easily fix. Vibe coding is powerful. But in practice, reliable setup (for me) is simple: the human owns the architecture and decisions; the agent executes small, small and well-scoped tasks. Speed is great, but the details are usually what decides whether a project survives.