https://appsumo.com/products/rhino/?utm_source=sendfox&utm_medium=email&utm_campaign=okay-i-built-a-free-voice-dictation-tool Not affiliated with the product or AppSummo

A model reviewing its own work is not a review. It is the same judgement run twice, and it agrees with itself both times. - Maker and checker are separate passes - whatever produced the work does not get to grade it. - Fresh context, not just a fresh prompt - a different chat, ideally a different model, carrying none of the reasoning that built the thing. - A number it cannot argue with - a test, a diff, a count. Prose review on its own will find reasons to approve. The failure mode is not that a model lies to you. It is that it is still holding every assumption that produced the work, so asking whether the work is good just reasons forward from those assumptions and lands where it landed the first time. I have had this go wrong with real stakes on it. Folder bloat that survived an adversarial review and two further passes on the strongest model I had. A multi-repo restructure proposed off one of three files the model had actually read. A Git migration recommended on the grounds that we had a backup, which we had made ourselves an hour earlier. Every one of those cleared a self-check first. What changed it was making the check structural rather than something I remember to do. In my YouTube workspace no finding enters the register until it has been surfaced to me at the close of the query that produced it, so the system proposes a belief and a human commits it. In phronesis the distillation pass runs behind an eval gate allowed to reject the commit outright, so the pass that writes the profile is never the pass that decides the profile is good. Metrics carry the other half. A verdict written in prose can always be argued into place, a count or a failing test cannot - if the only evidence something worked is a paragraph the model wrote about its own output, there is no evidence. Where has a self-review waved something through that it should have caught, and what do you actually use as the outside check - a second model, a fresh chat, a test, someone else in here? More interested in the practical setups than the principle.

The hot take on X right now: SaaS is dead, cancel everything, build in-house. The real shift: SaaS is becoming SiaS. Software in a Service. SaaS sells you a tool and makes you run it. Software in a service sells you the outcome, with the software built in. Calls answered, clients booked, systems connected, decisions surfaced from real-time data. Then add a layer of intelligence. This shift is happening across every industry at every organization size.

A pad of scrap paper beside the keyboard has done more for my throughput than most of the tooling I changed this year. The minutes a model spends building are the minutes to spend deciding what happens after it lands. - The next sequence - the two or three work orders after this one, written while this one runs. - Notes on the output - what to keep and what to challenge, marked as you read rather than after. - Designs - page layouts, folder trees, flows. Faster to draw than to describe. The dead time in an agentic session is real. A job runs for a few minutes and there are three things you can do with that window: watch it, interrupt it, or think. Watching teaches you nothing and interrupting usually costs a rerun. Writing by hand does something a second chat window does not. The keyboard pulls you back into the work; paper keeps you above it, which is the seat you are supposed to be in while an agent is running. The reading half matters more than the planning half. Marking what to challenge as an output comes in, rather than reaching the end and reconstructing it, is the difference between a next instruction that corrects course and one that just says carry on. The bit I have not solved is getting any of it back into the system. Everything on that pad is orientation the workspace never sees. One of the synced writing tablets pointed at a folder would close that - handwriting arriving as context on the next prompt, and the notes logged as part of the record of how a build actually went. If anyone here has wired one up, I want to hear how. Genuinely think that is one of the more interesting unbuilt pieces sitting in plain sight...

Most of the time, plain old programming is the better tool. 1. The rules are clear If every step can be written as a rule, AI is not needed. Use: Code 2. The answer must be exact Math, totals, taxes, and dates should always come out right. Use: Code 3. The same input needs the same result Some jobs should work the same way every single time. Use: Code 4. The answer is already in the data If the system already knows the answer, just ask the system. Use: Query/Database 5. You are moving data around Sending data from one system to another usually does not need AI. Use: APIs 6. Only a few cases are unusual Let code handle the normal work and send the odd cases to a person. Use: Human review 7. A mistake could be costly If getting it wrong matters a lot, keep the risky step under tight control. Use: Human approval 8. No real thinking is needed If the job is just following steps, ICM probably adds very little. Use: Code 9. Your software already does it If the feature already exists and works, adding AI just adds another layer. Use: Existing software 10. You just want to use AI Sometimes the new tool is more exciting than the right tool. Use: Ask why When would you choose NOT to use ICM or AI at all?