Max Danilov

I design and build AI products, mobile apps, and design systems. Built TapeKit. Designed Peech and Haiper. Previously worked with teams like Continental, Bentley, and Blanco. I’ll share notes on product taste, AI UX, interface craft, and the messy parts of making useful apps.

A friend tried to move his Codex setup from one Mac to another. He asked Codex to "move itself." Codex did not really move. But the second Mac ended up with a new user whose password he had not saved, while the account he actually needed was not an administrator. The problem was the request. "Move Codex to the other Mac" sounds like one job. It is several different jobs: 1. Move the repository and its Git state. 2. Move project instructions such as AGENTS.md, .codex/config.toml and .agents/skills. 3. Reinstall Codex and sign in again. 4. Reconnect machine-bound access such as Keychain items, SSH keys, MCP servers, plugins and local tools. Copying a project folder can move the code and project-scoped setup. It does not safely move authentication or macOS permissions. Copying all of ~/.codex is also a bad shortcut because that directory can contain auth, logs, sessions, caches and paths tied to the old machine. A safer sequence: • Leave the old Mac untouched. • Inspect committed, uncommitted, untracked and ignored files. • Move the repository through Git or a verified archive that preserves hidden project files. • Install Codex fresh on the new Mac and sign in again. • Copy only the config, instructions and skills you actually need. • Re-authorize secrets and integrations separately. • Open the project from the correct directory, then run the build and tests. • Retire the old setup only after the new one passes verification. If the goal is to move the entire macOS user, apps and settings, use Migration Assistant. That is a macOS migration, not a Codex task. And never let "move Codex" silently turn into "create macOS users and change admin rights." Prompt to use before the migration: "Help me migrate this Codex workspace from one Mac to another. Do not copy files, create macOS users, change admin rights, delete anything, or move credentials yet. First inventory: 1. Repository state: branch, remotes, uncommitted, untracked and ignored files. 2. Project-scoped setup: AGENTS.md, .codex/config.toml, .agents/skills, hooks and setup scripts. 3. User-scoped setup: config.toml, profile configs, global instructions and personal skills. 4. Machine-bound dependencies: runtimes, CLI tools, MCP servers, plugins, absolute paths, SSH, Keychain and environment variables. For each item, classify it as: move through Git, copy selectively, reinstall, or reauthenticate. Never print or copy secret values. Return a step-by-step plan, verification commands and a rollback point. Stop before any system-level change, deletion, or credential replacement."

The tests can pass while the primary action disappears into the page. Functional tests prove only the behavior they assert. If they do not include visual checks, they do not prove hierarchy, spacing, truncation or how each state reads on the rendered screen. After an agent implements UI, run a separate screenshot review. Use the same viewport, theme, data and state before and after every fix. Paste this into Codex: Review the implemented interface from rendered screenshots. Do not edit code yet. Inputs: - product goal and intended primary action: [paste] - Figma frame, design system or reference images: [attach or link] - target platform and viewports: [list] - themes: [light, dark or both] - required states: [default, loading, empty, error, success, disabled, focused, keyboard open, long content] - areas that must not change: [list] If a reference or required screenshot is missing, report the gap. Do not invent design intent. 1. Run the real interface and capture a baseline screenshot for every required viewport and state. Keep device size, data and theme consistent. 2. Review each screenshot for: - visual hierarchy: name the first three elements the eye notices and compare that order with the product goal - layout: alignment, spacing, safe areas, clipping, overlap and content below the fold - typography: scale, weight, line length, wrapping and truncation - component states: selected, disabled, loading, empty, error and focus visibility - resilience: long text, localization, large text and narrow containers - accessibility visible in the render: contrast, color-only meaning and visible focus 3. Inspect code or the accessibility tree separately for semantic labels, reading order, keyboard behavior and announced state. Do not infer those from pixels alone. 4. Return: - a screenshot inventory - a findings list with screen, state, element, visible evidence, user consequence and severity - severity as blocker, major or minor, with the reason - the smallest proposed fix for each finding - the five fixes with the highest user impact - missing references and unresolved design questions Stop after the report unless the current request explicitly authorizes fixes. If fixes are authorized, change only confirmed findings. Rerun relevant tests, capture the same screenshots again and return before and after evidence plus any remaining uncertainty.

