New YouTube Video is out, takes cut from a live lecture I was giving the other day. Hits on a lot of structure points, some gold in their if you are willing to listen all the way though. If you want to be a part of these live lectures and ask your OWN questions, join the premium or vip before prices go up this weekend.

Hi all. I'm John, from Georgetown, Ontario. I joined the Lyceum in late October on the recordings, so I'm working through it on my own and sitting the exam in December. I've been quiet in here, and I'm going to post what I learn as I go, starting with the reading. Jake's reading list sent me to Weinberg's The Psychology of Computer Programming. I didn't read it in the eighties, but I lived it in the eighties. Reading it now took me straight back there. I was at a company called Teela in Toronto, a division of Moore, programming on IBM 370 and Digital VAX 11/750 hardware in PL/1, Fortran and COBOL. Yes, I'm a dinosaur. Moore had moved into laser printing, and it was the disruptor of its day. A personalized direct mail letter for a bank or a financial services company used to cost 70 to 85 cents before postage: graphic artists, multiple pages, colour. We got that down to 3 to 6 cents. Here's how it fit together. Data came in from all kinds of client systems, in all kinds of formats. We ran it through our own programs on the IBM and the VAX. In a cold room off the print floor sat a separate PDP 11, where we converted clients' tapes coming in and wrote the output tapes going out. Those tapes went to our Xerox operators, who ran six or seven Xerox 9700-series mainframe laser printers: two pages a second, on plain cut sheets, both sides. Other clients' jobs came straight from disk. Many inputs, one process in the middle, one output somebody had to sign off on. If that sounds familiar, it's the same shape as everything we're building in the Lyceum. The machines were never the hard part. The people were. Something new called "desktop publishing" was arriving, and the graphics people were sure it would take their jobs. Salespeople were chasing commissions. The client's VP needed it right and on time. What fixed it wasn't code. It was lunch, and a couple of pints after work. That's where somebody says, "Can I talk to you about something?" and you finally hear the edge cases.

Title: simple I just watched the Jake Van Cleef breakdown, and the biggest thing that stood out to me was how to give it a simple system ]. It clicked because i was frustrated with having to repetitively correct My main takeaway was how the organizational folder system works basically. The experiment at the end helped me understand [you don't really need to know anything but the goal and let the ai guide you there Going forward, it will be the basic that all will be created

Most of us run AI like a vending machine. Prompt goes in, product is supposed to come out. Instead the output drifts, the context window fills, and everything collapses. So we blame the model and try again. The article's punch: the model was never the answer. The structure around it is. Systems engineering kept a nuclear plant stable on a submarine, and it is the same loop that finishes pool jobs on budget, survives nonprofit handoffs, and carried me 42 days on a bicycle from California to Michigan. The loop, everywhere: 🔹 Research. Know the outcome before you touch the tool. 🔹 Declare. One page, in terms you can measure. 🔹 Cycle. Run small. Check. Track. Adjust. Add nothing yet. 🔹 Layer. Only after the core holds. Karpathy framed it for agents: fill the context window with exactly the right information for the next step. Your move: pick one system this week, write its one page, run the first cycle, and drop the page below. The comments are the course. The text is fuel. https://www.skool.com/cliefnotes/classroom/c7f102c7?md=2b72dd8a1c464a238cf995646d8b40bc #systemsengineering #contextengineering #auditable #ownYourStack #CliefNotes

I'm currently using AI to build a 360° drone tour of Roatán for my excursion business, and right now I'm at the building structured systems stage. I got there one step at a time. How my review method grew: 1. Screenshots with the compass. At first I just sent a screenshot of each problem I saw. The tour shows a compass badge with the heading and the tilt (for example "186° S · ▲1°"), so every screenshot told the AI exactly where to look. 2. The grid (picture 4). Screenshots only covered what I happened to look at. So I came up with a grid over the whole 360°: letters A to L around the circle and rows 1 to 6 from sky to ground. Now I say "K3 is broken" and the AI knows the exact cell, and I can review a whole place on one sheet. 3. One file for every defect. Each problem gets written down with how to detect it, how to fix it, and a before/after picture. That file now holds 59 kinds of defects. This week it showed me something humbling: an automatic check had flagged two horizon steps three days before I spotted them myself, and the AI had dismissed them by eye. The check was right. The pictures show three kinds of defects we fixed this way: - Picture 1, stitching: in September, one build stitched the cruise port's waterpark twice. Today it's clean. (Honest note: that old build had nicer colour, and we're bringing it back.) - Picture 2, horizon: a small step in the horizon cut a far island in two. Now the line is straight and the island is whole. - Picture 3, trees: where two photos faded into each other, the trees went soft. Rebuilding that strip from the sharpest photo brought the detail back. Colour has its own settings. Each place starts from the drone's RAW files. They are developed in Python with DJI's official colour profile (LUT) for my drone, then stitched with the free Hugin tools. We now have a set recipe for sunny days and, since November 10, a default for cloudy days that I picked from 4 looks shown side by side. Right now I tell the AI what the weather was. We're working on having it recognise the weather by itself and pick the right setting.