Tool Development

For the past months I have been building Obliqo as a solo founder — and tonight I want to share the thing more than the launch, because the launch is the small part. Obliqo exists because of something this community has named for years. The AI gives you text that looks finished before the thinking behind it is. You publish faster than you can verify. That is the gap. What I built is a small extension that runs four agents over the draft you have just written — inside the tab where you write (Gmail, a PR description, the body of a post). They do not rewrite. They do not flatter. They tell you where the draft does not hold. Then they leave you with a question only you can answer. I built it because I needed it. Not in the dogfooding sense from product talks. In the cruder sense — the dogfounding sense — that for months I was the first user of a tool I had not finished, working in conditions where I knew I would publish badly without it. Necessity under pressure. The product is the sediment of that contradiction: I built a tool against frenzy from inside the frenzy. The extension is live now: Chrome Web Store. The webapp is at obliqo.pyragogy.org. One small note about Chrome: when you install, you will see a warning that the extension is “not trusted.” Nothing dangerous. I am a new developer and Google extends trust over time. Chrome is asking me to earn it — which is also what I am asking the writer to do, with their own drafts, before they ship. Fair enough. The blog has the longer version of this story, with the contradiction left open: I Was the First One Who Needed It. I do not have all the answers about how this scales beyond my own case. I am hoping some of you will find a way to break it, and tell me what you found.

[image: 1775719135114-logo-obliqo.png] I started Obliqo from a simple intuition: what if AI should not help us write faster, but help us think more honestly before we publish? That is the experiment. Obliqo is not being built as an AI writer, a ghostwriter, or a polishing tool. It is being built as a friction engine: a system that introduces structured resistance into the writing process so that a draft can be challenged before it becomes public. The current handbook page is here: Obliqo — The Friction Engine The wiki holds the more stable version of the idea. This thread is for the unstable part: doubts, objections, tensions, failures, and possible improvements. The core question Obliqo starts from one conviction: not all friction is a defect Sometimes friction is exactly what prevents a text from hiding behind fluency. A draft may sound clear and persuasive while still containing: weak reasoning rhetorical shortcuts unexamined assumptions more certainty than it has earned Obliqo is meant to make those things harder to ignore. But that raises a harder question: what kind of friction is actually useful, for whom, and under what conditions? That is the question I would like this thread to explore. A simple example Imagine a short text that sounds strong on first reading. Obliqo does not rewrite it. It does not make it smoother. It may simply interrupt it. It may say: this conclusion comes too fast this tone claims more certainty than the argument supports this sentence hides a shortcut instead of making the point this draft is avoiding the real question That interruption is the value. Not because friction is always good, but because sometimes a text needs resistance more than polish. What I want to discuss here I would especially like to hear thoughts on questions like these: When does friction improve thinking, and when does it only discourage the writer? What kinds of weak reasoning should Obliqo become better at detecting? How can AI challenge a draft without becoming theatrical, arrogant, or empty? What separates useful resistance from mere negativity? Should Obliqo remain strictly non-generative, or are there narrow exceptions worth discussing? How can this stay open without losing its identity? Contribute by disagreeing You do not need to agree with the current framing. In fact, disagreement is part of the point. You can help by: questioning the assumptions behind Obliqo proposing new friction patterns describing where this method would fail suggesting educational, editorial, or research uses helping define the line between assistance and substitution One thing I want to protect Obliqo should not become just another system that flatters the user by making everything easier. If it grows, I would rather see it grow slowly and honestly than turn into a convenience machine with a more intellectual logo. That is why this conversation matters. If you have a critique, a doubt, or a better question than the ones above, bring it in.