• The author, a designer at Jane Street, now primarily uses Claude Code rather than Figma to design and prototype new features.
• Instead of creating traditional spec documents, Figma mockups, and proposals, the new workflow involves writing a problem description, opening an editor, and using Claude to build an interactive prototype inside the actual codebase.
• Building high-fidelity prototypes directly in the medium (e.g., using OCaml and Bonsai at Jane Street) eliminates intermediary artifacts and allows the author to quickly iterate on minute details like keyboard shortcuts, copy, and button refinement.
• This approach makes evaluating concepts much easier for stakeholders, as they can interact with a live tool rather than static frames, which is particularly valuable when testing the feasibility of complex features like internal LLM integration.
• A key shift in their model happened over the course of a few months as improved models, growing prompting familiarity, and proper scoping allowed for handling large-scale diffs (exceeding 2,000 lines).
• A major workflow challenge is how engineering teammates handle code reviews for fully baked features; the current solution treats the prototypes like "code mockups" that engineers can iterate on or reference to write the official production code.
• The author expresses concern that relying on Claude might stifle fluid, out-of-the-box creativity, locking them into an incremental, iterative mindset constrained by what they expect the LLM can easily generate.

Hacker News Discussion

• The Shift from Static Design to Working Prototypes: Many users echoed the author's sentiment, noting that the traditional reliance on Figma for initial product concepts is declining. Teams increasingly prefer building quick, functional wireframes in dev environments that stakeholders can actually interact with.
• Organizational Friction and "Vibe Coding" Pressure: A prominent topic of discussion was the tension this workflow introduces with management and business teams. When non-technical stakeholders or designers build a working prototype quickly using AI ("vibe coding"), leadership often pressures engineers to push it directly to production without understanding the need for refactoring, architecture, and handling edge cases.
• Loss of Deep Design Thinking: Some commenters argued that outsourcing early-stage creation to an LLM removes a crucial phase of critical thinking. Because the AI automatically paints over gaps or details in a prompt, team members stop asking foundational questions ("how should we communicate this idea?" or "what happens when..."), leaving critical logic gaps to be fixed much later.
• Homogenized and "Safe" Aesthetics: Users iterating with text-to-UI tools noted that the default visual output tends to adhere strongly to contemporary web tropes, resulting in boilerplate or generic Tailwind/Bootstrap-style layouts unless heavily prompted with highly specific design rules or unconventional examples.
• The Long Tail of Accountability: Engineers emphasized that while AI dramatically speeds up the initial prototyping loop, it does not replace the necessity for engineering discipline. The long-term ownership of operational risk, system maintenance, edge-case mitigation, and on-call accountability still relies entirely on human experts.

This reframes the AI interaction problem: instead of AI being a destination users navigate TO, AI should come TO the user's context. This 'ambient AI' design philosophy is the opposite of the chatbox paradigm that's dominated for 3 years.

大多数人认为增加对AI代理的支持会使工具变得复杂，降低人类用户体验。但作者认为，为AI代理添加的功能实际上没有损害人类用户体验，反而通过增加'第二扇门'（非交互式接口）同时改善了两种用户群体的体验。

大多数人认为为AI代理设计工具会使其对人类用户更加复杂或难以使用，但作者认为为AI代理设计工具实际上改善了所有用户的体验。因为代理的约束（如需要明确的参数、避免隐式状态）恰好使工具更加模块化、可脚本化和可测试，这对人类开发者同样有益。

大多数人认为增加机器可读的接口（如标志、JSON配置）会降低工具对人类的友好度。但作者认为，这些为AI代理设计的特性实际上改善了人类用户体验，因为它们使工具更加明确、可预测和可组合，而不是让工具变得更复杂。

大多数人认为设计AI代理工具会专门针对机器，可能会牺牲人类用户体验。但作者认为，为AI代理设计工具反而能提升所有用户的体验，因为代理带来的约束条件（如明确的状态管理、可预测的接口）同样让工具对人类开发者更加友好和可脚本化。