10 posts
AI & Tools
Agent workflows and tools examined through experiments, worklogs, and practical limits.
This is one body of work organized into five editorial tracks. Each track keeps a stable voice and reading rhythm, while tags connect related ideas across the whole collection.
Subscribe to the RSS feed to stay updated with new posts.
Every post belongs to one track with its own subject, reading rhythm, and voice. Tags connect ideas across tracks.
10 posts
Agent workflows and tools examined through experiments, worklogs, and practical limits.
17 posts
Architecture, reliability, languages, and the mechanisms behind engineering choices.
16 posts
Personal history, retrospectives, portfolios, and observations from work in progress.
6 posts
Ownership, autonomy, communication, and the systems that shape how teams operate.
20 posts
The connected framework, from Search, Drive, and Renew to practical applications.
Blameless engineering, borrowed from Google's SRE culture, is usually filed under postmortems. But the postmortem is only the last place the culture shows up. Blamelessness shifts all the way left into how you design systems, and it lands on one uncomfortable rule: the team is the unit of work, and heroes are a symptom of a system that is not yet well crafted. In the age of agents, where there is no one to blame, that rule stops being a nicety and becomes the only way to debug at all.
I used to say bad version, bad rollout, bad payload. I stopped, because a version isn't good or bad in the abstract. It's a distribution of outcomes across a population of users, configs, and use cases. The same payload can be flawless for 99% and broken for 0.5%, and calling it bad collapses that spectrum onto one label that quietly dictates how you triage, communicate, and remember the incident.
When I was starting out, hesitation held me back from trying things. Over time it faded, not because I got braver, but because I got a better handle on risk. Fearless engineering is not the absence of caution. It is a calculated read of what you know, what you do not, and how far a change can reach.
Nine years of work notes, from sort-of-daily Markdown files in 2017 to monthly Word docs to a single yearly running document, and how AI agents finally took over the writing through worklogs.
A reflection on why the word impact is too overloaded for work conversations, and why accomplishments and outcomes are clearer alternatives.
Salty is not the opposite of sweet. They are separate receptors, separate dials, and salted caramel exists because you can turn up both at once. Most 'balance' advice is secretly slider-thinking. The method is to catch the false opposite, test for a real tradeoff, and go to the corner everyone told you was impossible.
Time matters, but expertise does not come from time alone. In software engineering, AI makes the missing part impossible to ignore: growth comes from new constraints, real feedback, rising stakes, and ownership of outcomes.
Interesting motivation is intrinsic, not extrinsic. Mastery (the pull to get better), Autonomy (ownership and a map of what you control), and Purpose (the why that renews) are the three forces that make work gel. Find your why, and let the Quest Engine help you search for a more interesting one.
There's a natural-sounding intuition that autonomy is about exploring, so maybe it lines up with Search. It turns out backwards, and the reason it's backwards is the most useful thing about the framework: the mapping between Search/Drive/Renew and Mastery/Autonomy/Purpose is fixed by when each force acts, not by what its name sounds like.
Configuration earned its place next to code: versioned, reviewed, owned. The corpus of context that aligns a team (design docs, contextual documents, the why behind the system) deserves the same standard. It's the operating system humans run on, and now the grounding agents read to understand how we work.