Don’t be naked when the agents arrive

“It's only when the tide goes out that you discover who's been swimming naked” - Warren Buffett.

As the tide pulls out on much of coding and knowledge work, what actually matters when building products? If 2026 pans out the way we're all predicting, I suspect a lot of engineers (and product managers!) will find out they've been swimming naked.

Last year, I just so happened to be one of them.

When I switched from engineering to product management I was full of optimism and naivety. Turns out, it was harder than I thought. I was an engineer with good product intuition, but when product became my primary goal, I realized I was an okay product manager with good technical intuition. I think this mirrors what many will face this year, not just PMs, engineers, too.

Linear's CEO, Karri, recently posted about the disappearing middle in product building. So, what does that mean for folks building products? Even if your title isn't changing, what matters for engineers is more and more going to look like what matters for PMs — the outcome.

When I transitioned roles, I needed to entirely shift my mindset and deeply understand what scaling product building beyond myself looked liked — a 180 from being an IC engineer. Success wasn’t coming from executing a list of tasks. I needed to recalibrate on what progress looked like and master the skills that would actually change the outcome - judgment, focus, and clarity.

Ask more of agents

Much of the work that you are used to, that feels the most productive, may not be around much longer. In fact, many of your tasks can probably already be handled by agents.

I felt this acutely. It's pretty weird to go from writing every line of code yourself to directing a team on what to build — and even weirder to do it while watching the world try to automate engineering as a whole.

Early on, I found myself picking up small bugs, reviewing PRs when I had extra time - quick wins that felt productive. Looking back, almost none of this work mattered. In the rush to ship a new feature, I was hill climbing local maxima. How many times did I save a day in exchange for wasting a week of the team's time building the wrong thing?

That isn't to say don’t code — but I found myself not actually making a real dent in what was most critical long term. It’s obvious in retrospect, but activity doesn’t equate to progress. Many engineers are going to run into this, what’s the way to become higher leverage and take advantage of agents at your disposable?

As I transitioned, I was holding onto tasks that felt gratifying and concrete to prevent myself from drowning in uncertainty and ambiguity, figuring out what to do next. That's the thing no one tells you about building products: the "right" next thing is seldom obvious, so that’s where your time really needs to be spent.

Being right and being focused

When agents can implement almost anything, the scarce resource becomes judgment. What should you build?

I learned the hard way that building the wrong things is bitter. I made the wrong calls, spent too long on features that weren't working, and needed to learn to redirect the ship faster. The job isn't to just ship features — you need to solve the right problem for the right person at the right time (2/3 isn't enough).

Engineers now have a real advantage, coding agents provide a preview of where more generic model capabilities are going. That insight is highly valuable when trying to answer the hardest question, is now the right time?

Perhaps most important is to say no to the things that distract from that. Distractions have always been expensive, but I’d wager they’re the most expensive in a world where implementation time continues to dwindle. That’s the only advantage any startup has - its compounding time spent focused.

Crisper context

In order to enable agents (and people!) to enact a product vision, they’ll need clear context. What’s the one core problem that they must solve? What are acceptable edge cases? Who are they building for? And what existing context can they pull to understand the full perspective of their work?

When I first transitioned to being a product manager, I had a lot of ideas and was wary of writing lengthy feature specs — heck, I still am. Yet I constantly found myself surprised when I talked to someone and realized we were on totally different pages on what we were building and why. I learned quickly that if I don’t provide the context directly, everyone will come up with their own.

Incredible writing is an underrated skill for engineers. The process of building may be changing, but writing is still how you gain true clarity. If you can’t write it down, do you actually have a vision? I’d wager no matter how good the agents get, clearly articulating a vision will never be automated: for humans and agents alike.

Low tide is coming. It’s time we learn how good we actually are.