# Chapter 02 Draft: A Side Project Is The Fastest Way To Learn AI Design Status: Draft foundation chapter Template target: `article-template.html` first, with an editorial opening. Primary source brief: `docs/INDUSTRY-OVERVIEW.md` Writing skills: - `docs/skills/marco-writing-voice/SKILL.md` - `docs/skills/article-to-marco-voice/SKILL.md` Derivative plan: - site article - email lesson 1 for the free course - LinkedIn post - 3-5 short social snippets - future course exercise - Harness artifact: first workflow map ## Working Title A Side Project Is The Fastest Way To Learn AI Design ## Other Title Options - A Side Project Is The Fastest Way To Learn AI Design - Planark Is My AI Design Proof Environment - A Real Product Teaches AI Design Faster Than Tool Theory - Why Design Needs A New Operating System - What Planark Taught Me About AI Design Work - Building Planark Changed How I Use AI - Design After The Prompt - The Designer's New Loop - Taste, Tools, And The Work - From Prompts To Operating Systems - The New Design Operating System ## Reader Promise Understand why building a real side project with AI changed how I think about design work, and why designers need taste, context, orchestration, validation, and reusable project memory before they need more prompts. ## Opening Thesis Planark taught me that the important change is not that designers can generate more screens. The important change is that design work now needs a stronger operating system. AI can create interface options, rewrite copy, produce HTML, inspect code, summarize research, and suggest implementation paths. That makes output cheaper. But cheaper output does not make the work clearer. It usually makes the judgment problem bigger. The designer still has to decide: - what should exist - what good means - what context the agent needs - what source material is trustworthy - what should be implemented - what should be rejected - what should be saved so the next pass is better This is where Agentic Design Ops begins. ## Article Direction Start from Planark, not from the abstract industry shift. The order should be: 1. What I learned building Planark 2. Why prompts were not enough 3. What the industry shift made clearer 4. Why taste, craft, code, and proof matter more 5. The new design operating system 6. Why this leads to the Design Harness The external articles should support the argument after the lived problem is clear. They should not be the opening structure. ## Inspiration Notes These references are not article material to copy. They are starting points. Each idea must become Marco's interpretation, then a Planark/workflow example, then a reusable Harness lesson. ### Taste Is Not A Token Inspired by: [Design Is How It Tastes](https://superposition.jem.computer/design-is-how-it-tastes/) What the source helps frame: - Design language cannot be reduced only to tokens, components, and implementation instructions. - Taste includes mood, pacing, atmosphere, audience, and the felt quality of the experience. - AI makes it easier to produce structured design output, so taste has to be made explicit enough for agents to work with it. Marco take: For me, this is why `DESIGN.md` matters. A design system can tell an agent what radius, font, and color to use. But it also needs to explain what the product should feel like, what kind of page it is, what to avoid, and where the work should be restrained or expressive. Harness lesson: The Harness needs a design memory file, not only tokens. ### Craft Becomes Shared Inspired by: [Product Quality: A Shared Commitment to Craft in the wake of AI](https://slack.design/articles/product-quality-a-shared-commitment-to-craft-in-the-wake-of-ai/) What the source helps frame: - Quality is not owned by design alone. - AI makes execution faster across roles, but shared craft still needs standards. - Teams need clearer agreements about what good means. Marco take: The more AI enters the workflow, the more important it is to define craft outside a single Figma file. If a product manager, designer, or engineer can ask an agent to change the product, the product needs shared context and review loops. Harness lesson: The Harness should include quality rules, review checklists, and source-trust gates. ### Designers Are Moving Closer To Code Inspired by: [9 designers open up about AI-assisted coding](https://rongoldin.substack.com/p/9-designers-open-up-about-ai-assisted) What the source helps frame: - Designers are using AI to prototype, inspect, and sometimes contribute code. - The useful question is not whether every designer should become an engineer. - The useful question is where code gives designers better judgment and better artifacts. Marco take: I do not want to present this as "designers must code now." That is the wrong pressure. The more useful idea is that designers can get closer to the material. HTML mockups, small prototypes, source inspection, and agent-assisted implementation all make design decisions more concrete. Harness lesson: The Harness should teach when to use HTML, when to inspect code, when to ask an agent for implementation, and when to stop. ### Build Something Real Inspired by: [A side project is the fastest way to upskill in the age of AI](https://www.philmorton.co/a-side-project-is-the-fastest-way-to-upskill-in-the-age-of-ai/) What the source helps frame: - Real projects force end-to-end learning. - AI skills become meaningful when they are attached to an actual product. - Building teaches the hidden parts: data, QA, publishing, product judgment, and tradeoffs. - Side projects are useful because there is nowhere to hide: the idea has to become a thing, the thing has to work, and the work has to be judged by reality. Marco take: Planark is not just an example app. It is the proof environment. It is where the workflow has to survive real source data, UI decisions, bugs, infrastructure, and publishing pressure. The reason Planark matters for this site is that it keeps the AI workflow honest. A generic demo can look impressive for five minutes. A real product exposes source trust, edge cases, localization, performance, onboarding, design-system drift, vague product thinking, and all the decisions a prompt cannot make for you. Harness lesson: Every workflow in the site should eventually point to a real artifact, not just a concept. Planark should become the recurring proof loop: ```text idea -> product context -> prototype -> implementation -> source trust -> QA -> launch pressure -> saved learning -> Harness rule ``` ## Proposed Chapter Structure ### 01. What Planark Taught Me Planark made the AI workflow real. It was not just "ask AI to design an app." The work had to survive product positioning, real data, messy UI decisions, debugging, source trust, writing, implementation, and publishing pressure. That is where the limits of prompt-first work became obvious. This is also why side projects matter in the age of AI. They make the full system visible. You do not only learn how to prompt. You learn where the prompt breaks, where the source data is weak, where the interface becomes vague, where the implementation pushes back, where QA catches the thing you missed, and where your own taste has to become more explicit. Planark is the place where those lessons became concrete. ### 02. Prompts Were Not Enough A prompt can produce an answer. It cannot carry the whole product context, design taste, source policy, QA habit, or memory of what already failed. That was the gap. ### 03. The Industry Shift That is useful, but it is not the whole story. The hard part is not producing more. The hard part is knowing what to ask for, what to trust, what to change, what to ignore, and what to keep. ### 04. Output Is Cheaper, Judgment Is More Valuable When output becomes cheap, the designer's value moves upstream and downstream. Upstream: - define the problem - shape the brief - choose source material - set quality standards Downstream: - critique the output - validate the sources - decide what ships - save the learning ### 05. Taste Becomes Working Context Taste cannot stay trapped in a designer's head. If agents are part of the workflow, taste has to become usable context: - what the product should feel like - what visual moves belong - what visual moves are banned - what level of density is right - what patterns should be reused - what counts as too generic This is the job of `DESIGN.md`. ### 06. Craft Moves Across Roles AI blurs execution boundaries. That does not remove craft. It makes craft more shared. The team needs better language for quality because more people can now produce changes that affect the experience. ### 07. Designers Get Closer To The Material A designer does not need to become a full engineer to benefit from code. But a designer who can create an HTML mockup, inspect a component, read a log, or understand the shape of an implementation has better leverage with AI agents. The point is not coding as identity. The point is better design judgment. ### 08. Real Projects Teach The Loop You do not learn this only by reading tool posts. You learn it when a real project pushes back: - the data is messy - the UI breaks - the copy is too vague - the model invents structure - the design drifts - the implementation exposes missing decisions That is why Planark matters in this site. ### 09. The New Loop The loop is: ```text taste -> brief -> context -> agent task -> generated options -> critique -> implementation -> validation -> saved learning ``` Each step needs a reusable artifact: | Step | Artifact | | --- | --- | | Taste | `DESIGN.md` | | Brief | task brief / product note | | Context | `AGENTS.md`, source docs, examples | | Agent task | skill or prompt | | Generated options | mockup, code diff, critique, draft | | Critique | review notes | | Implementation | HTML, app code, content, docs | | Validation | source-trust checklist, QA pass | | Saved learning | updated memory, pattern, or Harness file | ### 10. Why This Leads To The Harness The Harness is the folder version of this operating system. It is not a magic prompt pack. It is a way to carry the process across projects: - project memory - design memory - skills - prompt patterns - templates - source-trust rules - QA checklists - examples The rest of the foundation explains each piece. ## Draft V1 Building Planark changed how I use AI. At the beginning, it was tempting to think the value was speed. Generate the idea faster. Make the mockup faster. Rewrite the copy faster. Ask for a fix faster. Move from a rough direction to something that looked like a product. That part is real. But the deeper I got into the product, the more obvious it became that speed was not the hard part. The hard part was knowing what to trust. Planark is a travel product, so plausible output is dangerous. A beautiful generated itinerary is not useful if the place data is weak. A confident recommendation is not useful if it ignores the actual use case. A polished UI is not useful if the structure underneath is wrong. That is when I started to see the work differently. AI did not remove the design process. It made the invisible parts of the design process more important. Before, a lot of taste, context, and judgment could stay inside a designer's head. You could carry the product feeling from meeting to meeting, from Figma frame to Figma frame, from critique to handoff. It was inefficient, but it worked because humans were doing most of the translation. With AI agents, that breaks quickly. An agent can generate a page, rewrite a brief, inspect code, build a prototype, or suggest an implementation. But it does not automatically know what good means for this product, what sources matter, what tradeoffs are acceptable, or when the output is plausible but wrong. So the work changes. The designer becomes the person who gives the system taste, context, sequence, and proof. That is the lesson Planark keeps teaching me. ### The Easy Version Would Have Been A Chatbot The easiest version of Planark would have been a chat box. Where do you want to go? How many days? What kind of trip? Then the app could return a generated itinerary and call itself an AI travel planner. That would have been easier to explain. It would have matched the market. It would have looked current because so many products are racing to put a prompt field on the first screen. But it would have been the wrong product. Travel often starts before the user knows what to ask. You arrive somewhere and do not understand the surrounding region yet. You pass a sign for a town you have never heard of. You are staying in a coastal place and someone mentions a river delta, a wine area, a national park, or a small town nearby. The problem is not writing a better prompt. The problem is not knowing the question. That distinction changed Planark. It pushed the product away from "AI as the interface" and toward AI as a layer inside a more specific travel experience. Planark should help someone understand the shape of a place before they ask for a plan. That is a product decision, not a prompt decision. ### Regional Discovery Became The Product For a while, I thought Planark was an AI trip planner with strong discovery features. That was close, but not quite right. The real category became clearer through the work: Planark is a regional discovery app with trip planning attached. That sentence matters because it changes the design priorities. Most travel products are good when the destination is already famous or already chosen. Search for Barcelona, Lisbon, Rome, or a three-day itinerary and the internet is full of answers. But travel is not only famous cities. Some of the best moments are outside the obvious center: a coastal drive, a small village, a river delta, a wine route, a historic loop, a park, a town that is not in the top ten but is exactly right for an afternoon. Maps can show pins. Booking sites can show inventory. Review platforms can rank businesses. A chatbot can describe something if you already know what to ask. But the missing layer is regional understanding. What is around me? What is worth exploring? Is this a twenty-minute stop, a half-day detour, or a weekend? That is the job Planark has to do. AI can help with ranking, summarizing, route naming, and explanation. But AI did not decide that a region card was not enough. AI did not decide that people do not want "a region" in the abstract. They want a reason to go. That was product judgment. ### Plausible Is Not Good Enough The most dangerous thing about AI travel planning is that bad output often sounds good. A generated itinerary can be polished, confident, and wrong. The place might not exist. The distance might be unrealistic. The opening hours might be invented. The recommendation might be the same generic list every model has seen. The day might look complete until someone tries to use it. Travel is not a domain where "sounds right" is enough. That forced a rule into Planark: Real data first. AI after. Wikivoyage helps with travel structure. OpenStreetMap helps with coordinates and place types. Wikipedia and Wikimedia help with identity and images. Weather helps with timing. Perplexity can help with freshness. Gemini can help organize, rank, explain, and compose. The list of providers is not the important part. The order is. AI should not invent the map. It should not hallucinate a place. It should not replace coordinates, source identity, distance, or source-trust checks. The best use of AI in Planark is not "make something up." It is: Take real material and make it useful. That idea now sits at the center of how I think about AI design work. If the source is weak, the output should be restrained. If the match is uncertain, the interface should not pretend. If the product cannot verify a detail, it should not present it as fact. Trust is built by restraint. ### Prompts Were Not Enough This is where prompts started to feel too small. A prompt can produce an answer. It cannot carry the whole product context. It cannot remember every source decision, every design rule, every previous mistake, every taste decision, every QA habit, or every reason a generated direction was rejected. That does not mean prompts are useless. It means prompts are one piece inside a larger workflow. In Planark, the important material started living around the prompt: - product notes - source maps - design rules - itinerary quality checks - build logs - debugging notes - screenshots - HTML mockups - implementation constraints - editorial drafts - decisions about what Planark should not become That is when Markdown became part of the product process. Writing was not separate from building. Writing was how I made the product thinkable enough for agents to help. ### AI Exposes Weak Product Thinking One uncomfortable thing about AI-assisted building is that it removes some of the old hiding places. Before, a feature could sit in a document for weeks and still sound reasonable because nobody had pushed it into a real screen, a real data model, or a real user flow. With AI tools and code agents, the distance from idea to artifact is much shorter. That means weak ideas reveal themselves faster. Loops was the clearest example. The obvious version was simple: Take available travel regions. Show cards. Let users tap. There is nothing technically wrong with that. It could be built. It might even look polished. But it felt empty. A user does not want "a region." They want a reason to go. That sentence changed the work. The feature had to translate geography into intent: a coastal drive, a wine route, a mountain escape, a heritage loop, a nearby afternoon, a weekend with small towns and enough breathing room. AI could help name, rank, summarize, prototype, and compare directions. But it could not decide that "region cards" were not enough. That was the product work. ### Designers Get Closer To The Material Building Planark also changed my relationship with code. I do not think the lesson is "every designer must become an engineer." That is too simplistic. The better lesson is that designers get better with AI when they get closer to the material. An HTML mockup makes an idea more concrete than a paragraph. A code diff shows what the agent actually changed. A log can reveal that the visible UI problem started much earlier in the data path. A local prototype can expose a missing product decision that a static mockup hides. This is where the designer-builder loop becomes useful. Not because code is the new status symbol. Because implementation makes judgment sharper. In Planark, some decisions looked like UI decisions but were actually source decisions. Some loading problems looked like image problems but were actually data-path problems. Some itinerary problems looked like writing problems but were actually trust problems. If I only reacted to the surface, I would patch the wrong thing faster. AI makes that very easy. ### Logs Before Fixes One of the most practical lessons from Planark is simple: Do not guess where the bug is. Look. That matters even more when agents are involved. A model can propose a fix quickly. A UI symptom can look obvious. A missing image looks like an image bug. A slow itinerary looks like a model problem. A bad card layout looks like a styling issue. Sometimes that is true. Often it is not. The workflow has to create evidence before it creates changes. Read the logs. Trace the source path. Find where the data changes shape. State what was verified. State what remains unverified. That is not glamorous, but it is the work. AI can help with it if the workflow forces it to respect evidence. If not, it will happily help you patch the wrong thing faster. ### What Stayed Human The more AI helped me build, the more human the important decisions became. AI could generate options. It could not decide what Planark should be. It could write copy. It could not decide that Planark should feel calm instead of magical. It could suggest an itinerary. It could not decide that a wrong image is worse than no image. It could build a chat-first flow. It could not decide that regional discovery was the stronger product. It could produce region cards. It could not decide that people need a reason to go. Those are not model problems. They are design responsibilities. ### The Loop Planark Taught Me The loop I keep coming back to is: ```text idea -> product context -> prototype -> implementation -> source trust -> QA -> launch pressure -> saved learning -> Harness rule ``` This is different from: ```text prompt -> output -> ship ``` The first loop compounds. The second loop resets. Every time Planark exposed a problem, the useful question was not only "how do I fix this?" It was: What should this teach the system? If the issue was source trust, the Harness needs a source-trust rule. If the issue was design drift, the Harness needs design memory. If the issue was vague product intent, the Harness needs a better brief. If the issue was agent overreach, the Harness needs a clearer task boundary. If the issue was QA, the Harness needs a validation step. This is how a side project becomes more than a side project. It becomes a proof environment. ### Why This Leads To The Design Harness The Design Harness is my answer to the mess Planark revealed. Not a prompt pack. Not a folder of random AI tricks. A reusable operating system for design work with AI: - product context - design memory - source-trust rules - task briefs - agent skills - critique checklists - prototype templates - validation habits - build logs - saved lessons The point is not to make the process heavier. The point is to stop starting from zero. If a designer has to explain taste, context, sources, constraints, and quality from scratch every time they open an AI tool, the workflow is fragile. If those things are captured, updated, and reused, the workflow gets stronger. That is what Planark taught me. AI makes it easier to produce. Real products teach you what production is missing. The Harness is how I want to save that learning and carry it into the next project. ## Review Notes For The First Three Articles The opening arc now reads: 1. `The New Era Of AI Design` The wide argument: output is cheaper, but taste, judgment, craft, context, and responsibility matter more. 2. `The New Design Process` The workflow argument: the useful loop is intent, context, agent task, prototype, critique, test, validation, and saved learning. 3. `A Side Project Is The Fastest Way To Learn AI Design` The proof: a real product exposes source trust, product judgment, design memory, logs, QA, and the need for the Harness. ## Notes For HTML Build - Use `article-template.html`. - Keep the hero title as `A Side Project Is The Fastest Way To Learn AI Design`. - Use Planark in the subtitle as the proof environment. - Subtitle should mention the shift from prompts to taste, context, orchestration, validation, and reusable memory. - Use one terminal-style block for the loop. - Use one data table for `Step -> Artifact`. - End with a CTA to `The Design Harness`.