A friend tried to move his Codex setup from one Mac to another. He asked Codex to "move itself." Codex did not really move. But the second Mac ended up with a new user whose password he had not saved, while the account he actually needed was not an administrator. The problem was the request. "Move Codex to the other Mac" sounds like one job. It is several different jobs: 1. Move the repository and its Git state. 2. Move project instructions such as AGENTS.md, .codex/config.toml and .agents/skills. 3. Reinstall Codex and sign in again. 4. Reconnect machine-bound access such as Keychain items, SSH keys, MCP servers, plugins and local tools. Copying a project folder can move the code and project-scoped setup. It does not safely move authentication or macOS permissions. Copying all of ~/.codex is also a bad shortcut because that directory can contain auth, logs, sessions, caches and paths tied to the old machine. A safer sequence: • Leave the old Mac untouched. • Inspect committed, uncommitted, untracked and ignored files. • Move the repository through Git or a verified archive that preserves hidden project files. • Install Codex fresh on the new Mac and sign in again. • Copy only the config, instructions and skills you actually need. • Re-authorize secrets and integrations separately. • Open the project from the correct directory, then run the build and tests. • Retire the old setup only after the new one passes verification. If the goal is to move the entire macOS user, apps and settings, use Migration Assistant. That is a macOS migration, not a Codex task. And never let "move Codex" silently turn into "create macOS users and change admin rights." Prompt to use before the migration: "Help me migrate this Codex workspace from one Mac to another. Do not copy files, create macOS users, change admin rights, delete anything, or move credentials yet. First inventory: 1. Repository state: branch, remotes, uncommitted, untracked and ignored files. 2. Project-scoped setup: AGENTS.md, .codex/config.toml, .agents/skills, hooks and setup scripts. 3. User-scoped setup: config.toml, profile configs, global instructions and personal skills. 4. Machine-bound dependencies: runtimes, CLI tools, MCP servers, plugins, absolute paths, SSH, Keychain and environment variables. For each item, classify it as: move through Git, copy selectively, reinstall, or reauthenticate. Never print or copy secret values. Return a step-by-step plan, verification commands and a rollback point. Stop before any system-level change, deletion, or credential replacement."

A 30-file rename can be a Luna task. A one-line payment change can deserve Sol. Diff size measures output, not uncertainty. Route Codex by the cost of a wrong decision, test quality, and reversibility. Copy this before choosing a model: ```text Risk: Ambiguity: Verification: Reversibility: ```

Palette of the day: Deep Blue + Bright Orange. Great for devtools, sports, logistics, or any product that needs a clean base and obvious calls to action. Blue can carry structure and readability, while orange should stay reserved for the moments that need urgency.

yeah, I’ve been noticing this too lately. it feels like Codex is taking longer to think through some tasks now. in my case, I think it’s because the smarter models run more checks than they used to. so the path from starting a task to actually finishing it has become noticeably longer

Okay, I played with Codex last night for a few hours. It’s great at some things like website design, but when it comes to building systems, backends, and features it can get the job done… but it’s painfully slow. 7 minutes to make one change to an existing feature, while Grok 4.5 does it in 1 minute. I’ve been completely spoiled by Grok’s speed. It’s hard to build with Claude and Codex now unless you go back to the old way: ask, step away, then come back later. That really kills the flow.

@UIbyBiba really interesting process. feels like a very solid way to get to a good result

A lot of people have asked what my process looked like, so here it is. I started by studying the existing Ollin website to understand what worked, what didn’t, and where the experience could be improved. Then I gave the current design to Figma AI Agent and asked: “If you were to redesign Ollin, what would you change and what would it look like?” It came back with a completely different direction. I liked it, it gave me a fresh perspective - but it still wasn’t the vision I had in mind. That’s where being a designer comes in. AI can give you a starting point, but your taste, judgment, and experience are what shape the final product. So I took what it generated, kept the ideas I liked, threw away what I didn’t, and started refining everything myself until I arrived at the final design. Once the visuals were locked in, I moved to Claude. The interactions were already in my head while I was designing. One thing I genuinely love about Claude is that it understands what I’m trying to achieve even when I don’t know the proper development terminology. I’d describe an interaction in plain English, how I wanted a section to move, reveal itself, or respond as users scrolled, and we’d refine it together until it felt right. The entire project took me about 3–4 days, mostly because I kept running into my Claude usage limits. If I had unlimited access and a stronger grasp of frontend terminology, it honestly would’ve taken much less time. This project reminded me that AI doesn’t replace the creative process. It speeds up execution, but the ideas, decisions, and refinements still come from you. That’s the part I enjoy the most.

@nitishkmrk looks super. really cool you got it working on the first try

