I am trying Claude Code on mobile to develop my log app, and it is really great.

There is one minor challenge: how to view localhost on mobile while developing.

Found a solution called Wormkey: https://github.com/max-pantom/worm. Will share more about it as I go.

Update: Installed Wormkey, but it requires the machine to be running 24/7 to work. Skipping it for now.

A PR can either be merged or canceled. That binary outcome means every PR needs to stand on its own.

When changes span multiple screens, a single dependency issue on one screen can block the entire PR from merging, including unrelated changes on other screens that were perfectly fine.

The rule is simple: keep changes screen-specific. If an asset is updated on the profile screen, raise a PR for the profile screen only. The home screen and market screen get their own separate PRs.

This is not about limiting the number of PRs. It is the opposite. Raise as many PRs as needed. More focused PRs move faster, get reviewed more accurately, and can be merged or canceled independently without collateral damage.

• One screen per PR, not one PR for all screens.
• A blocked change should never hold back an unrelated change.
• Functionality dependencies are screen-local, so PRs should be too.
• Do not limit yourself by PR count. Limit yourself by scope.

Everyone is saying Figma is dead. I kind of believed it too. But what is happening in the current workspace is the total opposite.

I assumed the source of truth would be a granular PRD, and that everything else would derive from it. In a startup environment, that is not true. PMs use architecture docs as the source of truth and derive features from there. Getting to granular UX and technical detail from that is still broken.

What is actually happening is Figma is becoming the source of truth. It is the place where UI, UX, Dev, and QA all meet.

• UI: colours and typography are already there.
• UX: you can create flows with prototype mode.
• Dev: MCP integration works well with Claude and Codex.
• QA: they can use Dev Mode to check for UI and UX bugs.

Over the last two days, I have been working on minor UI and UX fixes for the Crpko Web Platform and raising PRs.

One point I missed, and now see as a must, is that every PR needs a proper audit before it moves forward.

Before making any change, even something that looks tiny like updating an icon, it is important to check functionality dependencies.

Small UI changes can look isolated, but they can still affect behavior, user flow, or connected parts of the product in ways that are easy to miss.

• Audit the PR before merging.
• Check what functionality depends on the change.
• Do not assume a visual update is risk-free.
• Treat even icon changes with the same engineering discipline.

Design engineering is getting more interesting as I am working on it. As I am getting deep into it, I am feeling less about losing the value of software developers, and seeing the rise of people who truly take control and think in the perspective of product.

Currently, I am more involved in doing minor edits by Claude mobile and major by Claude desktop and Codex.

One tip from my make-interfaces-feel-better skill is using `font-variant-numeric: tabular-nums` for values that update.

It makes digits equal width, similar to monospace fonts. Keep in mind that some fonts change the appearance of numerals when this is used.

Today, while coming to office, I got a thought. What if I lose this job? What can I say to prove my self-worth?

Then I got the answer: I am doing my 110%. That extra 10% led to a golden path for MVP before the 31st. That 10% led to quick execution of design. That 10% got the design team efforts streamlined. That 10% got me a collective view of what feature we are building and where its source is.

Today, after a small discussion, I am very disappointed by my PM, not because of management, but because he is avoiding the work of writing a detailed PRD. Since he does not want to do it, I have taken the initiative and started doing it myself. Obviously using AI, but it is good to experience engineering and product management in one view.

This week I noticed a significant shift in my process. AI has made shipping faster, so the question moved from "can we ship this" to "what to ship and how to package it within what already exists." That is the new bottleneck.

One level of the answer is a repo of competitor screens with good metadata: what they are doing today, what they are planning next, and eventually user sentiment per feature. So when we build, we work from a valid feature list, not a gut feeling.

I built an MVP for this called AgentUX Catalogue, still in progress. Once the metadata is proper, brainstorming layout and UX gets two things: the catalogue gives data, the AI tool gives choices. It stops being guesswork.

The "new" also needs to be captured, so I am planning a GitHub workflow that fetches raw info on a schedule. More on that later.

Now I am building this. Who manages it? I have 2 people in the team. Shaina is handling graphics, that is set. Praveen is not yet at the mark I am looking for, so I am leading the design direction myself. As I hire, I am looking for someone good at speed. The plan: Praveen takes research, I take either mobile or web, and the new hire handles what is left.

• AI made shipping cheap, so packaging within what exists became the bottleneck.
• The catalogue gives data, the AI tool gives choices. Brainstorming becomes data-backed.
• Team plan: Shaina on graphics, Praveen on research, me on mobile or web, a new fast-executor on what is left.

A special mention I want to make is about a new teammate, Jaswant. He is the one who got me using AI full-fledged, and the one who got me into the GitHub of the organisation. I cannot really capture his impact in a few lines.

Some things I picked up from him that have stuck:

• Using multiple AI tools, not just one.
• Having rules.
• Having a process.
• Keeping a `.md` file for proper logs.

Today I ran 3 whiteboard sessions on a problem I generated from the codebase, given to the first candidate I am hiring for. The problem came out well, and everyone in the room did okay work.

Then I asked OpenAI Codex for the ideal screen for the same problem. I was astonished by the output.

