But recently, I’ve been working on a project where the team uses a lot of AI and the domain is very complex, so I’ve reluctantly been using it to help me understand what is happening in the app and how changes I make affect areas of the app I didn’t even know existed. As I get more and more comfortable turning to Cursor to help me get unstuck in my code, I do not like what is happening to my brain.

I keep knitting near my desk so I have a way to keep my hands busy in meetings and I’ve been picking it up while waiting for a response from Cursor sometimes. I’m currently working on a pretty complicated sweater pattern with minimal instructions that are hard to interpret. I recently stepped back to look at my work and saw the pattern had gotten wonky a few rows back and realized my first instinct was to turn to AI. This horrified me.

The whole reason I enjoy knitting is the process. I spend dozens of hours and more money than I’d like to admit on yarn to create a sweater that sometimes looks no better than a $20 one I could have gotten on Amazon. But that’s not the point! I enjoy knitting. I like using my brain and my hands and figuring out solutions to problems. It feels amazing to respond to “I like your sweater” with “THANKS I MADE IT ALL BY MYSELF”. Turning to AI when I encounter a bump in the road is the opposite of that. And to be totally honest, I have tried asking ChatGPT for help on projects before and it didn’t help at all. So why did I find myself reaching for AI to fix my sweater?

Apparently, I can’t isolate the way I solve problems at work from the rest of my life. Even if I can justify using it on my work project (a big if), I’m not a character in Severance. What I do at work affects my whole brain. Getting into the habit of handing AI tedious tasks and asking it to explain things I’m not familiar with instead of trying to figure them out myself seems to have decreased how much work I’m willing to put into hard things outside of work. How far will it creep into my life? When does asking Cursor to pass the right props into the right React components turn into outsourcing talking to my kids to ChatGPT?

I don’t have the answers to any of this, but I can be proud of something: my first instinct was to ask ChatGPT to fix my knitting, but I didn’t stop there. I paused, thought about how ChatGPT would approach the problem and how I would approach it, and decided that it was worth struggling through on my own. AI hasn’t ruined my brain yet, but I’m going to keep checking to make sure.

On October 21, we’ll be gathering at Badger & Co for an informal evening with fellow technology leaders from across Edinburgh and the wider Scottish tech community.

If you’re leading or building technology teams, working across product or engineering, or simply want to meet more people in the local tech community, we’d love to have you join us.

Join us in Edinburgh

• Date: October 21, 2026
• Location: Badger & Co, The Courtyard.
• Sign up: https://luma.com/rbilas03

We hope to see you there!

Specifically the fourth message in a thread about whether a card’s inner spacing was 16px or 20px. I have had some version of that conversation on every project I have worked on, along with the ones about type scale, and border radius, and which grey. All of them cost a lot of time, for designers and developers both.

We make those decisions in design. They get translated in code, and translation is where they go missing. I wanted to carry one all the way through, so I decided to explore React.

Early in the docs there is a page called “Thinking in React”. I opened it braced to be lost, and spent most of it recognising things. It lays out five steps for turning a design into working code. Three described work I already do. The other two were new, and those two are most of what I have to say.

Three of the five were already the job

The docs open by telling you to break the interface into a hierarchy of components. Decide what’s a component, what nests inside what, where the line falls between a card and the list it sits in.

That’s the layers panel. I have been doing it for years and calling it organising my layers.

Then they tell you to build a static version first. No data, no behaviour, everything hard-coded, and resist adding interactivity until the static version holds up. That’s the Figma file. Designers get that discipline for free, because the canvas puts that constraint on us.

Here’s the part that actually stopped me. I have a button in our library with three properties. Size, state, and a switch for the leading icon. Set those three and you get the button you need. Turns out that is what a component’s props are. I had been building those for years, knowing someone else would pick them up and use them.

Some of that overlap is deliberate. Figma’s slots, the areas inside a component you can fill without detaching the instance, are the same idea as children in React.

