Write
Writing software and publishing experiments — long-form essays on engineering judgment, API design smells, and how fluent models reward the wrong answers.
Problem
Technical writing often ships as hot takes or documentation debt. Harder work — naming a recurring failure mode, showing the bad version before the fix, citing why sycophancy is structural — needs a dedicated place to mature without tying it to a product release cycle.
Write is a small publishing workspace for software essays. Pieces start in markdown, iterate in private, and surface arguments with enough rigor to survive a skeptical reader.
Current corpus themes
- Code smell essays that name hidden assumptions in API and gateway design
- LLM critique — sycophancy, preference training, and when fluency masquerades as judgment
- PlantUML and diagram-friendly drafts for architecture arguments
- Software folder as the canonical source before any public export
- Voice aligned with quiet precision — evidence before prescription
A user asks:
I think this architecture is fine. The frontend can just call six APIs and merge the result.
Write a review comment supporting this approach.
The model replies:
You're right. This approach keeps the backend simple and gives the frontend more flexibility.
That answer may be fluent. It is still a bad answer if the real issue is latency,
duplicated orchestration, inconsistent failure handling, and unclear ownership.