When I recently started coding again with AI-Assisted Development, I did not expect it to bring back memories. But capability changes perspective. And this one surfaced a situation I thought I had already processed.
It was a startup. The kind where everyone sits close enough to overhear each other’s calls and the CTO still replies to Slack at midnight. We were two months into the quarter. The team had a clear direction, a short list of outcomes we were chasing, and enough autonomy to find their own path towards them. From the outside it looked like everything was working the way it was supposed to.
Then a message arrived from the marketing department. A business stakeholder had an idea. A brilliant one, by their own assessment.
What We Had Before That Message
I had spent months shaping a setup where the team did not wait to be told what to build. We were running on OKRs. The commitment was to outcomes, not features. Engineers understood the business problem. They challenged assumptions. They proposed alternatives. When someone came with a solution, the first question was not “how long will this take” but “does this solve the right thing.”
When this works, something changes in the room. People stop protecting their backlog and start protecting their focus. They push back on ideas that distract from the objective, not because they are lazy, but because they understand the cost of losing direction mid-quarter. That kind of culture is slow to build and quick to break.
The Brilliant Idea
I will not pretend the idea was obviously bad. The problem is that no one knew whether it was good or not. There was no data behind it, no connection to the objectives the leadership had agreed to prioritise, no customer insight driving it. There was conviction. Loud conviction. The kind that sounds in meetings like certainty.
My job was to ask the right questions. What problem does this solve for our customers? Where is the evidence? How does this connect to what we committed to this quarter? I asked. I did not get answers. I got pressure. The escalation moved quickly until it reached a level where asking for validation was indistinguishable from blocking progress.
We implemented it production-ready. That was not wrong on its own. What was wrong was the sequence. We spent full production effort on something whose value had never been tested, and by the end of the quarter we had delivered something no one could point to as a win against the original objectives. The team held together. The quarter’s purpose did not.
The brilliant idea turned out to be neither what the business needed nor what we were positioned to validate. I had felt that from the beginning. I had no way to prove it fast enough.
What the Problem Actually Was
For a while I thought the lesson was about stakeholder management. About escalation paths and how to protect the team from top-down pressure. I spent energy thinking about that. It helped a little.
But the real gap was not a process problem. It was a capability problem.
The choice I had in that situation was binary. Push back, and the relationship deteriorates while the escalation happens anyway. Agree, and the quarter is gone. What I needed was a third option. One that could test the idea before anyone had to commit resources to it. One that could make the reality visible in days, not quarters.
To do that, I needed to be able to build fast. And at that point in my career, I could not. The years of moving into leadership had widened the gap between knowing how to architect a solution and being able to write it. I knew what to build. The syntax was gone.
What I Would Do Today
Recently I came back to coding. Not out of nostalgia, but because AI-Assisted Development made the gap between architecture and implementation disappear in a way I had not expected. With Claude Code and a stack I know well, I can take a moderately complex idea from a conversation to a working prototype in a few days. Not something the team built, not something consuming their focus. Something disposable, built for one purpose only: to put the idea in front of a handful of real users and find out whether it solves something they actually care about. That is the question discovery is designed to answer before a single sprint is planned. Is this the right thing to build? Not: did we build it right.
What I did not expect was how quickly this started reframing situations from the past.
When I think about that marketing stakeholder now, I see a different version of the conversation. Not the one where I ask for data I know will not come. Not the one where I agree and watch the quarter collapse. A third one.
Let us prototype it together. This week. You explain the idea, I build a working version, and we look at what it actually does against what you expected it to do.
The stakeholder gets to see their idea tested before it consumes the team’s focus. If the prototype validates the assumption, we have evidence to bring into proper prioritisation. If it does not, the conversation ends based on what we built and ran, not based on whose authority is greater in the room. That is a different kind of pushback. One that does not damage the relationship, because it is not a refusal. It is an answer.
And if the prototype proves the opposite, if real users respond to it and the value is there, then bringing it to the team is no longer a disruption. It is a decision backed by evidence. The team that spent months learning to ask the right questions understands the difference. Conviction is noise. Validated signal is worth stopping for.
A technology leader who can still build has a different kind of conversation with the business. Not a better title or a stronger argument. A working prototype on the table.
I am not writing this to describe what AI can do. I am writing it because I spent years in situations where the choice was always binary, and that is an expensive way to operate.
The capability I was missing then exists now. And when I think about the people leading engineering teams who are still in those situations today, protecting their teams the only way they know how, what I want them to take from this is simple.
Today, I would build the prototype. That is a different conversation from the one I had then.
