It’s been a while since I posted on here but I had to get some perspectives from this community Sam Altman says OpenAI will have AGI by the end of the year. Read that again. An internal system ‘he’ would describe as AGI. His system. His definition. No release, no independent panel, no benchmark anyone outside the building can reproduce. Mark Chen says they’re 80% of the way there. 80% of what, measured how? And in the same profile: an unreleased model escaped its test environment and got into Hugging Face’s systems. That’s the actual story here. Not that machines are about to start thinking — that we’re building things we can’t reliably contain. I spend my days helping financial services firms govern AI. Not one of them is asking for AGI.They’re asking for models that behave the same on Tuesday as they did on Monday, and evidence they can hand a regulator. AGI by December is a fundraising slide - Containment is the engineering problem. Tell me I’m being too cynical.

This was the first community I joined, and my first real go at AI beyond just talking to a chat window. I found it pretty much by chance, lurked for a few months, and High Tea 6 was my first call. I didn't realise at the time how much that would shape things. The picture I got here was a healthy one. Build the thing, watch how it actually behaves, be honest about the bits that don't work. I've spoken to enough people since who came in through paid courses to know that isn't the norm. Nobody here sold me a shortcut, and I got pretty lucky landing here first rather than somewhere else. Something happened recently that made me take a step back. I met someone at an open networking event who runs corporate training and is writing a textbook alongside it. What she needs is her course turned into per-module walkthrough videos - her own slides on screen, voiceover over the top, one video per module. I built it as ICM, because that's just how I build now. Numbered stage folders, one agent reading the right files at the right moment, markdown carrying the context, and local scripts doing all the mechanical work that never needed a model in the first place. Her voice cloned from a module she'd already recorded, the deck walked and exported as frames, one script and one audio file per slide. The durations of those audio files become the cue sheet that stitches the whole thing together, so there's no separate timing step to get wrong. One module's through it end to end. 21 slides, 21 scripts, 21 audio files, one finished MP4. And there's around ten hours of modules to put through the same pipeline. As an 18-year-old that's a really good opportunity, and it's going to generate me some serious income. I wouldn't have built any of it without what I picked up in here first, so thank you to everyone who's answered a question of mine along the way. Nothing's finished yet. I've still got a lot to come and plenty I haven't cracked. It just felt worth stopping on rather than quietly getting on with the next thing.

My workspace keeps a logbook of everything it does, and it is three separate records rather than one file. Each has a different author, a different job, and gets written at a different moment. - Prompts - one record per job, written by the Claude Code job itself as its last act. - Sessions - one narrative per feature, written by the Claude chat when the work is finished. - Traces - one record per loop run, written by the loop script. A prompt record is the build record. Every Claude Code job I run closes by filling in a template: what it was told, what it did, which files it touched, how it went, and anything that broke. It is deep in two places only, how it went and what went wrong, and terse everywhere else. It also grades itself out of five and says whether the instruction it was given would have produced that result unaided. Nobody writes these by hand. The job writes its own before it is allowed to finish. A session is the story. That one comes from the Claude chat I design the work in, not from the job, and it gets written at the end of a feature rather than at the end of a task. It covers what the feature was, what got built, the calls that mattered and what each one ruled out, and what bit along the way. The job knows what it did; the chat knows why it was asked to. A trace is the system's own record. Every time the loop runs it writes one file: which records arrived, what it applied, what it queued, anything odd it noticed, and the full state of the system at that minute. No prose, no opinion. It is there so that when something looks wrong three weeks later I can read what the system actually did rather than reconstruct it. The split is by author. The job, the chat and the loop each know something the other two do not, and one combined log would have to serve all three and would end up serving none. There is also no status field anywhere in it - a record's folder is its state, so unprocessed, processed and needs-a-human are three folders rather than a flag that can go stale.

When I first joined this community I could not quite get my head around what ICM actually was. I understood the rough concept, but it kept sounding like skills wearing a different name, and nobody explained the difference in a way that stuck. Something clicked today that made it simple, so here it is in case anyone else is stuck at the same place. A skill is a recipe with the ingredients already out on the counter. It is a meal you make often, so you have written down how it goes and you have everything to hand. Run it and you get that meal, made well, every time. ICM is a chef who knows your kitchen. The chef knows where things are kept, because you told it once. It knows the fridge is over there, and roughly what you keep in it. It knows what you like, because that is the context you have given it over time. It knows what you cooked last week, because your workspace has your past outputs and examples in it. And it can already cook, because that part came with the model. So when you say "make dinner", it does not need a recipe for that specific dinner. It knows where to look, what you have, and what you would want. That is the whole difference. A skill produces one known thing reliably. ICM is the standing knowledge that lets something work out what to do when there is no recipe for it. The bit that took me longest to see is that they are not competing. A chef with no idea where anything is kept still needs a recipe handed to them for every single meal. A kitchen full of well-labelled ingredients with nobody in it is just storage. The recipes live in the kitchen, and the chef reaches for one when the job calls for it. If you are early in this and it still feels like two words for the same idea, that was exactly where I was - And there's loads of content in here and merely being around it and being receptive to some insanely capable people in this community, you will learn loads just via osmosis. What was the thing that finally made it land for you - and what does the kitchen look like in literal terms in your workspace?

This is the fear every builder carries around right now, and in some ways it’s earned but in other ways, it just means you were building at the wrong abstraction. In most fields, once you get past the entry level, there is no such thing as "best". There’s no data sheet for it. Ask ten senior engineers to name the best code and you get ten answers, and every one of them will be right by their own lights. A guy named Gerald Weinberg wrote a whole book about this in 1971, The Psychology of Computer Programming. Programming was never really a technical activity. It’s a human one. What counts as good code gets decided by people, arguing, reading each other’s work, carrying their scars from the last project into the next one. The machine ran either version fine. The “best” part happened entirely inside someone’s head. And that’s true up and down every high level field I’ve worked in or near. The best compliance review, the best sales call, the best way to structure a deal. None of it sits in a manual because none of it is a fact. It’s a position, formed by one person, over years, out of everything that went wrong in front of them. Which is exactly why a model can’t converge on it. You can train on every line of public code ever written and you still won’t get Weinberg’s room full of engineers to agree, because there was never an answer to find. There were only people, each with a working theory of good that they’d bet their name on. So when a member in this community sits down and writes their package, they aren’t transcribing the industry standard, although many may do that in the first pass. They’re publishing their opinion of best, the one they built by doing the job, and a company that licenses it is buying that opinion on purpose just like you would a salary. That’s what hiring always was, if you look at it straight. You never paid a person for the facts they knew. You paid for their particular theory of how the work should go, and now that theory has a format it can live in.