Raw voice notes. No script, no editing. Just whatever I'm thinking about.
AI-native design tooling after Claude Design and Google Stitch
0:00
So I was trying Cloud Design, the new feature they have recently launched. It seems like when I was reflecting back on to the tooling they have provided, it's been there, I remember very first, I think was the one which basically launched such tooling which let you interact with your design in more designers. Sort of like preferred way, you can put comments, ask the model to correct it and all that. And on the similar note, I think Google also has done Google Stitch, which basically let you do the same. And it seems like now more design is also kind of like moving into the similar direction. And it feels like maybe the more and more these AI first organizations are going to adapt, this kind of like design interfaces. I have a hunch that the ecosystem of design tooling would look very different from what it used to look like from last decade and so.
1:34
Claude Design as a design surface
0:00
Claude just came up with something called Claude Design, which is basically an idea of giving a design-like surface, similar to how Figma and other popular design tools work, and letting people brainstorm design directions and push directly from there to code. One could wonder that this is already happening inside Claude Code, but in my view what is interesting here is that whenever you work inside Claude Code, it starts writing everything in terms of code and builds on top of that. You don't get a chance as a designer to explore different directions before settling on one, given all the context of the problem. I feel like this is quite an expected step in that direction. Some nice features are that you can bring your own design system if it is hosted somewhere, like GitHub. It has wireframing options and collaboration options for people commenting and sharing. I felt that could be the evolution of Claude Code going toward a design space as well.
1:15
Codex CLI sub-agent patience
0:00
One problem I noticed while using Codex CLI is that it is quite impatient for the sub-agent experience. Whenever I ask it to launch sub-agents in a session and let those sub-agents do the work, in my experience, I've noticed that it's not going to wait for long. What it generally does is constantly check whether the sub-agent has finished working, and when it has not, it basically takes over the task and says it looks like the sub-agent is not working properly, so let me take the task and finish it off. Versus in Claude Code, that experience is much better. I find it more comfortable to launch multiple sub-agents inside Claude Code. They finish their job and return back to the main flow. Whereas that's not the case in Codex, at least up until this point.
1:03
GPT 5.4 and Codex CLI sub-agents
0:00
So I'm using this GPT 5.4 in Codex CLI and I really like that now — given you can also launch sub-agents inside Codex CLI, how powerful this has become. So this morning I had a side project code which was quite bloated I would say, and monolithic as well. I was able to see how well it has organized and restructured the code. So now I'm trying it for some another project and yeah, this has been working pretty well. So I'm very impressed with GPT 5.4.
1:47
AI agents in tmux
0:00
For the last couple of days, I've been doing an experiment — using my AI agents inside tmux. So tmux is basically this terminal multiplexer which splits a given terminal window into different panes. It's really amazing to see how you can leverage the true power of these different AI agents. You can literally launch an individual AI agent in one of those panes and work on a single problem but different parts of it. So let's say one agent takes care of thinking about the UX part, another one thinks about the UI part, and another one can think about something else in the product development pipeline. That's one of the ways — there are so many ways you can do it. As just a UX designer and UI designer, I can also do a git worktree and assign each of these different agents to an individual worktree. Then ask them to produce different UI solutions for the same problem, and share the results with me. I feel like this is a truly powerful way of using different AI agents working on the same problem.
1:42
Why we're drawn to LLMs
0:00
Why don't we really like using LLMs? I was discussing this with one of my colleagues, and we were sharing our points of view, and then post-conversation, I was reflecting back on our conversation, and I had this analogy in my mind. Let's imagine you're talking to an expert about, let's say, the design field, and in the mid-conversation, you basically talk to them about something else. It's going to take time for the person to basically switch context, given they know about the other field as well. But this is where I guess LLMs are very quick to change the context. But I'm not sure when they change the context, how reliable the information they provide about the different field, which maybe I as a human being don't know much about. In conclusion, I feel like these systems thrive because they can produce volume of information at speed which our brain wasn't really there. I feel like this is one of the impressive part about these systems.