Engineering choices, automation boundaries, business lessons, and the parts that changed when a prototype met real use.
A feature can exist in source and still be absent from the thing a person can install. A test can pass without proving the real workflow. An upload can finish without becoming the public release.
I keep separate language for implemented, merged, deployed, released, and accepted because each boundary answers a different question. The distinction can sound fussy until the day a confident status report is the only thing standing between a user and the truth.
AI lets me explore more directions, write more tests, and move between engineering, design, operations, and communication without pretending they are separate worlds.
It does not get the last word. I still have to understand the system, decide which tradeoff is acceptable, verify what happened, and own the result. The useful boundary is not human versus machine. It is leverage versus abdication.
It is easy to answer friction by adding another control. The harder move is to notice when the interface is exposing a process that should not exist.
I try to trace the repeated action back to the decision underneath it. If the system already has trustworthy evidence, it should carry that evidence forward. The person should spend attention on the judgment, not on reassembling context the software already knows.
Local-first is not a slogan for me. It is a practical answer when the user’s material is private, the tool should remain useful without another account, or a product ought to be giftable without creating a permanent hosting bill.
It carries tradeoffs: synchronization is harder, each machine has its own state, and remote workflows need explicit design. Those limits are worth naming because architecture is not a personality. It is a choice made for a particular kind of trust.