16:15Austin Marchese · Tutorial
How Anthropic Employees ACTUALLY Use Claude Skills
A 16-minute extraction of Anthropic's internal playbook, collapsed into five lessons any Claude Code user can implement today.
June 23rdThe argument in one line.
Designers who learn to orchestrate AI agents rather than execute design work themselves are entering the same career-defining window that early Figma adopters had in 2016.
Read if. Skip if.
READ IF YOU ARE…
- Designers who want to stop being executors and start orchestrating AI to do the heavy lifting
- Creatives who feel left behind by the agentic AI wave and want a no-terminal, business-first entry point
- Design business owners tired of repetitive UX reviews, brand audits, and system updates they could automate
- Curious non-coders who learn best from visual Miro decks and live demos rather than docs
SKIP IF…
- Developers looking for engineering depth — this is built for designers, not backend engineers
- Anyone who wants a quick 20-minute overview — this is a 4-hour deep curriculum
- Teams where design and dev are siloed and AI adoption requires org-level approval
The full version, fast.
Designers who treat AI as an execution tool will be outpaced by those who learn to orchestrate it. This four-hour course teaches a practical framework for agentic design across three phases: understanding how AI agents actually work, loading your own context into Claude Code through a structured CLAUDE.md and three-layer architecture, then applying that setup across four modes — Discover, Create, Systematize, and Automate. The course covers live builds including UX review bots, on-brand site generation, an AI-native design system, and a multiplayer game. The core takeaway is that system-level thinking — not one-off prompt use — is what separates designers who stay relevant from those who get replaced.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 04:43
01 · Intro — executioner to orchestrator
Sets up the thesis: design is moving from doing the work to directing agents that do the work. PMs+AI+design-systems can already ship 80% interfaces, so designers must speed up or become the bottleneck. The window is 'Figma in 2016' wide open.
04:43 – 07:20
02 · Course curriculum
Three buckets: (1) understand the tech, (2) bring your own context, (3) put it to work. Plus what's NOT covered: design taste, judgment, traditional craft — that's still on you.
07:20 – 31:47
03 · What is Agentic Design
Chat (you ask, AI answers, you copy-paste) vs Agent (you direct, AI does). Live demo: parking-permit form UX review — chat reads HTML and lists 15 generic issues; Claude Code spawns Maria + Jake + heuristic sub-agents that fill the form live in Chrome and report back with a 14/40 UX health score. Then maps the tool landscape: legacy Figma vs agentic design tools (Stitch/Make/UX Pilot) vs general agentic (Claude Code/Cursor).
31:47 – 49:07
04 · How AI Agents Work
Defines the agentic loop: you give direction, agent executes, you review, you redirect. Talks about tool use, sub-agents, memory, context windows. Why 'AI is not a silver bullet' — competence without judgment is dangerous.
49:07 – 1:34:01
05 · Setting Up Your Agentic Environment
Pricing/plans, installation (Claude subscription + IDE software + Claude Code extension), 'Your Controls' walkthrough of the Claude Code UI, file system orientation, what auto-accept / plan mode / bypass permissions actually do.
1:34:01 – 1:49:22
06 · Your System Prompt (CLAUDE.md)
Show-and-tell of CLAUDE.md as a 'design brief that runs before every conversation'. Same LinkedIn-PDF -> personal site demo, but with brand colors/tone/rules in CLAUDE.md gets a way more on-brand result. Markdown vs PDF — token economics, why .md is the LLM-native format.
1:49:22 – 2:14:09
07 · The 3-Layer Architecture
The reliability unlock: instructions (rules) -> orchestration (skills) -> execution. Two-layer (just rules + execution) breaks down as complexity grows. Skills are .skill.md files with YAML frontmatter — recipes the agent invokes by name.
2:14:09 – 2:37:17
08 · Connecting Your Tools
MCPs and tool calls — bringing Figma, browser, Slack, your email into the agent. 'Tech context' as a separate slide section. How an agent picks which tool to use.
2:37:17 – 2:46:35
09 · Discover (build research skills)
Builds the Color Thief skill in ~12 min. Then lists 8 more skills you could build the same way: Review Miner, Tone Scraper, Heuristic Audit, Jobs-to-be-Done Mapper, Business Model Mapper, Survey-to-Persona, Strategy Mapper. The constraint is imagination, not capability.
2:46:35 – 3:21:41
10 · Create (build a portfolio site + multiplayer game)
Three creation demos: (1) make the LinkedIn-derived personal site live with Netlify free tier, (2) build the Color Thief skill end-to-end, (3) build NumberDrop — a multiplayer estimation game for his students that uses Google Maps as the core UI element. Iterates with plan mode + 'simulate 7 teams' to stress-test the UI before real players touch it.
3:21:41 – 4:00:54
11 · Systematize (AI-native design systems)
Hands off to Tom (program director at the MBA). They built an AI-native design system because they finally needed one — and designed it so any agent generating new code automatically produces on-brand UI without a human reviewing every component. Two-host segment.
4:00:54 – 4:27:10
12 · Automate (weekly Slack status reporter)
Builds a real automation: a cron'd Trigger.dev job that DMs each team lead asking for a status update, then summarises the responses into a clean Slack post for the whole team. Live setup of GitHub auth, Slack scopes, the .env pattern, and the deployment to cloud infra.
4:27:10 – 4:29:39
13 · Outro + Agentic Design Community CTA
Acknowledges the space moves so fast even this video will age. Soft pitch for an Agentic Design Community (paid, domain already bought) — but transparent he won't build it unless enough people sign up. Link in description.
Lines worth screenshotting.
- Designers are moving from executioners who produce deliverables to orchestrators who direct agents — and that shift touches UX, research, service design, and design ops equally.
- A PM with an AI tool and a design system can already draft an 80-90% interface without a designer — the remaining 10-20% is where design actually matters now.
- The difference between a one-off AI-generated design and a maintained system is exactly why design still has a job — anyone can prompt a screen, almost nobody can build the system behind it.
- Learning Claude Code as a designer in 2026 is the equivalent of learning Figma in 2016 — the window to set the standard is open and closing.
- Design systems are becoming AI-native, design ops is getting automated, and research is accelerating — every design discipline is changing simultaneously, not one at a time.
- If you're in a slow-moving industry without AI pressure yet, the moment one competitor adopts it, every other company in the category follows within months.
- Being fluent with AI agents is currently a competitive advantage on the job market — it will become a hygiene factor, which means the advantage window is finite.
- The 'fast and good enough' approach is being forced on most companies not by choice but by competitive pressure from engineering teams shipping faster with AI tools.
- CLAUDE.md is the mechanism that prevents AI slop — without your own context loaded, the agent is guessing what you need instead of knowing your standards and constraints.
- A designer who builds the internal automations their company runs on has converted from a cost center into infrastructure — that repositioning is permanent, not project-based.
- Human craft in design will still matter — it will just arrive in smaller doses and carry more weight precisely because it is rarer.
- The three-layer context architecture (understand the tech, bring your own context, put it to work) is the difference between using AI as a search engine and using it as a collaborator.
Steal the curriculum spine.
Joe Skill: Build vs Direct
Faljic's 'executioner to orchestrator' frame is the exact pitch Joe should be making to solo creators — and the 3-layer architecture is the exact spine JoeFlow / Paperclip should ship as a template.
- Pitch every Joe product through the executioner -> orchestrator frame. Creators are still pressing record themselves. They should be directing.
- Adopt the 3-layer architecture as the JoeFlow spine: SOUL.md = instructions, sessions/skills = orchestration, the actual file/recording/upload = execution. Diagram it once, reference it forever.
- Ship a starter-skills pack with JoeFlow. Pick 6-8 like Faljic's list (Review Miner, Tone Scraper, Heuristic Audit, etc.) but reframed for creators: Hook Miner, Caption Scraper, Thumbnail Audit, Title Splitter, B-roll Mapper.
- Build a 'fresh-instance reviewer' loop into the Sessions panel — when a builder session finishes, auto-spawn a reviewer in a different model with no prior context. This is the kind of feature that makes the product feel smart.
- Use the soft-CTA ending pattern: 'I might not even build this — depends if enough of you want it. Drop your email if you do.' Honesty as conversion mechanic.
- Steal his title format for the Mod Boss long-form: 'MOD BOSS FOR CREATORS (Full Course - 90 Minutes)'. Set expectations in the title, let the chapters do the discovery work.
- Replicate the visual rhythm: face + Miro PIP. Hand-drawn highlighter is doing more work than slick slides would. Cheap, fast, recognisable.
Terms worth knowing.
- Agentic design
- A design practice where the designer acts as an orchestrator — directing AI agents to execute design work (research, wireframing, system generation, automation) — rather than personally producing every artifact by hand.
- Orchestrator (design role)
- A designer who directs and coordinates AI agents to do the production work, as opposed to an executioner who manually produces every design asset. The shift from executioner to orchestrator is the central career transition the course addresses.
- CLAUDE.md
- A markdown file placed in a project repository that gives an AI agent persistent context about the project — its architecture, conventions, and goals — so the agent doesn't need the same background re-explained at the start of every session.
- 3-layer architecture (AI context)
- A context structure for AI-powered projects consisting of three levels: global rules that apply everywhere, project-specific rules, and task-specific instructions — used to give Claude Code the right context without bloating every prompt with everything.
- Design ops
- The operational layer of a design team — tooling, workflows, documentation, and processes that make designers more productive at scale. Referenced here as increasingly automatable via AI agents, shifting the design ops role toward system governance.
- AI-native design system
- A component library or design system built from the ground up to be used, extended, and maintained by AI agents — where the tokens, components, and documentation are structured so an AI can reliably generate on-brand interfaces without human intervention for each instance.
- UX review bot
- An AI agent configured to evaluate a user interface against defined heuristics or design standards, producing structured critique and improvement suggestions automatically — demonstrated in this course as a practical agentic design output.
- Custom skill (Claude Code)
- A reusable prompt-plus-workflow bundle added to a Claude Code project that gives the AI agent a repeatable, named capability — such as 'generate an on-brand landing page' or 'run a UX audit' — that can be invoked with a single command.
- Hygiene factor (career)
- A baseline expectation in a professional field — something that won't make you stand out if you have it, but will disqualify you if you don't. Used here to predict that AI agent fluency will move from competitive advantage to table stakes for designers within a few years.
Things they pointed at.
2:22:20toolUX Pilot
Lines you could clip.
00:08
“We are moving from a world where most designers are primarily executioners to a world where most designers will need to become orchestrators.”
58:20
“It's almost like learning Figma in 2016.”
1:01:40
“Being fluent with AI agents is a huge advantage on the job market. But soon it might be a hygiene factor.”
1:53:20
“CLAUDE.md is almost like a design brief that runs before every conversation.”
1:30:00
“PMs with an AI tool and a design system can draft an 80% interface, something that's 80 to 90% good enough.”
3:11:40
“The constraint is just your imagination and also your use case, and it's so easy to build this.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogy
Welcome. This is a comprehensive guide for designers of all disciplines and all seniorities who wanna become fluent in agentic design.
We are indeed entering a new era of design, so we are moving from a world where most designers are primarily executioners to a world where most designers will need to become orchestrators. Orchestrators who can direct agents to do a lot of that design work for us.
And this isn't just about UI. Whether you are in UX, research, service design, whether you're leading a team or you're design ops, that shift touches all of us.
Just a quick context on me. I'm a designer. I run the MBA, which is a business school for designers, and we have had over 1,000 alumni so far.
I am also an ex IDO business designer. I have no engineering background, but over the past year, I have spent hundreds of hours inside AgenTik AI tools, and I have built over a dozen of internal products and automations that run our business.
So So everything you'll see in this course, we use in our company. This isn't theoretical. Okay.
Now why do we designers all of a sudden need to learn how to use agentic AI? In other words, why is agentic design relevant?
Well, let's start with the fact that most business departments, if not all, are speeding up with the use of AI. So if you think about legal, if you think about marketing, engineering, finance, they're all accelerating.
And if we, as a design function, don't, you know, also speed up, we can become the bottleneck, which is not great, obviously, especially because nondesigners can now produce what they think is good enough design.
So a PM with an AI tool and a design system can draft an 80% their interface, something that is 80 to 90% good enough.
Right? At the same time, tools are getting better. So this thing is not stopping in terms of the progress.
But, you know, this is very important, but there's a real difference between creating a one off design and maintaining and building this into a system.
So while PMs and others can create a one off design, really building this out into a system and managing the system is basically why design still matters and how it will matter even more in the future.
At the same time, I do wanna say that human craft and human made design will still matter. It will just come in smaller doses. And the reason the main reason for this is because most companies, especially in tech, are not adapting the fast and good enough approach.
Meaning, they're not trying to go slow and be perfect, but they are just launching fast and quickly. And the reason for this is, again, AI. Engineering teams and other teams are adopting AI tools, and they can launch things faster.
And as soon as you have one competitor in your industry doing that, there's pressure on others to adapt. By the way, if you're in a slow moving industry or even if in a slow moving, let's say, geography, you know, where AI adoption is not as high for whatever the reason, you might not face that pressure yet, but it's just a matter of time until something clicks.
Maybe one competitor starts adopting it, and that puts pressure on everybody else. So even in this case, it's a good idea to start learning agentic design because it's coming. This also means that design rules are being redefined in a big way, and we'll talk about this in a bit.
But just in a nutshell, design systems are becoming AI native. Design ops is getting automated. Research and discovery is getting faster, and so is creating visuals and wireframes.
So, yeah, all business processes are getting AI fight, and the same is happening with design. Now the good news is this window to learn this tool is wide open. It's almost like learning Figma in 2016, and designers who get fluent using this will set the standards of how it's done community wide, but also company wide.
Right? So if you're the first person or among the first person in the company, you can really set the tone, and that's why this is a huge opportunity for all of us.
And I would even say that these days, being fluent with AI agents is a huge advantage on the job market. But at the same time, I have to say that maybe soon it might be a hygiene factor.
Okay. So now let's have a look at what we will cover in this course. As you can see, we have three bigger buckets.
We have part one, which is the understanding the technology, how it works. Part two, which is about how do you bring your own context into the tool, so how it can do a good job for you instead of just giving you AI slop.
And then we'll show you some of the ways you can build with it. So we'll talk about in the first section about what is agentic design. So we'll define this term.
We'll define how it affects different design disciplines, and what are the tools of agentic design. We'll talk about how AI agents work, which is all about understanding the technology of AI agents.
Then we'll also set up the agentic environment, which means if you have never used Cloud Code, that's totally fine. We will go from zero, from installing it well, installing everything you need on your machine to get it up and running.
And then we'll go into how to bring your own context, which is creating your system prompt. We'll talk about a three layer architecture, which is a really important lesson here, and it's we'll talk about the how to use these agents to get reliable and good results as opposed to something that feels unreliable.
And lastly, we'll talk about connecting your tools. So how can you bring the tools you are using on a daily basis, such as Figma or a browser or your email perhaps into these tools to be more productive.
And lastly, we'll talk about the building part, so we'll put it to work. We'll show you a few examples of how we and and others have used this tool in different phases from discovery phase, which is we'll show you how to, for example, do a competitor research really fast and really thorough, how to obviously build design systems, build designs, build apps with agents.
We'll talk about systematizing, so how to build an AI native design system, and how to automate things, which is how to build automations that will make some of the design ops just much faster.
At the same time, I do wanna mention what we will not cover. We will not go into any design skills, which is the traditional design process or design judgment or taste. So knowing what's good is still on you, and frankly, that's what makes you valuable.
Second thing I wanna mention is that, obviously, as the title of this video suggests, we will be using Cloud Code, but don't let the name fool you. It's not just a coding tool.
It's a general purpose agent that just happens to work through text and files. Okay.
Having said that, it's time to jump in into the first section, which is what is even agentic design? Well, the best way to explain it is to explain the difference between a chat AI and an agent AI.
So what we have here is two screenshots. On the left is a screenshot of a Claude chat, and on the right is a screenshot of a Claude code as an agent.
So here on the left, you could also swap this image with a ChatGPT or Gemini. It's the same thing. So what I wanna talk about is the difference.
So the way chat works is that we ask questions and AI answers. So and it's back and forth, back and forth.
And when we get the answer that we like, that we need, that we can use, that's when we get into what I call the copy paste phase, which is we take the answer, and then we use it in the environment where we wanna use it. That might be Figma.
That might be some kind of Google Doc or whatever. Right? But it requires a lot of us bringing context into it and then out of it.
And it's still us who is doing the work. We're just outsourcing some of the thinking to AI.
Now with agent, it's a little bit different. So we are actually leading, and we are asking or giving it directions, and AI is doing things for us.
Right? And that is a huge paradigm. We're no longer bringing context into it.
It's already there. An AI agent just does things with that context. It's best for me to just show you this through a live demo so you understand the example.
I was trying to find something that's very illustrative as an example that a lot of designers could identify with. There's plenty more, and we will cover more also throughout the session.
So let's just imagine that we're trying to design or we have designed a form, a form for a city council where residents can actually apply for a parking permit.
As you can see, it's a pretty standard form.
It has all the personal information, address information, vehicle information, and so on. So it looks very solid. It doesn't look the most modern, but it just looks like a lot of government forms do.
So what we would do in this stage of the process as designers is test this. We haven't launched it yet. We need to now see if it's actually everything is working.
So, obviously, we would use it ourselves, but maybe as a first filter because of AI technology, we would also hand it over to AI as well. So if we were to use chat, what we would do, and obviously, will do this now, is we will bring in this file.
Right? In this case, I'm actually bringing in the HTML file. I could have also brought in a screenshot, but, actually, HTML gives more information to AI to work with.
So what I will do now is I will use a voice to text software, and I will talk about it later just for you to know what's going on. Hey, Claude.
I want you to review this landing page or a form page that I have built. I want you to review it from the UX perspective, find any glaring usability issues.
There we go. So we'll hand this over to chat.
And while this is doing its job, let's hop over to our Cloud Code agent, and let's do the same thing.
In this case, I don't have to bring any files in. That's the big advantage also because it's already here. I have given it access to my project folder, but that's not the only difference.
Hey, Claude. I want you to run the UX review for my form that I have just built.
So just run my usual skill.
There we go. It doesn't matter if there is some typos as well because as a language model, it's pretty good at predicting and understanding what I actually wanted to say. Okay.
So what it will do now, it will invoke a skill that I have built, which is a special sequence of steps, a recipe of how I wanted to actually review a page like this. And, basically, it will do the following.
It will actually host this page on my machine as a server, so my computer will serve as a server. It will open up a few Chrome tabs, Chrome Windows.
It will create a few agents, sub agents who will actually fill out this form and then report back to us what was wrong. So there's a big difference between what chat is doing, which is basically just reading the HTML, and what is happening here, which as you can see, we are launching three parallel review agents.
There is someone called Maria, Jake, and then Heuristic. And basically, they will all actually be using this exact page and filling it out to find visibility issues.
So the survey is now up, and I should see the Chrome opening up very soon, and then I will share it with you. Oh, it's already here. So I'm not doing anything.
As you can also see, my hands are up. So this is now a agent who is who has a task to fill this out as Maria, and then there's another agent who has a task to fill this form out as a Jake, and both of them will fill it out and then come back to us with results.
Okay. So Maria just finished that. Jake just finished that.
So both of these are gonna close, both of these crumbs. And when they come back with all the results, our main agent will summarize, synthesize all the results, and get back to us with results.
So let's, for now, just jump back into chat and see what it has found. So we have how many?
We have 15 issues, and I'm not gonna even read through it.
What I just wanted to show you is the depth of the file the of the things it have found, which is 15 issues plus what it is based on.
So you can see that it's based on reading the code. Right?
It didn't actually it could not actually run this page and actually fill it out because that's not how chats are built.
I would now have to go through all of this and implement this into the design in the CSS or code. Okay?
Now let's go back into our Cloud Code instance, and what we will hear and what we will see here is a completely different depth of analysis and also what this analysis is based on, which is actually having agents filling out the form.
Maybe while this is still finishing the work, let me actually visualize what has happened.
So in this case, we have started a chat, and we just told it to do something. And because this particular skill asked the agent to actually spawn sub agents, so this is our main so called parent agent, It actually spawned three additional agents.
One was Maria, one was Jake, and then there was one more whose job was just to check for main, like, 10 main heuristics if the form is following this, like, 10 best practices in terms of how the form is and how design should look like.
And when these were done with their tasks, they reported back to the agent like this. And now the agent is summarizing this, and it will create a report.
This is, let's just say, slightly more advanced tactic. What we could also just have done is just told CloudScope to, hey. Just review this page and just give me feedback, and then the main agent would just do this itself.
Also, at this stage, I don't want you to be confused about the user interface that we're looking at. We will actually get this very, very soon, and I will explain how to set this up, how to use it. For now, I just wanna show you how different tools give you different results.
So let's give this a few more seconds, and then when it's back, I will show you the results.
Okay. Here we go. Here is the full report.
We have the executive summary on top with even some UX health score, 14 points out of 40 only. That's not good. Let's see what it found.
So error prevention is catastrophic. Permit zone selector is unusable. Legal tax is invisible, and so on.
So a lot of the stuff that actually the chat could not find because it requires actually using the form.
We have a amazing table as well. We're showing what issues both of the personas found. By the way, what were the personas based on?
I believe Maria was, like, a senior citizen, and Jake was, like, a younger tech savvy user, something like that. I could go and check it out, but doesn't really matter.
So we have this overview here with the issues both of these found. Oh, it's here. Maria cautious 68.
So these are all the issues that Maria found, all the issues that Jake found, and then this is our third agent who actually went through this form with the heuristic glasses and just look to these best practices and if we're actually doing well on them or not.
So we can just obviously read through all that. And then we have top five fixes we need to fix. And if I wanted to, I could just tell it, hey.
Fix it now. And this is vastly, vastly different from us getting the suggestions here, reading all of these, and being like, okay.
Now let me go and check that. So it's not just that we got way fewer things to improve.
Like, it was just a not a store of analysis. Also, now it's on us to do them. So, hopefully, that really illustrates the power of this agentic workflows, of agentic work, and what the agentic design is.
You know? It is when we're not doing things necessarily we're not doing all the things ourselves, but we are handing over him to agent some of the things that it can do for us.
What it means is that the role of designer is, well, changing. I have already talked about us moving away from doing less execution to doing more orchestration where agents are doing that work for us.
That means that we're not the ones that are building things, but we're more like evaluating. And when I say building, what I mean is like we're not physically or manually, like, doing things, but we are more like steering the wheel.
So we are still building. We're like, mentally, we are paying the picture. We are setting the strategy and direction, but it's manually building, like, screens and code.
It is actually agents that can do this for us. What this means is that a lot of us are actually gonna be moving, especially those who are, like, earlier in their career, from individual contributor roles to almost everybody being in, like, some sort of a design director or team lead role where maybe you're not managing people, but you're managing agents.
Just a side anecdote on this, I have seen some people take this to a very, very extreme.
So when I look at their screens so the way their screens look like is they have at the same time, like, this is six, but let's say eight of these running.
So they have, like, one, two, three, four, five, six, seven, eight. So just imagine this screen just being, like, basically each of these screens. So they're, like, basically running eight instances of Cloud Code at the same time because while one agent is doing something, they can hand over something else to another one, and it's just huge boost in productivity.
And, yeah, one one team member can just do way more, which means as a team, we can do way more, and we can just ship more things.
Again, I wanna remind you that my point of view is not that human craft will go away. We will just use it where it really matters. It's just a matter of fact that most companies will optimize for speed and for cost because this is cheaper and faster.
And then the human made graphics will use sporadically where it makes sense and when it makes sense. And so those might be illustrations. Those might be so some specific graphics that AI want to do as well.
So there will be some concom some combination of that, and it's still the jury is still out how this will actually shape. But there's no doubt in my mind that most companies will be moving more and more into agentic design and, in general, agentic departments and workflows.
So what does that mean for tools that we are using? Let's have a look at the most prominent, more popular legacy design tool, which is Figma.
So what are the all the things that we're doing in Figma? We do a lot in Figma. We're doing basically exploration, the brainstorming.
We're building wireframes. We're building prototypes. We're actually designing things.
We're handing over them to developers. We're also enforcing design systems. We're also reviewing.
Basically, has happened in Figma Abutil recently. What's happening now is that for most of these things, there are better tools.
So if we just try to visualize let's say this is currently like the old school Figma, and I know there's Figma Make and UX pilot and Google Stitch, and I'm getting to this. Right?
So Figma is a legacy design tool where the way you work is , meaning you are basically moving your mouse and keyboard for it to do all of these things. There's a new breed of design tools, which I call agentic design tools.
That would be Google Stitch. That would be UX pilot, Figma make. Where actually, you can do all of these things, but you're doing them while you're doing them text to visual.
Right? So you're putting in language, and you're getting out pixels.
And here it's pixel to pixel. I hope you can get used to my poor drawings. Sometimes it's gonna happen.
Okay. So this is basically I'll just be a little more clear. So this is Figma, and this is, let's say, Google Stitch or Figma Make or UX pilot.
And these tools can do all of these things that Figma does just way, way faster. So you can explore different variations of your design cheaper and faster.
You can do wireframes. You can do prototypes. You can more advanced prototypes can be done.
You can do the handoff, but it is a developer team. You can enforce design systems.
You can review. The only player, the only part where maybe Figma still has the traditional Figma still has an upper hand is like more this, let's call it the craft part where you're still trying to by hand do a certain, yeah, designs.
By the way, Adobe will also fit into this bucket, obviously. So what these tools what these tools, so design agentic tools do is basically just make us much faster at doing design.
But the point of this whole course is that there's actually a bigger story here, which is that we have what I will call, like, general agent tools.
And an example of that would be, obviously, plot code. So what plot code does, it basically takes language and turns it into more language.
And that language can be actual words. It can be code.
It can be CSS code. It's also visual in a way. But because the graphical user interface that plot code uses is very text based, that's why we will still, as a community, need some sort of design dedicated genetic tools such as Google Stitch, Figma, and Make.
And the bigger story here is what these suite of tools we will be using in the future actually enables us to do as designers.
So if we look at our role as some kind of creative directors or orchestrators, what we have here is the old school traditional legacy Figma Adobe and Son, which might be still there to help us do the craft part, right, pixel to pixel.
We will also be using these new tools, so agentic design tools such as Stitch, FigmaMake, UX pilot that will help us do some of the stuff that we have done previously just faster and more effectively. But this general agentic tools such as ClotCode and Cursor help us actually build out more stuff that we couldn't do so far.
And let me actually show you what I mean. So here's a list of stuff that we can do as designers now.
Also, if we really get fluent at tools like ClothCode. We can start building and shipping software, actual working software.
We can automate design operations. There is a lot of scripts that ClothCode can help us write where we can automate some of the tedious tasks. We can analyze research data at scale.
We can build internal tools. Yeah. We can build dashboards, calculators, things like that.
We can also connect our tools better with APIs. We could connect Figma with Sheets or Slack, whatever we need. We could create self enforcing design systems.
So design systems that are AI native that actually if anyone else in the team uses or writes new code, actually, it creates great design. And as we have seen, we can also test our designs as real users.
And this is not a definitive list. This is just to give you some, like, ideas for what is possible because what we're getting into our hands and everybody is if is basically a very, very capable, very, very powerful tool that makes our job easier, but it also expands of what we can do, and that means that also the value of our work can go up if we actually adopt these tools.
And I think that's the very positive way to look at these tools as opposed to just them taking our job. So if we now jump into which design disciplines that will this will impact, it's basically all of them.
So, obviously, UI and visual design, we have tools that can generate layouts, components, variations of that at very high speed.
We also have the same thing for prototypes and for wireframes. We have well, obviously, we can do synthesis at scale if you're a researcher. If you're a researcher, you can also, like, build some simple prototypes that maybe previously you had to ask a developer to build something for you.
Now you can just do it with cloud code and maybe have something you can use in a research that otherwise you wouldn't have you would never build because you didn't know how. Then the work of people building design systems is gonna be different. It's gonna be way more about how to build AI native systems.
So not systems that humans can can, like, work with, but something that will work well when replicated by agents.
Then we have design operations will definitely change. A lot of, yeah, manual tedious work can be automated. The brand identity will need to be written in a machine readable way so that it can be read by agents and reliably put out.
And, also, all this work, strategic work around that's understanding the product strategy, understanding to what to work on is also getting augmented with AI because we can do competitor research. We can build dashboards.
We can also quickly do reports with the help of these tools. So they're very powerful. They're touching all kinds of design disciplines across all seniorities.
It is, yeah, a huge, huge paradigm shift. The last thing I would like to focus on before we move into how this technology works is just Cloud Cowork versus Cloud Code. Actually, you can skip this if you haven't heard of either, but for those of you who have maybe started playing with Cloud Cowork, I just want to explain why we're actually just talking about Cloth Co here.
So just as a quick intro, if you have a desktop app installed by Cloth, you can actually see something like this.
So on top, there's basically three products that they have. One is the chat. That's the one we have used.
There's there's co work, and then there's code. So if we draw a line like this, this is basically the chat side of AI, and this is basically the agent side of AI.
Meaning, co work does fall under agent as well. So this is the user interface you see if you click on co work, and this is the user interface for code.
Now the big difference between co work and clot is the way they're working. So, actually, co work uses your screen to move around and do things, which means it takes screenshots of your screen, it clicks, and it just takes ages to do anything.
And, yes, it will get faster, but this so the reason this is this way is because CoreC was meant to be a light version of ClothCode for people who will never touch a tool that looks like this because it does look a little bit intimidating.
And again, we will actually cover all about this tool, how to install it, what you actually use it, and what you see on the screen when you open it. So we'll get back to this.
But, yeah, Corework was built to just serve as a simple version of the code, and it's built into its very nature that it uses the graphical user interface to actually work and to you work with it through it, and also it works through the graphical user interface, which means it's way slower, and it can do fewer things because of that.
On the other hand, Cloud Code can actually work through your file system, and it's not working by seeing what on the screen, but actually just reading the command lines and text.
So it can just do things way faster, and it can do more things. So it's way more capable of a tool, and if you're investing your time in learning anything, you should definitely be learning the Clot code. It just gives you way, way, way, way more leverage.
And, again, we will cover everything about how to install it and how to use it. Don't worry. My main point of this section was just to tell you that there's a huge difference between using AI in the chat function and in agent function.
Agents do things for us. And if we actually adopt this as a community and you individually, you will just have way more leverage, you will be able to do different things and way more things that have, yeah, more value.
That's it in this section, and in the next one, we'll learn how AI agents think and how they work. So if you think nothing else away from this course but just this fundamental framework and principle, you will be a much better user of AI regardless of if you're using chat or agent or if you're using cloth code or anything else.
This is the fundamental nature of AI and agents, which is that they are probabilistic in their nature.
In other words, if we ask AI, an agent, to do something, it actually runs through a probability machine, and it just gives us an answer which is gonna be different every time.
It's very, very rare we're gonna get the same answer even if we ask for exactly the same thing every single time. This is because in their nature, they are probabilistic.
They are calculating the probability of what is the right answer for that request.
So just to show you this, I will just say, hey. Hey, can you write a song, a short song about designers using plot code?
And not plot code, but plot code. And let's do this three times.
Boom. Boom. And boom.
Control ship it. Verse one, chorus. Oh, verse two, chorus, bridge.
Oh, true. Okay. I'm not gonna read it or even sing it.
Another singer. Okay. Here's a short song about design discovery in Cloud Code.
Verse one, I used to push pixels all day long, tweaking shadows, la la la. Let's compare this to here. I used to pixel.
DrewBox is a Figma. Okay. So we can see it's already slightly different even though the structure it's following is pretty similar.
Ultra, bridge, chorus, verse. Same here, but we can always see that it only has one verse. Verse, chorus, verse, chorus.
Yeah. There is verse, chorus, and then verse, chorus, ultra. Why do I feel like there's a bit less text here?
So verse, chorus, verse, chorus, ultra. And here we have verse, chorus, verse ah, bridge. Okay.
So bridge is missing in the last one. Anyway, you get the point.
Right? It's probabilistic, and that's awesome because it's very creative.
It can solve problems it hasn't seen before. It can brainstorm.
It can be creative. It can really cover a lot of ground, and that's why we all of us are using it.
However, sometimes in business and in life, you want something that's much more deterministic.
And what deterministic means is that if you put the same input in, you get the same output out. Right? So if I give you the same input, I wanna exactly same thing out all of it.
An example of that would be a code like a Python script. So just imagine a script that takes an image that we have created, and in the code, it's encoded that each time we run this script, we get three different variations of that image in different sizes.
I don't know. One that's maybe focused or, like, specialized optimized for LinkedIn, one maybe for Facebook, and one for Instagram.
Okay? So let's say we are marketing team, we just need this. When design team gives us an image, we have this Python script that just always cuts out different sizes.
Now when I want these different sizes, I don't want my tool, AI tool to be creative. I just want it to do the thing that it has always done and just deliver the right result.
So our job when we are working with AI and we're designing AI systems and orchestrating AI agents is to understand when to use which nature.
So when to use AI's probabilistic nature and when to use scripts.
The good thing about AI is that AI can act, and by nature, it acts as a probabilistic tool, but we can use it to help us build scripts quote.
And that's why it covers both, and that's why it's so amazing. And that's why, yeah, it just has such a big impact. But I will actually cover more about how we can use AI to build codes and scripts and when to use it as probabilistic and deterministic in the fifth chapter of this video.
So more about that later. For now, the main point is just that in its very nature, when you're using an AI, it's probabilistic, which is good, but also bad, and you need to know that this is its nature and when to use it.
Great. Okay. So the next thing to understand is that especially this is important for us as designers is that AI is a language machine, but at least most of the well, definitely LLMs are language machines.
There's also video models and image models. But in this course, we're covering plot code, which is using language models. So it's a language machine, not a visual machine.
So even when you drop a screenshot into ClothCode, it does not see images.
What it does, it basically tries to translate this into words or code or CSS. Right?
And through that, it tries to understand what you're actually trying to tell it to do or what you're actually sharing with it.
And that's very important for us as designers to understand that when we are sharing screenshots or when doing anything visual, it's very important that we don't just show things, but we try to describe that. And this can be in words.
This can be well, it could be code if you have an HTML version of your visual. One tool I wanna share here that really helped me a lot is to use these voice to text tools.
If you just go on Google or any AI tool and just type in, hey. What are voice to text tools?
You will find a few. Don't wanna promote any. So what they do is that you have a hotkey, like a shortcut on your keyboard.
Whenever you press that, it's just going to start recording your microphone or, yeah, headphones, and you can just talk instead of write.
And I just find it just much easier to talk out loud than to write out. And this way, I just share also what's on my mind and what am I seeing, what I wanted to change. So what I'm trying to say is you can augment this process by adding more words to your visuals when working with AI, if you actually wanna work with it this way.
And one way to do this in a efficient manner is to use these voice to text tools.
Next thing to always remember, I mean, we have all experienced this, but AI will give us false facts with full confidence.
The it never hesitates. It doesn't really understand what is true and what is wrong.
It's, as we said, probabilistic in its very nature. So it will just create something that and be very confident about it that isn't true or isn't working.
So it's very important to always keep this in mind and not get fooled by the confident voice that AI gives us, We always need to have some kind of loops to review things. This is fundamentally the role of a design agent or the employee working with agentic tools.
It is to be that you know, like, a line like a filter for AIs to really know, is this making sense or not?
At the same time, to also use AI in a way where there is less chance that you're getting the wrong answer. One example of that was us. Remember?
When we did the usability testing, we actually spawned out three different agents. So when three different agents go through the same process, you are just having more probability that you're covering more ground, and you actually find the right answer.
So if we had, I don't know, one if you would be looking up a doing, a competitor research and you just ask one agent to do it, it would cover less ground and maybe uncover some fake facts.
But if you ran five agents and let them come to a consensus, you could be much more confident in that answer. So this is how you can use AI to and it's very nature of the AI to actually get you better results.
But at the same time, it's us on us as people who are orchestrating this to also review in the end or create a system that reviews.
And honestly, this is also the additional value of of designers in this process is to visually always review the output if your nature of work is visual. If it's more research or service, then it's just different type of thing you're reviewing.
But ultimately, it is on us to give a green light.
Okay. How to work with AI? So this is a ladder of how you can get more and more confident using AI and how you can be more and more confident in the results that you're getting out of it.
So at the bottom, we have total and utter chaos, which is, yeah, using AI in a way where we get very probabilistic well, very creative answers.
And then on top, we have something we can fully trust. And at the bottom of this ladder, we have the way most people are using AI, which is you open a new chat.
It doesn't have any understanding of who you are or what you're trying to achieve, and you just give it a prompt. Right? And this is where a lot of the slob comes from.
We are just getting different answers every time, and it just it's also pretty generic. The way we get out of this is that we add some kind of rules to it. So if we are designers creating like visuals, what we could do is add certain like brand visuals, or, like, we could take our PDF of the brand guidelines and extract out of it the colors, the spacing, and so on.
And we will write this in something called clot MD, and we will cover this later in the course.
But it's just a system prompt that AI reads every time you open a new chat regardless yeah.
Every time you open a new chat, it preloads this as context. So if you will write in this Claude MD file, if you will write the colors that you wanted to use whenever you ask to design something, the spacing, the logo, and so on, it would follow those much better.
But if you really wanted to repeat exactly the rule every time and to just have yeah.
Just have a a output that is much more deterministic and that you can trust more, then we need to get into the code.
Right? Into the scripts. Meaning turning our design elements, our design ideas into CSS, into components, into language like, hey, spacing needs to be 16 pixels, and so on.
Right? So the more we can get towards the code, the more we can trust the output of a tool like cloth coat.
And mind you, look, sometimes we do want this because we want the tool to be more creative and cover more ground, and sometimes we wanna be here.
But in general, most of our work should be especially the repetitive work, like the production work is all about moving up the ladder.
Again, we will cover what ClotMD is, so don't worry about this. The main message right now is just repeating also this probabilistic and deterministic nature, and that we need to understand what we want when.
And if we if we want AI to follow our taste, we need to encode it and use code. Next thing to remember is that the more instructions we give to AI, the less likely it is to follow all of them. So if I went into an instance, so open up a new chat, open up a new agent, and it gave me 12 things to do, as opposed to giving it maybe three things to do, it's very more likely that some of these would be skipped, not done.
Has happened to me a lot, so the longer the prompt, the more chance it is that it's actually not gonna do one of those things, and then I have to do even more work of reviewing. So the practical and pragmatic rule is to just give it a few tasks at a time, one to three maybe, and then review the work and then move on to the next stage.
Next one is context, Rod. Extremely, extremely important concept.
Not a lot of people are aware of this. So a year ago, I think there was this notion that, hey. The more context we can give to AI, the better.
Right? So I'm just gonna cram everything, all my documents, all my PDFs into this chat, and this way, it knows everything about me and give it can give me a better answer. It turns out there is something called context, which is the more tokens we spent, the more messages we sent, the worse the performance of the model.
Meaning, like, after a 100 messages, the model might be performing just at 40% of its, like, peak quality.
And in the beginning, the first 10 messages, you know, it's around, like, 100%. Well, it's never a 100%, but basically, it follows this kind of graph where first, it's for the first majority of the conversation, it's kind of acting okay, but then it just degrades very quickly and very drastically.
So the whole idea of this is that when your chats or your conversations with agents get longer, then you just should open up a new agent, open up a new instance.
Just I'll show you later how what I mean with this. But, basically, in an agentic workflow or, like, in a chat workflow, this would mean after I had a long conversation with chat, I would just open up a new chat.
And the same thing's in is in agent because we can open up new chats with an agent, so it's the same thing there. So, yeah, the way you can also measure this is that these tools do show you what percentage of context you have already used.
For example, if you have, like, 200,000, 200,000, which is some models give you 200,000, some give you 1,000,000.
Once you get close to a certain number, then you basically just it's better for you to start a new chat. The general consensus right now with Cloud Code is that it starts to degrade around 100 to 200,000 tokens.
It's also a topic of big debate because there is new research showing that it's getting better and better. So maybe by the time you're watching this, you can just have a look at the context rod.
You could just maybe go on and even ask cloth, or we could just go on Google and Google for context rod, cloth, opus model, and so on, and just have a look at what is the current the current rule of thumb.
My rule of thumb is just you kind of get a feeling for when it starts to degrade, when it's not really following instructions anymore, and I generally just refresh or start a new agent around 100 to 200 k tokens. That's that's as of April 2026.
Okay. Actually, maybe just one last thing on why this is the case, why context rod happens.
Well, it is exactly because these tools are probabilistic. So the more input we give it, the more well, the wider the net it needs to cast in terms of the options.
Alright? So if I just give it very, very pointed prompt, it only needs to consider maybe, like, this, like, 10% of things.
But if I give it a lot more context, it needs to start considering all of these other maybe, let's say, that's, like, 60 per 60 degrees angle, and it just needs to think about many, many more options.
And then it just starts to hold too many tokens and too many information in its context window, and it just starts to degrade in terms of performance. So that's why this happens.
And this is built into the very nature of LLMs, and we'll see how far we can correct this. So that's that maybe is going to be one of the big advantages of humans over AIs and LLMs.
It's just that we are able to hold in more context than they are. But let's see. Okay.
So that's how AI agents think and work. Next one is setting up our agentic environment. Okay.
So the first thing we need to talk about is three different environments or user interfaces that you have available when you're deciding to use Cloud Code. And these three environments or UIs are terminal, Cloud's desktop app, or something called IDE, which is integrated development environment.
And if you've never used this or any of these, that's fine. I will go through them now and explain what they are.
So first is the terminal. This is Cloud Code's native environment in the sense that when it was introduced, when it was developed, it was developed to be used in the terminal. And if you have never used terminal, that's completely fine.
We will not be using as a part of this course. By the way, you get access to terminal is that you use your Spotlight search if you're using Mac and just type in terminal, and then you will get this kind of command line interface where you actually are talking to your computer by typing in commands.
So it's command line interface, which is completely different from the graphical user interface, which is what we're all used to and we're all using day to day. So while I do have to say the terminal's version of Cloud Code is usually the most capable.
Why? Well, because all the new features that come out, they come first to terminal. Sometimes they're also directly available in the Desktop app and IDEs, but usually, they're not right away available also in these two options.
But they usually trickle down to these in, like, couple of weeks. So it is definitely most capable and most recent version of Cloud Code, but it's the hardest to master just because of how we are used to using software, which is more graphically.
One big downside is also the fact that terminal doesn't have any, like, file previews. So the things you're working with, you actually can see those files, whether that's CSS or maybe that's web page or anything else.
You just have to always have terminal and then another software open next to it. So that's the downside, and, yeah, frankly, these are all the reasons we will not be using terminal in this course. Now the next option is the desktop app.
So this is the native Anthropix desktop app in which we can see that we have option to do the chat, to do co work, and do coding. Now we're in the coding section, and you can see that it looks very familiar.
There is a chat field where we can chat with the agent. There's also a way to choose a file because the way agents work is you do need to dedicate a certain space on your computer.
So that would be a folder in which it works, and then you can just chat with it in this environment. So it is easiest to use, but, again, it doesn't have the file preview, so that's another downside.
And that's why we will actually be using IDE, which is examples of that would be anti gravity, which is Google's IDE.
We have Versus Code, and then we have Cursor, and there's more of them. But the one we will be using is anti gravity.
An advantage of these is that they do have file previews, we can actually go through our folders, and we can actually work through them. We can see the changes that we make into the files.
So when we're actually talking to the agent, it actually asks us, hey. We wanna make this change, and it actually visually shows us the change it's trying to make, so it's just easier easier to know what you're actually changing. It is simple to use, and it's interoperable.
And that's a big point, which is if at any point in your journey, agentic journey, you don't wanna use anti Cloud Code anymore, you can actually just switch you can have the same folders, the same files, and just switch to another model.
For example, Codex. You can just use Codex to OpenAI's basically competitor product to ClothCode, and you can just use OpenAI's models to basically do your work.
So it means you're not locked in into Anthropic's way of working. So for all these reasons, we will be using antigravity and IDE as the environment.
And, again, don't worry if you have never used this. I will explain everything how it's used. What I will say, and just as a last thing here is that this is definitely the best starting point in my opinion.
But then later, once you get more comfortable with using Cloud Code, you will then also be able to use terminal, and you can also use Desktop app for certain use cases. But let's just simplify for now, and let's just focus on this one.
K? So next step for us is to set this up, so to actually be able to use anti gravity and cloth code within it.
So we need three things to be able to do that. The first is the subscription. So cloth code only works if you are a paying customer.
So they have four, essentially, plans. First first is free, then it's pro, and then there is max, which comes in two different tiers.
One is $100, and then one is $200. Essentially, it's similar to the pro version.
It just gives you more usage. I would suggest you start with a pro just to get to know Cloud Code and see how much you're using it.
And then if you, like, constantly are hitting the usage limit, then you can upgrade to max or the super max, which is the 20 times more usage than in the pro.
But, yeah, for this course and for you actually starting to play with it, pro is completely enough. I will not go through the whole flow of you subscribing.
I'm assuming that's that's something that you're all comfortable doing. You could just click on dry cloth and just go through the flow, add your credit card, and then you have a subscription.
One thing I would mention here is just that if your company doesn't let you use these models from Entropic or OpenAI for privacy or GDPR reasons, which is a case for a lot of companies in Europe, I've spoken to a lot of friends who just are not allowed to use this unless they are, you know, using it on their own machine and maybe for not working.
Luckily now, there is some companies that are trying to solve this. Let's call them AI wrappers. So they basically have all the latest models available from Entropic, from Google, from OpenAI.
So this OpenAI, this is Google, this is Entropic. So there's all the latest models.
You can see Sonnet 4.6, opens 4.6 as well here. And it basically means that you can use these models, but in between you, let's just say that this is you, and this is Entropic.
So clot. This is you. In between, there is this company.
An example of that would be Langdoc or Elo GPT, and there is more. So whenever you send a request, you are actually sending a request through your chat message first to Langdoc, and they are actually making sure that there is no sensitive data on that. They're also making sure that this data is being only transferred to European servers and so on, and only then it goes to the models, and then it comes back, and then you get your answer.
So essentially, it is just a way to make sure that you're using it in a safe manner and also compliant manner. So if that's a problem you're hitting within your company, maybe just have a look at the options.
You don't have to use these specific ones. These are the two I have heard of. I think they're both German, but there might be more many more depending on the country you're from.
So no excuses. Okay. So we have the cloud subscription.
Let's go to IDE software. In other words, we now need to download Antigravity. So the way you download Antigravity is you just go on Google and type in download anti gravity, and you will get to a page that looks like this.
So you can decide which download you need. If you're in Windows, you download here.
If you're in Mac, just make sure that you're downloading the right version. If you just go on here and type in about this Mac, you'll basically see what kind of chip you have.
In my case, it's m one. So if you see m something, it means you're an Apple silicon, and you would download this one.
And if it says Intel, then obviously it's Intel's chip, so you download this one. After you click here, you will get the package on your downloads folder, and then you just open it up and finish the installation.
After you have done installing it, bum.
This is check mark. Then now we go through the list or to the steps of setting it up.
And I will not be sharing my screen because I have already set this up, and I have rather just use my wife's computer to set it up also for her and took screenshots so that I don't mess up my own setup.
But for you, it should be the same experience. You will see exactly all the steps you need to take in order to, well, start using anti gravity.
So at this stage, at this screen, I'm assuming that you have installed anti gravity and opened it. And this is the first thing you will see. Welcome to anti gravity.
Let's get you set up. You obviously click the button next, then we move on.
Now you choose your editor theme. You can use the dark modern on any other that you like. Then, again, you click next.
Then you choose how you wanna use anti gravity agent. I suggest you just go with review during development, then you click next.
Again, here, just click next. It means it will download some of the extensions that are going to be useful when you're actually using this, and then you have to sign in to Google.
So AntiGravity is Google's product, so you do have to sign in with your Google credentials.
So you just click here, and then it's gonna open up your Gmail or Google Workspace page, and you just authorize Google to sign in, and that's it.
By the way, if you don't wanna use and if you're not a user of Google and if you don't like their services, everything I'm saying here, everything I'm saying here, it's equally useful, equally applicable to Versus Code.
So these two tools look essentially the same, almost the same. There's minor differences.
So if you don't wanna use Google's products, you can also just use Versus Code. The whole process is going to be very, very similar, if not exactly the same. And if you get stuck using or installing it, you can just use, well, Clot Chat or Gemini Chat to just get you unstuck, which is also what I suggest to you if you're watching this video and some of the screens have changed and you're not sure what to do.
Just take a screenshot, put it in a AI chat, and just ask it to help you. So next thing you will see is, obviously, you will need to accept the terms of use, then Entegravity will ask you to install OSCA script, OSAS script on your machine.
That is necessary. So just click okay here and put in your password for your computer, and then you'll get to the first screen.
But we're not done yet. Right? Because what we have done now is we have just set up antigravity, but what we still need is an extension to use clot code within antigravity.
Okay? So we do have anti gravity setup, but now we need to almost, like, add a plug in, you know, almost like a download an app on a phone to for this anti gravity to be compatible with cloth code.
Well, actually, just a minor detour. What you will see here on the right hand side is an agent that's a built in agent by Entegravity.
And if you click through well, if you click here, you will see that, actually, you can also choose SONET 4.6, and you can choose Opus 4.6, which are essentially Anthropix models.
But I would suggest you don't do that because it's not doesn't have the same features as using Cloud Code natively within its extension. Okay?
So what you have to do to add this extension is on the left hand side of our anti gravity, you will see this kind of menu, and your job is to click this option.
This is extensions. Okay? Once you have done this, you need to type in clot code into search, and then you need to look for this kind of looking icon and option.
Make sure that it's Anthropix. Alright? So there's some who some plugins and extensions which aren't Anthropix native, so just make sure that when you're actually reviewing this page and before you click install that it says Anthropix here.
Alright. I'm just gonna highlight this again. It says Anthropix here, and you will see millions of downloads.
You click install and also make sure auto out of the update is selected so that it's going to be updated automatically. The next thing you have to do is you have to click trust publisher and install. And the the way you know that it's installed is that you will now see uninstall button instead of install, obviously.
And we're almost done. The next thing then is basically you will yeah.
Next thing we have to do is you have to click this button here. Let me actually be a little bit more clear. All of these have have such a big thickness.
So this this is Anthropic's logo.
You have to click here in order to see a screen like this.
Okay? So what we do now is we click on Cloud AI subscription because what we're doing now is we are connecting the extension with our own username, with our own plan.
You know? If you have bought Pro or if you have bought Max, now we need to tell it who you are that you can actually start using your tokens. So you click here, and it's going to ask you to open a page.
Obviously, click open. The next thing you will see is in your browser, you will just there's gonna be a page open up by Entropic, and it's going to ask you to connect your clot code with your clot account.
And you just click authorize, and then you will see a screen like this, and then you're ready.
Welcome. Alrighty. So that means is that now we have everything ready to actually start using Cloud Code.
We have the subscription. We have the ID software, and we have the Cloud Code extension within our IDE.
Okay? Alrighty. So if you decided to use desktop app, you wouldn't have to do any of that.
You could just jump in. But, again, I think for if you're serious about using agentic tools, that is a good investment to just go through this process.
Okay. Now I want you to I will guide you through the controls. What do you actually see when you open up your anti gravity instance?
So let me just open it up. So this is what we're exactly seeing. So in the middle, basically, we need to choose what folder we'll work with.
And on the right, we have this agent, which as I said, for now, let's just ignore it and let's just close this. But because agents do stuff on our computer, we need to give it a dedicated space.
We need to give it a folder within each within which it will actually be doing its job. So you click open folder, and then you basically choose one of the folders you have.
I suggest you create a new one. Let's just call it in my case, I'll call it demo.
You can call it whatever you want, cloud codes, whatever. So just create it and then select it.
Okay. So you can see that the view has slightly changed. Again, I'm going to close the agent.
And here on the left, can see that now we have this my folder open. Within this folder, there is nothing yet.
But as we now start building things, there's going to be more and more stuff in it. Okay. So what we need to do now is we need to open a cloth coat, and I'm just gonna click here.
Actually, let's say it differently. So just type in command n and click here.
Entity Guarantee frequently changes certain yeah, buttons to open things.
But the most reliable way to open Cloud Code instance, if there's nothing on your screen, is to just click, command and letter n, command n, and then just click this button, and then you will get a Cloud Code chat.
And this is what you wanna see. This is how you know you're actually talking to Cloud Code.
There we go. So you just first send the first message, and you see if it's working. So what I wanna do now is just show you some of the first commands and how everything looks like.
So what you can see, obviously, as a at the bottom, we have the chat function. We are typing stuff in, and this is pretty, I think, familiar to to most of us. One thing I wanna do is just have this open.
Yeah. So this is the file preview view, and I suggest you have this open most of the time. And then on the right, you can have your chat with ClothCode.
You can obviously have multiple chats. You can open as many as you like. You can also use use hotkeys to move between these.
So option command and left takes you left. Option command and right takes you right. Command w closes it, and you can also close it like this, obviously.
Also, you can open the history here. If you just click here, you can see some of the previous sessions, and you can just also reopen those.
And, also, you can open a new Claude code instance just by clicking the plus here.
Right? That's another option. Instead of clicking it here, you can also click it here.
Alrighty. What else do we have? So we have the chat, then we have, well, these commands.
So whenever you type in slash, you will just see options of the things that you can do.
We will just go through some of the most basic ones. And I think once you get more fluent, you can also just learn and add yeah.
Learn how to use more of these. The most important ones are switching the model.
Right? So by default, you will have Opus 4.6, which is their most capable model.
You can also switch to Sonnet or Haiku, which are two of the less capable but also cheaper ones. Actually, let me just show you all the options.
So as I was just saying, we have opus, we have sonnet, and we have haiku. And as the name suggests, you know, it's taking its analogy from the, well, poems.
So Opus is the slowest but the most capable. Right?
But also the most expensive. Sonnet, it's pretty fast, but it's much cheaper.
Let's say, quite a bit cheaper than Opus. But it has, like, 80 to 90% of the capability in terms of the thinking that Opus does.
And then there is Haiku, who is just very, very fast and very, very affordable, but it's not as capable in terms of the thinking. So depending on the task at hand, you can just choose whichever you actually want.
You can see there's a huge difference also in the prices. So $15 per million tokens in Opus, $3 per million tokens for Sonnet, and a quarter of a dollar per million tokens for Haiku.
If you are a pro or max subscriber, you will not be paying for this exactly these prices because you're heavily subsidized.
But if you actually use their API tokens, which is a different kind of product, and let's leave that for another video if we ever do advanced version of this video. So this is just for us, like, illustratively to understand how many tokens we are burning, but we're not exactly paying these prices if we have the pro and max accounts.
Okay? But it's important because Opus spends most of our tokens, and if we need to save some of that, we can just use Sonnet.
My suggestion is that you start with Opus. You see how fast you use it, and then you slowly start to get a feel for what to use, which model for.
Some of the most advanced users have a good feeling for, like, for example, Opus. They only use Opus for more advanced coding and for planning, and then they leave the execution to Sonnet. And then for certain very simple, agentic tasks, you could use Hike.
For example, I have one automation where I use agent to label all my emails so they it goes through my emails, and it just puts them into right sorting it into the right how is that called?
Not extensions, but labels. Yeah. Labels in Gmail.
And I just use Haiku for that because it's way faster. And then I use Sonnet and Opus for other things.
So, yeah, going back to anti gravity, we just spent some time talking about models, which is this.
So the way you actually switch models is, well, you can just click here and click switch model, and you can choose the one. And you can do this mid mid session.
Right? I can start chatting with it first in Opus. Hey.
This is Naya talking to Opus 4.6. Now mid chat, I can also change and go into model, and I can just use Haiku. And it says switch to Cloud Haiku.
Okay? Then you can just do that. You can do the same also just with a slash command model, and you get to the same page.
Next thing that's very, very important is also this, which is permission mode.
And this is what most people are worried about, which is if I give a task to an agent, what will it actually do?
Well, there's four different now there's fifth one, but let's, again, leave that for now. Four main ways, four main permission modes, ask before editing is basically whenever Cloud makes any change, any file, even delete like, not even deleting it, but moving it, editing it, creating it, it will always ask you.
Next option is edit edit automatically. Let me just maybe zoom in so you can see who it is. So we have ask before edits.
We have add it automatically, which is that once you give it a green light for that specific task, it will do that specific task without asking you for permission all the time, but it will ask you permission as soon as it goes outside the scope of that task or that file.
Then we have the plan mode, which is a very, very important feature, especially for the beginning of chat when we're starting a new task. I typically use plan mode all the time.
So when I'm starting a new task, think of a new build, I always use the plan mode, which means it's just a simple injection of a prompt that tells Cloud Code to not act right away, but to first try to understand the context, which means it will ask you questions. And I'll show you how this looks like in a bit. And then the last is called bypass permissions, which means you just letting Cloud Code do whatever it thinks it needs to do.
I don't recommend using this all the time, but I do use bypass permissions a lot after I have done the plan mode. But, again, I wouldn't recommend you do this right away or at all.
Disclaimer, I'm not liable for any the yeah. Any work you do with Cloud Code, obviously, but I'm just sharing how I use it.
So when I use it in the beginning, I used ask before edits all the time because I was trying to understand what is Cloth even doing. And after I got a little bit more comfortable with that, I have switched to edit automatically, then I have switched to bypass permission once I get the feel for once I got the feel for how it's working.
But I again, the way I usually use it is that I first do the plan mode on the on the build on what we're trying to do, and then I click bypass permission, so it just runs faster. And the reason we do this is speed and also interruptions because if you ask for edit yeah.
If you tell Cloud Code to ask you for permission for every single edit, it will just be clicking approve all the time. So it kind of defeats the purpose of also having an agent.
So, yeah, that's on the permission modes. There is a fifth one, which conveniently is already available on terminal, but it's not available on the IDE.
So just as a reminder, I was telling you that new features are first released to the terminal, and then only later, they make their way into desktop app. And, usually, IDE is the latest one.
So in the anti gravity, we do not have the fifth permission mode, yes, which mode yet, which is called auto mode, which basically just means that Claw decides on its own when it just bypasses permissions and when it feels like it's doing something a little bit more critical, and then it asks you for your permission.
So I would say this is probably much safer than bypass permissions. And once that fifth option is available, that's the one that you should use instead of the bypass permissions once you get to that level of comfortability.
I don't know if that's a word, but you know what I mean. Comfortableness. Again, not sure if that's a word.
Anyway, so that's the permission mode.
Where we have let's see. This is this is my list of things we should go through. So permission modes covered.
Model switching covered. Slash commands partially covered.
So slash commands where we have the switch model, you can also click here and see your account usage.
The one the one the last one I will share with you is just slash clear, which means you clear a conversation of all the well, of everything you have set so far.
And the reason this is useful and important is for context route reason, which we have just covered. Right?
So at a certain point of the conversation, once the performance of the model degrades, what I do is just I ask it to recap the conversation so far to me. Hey.
I just want you to recap this conversation because I will hand it over to a new agent. It writes a nice summary. I copy that summary, then I do slash clear.
I clear the conversation and paste what I talked with it in the last session, and then I just continue the build.
So that's why this slash clear is useful. And there's many other commands. I will not be covering all of them.
They might also pop up while we are in the third section of the video where we're actually sharing how we're using it ourselves. But for now, I think these two are most important.
So so slash models and slash clear, I think, are the two most important ones you need right now. And if I have forgotten any well, you can also use slash compact, which means it just compacts the conversation from, I don't know, if you had, like, thirty, forty messages, it will just try to compact that so that its token usage is less.
But my approach is just to clear the conversation because it just gives you better performance. Already, tabs, we have talked about. Right?
So you have you can have multiple tabs here of Clothes Code, and you can have three, four instances, and you can work on different things at the same time. You can see the past conversations.
Let me just copy this. Copy this over. Hot keys, have talked about.
And then, yeah, what you can also do is you can copy paste screenshots. So, basically, one way to bring documents into the conversation is to obviously bring them into this file or the folder that we have now dedicated for Cloud Code to work with.
Right? Another option is to just, let's say, I take a screenshot of something.
So I'm gonna take a screenshot of a another desktop here, and I'm gonna just do command v, and now the image is added to this conversation. So you can also do that as well.
And you can also upload things from your computer. You can add some context, and you can also ask it to browse web, but you can browse web even without you clicking this. So, okay, I think that covers the most important initial things that we need to know about how to use Cloud Code within anti gravity.
So now let's do something with it. And I will just use a simple demonstration of what it can do.
Don't take this as, oh, this is so simple. Why are you not showing us something more complicated?
Well, I'm not showing you something more complicated because I'm not trying to show you something more complicated, but I should show you how this tool works. We will be showing you a little bit more advanced builds and examples a little bit later in the video.
For now, just follow me. Okay? So what I want you to do is maybe go on let's turn our LinkedIn page into a website, into a VC or portfolio website.
So my challenge to you is if you have gotten and if you have followed me so far, go on LinkedIn, find your profile, and then click save to PDF.
What this will do is it will just save this page as a neat PDF as your CV. So that was just done for me. And what I will do now is I will bring this into my folder, into this demo folder.
Right? So what I need to do is I need to go into finder. Where are you finder?
Oh, here. Okay. So in my downloads section, I have profile, and then I would just carry it over here to the demo.
I could have done the same thing also just in finder. Why? So I could just where is it?
Yeah. I could just have taken this profile PDF and just, you know, carry it over to the folder that I wanted. It would also show up here if that's the folder that I have opened in anti gravity.
So the first thing that has happened, as you can see here on the right hand side of the screen, we now have a preview of this document, which is what I was alluding to before about the fact that you have file previews and you have, yeah, more visual graphical user interface if you use a tool like anti gravity.
So you can open PDFs, you can open files, and you can just review things here without switching context all the time and opening more tabs. So what I want you to do now is basically turn this into a website.
So let's change the permission mode to plan mode, and let's tell Claude to do this for us. Hey.
I want you to turn the my my profile, which is a PDF with my CV into a, like, a website, a website I can share online and that introduces who I am, and maybe there's a contact form at the bottom.
Yeah.
Since we're in the planning mode now, what will happen is Cloud will not automatically build anything, but it will think. It will then also ask me questions, and we will together build a plan.
And then I will approve the plan, and then, basically, it will only then it will build the website.
It seems that it's looking for the PDF. I just found it. So one thing I could have sped this up was to actually tell it where this profile is, and the way to do this is to copy path.
So if I just copy this over and I told it, hey. The profile PDF is here, then it would now look through my whole computer to find it.
But it did find eventually, and now it's making a plan. And it's going to open this plan and probably ask me a few questions.
Okay. Just finished planning, and it opened a plan here on the right hand side so we can review it and basically decide if that's good.
Basically, it's telling me where it will create this output file, so where this HTML is going to live, which is exactly in this folder demo, which is great.
And let's see the sections. There's gonna be navigation at the top.
Great. There's gonna be hero. There's gonna be story, experience, education, contact, footer.
All looks great. It's giving me some values for colors. But at this stage, actually, I think I would just accept this as a plan and just rather review it visually.
So let's just do that. So what I did now is accepted it, and now I will switch to bypass permissions, and Cloud Code will create a single index HTML, and then we can have a look at it.
What I wanna show in the meantime is also what is actually happening once you are giving a command to Cloud Code.
Mhmm. So one big differentiator and advantage over other models is that it's really clear about its thought process.
So here you can see that we have asked it something, and then here, if I wanted to, and here, Todd for this many seconds, I can click into it and actually see how it's thinking. And we can see that it's think going through a thinking process saying, hey.
Now I have all the content from Alan's CV. Let me plan a personal website, some of the information.
I'm thinking this should be a narrative driven personal brand rather than a full CV dump. I agree with that. Minimum modern, la la la la.
And then it had a comprehensive plan, la la la. Okay. Actually, it's already done.
So we can open this in a browser and see what it has done. I will actually ask it.
Please open it up in in Chrome.
There you go. Okay. So this we can see the navigation.
We can see the color scheme.
Yeah. I mean, pretty solid. It's not gonna be in any design awards for sure or not, but it's pretty solid.
Can you create two more versions just with different visuals.
Don't do dark mode again.
And this is where the power of this agentic workflow comes in. It's just it's so easy to actually review, get a feel for it, give it new instructions.
It has all the context it needs to have, has all the tools it needs to have in order to, you know, for you to be building with it. So in this case, I don't know exactly what I'm looking for, but I just wanted to create more versions, and then I will be able to choose one, and then I will be able to, yeah, deploy one.
Actually, let's do that. We can even deploy this website online and have it online in, like, ten minutes. So let's just wait for it to create two more versions.
We'll pick one of those and then just put it online for you to see, yeah, how easy this has gotten and maybe why we all don't need Squarespace anymore. Let's see.
Okay. So we have one more version here, and I guess I guess we're waiting for another one.
Alrighty. We have two more versions. Open them up in Chrome.
Okay. We have this version.
So it's basically the same layout. It's just different colors, which is what I asked for, but it's actually I don't like this layout.
But, anyway, I mean, I could have gone deeper into the conversation and give it feedback for how to improve this. What I wanna do inside is actually show you the real power of this, which is the following.
Could you actually create a portfolio segment on this website?
Because you have access to all my files. Right?
So just review all the files, everything I have built with Cloud Code so far, all the AI tools, or just pick a few, and just highlight them, write a short description on this website just to convey to potential employers that I have been playing with Cloud Code, and I know how to use it. So, yeah, just pick a few, maybe four or five, and make a new section on the website.
Just let's choose index lite as the one we're taking over into the next stage.
So just work on that one.
There we go. Clot. It's sort of cloud.
So what I have now is at the more you're using ClotCode and the better you well, the more things you can build together and better you understand how it actually works, you understand it has access to the files to your whole computer.
We don't give it the access to write files all over our computer. It can only write and create stuff within this folder, but it can read files all around our computer.
So it's actually now going through all of my computer to find all the things we have built together. It has the intelligence to be able to do that.
And based on that, it will go create a section on the website, which is going to work as a very simple portfolio. Obviously, we would wanna make it a little bit more visual, and I would maybe take some screenshots.
Actually, I could even ask you to take screenshots. Maybe that's gonna be the next stage. Actually, can you bring in some of the screenshots of these projects into it?
I mean, just take a screenshot of the maybe, like, a landing HTML for those of the projects where this can actually be done. So that's gonna be my next message to it, but let's first see what it has done in this stage.
Okay.
Just finished up adding a new section and open up a new Chrome tab for me. And we can now see that there is this section called work, which was not here before because we can also see the previous version, and there is none here. And we can see five of these examples.
Let's see actually what happens if I click in. No. This would this is broken.
But this is really cool. I mean, it just went through my files and just created this out of nothing, basically. But now let's try to make this a little bit more visual.
So I'm trying to go back and asking it basically to make a to to bring in some screenshots.
I mean, just take one screenshot of maybe, like, a landing HTML for each of those projects.
Yeah. So let's see how we can also bring in some visuals. I'll be back with you when it's done.
Okay. Took, let's say, roughly two minutes to do this. And you can also see that within this folder demo, there's a new folder called screenshots, which means it has tried to capture screenshots of these portfolio examples.
Let's see what we have in Chrome. So if I now scroll on to work, there we go.
We have some images here. So this one looks good. This one looks semi good.
I mean, this white border here, it's probably just actually, this could be that the screenshot includes below the fold, which is the white ribbon or the next section is white.
We could have worked on this to make it nicer. This one looks good, and these two do not look good. And I assume this is because it took a screenshot before the page was fully loaded, and this is something I could easily now also tell it to improve, and the next version would have that as well.
But I'm gonna stop here because my point here is just to show you what you can do with it and that this is not just a tool that is slightly better than a chat, but it's a completely new way of thinking and working. And the last thing I wanna share within this section is just what we have just done now, which is the basic way of working with agents is this loop where we are the director, where we set the goal, where we tell it what to do.
Then we have the agent who does the work, and then we review it. We evaluate the result, and then we give it another direction. So that's basically what we're doing here over and over again.
There is a more advanced version of that where actually, just go go just to go on a slight tangent, just imagine this is the more advanced version where agent also evaluates the result.
So it's not us, but it's an agent also evaluating the result. But in this case, we are living somehow outside of this loop. So that's us.
And we are creating this loop, and we are just reviewing the loop and the results of this loop improving over and over again. An example of that would be using something called auto research skill, and that's far beyond the scope of this video.
But it's just a skill that basically lets you build a loop where agents are trying to optimize for a certain result, let's say, the page load speed. It's making tweaking, making small changes onto the code and onto the website, and it's just trying to make it load faster and faster.
And, actually, because the objective of the objective is very measurable, so the the load speed, it can actually just review itself.
And then we're just reviewing the process, and then we tell it when to stop and when it's good enough. So that's the more advanced version of this. But for all the intents and purposes of this course and this level, I think it's just important to know that the agentic loop is basically us giving it giving the agent some work, then agent does the work, and then we review it, and then give it another direction.
So that's basically the basic agentic loop we'll be using over and over again. This also means that we have now finished the first section of this course, which is the technological context, which means now we understand how technology works and things.
Now And we can go a little bit more into well, I mean, actually hide this for now. We can go into our own context. How do we bring our own work into it, and how do we actually get work done for us?
The first thing we'll have a look at is something called a system prompt. But maybe before we jump into this, just to give you some context, which is gonna be useful. What we have done now is basically we have used ClotCode in the most rudimentary way basic way.
So we basically asked it to do something without giving it any constraints or real rules in terms of our taste.
Right? And that's why the result we have gotten at the end was pretty generic. It is what some people would also call AI slop, visually speaking.
Visually speaking, it is quite, you know, basic. Nothing special.
So what we wanna do now is we wanna basically go to level two. And the way you bring some rules in natural language into the AI or into agents is through something called system prompt, and a system prompt within Cloud Code is done through this Cloud MD file.
So if you have never heard about it or seen it, don't worry. I'll show you everything. So I think maybe the best way to get a feeling for what it is is to maybe just show you the power of it.
So let's head back into anti gravity. And what we will do now is we're still inputting the same folder demo, and we'll just ask it to ignore some of the things it has built, and just now follow this Claude MD file.
So if you notice, now I have uploaded a new file Claude called Claude dot MD, and I will just ask you to follow it and basically create a new layout for the page or a new version of this personal page.
So I have triggered the plan mode.
So it's gonna take some time to go through the plan and build it out. So I'll be back when it's built out, the website. So here is the result.
I mean, even just a quick glance just gives you completely different feeling. Definitely looks way more modern, also aligned with the rules I have given it.
So, like, this color here and this accent and this color here, that's all, like, the brand colors of what I have defined. I wanna be I wanted to be using paddings.
Yeah. Just just gives me a completely different vibe. Definitely looks something that I could use.
And well, don't get me wrong. It's not, you know again, it's not gonna win any design awards, but we have now gotten to, like, level two of this of the result.
Visually, we have defined certain things through the system prompt, and we have gotten a way better result. So let's have a look at what I actually fed into the Cloud Code by giving it Cloud MD.
So if I click into this, what you will see is that I'm reading a simple text document. That's all it is. It has sections like project, so it tells Cloud more about what this folder is about.
It has section about architecture, so how this folder is organized. There's code conventions.
There is design system based on the d m b a branding. We have the content and the tone, so what kind of tone of voice we wanted to be using, and some rules.
Right? And just with that additional input, he was able to create something that's way more aligned with what I actually wanna use.
Right?
So what I wanna do now is explain how this is how you can build your own and how this is even used. So if we go back to our board here, you will see that this is just a screenshot of a ClothCode chat.
So every time I have a new chat with ClothCode, I'm writing, you know, something.
I'm telling it what to do. And most people think that this is the only prompt that chats and agents are getting.
But, actually, what happens is that every time I send a message, clot m d is basically inserted before that.
So every time I open a new chat, clot reads clot dot m d. And that's why it's a system prompt because it's read every single time. So the hierarchy is as follows.
First, it reads ClawdMD, and we could have some information about the brand.
We could also have some other information in the ClawdMD. Then it reads our prompt, and only then does it give their response.
Right? And that's why if we don't have CloudMD and we just tell it to do something, it's going to be very generic like we have seen with this website. But with CloudMD, we get basically something that feels on brand.
It feels something like we would actually want to use. So the way you can think about it is almost like . So now just a few words on what even is dot m d.
And the best way to explain is to explain the difference between maybe a PDF, which is the most common way we would usually work with documents, and MD.
So PDF is optimized for rendering, meaning it gives us a reliable way to show text, to show document on different screens and also on printers when we print things.
That's why it has way more metadata, way more tokens, way more information for agent to read than MD.
MD is basically marked down, stripped down text file. So it only contains text, and the formatting is very, very basic.
So formatting is basically only these, like, hashtags and these stars here. That's basically what formatting is, and you can see that it's way shorter than maybe a metadata information that is needed in a PDF.
And why is that important? Well, it's important because of the context route. So the more context we feed into the model, the worse the performance.
Right? There's a certain drop off. So that's why with markdown files, we're trying to be as optimal in terms of the file that we are putting into the LLM.
And MDs are just very native, very yeah. Very condensed file types that are just optimized for agents and chats to use.
So if you have PDFs with a lot of information and you want it to be more optimized for working with AI, you just can transform this into MD. There's free services online.
You can ask ChatGPT. You can ask any tool you're using, either chat or agent, actually do this for you, and it will gladly assist you. You can also build MD natively.
And right, but the the way you build it is you can even ask Cloud Code, hey. Can you actually help me build an ND file? I will feed all the information into you, and you just help me build it out.
So that's on the file type.
So now we know basically what it is and why it's important. So now what would you typically put in it? So if you work in a technological context, working on a technological product, the main buckets would be the architecture of this project.
So how is code base organized, where this where are the API keys stored, things like that.
Then we would have code conventions, then we would have design system. Right? This is the part that we would own.
And then also, we'd have content and tone, so tone of voice, and things like that. So what you can see is that in a bigger project, you have different teams owning different parts of the CloudMD, and it would be shared among the team. Right?
So we might be owning this part. Somebody else is owning the other part, but we're all sharing the CloudMD together because we're, like, basically encoding it with our taste and with the preferences and yeah.
Of not preferences, but also just the logic of this project. Now this is for technological context.
If we would just strip down this to the most important parts of what we want in Claude MD, it is basically the what. It is the why and how.
Okay? So we would talk about what is going on here, what is the goal of this, which is the why, and then how are things structured, how are things built.
So one thing that's very, very important to talk about is also the recommended length for these things. The shorter, the better, I would say.
So, like, 40 to 80 lines would be ideal. You can go up to a 150 lines, but be be above that, you need to split out so your CloudMD is getting too long. And what you do if you wanna split it out is basically the following.
Right? You can see the CloudMD as kind of a hub hub and spoke system where it just basically tells agent, hey.
If you ever need information on this, read this document. If you ever need information on that, read this document. In other words, hey.
See brand guidelines here. You can see component rules here. You can see tone of voice here.
So, yeah, CloDMD is read every time, and then it basically just tells the agent what it can find where. So what we would typically, as designers, put into a project, let's say, more like a product project, would be, yeah, like design system stuff, topography rules, naming conventions, tone of voice, component library, and so on.
Now there's two additional things I wanna mention. One is call them these on different levels.
So if we have a file called let's just say that, you know, I have this folder called demo, but let's say you called it clot. So on your machine somewhere, there is a folder called clot, and everything you will do with clot, you will just do in this one.
So typically, in this root folder, you would have different file folders.
Let's say one is called project.
There is some other stuff. Doesn't really matter. But one of these here also would have ClotMD.
Okay? That would be our main ClotMD.
But then within each project, you know, we can have a project x, project y. Within each project, we can have another CloudMD, right, which talks just about that specific project.
This is getting hard to write, but, you know, you get the point. So this is CloudMD, and this is CloudMD. So what would happen now when I open a new chat?
Well, if if the root folder of accessed so if I open a Cloud code and I tell it to open this whole folder, it will by default just read this one.
Right? This is gonna this is going to be what it's reading every time it opens you open a new chat.
But if it realizes that actually you wanna work on project y, and project y has Claude MD, then it's and only then it's going to read the second one. Okay?
So the message here is you can have multiple Claude MDs on different levels of the project, and then Claude will only call the correct one when it actually needs it.
Additional side story here is that these CloudMDs on project levels usually do look like this, but then you might have a CloudMD which is more on a personal level. So if you're using this folder for all of your business work, this CloudMD could be more of an issue where actually you tell it about who you are, what are your goals, like KPIs, who is your team, I don't know, where you live, what kind of tech stack you have, all the context you would want it to have every time you open a new chat.
Right? So it might be more personal, and then these are little bit more technical. But, yeah, basically, you can use this with the wherever whatever way you want and whatever a way it works for you.
These are just some, like, basic fundamentals of how this actually works. Last thing that I need to mention here is that, obviously, as the name suggests, this is something that works with Cloth.
So only Cloth code will actually read ClothMD by default. If you actually at any point of your work, actually I need to go back here.
Let me just take this out. So if I actually at any point want to use this same project, not with Cloud Code, but maybe with Gemini 3.1, which is something I can do in Entegravity by using this agent sidebar, and just click Gemini 3.1, it will not read CloudMD by default, but it will read something else.
It will read something called oh, this is gonna be a huge font, but it's going to read gemini.md. Okay?
Gemini. Md.
And if you actually use OpenAI, OpenAI, it will actually read something called agent dot m d.
And it's not as simple as just just changing the name of Cloud MD to Gemini MD and having duplicates. It's slightly more complicated, not way more complicated, But my suggestion would be that if you ever actually wanna jump out of Cloud Code into another agent, you just ask it to help you prepare this document, and it's going to know what to do, and it you will be able to then use it also in other agentic tools.
Alrighty. So that's how you bring your context in. I think maybe one last thing of this is that I would suggest that you don't start with that.
So I don't feel like the best way to start your project is to build out the CloudMD. It's better to just start building and start using this tool. And maybe where you get to a certain point, then you ask it to maybe remember those things and help you create CloudMD.
Unless you already have a huge running project that you wanna transfer into Cloud Code, then you can just open the folder and maybe ask it to help you build CloudMD with you.
Also, last thing maybe oh, I have said so many last things in this section, but I think this is gonna be the last one, is that this is not necessary. This is just a way to get better results, but also there's other ways around it, which is just like you always provide better context when you are chatting with it. So it's not like a a must have.
It's just a good practice to do, especially if there's more people working on it so that you're getting more reliable results.
So that's it about the system prompt. Next on is the three layer architecture. So the first thing we need to talk about is the fact that AI is not a silver bullet.
However, most of us treat it as such. We just give various tasks to AI and just expect it to magically do its job.
And the reason that a lot of us are unhappy with the results is that we are forgetting that AI is very probabilistic in its nature, meaning that even if we give it the same exact prompt, there's gonna be slight variance in the answers.
So it's not deterministic, and it's not highly reliable in terms of the output that we will get, but we use it that way. And if we know that it's probabilistic in its nature, there is a very important lesson about how we should actually be using AI.
Let me illustrate this with an example of a designer working for an ecommerce brand. So just imagine that there is a photographer who just took 30 images of a few products, and now it is our job as designers to filter through those, choose images that we will use, and, you know, give them certain names because we have a certain convention naming convention that we're following.
For example, each product maybe needs to have an SQ number, and that is basically the name of the file.
So the SQ number, SQ, and then dot j pk is, let's say, our naming question. So we have to now, you know, manually also type this in.
The next thing we have to do is we have to do the background cleanup. If the background is not good enough, we need to cut it out, add new one.
We need to then export these images in different variants because the product images are placed on different, well, different sites, and we just need different frames and ratios and sizes.
And then we need to upload all of this to our asset library, and then we also need to do this well, we need to import these images to the I believe this is product placement product page product description page, I believe this is.
Anyway, just on on our website where basically these images will live. So what I see all of us doing is we give several step process to an AI and hoping that we'll be able to just do it right.
Sometimes we actually ask it to do all of this in one shot. We just give it, like, basically a list. Hey.
Do this. Do that. Then do this.
And we're hoping that it's going to work. And or sometimes, more frequently, we see that this isn't working, so we just give it this task, maybe this task, this task, this one, and that one separately, and then we have to do a lot of reviews, obviously.
And then, again, it's almost like using chat because all of these tasks then mean that we have to manually stitch this together and bring it to the environment where we actually need it, which might be a website or any other tool. So the reason that a lot of us are not getting good results with AI is because of its probabilistic nature.
So let's say that for each of these tasks, AI has a 95% chance of getting it right.
So let's just do 95% chance. Right?
So what does that mean? Well, that means if we stitch all of these five together, we get zero nine five to the power of five chances of getting it right.
So that would mean that basically, we have roughly 70% 77, I believe.
I did the math upfront. I'm not a math genius. So roughly 77% chance of AI getting this full process right if we just, you know, give you the full thing.
And this goes to the core of why a lot of us are, you know, not happy with the results, and it also goes to the core of how we should actually be using it, which brings us to the three layer architecture.
And the best way to explain the three layer architecture is to first, you know, compare with how we're usually using AI, which is that we we are serving as some kind of instruction input, and then we are just asking AI to execute.
And I and we're using AI here. And because of its probabilistic nature, we have a high variance in the answers. And, you know, in business, high variance, especially in the later in the pro product stage.
So the closer you are to production, less variance you wanna have, the more reliability you wanna have, and the variance actually is a bad thing. It's good thing when you're trying to brainstorm and look for solutions, but it's bad thing when you're thing getting things ready for production.
So I want us to think about using AI agentically.
If we talk about using agentic AI, I want us to think in three different layers. One is there's instructions, which usually typically come from us, from user, and then there is orchestration, and then there is execution.
So there's additional layer here. Right? So we only had execution here, and now we have orchestration as well.
So let's break this down. So instruction is still us telling the system to do something.
But now we're not telling the system, hey, you do it, but we're giving it options so it can orchestrate how it will do this. Here, we're still using AI.
But then when it comes to execution, we give it two options. Either it's gonna use its brain, so it's gonna use its logic to try and figure out what to do, or it's going to use a script, you know, or quote to actually do it.
Because script, in a lot of cases, you know, it's very close to 100% because we're building a script once, we're testing it, and we know it works as opposed to just letting AI execute this thing.
So let me go back to our example here and explain how this would look like here with us trying to make these photos ready for the website.
So if we were to use the three layer architecture, what we would do is we could build a so called skill, and I'll talk about skills in a minute.
We could build a skill that basically tells AI to act as an orchestrator, and when it gets images, it can use its logic, so the AI part, to actually pick images.
Right? Or actually, this could even be done by us, but you can choose. So AI can maybe pick the images, but then the renaming comes from the script because we really don't want any variation.
We didn't we don't want AI to be innovative, creative with how it's naming our files because we have a very specific naming convention. And if we give AI the task to name our files, there's gonna be typos.
There's gonna be some hallucinations. There's going to be mistakes. So we'd rather use a script.
Next, in terms of the background cleanup, we again, we could use AI to judge if background is on brand or not. And then if it's not on brand, then it could actually hand this over to the script to actually flatten well, actually, when it's good enough to just flatten the image or all the layers in the image.
Next, we go to the next step. Here, we have basically two things that, well, our scripts can do.
So just resize the images and maybe name them. Maybe we could even have the AI step here where actually it defines, you know, what is the focal point of the image based on using using image recognition.
It could define the focal point so that when we are resizing these things, we still have the product in the center. Then we have the asset library step where, again, we could have a script that helps us upload this upload this images, but then AI takes care of tagging based on what is an image.
It could add tags to this product.
And then in the last step, it could help us write the URL of this product description page. And so Script could help us do this, and AI could help write the alternative or alt text for the website as you optimize and so on. So what we have done here is we actually try to use intelligence and code for what they are best at.
We didn't just give everything to AI. We really tried to define, hey. These steps there are certain steps in this process that need to be deterministic, and there are certain steps in this process that we need some intelligence involved.
So let's just, like, build a world or a process where we have best of both worlds.
And that brings us way higher from 77 closer to 90 or 95%, so we have fewer things to actually correct.
Because in the end, we still need to a lot of steps involved. We still need to review this. We'll be what but we are going from a process where we are doing all of this by hand to having AI assist that assist us with a lot of these things.
So that's the basic idea. The basic idea, just to make it more clear, is really try to figure out what we're using AI for, when do we want its intelligence, and when do we want something that's just very repeatable, very reliable, and then let's use code.
And as I was also saying earlier in the course, AI can actually also help us build the code, so it can cover both sides. It can actually help us in intelligence use intelligence and build scripts.
So one thing to talk about here is Cloth skills.
But actually, maybe before we go into cloud skills, let's have a look at just one example of of of what I have built to help me in the DMBA.
Right? So DMBA, as I was saying before, it's a business school for designers.
And there is one really nagging process that we had to take after every student call.
So what we have is each month, there is practice sessions and coaching calls, and the practice sessions are mandatory, meaning you have to be in a call.
And if you're not in the call, then you need to rewatch it and send us in the report. So what we had to do or somebody in the team had to do was basically just review who was in the call.
So what had to happen was just a lot of steps. So they had to log well, first of all, they had to log out of their personal Zoom and log in to our admin Zoom. They had to navigate to reports.
They had to find the right meeting and then download a CSV file, which looks like this. So here on the first row, we have the name of the student, then we have how long were they in the call, and that's it.
Now the issue with the first row here is that we wouldn't really get full names. Right?
Sometimes we would just get their first name. Sometimes it's even initials. You know, like, for me, it would be AF.
Sometimes it's a company name. So you have to use a lot of intelligence to actually figure out which students were in a call, and then because when we would have to open a spreadsheet, and we would have to match the name, find the right column, and then write yes or no if a student was in the call or not.
So on the surface, it looks like a great tool for you know, let's just give this an AI to do, but we had to use the three layer architecture to build also the scripts to be able to actually do that.
So the way it works right now is we have built a so called cloth skill, where the only thing I have to do is basically go into a cloth code instance.
Just type in, hey. Run the attendance report. Here's the URL or the ID of the meeting, and here's the URL of the spreadsheet, and this is the column in which I want you to write your report.
And that's it. And then this does it in thirty seconds, and it's highly highly reliable.
As opposed to us needing to do this by hand, which was like an hour or maybe even sometimes two hours of work, just because, you know, there's a lot of steps involved and then you get interrupted and things like that, so it just takes way longer than what we would like to.
Well, it used to. Not anymore.
The way you build these kind of skills is in Cloud Code. So you open up a new chat, and you basically tell it, hey. I would like you to help me build an automation for the following thing, or I would help like you to help me build a skill.
And then you just, in natural language, explain what you wanted to help you build.
In this case, I'm just explaining what I just told you. I wanna I want you to build me an automation that checks who was in the zone. They need you to join for at least ten minutes.
Then you I want you to mark it as attended in this spreadsheet. The hardest part is matching names from the CCV because not every time they have the right name.
Also, ignore the t m DMB so DMB team members in the TCP file. There's just a lot of, you know, nuance that AI needs to get.
Right? So what basically what basically I have done is build a script that is just highly highly reliable, that uses intelligence when it needs to, and it uses script when it needs to.
So the way it uses script is that it basically connects to Zoom, catches the right TCV file, and then hands over to intelligence to figure out the names, so which name fits to which spreadsheet row, because that's the part where you cannot use a script because that is there's a high variance.
There's new names, new students. They might change their display names, so you can't really use a script. It's just going to give you an error for people that is for new and for whom he it doesn't know which row they belong to.
So it's a really good example where the script does the heavy lifting of extracting certain things, and then intelligence basically basically is used where it needs to be used, which is sorting the names to the sheets.
And the way I build it is even to tell it to, hey. If you're 90% or more sure about this student being in the spreadsheet, just do it yourself.
If you are unsure, then at the end, just give me a list of those names, and then I will tell you where they fit into the spreadsheet. And I want you to remember it so that it's written into the skill that this specific person with this display name is actually in the spreadsheet under this row.
So if they ever show up in a call again, the script and intelligence knows where to put it.
The thing I wanted to also show you here is that I have never built anything before that in in Cloud Code, and it's just really good in also walking you through the process.
I didn't know that we we will actually need to have or set up a Zoom API between the script and our Zoom username. But it just told me, hey.
Go to marketplace.zoom.us. Click here. Click here.
Give me these things, and we build it together.
And, yeah, really, if you're even if you're not a developer, you can do so many things these days with Cloud Code that it's just crazy. So this is obviously an example that doesn't have much to do with design, but you can think about other examples, other applications of this kind of thinking.
For example, you could develop a Drift audit. So you would have a script that pulls all the computed CSS from your live site, maybe, like, every Friday.
And then the skilled the skilled would hold the design tokens, and so you don't have to re explain them. And then the Cloud would basically run the script, and if it encounters any issues, if the audit actually throws out any errors, the Cloud itself could do the first round of trying to figure out what is actually wrong there.
You wouldn't just see an error, but you would also see some kind of an explanation what has happened. So that's the Drift audit. The next thing we could do is research research synthesis.
So you might build a script that feeds Claude one by one all the interviews because by now, we know that actually dropping all the scripts so if you I'd say you have done, like, 20 interviews. If you jump if you just, like, dumped all the 20 interviews or scripts of these interviews into Cloth Chat or Cloth Code, it's not going to do a good job because of the context window issue, context rot.
So what we could do is build a script that actually feeds one by one this, well, these research transcripts and only extracts basically the most important things, and then we have intelligence in the end to basically help us synthesize the learnings.
The next one might be, like, design ticket triage. So if you get a lot of, yeah, tickets about the things you have to do as a designer within your company, whether that's Jira or or any other tool, you could build a script that just basically communicates with that tool through API.
Just gather all of those things, and then Clot could do some intelligence thinking for you in terms of what is the highest priority, or it might even be able to actually fix those things already if you have all the right skills set up.
So there's just a lot of stuff you could do there. On a more personal note, you could also have, like, a inbox triage bot where, basically, if you give it access to your Gmail, it could just go through all the emails you're getting and maybe just already, like, putting the right labels, sorting them out in terms of do you need to reply, or can you just ignore?
Maybe you can even draft emails for you. You could also do monthly reporting. I don't know if you need to report to a client or you need to report to internal team how many hours you have spent on something.
You could, again, build a script together with Cloud Code and another tool that would basically, yeah, track what you're spending your time on, and it would just automate this whole process to a certain extent or fully automate the process of you creating that report and sending it to your team member or client.
There's many other examples. You might also want to create proposals based on a client call.
And so you might wanna have a you might have a call with a client, potential client, and you can have an AI listen to this call, and then you can just create a skill or a script that actually then just gives you a 90% there, 95% there proposal that you just need to slightly touch up and just send send over.
So, yeah, you can see that once you have this mindset of having a three layer architecture, you just see it completely differently, like a new world opens up because, yeah, you use AI not just to do the thinking, but also to help you build scripts, and then you really unlock the whole new level of using AI, which is intelligence and deterministic code, which is a really good combination.
Now before I close this section, let's just spend a few moments talking about cloth skills.
So a few months back, cloth came out with this notion of skills, which are basically like reusable recipes. So in a way, cloud skills are these instructions.
So instead of me needing to tell it every time, hey. I want you to do this, that, and that, I create let's call it a recipe, a reusable recipe where it just every time does certain steps.
And what falls under Claude's skills is so called skill MD file, which is, yeah, the brain or, like, just a natural language file that explains what this skill does and how it does it, like the steps.
And very importantly, skills also can include scripts. So this would be Python or any other code references and assets.
Most people, when they talk about cloud skills or in general, when they talk about agentic skills, they only mention this part. And for some reason, they really forget about scripts and references and assets.
I mean, they usually actually do talk about references or assets, but very rarely do anyone talks about scripts, and they're definitely part of that.
So if you think about Cloud skills, they are in a way trying to, well, in a way trying to create a format for how CloudSkills actually fit.
Well, actually, in other words, CloudSkills is already native to three layer architecture. Right? It has instructions.
It actually uses AI as an orchestrator, and it also can include scripts when you actually need it to execute something. So I'm a big proponent of using skills, but just please bear in mind that sometimes scripts are a part of skills for a good reason.
And as you have seen in my example, they're not that hard to build. Now where do they live? So they live in a hidden folder on your machine.
So as soon as you download Cloud Code, there's gonna be a file that's created by that software, by Cloud Code, which is dot Cloud.
And then within dot Cloud, there's gonna be a folder called skills. And then within that, you this is where you're gonna have all of your skills inside. An example of the skill that I just showed you here is so called attendance skill, which, as you can see, has a lot of additional files in here.
Everything from skill m d to Reference MD, which has a reference to some important, well, URL paths and so on. Then we have the API keys, then we have scripts.
Right? So there's just a lot going on here. And, yeah, I didn't build any of that.
Right? I just told Cloth what I wanted to build, and we just built it together, and it just created this whole folder for me.
Skills are also interoperable among different agents.
So if you switch from Cloth to OpenAI or Google Gemini, they are going to work.
Actually, they're definitely going to work. I'm just thinking whether they need to be slightly renamed or if the convention or where they live is different.
Because, obviously, here, they live in clot dot clot. So, actually, that's something I have to look into.
But, yeah, if you ever wanna switch from Cloud Code or, like, using Cloud Skills in another agentic environment, just ask Cloud Code.
Hey. I wanna actually use this skill also there. How do I make it happen?
Alrighty. So the big picture here is we can also use AI to write code, and then we can really use AI as an orchestrator of our skills, of our processes, where the AI can essentially act as a orchestrator deciding what basic where where and when it needs intelligence, and where and when it needs certain deterministic work, and then it uses scripts.
And then we can package all of that into instructions, into cloth skills, which we can build with ClothCode. Okay.
So the next thing we will learn is basically how to bring your own tools into ClothCode and how to use them within this tool. The first thing to talk about is why would we even want to bring our own tools into Cloud Code instead of just using them, you know, within the tool's native user interface environment.
Because we did say that in the future, we still expect to use design tools within design tools.
You know, we could have Figma, Figma Make, UX Pilot, Google Stitch, and so on. So what's the advantage of bringing these tools into this bigger harness, biggest bigger environment of Cloud Code or any other agent?
Well, there's a few advantages to that. One is that, well, you can basically automate multistep work.
So for example, if you also need to then report what you have done through Jira or any other system, you could have certain flows where this automatically happens. Or maybe you're using your browser a lot to check if the design that you have created actually looks the way it should look.
Or maybe using email to, I don't know, talk to a client or something like that, so email. And there's plenty more.
So the idea here is if we can bring some of these tools that we use most frequently into Cloud Code, we can be automating these flows. And as we have said also in the beginning of this course, bringing context into agent is one of the biggest advantages it has over chat because in chat, we have to drag the context into it, and with agent, the context is already there.
So by connecting our tools, we are actually just by default doing that for a cloth coat. It also means that we can do more parallel work. So imagine opening up Cloud Code in the morning, and you can basically, within one user interface, maybe open three separate agents.
And in this one, you are working on email. In this one, agent is doing some design work. And in this one, I don't know, you need to clean up the tickets for the week or whatever.
So you can see that that's another advantage is productivity in terms of the parallel work.
And, yeah, I think that's already enough benefits for why you should even try and play with that. I think with a lot of these things that we are covering in general in these courses, what I'm trying to lay out for you is just the landscape and the map for you to know what is there, and you will be able to build your own workflows, your own way of working with these tools.
I'm just trying to give you an overview of opportunities. So how do you bring your tools into something like ClotCode? Well, basically, we have three options.
There is something called MCPs, model context protocol, and this was actually created by Entropic to standardize how agents such as ClotCode.
So that's an agent, and let's say this is Figma. How do they talk?
Well, they can't talk directly. What they need in between is something called MCP server. Right?
And what we need to do in order to use Figma or Gmail or something else inside Cloud Code is to connect it through MCP server.
So in order to do that, what we do is we first need to see if the tool we wanna use within Cloud Code even has an MCP server. So you can just go on Google and type in Figma MCP. There's also some websites where you can have an overview of all the MCP service out there.
By the way, one thing to that's important to stress is that not all MCPs are official.
Not all of them are coming by the company that's actually creating the tool.
So if I go back here, the Figma NCP, the one you're installing might be by Figma, but it also might be by another designer who just created their own MCP server just because they wanted to use Figma in Cloud Code.
So, yeah, just keep this in mind. So one way to make sure you have a valid MCP is to just review website like websites like this one and just make sure that there is more people using it and it has some traction and some reviews. The way you install an MCP server is pretty easy.
Actually, let's just do one now together. So this is a pretty well known MCP, probably the most popular MCP out there called Chrome DevTools MCP. It's basically just an MCTP that lets you control your Chrome.
And it's obviously very useful because if you have Chrome MCP, you basically get access to all the all of the tools that you are or potentially could be using via browser, which is majority of them. So this one MCP is to rule them all, so I definitely recommend this one.
So let me just show you how you install it. Well, basically hey.
Can you install this for me?
That's it. It's gonna do its job. We might need to accept certain actions.
Yes.
Yes.
Okay, that's it. I will not restore to Cloud Code now, but that's how easy it is to install NMCP.
Sometimes it's a little bit more complicated, but in general, basically, that's what you have to do. You need to give it access to the file where it can basically read instructions how to install it.
Also, you go back to this page, there's a subfolder here called design category of MCP servers.
So there's also Figma here. If I just, again, send this link to Cloud Code, it will be able to install it. Because in the README, it has this, which is the command line for installing this specific Figma MCP server.
Okay. So that's one option we have, MCPs, probably most common, most commonly used, and also there is most of these.
Second thing that is now up and coming is something called CLI, and it stands for command line interface.
And you might remember that we actually talked about command line interface when we talked about terminal because terminal is a command line interface, meaning we are giving commands by typing them in a line. Right.
So the same way you have MCPs, you might have CLIs for tools. They are, at this stage, less frequent, so less tools have them available, But they have one big advantage over MCPs, which is that the way most MCPs work is pretty token inefficient.
For example, if we talk about the Chrome DevTools, the way Chrome DevTools works is that it actually opens up a Chrome instance. It types in the URL.
It takes a screenshot, and then it reads the screenshot, which we know is very token inefficient, and then it decides what to do next.
And then it needs to do this over and over again. And a CLI doesn't take a screenshot of the website, but actually just reads the accessibility version of the website, which is just language, which is more token efficient.
And it just threw the language or the code, can figure out what it needs to click, and then it on the next page, does the same. So it is faster, usually.
Right? I'm not generalizing, but it's faster and cheaper in terms of the tokens.
However, it is much less popular at the moment, so less tools have it available. If you actually want to dive deeper into CLIs and if they are available for your tool, you can go under CLI anything, and there is like a nice one page.
I wouldn't say this is comprehensive of all the CLIs out there, but it's just maybe a way to maybe get inspired about what is available. But the best way to figure out if there's a CLI for the tool you're using, then, you know, you just go on Google again and have a look at it.
So the CLIs I'm using, just to give you some examples, is NotebookLM.
It is Playwright CLI and Audacity.
So the Notebook LM and there's also one for Google Workspace, which is amazing.
Right? So you have for Google, for example, if you're using Google Workspace, you can well, you can use it, and a Cloud Code can use your Google through MCP or CLI.
Obviously, giving access to your email, the work email through MCP or CLI, There is some risk involved, so just keep this in mind.
But, yeah, you can actually use your you can connect Cloud Code to Google through MCP or CLI, and CLI, again, is faster and cheaper.
Same for Audacity. That's the audio engineering software.
And I want to spend just a minute talking about Playwright CLI, which is my favorite, the one I use the most. And it is the one actually you have seen in action when I did the demo in the beginning of this course where we did the testing, usability testing.
The Playwright CLI was used there to basically open up Chrome and just read what's on the page and just use it. So Playwright CLI is basically just like Chrome Dev Tools, MCP. Instead of using Chrome through visual interface, it's just reading the code of the website and deciding what to do based on that.
So it's way more efficient. Okay. So these are two big options, MCP and CLIs, way more popular but less token efficient and usually slower, and CLI, way less popular but faster and cheaper.
But now they are, like, on the rise, so probably soon we will have more CLIs. Now the third option is connecting your tools through APIs, and this is what you have seen me do here when I ran this demo.
So the demo was me basically telling Cloud Code to just fill out the spreadsheet of who was in the call. And you might remember that in the instructions of me building this demo, Cloud Code asked me to provide it with some APIs.
In this case, the account ID, client ID, and the client secret. And it told me basically how to extract out those APIs. So what we're essentially doing is I'm giving access to Zoom.
Oh, I'm giving access cloud code to my Zoom, but I'm giving it very targeted access. While MCPs and CLIs are, like, very flexible tools that basic can interact with your Figma or Chrome or Google in variety of ways, APIs are very targeted.
Like, I can basically say, hey. Cloud Code, you can only read the meeting reports. You're only allowed to download this CSV file, which is obviously and and, like, it's way more token efficient because it only does that, but it's then less flexible.
So I would say I mostly use APIs when it's about building a script, when I know exactly what I want and when it's repeatable, and when it's something more general where I just wanna have access to a tool inside Cloud Code, that's when I use MCP or CLI.
Alrighty. So that's the context of well, in other words, that's how we bring our context into Cloud Code.
So now we have covered, basically. We understand how the technology works. We understand how we bring more of our context into Cloud Code, and now we'll have a look at just some more concrete examples, use cases for how to actually use this in our day to day jobs.
So in this section, we'll go through different kind of builds, different kind of things you can build with Cloud Code. We'll talk about more the research or discovery phase of design to how do you create things, how you systematize.
He'll specifically will talk about the AI native design system and also about automating tasks, automating processes.
So in this first one, we'll jump into the research phase, discover phase of the project. And what I wanna share here with you is a skill called competitor pipeline research.
It's a skill I have built together with Cloud Code to help me basically very quickly I give it an industry, and based on an industry, it basically defines big players in that space, and it just has a look at their pipeline.
You know, the acquisition, onboarding, activation, that kind of stuff.
Actually, I can show you in the anti gravity. So this is the skill m d.
Exactly. Right? So this is the skill m d, which is the markdown file explaining what this skill does.
Here at the top, we have so called YAML. YAML. YAML is yet another markup language.
Maybe that's going too deep, so let's stop here. The only thing you need to know is that these this text, which is in between these three dashes, is basically the description of what this tool or this skill does so that when we are actually talking to Cloud Code, it doesn't have to load the whole skill unless it figures out actually it needs it.
And this way, it saves tokens. Okay. So here we have the name of the skill, and then the description is that we give it an industry.
It finds five leading competitors, and then it goes to acquisition, onboarding, activation, core task, and pricing. It captures screenshots and compiles a comparison report.
Pretty neat. Right? So you might need a different kind of research, but I basically just wanna share that I have built this skill in no more than ten minutes.
So I just asked it asked Cloud Code to help me build it when I needed it, and now I have it whenever I need it, obviously. That's how that works.
So what I want us to do now is basically just run it so you see how that looks like.
Hey. I want you to run the competitor pipeline research skill and do it in the, let's say, form builder industry.
So this is Google Form, Tally, and other players. So identify five biggest players and just do the the research.
I don't know why I sometimes do this, but I capitalize things in the beginning, and sometimes I just don't correct typos at all. Anyway okay.
Now it's asking me if I do wanna use the skill. The answer is yes. Absolutely.
And what it will do now is figure out which companies it needs to actually research, and then it's going to actually open up a website.
It's gonna use the Playwright CLI, which we have just covered. So also within the in this description is that it will be using command f, Playwright.
Yeah. Playwright CLI, which is the tool of my choice when I need to do anything browser related.
Oh, you can see that the job has started. Google Form, Tele, Typeform, Jotform, and so on.
So agents will do their job. And while they're doing this, I'm just gonna stop the recording and come back when they're done.
Or, actually, let me see if we forgot anything. So this is the Skill MD. It explains how it works.
Oh, yeah. There is one thing which I wanted to show you, which is this.
That when I created this skill, Cloud Code automatically also created scripts for me. In this case, it is a script or a code that just basically explains how we will do this through Playwright CLI.
And, also, I have reference file, which explains the stages of the pipeline that I would like it to always research.
So let's go back to anti gravity, and let's see if it's done. Actually, not yet.
So I'll be back when it's done. Okay. Just done.
So I can click into report MD and actually preview that. If you click on this button here, actually, will see a better representation of the markdown file.
So we can basically see what this skill has done in just a couple of minutes of work. So we have today's date, the five companies it has identified, and we have a nice visual using the AASCI art, which is a terminal native way to do graphs, which you have seen all over this video also.
A lot of these are actually exactly this AASCI kind of graphs.
Just a slight tangent there. But So here now, we can have a look at this report. What what does it say?
Four out of five companies gate their product behind a sign up wall. I guess only Google Form doesn't do it.
Yeah. Oh, also, we can see exactly where this happens. So most walls are exactly the onboarding, which kind of makes sense.
And we can also have a drop off funnel, which shows us how many companies show which part of the flow. We also have the screenshots here.
Yeah. I mean, that was literally two minutes, two minutes of work to get really proper research on the competitors' pipeline.
And, yeah, we could have gone a step further and actually gave it what I didn't do in this case was actually I didn't let it create accounts because I didn't want to spam those services with fake accounts.
But actually, what we could have done is just create bots who would create accounts and actually also use the product to the extent where we could get gather some screenshots. And then we would just have even more comprehensive file report.
And then we could also ask agents to delete those accounts. Right?
So, I mean, this is just to show how powerful this thing can be. And obviously, this is just one example of that thing you can do.
So you can build a skill in ten to fifteen minutes, and you can just reuse it all the time. What you could do with it, just to give you some examples of other design, like discovery slash research skills that you could build is review miner.
So it would be a skill that will actually go on Amazon or G2 and just review, like scrape for reviews on your competitors' product, so you get ideas for, I don't know, the stuff you can build.
A tone scraper, so again, maybe for having a look at analogous companies, competitors, but also companies from other industries, you could just scrape their language and get it analyzed to maybe get some ideas for what kind of tone of voice your product should have. Heuristic audit, we had that as a part of our UX usability here at the beginning.
So one of the agents was actually a heuristic agent that went through 10 Nielsen heuristics of a good design. We can have a color thief.
I love the name, by the way. The color thief is basically just having a look at companies or an industry of companies and just analyzes their color scheme.
So you can see maybe what colors are still available in that space if you're trying to design a brand. You can have a business model mapper. You tell it to have a look at your client or your competitors to analyze who are players involved in the business model of that company.
Same thing with strategy. You can have jobs to be done mapper, so you can have an agent go through the product and actually try to figure out what are the jobs to be done behind those. You can have survey to persona agents, so once you have all the service analyzed, you can tell it to help you shape some personas.
The list is endless, really endless. So it's more your the constraint is just your imagination and also your use case, and it's so easy to build this.
So really, I mean, the act of building this is not a problem. I think it's more about just polishing them, reviewing them, and sharing them with the rest of the team so you actually get the use case, like the value of it.
I think that's it. That covers the discover build part.
Next, although we're gonna jump into create and then systematize buckets. Now to the most fun part, which is how do we create things. So we'll have a look at three examples, and I think if you pay attention closely, you will understand the underlying principles of how you are building things and creating things with Cloud Code, and you will be able to apply this to other cases as well.
What we will do is we will make our portfolio slash personal website live. So the one that we have built in the beginning, you're losing using LinkedIn profile PDF.
So I'll just show you how to easily make it online and not needing to pay Squarespace subscription anymore. Then we'll have a look at how to build a skill.
We'll build a skill called ColorThief, and I'll show you how to build some clickable prototypes of maybe an idea you have for your own business or ideas that you have for within your job.
So let's first make our website live. So just as a reminder, this is the website we have built, the personal website.
In this case, my my for for my LinkedIn profile. And now I just wanna make it live. There's a really cool service called Netify that basically lets you publish these kind of websites and more than just websites.
But basically, what we are now doing is we will be using the free plan that they have available. It says free forever.
Hopefully, it is. Let's see if they change it. But, basically, if you have any kind of personal portfolio or kind of website that doesn't have that much traffic, this free should be able to handle that for indefinitely.
Yeah. So, basically, what we'll do is we'll sign up for the free version of this plan. Actually actually, I have already done this, but if you haven't, you can just sign up here, and then you will get to a page that looks like this.
And what we need to do is we need to drag drop our project file, our website file in here. And what I have done is I have asked my cloud cloud code to actually just prepare me a project.
It's called Netlify deploy where I have all the files that I need in order to be able to now basically make this website live. I'm just gonna drag drop it in here.
And once it's done with uploading, which is already done because it's a very simple website, I have the website live. Right? If I just use if I click here, it is going to open the website.
And, yeah, I could now share this link with anyone that I wanted to access it. Obviously, this is not the most representative professional URL, so you can also use your own custom domain.
So you can buy one if you don't have one yet on any of the domain registries such as Namecheap, GoDaddy, and others. And you can just follow the instructions here to actually change this funky looking URL with your personal, maybe name+surname.com or whatever.
So yeah. What I wanted what I wanted to do with this example is just show you how easy it is to build your own personal portfolio websites these days, and that's yeah.
You can do this with Cloud Code and Netlify and just under well, it really depends on how much time you want to spend filling with design and how many sections you want to have in there. Obviously, this one is pretty simple, so we build it really quickly.
But also, it's not just faster, but it's also cheaper. Right? No need to be paying that money to those services anymore.
Yeah. Well, if we have spent more time on it, we could have also actually connected this contact form with some sort of notification system where we would get notified when somebody sends us an email, but that will be probably another few minutes just of connecting this to to our email so we would actually get it inbox when somebody reaches out to us.
But yeah. That's use case number one.
Done and dusted. And let's go to the next one, which is color thief. So what we wanna do here is build a skill, and I have talked about this skill just now, a few minutes back, which is basically a some sort of a recipe that when we tell it about an industry or certain competitors, It goes online and just scrapes and slash understands what their color scheme is.
And if we are brand designers, if we're just creating a design, we can better decide maybe what kind of color scheme we can choose so we can really differentiate and stand out in this specific market.
So that that's the fun little skill we can build. Might be useful to some of you. But even if you don't wanna use color teeth in the future, what you will learn is just how to build skills.
So let's dive in. We need to go back into anti gravity. Need to create a new need to create a new skill, plot code.
Where are we? Plot code. Boom.
Boom. Okay. So the first thing I suggest you to do if you're trying to build a skill is to actually get a skill called skill creator.
It's very meta. Basically, Entropic has created a Entropic skill creator skill, which you can download here.
It's a skill that basically tells Cloud how to build skills or even evaluate them. So if you just take this URL and drop it in here, hey, help me install this skill.
If I already have it, just tell me so.
I already have it. That's why I'm telling it that it doesn't have to actually do that.
But that's I just wanna show you how I actually install it, which is you just point to a link, and then it's gonna take care of everything for you. And it is going to save that under a folder called dot clot. And then within that, you're gonna have skills.
So I have, as you can see, a lot of skills already. One of those is called Skill Creator.
And within Skill Creator, you have a lot of assets and instructions. One of those is Skill MD, which is the one that if you really wanna get to know the skill, you can always read. Basically, just tell us Claude how to do it properly.
Okay? So I would suggest you to use this one.
Well, install it before you actually build any skills. Since I have it, we can jump straight into building them, building the one that I wanna build.
Hey. I want you to help me build a skill, which I call caller thief. Whenever I run this skill, I want you to have a look at the main companies within a certain industry, or I would just give you the names of the companies that I want you to understand.
Well, have a look at their website, have a look at their materials, and to give back their color scheme, primary, secondary, tertiary colors, call to action colors, give them in the hex coding, and maybe just also take a screenshot of their main homepage because I also wanna get a feeling for the portions and just for how it all all comes together.
So, yeah, the end deliverable of this code should be a report, which can be an MD file as well. Yeah.
Please use Playwright CLA, not Chrome Dev Tool. Yeah. Please build me the skill.
So I have again used my voice to text tool.
Play right. What I'll do now is I will basically put it into plan mode because whenever I'm building something, I do start with a plan mode.
It's just a good practice that most people follow. Instead of it just doing whatever, it will ask you if it has any assumptions and it's not clear about something, it will ask you how to actually do it.
And then after I have seen the plan, then I switch from the plan mode into bypass permissions because it's just faster. And frankly, that's how most people use it these days because yeah.
If you're if you're not on bypass permissions, but actually maybe have asked before edits, the way this will look like is that you will just have to just have this screen on all the time and just be accepting accepting accepting every single edit that it's going to make.
So it's just, at this stage, a good practice to really review the plan and only then do the bypass permissions. But obviously, there's also the auto mode coming out, which will give you the fourth option as well, which is the option where where basically cloud will decide what is okay to just run with and what actually it wants you to ask well, what it still wants to get your input or permission before it actually acts on it.
Actually, I'm not 100% sure if I have talked about this already when we were in the permission modes. I might have, but I think this is so important that maybe I can just explain again.
Permission modes. So we talked about permission modes here in terms of how you use Cloud Code.
And I think I only talked about four options. There is now a new one called auto mode, which is a safer way to skip permissions.
So most people will not be using bypass permissions soon, but you will be using the auto mode. So it's supposed to be just a fifth option here.
We don't have it yet because right now, I think it's only available for the team and the enterprise. It doesn't say here, but I'm pretty sure right now, it's available just for enterprise customers, and it's all going to be available for the rest of us as well.
Up until now up until then, the way I'm doing it here with just plan mode and then bypass permissions is the way to go. Okay.
So we have the plan now, and the way you will know that it's done is you're also gonna have this pop up in the extension. So what I suggest is to carefully read the plan and then accept it.
Or if you don't like it, then you can also tell Claude what to do instead. Okay. Let's see the context.
So Ale wants to a skill that extracts color schemes from company websites. Yes. Yes.
Yes. That makes sense. Deliverable create dot cloud skills.
Yes.
Skill MD, that also makes sense. JS call extraction strategy.
Okay. So I'm not seeing any glaring issues that I would want it done differently.
So I'll just auto accept and move to bypass permissions. And when it's done, then I will be back with you.
Okay. So the skill is done. That took, like, twenty, thirty seconds.
If I click here, I can also see and read basically how it works.
So the input is me, the user telling the company name or an industry, and the workflow is it opens a browser.
And for each company, it does this.
Then it also closes the browser, analyzes, and categorizes, and writes a report.
I mean, that's great. Let's just give it a go and let's see how it feels. Yes.
Do it for, again, maybe like a form builder industry.
So that would be Google Form, Tally, Typeform, etcetera.
Yep.
It's a big part of this process. It's also just testing things out, meaning that the process of building things basically follows this, like, cycle of you having an input.
And there's gonna be a lot of writing now, so let me switch to this. There's gonna be your input.
I'll just make this way bigger.
Input, then AI builds it, then you review it.
Right? Boom. Boom.
Boom. So that's kind of the cycle. And a lot of this is basically us deciding what we wanna build, reviewing if the build is good, and then giving it more input to improve.
So if I go back, still building, so I'll just be back when when it's done.
Okay. I'm back maybe two, two and a half minutes later with, first of all, like a written report inside ClothCode.
What I was able to see while I skipped this section was just how it worked, and I just wanted to show you one little sign of detail, which is that at a certain point, it ran into ran into an issue, and was basically just found its own way to solve that.
So that's a very good feature of Cloud Code that it also can do this and it does do that automatically, but sometimes it if it doesn't, you can also tell, hey, how would you fix it? So it's all about just giving it permission also to try and figure out different ways to solve this issue.
Anyway, now let's have a look at the results. So it analyzed five different companies, Typeform, Tally, Google Forms, Jotform, and fill out. And we have a report here, and we can open it up like this.
And, yeah, we can just see we have primary, secondary, tertiary color, call to action color, background color, and text color for each of these.
We also have some notes. For example, Teles intentionally minimal. Teles brand is the free and simple alternative, so the brand kind of follows that.
Google Form, it's a pure Google for this palette, no unique branding, job form. Okay.
Let's see also if we have screenshots. Full report with screenshots is here. I can't see screenshots.
Did I miss something? No.
Okay.
Okay. It's going to correct this, and then we will have the markdown file with images like we had also before when we did the competitor pipeline research.
I'm just gonna close this because I think we'll have to open it again. Oh, the nice thing it did now is also it just edited the Skill MD because it realized this was a mistake.
And the next time we run this skill, it will just not make this mistake. So I guess I can now reopen this and it should work.
No. I still don't see screenshots.
Where are they?
So obviously, I mean, if I just were doing this once, maybe now it would be faster to just type into to type oh, now it's opening.
Okay. Just opened this file for me in preview.
So it's just showing me the screenshots, which is also fine.
Presentation of the ID extension display. Okay. Well, so if I wanted to spend more time on this and if this would be a skill that I would be using constantly, I would now spend another five minutes to figure out or maybe a minute to figure out how to actually show this because we have we're able to already see this with the previous report, so we know it's doable.
But for what we need now also, the preview pop up was equally fine. But I just hope this shows how, you know, how easy it is to build skills. And while it is easy to build them, I think what is important is exactly the process we had now, which is, like, troubleshooting things and really optimizing them.
So the more you use the skill and the more people use the skill, the better the more, like, safe or the better test it needs to be. What you can do now is, like, I build a skill like this.
You could just also literally just grab it. Let's see. Colorative skill skill MD.
I could basically just literally grab it from my computer and share it with a teammate. They could install it into their cloud code, and they could use it as well. Or we could have this stored somewhere on GitHub, and every time anyone makes a change to the Skill MD, we could all have the same version once we pull the version off of GitHub.
But that's more advanced more advanced strategy.
So let's leave this aside. I think for now, what is important is we can build them, we can share them with others.
The last thing I would mention on skills front is that well, two things. One is, as we have seen, they're loaded every time.
So every time we open a new chat context. All of them are loaded or at least the YAML, the front matter.
So if I go into color teeth and open it up, so this part here this part here is always loaded in every single chat, which is obviously not great. So what is important is that you frequently go through your skills, and if you're not using any, maybe you just, you know, delete it and or maybe put it out of yeah.
Probably delete it. There's other ways to do it, but delete it or use it differently.
And when I say differently, maybe you can ask Claude's code, what are the strategies where you can use these skills instead of them being loaded all the time in the in every single chat.
Okay. So that's one thing. And the second thing I wanted to mention was that actually, if you go under Anthropic slash skills, their GitHub, basically, they have just a whole list of skills that basically they have developed internally, and they're just sharing with the world.
So you can go through this and download whatever you want. What I, again, don't recommend is downloading all of them because they will just eat up your contact window. So really be, yeah, be mindful of what it is that you actually want to build and bring into your cloud code.
Alrighty. So this means that we have now built the skill.
So let's now do the most complicated, which is like building a prototype. So the example I will be using here is, as I have mentioned, like, we are in the NBA.
We are now developing multiplayer games for our students because we just think it's much better and much more fun way to learn this, like, business skills if you actually practice them in a group environment with other students because that's how you actually gonna use these skills also later in your work, so not alone, but probably with other teammates.
There's some competition because in business, there's also competition, and there's, like, real context. You know, there's real context in terms of there's, like, a whole scenario of how you're playing the game and so on. So what I wanna do now is just build a simple game for prototyping with numbers module.
So let's just focus on one, like, single part of this game, and let's just build a clickable prototype of how this could feel like.
And the context for you to know actually, me just open the anti gravity, and let's just explain this together to clot.
There we go. Okay. So what I did here is also I just hidden basically, what is this here is a specific file that it will read automatically.
It will read as part of the like, Cloud MD. Well, not really Cloud MD.
Let me show show what I mean.
As we said before, like, when you're actually starting a chat, what is low loaded first is, like, clot dot m d. That is also your message. But also this thing is something that is loaded or it's basically telling Cloud Code to read it.
So sometimes, basically, this is the last file that we had open, and when I highlighted that front matter YAML, I think I did this.
Right? We were in color teeth, and I basically did that.
Exactly right. Even you what you see now here is that these lines are selected. So even if I close this now, it still says 11 lines selected.
This is no longer really relevant for the next chat, so I'm just hiding it. But if I really wanted to have a look at a certain thing, like fly to research, okay, do Skill MD, read it, then actually, you know, it would show up.
I mean, I can also do this.
Right now, the skill m d is also preloaded as a part of this chat or the beginning of this chat. Right?
So this would be one, two, and three things that are preloaded into this chat at the beginning.
Anyway, that's why I'm hiding this now, and I wanna tell you to build something for me.
Hey. I want us to build a simple multiplayer game that my students at the NBA will play during a live online practice session that we do in a Zoom call.
We'll be putting students into groups of three or four, and each group will have one student who will be screen sharing the game, and then they will be discussing together and submitting their answers. So they will submit their answers, and it's gonna be some kind of competition between the teams.
Mhmm. And then there's gonna be a reveal of the result. What I want us to do is to build this for the prototyping with numbers module.
You have a skill, so you can have a look at that particular module, what it is about. What I already know is I want this game to be testing one particular skill, which is just getting the feel for numbers.
Let's call it number estimator. So I want to basically show, and I want, well, students to train what we teach them as a part of that module, which is how do you estimate numbers out of nothing.
For example, how do you estimate if you just pass by a coffee shop, how do you estimate its revenue yearly revenue? Or maybe how do you estimate number of highway kilometers in a country like Germany or France?
All of these basically gives you the feeling for the scale things, which is very important in business when you're maybe estimating also the impact of your decisions on the bottom line or the revenue. So I want this game to be played, yeah, multiplayer.
I want it to be fun. You know what the main thing I wanted to teach. And what else?
Well, I think it's very important for this particular game to be based on publicly available data. So if we have a certain question about a certain number, the game needs to be able to like, there needs to be some kind of a public statistic about that number so that we can have a clear right answer.
And I want you to build out the scoring system where based on this scoring system, how close students were to the right answer, they get there some kind of a leaderboard, and so on. Okay.
So that's all the context. You you can hear I have given it a lot. I had a pretty clear idea of what I wanted to build.
If I didn't, I would just be able to give it less, and then well, then we would together work through the plan.
But in this case, I think the plan is very thorough already, but I'm pretty sure Claudia's gonna ask me from some follow-up questions after it has read all the relevant information.
Now you can also see the benefit of actually really working with Cloth code. It's almost like exponential. So the more things I have built, the more things I can build with it.
So I referenced a skill called the NBA prototyping with numbers module, which you can see here. Right?
So in this skill, basically, we have a description of the whole module. And whenever I want to do any kind of work with this specific knowledge based on how we teach it, I can just reference this skill.
Instead of me needing to always explain what prototyping with numbers means in our context, because if I just told it, hey. Look.
We're teaching prototype with numbers, the Claus code wouldn't know what I actually mean because well, it's a it's a it's a thing we have actually created. I mean, this whole notion of protolling with numbers, it's not something that's well known.
So a, we had to define it. But if I would be invoking a different skill such as, I don't know, the MBA, yeah, business strategy, well, it has a lot of knowledge about what business strategy is, but also from various sources.
But the way we define it is specific way that makes sense for the design use case. So that's why I wanna have this skill so that whenever we talk about business strategy, Cloud Code knows what I actually mean. Okay.
So as you can see, it's doing a lot of job now really trying to prep for this task. So I will now stop the video and be back when there's something more to share. Okay.
After two minutes or so, we're back with the plan. It took a bit longer because just I have built these kind of games for other modules before, so I just read all the relevant files that were in this folder in order just to learn how we have done this before.
Again, that speaks about . So here is what it's proposing. Number estimator game, a multiplayer estimation game where teams compete to guess real world numbers, revenue, highways, global sales market size.
It trains the feeling for numbers, scale, yada yada. Same architecture as strategy game.
That makes sense. Lock scale scoring. Actually, we'll not even go into all the details because sometimes I'm just trying to send, has it made any decisions that really do not make sense to me?
Because then I would course correct. If everything feels good or actually, I'm not sure here, it's telling me just how the scoring with inside the game works.
And I will not try to fully understand it because it's better for me just for it to build it, and then I will see it there. It's not a critical mission critical thing to know and understand right now.
Magnitude input, so something is that also makes sense.
Dramatic reveal speed bonus. Actually, I think we can we can take speed bonus out.
I don't want teams I don't want teams to just focus on the speed. I really want them to together discuss things. How do we actually understand how many kilometers they are in Germany?
20 questions to start. All backed. Yes.
That makes sense. Actually, I have one more one more idea. What if the core UI element is Google Maps?
Maybe just a link.
And students can see what we are actually trying to estimate.
And there are some because on Google Maps, there are there are hints.
Right? So, like, if I am a person trying to estimate number of kilometers in Germany, and I just the way Google Maps opens for me, I can see the Germany. I can start to get the sense about it.
Or if I'm trying to estimate the revenue of a coffee shop, and it just opens up a Google Maps with that particular coffee shop, the street view of it. I can just click into the coffee shop. I can go through maybe the images, see how many chairs, how many tables it has, what is on the like, what is the average price on the menu.
I think it just maybe better mimics how actually you would do something like that in a real world where you would take some proxy data from something like Google Maps or even company's website to try to estimate some other number.
So I just give this to plot code as a feedback, and it will create a new plan. In the meantime, we can see actually, I was reading the plan here on the left.
I should have read it here because this is just a better formatting and also more thorough. The one thing I always read is definitely the file structure.
I wanna first make sure that it actually saves it and works in the right folder. In this case, this is all clear, so I want it to work in projects, then it's gonna create a new folder called number estimator. It's going to create some scripts.
There's going to be some well, I'm not sure about what requirements text are. Server, Python script, which is very important because we wanna play this game live.
So when there is actually a live call, the way these games work is that me or my cohost, Tom, would host the game on our own servers, so which our machine basically basically becomes a server, and then we just can spin up this game for two hours, share the link with students, and then close it down. Also, this means there's there's any, like, big security vulnerability there.
By the way, I didn't know any of that when I was first creating the first game. I just told it what I wanted to do, which is like, hey. I just wanna have a website that I can share with my students during the during this call, and it just explained everything to me.
Okay. The options you have are we can actually put it on a server. This can be always accessible, you can just have it on your machine and just used during that time.
And you can use this kind of tunnel or that kind of tunnel, la la la la, and I just work through that with with it. Okay. We have a new plan.
Do I see any mention of Google Maps? Let's see. Command f.
Not working in here. Okay. Let's see.
A lobby question reveal finished scoring Google Maps integration. The core UI innovation, many questions are tied to real place. Yes.
I think that's gonna be cool. Instead of just reading, they can review photos, how it works.
So how it works, play specific company.
Okay. What I see here is actually, I think I don't want, which is I want only the questions. What it's saying here is, okay, when a question does need Google Maps, we'll use Google Maps, and if it doesn't need it, then we will not use it.
But I just actually, just to make this even more unified game, just have questions that actually need or benefit from Google Maps to have unified game experience.
Okay. That's one thing I want. Let's see.
Another thing is how will it actually open Google Maps.
Okay. That's a very important technical detail because one way you could build this is that actually the Google Maps will be embedded into our website, which I think would be probably way more complicated.
Another one is to just keep a link to students, and students can open up a link, and they can just open up Google Maps and have a look there. And I think for what we're trying to build, that would be completely enough. Okay.
So I'm giving it this feedback now, and after that, we'll just let it run and build build it.
Let's see what kind of questions it came up with. So play specific question example.
Cafe Kreuzberg, which is in Berlin revenue. Estimate the annual revenue of this Berlin coffee shop. The answer is 35,000, and then it has hints.
K. I'm curious what's that going to do. And then it has a link to the maps.
That's all good. Okay. Okay.
So I think we're gonna be ready now to build, and then we can just review the page, and then we can actually work with the live page, which is also way easier then to understand what we still need to do, what doesn't feel right, and so on.
So I'll be back when the plan is finished, and then I'll just auto accept it, and it will build it out. Okay.
Just for transparency transparency sake, we have an updated plan.
I will just auto accept moving to bypass permissions and let it built, and I'll be back when it's built.
Okay. So the game is now built, and we have the name, the number drop.
There's a teams or student view, and then there is the admin view. Now we need to open this in Chrome. Let's go.
This one is already open, so let's just open the admin view as well. Let's see what we have.
Okay. How well do you know the world in numbers? Explore a relocation Google Maps, estimate a number about what you see, the closest team wins.
Great. Testing team. Join the game.
And then if this is played by more players, I guess if I create one more oh, it's the same URL, same IP, so that's why it just prepopulates with this one. But if this would open by another team, I guess we would see all of them here.
And obviously, we could test that later. So now as a student, I can't do anything, so I guess the admin needs to do something. Yes.
So admin can see who is in the room, and I can start a game. And then the students should see that as well.
Yes. Okay. It didn't work quite a way.
I had to refresh, so that's one thing I would need to debug. But now let's see. Yes.
So that looks right. So we have one out of 15 questions. Many people visit the Colosseum in Rome each year?
Open the Google Maps. We see the Colosseum. That's cool.
I like this. I like this. I like that it's simple.
I like that it's clear. I like also that it's just the depth of the game is hidden in in here, which is like somebody might just be completely bewildered by this question.
Obviously, they have seen the content of the DMA, so they would know how to tackle this. But still, like, how do you know how many visitors? I mean, you can guess, but this game is all about, like, finding clues.
And based on those clues, then potentially having a better guess. So if I now drop the man here in the Colosseum, I might be able to even from this picture, just yes, even from this picture, I might be able to get a lot of hints around how many people visit this a year.
Like, I could just estimate the current number of people here and then multiply this with how many hours it is opened per day times how many days it's opened per year. That would be one path I could do.
I could also estimate something based on reviews. I could estimate also I could go on the company's website potentially. So there's a lot of stuff we could do here.
Let's just put in an estimate, like, round number, 2,000,000, and we lock it in just to see how this looks like.
So waiting for the host to reveal the answer. So one team submitted. Okay.
Reveal the answers. Okay. So this is how it's actually shown.
So we see the actual answer. What do the students see? Oh, students see this as well.
So they see the actual answer, which is 7,400,000. They see their answer, which is 2,000,000, and they see how many numbers. They have many points they have gotten.
So, actually, what I wanna see now is just how this game look like if seven players played it. So let's go back into anti gravity. Hey.
Could you add one more button on the admin view, which simulates if seven teams have answered a question, if seven teams are playing a game? I just wanna see how the UI and UX feels like if it's more players in there. That's another really cool use case for AI.
An agent is just like making up or simulating how the prototype is being used. In this case, we have one real player, which is me, and other six teams which would just be bots.
But what I'm really interested in is how does the game feel, how does the UI feel if it's more players playing, and it doesn't get crowded, when does it get crowded, things like that. And you will see in just a matter of few seconds, we will have a new version of the game where which will have the simulate button, and then we'll be able to test one that one as well.
So I'll be back when this is done. Or is it already? No.
It's not yet. So I'll be back in a few seconds or so.
Okay. This took like twenty seconds or so. And now we're supposed to have a simulate seven teams button in the admin view.
K. Need to start this again. Testing team.
Join the game. Start the game. So this one would just be 1,000,000.
Lock in the estimate. And now I can simulate the seven other teams. That's good.
And reveal reveal the answer. Does that work here as well? It does.
Okay. We can see some issues here. Right?
So there's too many teams close to each other, so we need to find a solution for that. We can also now better see how the the scoring actually works.
So we have team Foxtrot, which got 1,000 points.
Gamma, 800 points, 800 points. So now I'm guessing that they were close enough to get all the points.
That's probably maximum. I mean, I could now also ask LotCode, but just to not go too far, I think this is this is basically just trying to show you how you're now reviewing, iterating, building on that, and so on.
Alrighty. Let's do one more round just because it's fun. How many kilometers of motorway does France have?
Google Maps. It opens in Paris. Okay.
We could correct that. But, basically, does this is this helpful? I think it is.
I mean, having this image might help you figure out how many kilometers is it has, especially, like, if you're from one of the European countries, at least one of the team members is, then they can say, okay.
I know we have this many kilometers roughly, and this is the size, I don't know, Belgium. And if we multiply this through the France, we get some kind of estimate, or, you know, we might actually be able to just use some kind of a legend here.
Is there like a ruler here at the bottom that would just show us? There isn't.
But we could use Google Maps actually to just be I'm gonna drive from Tours to Orleans, and we can see how many kilometers this line is.
And then based on this line, we could start estimating everything else. Things like that. Things like that.
I like it. I think this is a really interesting game. I think we can also just stop here.
What I would do next is make sure that this actually works on my machine as a server. I would send it to few colleagues in the team to test it out with them, things like that. I would also well, I would also definitely where is on Entegravity?
I would definitely open a new chat and tell it to review. Hey. Can you review the code of this game?
Because the fresh instance, the fresh fresh agent doesn't have all the cognitive bias or, like, confirmation bias because it this agent that you see now did not build the game, but this one did. So this one will think it's amazing, and this one can, with fresh pair of eyes, so to say, review the game.
Actually, it works just like humans. So this one is doesn't doesn't have as big attachment to the game, it can just give you better feedback.
Another thing we could do is we could actually take this whole code base and ask completely different model. We could ask well, codex.
We could ask one of the OpenAI models to actually review the game, and through that, also have another pair of eyes on it and be more comfortable that this is actually going to work if we need it to work. I mean, if it's just a clickable prototype prototype for research, then we don't even need that.
One last thing thing I wanted to show you is that because I have built games before what Cloud Code has done, it actually has built this based on a visual, a visual UI of the previous game.
Can you host on my machine and run strategy game?
Strategy game.
And you will see that actually the visually, this number drop game that we just developed actually mimics very, very closely the or it's virtually the same as the strategy canvas game.
And this is almost like a first layer of how you can use clause code to help you build search games are we running?
It's live. No. Number drop is live on that port.
Use a different port.
So eighty eighty is a port that's used by this game. That's why I used to use a different one.
Yep. Well, actually, let's just do this.
So this is the strategy game. We can just skip to the game. We can just simulate seven teams.
Anyway, it doesn't really matter more than that, but you can see that actually visually, this is pretty close to that, if not virtually the same.
I would now have to check everything. There's stuff that we could do better, obviously, but you can just see that Cloud Code had a look at the previous game's visual CSS and code and was able to just infer a lot of things about how the game needs to build and how it needs to look like.
And this is already, like, the first layer of how design systems could look like in the future in the sense that, yeah, these machines are really good at just inferring things from the examples or the code we have already given it. But as promised, in the next session, we'll also show you how to if you already have a design system, how you can actually really properly build it out into an AI AI native design system.
So, yeah, that concludes this create section. And next, we'll go into the systematize where I will actually be joined by a team member.
Alrighty. Time to jump into systematizing where we will dive into AI native design systems.
As you can see, I have someone with me. That someone is Tom, colleague, program director at the MBA.
And Tom had a wonderful opportunity to help us design the AI native design system for the MBA because lately, we basically started needing it.
We didn't need it until now because we didn't develop any technological digital products.
We only had educational, yeah, educational programs.
And now at certain point, we needed it, so we had to solve this problem for ourselves. So, yeah, Tom is gonna show us how he solved this for us and show you how he can do it as well.
So Thanks, Tom. Take it away, Tom. Glad to be here.
Thank you.
So, yeah, like, full disclosure to start with is I'm not a big design systems guy in in several ways. Like, I've worked on a lot of design systems when design systems were first kind of, like, in vogue, what, like, ten plus years ago.
I was reasonably enthused by them. My enthusiasm waned when they sort of got quite fetishized by design teams, and I felt like we took our eye off the ball of, like, where our true value is. I think that might be coming back to bias a little bit now as far as, like, this focus on execution and stuff like that.
Topic for another video, but absolutely see the value in design systems. For us as a small team, we don't maybe historically, haven't always been able to benefit from from design systems.
Like, if you are in a big tech organization, you almost certainly have all the components you could ask for. You have maybe big teams managing them, managing the governance of design systems, which is obviously the most important bit of a design system.
But when you're, you know, small team like ours, maintaining that thing, even creating it in the first place can be, uh, something that gets deprioritized. Thankfully, now, um, with the tools we have at our disposal, we have managed to quite quickly spin up a design system for some of our tools that we are starting to create, some of the games we're trying to create for our students, create a system that allows us to create tools that we have some confidence are going to be reasonably consistent in how students interact with them because we don't want that getting in the way of their learning experience.
But also feel the MBA esque in the way they look, the way they speak, things like that. All the good things that a design system helps you do. Topic for another video is maybe how we developed that design system because very fast, maybe not the robust process that a lot of our experts in design systems might might use, but definitely good enough for us.
But version 0.01. So bit of context, we have our kind of parent brands. So a good example here would be, like, the DMBA website.
So there's a typographic style, a tone of voice, a visual style that we have been using on the website, printed materials, social media videos for quite a long time here. Our context has now changed. We're developing products.
These are tools, these are games where this kind of spacing, this kind of typography, this kind of grid doesn't cut the musters. So we have been, you and I, vibe coding and agentically building these games, right, using AI.
And they come out of the box from these tools, whatever tool you're using, if you give them no context about your brands, they can come out looking, I don't know, kinda like this.
This is like the the you know, this lands on your desk from product product manager. You're like, someone's got a Lovable license or someone's just started to use full code.
Absolutely fine. Like, no judgment here. I think it's I honestly think it's great that, like, this is these tools are freeing up others to be creative.
But if you're part of a if you're a designer in a team and your your job now is to try and make this, uh, vibe coded thing that's landing on your desk, see how viable it is to build and maybe start to look at the kind of patterns and ways that you deliver designs fit this, and maybe even this isn't buildable or doesn't fit at all with the process of how you do things in your team, that's where these headaches start to come in.
We'll come back to that because this is really about using design systems to do agentic coding in a way where the results that come out don't feel like slop and what comes out feels closer to something you could actually build is kind of production readiness ticks a bunch of those boxes.
And that will come to life through some examples we're gonna, uh, we're gonna we're gonna share. So we're gonna jump into, um, my workspace.
Alan, earlier, you were using anti gravity. I use something called cursor. They're basically the same.
Doesn't really matter what what that is. So it's a way for me to explore files.
So I can see, like, file system on the left here. I can see the contents of the file when I click on anything in here.
And then I have something running that I don't think you've demoed so far, which is terminal. This is basically where I run Claude code. I know that in anti gravity, Claude code just kind of runs within a window, the same as in desktop app.
But it's great to see also how this works. There's a chance to get the same view also in anti gravity. I just didn't wanna do it for this,
like, initial course. We might do it if we ever do an advanced version, but that's basically the same. So Yep.
It's basically Cloud Code just running in this little terminal window, so we need to know at this stage. I like this kind of view. I think as a designer, being able to kind of see what's being referenced, be able to see my files.
And, actually, if you're on a team that has front end developers and stuff, probably a similar see a similar view to what they do. I think that's powerful.
Um, and the abstraction of a lot of this stuff, if you're just using, like, the Claw desktop app and you're kind of not seeing this stuff, I They're just yeah, I'm I get uncomfortable with that. So I I I I like to see things in this way. So if you've used a design system before or built a design system before, there'll be a lot of things in here that feel very familiar.
So things like accessibility rules, like our absolute baseline.
The thing you will notice in here that you might not have in your design system that you've built previously is that this is all in markdown. And, Alan, I'm assuming that Markdown has been covered already.
Ironically, for something that's been around for so long, Markdown files right there are now becoming the language of AI, the format of AI.
So we might have had these kind of documents in other formats before.
I don't know, actually. I don't know. Maybe Markdown has been the thing for design systems for a while, but certainly now, like, markdown for the win.
So bunch of stuff in here around accessibility, kind of rules we should have.
We have got all of our components. So this would almost certainly be very recognizable for people.
So we've got our HTML for things like all of our buttons, but most importantly, we've got all the anatomy. So all of the breakdown of what our variants are, how they should be used, the different sizes, the tokens that are referenced, that are used in these different buttons, the dos and don'ts.
All of that guidance is now in Markdown files. So we've got cards.
We've got case studies. We've got chat. We've checkboxes, all the kind of stuff that we need for our games.
So a good example would be, like, chat input. Adam, we've not needed chat input in the in the the the NBA world until the last few months, but now we're building things that our students can chat with.
So in that process of building a design system, we've had to think about stuff like that. So markdown files with all of the documentation for all of those different sections.
So that's the main crux of the design system components, but, obviously, anyone that has used the design system before knows that having your components is it feels like the big job, but it's it's it's not the job.
The job is governance. Uh, that's the important part in here. So how do we actually get people to use the design system?
How do we get them to, um, have some meaningful guidance on when to use something, when not to use it, decision making, how to review work? All that good stuff is the stuff that is where design systems die on the vine is where that stuff is not well documented or not well expressed or that rhythm and that governance, that that person, that team that kind of keeps it alive, keeps people understanding it, getting comfortable with it gets lost.
We are a small team. We do not have a design ops person. So we have, as many of you would have developed a principles markdown file, which basically tells us yeah.
It it talks in a few levels. We have things around, like, the substance of what we build being the most important thing. So the most important thing that comes out of this is around learning.
Right? So all of in this context, everything is about making people feel like they're making good progress, not in a kind of gamified dark patterns kind of way.
It needs to feel well authored. It needs to feel authentic. We need to make it feel like pieces on a table.
This is a good example. So interfaces in this context need to feel kind of physical.
They need to have weight to them. They need to feel tactile because that's all important to how people interact with these things they play with.
So we have principles in here that are not like use this button here. It's things that as a designer you build that sensibility around.
So we've tried to codify some of that. You would almost certainly, over the last five, ten years, have a page in your design system that talks at design principles level.
So, yeah, we we have that codified. We've got patterns as well. So one thing would be having various parts of your design system.
Right? Like, we've got all these card elements. We've got these form elements, etcetera, but how do we decide when they are used?
What context do you use them? How to group them? How to if you've got a new workflow you've designed, how many pages that should be across, all that kind of stuff, which is very important as well.
So we've got rules in here around the rationale of form layouts, all that kind of good stuff. So I appreciate most people watching this probably already know that, but I think it's a good reminder that the design system is not just the UI.
It's one part of it. It's not it's actually not the system. It's the the system is the thing you build around that.
Very, very, very important because if we just gave Claude or any AI tool the UI components and said, go and build us this this game.
We're gonna get a whole world of ways that that is applied. Right? We would get high variance, Alan, in what comes out.
And today, what we're about to demo here is about reducing that variance to a level where we have confidence in what's gonna come out the other end, and we have to do less intervention, and we can have a lot more confidence in vibe coding something that fits fits our fits our brand, fits our products.
I'm gonna take a sip of water. I
know this question makes you uncomfortable, but that's exactly why I want you to just answer very, very briefly, which is how long did it take you slash us to develop this?
Design system, five hours.
I think that's very important to know. And, it may not be as comprehensive and battle tested as something you would do for weeks or months, but I think this also speaks about the future of what these tools can do and what, you know, they will do those in the future.
Anyway, continue. Yeah. Another video definitely on on how to do that.
But Yeah. Actually, if you want us to do a video on the how because now we're just going into the what and what their what their benefits are and how this actually looks like. If you want the how, let us know in the comments so we can also do that one.
Yeah.
Okay. Let's get into it.
So one of those key stages, like we already said, was creating these markdown files because these are the things Claude is going to be able to read effectively and design using this design system.
People will recognize is we have a tokens dot m d. So this is like our canonical reference of all of our components.
So any part in the design system, these will be get referenced as the, like, source of truth. So we have tokens.md and tokens.css.
If you don't know about tokens, and I'm sure the majority of you are, go go go and look that up. Um, and, actually, worth kind of if you need a bit of a primer on design systems, there's far better people than me, uh, to explain why these are structured these are structured in this way and why we have designed tokens.
But very, very powerful and something that we have in here, which, again, gives us some certainty around what Claude is gonna use when it's creating any elements. It's going to be using, uh, tokens.nd as one of our sources of truth here.
So that is to say we've got an awful lot of information here, um, that Claude can make use of. Right?
Lots and lots of markdown files, stuff about accessibility, um, stuff about governance, icons, motion, patterns. It might even be thousands of lines thousands of lines that we would not put into a Claude dot m d file.
So, Alan, I'm gonna pass over to you just to explain again, you may have already covered this, what a Claude Markdown file is and, yeah, how big it should be and maybe why something like this is useful.
Yeah. Can I actually go back to Miro? I just can actually and just follow my cursor there.
There we go. So you might remember this section of the course where I said that Cloud MD actually functions as the hub, and that it should be ideally very short because it's loaded every time we start a conversation within that project.
So that's exactly what we have done here. So we have kept the Cloud MD very, very narrow and sharp.
And all the things that actually we or the AI might need, it just knows where to find them when it needs them, which means that we have we are way more token efficient and that we're also avoiding context fraud as much as possible, so we're getting better performance from the AI, which is also, I think, one thing maybe to mention is that CloudMD functions differently from SkillMD because I've seen a lot of people actually using SkillMD for their design system.
And the difference between Cloud MD and Skill MD is that Cloud MD is just read every time you start a new chat within that project, and Skill MD needs to be invoked. So it means that if you haven't properly invoked the skill, then it's actually not following your design system.
And by having these things in Cloud MD, then actually you know that it's going to do these things. There still might be some drift, but still, I mean, this is just a much better way to actually ensure and enforce that, you know, that AI is actually using and following the conventions.
Nice. And a a far more reliable way of getting it to follow these conventions than using a skill. Right?
Yeah. And or or putting all of that into one file. Yeah.
Because the longer that one MD gets, just the lower the compliance of AI is with it. Usually, it remembers the best the things in the very beginning of the MD file at the very bottom.
So that's why keeping it narrow just makes a lot of sense.
Yeah. So what we have got in this ClaudaMD for the design system.
So instead of, like Alan said, putting all of the context within here or giving it a file with everything in here, we tell it exactly what to do when it's coming up with anything new or it's reviewing something is to read these files that I've already shown you, all of the context from the design system or the markdown files in an order so that it gets that context, um, and give it some rules of how to implement.
So use existing components, Use tokens, not hard code to values. I appreciate that for the Us designers, this is basics, but they can't be taken for granted.
We've all all seen hallucinogenic stuff that comes out of AI. This is trying again to reduce that that chance of that happening. Don't invent tokens.
Okay? So we've given it. This is like the procedural bit that we give it each time.
Now this is to more token efficient, but this is still quite token intensive. I know that sounds like talking out of both sides of my mouth there.
If you are invoking this to create something new for you, it still has a fair bit of work to do. So when you are vibe coding something, it might take a little while to give you an output that is far more token efficient than vibe coding something very quickly and then spending a whole bunch of tokens to try and, um, kind of form it back into shape.
And what you are probably kind of retrospectively shaping it into is structurally almost certainly not going to follow your patterns terribly well, not going to be structured the way your HTML, CSS, JavaScript, all of that stuff should be. So rather than spending tokens, shaping something after the fact, we're using tokens at the start to try and make the first output much more reliable.
Okay. So we've had a quick tour of the anatomy of a design system. Your design system may vary in how you've set it up.
This is ours. We've gone through some of the elements in there that are needed to make it AI friendly. So mostly markdown files, which we've taken you through.
We've shown you the most important file, which is claud dot m d. That's acting as a kind of router in this project. It's giving it that governance of what it needs to run through in order to execute on our design system intelligently.
What we're do now is actually show you the practical stuff. So there's a couple of scenarios that we might wanna use this design system when we're vibe coding. First one is you've vibe coded something already, and now you wanna try and make it fit your design system.
Could be something you've worked on yourself in Claude, in Lovable, in Figma Make, whatever you've used as long as you can access the code behind it. The other scenario is you wanna vibe code something new.
You wanna work on a prototype or a proof of concept. Could be you, could be a colleague, could be a product manager. And full disclosure, that's the better way to start, and that is our recommendation if you end up putting into place this kind of design system with these components that are sort of Claude code friendly, and I explain why now.
So let's imagine you've been vibe coding or your colleague, Alan, might have been vibe coding an idea for a game to play with students.
And I think most of us out there, this lands on our desk, this screams vibe coded. It has all the hallmarks, all the kind of gradients, the use of interphone, lots of stuff that feels kind of very, very lovable esque.
That's fine. This might be absolutely appropriate to test something out just to get a concept moving to get the kind of creative juices flowing.
No problem with that. But we might wanna understand, okay.
Is this viable to be built using our branding? Or if we wanna it or present it to senior stakeholders, we might want it to look less vibe coded.
So no real problem with this. I think, you know, this has its place, but it screams it screams vibe coded for better or worse.
So what we can do and what you can see here is we might decide, okay. We're gonna ask Claude to retrospectively apply our design system to the files that we've been sent.
So in Claude in this version here, we can see I said to it, fix this five coded prototypes, use our design system, pointed it to where the file was. And what's come back already looks better.
Right? It looks more like of the MBA. Let's have a little reminder of our website.
It's using the right colors. Typography looks more on definitely using the right button styles and stuff.
Already, you can kinda see it's doing that thing of basically painting by numbers. So it's taken the existing structure that came out of the box from whatever we vibe coded, and it is attempting to make it look and feel right.
And then we start to see issues here. We can see where it's tried to patch up the existing code, the existing mechanics of the of the game.
We can already see a few errors that have crept in here. I can see a few things in here that are suboptimal. So it's almost like it's been applied, but it's been done quite roughly.
Again, this might be absolutely fine for your use case, some very, like, early testing or something like that, but we can do better.
And the problem here is we're trying to patch something that's already been created with that design system. So you can do that, and you can ask Claude to do that, but there is a much better way, and that is starting from scratch vibe coding using the same tool using Claude, but giving it the constraints of our design system to do that ideation.
So what we can ask Claude to do, we look at my other terminal node. What we have, we have where is it?
Skill.m d. Alan, can you tell us a little bit more about this actually?
So this is one of the the instructions about what we wanna vibe code.
Right?
No. In this Skill MD, it's basically a recap of one of the modules of the dMVA. So whenever we do wanna make projects on that particular module, this is how we bring in the context of the actual content that students go through.
So what I'm guessing you have done is you have probably pointed Claude to this particular mod document, so it knew what we mean when we say business strategy.
Because if we just told it to build a strategy game, it would just build whatever it thinks strategy is. But obviously, in the container of our program, it has specific definitions, specific examples, and so on. So that was that's a a skill that we use whenever we need to bring in that context.
This additional context is something I've told Claude about before it starts vibe coding. So I've said to you, I want you to come up with a new concept for a new game teaching designers Actually, Tom, can you just highlight this text, I think, just for us to be able to yeah. Exactly.
Yeah. I don't know if such highlight's showing up, but yeah. I you to come up with I'm doing this in natural language, so come up with a new game teaching designers about business strategy.
We've created a skill, and I've told you where that skill lies, which gives you all the context of how we teach. Like Alan said, that's we want it to have our opinion, our way of teaching strategy.
I'd like it to be based off of Yeah. The the skill.
Right? Oh, yes. Based off of the skill.
Sorry. And to use our design system, and I've told it where I want it to create it once it's finished. So it puts it into that folder and uses skill.md for all the context that I mentioned.
So when this starts, we already mentioned, it will look at Claude m d first. So it will pass through this file, read it all in order, and get that context about the design system before it starts vibe coding rather than trying to do this retrospectively.
So it goes into the process of vibe coding our idea with all the context of how we build, what our design system looks like, how it works, and how to make decisions from it.
So takes a little while to go through that. I think it took about five minutes to create this first version, but I'm gonna show you what that looks like.
So this is obviously the one where it was retrospectively applying the branding. And then we have version one, which is it's calling trade off.
Trade offs are central to business strategy. Not gonna go into a lesson about business strategy. This is what it's created, and this is starting to feel a bit more us.
It's giving as far as, like, the kind of fundamentals when we're teaching, we like to give a little bit of context first, a bit of instruction, and rather than just giving this kind of here.
Also, way that we when I was setting up the design system for games, we talked about stuff having containers, having progress, the kind of language we use, giving people context about the business case that they're gonna be designing around.
So we can already see here that the way that these buttons and things and the way things are laid out is a bit more us. One of the key principles is kind of one key decision per page, whereas the previous version has lots and lots of decisions to be made here.
This is the one that we branded up that came straight out of an initial vibe code without our design system. There's a lot of, much as I hate the term, cognitive load here for the user. That's not us.
That's not how we teach. So we are asking people to make one decision at a time. So you see already that the look and feel is there, but also it's paid attention to our patterns, our rules, and how we govern our design system.
So this already feels like a superior product and something actually that's I think is a tear up from something looks vibe coded. We can go through and sort of choose our places within the arena and tune our activities.
And this is all already feeling more more us. So you can see this. I know the design system that we've created for the tools.
So I know by looking at this initially that this is much more in line with how we would build something if it was ready for production, production, and it's already brought all that sensibility early into the process. K. So that's kind of one version of this.
Now if we gave, say, two designers in our team the same brief, if we gave them all the context about how we teach business strategy and we give them our design system, they're not gonna come up with the same design.
Two designers are not gonna come up with something identical. That actually isn't what we expect Claude to do either, but we do expect our designers and we do expect Claude, any design it comes up with, to be within those constraints that we've built into the into the design system, into our MD files.
So I actually got Claude to do this again because I wanted to see what the variations looked like. So so that it didn't have a a reference point in the existing design, I actually moved this file outside of the project and asked it to do a version two.
This would be like our other designer going off and doing something. It came out with this. Now you might recognize, actually, it's done a pretty good job consistency wise of how we would kick off a game.
It's chasing the right kind of typography scales, the way it's putting things within a a big card, the way it's got progress, pretty similar.
So, you know, I get a bit of confidence here that there is a consistency starting to happen by using this design system. The thing that's different is Howie has taken that brief and decided to design a game.
So draw the line is this one. So I imagine this is gonna be something about strategy canvas.
So new coffee train. And, again, we can see there's definitely a similarity here in button styles and choices it's made.
It's done the right thing. It's put one question per page. It's got the right hover effects.
This is all feeling like the same design system. Right? We go into the next stage.
Let's draw our lines. So now now now we can start doing a nice strategy canvas. This feels like an upgrade from the last game that we built, actually.
Alan, we might wanna try this. So we can see here that just like in the non AI world, two designers with the same design system can come up with interesting concepts, and that's what's what that's what we wanna vibe code.
That's why we vibe code. Right? We are diverging, but we're diverging very quickly.
But in this instance, we're diverging with those constraints of the design system. I would feel comfortable taking this into an executive or to Alan or actually to our students pretty soon versus something that's just been VIBE coded without those constraints.
Does that make sense? I actually gotta do the third version, Alan, because it was on such a roll. But we'll come on to that.
Yeah. No. I'm gonna show the third version now, which I quite like.
So, again, it's got the right kind of starting point, very similar. It uses this kind of quite fun cards thing. But what I like here, what's different here, is it's used a different version of our progress bar from the design system.
So whereas previously, using this one, which we've used in other games, we actually have two versions of this. This And is the one that gives a bit more context.
And, actually, if I was reviewing the designs that had come to me from a designer, I prefer this one.
What do you think, Alan?
I would have to think about it more.
But we're now getting into the into the bit that I think is particularly interesting when you are implementing a design system like this. So I'm pretty happy with the kind of quality that's coming out generally through these different versions.
But from reviewing the two well, actually, different games now that we've had, there are a few things that if I was reviewing these and updating the design system, there are choices that I would want it to make moving forward.
There are choices that I would say to a designer, Actually, you know what? When we're designing a game, I think the contextual progress bar that kind of tells you what stage you're at, tells you what part of the game you're playing is more useful than something a bit too abstract.
So it looks nice, but it's not as useful when you're learning as something like this. I've not given that enormous amount of thought, but I wanna get now make that codified. The other thing that I've just noticed, the subtle difference here, is the start the brief button here.
I kind of like the fact that it's got the little arrow version on there because it feels like I'm about to go through this process, whereas this feels like a sort of terminal in the process, like a stop point. So it's a little thing, but it's something that I would like the design system to remember in future.
I would like to make it part of our governance. So we have a file for that. So we have something called decisions markdown.
And, basically, this is what how we are training the design system, training Claude to get better as it continues to vibe code and play our design system at making decisions about the right thing to use in the right context. Now this is the kind of stuff that designers do codify. We do put it into our documentation.
We talk about it in critique. We are a small team trying to run this ourselves. We don't have design groups of designers critiquing these things, so we wanna do this at speed, and we wanna make it reliable in that when Claude kicks off this process and looks through decisions.md, it understands our preference for certain things.
So within here, each decision has a few bits of criteria.
So it's like a rule, when to use it, examples, counterexamples like what a bad bad version of this would look like so they can review itself, and then why it was added.
So we've got a number of existing rules in here around that. Things around feedback and state like when to use a toast versus a modal, how to use loading states.
But what I've added in down the bottom here Where is it?
Here we go. So I actually reviewed those two designs and added a new decision rule, which is step up versus progress bar.
So I've told it when to use this version of the progress bar versus this version and also my preference for using this version of the button with the arrow versus the one without it.
So I've now added those into decisions dot n d off the back of reviewing those Vibe coded games. So we've got the button hierarchy on the game screen, the forward arrow, when to use that, and the progress indicators for the steps.
So that now will be something that Claude runs through whenever it Vibe codes something new. So in order to test that, I actually did a next another version. So I asked it to do another version of the game.
It understands what we wanna get from the game, what the mechanics are, how we teach. But now you can see in this version, the arrow is in the button, and we are working with a version of the progress bar which has the context that I asked for.
And I would expect now every time I vibe in a new version, it's gonna follow that rule. I'll stop there. I hope that makes sense.
It does make sense. Yeah. Cool.
Nice.
So yeah. That's kind of so to kind of recap, I think applying a design system to something existing kind of vibe coded piece is not the way to go.
You can do it, and you saw the results. They were kind of you know, it looked like someone had painted on the the NBA look and feel on here, but it was definitely suboptimal.
It wasn't following our rules strictly versus vibe coding from the start using the design system. We got what I would say was some pretty solid results out of that.
They passed the eye test and also give me variations where I can start to see preferences from my perspective that I would like to build into the system longer term.
Any questions, Alan?
No, all clear. Thanks Tom. No worries.
Anything else to cover here?
Mean, obviously, like anything, when you're deciding whether whether saint qualifies as a rule to write down, it's not you you don't necessarily make a rule at everything.
So yeah. Like, could you defend the choice with a principle or scenario?
If not, then if it's just I prefer it and you can't point to any why any choice is better in a similar situation, it's not really a rule. Your your taste is kind of forming.
So these are all the kind of rules around well, rules, guidance around design systems that regardless of whether you're building them and managing them and implementing them with AI or not, you know, use your sensibilities as a designer to know when to make something a rule versus not.
Anything else to add though? No. I don't think so.
No. I think I think where the senior designer fits into all this is the kind of quality bar for what you can get out of vibe coding has got higher, not lower.
But someone still has to look at the ideas that have come out the back of this process and decide which is the better way to teach, what is the more I'm just gonna end up waffling.
So I think we'll leave that there.
No. Well, I I think that's exactly what the role of a designer when the a like, building an AI design native system is, is seeing how AI system, like, understands what we have written in MD files and the components and just make sure that the way it's applying this is actually on brand.
So that's a big part of this job is just translating now this, not that it's human readable, also that it's like machine readable that you're getting the results that you wanna be getting.
Yeah. And I think there's a whole lot of philosophical questions here around like how where does the role of a junior designer fit into this?
If you are just being handed this off and you're not getting to play with the design system and use it yourself so much, Like yeah. But I think that could end up being a whole different discussion.
But
Yep. Let's stop there. This goes then into, I think, other topics as well.
So this is just, I think, a nice way to show how AI yeah.
How design systems can be AI native. Thanks, Tom, for showing us this, and I see you in the next section. Thanks.
Bye. Okay. Time to automate some of the boring tasks.
So what we will do here is a task a weekly task that maybe a lot of you have to do if your team leads, design leads, which is let's call it, like, team reporting.
Let's say that you need to stay updated about what each team member does, and you would like to each week basically know what the status of the project is.
And there's some kind of a Google Sheet that you have where you're tracking that. So let's just build this quickly together.
So this is the name of the person. We'll talk about this later. Maybe project name and status.
Actually, if this is weekly, right, we would probably wanna have status per week.
So maybe this is status let's see.
Status week one, status week two, and so on.
And what we would want our team members to do, let's say, Mercy, and May, is to basically if we are in week one of the project, we would want them to fill this out.
And if they were in week two of the project, to fill this out. And we give them a few options. Where is this done?
Drop down? Yeah. I think it's drop down.
Done in progress. Let's say 50% or less, and then maybe in progress 50% or more.
I'm just making stuff up here. Obviously, this is all the stuff you can adjust and make better.
I don't know. Just choosing some colors here like this. Yeah.
So we have these different versions of what they can choose here.
And what we want basically is that if they didn't do it by Friday, let's say 4PM, that they get reminded.
And up until now, we had to chase them and do this ourselves. And just imagine there is not just three, but there is maybe like 12 people on this list. You know, you do spend quite some time doing these kind of things.
And, yeah, probably this is not exactly what you're doing, but you might have some kind of tasks that in some shape or form will relate to what we're building here, which is automations to free up some time we can really spend more time on what really matters, which is the actual work.
Okay. So let's build this team reporting, and I'll open up an anti gravity instance and basically tell it to, hey.
Can you help me build automation that would every week on Friday at 4PM Central European time, ping any of the team members that haven't filled out the status report, which we have in a Google Sheet? So just ping them through Slack.
I'm giving you that really, really simple prompt here because I don't know how we should build this. So I wanted to figure it out.
I wanted to ask me questions. So that's why I'm using the plan mode, and I'm guessing it's gonna come up with some clarifying questions for how to build this because I'm not sure completely either.
Okay. So we have a few questions from Claude.
First one is, what is the sheet structure? How is the status report tracked in Google Sheet? What indicates whether someone has filled it out or not?
So do we have a column per week? Do we have a stamp timestamp column, or do we have checkbox column?
Each row is a person with a checkbox or a status value per week. Each row. So row is just to clarify because I know a lot of designers don't like sheets.
Row is this, and this is column. So checkbox column.
Each row is a person with a checkbox of status value per week. No. Column per week.
Each column is a week. Each row is a person. Yes.
So that's the one we have. Right? So we have person per row, and then this is a week.
How do we want to remind these people? Let's say DM. Right?
We could do this. We could also do something else. We could send an email, whatever really we can choose here.
Scheduling, very important. So how should this automation be scheduled to run? Is it through ClotCodes built in scheduled triggers, or would we use a server or Mac local CRM job?
Well, definitely ClotCodes built in scheduled triggers, which by the way, clot code schedule tasks is a feature that it was used, I don't know, a few weeks back where you can run prompt on a schedule.
You can do command loop or you can do command command schedule, and that's what we're gonna use.
So if you wanna dive deeper, that's what you can look into. But, yeah, I'm gonna choose the first one. Submit answers.
So now it came back with few more questions. How are team members identified in the Google Sheet? Is there a column with their Slack username or email or just their name?
Well, right now, it's just a name. But because I have built the similar things before, I am expecting that this column b will have to put in the Slack ID, which is the unique identifier of each team member, which, by the way, the way you can get it is if you go on Slack, if you just do the right click over the person, then you can do copy copy name, not not not.
Actually, you will have to then click into this person and then go here and then where is it?
Steps about view profile. Okay.
Here. It should be here. Copy member ID.
Copy member ID, and we will do the same for the other two. So for Mercy and for Yerne.
And then I mean, right now, it's enough if we have just one so we can test things out. Project name, testing project.
Doesn't really matter. Okay. Basically, now we have the sheet ready for testing.
So if we go back, now we can answer. It's Slack username column. Well, there is actually Slack ID column b column.
Right? B is here. So I click enter.
Slack authentication for Slack. Should I set up dedicated Slack bot or use an existing Slack integration you already have?
Use existing Slack app. I don't think I have one. Use Slack MCP tools.
Create a new Slack bot.
Most reliable or use Slack MCP. Actually, let's try Slack bot if it's recommended.
Well, here is the plan.
File structure makes sense. So dot ENV file.
Yes. I'll explain what it is. Tokens, temporary scripts.
Okay. Makes sense. And I will need to create a one time I will need to create the bot.
So I'll just go ahead. And then I guess, Claudia also give me instructions for what I have to do versus what it will take care of. So I'll definitely have to so here's like an ISO overview of what usually happens when you're in the build phase, which is that you will basically see like a whole plan.
So right now, it's in the step one. That's what this star is for. Create a skill directory structure.
Copy copy and patch to Google auth. So I already have Google connected to my cloud code, but I will ask you to explain how you would do it.
If we wouldn't have that. Then it's gonna create a check status Python script. This is gonna be a script that's gonna check if people have already, like, basically added their status here or not.
Hey. Google Auth.
It then is going to write the Skill MD. The it's gonna write the ENV file, install the Python dependencies, and set up the remote trigger schedule.
Okay. What do you need from me? What do you need from me?
By the way, the ENV file is very, very important. So let me just spend a second on that.
So basically, when you're building some kind of a potential prototype or whenever you are connecting your prototype to some kind of API service, you will need to add your API keys.
Well, somehow, you the code will need to communicate to your API keys. An API key is basically a password, and if somebody gets it, then they can use that service.
So for example, if you would have my API key for my cloth code, you would be able to use my usage tokens. This means that, yeah, you're basically wasting or using my money.
So that's why we're trying to or you're getting some kind of data that you shouldn't be getting. So that's why the best practice is to store all the API keys in a call file called dot d n v, and I'll show you how this is done.
But whenever you see this, it means that you need basically need to store some kind of information, sensitive information for your script to work. There we go.
For some reason today, the bypass permissions is not working because all of these questions I'm getting about, hey, do you want can I do this? Can I do that? Should be just automatically done.
Yeah. All of these things should not be happening.
But it is what it is. So it's doing the job.
We have talked about the ENV. So, actually, I do know that I will need to set up a bot. Right?
So, actually, let's start doing that. Where was that section about the bot? There was something about a bot somewhere.
Maybe it was in the plan. Let's see.
Requirements, status.
Think it was somewhere here.
Okay. It's here. Step four, one time Slack bot setup.
So I will need this link. I'll need to go here.
Create an app. Let's see what it says. So create a new app.
Okay. Boom. From scratch, I guess.
Yes. From scratch. App name.
Weekly status. Select the workspace.
The team. Create app. And then what does it need from me?
OAuth and permissions both, tokens, scopes, add chat. Okay.
App ID, client ID, display information. So scope.
Let's see. Where is the scope? Generate token and scopes.
Right? Is it here? Token name.
Add scope token name.
Actually, don't know what this means. Weekly. Let's see.
Weekly. What is that? Weekly status.
Right? Let's see. Add scope.
Okay. So for scope, I'm gonna copy this over. Chat.
Right? Let's see. No items.
Okay. So I got stuck here. So what I will do is basically okay.
So now we have the message that code is built, and now we are the ones that are the bottleneck. That's usually the case. So I will now tell Cloud Code I'm having issues.
Hey. I'm just trying to create this Slack bot, and I got stuck here.
You can see the screenshot. Am I in the right page? And I'm now in the step two, trying to get the bot token, I guess.
I'm in step two, so just help me out.
As I said in the beginning, I'm not I'm not an engineer, but I've just been playing with this enough to be able to know what I need to ask, and that's it.
But still, all the times, I don't know exactly the terminology either. So click add an OAuth scope.
Scroll okay. In the left side of word, click okay. So I'm not on the right page.
Click on the auth and permissions. That's here.
And now we need to click bot token scopes. I guess that's here.
Add an o at. Yes. Add an o at.
And now chat. Right. Okay.
That is added. Scroll back up and click install to workspace and authorize.
Scroll back up. I am back up, but I don't see this. Install to workspace.
Install to. I guess that's it.
Allow.
Let's see. Copy the bot token at the top. Starts with.
Okay. Copy.
The upload token section you were in under okay. So we have gotten to step five.
Okay. Step five done. Where do I add the token?
Yes. Okay. So I need to do it here.
Slackable token. So one all other thing I recommend you to not do is to drop your API keys or stuff like that into the chat.
Long story short, don't do it. Just try to always write directly into the ENV file. Okay.
So we have done this. Now we need to also give you the spreadsheet ID. So the spreadsheet ID is, I believe, this part.
Actually, let's just ask it. What part of this URL is spreadsheet ID?
Oh, it actually told me even before. Anyway, now I got it. Boom.
Boom. Spreadsheet ID is not as sensitive at all.
So that's why I can drop it into the chat as opposed to Slack both bot token.
Okay. Command s. Is that all?
Let's see if that's enough.
Not quite. Still need to do Google OAuth so the script can access the sheet. Run this.
It will open a browser window asking you to sign. No. You run it.
So a lot of times you'll get cloud code telling you what to do, and a lot of times you can just tell it to do it exactly this for you. So what will happen now is we should see a Google page open up on our screen, and we should be able to grant access.
There's a bash command here. I still don't see anything opening.
Yes.
Okay. There we go. So now I need to basically give my blessing.
The authentication flow has completed. You may close this window. Okay.
So let's go back to anti gravity. Now it should already have information that this is done.
Actually, now we can see how annoying it is if the bypass permission is not working. Basically, it's just asking all the time to approve everything.
Yeah. For some reason, it's just not working today.
Okay. The sheet name in in v is set to is set to spreadsheet title, but it should be the tab name.
Yes. Okay. So that okay.
It corrected itself. That's good. So now everything is in the in the v ENV makes sense.
The sheet is connecting fine, but the header uses yeah. Exactly. I was waiting for this.
So the issue we have right now is that this is not really self explanatory. Like, what is status w one, status w two?
What we do better is that we had dates. The script was expecting date based headers to find current week. Simplest fix, always use rightmost column as the current week, the way you just add new column each week, and it's automatically picked up.
Let me update the logic. That's one way to solve it. The other way would be, no.
Please just create in the spreadsheet column for each week in the q two, so second quarter of twenty twenty six.
Do this from column d onward.
Okay? So this is from here onward. It's gonna create, I guess, twelve twelve weeks.
And if it does this correctly, then it not going to need to rely on the rightmost column because then it's, again, on us to be creating that column each week, and we don't want this.
Okay. So now the dry run has worked.
So basically, Cloud has created these columns, and it basically identified that Tom needs to be basically reached out to.
It hadn't actually performed this action because it was just a dry run. But then it also identified a problem, which is that we can not use Entropic's cloud because it doesn't have access to the local Mac, so it can't run the Python script or read the local credentials or add token.
So the right approach here is local Mac cron jobs. So remember in the beginning when we were planning this out, one of the options was to actually do this through the local job.
What this means is that our computer just needs to be on in order for this to work. So it's not as convenient. But still, if our computer was on on Friday at fourteen UTC or anytime after that, it was just it would run this schedule.
Two things to do before next Friday, add Slack IDs for Messi and Hernay. Yes. We haven't done this.
Can we now run, uh, can we run this for Tom? Just sent him a message reminder to fill out the status in here.
And then we just give him the link, and let's see if this works.
Now it's oh, it's already actually, it already had a reminder message.
And now I give it a new one, so it's gonna update this and send live Slack DM to Tom. DM sent to Tom.
He should have it in Slack now. I guess I won't be able to see this because it was sent through bot.
Okay. So that's the downside of this approach. If we went with a different approach with the Slack MCP, it will be able to send messages as us, which would maybe be better in this case.
So actually, let's try and do this. Actually, can we not use bot, but rather MCP Slack so that the message is sent as me, Alan.
Also, now you can see that we're getting very, very close to having full context window.
So I would typically open up a new chat and just or instance of agent and just continue there, especially now because we're changing the whole approach to it because we just built everything with Slack bot, and now we're changing it to an MCP approach.
What we're basically doing is instead of using and right right now, we do wanna use an MCP, and before that, we basically went through APIs and tried to build a bot.
And that obviously will not look like the message came from us, but it came through a bot. Now we actually wanna use MCP so that it actually looks like it came through us.
So it's gonna now it has to redo a lot of the code.
We no longer need the Slack bot token, so it's gonna take this out.
Yeah. Now let's test it.
I already have the MCP for Slack connected. That's why this is gonna be pretty fast. And let's see if the message is delivered.
Yes. So Tom has gotten the message, and there's also a message sent using Cloth.
Yeah. There we go. Sent.
So this is how this works. So you can see that I just started with a very broad idea of what I actually want to build. I was exploring the technological architecture of how we can do this.
There were various options. Obviously, we had to kind of glue together a spreadsheet with Slack, and we wanted it to come through us, and then we found a way.
We found a way. So now, basically, every Friday, this would be at 4PM. If our computer was on, it would be red.
If we wanted to have a system where this wouldn't be connected to our own computer, we could use we could just ask Cloud, hey. I actually let's say, hey.
Actually, if we my computer let's say, I don't work on Fridays usually. Is there another architectural way we could solve this maybe with a server or what do you suggest?
Don't do anything, just give me options. So again, like I'm just now basically conductor trying to understand what are my options here.
And yeah, Cloud Code is a great teacher as well, and it's gonna give you different options for how you can solve this.
And then if I spend more time on this, I would be able to use it. So number three, reframe it as a remote trigger, which is also its recommendation.
Since the Slack MCP is connected to your Cloud AI, remote trigger can slide send Slack messages. Oh, since we actually move away from the API architecture, so the Slack bot architecture to the MCPs.
Now we could use the cloud built in cloud structure infrastructure, which is the most convenient way we could have solved this.
Well, think we can stop here. So my point, my goal with this section was to just show you how you can build automations, things that would help you as a team lead.
I mean, obviously, this is like a very team lead specific example, but I just hope it gives you some idea for what kind of things you can build so you can transfer them to your own use cases.
And with this, we are also closing the build section of this video, and I'll just have a short outro for you in the next section.
Alright. That's the course. So I hope you got a lot out of this because I genuinely enjoyed making it.
But the thing is that this field moves ridiculously fast. Even during this week when I was recording this video, new stuff dropped.
For example, Klot or Entropic announced a new model called Mythos, It's supposed to be way better even than Opus. There's also a new plan mode called Ultra Plan.
So, yeah, there's new features I couldn't even include in this video. So and that made me wonder, like, what is the future of this space and how can we really keep up?
Because this video will get old in a few months probably. I mean, the principles will stay the same, but there's just a lot of features and new ways that you could do things that will be new.
That's why I'm playing with an idea. It's something I call a agentic design community.
I even bought a domain already. It's a place where we would regularly do trainings, where we would break down new tools as they drop, but not just cloth code.
Also like Figma Make, UX Pilot, Google Stitch, or even new agentic tools. So it will be sort of like an ongoing education for design community. Frankly, I don't know if I will build it yet.
Depends whether of well, if enough of you actually want it. So if this does sound interesting to you, like, click the first link in the description and, yeah, join the wait list.
And that's frankly it. Thanks for watching, and see you in the next one.
The Hook
The bait, then the rug-pull.
Faljic opens with a thesis disguised as a welcome: design is splitting into a world of executioners and a world of orchestrators, and the four hours you're about to spend are the on-ramp to the second one. No engineering background required; he doesn't have one either.
Named ideas worth stealing.
21:54model
Three buckets of design tools
- Legacy design tools (Figma, Adobe) — pixel-to-pixel craft
- Agentic design tools (Google Stitch, Figma Make, UX Pilot) — text-to-pixel, faster pixel work
- General agentic tools (Claude Code, Cursor) — text-to-anything, the real scope expansion
Maps where every tool sits and what it actually replaces. The point: general agentic isn't competing with Figma — it expands what a designer can ship.
Steal forMod Boss pricing/positioning — same three-bucket logic works for transcription tools (Wispr/Glaido = legacy, Mod Boss = the orchestration layer).
1:49:22model
3-Layer Architecture
- Instructions (CLAUDE.md / brand / taste / rules)
- Orchestration (skills — .skill.md recipes)
- Execution (the actual file edits)
The reliability unlock. Two-layer setups (instructions + execution only) get unreliable as complexity grows. The orchestration layer is what makes agentic workflows production-grade.
Steal forEvery Joe agent. JoeFlow Sessions = orchestration layer. SOUL.md = instructions layer. The actual edits = execution. This maps 1:1 to how Paperclip should be structured.
03:20concept
Executioner -> Orchestrator
The career-shift framing for designers. Same shift Joe is teaching for solo creators — stop renting tools, stop executing every step yourself, become the conductor.
Steal forKilling Excuses script angle: 'You're still doing the work. The people winning are directing the work.'
2:42:40list
Eight discovery skills you can build
- Review Miner (G2 / Amazon scraper)
- Tone Scraper (competitor voice analysis)
- Heuristic Audit (Nielsen 10)
- Color Thief
- Business Model Mapper
- Strategy Mapper
- Jobs-to-be-Done Mapper
- Survey-to-Persona
Ready-made shopping list of skills any team can build in an afternoon. Each takes 10-15 min once you have one working skill to copy from.
Steal forJoeFlow batch templates — ship a 'starter skills pack' as part of the product. Each one is a tangible time-saver Joe can demo.
3:53:20concept
Fresh-instance code review
After Claude Code builds something, open a NEW chat to review it. The original instance has confirmation bias; the fresh one doesn't. Bonus: hand the same code to a different model (Codex) for a third pair of eyes.
Steal forSessions panel feature — auto-spawn a 'reviewer' session whenever a 'builder' session marks itself done. Different model, fresh context.
How they asked for the click.
VERBAL ASK
4:29:00newsletter
“I'm playing with an idea I call an agentic design community. I even bought a domain already. It's a place where we would regularly do trainings, where we would break down new tools as they drop. I don't know if I will build it yet — depends whether enough of you actually want it. If this sounds interesting, click the first link in the description and join the wait list.”
Soft, honest, last-90-seconds. No newsletter pitch, no sponsor through the body of the video. The transparency ('I might not even build it') is the strongest CTA mechanic — it makes signing up feel like a vote, not a transaction.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
Visual structure at a glance.
