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 three 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 building 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 fast. From the stakeholder to the VP of Engineering. From the VP to the CTO. Then to the CEO, who trusted the idea completely. By the time it reached that level, asking for validation was indistinguishable from blocking progress. The conversation had moved from “should we do this” to “how quickly can we start.”
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 the cost of that mismatch became visible only after it was too late to change the approach.
What It Cost
We lost the quarter. Not dramatically. The system did not break. The delivery happened. But the outcomes the team had been building towards for three months never arrived. Focus shifted, momentum dissolved, and by the end of the quarter we had delivered something no one could point to as a win against the original objectives.
The harder loss was what happened to the team. Engineers who had started asking the right questions went quiet. The product manager stopped pushing back on assumptions. The confidence that had taken months to build took one forced pivot to damage. People started waiting for direction again instead of proposing it.
The brilliant idea turned out to be neither ready for production nor what the business actually needed. 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. I have written about this experience separately. The short version is that I felt productive again in a way I had not since I was leading a team of eight engineers, except now I was doing it alone, in a fraction of the time.
What I did not expect was how quickly this started reframing problems 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.
With Claude Code and the right stack, I can now take a moderately complex idea from description to a working prototype in a few days. Not polished. Not production-ready. But real enough to answer the only question that matters at that stage: does this work the way you think it does?
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.
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 changes everything downstream from it.
