I Was a “Hold My Beer” Engineer.
Product owner was in the middle of explaining the feature. Before they’re even done talking, the solution is already fully formed in my head.
“Hold my beer, I know what to do.”
Two columns in this table. One new API call. A toggle in those two frontend components.
I’d be halfway through the mental implementation before the first sentence was finished.
I thought that was a superpower. It wasn’t.
What felt like clarity was just my own mental model. Not what was actually needed most of the time. My interpretation. My assumptions. My blind spots - shipped with full confidence.
Alberto Brandolini said it better than I ever could: “It’s your engineer’s understanding that goes to production, not your business knowledge.”
I was that “Hold My Beer” engineer. And I’m not proud of it.
I’m an engineer. I love building things and solving riddles with code.
And yet my favorite thing today is not having to think about implementation at all. It’s a blessing.
Three Versions of the Truth
The business person has one version in their head.
The engineer has another.
The code tells a third story.
Nobody in the room knows this is happening. Everyone thinks they’re aligned. Nobody is.
And now we’re handing this exact problem to AI - which takes whatever specification it’s given, makes its own assumptions about the gaps, and ships. Fast. Confidently. Wrong.
Everyone is celebrating the speed. Nobody is asking “speed towards what, exactly?”
The Moment Backstage
Before going on stage at the Craft Conference in Budapest, Hungary recently, someone asked me what I wanted the audience to take away.
The answer came immediately: focus on the business problem, not the technology.
That didn’t come from nowhere. It came from years of watching the gap between intent and implementation cause real damage. Rework. Missed deadlines. Systems that did exactly what the engineer imagined - and nothing the business actually needed.
Systems that I helped build that way.
Implementation Is a Byproduct
Code can never be the single source of truth. A business person will never go there. So you already have a split the moment you treat the codebase as the definition of what a system does.
The source of truth has to be something everybody can reason about. Engineers, stakeholders, product owners - and now AI agents.
Once that shared understanding exists, implementation becomes almost mechanical. It’s a byproduct of a clear specification. Nothing more. I know many engineers will disagree with me here, and I did once myself. I changed my mind.
Thinking One Step at a Time
When I recently built the backoffice for the Event Modelers platform, I didn’t think about code once. And I so much enjoy not having to talk implementation.
Every system really only does one of three things. Something changes - that’s a state change. Someone needs information, maybe displayed on a screen - that’s a state view. Something happens automatically - that’s an automation.
The actual thinking is about information flow. How does the user get to this screen? What happens after they leave it? Where does this data come from? What triggers this process?
Figuring that out is the important part. Once that map is clear, you define a blueprint architecture - basically a template for how each of those patterns looks in your specific system. “This is how we do things here.”
Then you hand it to an agent. And it handles the rest. Very well.
It’s Not About Writing the Best Code Anymore. It’s About Drawing the Clearest Map.
That’s the shift.
And here’s what you get on the other side of it.
I’m not spending my mental energy on “how will I build this” anymore. I’m spending it on “how do I make this better.” That’s the whole trade. And it’s the best trade I’ve ever made.
The engineers who will matter most in the next five years aren’t the ones who write the fastest code. This skill is gone, outdated - nobody cares. You’ll never beat an agent with this. Why even bother. They’re the ones who can draw a map clear enough that everyone in the room - and every agent in the system - builds the right thing.
I used to jump straight to the solution before the problem was even fully explained.
Now I slow down at the start - so everything after that can move fast.
It’s like sharpening the saw. I spend 80% of my time sharpening.
The implementation is solved. That part is easy now.
The hard part - the human part - is clarity.
Bringing stakeholders, UX, engineers and AI together on eventmodelers.ai. Join us there? Start modeling for free right away, no login required.
Learn Event Modeling from the experts
Join the Event Modeling Hands-On Workshop - learn how to design systems that are honest from the start.
Full Agentic Event Modeling Plattform
AI-Enabled Event Modeling and Code-Generation