What I took away: design is becoming less about doing it alone and more about how well you can combine tools. Today I experimented with this, did a small improvement test, and started building an app to document all the research I do, the place where the stack lives.

The stack right now:

• Mobbin MCP and Codex Search for researching what other platforms are doing.
• Codex Image Gen for the actual solution-design output.
• Growth.design for the UX rules layer, the piece that is currently missing.

Building the exchange experience for CRPKO surfaced this clearly. Claude Code is great for one half of design and not the other.

It is great for UX: the steps, the motion, how information changes as a flow progresses. Building it in code lets me feel the actual experience: what a tap does, how a number animates, how a screen transitions. Figma cannot fake this honestly.

It is not great for UI: colours, typography, the visual weight that needs taste, not iteration speed. The tints, the type scale, the precise font weight still want Figma's eye-level control.

• UX: steps, motion, information change. Use Claude Code.
• UI: colour, type, weight. Use Figma.
• Stop forcing one tool to do both halves of design.

Following the UX-vs-UI split: even in the AI fast-shipping era, the basics hold. They hold more than ever. Colour systems that scale. Typography that survives every UI change. The stuff Claude Code does not replace.

So my next move is to put the foundation in before the shipping starts. Codify the base (colour rules, type rules, UI/UX laws) into a Skill that AI can consume. AI does not reach for these on its own. If they live in the Skill, they become defaults.

After the foundation: a clear vision on what the product actually is, and a proper understanding of the flow before any of it gets built.

• Basics scale more in the AI era, not less. Colour and typography systems are the anchor.
• Codify UI/UX laws into a Skill. AI does not know them by default.
• Foundation first, product vision second, build third.

Today I taught Bhumika how to prototype with HTML, and she is learning really well. Her ideas are coming along good. But the gap is still there. The prototypes are in HTML, and devs still need Figma as the source of truth to implement from.

Even I fell into this. Since I started design engineering I stopped using Figma for design and kept it only for versioning. But it keeps pulling itself back as the go-to tool for handoff. As a designer I still don't want to work on production directly, so handoff stays on Figma.

So the move I want to make strong tomorrow is to stop fighting it. Use "HTML to Figma", the Figma capture script I documented on /md, to copy the hosted HTML into Figma. Code to Figma. Then use Figma's annotate tool for the dev handoff, and the interaction videos hosted on AgentUX to show the motion. Devs can check the HTML too.

• HTML to prototype the feel. Capture script to bring the code into Figma.
• Figma annotate for the dev handoff layer.
• AgentUX videos for interaction. HTML as the backup reference.
• Don't fight Figma's gravity as source of truth. Bridge into it.

It worked. I used Codex to capture the HTML into Figma, and this time it pulled in all the states, arranged for dev handoff. Not the stripped one-frame import I kept getting before. The full set, laid out for engineering to pick up.

So the flow I have now is three stages: HTML, then Design App playground, then Dev Handoff. HTML and the Design App stay in Claude. The HTML to Figma capture runs on Codex. Figma is back in the flow, but only at the last stage, and only as the artifact engineering reads from. I am not designing in it.

This closes the gap I wrote about yesterday. Devs still want Figma as the source of truth. I still want to design in code. Codex sits in between, and the translation cost goes away. Same loop I have been refining for a year, just with the handoff finally automated.

• HTML for the prototype loop. Claude.
• Design App playground for testing against real data. Claude.
• Figma for dev handoff. Codex captures the HTML in, with all states arranged.
• Claude for design, Codex for handoff. Figma is the artifact, not the medium.

Something shifted yesterday, and it is stronger than before. Product design has evolved for me. When new work comes in, the first question is no longer what is the ideal design. It is what can be shipped right away. The mindset has collapsed into the launch itself.

At Crpko this week the plan follows the same lens: fix what can be fixed, and make the whole product launch-ready with what is already ready. Not a rebuild, not a wishlist. Ship the ready, repair the fixable, and let that be the launch.

• First question on new work: what can ship right away, not what is ideal.
• The design mindset has merged with the launch.
• Crpko this week: fix what is fixable, launch with what is ready.

AI can build UI faster than any of us now. A prompt gets you a screen. So the screen is not where a designer's value sits anymore. The value moves up: to the interactions and the flows. The choices about how an action actually gets completed, and how that path turns into revenue.

That is the part AI does not decide for you. It will render a button, a form, a table. It will not tell you the deposit should confirm before the KYC step, or that an order flow should feel instant even when the fill is not. Redefining how the action completes, and where the money is made, stays with the designer.

So my first move on any new project is not UI. If I start something new, I map the UX flow as HTML first, built from the user's journey. Not screens, the flow: the steps, the states, the order things happen in. HTML because I can feel it, the tap, the transition, how information changes as the flow moves. The flow is the artifact. UI comes after, and by then AI can move fast on it because the hard decisions are already made.

• AI builds UI fast. The screen is no longer where the design value is.
• Value moves up: interactions and flows, how the action completes and how revenue is generated.
• A new project starts with the flow, not the screen.
• Map the journey as HTML first, so you feel the steps and states before any UI.
• Decide the flow, then let AI move fast on the UI on top of it.