One of my main struggles in the past year:
I’m expected to mentor my engineers and help them adopt AI more effectively. But I first need to get better at it myself…
This became much easier since my company integrated Weave. It gives you (and your engineers) visibility into their work process: prompt quality, one-shot success, code quality, and skills+tools usage.
So instead of a vague ‘we need to be more effective’, you can see exactly where your team can improve.
I became a ‘co-founder & CTO’ 18 months ago. There were 2 of us - me and my childhood friend, who was the CEO.
The first month was amazing. We had a clear vision and lots of energy - I was responsible for building, and he for getting our first customers.
In the second month, the arguments started. He couldn’t understand why I was so slow in a world with LLMs. He wanted to push features into production from his phone, without reading any of the code. “If we have a bug, I’ll just tell the agents to fix it”.
I felt we’d be building a house of cards that would collapse the moment a real client used it.
The arguments turned into fights, and 7 months later we finally split up, with zero paying customers and a barely working product.
He was a builder, and I was a keeper.
It’s the same fight our whole industry is having right now.
The software engineering war
This is not a new war. For 15 years in tech, I heard the same argument again and again: “Let’s just ship it quick and dirty” vs “We need to build things properly”. It was mostly PMs vs engineers, but sometimes also PMs vs PMs and often devs vs devs.
Somewhere in 2023-4, the fight started to escalate. The builders discovered guns:
Even inside software teams there is conflict. In my team of 6, there is an even split:
On one side, you have the builders. Those are the engineers who get their dopamine hits from customers and the usage of the product they build. They won’t miss typing code by hand. A refactor without any customer impact doesn’t excite them. They’ll prefer to dogfood their product to reading technical articles.
The extreme ones are saying:
LLMs will generate 100% of code
Code is obsolete. You won’t need to read it soon
The idea is all that matters
Software engineers without product orientation are doomed
On the other side, you have the keepers. Those are the engineers who enjoy writing well-built systems, purely for the technical challenge. They hate sloppy code. Every time they work in an area, they’ll do some small refactors to make it better. They’ll always want the most technically complex task to challenge themselves.
They are the ones saying:
The models will always produce shitty results
If you won’t read the code, disaster will happen
Vibe coders will ruin their companies
There is no clear division, but every single person reading this leans a bit more toward one side.
3 weeks ago I wrote an article about the “I don’t know, Claude wrote this” pandemic. It went viral on Reddit, with a heated debate:
A popular comment mentioned an intern who dared to question why understanding the code even mattered anymore:
And of course, the replies were brutal:
I carefully wrote my take (didn’t want a wave of hate): this intern could be a great builder. Surprisingly, the OP agreed:
I want to expand a bit on that ‘balanced perspective’ part the original poster mentioned (“I hope I can guide them towards a more balanced perspective of strong engineering vs getting business results”)
It depends who you're standing next to
In politics, 90% of people lean either left or right. When you meet someone holding an ‘opposite’ view, and you start a conversation about politics, most likely you’ll both end up frustrated and angry. “How come they don’t get it??”
But what happens when you meet someone from the “same side”, but much more extreme than you? Suddenly, they might label YOU as the ‘wrong’ side, because your opinions are not extreme enough.
So your political orientation is not just about your opinions, but where they land in relation to others.
I feel the same in the builders vs keepers war. With my co-founder, I was very much a ‘keeper’. It’s probably the same for all engineers - when you talk without non-engineers, you are representing ‘the keeper’ mindset, and the importance and difficulty of creating production-ready systems.
But inside my team, I’m much closer to the builder side. I haven’t typed a line of code in a few months, and I get my dopamine from business impact and not well-written code.
That's your position in a given room. The second thing that moves is your position over time:
Re-evaluating your opinions
Like with politics, the people I respect the most are the ones who CAN change their opinion with time, and not be ashamed to admit they were wrong (which DOESN’T mean switching to the ‘other’ side)
David Heinemeier Hansson is a great example. For those unfamiliar:
Creator of Ruby on Rails
CTO of Basecamp ($250M+ ARR, privately held by him and the CTO)
Author of Rework and It Doesn’t Have to be Crazy at Work (both books I really enjoyed)
Exactly a year ago, he said on a Lex Fridman episode:
…One of the reasons I don’t enjoy that way of writing is, I can literally feel competence draining out of my fingers. … I have to do the typing myself because you learn with your fingers. If you’re learning how to play the guitar, you can watch as many YouTube videos as you want, you’re not going to learn the guitar. You have to put your fingers on the strings to actually learn the motions. I think there is a parallel here to programming, where programming has to be learned in part by the actual typing.
DHH
Then 6 months later, he tweeted:
Just last summer, I spoke with Lex Fridman about not letting AI write any code directly, but it turns out part of this resistance was simply based on the models not being good enough at the time! I spent more time rewriting what it wrote, than if I’d done it from scratch. That has now flipped.
But I’m not talking only about ‘keepers who admit LLMs are somewhat good’. Most non-technical builders I know start very optimistic, but slowly learn the complexities of writing software, and why you can’t just vibe code a complex production system.
I really appreciate hearing some of them admit they were wrong, and adopt a more sensible and pragmatic approach.
The extremes are the worst place to be:
The builder who vibe-codes a critical production system (without reading any line), and the keeper who refuses to write a single line with an LLM even in 2026 - both of them are stuck with outdated opinions, refusing to admit there is a bit of truth to the other side.
18 months later
I left after 8 months, but my non-technical co-founder is still at it. He’s building it all by himself, and has some paying customers. Even if I purely vibe coded like him, his results are MUCH more impressive than what I could have achieved (product-wise), mainly because he refuses to give up.
In hindsight, of course I would have behaved differently. Neither of us was 100% right, but I could have been a bit more flexible at the ‘we have ZERO customers so far’ stage.
My favorite reads of the week
Please stop the AI confidence theater. Really loved that one:
“I started asking a simple question whenever someone told me AI had changed their life: ‘Cool. Show me.’And most of the time I see some basic workflows. Summarizing Slack. Answering emails. Doing scheduled scans. Performing research and booking something. Sending emails out of Claude. Okay…. it’s useful. But show me something that has become so critical in your day that if I took it away tomorrow, your work would actually fall apart. Show me something truly life-changing.
It turns out that’s a super short list.”
The Best Business School You’ve Never Attended - “There’s a business school hiding in plain sight. You probably walked past it last night on your way to dinner.”
Loved that one. (And if you love books, Unreasonable Hospitality is a great one on the topic!)We used context engineering to 5x conversion and 2x activation
