15 korrents from this recording
Every claim below is a statement made in this recording, quoted word for word and linked to the second it was said, so you can hear it rather than take our word for it. The wording comes from the transcript published alongside the recording; the sentence above each quote is our reading of the claim, not their wording.
Their wordsThey're pretty lightweight. They're not super specific in terms of like exact execution or anything. They're higher level principles. But because these live in the repo here alongside the prototypes, the agent can reference them in this way to be able to use them as a tool for design
Their wordsdoing that kind of work in like a static environment detached from the code was always way harder than it probably needed to be because you're think trying to think through like a ton of different combinations of states that are just hard to gro until you actually get something in some form of code to be able to understand whether your your idea even makes any sense at all
Their wordsI would be probably having it before it actually generates any UI here at all. I would just have it describe these potential approaches to me in text and I would review it that way because it would be quicker for me to gro like that seems directionally right, that seems directionally wrong
Their wordsI didn't want to mislead people by creating something that was like almost production fidelity but not actually production fidelity. and then I end up with this big communication gap of like people looking at something very high fidelity but it's not quite right and so they misinterpret
Their wordseven my workflow has changed so much just since the agentic coding harnesses released this ability to just directly give specific feedback on elements. That was a huge unlock
Their wordsI cannot assume that the human user will be doing any of it. it's always the agent doing stuff on their behalf
Their wordsif you are working on something that is going to impact other people's work, that requires a higher level of review and more of a typical kind of dev workflow where we want to make sure that what you push isn't going to break stuff for other people. So my rule is you can you can break your own stuff, but you can't break other people's stuff
Their wordsI'm no longer really handing off designs just to an engineer. I am pretty much preparing the design to be reinterpreted by the engineer's agent
Their wordsthe agent can do it. It doesn't care. They're incredibly good translators. So if you just think of like production as one language of code that has its own set of constraints and semantics that are necessary for like a production app at scale
Their wordsmany of those conventions don't serve the design process because they do things that intentionally make it hard for like the app to break, which you want in production, but you don't necessarily want in in prototype land
Their wordsthere's so many different ways to get value from prototyping. I think when people hear prototyping, they jump immediately to highfidelity prototyping. And that's definitely not the way that I think about it or approach it
Their wordsI think for a lot of teams even just starting there or just getting your sort of centralizing your prototyping efforts so that you can start to build on your team's work like as a collective is a huge benefit
Their wordsyour team might look very different and like your process as you sort of discover your little tensions, you just work through them. It's a product design problem to solve, you know?
Their wordsin order to design the end thing that I'm aiming at, I needed to design this tool and then that tool facilitated the like the work. And I'm noticing that more and more with more designers workflow
Their wordsI think once you start to look at like what's possible in this environment, it starts to become more clear like the the b the benefits of giving yourself just enough distance. This would never go into our production like even close to our production product codebase, right?