made this iOS onboarding with single Codex prompt, including the consistent icon images ⎯⟡° prompt in the first reply ↓

@csaba_kissi thanks for the list. was actually about to look for something like this, gonna check these out

Open-source and free apps for coders tracedr.com - Free domain rank tracker apifinder.io - Directory of public APIs onorca.dev - Open-source Agent IDE Claude Code, Codex, OpenCode cssloaders.colorion.co - 99 CSS loaders with ready-to-use AI Prompts reactbits.dev - Open-source React components for creative developers

unfortunately, the most useful design skill for me is still designing the UI in Figma first, then passing it to the agent over a few iterations with Figma links and separate specs, so Codex doesn’t make mistakes. right now, all these skills and UI generation in models still feel like a coin toss. sometimes it comes out right, sometimes it really doesn’t

what are the best design skills for codex that you've used?

@emilkowalski the “does this even need motion” prompt is really good. easy to forget the answer can just be no

Here are a few example prompts that go well with the /find-animation-opportunities skill: Scoped to one view with extra context for more accurate judgement: “Find animation opportunities in the checkout flow. It’s used a few times per session by each customer, factor this in.” Combined with the /improve-animations skill, this works extremely well: “Look through the dashboard UI for places that would benefit from motion, tell me what you'd skip and why, then turn the top suggestion into an improve-animations plan.” Using this as a “shield” instead of trying to find ways to add animations: “Before we add any motion to this dashboard, is there anything here that should animate at all?” Right after an agent builds new UI: “I just generated this settings page and it has zero motion. What should animate and what shouldn’t?”

@BeaverBuilder native modules are the important bit. if Claude writes into the same layout primitives, the page stays editable after the first prompt instead of turning into a dead HTML blob

@kr0der Screen recordings are the useful part. Static screens hide timing, keyboard states, and what happens after a wrong input. AI can copy the surface and still miss the flow completely

i found something super super useful for mobile app builders screensdesign (not sponsored) literally posts the whole onboarding flow of apps making a lot of money and even has a screen recording of it it's useful for studying popular apps and giving UI references to your AI

@as_if_so the squash on hold is a tiny detail, but it changes the control from visual feedback into something you almost feel. smart to reserve maroon for the on-state too

Day 13/45 · Toggle Small control, rebuilt properly: the knob rides a spring and squashes while you hold it, so the press has weight. Maroon is the system's one on-colour, nothing else gets it. One component a day, from an AI-native design system.

@omaralbeik five Apple platforms from one SwiftUI surface sounds great. the part I’d want from this wrapper is keeping playback state and controls consistent without platform conditionals leaking into every view

SwiftVLC 1.0.0 is live 🎉 Our first stable Swift 6 wrapper for libVLC 4, built for SwiftUI across iOS, macOS, tvOS, visionOS, and Mac Catalyst. Thanks to everyone who opened an issue or contributed a PR. github.com/harflabs/Swift…

@iwitaly 10-second copy changes are great. the part I’d care about next is version history, because three live flows get messy fast when analytics and rollback don’t point to the exact flow version

changing one word on your onboarding screen: 1 pr, 1 review, 1 release, 1 app store review, ~2 weeks same change in adapty now: ~10 seconds go.adapty.io/flow-paywall-b…

@AIAdsApps the trust stack and segmentation are reusable. the 75% spin wheel is not. once close reveals that discount, the original price stops feeling real and users learn to close first

This is what it takes to be an App Store "App of the Year" Yazio. Calorie tracker. $4M MRR. 700K downloads - trust stack before any ask - segments users - tap & hold button - cancellation policy - close paywall = spin wheel = 75% off - streaks + weekend reward copy this.

@stevenmerrill The plan handoff is where this works or breaks. are you giving Luna a written artifact from Sol, or the full thread and hoping it reconstructs the decisions?

I've been back in Codex recently: Sol is a talented planner and Luna at high reasoning is a no-nonsense workhorse that can get so much done while sipping usage. I had Luna helping me with SwiftUI work that Sol planned for a new DynamoDB client I've been building last night.

@BigMtnStudio `onAppear` is the easy hook, but prewarming every session there makes optional AI pay the memory cost too early. focus-based prewarm feels safer when the model isn't the first action

❓How do I prewarm a language model in SwiftUI? 💡Call the prewarm function from your session's onAppear modifier to load resources into memory before the user engages with the model. Time it when your app loads, a view loads, or a text field gets focus. 👉Free #SwiftUI picture book at bigmtn.studio