← Voices /

Build First, Ask Questions Later

🎙 hear it in his voice
What does it mean to teams? — Rajesh T's reflection
Unfiltered recording on how LLMs disrupt traditional discovery.

Inspired by real events. Part real, part retelling — the way you'd tell a story to a friend. Names and details may have been changed or interpreted. If this caused any discomfort, we're sorry.

By now, we'd seen what LLMs could do. Especially with code.

A machine could take a few lines of intent and hand you back something that worked. Once that sinks in, you can't un-see it. And the questions start.

What does this actually mean?

The first conclusion was the simplest one. There is going to be a lot of software.

Anytime something becomes easy, you end up with a lot of it. That's just how it goes. And sure enough — Base44, Emergent, a dozen other "describe an app, get an app" platforms. We called that one early. It wasn't a hard call.

But if anybody can build software, a quieter, harder question follows close behind.

If everybody can become a coder — what happens to the existing teams?

Our hypothesis — and remember, this is us talking almost two years ago — was that three things would change.

The composition of the team. The nature of the work. And the way we do the work.

Even now, sitting here in May 2026, we don't know what the end state looks like. But those three things? They're moving. That much we were sure of.

So we asked the next obvious thing: what does that change mean immediately?


First: if anybody can write code — even half-decent code — then everybody will.

The product manager starts building. Maybe just prototypes, but it's still code. The designer ends up coding too. The engineers, obviously, keep coding.

Coding stops being a job title. It becomes something everyone just... does.

Which breaks the org chart.

Product manager. Business analyst. Developer. Frontend. Backend. QA. Designer. That whole assembly line of roles — we think it collapses into something much smaller.

We started calling that smaller thing the Builder.

A team has one or more Builders. Depending on their appetite, a Builder straddles two, three, four of the old roles at once — and partners with AI to cover the rest.


But the biggest change was the one we kept circling back to. If generating code becomes a commodity — do we still need to spend all that time on discovery?

Some context, for anyone who hasn't lived inside a product team.

There are two questions that matter: are we building the right thing? and are we building it right? Discovery was our answer to the first one. Because however well you build the wrong thing, it's still the wrong thing.

So before a project ever kicked off, we'd spend real time on it. The business problem. The outcome. The risks. Even with agile, even with fast feedback loops, the team still needed to know: what are we building, what are we validating, how will we know it's right, and when do we stop?

I've run discoveries that were two or three days — short and intense. I've run discoveries that stretched to a couple of weeks.

Why so much? Because building was expensive. If you built the wrong thing, that was money, time, and people — gone.


Now flip that.

If building a V1 is fast, and close to free — does discovery still need to be a massive exercise?

(The "free" part deserves an asterisk. Right now the LLMs are floating on VC money and are almost certainly subsidised. But play along — assume it's cheap and fast.)

If it is, then you don't agonise upfront. You build the thing a team imagines. You ship a V1. You put it in front of real people and watch what actually happens.

Real usage beats a discovery workshop. Every time.

And you can afford to be wrong. You can have a whole graveyard of abandoned projects, and it doesn't sting the way it used to — because the cost of trying was almost nothing.


That shift has a name now. Earlier we'd have called it a hackathon. We don't anymore.

We call it Dark Mode.

Notifications off. World off. Two to four days of nothing but focus — and at the end, something real comes out. Something the people who asked for it can actually use. Then you look at it, and you decide: keep going, or let it go.

That's a story for another day. It deserves its own telling.


So that was the theory. The composition changes. The work changes. The way we work changes. Discovery shrinks down to one honest question — what do we want to do a V1 on? — and the rest gets dreamed bigger and built faster.

On paper, it's beautiful.

Then we tried to make it real. Inside actual teams, with actual people.

And it turned into a massive fight.

That one's coming.

About the author
Rajesh T is a product leader navigating the messy reality of shifting organizations toward an AI-first mindset. He previously thought AI was just another hype cycle. He was wrong.