Hey everyone! Just read the three chapters recommended by Jake. Se below my favourite quotes and some thoughts of mine attached to it. No AI was involved in this process! Chapter 1 “Nobody can seriously have believed that executives could read programs. Why should they? Even programmers do not read programs” - Very liberating to know that. Ever since I started vibe coding I have this feeling that I don’t understand what I have created or at least how it works. What does “reading programs” look like in the age of AI? With millions of people vibe coding without writing a single sentence, what constitutes reading their programs? It is looking at their folder structures? Is it looking at the prompts they’ve created? And another question would be: should ask for AI’s help to read other people’s programming for us, or with us? “Therefore it is reasonable to expect that future languages will make us feel those limitations of PL/I that are not detectable today. Notice that this is a psychological question-one to which we shall have occasion to return” - When we vibe-code we don’t even know what the language limitations are. We can feel limitations in the results we are trying to achieve. “There are, of course, programmer limitations other than merely not knowing the full power of the languages - vocabulary limitations, we might say. For instance, the programmer may be unaware of certain algorithms, or he may be unable to grasp a sufficiently large portion of the problem at one time to see that certain duplication may be avoided.” - With AI, most people don’t know the full power of the languages. We delegate that knowledge to the LLM. But knowing and expressing the problem we want to tackle is still a very human activity. “…in most cases, we do not know what we want to do until we have taken a flying leap at programming it. Specifications evolve together with programs and programmers. Writing a program is a process of learning - both for the programmer and the person who commissions the program. Moreover, this learning takes place in the context of a particular machine, a particular programming language, a particular programmer or programming team in a particular work environment, and a particular set of historical events that determine not just the form of the code but also what the code does!”

Some lessons from my latest build: a personal assistant for my daughter Luna, 17. She studies at Sora Schools, an online school, and asked for an assistant that organizes school and life with her: a morning panel, weekly plans that roll up into the trimester, and one hard rule: it never answers schoolwork. Her school's AI policy went into the workspace verbatim, as a rule the assistant has to follow. Speed comes from the process, not from rushing. In the morning I recorded a discovery interview with her. In the same day the factory ran the whole pipeline: spec interview, value baseline (the "before", measured in her own words), workspace design, deploy and delivery. By 3pm she had cloned the repo and was using it on her own machine. None of the phases was skipped. The process is what made one day possible. The checks that catch things are the ones you don't run yourself. Three cold reviews, each by an agent with no memory of the build. A cold audit of the design against my own decision principles caught one factual error and proposed four improvements, all applied before I approved it. A cold walk test dropped a fresh agent into the finished workspace with one task: orient yourself from the files alone. It found the right place after reading just two files, and flagged two references to files that don't exist yet. And between every phase there was a human gate: nothing moved without my explicit approval. Delivery is a repo, not a meeting. The product is fi the workspace as a private GitHub repo, I added Lunaas a collaborator, and a one-page SETUP guide sits in the repo itself. She cloned it with GitHub Desktop, opened the folder in Claude Code, and started. That was the whole handoff In two weeks I'll be back here with results. We measbout 30 minutes a day spent planning, plus the worstpart of all: carrying everything in her head all day. So we'll know exactly what changed. Measure the before, so you can show the after!

Two weeks ago I shipped a personal assistant for my daughter Luna, 17, in a single day, and promised I'd come back here with results. (read original post). Here they are, with the lessons that came with them. Last time I said: measure the before, so you can show the after. So here it is. Before, planning her day took about half an hour, and the worst part was carrying it all in her head, always half-worried she'd forgotten something. Two weeks in, the half hour is basically gone, and what she told me herself is that the worry went with it. She got through a trip without it hanging over her. The minutes were never the point. The relief was. But asking the user about the system is not enough. So I ran an audit. I found out there was a learning loop that was writting to a file nobody was re-reading when needed. The assistant was built to turn every correction Luna makes into a written rule, in the file that owns it. It did exactly that. But those corrections landed in a file the morning routine never re-opened, so the same correction came back more than once in a single day. The fix wasn't a smarter model or a better prompt. It was one line: put the corrections file inside the load path of the routine it's meant to fix. Fix the context, not the agent. Audit the system you shipped, don't admire it. Two weeks of real use is a first, good and honest test, so I ran an audit: her before and after side by side, in her own words, and I walked the delivered files cold, with her permission, since the workspace is hers. Watching it work told me it was great. Walking the files told me where it was still broken. Both were true, and only the audit showed me the second one. Ship it, let someone live in it, then go back and measure what actually changed! BTW: Luna's assistant is called Janet.

💰 $500 CASH 💰 One winner takes it. 📋 THE CHALLENGE Build a folder-based AI auditor that checks something against a specific standard and reports where it falls short. Not your opinion of what's good. An actual standard that exists in the world. This week's deliverable is one auditor folder that someone could drop into a Claude project and use to check their work against the rules of their industry. 🎯 PICK YOUR STANDARD The standard is yours. Pick one that actually exists. Pick one you could point someone to. A few sparks to get you thinking: - ♿ WCAG 2.1 AA accessibility audit of a web page - 🔒 GDPR audit of a privacy policy or data flow - 📋 SOC 2 readiness audit of a security policy doc - 📄 Contract audit against standard SaaS data-handling clauses - 🏗️ Code audit against a specific style guide (PEP 8, Airbnb JS, Google Java) - 🏥 HIPAA audit of a patient intake process - ♻️ Brand compliance audit against a published brand guideline - 📊 Financial model audit against FAST modeling standards - 🎓 Grant proposal audit against a specific foundation's published criteria - 📱 App Store submission audit against Apple's review guidelines - 🧾 Invoice audit against a client's stated payment terms The more specific the standard, the better. "Audits for quality" is not a standard. "Audits a React component against the WCAG 2.1 AA success criteria" is. 🔥 THE ANGLE THIS WEEK Last comp was The Cartographer. Forty of you built maps where every card cited a file and a line, and we cloned the territory to check the cards against source. The ones that held up were the ones a stranger could verify. The Auditor is that same discipline pointed at a rulebook instead of a codebase. ⚖️ Every finding cites a provision the way every card cited a line. The standard is the territory. The audit is the map of where the artifact sits against it. Three things separate a real audit from an opinion: 1. The standard is external and citable. Your auditor should be able to say "this fails WCAG 2.1 success criterion 1.4.3" not "this contrast looks low to me."

I read Jeff's post about coming up with ideas and bouncing them off of Claude and blinked really hard several times. His idea is clever and he has a neat Remotion video to show it. My problem sits adjacent to this. I can't wrangle all the ideas that my brain produces... every single day. It's insane. I think I have ADHD and OCD combined. I'm everywhere all at once and obsessing over every next cool concept. Granted, some of the ideas are lame (plenty of them in the archives), but quite a few are really good and should be pursued. The problem is that there is only ONE of me. How do you decide what is worth pursuing? Do you use any kind of metrics? Do you bounce your ideas off of someone else? Do you wing it? (my current approach) Or does it come down to how much money an idea could make? How much it would cost to build? How quickly you could ship it? For many of us there is an added layer. What can I build that will genuinely make a difference for someone else? That question ends up carrying a surprising amount of weight for me. An idea can be profitable, technically interesting, and perfectly viable — but if another idea has the potential to solve a real problem for someone, I have a hard time ignoring it. Which, unfortunately, does absolutely nothing to solve my too-many-ideas problem. So I’m curious: how do you decide which ideas earn the right to become a real project and when to just say, "No"? Jeff's post: https://www.skool.com/cliefnotes/youre-not-out-of-ideas-youre-out-of-someone-to-say-no-to