Cast by decent-artlu
Show the cast this replies to
## 3. stricter is better The Rust code review stage surfaced an issue: the app could get stuck if things happened in a specific unlucky way. State appears indeterminate but most likely fine, and it's correct to proceed. But in the meantime, state gets updated outside of our system (i.e., we read the internet). Broadly, this is a "race" and it's standard practice to deal with race conditions by applying "locks". The architecture did this, but its specific implementation was soggy. The Typescript side had passed code review, because it was looser and the implementation looked plausible. It's like asking, *if a Scot and an Irish person have a sprog, will they be ginger?* You can answer this with some probability, and make your decisions accordingly. *But if you ask the question as, if ginger Scots and ginger Irish mate, how ginger will the population be, you can see the segmentation of outcomes more easily, and assign more precise probabilities to each combination.*
1 reply
## 4. do not "meatproxy between agents" The agent identified six permutations of fail cases, and hardened the lock implementation on the Rust side without touching the Typescript side. Then I handed the Typescript agent the Rust agent's enumeration, asking > the Rust review discovered a bug that it claims affect s the Typescript baseline. Is this true? The agent confirmed, and described the situation in detail.
## HERE IS THE KEY Instead of instructing the Typescript agent to copy the Rust agent if it agreed with the assessment, I prompted: > this looks like a suboptimal outcome > how would a clean codebase address the situation holistically? not necessarily routing around the identified bug, but eliminating its getting stick (all typos remain btw) The agent decided to re-design the locking mechanism more elegantly. Then I asked the Rust agent, which had just finished hardening the original design, to assess the Typescript agent's rebuild. The Rust agent discovered the Typescript agent had re-created a useful core primitive available natively on the Rust side (flock). And it delightedly replaced its clumsy, but thoroughly hardened solution, with the more elegant approach. [technical deep dive](
## Conclusions Blind process is sufficient to produce correct code. It is not sufficient to produce clean code. Path dependency produces layers of sediment, which eventually clogs your pipes. In software eng organizations with very high standards, silt doesn't get into the water because code review catches it. But maybe those organizations move slower than startups. In an AI pipeline, the human and/or agentic conductors need to cut off the anti-patterns that blind process can produce. (shared free on [my Bear blog](artlu.bearblog.dev/when-blind-process-isnt-enough/) for about a month, then gated by x402)
