I was never the best developer in the room. Now that's my advantage.
I notice something. And it is polarizing (like everything nowadays).
Agentic engineering works. Really well.
And the people who say it doesn’t? They haven’t tried it. Not properly.
In this post you find out why.
The Silicon Valley problem
I love the HBO series Silicon Valley. If you haven’t seen it and you’re in the creative or tech business, I’d strongly recommend it. Especially because things are so recognizable.
Every character thinks they’re the smartest person in the room. Every developer is convinced their code is art and everyone else’s is garbage.
I’ve seen this my entire career. Developers who look at other people’s code and immediately tear it apart. Freelancers who tell every new client that the previous developer was an idiot. Senior engineers who dismiss any approach that isn’t theirs.
That ego… it was always a problem. But people got away with it. They had a skill that was rare and writing great code was the thing that mattered. People needed them.
Not anymore.
The shift nobody wants to talk about
Developers were the untouchable class of knowledge workers. Until now.
If writing code is your entire identity… if you’ve built your career on being the person who types the fastest and knows the most obscure syntax… this moment is going to hurt.
Because Claude Code and likewise tools are getting really good at that part. The typing part. The syntax part. The “let me write 200 lines of boilerplate” part.
What the tools can’t do (yet)? Think clearly. Define what to build and why. See the bigger picture. Communicate intent in human language.
The stuff developers always called “soft skills” and dismissed? Turns out that’s the hard part.
A confession
I recognize this pattern so well because I’ve been on the other side of it. Because here’s the thing:
I was never the best developer in the room.
I’m good, don’t get me wrong. Solid technical knowledge. But if engineering was a sport… I was never the star player, the champion, the Robin van Persie or Lionel Messi. I played on championship teams. I’m the team player, the nice guy. Looking after my team mates. The one who sees connections between things. Who thinks about the people and the problem, not just the code.
And if I may add 1 superpower. I can explain hard technical topics in a dead simple way. So simple even my mother would understand. That skill was nice to have for years. Now it’s the most valuable thing I bring to the table. (More on that later.)
My solutions? Always a bit more creative than technically perfect. And the real techies… they didn’t always get it. “That’s not how you do it properly.” “The architecture isn’t clean enough.” “That’s not best practice.”
I heard that a lot.
And you know what? Sometimes they were right. Sometimes my code wasn’t the prettiest. But my solutions worked. They solved the actual problem. They just weren’t wrapped in perfect code.
That bothered me for years. Not gonna lie.
Why I see what others don’t
My ideas were always good. (Not always, let me not get too confident here.) But my ability to translate them into perfect code… that was the bottleneck.
And suddenly, that bottleneck is gone.
The person who can describe a problem clearly in human language is now more valuable than the person who writes the fastest for-loop.
The game didn’t just change. It flipped.
And I noticed. Because I’m living it.
The turning point
It all started when I began using agentic engineering properly. Not the “open ChatGPT and YOLO: hope for the best” version. The structured version. With planning, architecture, context and real intention.
In one of my calls with my friend Nick Wouters he mentioned the BMAD method. An open-source AI Agile framework. It gives you a team of AI agents. Not just the architect, developer and QA. But also roles like UX, PM and a scrum master. You name it. Up to 25 of them. They work together through documented stories within your coding project.
But here’s what matters. Not the tool. The process.
I sit down. I have a conversation. In human language. About what I’m building, why it matters, who it’s for. The PM agent interviews me. Calls me by my name. His name is Bob by the way…
Remember that superpower? Turns out describing things in simple human language is exactly what Bob needs from you. Bob challenges my assumptions. Asks about edge cases I forgot. And even then. Every task can be checked by an edge case hunter. You get it right?
An interview with Bob takes about 2 to 3 hours. Walking through your domain and your project before the first sprint. That’s normal. It took me in a complex domain almost 5 hours. Although exceptional, that was totally worth it…
During my first intake I had multiple moments where I really felt some excitement at the level of expertise Bob had.
The process is so well organized. It cuts straight through the hard parts. Asks questions I rarely get from my human colleagues (if you are reading this, no offence guys)…
And the whole time, it keeps me in the lead. I decide.
And once the Developer agent is ready to roll. Story by story. Following the blueprint. It just knows what to do. The stories are there. Adaptable by you. And the code is good. Really good. Solid design patterns. Clean architecture.
My ideas. My creative solutions. My vision and my guidelines for coding standards. Executed by something that writes better code faster than I ever could.
That made me insanely happy.
So why are people still struggling?
Because they skip the boring part.
Two hours of talking to Bob feels slow when you can generate code in seconds. I get it. It feels like wasting time.
And we’re not used to this level of AI yet. Claude Code is good. That’s enough for 99% apparently. But “good enough” is still a reason to stay mediocre instead of discovering what it can actually do.
Here’s what those hours give you. Context. For every single task. Not a vague prompt. Not half a Slack message as a requirement. A specification that knows what came before, what connects to what, and what’s out of scope.
We’ve been preaching this in agile for 20 years. Slow down. Plan. Communicate. Document your decisions. And most teams still don’t do it. (How many sprints have you run where the only documentation was a Jira title? Exactly.)
BMAD just… does it. Automatically. In hours instead of weeks of alignment meetings.
And even with those hours upfront, you’re still way faster than the old way. Two hours of planning plus an hour of building beats two weeks of coding, debugging, refactoring, and arguing about what was supposed to happen.
Slower is faster. We always said it. Now it’s actually true.
Start here
You don’t need BMAD. You don’t need any framework. You need one habit.
This is what I do. Every single time.
Before your next AI coding session, write down three things:
What am I building? (One paragraph. Not a novel.)
How should it connect to what already exists?
What does “done” look like? (Be specific.)
Put that in a markdown file. Give it to your agent as context. Compare the output to your last session without a spec.
If you want the full system… BMAD is open-source, installs in one command. I use it daily. I love it. But the tool is secondary.
The mindset is everything.
Accept that AI is the future. Then think first. Architect second. Let the agent build third.
What about you?
Are you planning first? Or prompting and hoping? Or keep doing things yourself?
And honestly… is ego getting in the way?
I’d love to hear.