Notes.
On building systems, running the work,
and using AI in practice.
How to check an agent's work before accepting it
A small regression test, an acceptance record and a review routine for separating finished code from a convincing completion report.
A small patch can fix the wrong place
Follow a bug through two callers, reject a partial fix, and test the correction where the behavior belongs.
Give coding agents the same project context
Keep one small project entry point, connect each client explicitly, and check the files and facts a fresh session retrieves.
Before I automate it
A worked example and a copyable worksheet for deciding whether a recurring task needs a script at all.
Before you add another dependency
Check whether the project already solves the problem, using a read-only inventory and one concrete acceptance test.
Write down what a rule is protecting
A practical way to review a team rule before enforcing it, making an exception, or getting rid of it.
You're absolutely right. What changed?
A paired-prompt exercise for telling a useful correction from an answer that merely follows your confidence.
I love Linear. Why did I build Hydrant?
Building another issue tracker doesn't require pretending the one I like is broken. It does require being honest about which decisions I want to own.
An assistant's memory needs a source
Audit one remembered claim by tracing its source, separating inference from evidence, and checking what is still true before correcting it.
Teach the procedure, not the whole conversation
Turn a repeated support-writing task into a small Hermes skill, with explicit inputs, stopping rules and human checks for reuse.
A timeout doesn't mean nothing happened
Run a small retry experiment that separates a lost reply, a duplicate command and an edit based on an old version.
Read-only should be a permission, not a prompt
Test an integration's authority directly: a read-only connection should fail to write even when the caller asks it to.