The human bottleneck

There's been a lot of talk about finding ways to 10x productivity amongst folks in tech. I've been part of that conversation, trying to identify how I can speed up what I do. This, of course, juxtaposes with my desire to slow down, have deep work sessions, and create space to think.

Candidly, I waffle between these two spectrums on a given day, and some times I just give in to the frenetic nature of how the world has shifted, and I try to maximize Claude sessions and crank out as much as possible before crashing to bed. Other times I want to just throw it all away and pull out my sketch pad to think through a problem thoroughly.

As I, and thousands more like me, have been wrestling through this, we keep coming up against the question of bottlenecks and trying to beat the competition to market. If one part of the product creation equation, such as a product designer, manages to output work faster, what happens along the rest of the chain of development?

We're seeing this play out everywhere. A developer builds with Claude, shipping designers faster, and designers rush to backfill the next features. Then designers start shipping code, and developers are pushed to review that code and try and figure out if it's going to break the whole system and cause security vulnerabilities.

I don't know where all this will settle, but there are a few ways I've been trying to at least make life easier for the engineers around me (and huge kudos to these patient folks spending time to train me up in thinking from engineering first principles).

First, when I'm building out a feature with Claude, I've been slowly learning how to think about frontend functionality against backend connections. I try to figure out how to modify the interface, and then look at what database tables need to be touched as a result. Some projects work more smoothly when an engineer is able to stub out the schema model (which I barely understand) and then I can just ask Claude to build an interface against it—a think I understand very well.

So, as I've been fast stumbling into learning the ways of development, at least from a junior perspective, I've been trying to level up my skills in, well frankly, everything. That's a lot, and part of the reason I've been turning off my phone for much of the weekend once Friday afternoon hits—it's a desperate attempt to slow down and calm my brain after the endless days of extensive effort, sometimes from first waking until closing my eyes; all this while trying to learn as much as possible and bringing these improvements to how I do the work.

The biggest suggestion I've learned, as a designer trying to build with coding agents, is to make sure I understand what's getting built. Yes, it's slower, and yes it requires thinking on a deeper level; but that's what I signed up for as a human creative, and what I like to do. When I use Claude Code to build out a feature, it's important to look at the code output, at least at a high level, to understand what it's doing.

I've found that when I submit pull requests for team members to review, things go much better when I actually understand what I'm submitting, how it all connects together, and how the interface will change as a result. The engineers appreciate it, I appreciate it, and ultimately it gives us the chance to do what we all want—build better products.

The problem, of course, is that's hard. It's hard to slow down, digest what is being done, understand the code, and break solutions into small bites to process in sequence. We want AI to do it all, to just magically solve all the issues.

That tension is a challenge I wrestle with daily. Do I surrender and let the AI do my thinking, or instead pull back, slow down, insert friction into the process, and try to build better products as a result. Myself and many more like me are trying to figure this out on a daily basis.

We want to build products that are interesting and helpful. We want to solve problems, and in solving those problems we love the thrill of all the tiny details that lead toward a solution. So, on a given Monday afternoon, that might mean taking a beat, looking at the code that has been created, and asking myself if it's solving the right problem. Sometimes a five minute detour clicking through a prototype, and getting a feel for it, can save hours of effort down the line.