
Read-Only Is Not the Same as Safe
Preventing writes protects one boundary. An agent may still read sensitive data, send context to services or expose it in outputs. I want those paths explicit.
Notes on frontend development, software design and the practical details of building applications.
New here? Start with The React Playbook— a 56-part path →
Preventing writes protects one boundary. An agent may still read sensitive data, send context to services or expose it in outputs. I want those paths explicit.

Generated code can be correct and still be expensive to change. I care whether the next engineer can explain its boundaries without reconstructing the prompt.

A plausible API can belong to another release, runtime or feature mode. I want agent advice checked against the package and configuration the project uses.

An agent can validate a change in an environment nobody else can reproduce. I want the handoff to explain the runtime, dependencies and state behind the result.

A model upgrade can change tool use, stopping decisions and recovery, not just answer quality. I would test the workflow contract before trusting a new default.

A coding agent must read repository content without treating it all as authority. I want the boundary between useful evidence and instructions to stay visible.

Generating a patch and understanding its consequences consume different resources. I want agent workflows to respect the capacity of the people reviewing them.

An AI agent made a sound improvement, and I agreed. A colleague found his task implemented in my PR. What should review verify beyond the quality of the code?

Micro-frontends and a modular monolith can share strong code boundaries. Their practical difference appears when old and new parts coexist: shell contracts, assets, dependency versions, cross-app state, and rollback need an operating agreement.

An AI agent can write code and tests that agree on the same mistake. I want the expected result to come from somewhere other than the implementation under test.