> ## Content Index > Fetch the complete content index at: https://buildcraft.tomfejer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Building, Fast and Slow - URL: https://buildcraft.tomfejer.com/building-fast-and-slow/ - Published: 2026-11-09T21:24:40.000Z - Updated: 2026-11-09T21:32:41.000Z - Description: AI is making software faster to build than ever. As designers gain the freedom to turn ideas into working products without writing code, the real challenge shifts to judgment: knowing what to build, what to leave out, and when to slow down. - Author: Tom Fejer - Tags: Product Design, Design Engineering, Design Process, AI-Assisted Development *How AI is changing the practice of designing software.* About a year ago, I started exploring how AI-assisted workflows could be used to build 3D games. I had no experience with the technology stack, but within a few weeks, and without engineering support, I had working AI agents that could understand and modify both the 3D environment and its gameplay. They could offer contextual recommendations and improve their behavior over time. Previously, I would have spent weeks getting familiar with the technology before being able to explore the actual idea. With AI, I could start building almost immediately. Since then, I've built native iOS and macOS applications, Chrome extensions, and complex web applications with functioning backends, often without writing or even looking at a single line of code. Building software is getting much faster. But as the effort required to build something decreases, I'm increasingly interested in the other side of the process: deciding what deserves to be built, evaluating whether it works for people, and knowing when it's good enough to ship. Borrowing the framing of Daniel Kahneman's *Thinking, Fast and Slow*, I see two complementary modes emerging in how we make software. **Fast building** allows us to explore and experiment with greater freedom. **Slow deciding** gives us room to question assumptions, exercise judgment, and make deliberate decisions about the product we're creating. The faster building becomes, the more important it is to know when to slow down. ## Implementation is no longer the barrier Designers have been working directly with code for decades. I was one of those designers who knew enough about frontend and backend technologies to build prototypes, communicate more effectively with engineers, and occasionally take on implementation tasks myself. For me, the traditional designer-to-engineer handoff had already been changing for years. My journey with AI started relatively small. I used it to create complex regular expressions and mathematical expressions in Origami Studio, then to generate JavaScript patches for custom nodes. Gradually, I moved from solving isolated technical problems to working with AI on entire systems. What makes 2026 a turning point is that this way of working is becoming accessible to almost every designer. **Fluency in programming syntax is no longer the price of entry for building sophisticated software.** Manual coding is becoming an optional method of implementation rather than the default requirement for creating working products. Experienced software engineers are describing the same transition. Ruby on Rails creator David Heinemeier Hansson [argues that the vast majority of code will no longer be written by hand](https://world.hey.com/dhh/over-my-dead-pencil-fb0f3647?ref=buildcraft.tomfejer.com). Microsoft's Jay Parikh [advocates making agents the default](https://commandline.microsoft.com/new-rules-for-builders-agentic-ai-development-jay-parikh-build-2026/?ref=buildcraft.tomfejer.com), with engineers increasingly focused on planning, context, verification, and orchestrating systems. The shift is visible in the design profession too. The [*AI in Design Report 2026*](https://stateofaidesign.com/chapters/craft?ref=buildcraft.tomfejer.com) surveyed 906 designers across more than 60 countries. Half reported shipping AI-generated code to production, despite only 20% identifying as design engineers. The survey may overrepresent early adopters, but it illustrates how widely these capabilities are spreading beyond traditionally technical roles. Understanding software remains essential. Knowing how applications work, how systems and services connect, what technical constraints exist, and how to evaluate the results all matter. I still need a mental model of how the systems I'm building fit together, even when an agent handles the implementation. What's changing is the relationship between technical understanding and technical execution. I can now work with systems that I understand conceptually without first mastering the languages they're written in. For years, that distinction gave technically inclined designers an advantage. AI is making the same freedom available at scale. ## Building is becoming a design medium The rapid progress of AI coding tools has led to plenty of discussion about whether designers still need Figma. I don't find that the most useful question. Different tools and representations help us think about different problems, and I don't see a reason to abandon useful ones. Where I start depends on the project. Some ideas begin with a software specification, others with a visual concept, an interaction problem, or an existing prototype. Figma remains an important part of my workflow, but it's increasingly becoming a design environment for my AI agents as well as for me. Through MCP integrations, I can ask agents to explore an idea based on anything from a vague description to a detailed specification or an existing design. What's changing most is my role in that process. I'm comfortable working directly in Figma, but I can't compete with the speed at which AI agents can generate variations. Increasingly, I direct their work, evaluate alternatives, and provide design critique. I still enjoy getting into the details myself, particularly when refining visual compositions or interaction behaviors, but I no longer need to create every variation manually. None of this makes a working prototype inherently better than a Figma prototype. I still value a good hand-drawn wireframe when that's the right level of fidelity for a discussion. The important question is **what are you trying to learn?** If you're exploring a visual direction, there's little reason to build a functioning application. But when you're evaluating an interaction, experiencing it on the actual device and in its intended context is usually far more informative. Being able to populate an interface with real data and quickly stress-test it has changed how I design. A layout that looks convincing with carefully selected placeholder content can behave very differently with unpredictable data, long text, empty states, or unusual combinations of information. Seeing those problems while designing creates opportunities to improve the experience before implementation decisions become difficult to change. One example came from my upcoming comic-library app, which I've been building with AI agents. While working on its search experience, an inconsistency emerged between the interface and the underlying search behavior. Typing just one character could replace the discovery screen, with its recent searches, with premature results or a misleading empty-results message. Some parts of the application treated that single character as a search query, while others correctly waited for more input. The fix required aligning the search logic and interface state around the same minimum query length, then adding tests to prevent the inconsistency from returning. It's a small detail, but a static search mockup wouldn't have revealed the disagreement between different parts of the application. Working through the actual behavior exposed a problem that crossed the boundaries between interaction design and implementation. Other interactions are even more inseparable from their medium. Touch gestures, haptic feedback, sound, camera-based experiences, and interactions that depend on physical device characteristics can't be fully evaluated through static representations. You need to experience how they behave and feel. John Maeda made an observation in his [2026 talk on product simplicity](https://youtu.be/w6BJ6lXxB0I?ref=buildcraft.tomfejer.com) that resonates with me: making something helps complete a thought, and completing that thought often reveals the next one. That's what I value about prototyping. The process of building helps me discover things I couldn't have anticipated by planning alone. This changes how designers collaborate with engineers as well. I've worked on teams where *handoff* was practically a swear word, and in organizations where formal handoffs became mechanisms for preventing designers from changing anything after a deadline. I've always preferred involving engineers in early ideation and critique, staying involved during implementation, and taking part in QA whenever possible. AI creates more opportunities for that kind of collaboration. Designers can bring functioning experiments into discussions, and engineers can engage with concrete behavior much earlier. Both disciplines can contribute beyond their traditional boundaries. The freedom to move between sketches, visual designs, prototypes, and working software means I can choose the medium based on what I need to learn, rather than what I have the skills or resources to build. ## The difficult part is knowing what's good Generating a convincing interface is becoming easy. Recognizing whether it's genuinely good remains difficult. For me, the distinguishing capabilities are design judgment, empathy for users, and systems thinking. A good designer understands why an interface exists, how it fits into the broader product, and how its behavior affects the people using it. They recognize unnecessary complexity, inconsistent interaction patterns, and solutions that look attractive but fail to address the underlying problem. AI agents can also be confidently wrong. A 2026 study, [*Design Theater*](https://arxiv.org/abs/2607.22928?ref=buildcraft.tomfejer.com), evaluated 120 generated interfaces and found that more than 25% of the design rationales produced by AI tools weren't reflected in their implementations. For functional requirements, that figure rose to 34%. An agent might claim that it has improved accessibility without implementing the keyboard interactions or semantic structure necessary to support that claim. This raises an obvious question about my own workflow. **If I can build applications without looking at their source code, how can I tell whether the implementation is actually good?** Some problems reveal themselves through direct experience. Running the application on its intended device, testing real-world scenarios, deliberately trying unusual inputs, and evaluating interaction behavior can expose issues that an agent's explanation would never reveal. These are activities designers already understand well, and they're becoming even more valuable. Other problems are harder to observe. Security vulnerabilities, architectural mistakes, unreliable background processes, and certain accessibility failures may remain invisible during ordinary interaction testing. These require additional forms of verification: automated tests, accessibility checks, independent code review, logs, and sometimes specialists with deeper technical expertise. Coding agents can help perform these checks, but their assurances need evidence. A passing test is more useful than a confident summary, although it only establishes that the behavior covered by the test meets its assertions. Tests themselves can miss important problems. This is where technical literacy remains essential. I need to understand enough about the systems I'm working with to recognize when an LLM is talking nonsense, where to push harder, and when a technical shortcut might introduce more problems than it solves. Language matters here too. Knowing the right concepts and terminology helps me ask better questions, challenge assumptions, and understand trade-offs. I might not need to read an entire implementation, but I need to know what evidence to request and when the answers deserve skepticism. There's also a difference between producing a demonstration and taking responsibility for something that people will actually use. In her 2026 talk [*Design Will Never Be the Same*](https://youtu.be/na1OyJ3E7Kc?ref=buildcraft.tomfejer.com), Meaghan Choi describes designers contributing directly to production code and taking on responsibilities such as defining quality criteria, understanding engineering trade-offs, and establishing automated guardrails. Greater independence comes with greater accountability. As designers participate more directly in implementation, they also need to take responsibility for the reliability, accessibility, and maintainability of what reaches users. ## Design systems need to express intent One of the limitations of current AI agents is their difficulty understanding the reasoning behind design decisions. Can we make more of that reasoning accessible through our design systems? For decades, we've maintained separate representations of products across design files and production code. I've always seen design files as abstractions of the final experience, valuable because they help us think at different levels of detail. A wireframe can communicate information architecture, a visual composition can establish hierarchy, and a prototype can help evaluate an interaction. If a design file becomes a one-to-one replica of production software, I'd rather spend the effort improving the actual product than maintaining the duplicate. AI is reducing the friction between these representations. Figma's [MCP tools and Code Connect](https://developers.figma.com/docs/figma-mcp-server/?ref=buildcraft.tomfejer.com) help agents understand design files and connect components to their actual implementations. Google's open [DESIGN.md](https://github.com/google-labs-code/design.md?ref=buildcraft.tomfejer.com) initiative explores how design tokens and visual guidance can travel between tools and agents. These developments are useful, but they address only part of the problem. Most design systems describe components, properties, tokens, and visual rules reasonably well. They're much less effective at communicating the reasoning behind interaction decisions. An agent might know exactly which button component to use while misunderstanding which action deserves prominence. It might faithfully apply typography tokens while creating a confusing information hierarchy. It might add explicit affordances everywhere because they're generally considered good for usability, without recognizing when they introduce unnecessary visual clutter. Those decisions depend on context, user expectations, established interaction patterns, and an understanding of the product as a system. I expect today's Markdown files, MCP integrations, and reusable agent skills to evolve into richer systems shared between humans and AI agents. They'll need to express more than what an interface looks like, including its purpose, structure, behavior, and the principles behind its design. The challenge is making design intent accessible without pretending that judgment can be reduced to an exhaustive collection of rules. Good systems should help people and agents make better decisions, including recognizing when an existing pattern isn't appropriate. ## The scarce skill is knowing what not to build Evaluating whether something has been built well is only half the problem. We also need to decide whether it should exist at all. As implementation becomes cheaper, one of the most valuable skills in product development will be **deciding what not to build**. Engineering constraints have historically forced teams to prioritize. Building another feature required time, expertise, and budget. Not every idea could receive the resources necessary to become real. AI is weakening that constraint. Teams can experiment more freely, explore alternatives, and build ideas that previously wouldn't have justified the investment. That creates more opportunities to learn, but also makes it easier to accumulate unnecessary features, interactions, and complexity. Choi describes this as *idea slop*: an abundance of inexpensive ideas and prototypes that haven't necessarily earned their place in a product. A working demo used to signal that someone had invested considerable effort. Today, it might represent an afternoon of prompting. The existence of a prototype tells us very little about whether the underlying idea is worthwhile. This changes how I think about the value of product design. The ability to generate alternatives is useful, but someone still needs to understand what users actually need, distinguish meaningful opportunities from distractions, and curate the experience into something coherent. Sometimes the most valuable design decision is removing a feature, simplifying a workflow, or refusing to introduce another option. ### Building, fast and slow Fast building and slow deciding shouldn't be separate phases of product development. The value comes from moving deliberately between them. We can build an idea quickly to learn whether it works, then spend time interpreting what we've learned. We can generate variations to discover possibilities, then carefully evaluate which direction deserves further attention. We can automate implementation while remaining closely involved in the decisions that shape the experience. This balance may become even more relevant as AI agents begin performing tasks on behalf of users. Maeda connects this to Don Norman's *gulf of execution* and *gulf of evaluation*. When an agent handles the execution, users still need to understand whether the task was completed correctly, what decisions were made, and when they should intervene. In a sense, slow deciding becomes part of the product experience itself. We need to design opportunities for people to evaluate outcomes, exercise control, and make informed decisions without forcing them to inspect every intermediate step. Speed is valuable when the system is acting on our behalf, but it needs to be accompanied by appropriate transparency and control. The same applies to my own practice. Has AI made me a better designer, or simply a more capable builder? Time will tell. I'm deliberately preserving the parts of the creative process I find most fulfilling: refining visual compositions, exploring interaction details, and making the small decisions that determine how an experience feels. I'm happy to delegate repetitive execution, but I don't want to lose the activities through which I develop my judgment. Design expertise grows through practice, failed experiments, technical constraints, criticism, and collaboration. As we automate more of that work, we need to be conscious of preserving the learning that comes from doing it. We have an opportunity to move quickly where speed helps us discover and learn, and deliberately where decisions have lasting consequences. **The most successful teams won't necessarily be the ones that build the most software. They'll be the ones that know what to build, what to leave out, and when to slow down enough to get it right.**