# Konigi
Konigi is the personal knowledge hub of Michael Angeles, a product designer, writer, DJ, and independent builder based in the San Francisco Bay Area.
Konigi focuses on:
- AI-assisted product design
- Design engineering
- Claude Code workflows
- Creative systems
- Independent product building
This site publishes essays, tutorials, resources, and experiments for designers building products with AI.
## Canonical Identity
Person: Michael Angeles
Brand: Konigi
Roles:
- Product Designer
- Writer
- DJ
- Independent Builder
Areas of expertise:
- AI-assisted product design
- Design engineering
- Claude Code workflows
- Creative systems
- Independent product building
Creator of:
- housemusic.is
- The DJ Kit
- Flyr Studio
- DJ Konigi
- Klarita
## Topics
- AI-assisted Product Design
- Design Engineering
- Claude Code
- Product Strategy
- Creative Systems
## Writing
- [From capture to inference](https://konigi.com/articles/from-capture-to-inference): Why a vault of linked markdown notes and an enterprise knowledge graph are the same shape. And why I built Unicron, a Mac app that turns notes into action items and pushes them through to done.
- [I built a career coach out of markdown files](https://konigi.com/articles/i-built-a-career-coach-out-of-markdown-files): A Claude Code-powered second brain that functions as a persistent life and career coach, and tells you what you're avoiding.
- [How to get your site cited by AI: A GEO field guide](https://konigi.com/articles/how-to-get-your-site-cited-by-ai-a-geo-field-guide): AEO and GEO (Generative Engine Optimization) require different signals than traditional SEO. Here's what I actually did to get konigi.com visible to AI systems and what the limits of that work are.
- [How to research a company's UX in 30 minutes before your next interview](https://konigi.com/articles/how-to-research-a-companys-ux-in-30-minutes-before-your-next-interview): A repeatable workflow for pulling real UX sentiment about any company's product, turning it into talking points, and walking into the interview as a peer instead of a candidate. Worked example with a real company. Includes a downloadable Claude skill.
- [Claude Design has the incumbents scrambling](https://konigi.com/articles/claude-design-has-the-incumbents-scrambling): Anthropic shipped Claude Design a month after Google's Stitch 2.0. Everyone's watching Figma. The tools that should actually be nervous are Lovable, Bolt, and everything in that lane.
- [Think first, prompt later](https://konigi.com/articles/think-first-prompt-later): Generative coding with AI makes building easy. Building the right thing still takes design thinking. Here's why that matters more, not less, in the age of AI.
## Answers
Direct answers to the questions people ask about working with Michael Angeles.
### Fractional product design and build
https://konigi.com/answers/fractional-design-build/
- [What is a fractional product designer?](https://konigi.com/answers/fractional-design-build/#what-is-a-fractional-product-designer): A fractional product designer works with your team part-time on an ongoing retainer, rather than full-time or per-project. Michael Angeles runs fractional engagements through Konigi at two or three days a week, designing the work and then writing the front-end code that ships it.
- [Can I hire Michael Angeles as a fractional product designer?](https://konigi.com/answers/fractional-design-build/#can-i-hire-michael-angeles): Yes. Michael Angeles takes a small number of client engagements a year and runs one fractional slot at a time, currently with Calx Analytics. Engagements are two or three days a week with a three-month minimum. He passes on advisory-only work, so if nothing ships he's the wrong hire.
- [How much does a fractional product designer cost?](https://konigi.com/answers/fractional-design-build/#how-much-does-fractional-design-cost): Michael Angeles charges $14,000 a month for fractional design and build through Konigi. That covers two or three days a week with a three-month minimum, and he runs one slot at a time. The rate includes both the design work and the front-end code that ships it.
- [What's the difference between a fractional designer and a design agency?](https://konigi.com/answers/fractional-design-build/#fractional-designer-vs-agency): A design agency assigns you a team and hands off finished files. Michael Angeles works as one person inside your codebase and your process, so there's no handoff between design and build. Agencies scale to more surface area; a fractional design engineer goes deeper on fewer problems and ships them.
- [Does a fractional design engineer write production code?](https://konigi.com/answers/fractional-design-build/#does-a-design-engineer-write-production-code): Yes. Michael Angeles designs the interfaces and writes the front-end code that ships them, working in your repository and your review process. His own recent products were built with zero lines of hand-written code, using Claude Code as the build partner. The output is merged work, not a prototype.
- [How long does a fractional design engagement last?](https://konigi.com/answers/fractional-design-build/#how-long-does-an-engagement-last): Fractional engagements with Konigi run on a three-month minimum and continue month to month after that. Michael Angeles holds one slot at a time, so a start date depends on when the current engagement winds down. The commitment is shipped product every month, not a discovery phase that never ends.
- [When should a startup hire a fractional designer instead of a full-time one?](https://konigi.com/answers/fractional-design-build/#when-to-hire-fractional-instead-of-full-time): Hire fractional when you need senior design judgment but can't yet justify a full-time designer, or when you'd otherwise need to hire a designer and a front-end engineer at once. Michael Angeles works with product teams in exactly that gap, and leaves the design practice behind when the engagement ends.
### Team workshops for design teams adopting Claude Code
https://konigi.com/answers/team-workshops/
- [Does Michael Angeles run Claude Code workshops for design teams?](https://konigi.com/answers/team-workshops/#does-michael-angeles-run-workshops): Yes. Michael Angeles runs one and two-day Claude Code workshops for design teams through Konigi, built from the five free courses on this site and run against your own product rather than a sample project. Teams up to eight take one day; nine or more takes two.
- [How much does a Claude Code workshop cost?](https://konigi.com/answers/team-workshops/#how-much-does-a-workshop-cost): Konigi workshops are $7,500 a day. One day covers a design team of up to eight people; nine or more runs two days. Michael Angeles delivers them remote or on-site, with travel billed at cost on top of the day rate.
- [What do designers actually do in a Claude Code workshop?](https://konigi.com/answers/team-workshops/#what-happens-in-a-workshop): Every designer starts by getting a working Claude Code setup on their own machine. Then Michael Angeles works the course material as exercises against your real product, cut down from 38 modules to what your team needs. Managers get a separate session on what to expect and what to measure.
- [Do you run workshops remotely or on-site?](https://konigi.com/answers/team-workshops/#remote-or-on-site): Both. Michael Angeles runs Konigi workshops remotely over shared screens or on-site at your office, at the same $7,500 day rate. On-site travel is billed at cost on top. Remote works well for distributed teams; on-site is better when the team is already co-located.
- [How is the workshop different from the free courses?](https://konigi.com/answers/team-workshops/#workshop-vs-free-courses): The courses are the same material, self-paced and free on konigi.com. The workshop compresses them into a day or two, cuts the 38 modules down to what your team specifically needs, and runs the exercises against your product with Michael Angeles in the room to unblock people.
- [Are the Konigi courses free?](https://konigi.com/answers/team-workshops/#are-the-courses-free): Yes. All five courses on konigi.com are free and self-paced, covering 38 modules across discovery, research, prototyping, testing, and design engineering. Michael Angeles wrote them and there's no signup or paywall. They're also the source material the paid Konigi team workshop is built from.
### 1:1 pair sessions in Claude Code
https://konigi.com/answers/pair-sessions/
- [Can I book a 1:1 session to learn Claude Code?](https://konigi.com/answers/pair-sessions/#can-i-book-a-1-1-session): Yes. Michael Angeles runs 1:1 Claude Code pair sessions through Konigi, remote over a shared screen, on your real project rather than a demo. A half day is $1,200 and hourly is $350. Most people book the half day because four hours is where real progress happens.
- [How much does a Claude Code pair session cost?](https://konigi.com/answers/pair-sessions/#how-much-does-a-pair-session-cost): A half-day pair session with Michael Angeles is $1,200 for four hours, or $350 an hour if you'd rather go shorter. Sessions run remote over a shared screen. Most people book the half day, because an hour mostly goes into context on your project.
- [What happens in a Claude Code pair session?](https://konigi.com/answers/pair-sessions/#what-happens-in-a-pair-session): You and Michael Angeles meet over a shared screen with Claude Code open on your actual project, pointed at whatever you most want to move. He explains each decision as he makes it, from how he briefs the model to why he throws a draft away.
- [Who are pair sessions for?](https://konigi.com/answers/pair-sessions/#who-are-pair-sessions-for): Designers who want to ship their own work, and solo founders building without a team. Michael Angeles runs these for people who already know what they want to build and are losing time to the how. They're not an introduction to design or to programming.
- [Is a pair session coaching, or do we actually build something?](https://konigi.com/answers/pair-sessions/#coaching-or-building): You build something. Michael Angeles doesn't take advisory-only work, so a session ends with code committed to your repository, not notes. The teaching happens inside the building rather than alongside it, which is why it runs on your real project.
- [Should I book a pair session or a team workshop?](https://konigi.com/answers/pair-sessions/#pair-session-or-workshop): Book a pair session if you're one person trying to ship your own work. Book a workshop if you have a design team that needs shared conventions. Michael Angeles runs sessions at $1,200 a half day and workshops at $7,500 a day for up to eight designers.
### GEO and AEO, and getting cited by AI
https://konigi.com/answers/geo-and-aeo/
- [What is AEO (answer engine optimization)?](https://konigi.com/answers/geo-and-aeo/#what-is-aeo): Answer engine optimization is the work of making a site the source an AI assistant quotes when it answers a question. Unlike SEO, which competes for a ranked link, AEO competes for a citation inside a generated answer. The unit that gets retrieved is a passage, not a page.
- [What is GEO and how is it different from SEO?](https://konigi.com/answers/geo-and-aeo/#what-is-geo-vs-seo): Generative engine optimization targets a citation inside an AI-generated answer rather than a position in a list of links. SEO optimizes a page for a ranking algorithm; GEO optimizes a passage for a retrieval system and the credibility signals a model has learned to trust. The two overlap but reward different things.
- [How do I get my site cited by ChatGPT and Perplexity?](https://konigi.com/answers/geo-and-aeo/#how-to-get-cited-by-ai): Write self-contained passages that answer real questions, mark up your identity so engines know who you are, and earn third-party mentions. Michael Angeles found the on-site work gets you eligible to be cited, but the off-site credibility is what actually gets you picked.
- [Does Michael Angeles do AEO and GEO consulting?](https://konigi.com/answers/geo-and-aeo/#does-michael-angeles-do-aeo-consulting): Yes. Michael Angeles takes on AEO and GEO work through Konigi in three forms: an assessment of how visible a site currently is to AI systems, ongoing monitoring of whether assistants are citing it, and content built to be citable. Scoping and rates are per engagement.
- [What does an AEO assessment include?](https://konigi.com/answers/geo-and-aeo/#what-does-an-aeo-assessment-include): A Konigi AEO assessment covers three things: whether AI systems can crawl and parse your site at all, whether your identity is unambiguous to them, and whether your content is written in passages that survive retrieval. It ends with a ranked list of fixes, not a score.
- [Does schema markup help you get cited by AI?](https://konigi.com/answers/geo-and-aeo/#does-schema-markup-help-with-ai): Schema markup is a parsing guarantee, not a ranking lever. It ensures an engine reads your content and your identity the way you intended. Google confirmed in 2026 that special schema isn't required for AI search, and Michael Angeles treats it as cheap table stakes rather than a strategy.
- [How do you measure whether AI tools are citing your site?](https://konigi.com/answers/geo-and-aeo/#how-to-measure-ai-citations): By asking the assistants directly and tracking what comes back over time. Konigi monitoring runs a fixed set of prompts against ChatGPT, Claude, Perplexity, and Google's AI surfaces on a schedule, and records whether you appear, what's said, and who gets cited instead.
### Knowledge graphs and the LLM Graph Wiki
https://konigi.com/answers/knowledge-structuring/
- [What is an LLM graph wiki?](https://konigi.com/answers/knowledge-structuring/#what-is-an-llm-graph-wiki): An LLM graph wiki is a body of plain-text notes where every idea is its own atomic page and the links between pages carry meaning, so a language model can traverse it as a graph rather than search it as a pile of documents. Michael Angeles builds these for individuals and teams.
- [How do I structure my notes so AI can actually use them?](https://konigi.com/answers/knowledge-structuring/#how-to-structure-notes-for-ai): One idea per note, plain markdown, explicit links between them, and a consistent vocabulary for the things you write about most. Michael Angeles builds personal vaults on this pattern with Claude Code as the engine, so an agent can treat the vault as memory rather than as search results.
- [What is a knowledge graph and does my company need one?](https://konigi.com/answers/knowledge-structuring/#what-is-a-knowledge-graph): A knowledge graph stores facts as entities and named relationships rather than as rows and columns, so systems can traverse meaning instead of joining tables. You need one when the same concept means different things in different systems and nobody can say authoritatively which is right.
- [Can I hire someone to structure my company's knowledge for AI?](https://konigi.com/answers/knowledge-structuring/#hire-someone-to-structure-company-knowledge): Yes. Michael Angeles takes on knowledge structuring work through Konigi, defining the terms, controlled vocabularies, and concept relationships a team needs before its knowledge graph is worth querying. Scoping is per engagement. This is library and information science applied to AI systems.
- [What does information architecture have to do with AI?](https://konigi.com/answers/knowledge-structuring/#what-does-ia-have-to-do-with-ai): Information architecture is the practice of defining what things are called and how they relate, which is precisely what a model needs in order to reason over your data. Michael Angeles, a co-founder of the Information Architecture Institute, argues AI made the discipline more valuable rather than less.
- [What's the difference between RAG and a knowledge graph?](https://konigi.com/answers/knowledge-structuring/#rag-vs-knowledge-graph): RAG retrieves passages that look similar to your question and hands them to a model. A knowledge graph stores explicit, named relationships the model can traverse. RAG is easier to stand up and fails quietly on questions that need several linked facts; a graph handles those but has to be built.
- [How do you build a second brain that Claude can read?](https://konigi.com/answers/knowledge-structuring/#second-brain-claude-can-read): Start with a folder of plain markdown files, one idea each, linked to one another, and point Claude Code at it. Michael Angeles built Unicron on exactly this: a local vault, no proprietary format, no lock-in, with the model reading files directly rather than through a sync service.
### Designing and building with Claude Code
https://konigi.com/answers/designing-with-claude-code/
- [Can a designer build a real product with Claude Code?](https://konigi.com/answers/designing-with-claude-code/#can-a-designer-build-with-claude-code): Yes. Michael Angeles has shipped eight products this way, all live today, and his recent ones were built with zero lines of hand-written code. The constraint isn't whether a designer can produce working software anymore. It's whether they know what's worth building.
- [What is a design engineer?](https://konigi.com/answers/designing-with-claude-code/#what-is-a-design-engineer): A design engineer designs an interface and then writes the code that ships it, rather than handing a specification to someone else. Michael Angeles works this way and teaches it through Konigi's free courses. The defining trait is owning the whole path from problem to production.
- [Should designers learn to code?](https://konigi.com/answers/designing-with-claude-code/#should-designers-learn-to-code): The old version of this question was about employability and the answer was usually no. The current version is different: a designer who can ship their own work makes decisions in the real material instead of in a picture of it. Michael Angeles thinks that's now worth the investment.
- [What does "think first, then prompt" mean?](https://konigi.com/answers/designing-with-claude-code/#what-does-think-first-then-prompt-mean): It's Michael Angeles's shorthand for doing the design thinking before you open the model. Frame the problem, decide what's worth building and why, then use Claude Code to build it. The order matters because a model will cheerfully build the wrong thing very quickly.
- [What's the difference between vibe coding and design engineering?](https://konigi.com/answers/designing-with-claude-code/#vibe-coding-vs-design-engineering): Vibe coding accepts whatever the model produces and iterates on the output until it looks right. Design engineering starts from a framed problem, reviews every change, and holds the result to the same bar as hand-written work. Michael Angeles teaches the second as a repeatable method, not vibes.
- [How do you go from a design idea to a working prototype?](https://konigi.com/answers/designing-with-claude-code/#from-design-idea-to-prototype): Write down what the thing is for and what a good outcome looks like, get the smallest honest version running, then put it in front of someone. Michael Angeles teaches this as a free six-module course, Prototyping from a Design Idea, on konigi.com.
### Wireframing and information architecture
https://konigi.com/answers/wireframing-and-ia/
- [Who wrote Wireframing for Everyone?](https://konigi.com/answers/wireframing-and-ia/#who-wrote-wireframing-for-everyone): Wireframing for Everyone was published by A Book Apart in 2023 and co-authored by Michael Angeles, who spent 15 years as the product designer at Balsamiq. It's a short practical book about using low-fidelity sketches to think through interface problems before committing to them.
- [Are wireframes still useful when AI can generate a UI instantly?](https://konigi.com/answers/wireframing-and-ia/#are-wireframes-still-useful-with-ai): Yes, and arguably more so. A wireframe's value was never that it was faster than building. It was that it's cheap to throw away. Michael Angeles argues that when generated interfaces look finished immediately, having a stage that's obviously provisional matters more, not less.
- [What is information architecture?](https://konigi.com/answers/wireframing-and-ia/#what-is-information-architecture): Information architecture is the practice of deciding what things are called, how they're grouped, and how they relate, so people and systems can find and understand them. Michael Angeles is a co-founder of the Information Architecture Institute and came up through IA before moving into UX and product design.
- [What's the difference between a wireframe, a mockup, and a prototype?](https://konigi.com/answers/wireframing-and-ia/#wireframe-vs-mockup-vs-prototype): A wireframe shows structure and content priority without visual design. A mockup adds the visual layer and looks like the finished screen. A prototype is interactive and demonstrates behaviour over time. They answer different questions, and picking the wrong one wastes the review.
- [How detailed should a wireframe be?](https://konigi.com/answers/wireframing-and-ia/#how-detailed-should-a-wireframe-be): Detailed enough to answer the question you're asking and no more. Michael Angeles's rule from 15 years at Balsamiq: if the wireframe looks finished, people will review it as if it were finished, and you'll lose the feedback you actually needed.
- [What does an information architect actually do?](https://konigi.com/answers/wireframing-and-ia/#what-does-an-information-architect-do): An information architect defines the vocabulary, categories, and relationships underneath a product or a body of content, then makes sure every surface uses them consistently. In AI work, that same output is what makes a system's inference trustworthy rather than plausible.
### Who is Michael Angeles, and how do you work with him?
https://konigi.com/answers/hiring-michael-angeles/
- [Who is Michael Angeles?](https://konigi.com/answers/hiring-michael-angeles/#who-is-michael-angeles): Michael Angeles is a UX and product designer based in the San Francisco Bay Area. He spent 15 years as the product designer at Balsamiq, co-wrote Wireframing for Everyone for A Book Apart, and co-founded the Information Architecture Institute. He now partners with founders and product teams to turn early ideas into shipped products, designing and building with AI.
- [What is Konigi?](https://konigi.com/answers/hiring-michael-angeles/#what-is-konigi): Konigi is Michael Angeles's design and build studio and personal knowledge hub. It's where he publishes writing and free courses on AI-assisted product design, ships his own products, and takes on a small number of client engagements each year. The name is Esperanto for “to make known.”
- [What is Michael Angeles an expert in?](https://konigi.com/answers/hiring-michael-angeles/#what-is-michael-angeles-an-expert-in): Product design, UX design, interaction design, information architecture, and AI-assisted development with Claude Code. Michael Angeles publishes his expertise as a structured knowledge bundle at konigi.com/okf, covering eleven areas from design thinking and wireframing to design systems and GEO/AEO. Each one links to the work that proves it.
- [What did Michael Angeles do at Balsamiq?](https://konigi.com/answers/hiring-michael-angeles/#what-did-michael-angeles-do-at-balsamiq): Michael Angeles was the product designer at Balsamiq for 15 years, working on the wireframing tool used by millions of people to sketch interfaces. The experience became the basis for Wireframing for Everyone, which he co-authored for A Book Apart in 2023.
- [What products has Michael Angeles built?](https://konigi.com/answers/hiring-michael-angeles/#what-products-has-michael-angeles-built): Eight products, all live: Klarita, a design brief tool; Unicron, a Mac second-brain front end; Motivist, an iOS tracking app for ADHD brains; PatternStax; FLYR.STUDIO; housemusic.is; 80s.is; and The DJ Kit. Most were built with Claude Code as the development partner.
- [What kind of work does Michael Angeles turn down?](https://konigi.com/answers/hiring-michael-angeles/#what-work-does-michael-angeles-turn-down): Advisory-only work. Michael Angeles takes engagements that end in shipped product, so if the arrangement is reviewing other people's work or sitting in strategy meetings without building anything, he'll say no. He also holds one fractional slot at a time.
- [How do I contact Michael Angeles about working together?](https://konigi.com/answers/hiring-michael-angeles/#how-do-i-contact-michael-angeles): Use the contact form at konigi.com/contact. Say what you're building, which of the three shapes fits, what a good outcome looks like, and when you'd want to start. Michael Angeles replies to every note within two business days, including the ones that are a no.
## Pages
- [About](https://konigi.com/about): Michael Angeles — product designer, former Balsamiq designer for 15+ years, co-author of *Wireframing for Everyone*, now building with AI.
- [Answers](https://konigi.com/answers/): Straight answers about fractional product design, AEO/GEO, knowledge graphs, workshops, and hiring Michael.
- [Services](https://konigi.com/services/): Fractional design and build ($14,000/mo), team workshops ($7,500/day), and 1:1 pair sessions ($1,200 half day).
- [Products](https://konigi.com/products/): Eight shipped products, designed and built with Claude Code.
- [Courses](https://konigi.com/courses/): Five free self-paced courses, 38 modules, on designing and building with AI.
- [Resources](https://konigi.com/resources): Curated tools and links for designing and building with AI.
- [Contact](https://konigi.com/contact): Get in touch.
## Knowledge
- [Konigi Brain (OKF bundle)](https://konigi.com/okf/index.md): A structured knowledge bundle in Open Knowledge Format describing Michael's areas of expertise, the writing and courses that prove them, and how to work with him.
## Feeds
- [RSS](https://konigi.com/rss.xml): Full article feed.
---
# [From capture to inference](https://konigi.com/articles/from-capture-to-inference)
> Why a vault of linked markdown notes and an enterprise knowledge graph are the same shape. And why I built Unicron, a Mac app that turns notes into action items and pushes them through to done.
In 1854, John Snow traced a cholera outbreak in London to a single water pump on Broad Street. Edward Tufte retells the story in Visual Explanations as a case where the evidence was there all along, waiting for someone to organize it and make it visible. The map gets the credit, but the real work was weeks of door-to-door data gathering; the map was how Snow made the case, not how he found it.
Even then, the establishment clung to a different and incorrect theory. It took nearly 30 years and a citywide sewer project before science confirmed what Snow's map already showed. The evidence took weeks to capture and a generation to accept.
We're living in an era where the gap between capturing evidence and acting on it has collapsed. The inference ability of LLMs is what's driving that speed. I've been experimenting with this at a small, personal scale.
This is the story of why I built Unicron, a Mac front end for my Claude Code second-brain skills. A second brain, if the term is new to you, is a store of everything you want to remember, kept outside your head in linked notes. The idea comes out of personal knowledge management and the tools-for-thought community, and its lineage runs deep, back through [Doug Engelbart's work](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos) on hypertext and augmenting human intellect to [Vannevar Bush imagining the memex](https://en.wikipedia.org/wiki/As_We_May_Think) in 1945, a desk that would hold a researcher's whole library as a web of linked ideas.
## The shift from capture to inference
A lot of my day is spent on capture, analysis, synthesis, and tracking. This can look like researching a project, pulling action lists out of meeting notes, or reading through notes to find a detail I know I saved somewhere (but where?). All of it comes down to finding the right thing at the right moment to make a decision. It eats the day fast. And when capture is slow, or doesn't happen at all, progress stalls with it.
The way we do knowledge work is changing now that LLMs can usefully describe the meaning of raw information. Hand one your meeting notes, a project brainstorm, your notes about a person, or any unstructured file, and you get back something organized and actionable. You show up ready to go to town on your action list, aware of what's going on. This is the magic of inference.
It's the natural evolution of the knowledge work I got into years ago, fresh out of an MLS program and working in digital libraries at Bell Labs. Back then I was a naive junior IA and front developer who began experimenting with alternative lightweight systems for knowledge management. I wrote articles in [Library Journal and LLRX](https://scholar.google.com/citations?user=6B-ttHcAAAAJ&hl=en), and gave a [talk at Los Alamos National Laboratory](https://web.archive.org/web/20051219205419/http://urlgreyhot.com/personal/node/2416) and [Computers in Libraries](https://web.archive.org/web/20101201203738/http://urlgreyhot.com/files/cil2004/angeles-cil-presentation-notes_print.pdf) about the frontier of knowledge capture using grassroots tools like blogs and wikis—things that gave access to anyone without locking them into cumbersome, esoteric systems. That was 20 years ago! Those ideas seem so quaint now. Those ideas about slow information capture and retrieval with heavy tools like federated search seem so quaint compared to what we can do today. Now the frontier has moved to passive capture and inference.
## Enter Unicron
People are already building products on this shift. My entry is [Unicron](https://unicron.konigi.com), a free Mac app that moved my initial Brain skills out of the terminal, with the Claude Code CLI as the engine. For now it's a fast way to iterate on the idea.
The part that changes your relationship with your notes is that Unicron treats the vault of notes, the folder holding all your notes, as the agent's memory. When the agent reads the vault before every daily brief and writes new notes back into it after every meeting, the notes stop being an archive and become the long-term memory of something that works alongside you. Local-first here means the files are plain markdown on your machine, portable and yours, with no lock-in. The inference runs on Claude in the cloud, so the data is yours even though the model isn't.
There's also an engineering reason plain markdown works so well. The second-brain crowd has always pushed atomic notes—short files that hold one idea and link heavily to their neighbors. That topology turns out to be close to ideal for an LLM. Hand a model a hundred-page document and it has to find the needle. Hand it a web of small linked notes and every retrieval comes back tightly scoped, with its context attached. Obsidian users were building the right data structure years before there was a model that could take advantage of it.
## The same shape at enterprise scale
Companies are building the same thing, and the vocabulary changes when they do. My vault links a meeting note to a project note with a wikilink. An enterprise knowledge graph links a customer in the CRM to an order in the ERP to a thread in Slack, mapping the business as entities and relationships instead of files and folders. It's the same shape with bigger nouns.
Where I get by with folders and tags, a company needs a semantic layer. Systems need a shared vocabulary so the model knows, for instance, that "gross margin" in a legacy spreadsheet and "profitability" in the new dashboard mean the same thing. This is the stuff of library and information science—defining terms, building controlled vocabularies, and mapping how concepts relate to each other. What's funny to me is that it's the work I trained for in the MLS program and did at Bell Labs, back when it felt like the least glamorous corner of the field. And now the importance of this work is cycling back into discussions. Seems the taxonomists were early.
Retrieval works differently on a graph, too. Plain vector search matches text that looks like your question, which is how you get confident answers assembled from the wrong context. GraphRAG makes the model follow the graph's actual relationships instead, the way you'd click from note to note in Obsidian. Ask how a supply chain delay in Ohio affected your top three clients and it walks from the Ohio node to the delayed shipments to the accounts those shipments feed. That doesn't make it hallucination-proof (nothing is), but the answer is grounded in connections that exist, and you can trace how it got there.
The idea runs in both directions. If you understand why a vault of small linked markdown files makes a personal agent useful, you understand the architecture enterprises are buying as a knowledge graph. Data that's linked and defined before the model shows up is what makes inference trustworthy at any scale. And the problem I see at both scales is the same one.
You already see pieces of this in Granola, Notion, Otter, Zoom, and Meet, and plenty of companies talk about workflows that pull notes out of a dashboard into where the work actually happens, e.g. Jira, Asana, Notion. But I don't hear many people talking about the part that interests me, which is not just organizing the notes, but forcing the action items through to done, with someone accountable for each one. That's what's I'm experimenting with in making Unicron.
Knowledge work has gotten exciting to me again. I am exploring opportunities to do really useful work in this space. I help teams structure their knowledge for AI inference. If you want to discuss where this is going, [connect with me on LinkedIn](https://www.linkedin.com/in/michaelangeles/) or [email me](https://konigi.com/contact/).
## Mentioned in this article
- [Visualization myths around Snow's cholera map](https://petewarden.com/2010/10/21/visualization-myths-around-snows-cholera-map/)
- [Unicron](https://unicron.konigi.com): my free Mac front end for Claude Code second-brain skills
- [Claude Code](https://claude.com/product/claude-code): Anthropic's agentic CLI, the engine behind Unicron
- [Obsidian](https://obsidian.md): local markdown vault with linked notes; the reference second-brain editor
- [Granola](https://www.granola.ai): AI meeting notes captured locally on your Mac, no bot in the call
- [Otter](https://otter.ai): meeting transcription and summaries across Zoom, Meet, and Teams
- [Zoom AI Companion](https://www.zoom.com/en/ai-assistant/): Zoom's built-in meeting summaries and action items
- [Gemini in Google Meet](https://workspace.google.com/products/meet/): Google's built-in meeting notes
- [Notion](https://www.notion.com): docs, wikis, and databases with AI layered on top
- [Jira](https://www.atlassian.com/software/jira) and [Asana](https://asana.com): where action items go to get done (or not)
- [GraphRAG](https://github.com/microsoft/graphrag): Microsoft's open-source graph-based retrieval project
- [Visual Explanations](https://www.edwardtufte.com/book/visual-explanations-images-and-quantities-evidence-and-narrative/): Edward Tufte's book with the John Snow chapter
---
# [I built a career coach out of markdown files](https://konigi.com/articles/i-built-a-career-coach-out-of-markdown-files)
> A Claude Code-powered second brain that functions as a persistent life and career coach, and tells you what you're avoiding.
I have ADHD. I've been thinking about "temporal discounting" because it's something I've lived with my whole life. The brain struggles to feel the future as real. A small, immediate reward wins over a larger, long-term priority because the future just doesn't feel concrete to it. Some smaller task feels more real, so I do that one instead.
Personal knowledge management has been an interest of mine for a long time. I published an article about using blogs for KM when I was at Bell Labs and gave a talk on the topic at Los Alamos. I've tried a lot of systems since then including Wikis, Notion, Obsidian, Apple Notes, and a few task managers. All were useful for different purposes. They could also be easily ignored. They were good for storing things, but what I need is a coach.
A few months ago, a friend started sharing ideas about practical AI in PM work. I'd also come across Andrej Karpathy's LLM wiki concept of using a set of markdown files maintained by an AI as a live knowledge base, with no proprietary formats or app. Plain files and an agent that reads, writes, and keeps them current.
So I used Claude Code to build my own second brain, customized to my particular needs. It tells me exactly what I need to keep track of and prioritize. It maintains perfect memory of my tasks, my blind spots, and the areas I'm working to improve. I asked it to be brutally honest, and it essentially serves as a straight-shooting, objective career coach.
## The idea behind it
I have folders for people I work with, companies I'm engaged with, raw notes and transcripts, and a living self-profile that gets updated after significant sessions. The profile holds who I am, what I'm optimizing for, and my active growth edges, the patterns I'm working on. Every command that runs reads that profile first. That's what makes the coaching feel personal rather than generic.
## What it actually does
The system runs on Claude Code slash commands. The main ones are `/focus`, `/meeting`, `/prep`, `/journal`, and `/tasks`.
`/focus` generates a daily brief and writes it to a local HTML file I've set as my browser homepage. Every morning it's just there. The brief has five sections: top three priorities, the thing I'm avoiding, open threads by person, hard deadlines, and a reflection prompt. The top three always lead with a job search action. It's never the vague category "job search." It's the specific thing I haven't done yet, like sending the emails or following up with the recruiter. The system reads my notes, so it knows what I've committed to, and it points right at the part I've been skipping.
`/meeting` takes a raw transcript or Granola note and processes it into a clean dated meeting file, updates the relevant people notes and company notes, and checks whether my profile should change based on what happened. This bidirectional update matters: a meeting reveals something about a coworker, but also something about how I showed up.
`/prep` reads a person's note, the company context, and my recent meetings before any call. It produces a brief in chat: who they are, how they communicate, what I owe them, what they owe me, and what I should raise.
`/journal` creates a daily entry in a `journal/` folder. The entries are free-form, but two conventions matter: lines starting with `→` are flagged reflections that get surfaced in the next day's brief, and lines starting with `!!` are urgent flags that get folded into "The Thing You're Avoiding" without softening.
## The thing you're avoiding
The `!!` flag is the part that blows my mind. Those flags surface the next morning and stay visible until I deal with them. Nothing gets softened into a gentle reminder. They show up exactly as I wrote them, which means I wrote them at the moment I knew I was avoiding something, and the system holds that against me the next day. Most productivity tools just remind you of tasks. This one reads what you wrote about yourself and calls you out by name.
I've been thinking about ADHD and this idea of temporal discounting, and looking for ways to keep myself accountable about the things I'm avoiding. So in my journal I added a `!!` flag: *Stay on top of your listening tour discussions.* That flag showed up in my daily brief the next morning under "The Thing You're Avoiding," right next to the Listening Tour emails that still hadn't been sent.
The reason this one can do that is persistence. Claude has the context. It read yesterday's journal, the meeting from two weeks ago where I made a commitment, the profile note about my tendency to go deep on the wrong thing when the important thing feels hard. It holds all of it, so when I'm not doing something I said I would, it notices.
## Building it as a pairing practice
Like a lot of my projects, this one grew organically. I started with a single need and built each piece with Claude as I hit it. The `/focus` command came first. I described what I wanted the brief to look like and we iterated on the prompt until it felt right. The journaling system came later, when I realized I wanted somewhere to put reflections that would actually get read back to me.
Claude showed up when I needed it in each build session. When I said "the brief should tell me what I'm avoiding," Claude asked what source material it should draw on. That question changed how I thought about the profile file. When I said "I want journaling that coaches me," Claude suggested the `→` and `!!` flag conventions as a lightweight way to signal intent without requiring structure.
The system is about 11 files as of this initial release: a CLAUDE.md with operating instructions, a set of slash commands in `.claude/commands/`, and the vault folders that hold the actual content. The journal, people notes, company notes, and HTML output files are all gitignored. What's public is the scaffolding, the instructions and commands that anyone can fork and fill in with their own life.
The template is at [github.com/jibbajabba/brain](https://github.com/jibbajabba/brain). If you use it, the first thing to do is write your own `me/profile.md`. That file is what makes the coaching yours.
---
# [How to get your site cited by AI: A GEO field guide](https://konigi.com/articles/how-to-get-your-site-cited-by-ai-a-geo-field-guide)
> AEO and GEO (Generative Engine Optimization) require different signals than traditional SEO. Here's what I actually did to get konigi.com visible to AI systems and what the limits of that work are.
The practice of optimizing your site content for AI is called AEO (AI Engine Optimization) or GEO (Generative Engine Optimization), depending on who you ask. AI assistants like ChatGPT, Perplexity, Gemini, and Claude are increasingly where people go for answers, and those systems don't work like search engines. They pull from a different pool of signals. If you only think about Google, you're not optimizing for these new search behaviors.
Since I'm relaunching Konigi, I have some work to do to optimize it for AI engines, so that people looking for answers related to AI-assisted design in their LLMs might find answers here. Here's what I did and what the limits of this kind of work are.
## What AI engines need that Google doesn't
Search engines rank pages. Google cares about backlinks, page speed, and keyword density.
AI engines synthesize answers from sources they trust. They care about clarity, structured data, and whether there's enough context to understand who wrote something and why they're credible. They also care about what's been published about you elsewhere on the web.
A site can rank well on Google and still be invisible to AI engines, and vice versa. This site at the time of writing is in the first camp. There's nothing that helps AI systems understand who writes here, what I know, or how articles connect to each other.
There's also a shift in what success even looks like now. With SEO, the goal is a click. Someone sees your result and visits your site. With GEO, an AI generates the answer and the user may never visit at all. They got what they needed inside the AI interface. That sounds like a loss. It isn't, not really. The citation still happened, your brand still got mentioned, and the reader's picture of who knows this topic now includes you. You're optimizing for presence in the answer, not for the click.
## The mechanical work: JSON-LD and Byline
### JSON-LD
The first thing to do is add JSON-LD structured data. This is machine-readable metadata embedded in page `` tags.
I added three schemas in a script tag embedded in the head:
1. A `WebSite` schema appears on every page. It names the site, describes it, and links to the author.
2. An `Article` schema appears on every article page. It names the piece, credits the author with job title and areas of expertise, and gives the publish date.
3. A `Person` schema on the `/about` page fills out the author profile: what I know, what I've written, what my professional background is.
Looks like this:
```
```
None of this is visible to readers. It's entirely for crawlers and language models. It answers the questions AI systems ask when deciding whether to cite a source, e.g. who wrote this, do they know what they're talking about, and is this current?
### Author byline
I also added an author byline to every article, beneath the title.
Signed content is more likely to be treated as authoritative than anonymous content. The byline is an E-E-A-T signal (experience, expertise, authoritativeness, trustworthiness), a framework Google uses and that AI engines appear to apply in their own ways.
### LLMS.txt?
I've seen conflicting information about the use of [llms.txt](https://llmstxt.org) files. This is a plain-text file at the root of your site that tells AI crawlers what the site is about and where to find the content, like a README for language models. It could list the site's purpose with links to every published article with a one-line description, and point to the about page and RSS feed. Doesn't seem harmful. So I added it, plus an `llms-full.txt` built the same way but with the full text of every article appended. That gives AI engines the actual content to work from, no page-by-page crawling required.
## Key takeaways and clarity
The mechanical stuff is table stakes. The harder part is writing in a way that's easy for AI to summarize accurately.
AI engines don't cite articles they can't summarize. If your ideas are buried inside long sections with weak headers, the model can't pull a clean answer from your content. The inverse is also true: if your article is a tight, well-structured piece with clear section headers and a direct argument, it's much easier for a model to reference it accurately.
I added a Key Takeaways block to each article. It includes three or four sentences summarizing the main points. You can see an example at the bottom of this article.
Key Takeaways are like the executive summary at the top of a long report. Not everyone will read everything, and the people (or systems) who skim need a reliable shortcut to the argument.
The takeaways also give AI engines something explicit to quote. Instead of having to synthesize meaning from 800 words of prose, they have direct bullets that represent the author's own summary of what matters.
There's some research behind this. The [GEO-BENCH study](https://arxiv.org/abs/2311.09735) from Princeton, Georgia Tech, Allen Institute for AI, and IIT Delhi tested optimization strategies across 10,000 queries in 25 domains. Their findings: quotations boost AI citation rates by 41%, using real statistics by 32%, including citations to authoritative sources by 30%, and clear writing by 28%. A separate analysis found that cited content has roughly 20.6% entity density (proper nouns, brand names, named people, specific products) compared to 5–8% in standard English. Specificity makes you more citable, and now there's data that measures it.
## What on-site work can't do
Everything above gets you ready to be cited, but doesn't make your words citable. I'm in that position right now. Writing content on a new topic in a new, undiscovered site (or blog if you will) won't necessarily make for appropriate answers to what's being asked.
AI engines build their understanding of authority from what's been published about you, not just from what you've published about yourself. A site with perfect structured data and no external mentions is a well-formatted unknown. A site with rough technical SEO but lots of credible third-party references will show up in AI-generated answers because the training data has already absorbed those signals.
This is the part that takes time and can't be engineered in one sitting. Speaking at events, writing for other publications, being quoted in articles, getting your work shared and linked by people with established reputations—these are the kinds of signals that will most likely tell AI systems a source is worth trusting. On-site optimization creates the infrastructure for authority, and third-party mentions are the authority itself.
## How do you know if it's working?
This is going to be the hard part I guess. There's no Perplexity Search Console and you can't see your citation rate the way you can see organic traffic. But companies like [AthenaHQ](https://athenahq.ai/) are trying to solve this problem for brands.
The proxies I'm using for now:
* Ask AI assistants about topics I write about and see if the site comes up.
* Watch for direct mentions in AI-generated content that gets shared.
* Check referral traffic for unusual sources.
I know this isn't precise. It's mostly hygiene work for now. It's the kind of thing that matters and will pay over time. The structured data is baked into the site and updates automatically as new articles publish. The writing habits, clear structure, explicit takeaways and signed bylines will make the content better for human readers too.
Optimizing for AI and optimizing for readers are the same work. Make your content clearer. Anyone who publishes should review their content now, or risk going invisible as people switch to AI search.
---
# [How to research a company's UX in 30 minutes before your next interview](https://konigi.com/articles/how-to-research-a-companys-ux-in-30-minutes-before-your-next-interview)
> A repeatable workflow for pulling real UX sentiment about any company's product, turning it into talking points, and walking into the interview as a peer instead of a candidate. Worked example with a real company. Includes a downloadable Claude skill.
My first instinct was to build a tool to do the research because I'm a builder. The thought was this, "I can build a little app that pulls reviews from G2 and Capterra and the App Store, runs sentiment analysis, and shows me the points of pain and friction. It'd help with every future interview. Maybe it could be a side product."
Thankfully I caught myself before heading to the terminal. I know how that story ends. I get sucked into scrapers and rate limits and anti-bot protection, and a few days later I've got a half-working tool and zero research done for the interview that's actually happening. Pausing to think saved my bacon.
So I did the boring, correct thing instead. I just did the research in Claude by hand. It took 30 minutes. It produced better material than any tool I could have built. Then I turned the workflow into a Claude skill so I can do it again in 10 minutes next time. The downloadable skill is at the bottom of this post.
## Why some candidates don't do this
Walk into a design interview and ask "what are your biggest UX challenges?" and you've told the hiring manager three things:
1. You didn't use the product.
2. You don't have your own opinions yet.
3. You expect them to do the work of framing the conversation.
We do it because real research used to take a full day. You had to find the reviews, read them, organize what you found, spot the patterns, then turn those into questions.
The economics are different now. With Claude running search and synthesis in parallel, you can do the whole pass in 30 minutes. So there's no longer much of an excuse.
One caveat. What you get back is a summary of what's been pulled from the sources the skill searches. It's on you to read it critically and pressure-test what it raises.
## The 30-minute workflow (as summarized by Claude)
The skill goes through seven steps after you hand it the company name. Duration is a rough estimate.
**Step 1: Scope (2 minutes).** Name the product and note whether it's B2B SaaS, consumer mobile, consumer web, developer tool, marketplace, or mission-driven tech. Different categories have signal in different places.
**Step 2: Broad search pass (10 minutes).** Do six or so parallel queries: G2 reviews, Capterra reviews, App Store reviews if mobile, Reddit, "alternatives to X" (reveals competitive friction), and Glassdoor (for internal product team complaints). Capture verbatim quotes with source names.
**Step 3: Friction-targeted pass (5 minutes).** Search with negative-sentiment anchors: `[product] frustrating`, `[product] confusing`, `[product] missing feature`, `[product] doesn't work`. Different sentiment words surface different shapes of complaint.
**Step 4.1: Read the product's marketing (5 minutes).** Reading marketing first anchors you to the team's framing. Read it last and the gap between promise and reality jumps out.
**Step 4.2: Pattern-match (5 minutes).** Group complaints into categories: wayfinding, error handling, onboarding, performance, feature gaps, integration friction, pricing clarity. If two or more independent reviewers mention the same thing, it's a pattern. One-off complaints are noise.
**Step 5: Generate improvements and questions (5 minutes).** For the top two or three patterns, draft a concrete change and the framing for a question. Each question should reference a specific finding, not a generic platitude.
**Final Step: Write up (5 minutes).** Friction patterns with quotes. Two or three improvements. Three to five questions. Under 1,500 words.
That's it. The whole thing is in a Claude skill I'm sharing below.
## Review the output
I ran this on the company I was interviewing with. I can't share that one, but here's the same pass run on Notion so you can see the shape of the output.
> ### Notion UX Sentiment Research
>
> **Sources scanned:** G2 (10,149 verified reviews), Capterra (4.7/5 across 2,000+ reviews), Reddit (r/Notion), UX Planet, Medium, Hacker News, and targeted Google searches across alternatives discourse.
>
> **Time spent:** ~30 minutes of search and synthesis.
>
> #### The pattern: the flexibility that sells Notion is the same thing that breaks it
>
> Every major friction cluster in Notion traces back to one architectural decision: the product is a canvas, not a system. That's the pitch and the problem. Power users love it. Everyone else hits a wall somewhere between "open blank page" and "have a working workspace." The complaints are not random — they cluster around four consistent themes, and they've been consistent for three years across independent reviewers.
>
> #### Top friction patterns
>
> 1. **Blank canvas paralysis.** New users open Notion and find themselves asking "What's a block? What's a rollup? Why are there five database types?" (Medium, Hetvi Desai). The template gallery partially addresses this, but templates teach the format, not the logic. Users still have to understand the underlying data model before the tool clicks. Nuclino's documentation on Notion alternatives summarizes the pattern: "Notion gives users a blank canvas rather than a system, requiring hours of building databases, templates, and views before actual work can begin. Once built, Notion systems require ongoing maintenance as pages pile up, databases get stale, and the system slowly becomes a graveyard of good intentions."
> 2. **Search doesn't scale with the workspace.** The more information lives in Notion, the harder it is to find anything. Quick Find doesn't cover subpages. There's no global search across databases from the main search bar. Keyword search "may fail to return relevant content that doesn't mention the search keyword directly" (Unleash). The painful irony: Notion markets itself as a second brain, but the search behavior actively undermines that promise at scale. Hacker News threads describe it plainly: "with everything in Notion, finding things becomes tricky — especially with quick search... if everything is in Notion, the number of search results will increase and increase, so finding anything will take longer and longer."
> 3. **Performance degrades once teams actually use it.** Databases over 5,000 rows load in 3–5 seconds. Databases over 10,000 rows make Notion "impractical as a primary database" for enterprise teams (NotionBoost). The root cause is architectural: Notion stores every element as an individual block in a centralized database, which creates exponentially more overhead as workspaces grow. Notion's own help center has a dedicated article on "optimizing database load times" — which is a tell. When the product needs a help article for a performance workaround, it's a systemic issue, not an edge case.
> 4. **The May 2025 AI pricing change felt like a bait-and-switch.** In May 2025, Notion retired the $10/month standalone AI add-on and bundled AI exclusively into Business and Enterprise plans. Free and Plus users now get 20 lifetime AI responses — total. Plus subscribers who had been paying $10 (plan) + $8 (AI add-on) = $18/seat lost AI access without an upgrade to $20/seat Business. Reddit's reaction was mostly negative. Multiple review aggregators document users describing it as a trust breach. The capability didn't change. The pricing architecture changed around them.
[View the whole example on Github.](https://github.com/jibbajabba/ux-sentiment-research/blob/master/examples/notion-output.md) The rest of the output includes a summary of what the friction points might tell you about the product team and a read on the product's maturity stage. Take what's useful to you as a starting point, but be sure to evaluate each point.
The report goes on to suggest areas for improvement, each anchored in a specific finding from the research. Do with that what you will, but I wouldn't regurgitate this. For example, you might see a suggestion like this: "the most consistent friction in your Capterra reviews is wayfinding." That could provide you with some specific questions you might ask, but make sure your question is grounded in the current reality in case the research is based on outdated information.
## What this gets you
A few things change when you walk in with research like this.
When you ask about a real concern, the interviewer can see you've done the work and actually used the product. With a little luck the conversation starts to feel like two peers talking instead of a candidate auditioning. You stop being the applicant. You become someone who could already be on the team, just talking shop about the product.
It flips the direction a little, too. Interviews are built around them evaluating you. Walk in with specifics and you're quietly evaluating them right back.
You also catch signals you'd otherwise miss. Ask about information architecture work. If the interviewer treats it as cosmetic, you've learned something about the role. If they treat it as structural to wayfinding and sensemaking, you've learned something else. Either way, the question reveals fit.
And you hand the hiring manager an easy way to advocate for you. When they go back and run through the candidates with their team, you're the one who said something concrete about the product. That's a much easier story to retell than "they seemed nice and gave good answers."
## Why this is pairing, not prompting
The instinct with Claude is often to write one long prompt and hope it works. "Research \[Product X] for me and give me everything I need for my interview." That's transactional prompting. You ask, Claude answers, you take what comes out.
Pairing is different. You stay in the loop. You read the first round of results, you notice a pattern, you steer the next search at a friction word, you read the marketing site after the reviews not before, you push back on a finding that feels thin. You don't leave your critical thinking behind.
The skill I'm sharing below codifies that pairing pattern. It's a workflow with checks and time-boxes and decisions about when to stop collecting and start synthesizing. This is the difference between designers who use AI well and designers who don't.
Stay in the loop. Don't outsource the thinking. Let the model handle the parts that are just execution (search, parallelism, formatting). Keep the parts that shouldn't be handed off (judgment, pattern recognition, deciding what to ask next).
## The skill
I packaged this as a Claude skill you can drop into your Claude Code setup or use as a workflow template in Claude chat. It includes the methodology, the source matrix by company type, and the query patterns that consistently surface real friction.
How to install it:
1. [Download ux-sentiment-research.skill](https://github.com/jibbajabba/ux-sentiment-research)
2. Drop the folder into your skills directory. Next time you have an interview, just say "research \[company] for my interview using ux-sentiment-research" and let Claude work the pattern. Or you can use the slash command, e.g. /ux-sentimentresearch \[Product]
You'll find instructions for how to use with Claude Code or Claude.ai (web and desktop).
## What I'd love to hear
If you run this on a company before an interview, I want to hear two things:
1. Did it surface something you wouldn't have found in 30 minutes by hand?
2. Did it change how the interview itself went?
[Find me on LinkedIn](https://www.linkedin.com/in/michaelangeles/). I'll be refining the skill based on what people actually report back.
---
# [Claude Design has the incumbents scrambling](https://konigi.com/articles/claude-design-has-the-incumbents-scrambling)
> Anthropic shipped Claude Design a month after Google's Stitch 2.0. Everyone's watching Figma. The tools that should actually be nervous are Lovable, Bolt, and everything in that lane.
Google released Stitch 2.0 on March 20, 2026. It shipped with an infinite canvas, multi-screen consistency, voice input, a Direct Edit feature, an MCP server, and a path to AI Studio for handing off to development.
Anthropic shipped Claude Design a month later. I don't know if that was a reaction to Stitch, and maybe it doesn't matter. In the battle for the desktop, Google and Anthropic are going at it fast.
My read is that Anthropic already had the product in hand and waited to ship it alongside Opus 4.7. Maybe I'm wrong. Either way, the sequence says a lot. Krieger steps off Figma's board, and three days later Anthropic ships Design. That's a real commitment to an already crowded category of generative design tools.
## Who actually needs to worry
I've seen plenty of "Figma is dead" takes. I've been around long enough to distrust any "so-and-so is dead" pronouncement, and the lines people draw in the sand tend to be premature. Figma isn't dead.
As someone who designs in code, I still can't get past the fact that 99% of design jobs require Figma. It's where teams manage their design tokens, run design reviews, and where the big companies keep their design system source of truth for multi-product systems. Claude Design doesn't do any of that, and Anthropic isn't pretending it does. The Canva partnership makes the positioning explicit. What Claude Design gives you in a few iterations is a really good draft, not a finished product. But it's early, and the output is impressive.
The tools that should be watching closely are the ones sitting in the same lane: Stitch, Figma Make, Lovable, v0, bolt.new. The "describe a thing, get a working prototype" category. Claude Design isn't at feature parity with any of them on depth yet. Lovable and Bolt generate full-stack apps with auth and a database. v0 has mature component-library integration. Stitch has a multi-screen canvas and voice.
But Claude Design does two things none of them do as well right now:
1. **It reads your codebase to extract your design system.** Point it at a repo, and every project after that uses your actual colors, typography, and components. Stitch has theme-level customization. Lovable, Bolt, and v0 can import a Figma file. Claude Design infers the system from production code.
2. **It hands off directly to Claude Code.** When a design is ready to build, Claude packages it into a bundle that Claude Code picks up with one instruction. That's vertical integration between the design surface and the agent that writes the code.
The second one is the structural advantage. Stitch can export to AI Studio. Lovable generates its own backend. But my guess is that most developers actually shipping AI-assisted products right now are on Claude Code. A design tool that hands off to the coding agent those devs already trust is going to be hard to counter from the outside.
## My first tries with it
A few experiments from the last week.
**Generating a design system from a Figma project.** I pointed Claude Design at a Figma file and had it extract a system I could apply to new screens for a prototype. It took a while and wasn't production-ready (you'd want to pressure-test the token decisions), but it was close enough to have a real conversation about the design with the client.
**Redesigning pitch deck slides with context-aware illustrations.** A colleague has a pitch deck he's been working on for an agency. I copied three slides and asked Claude Design to redesign them with animated illustrations tied to the topic of each slide. The illustrations actually corresponded to the content, which surprised me. What started as generic stock photos became modern illustrations that did a good job conveying abstract ideas.
**Swiss grid variations from a single portfolio screen.** I gave it the first screen from [my portfolio](https://michaelangeles.com) and asked for layout variations based on different grids drawn from Josef Müller-Brockmann's principles. Then out of curiosity I had it create illustrations to go with them. It treated the grid system as a design constraint, generated layouts that respected it, and made some genuinely interesting animated illustrations. For a designer who needs to explore, it delivered on the request: a lot of variations to spark ideas on something I'd been staring at for far too long.
**A full DIY environment for konigi.com.** I have a playground site, [konigi.com](https://konigi.com), that I wanted to turn into a DIY-themed environment for fun. I generated a graphic in Nano Banana to set the scene, handed it to Claude Design, and asked it to build the experience around that graphic. What came back was closer to a site than a mockup. The kind of thing I'd normally spend a weekend wiring up.
None of these are shippable without my hands on them. All of them compressed what could've taken me a week of exploration into a few hours. That's no exaggeration. I spent less than half an hour on the design system project and a few minutes on the pitch deck slides.
The last two projects, the portfolio and the playground page, ran a few hours each. After I had the portfolio screen and the playground package, I kept iterating and made them real on my server with Claude Code.
## What this may foretell
Right now, Claude Design and Stitch are positioned as generation tools. You describe something, they produce something. The output keeps getting better, but it's still a first draft that you refine in chat or export to a real design tool or to code for polish.
The scenario worth sitting with is what happens when the generative layer becomes the ideation surface for serious design work, and the professional tools have to rethink what they're for.
Claude Design already gives you inspector-level control over individual elements. It holds design-system consistency at generation time, and it can code full application flows from the same canvas. Keep pulling that thread and the thing Figma does best, the fine-grained pushing and nudging of screen elements, starts to look like a subset of what a prompt-native tool can do. We're not there yet. But the direction is hard to miss.
These tools are folding ideation, specification, and build onto one surface. Figma won its category by pulling design and collaboration into the browser. The next collapse pulls design and code into the agent itself.
When that happens, the designer's real question stops being which tool to use. It becomes what you're doing that the tool can't. The answer, as I keep saying here, is design thinking: knowing what to build, finding the right problem, and making the calls a prompt can't make for you.
Liz Miller, VP and principal analyst at Constellation Research, [had this to say at Adobe Summit](https://www.cmswire.com/digital-marketing/anthropic-labs-launches-claude-design-tool-for-visual-prototyping/). "Just as master painters have different brushes they use for different things, you are never going to use Claude for design to create your finished masterpiece," she told CMSWire. "You might use it and you might use OpenAI. You might even go and use a little Leonardo. You're going to use a lot of different things to get you to your end point."
She goes on to frame what Wall Street misses in its reaction. "While Wall Street is focused on outputs and how amazing those outputs are, Adobe continues to be focused on outcomes. And for an enterprise marketer, I'm going to bet on the outcome before I ever bet on the output."
The output of Claude Design can be stunning and still not be the thing that turns an idea into a product that works for the people using it. The outcome is what matters. And the outcome depends on someone who knows what they're trying to accomplish and can judge whether the generated work gets them closer.
The tools are getting very good at outputs, and Anthropic just made that harder to ignore. So the work moves up the stack, toward outcomes, problem definition, and the judgment calls a prompt can't make. Knowing what to build, and whether what you got is any good, is still on you.
## Where do we go from here?
Claude Design is a research preview. Features will change, limits will shift, and some of what I described above will break or get reworked before it stabilizes. That's the nature of a Labs release.
But the shape of it is clear enough. A foundation-model company shipped a design product, wired it to its coding agent, and did it a month after its biggest competitor's big release. Those are large moves, and they'll leave a mark on the incumbent tools.
If you're at Figma, Lovable, v0, bolt, or on the Stitch team, you already know this. If you're a designer watching from the outside, the takeaway is simpler. The ground is moving under us faster than anyone expected a year ago. The designers who come out of this well are the ones treating these tools as collaborators for exploration, not threats to their craft.
The craft is still the craft. The tools are just getting a lot more interesting.
---
# [Think first, prompt later](https://konigi.com/articles/think-first-prompt-later)
> Generative coding with AI makes building easy. Building the right thing still takes design thinking. Here's why that matters more, not less, in the age of AI.
## The hard part isn't building it anymore
Generative coding with AI makes building easy. Building the right thing still takes design thinking, and I'd argue it takes more of that now than it used to.
When building gets cheap, execution stops being the bottleneck. The question shifts. It used to be "can we build this?" Now it's "should we build this?", and that one was always the harder question to answer.
AI won't answer it for you. What it will happily do is raise the price of getting the answer wrong. With AI-enabled design tools making it easier to build products, often regurgitating what has already been built, you have to wonder if we're headed in the right direction.
A year ago, building out a full product meant weeks of engineering time. The friction was high enough that you had to think before you built. You couldn't afford not to. Today, with Claude Code, you can go from idea to working prototype in a weekend. That sounds like a superpower, and it is, but only if you know what you're building and why before you start. The tool's speed doesn't make the thinking behind it any better. All it does is expose the difference between good and bad thinking faster than before.
## The app I built too fast
Let's take one of my small failures as a cautionary tale. Last year I had an idea for a DJ profile app. I called it HeyDJ! (heydj.app). I posted a demo video for it here. The concept was straightforward: mobile DJs could have a profile page, list their upcoming events, and each event page could take song requests from guests. I was imagining the DJ at a party, like a wedding for instance, who wants a simple way to manage the night. I know that getting a song list before a wedding is common. I'd also been in situations like school dances where I took requests on the fly. That is super distracting. I could picture the use case to address these needs clearly enough that I felt ready to build.
So I built it. I used Bolt.new at first and it came together quickly. Profile pages, event pages, a song request flow. It looked good. It worked.
Then I did the research I should have done first. The emperor was apparently buck naked.
Services like this already existed. Not one or two, but several, and some of them were well-established. I liked how my app functioned better though. But after a few months, I started feeling like I had overdesigned a tool that I wasn't actually using enough to maintain. And I began to wonder if it was worth the effort and cost, when free tools to do most of this existed—except for my over-designed song list feature.
More surprising was what I found when I actually talked to DJs. Many of them didn't want to use a service for this at all. They had their own much simpler systems. Some had been doing this for years and had it handled. (And with the exception of wedding DJS, a lot of these working DJs just didn't take requests. Lol.)
The problem I thought I was solving wasn't the problem they were sitting with. And I more or less was creating an app of convenience for myself without taking the time to understand the real problems that other working DJs had.
I hadn't built the wrong thing technically. I'd built the wrong thing strategically. I'd built it at speed, which meant I'd invested more time and energy into the wrong direction than I would have if I'd stopped to think before I started. The AI will happily build the wrong thing at three times the speed it used to take.
## What the tax on exploration means
Before AI tools, the expensive part of product design was execution. Exploration was cheap. Sketching is free, talking to a handful of users costs you a few days, and even wireframing barely costs anything. The pricey part was handing something to an engineer and watching weeks evaporate.
Now execution is cheap. An afternoon with Claude Code and you have a working prototype or an MVP. So real exploration is the expensive part now, and the cost isn't dollars. It's the discipline it takes to resist the pull of just starting to build.
*This is a shift some designers are sitting with, whether they've named it or not. There's some fear that AI will replace them eventually. But the current fear is that their value has moved, and they're not sure they know where it went.*
My take is that it moved into the thinking that happens before you open a terminal or prompt screen.
## What thinking first actually looks like
"Think before you build" sounds obvious until you try to do it under pressure with a good idea and a low-friction tool sitting right in front of you.
It means asking who this is for. Not "mobile DJs" but which DJ, at which stage of their career, with which kind of gig. What is the job they're trying to get done? What does their current workflow look like, and where does it break down? What would they have to believe for your solution to be worth switching to?
It means writing down a problem statement before writing a prompt, and articulating a hypothesis: "I believe that \[user] needs \[thing] because \[reason], and I'll know I'm right if \[signal]." Then sketch the [critical user journey](https://www.gainsight.com/essential-guide/product-management-metrics/critical-user-journey/), not as a deliverable but as a thinking tool, so you understand what has to be true before someone ever touches your product, and what has to happen after.
None of this is new. Everything I wrote about early-stage ideation in [Wireframing for Everyone](https://abookapart.com/products/wireframing-for-everyone.html) still applies here, probably more than it ever did. I'm talking about the discipline of sitting with the problem before you solve it, the humility to sketch a bunch of ideas before committing to one, and the willingness to let go of your first draft.
None of that is a quaint artifact of a pre-AI era. Those are the skills that separate the people who ship the right thing from the ones who just ship fast.
## Why I built Klarita
After the heydj experience, I kept thinking about how to make the thinking-first part easier. I didn't want to make it softer or turn it into a shortcut. I wanted it more structured. The reason most people skip it isn't because they're lazy. There are plenty of reasons to skip it. Maybe there isn't time. Maybe there's no reliable place for it in the process, or no format that makes it feel like progress rather than procrastination.
So I built [Klarita](https://klarita.app) to be my design assistant—to walk me through discovery questions, user definition, jobs to be done, a problem statement, a hypothesis, user journey, and light wireframing before touching a prototype tool. This is all the stuff I have in templates that I used to do in a Google Doc or a wiki page. At the end of those steps I have a design brief I can share as a spec with a team or stakeholder. I've used it once now with a client and it's been performing well for me. I keep testing it to see where its usefulness ends, and am still finding some tasks that happen before jumping to design tool or code. The last thing I added is a feature to explore generation of a `claude.md` plan I can drop directly into Claude Code to start building. We'll see how that works.
The design brief isn't a bureaucratic artifact. I've had people direct me to remove my design brief from the project because they were viewed as redundant, only to see the steps that went into that process get re-created anyway. People like to put their stamp on things and word them in their own way. I get it. The important thing is to do the activities that give you the signal that you're building the right thing. So call it whatever you want, just don't skip the step.
If you're building products in an AI tool, here's my warm, not-so-controversial take. You're doing your stakeholder and user a disservice if you're not doing this work. I knew that as a staff designer, but as a self-serving product builder, I forgot to lean on that knowledge. I'm sure you won't make the same mistake.
I'm sure you know that a well-considered, intentional plan can lead to a successful execution of your idea. That's where the brief comes in. It gives your first prompt something specific to work from, and it turns your second iteration into something informed instead of a guess.
If you haven't guessed it, I love pairing with Claude. It is extraordinarily capable, but it's working from the instructions I give it. So I'm building a tool to help me with the building of those instructions, and thus the reason for writing about the experience.
## Something to ponder
If I can leave you with one thought, it's this. The designers who thrive in an AI-assisted world will be the ones who know what their stakeholders and users want before they prompt at all (or what they themselves want, if they're building for themselves). They can articulate the problem clearly enough that the AI becomes a real collaborator rather than a fast way to go sideways. Speed at the keyboard won't be the thing that sets them apart. You're the design director and Claude is your design/development implementer. You have the ability to think critically, to know what's best and to give direction.
I don't know if AI is a threat to designers when you look at it this way. I see it as an argument for their value.