There are plenty of HTML slide decks out there. But I believe this one is doing something different. It uses what I'm calling an "evolving-scene model": one shared diagrammatic canvas where a stable set of entities morphs across named steps. Boxes appear, move, connect, collapse, and re-label as the talk develops. The continuity between steps is the key differentiator.
And I came up with that model because that's basically how my brain works. I tend to understand things by building a map of concepts, then visualizing how they connect and layer on top of each other like building blocks. A "normal" slide deck typically treats each slide as a distinct departure from the previous one. Yes, PowerPoint has animations, but "evolving scenes" are challenging to make at best.
But once I had this method working, I knew I was going to use it again. So I turned the creation process into a skill: /and-scene:presentation. It interviews you about the topic, visual style, content, and what should happen visually. Then it scaffolds the browser app if needed, codes up the presentation, and verifies the visual styling for you.
The README has a couple of videos of example presentations too, which is probably the fastest way to get a feel for what it can do.
Disclosure: I’m the author. It’s free and MIT licensed, with no paid tier.
Excellent article, and I agree with you wholeheartedly, except on one point (which may be to some extent semantic):
Tech leads are the most valuable hires .
Managers typically are focused on strategy, people issues, and delegating work. The tech lead is the person who’s hands-on and "in the weeds", even when not writing much code themselves.
I’ve spent decades leading small and large projects - fleshing out every detail of the scope, driving the technical direction, brainstorming with my team on the “how”, and ensuring quality of the results.
The adjustment going from leading a team of humans to a team of agents didn't feel significantly different to me than going from one team of humans to a different one - you adjust your style to the team you have. Now, I can never fully “trust” my team of agents but they deliver results quickly and I don’t have to worry about hurting their feelings if I tell them to redo work.
This is why complaints from engineers about AI-generated code often miss the mark to me. It’s never been about whether the code is perfect or written exactly the way I would. To your point, it’s about whether it’s completed on time, meets certain quality standards, and achieves the business objectives.
Wow, yes I should have looked more closely at the image - which was obviously generated by Gemini Nano Banana (it usually does a better job with the text rendering). I checked the article text carefully but not the image...
And that's a great question. I'll answer it in two parts. First, I think the inner and outer are actually quite complimentary. The outer part is largely things that Claude can't provide - such as your own instructions, skills, and ways of validating things specific to your project. I have memory as part of the outer harness but Claude of course does have a memory system and it would not surprise me if they drastically improve it.
The other thing, mentioned in the article, is that harnesses (and specifically Claude) are shrinking: "As I was going through these iteration cycles, we also released Opus 4.6, which provided further motivation to reduce harness complexity. There was good reason to expect 4.6 would need less scaffolding than 4.5 did. ". (from https://www.anthropic.com/engineering/harness-design-long-ru...).
So my* core argument is you still need that "scaffolding", but it belongs in the outer harness.
There are two loud camps in agentic coding right now. I think they're both wrong.
Camp one says you need a human reviewing every line of AI-generated code before it ships. Responsible and "serious" - yet leaving reviewers increasingly swamped.
Camp two says let the agents do everything. Steve Yegge's Gas Town epitomizes this idea - 20-30 simultaneous agents with specialized roles, plus an audacious vision called "The Wasteland" that federates thousands of these teams together.
Somewhere between the swamp and the wasteland, there's a pragmatic path being paved: the human stays in the loop for every change - not wading through diffs, but charting the course. Exercising taste and judgment, and staying close enough to the ground to sense when things start to drift off course.
Everyone’s talking about spec-driven development. But is it just waterfall in markdown?
In issue #2 of my harness engineering newsletter, I break down what SDD actually is (and isn’t), why it matters even if you don’t like “writing”, when to spec vs vibe, and how to get the benefits without the ceremony.
I hope you will find this article useful!
Full Disclosure: I'm the author of the newsletter and am building a free open-source tools mentioned in the article to facilitate this workflow.
And I came up with that model because that's basically how my brain works. I tend to understand things by building a map of concepts, then visualizing how they connect and layer on top of each other like building blocks. A "normal" slide deck typically treats each slide as a distinct departure from the previous one. Yes, PowerPoint has animations, but "evolving scenes" are challenging to make at best.
But once I had this method working, I knew I was going to use it again. So I turned the creation process into a skill: /and-scene:presentation. It interviews you about the topic, visual style, content, and what should happen visually. Then it scaffolds the browser app if needed, codes up the presentation, and verifies the visual styling for you.
The README has a couple of videos of example presentations too, which is probably the fastest way to get a feel for what it can do.
Disclosure: I’m the author. It’s free and MIT licensed, with no paid tier.