However, what escaped me was the cost. On the canvas, adding a fourth property is one more frame. In code it multiplies against everything already there, and someone has to hold that arithmetic in their head every time they touch the file. That’s why the answer to “can we just add one more variant” is slower than it looks from my side.

The canvas has no time

There’s a page in most of my files where I start building my components, and it is mostly just states. Default, hover, loading, empty, error. All side by side, all equally true, none of them in each other’s way.

That’s the canvas doing what it does. There’s no time on the canvas and no data, so nothing ever has to be responsible for anything. Everything is simply true, forever, all at once.

I have found that React can’t do that. It shows one thing at a time, and something has to decide which. So it made me ask myself something about that page I had never had to ask. Which of these are real, and which ones are just what happens when something else is true?

Our empty state is the results list with nothing in it. If I let it become its own thing in code, I have built a second way for it to be empty, plus a bug for the day the two disagree. Loading is real, and it belongs somewhere else again, with whatever is doing the fetching.

Then comes the part with no canvas equivalent at all. Once you know what the real states are, something has to own them, and the owner sits above whatever you’re looking at.

Take a filter panel and a results list. On my canvas they’re siblings, sitting side by side, neither one inside the other. So when someone picks a filter, where does that choice live? The list needs it as much as the panel does, so it moves up to the nearest thing holding them both, and gets handed back down to each.

That has a name. Lifting state up. The vocabulary was new, and the instinct is one designers already have, because it’s the argument we have about tokens every time someone hardcodes a hex. One owner, everything else pointing at it.

Which, it turned out, is also the padding thread. That argument happens because the number lives in two places, my file and their code, with neither one pointing at the other, so both stay true until somebody notices they disagree. Dabbling in React made me ask who owns this often enough that I started asking it about my own files.

Thinking it isn’t writing it

The title of this post only goes so far, and this is where it runs out. I can look at a screen now and work out the hierarchy, sort the real states from the ones I drew, and tell you roughly where that filter choice needs to live. Then I open an empty file and none of it types itself.

The styling I can handle. That’s the CSS talking, and it’s the part that carries over most cleanly, though I gather it stops carrying the moment I get to React Native, where there’s no cascade and styles are just objects sitting on the component. Everything else is a skill I am still paying for. The syntax, the hooks, the six ways to do one thing and the opinion my codebase has about which one.

So should you learn it?

If you want to build what you design, then yes, and you are starting further along than the docs assume. The component thinking is already yours. What you are buying is the part about time, which the canvas never asked you to think about, and then writing the code itself.

That half shows up in real work more than it sounds like it would. When developers plan a build, one of the first things they settle is which parts of a screen are real and which fall out of something else, which is step three of that docs page happening in a meeting instead of a tutorial. I watched two experienced developers do it on a call recently, taking a design apart into components and deciding where each part got its value from.

You can run the same pass on your own work today. The react.dev page runs in the browser with editable examples, so there is nothing to install, and it builds one small thing across the five steps. Read it with a few of your own screens open beside it. Take one you have drawn several versions of, the empty one, the loading one, the error one, and ask the same question of it.

Our meetups are informal evenings for engineering, product, and technology leaders to network, exchange ideas, and have useful conversations over drinks and snacks. No panels, no presentations, and no formal agenda. Just a good group of people working in tech getting together in the same room.

Whether you’ve joined us before or have been meaning to come along, we’d love to see you at one of our upcoming events.

September

• Date: September 14, 2026
• Location: The Lamb, London
• Sign up: https://luma.com/gwkly12d

October

• Date: October 19, 2026
• Location: The Lamb, Empire Room, London
• Sign up: https://luma.com/ti7wbjui

November

We’ll wrap up the autumn series at Founder’s Arms.

• Date: November 5, 2026
• Location: Founder’s Arms, London
• Sign up: https://luma.com/myp6spnr

Join us

Come by, grab a drink, meet some new people, and join the conversation.

Spaces are limited, so register for the meetup that works best for you. We hope to see you there!