Do we still need dashboards, menus, buttons and complex applications? Or will the AI itself become the main interface, with a simple visual layer only for things like monitoring, approvals and seeing what’s happening? I’m curious how you see this evolving over the next 5 years. Will we still use software, or will we mostly talk to software? @David McDermott @Ari Evergreen @Jake Van Clief @David Vogel @Matthew Creamer @Bas Rosario

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...

I have a client in Australia who's looking for someone who understands ICM and can help him work on his software. Obviously he would prefer someone a bit more technical, but he's happy to have some people who are trying to learn as well. It's a pretty large software, but he's created a pretty good automated system and obviously he's using my methods so it's very well organized. Anyone out here looking for a project to take on the practice or learn more? Or is there anyone in the morning to get a little bit more work done at a higher level? He's looking for multiple skill levels.

34 entries. Jake, Don, David on isolated piles, then a panel. This one was hard. A few of you built things that would have won a different competition, and you should hear which one. Every entry got feedback, link at bottom of post! 📋 What we actually judged The post asked for one folder a stranger can drop into a Claude project. identity.md, rules.md, examples.md, reference/, README.md. It reads something broken and says why. Not how to fix it. Four questions, from the post: 1. Does it diagnose? One cause. Not a list. Not a prescription. 2. Is the domain specific enough to be useful? 3. Does each file do one job? 4. Can a stranger figure it out? That is an outcome. Can a person who is not already in your head use this to see why something in their world broke. A lot of the field went further. Refusal paths. Verifiers. Blind runs. Preserved failures. Those are real, and they are extra. We did not pick a winner on the extra. We picked a winner on the ask. this does not mean extra is not better, in many cases I LOVED the solutions created. If the outcome had been different, the name on this post changes honestly 🥇 Winner: Colm Whelan — Inbox Autopsy https://github.com/RockfieldIT/inbox-autopsy A stranger holding a bounced invoice can drop the folder in and see why it bounced. That was the assignment. 🔄 Where someone else wins 🔧 If the outcome was "the instrument that can prove itself wrong" — Sergey Manevitch, Radix https://github.com/sergeymanevitch/Radix Why a machine failed in a plant that already has notifications, rounds, and historian trends. Fourteen cold runs. He left the breaks in his own claims standing. A plant engineer is holding something serious. 🧪 If the outcome was "every claim reproduced, including the one that failed" — Pemmy Broke, Visual Momentum https://github.com/hoodwanders/visual-momentum-diagnostician Why an AI explainer lost momentum. She published the run that broke her own doctrine, changed the rules, and the re-run abstained. That is the standard the rest of the field should steal from.

Nope... Do people think I am... Yes (except for a discord group I am in, or literally anyone in this group🙄) Am I speaking at my first conference today about AI? ...Yes Is it in front of a lot of people... Hahahahahahahahahaha... Nope... Am I excited.... YES! Today I am teaching teachers about AI - not just another tool, building a system that lasts. #SuchFun