The Lazy Bulldozer's Guide to AI
Not the lazy that avoids work. The lazy that refuses to do the same work twice.
The best idea I ever had for a product came while I was in the bathroom.
Not in a meeting. Not on a whiteboard. Not during a brainstorming session where someone writes ideas on sticky notes and puts them on a wall.
I was just... not thinking. And then it was there.
I think most builders know this feeling. The idea never comes when you are forcing it. It comes when your brain finally has a moment to breathe. The problem is, my brain rarely gets that moment. Because I am a bulldozer.
This is part of a book I’m writing in public.
Subscribe to read the rest as it comes
I don’t mean I’m aggressive. I mean I just do things. If something needs to be built, I build it. If something is broken, I fix it. If nobody is moving, I move. I’ve been doing this for 30 years and the pattern has never changed. See the problem, do the work, ship it, move to the next one.
This works. I have built platforms, turned around failing products, led teams from zero to production. The bulldozer gets things done.
But after 30 years of pushing, someone might ask — are you burned out?
Honestly? Maybe. But I refuse to admit it. Or maybe I don’t refuse — maybe I just enjoy the pain a little. There is a word for that but let’s not go there.
The point is — even a masochist eventually thinks: what if I could get the same result without bleeding every time? Not because I want to stop. Because after doing this long enough, you start to see patterns. You know which walls actually need pushing and which ones you can just walk around.
That’s where the lazy part comes in. And that’s where AI changed everything.
People who work with me might be surprised to hear this. But I am lazy.
Not the kind of lazy that avoids work. The kind of lazy that hates doing the same work twice. If I built something once and I have to build it again from scratch — that first time was a failure. Not because the product was bad, but because I didn’t make it reusable.
This is not something I learned from a book. This is 30 years of building software telling me one thing over and over: build it once, reuse it everywhere.
Backend first. Always. I know everyone wants the shiny frontend — the demo that makes the sales team happy, the screen that the CEO can show on stage. But if you build the frontend without the backend, without the back-office, without the tools your support team needs to debug at 2 AM — you are not building a product. You are building a demo with technical debt hiding behind it.
Nobody talks about this part. The app support engineer who has to connect directly to the database client because there is no admin panel. The operations team copy-pasting data between systems because nobody built the API. That is not a small problem. That is the thing that kills products slowly after the launch party is over.
So yes, I am lazy. I refuse to build things that will create more work later. I refuse to skip the boring parts just to ship faster. I would rather sleep well knowing the foundation is right than ship a week early knowing someone will pay for it later.
And the good ideas? They come from this laziness too. When your brain is trained to always ask “how do I do this only once?” — the answers show up in strange places. In the shower. Walking to get coffee. In the bathroom.
The lazy mind is always designing, even when it looks like it is doing nothing.
I have been the fastest person on my team for most of my career. Not bragging. It is just what happens when you have been building for 30 years and you know where the shortcuts are.
Then I started working with AI. And for the first time, something kept up.
But not the way most people think. I didn’t just type a prompt and get code back. That is like saying you had a conversation with someone when all you did was shout an order at them.
What I actually do is this: discuss. That’s it. Discuss first, coding later. Discuss is probably the most frequent word I use with AI.
I take everything I know about a problem. PDFs, research, articles, domain knowledge from years of experience. I put it all on the table. Then we discuss. Not prompt. Discuss. Like a colleague who reads fast, remembers everything, and never gets tired of my questions.
The first round is never right. Sometimes the second is not right either. But somewhere around the third or fourth round, something lands. An idea connects to another idea in a way I didn’t expect. A product shape starts to appear. Not because AI invented it. Because the discussion pulled it out of what was already in my head but hadn’t found its form yet.
And sometimes it is the opposite. My brain is completely blank. I know what the system should do but I cannot see what it should look like. I describe the function, the flow, the constraints. And AI cracks the UI in ways I would not have reached on my own. The bulldozer knows the engine. The algorithm helps design the dashboard.
That is the part nobody tells you about AI. Sometimes it finds what you already know. Sometimes it fills in what you don’t. Either way. Discuss first, coding later.
Once the idea lands, things move fast. AI generates a prototype, a boilerplate, a playground. Something I can touch, break, reshape. Something I can show to people tomorrow instead of explaining with slides for three weeks.
And this is where the bulldozer met the algorithm. The bulldozer always had the instinct. The algorithm gave it speed without the bleeding.
So here is what I have learned. Not from a course. Not from a framework someone sold on LinkedIn. From doing this every day for the past two years and seeing what actually works.
Discuss before you build. I said this already but it deserves its own rule. The biggest waste in software is building the wrong thing fast. AI makes it easy to build fast. That makes it even more dangerous to skip the discussion. Put your knowledge in. Challenge the output. Go three, four, five rounds. The prototype comes after the thinking, not instead of it.
Prototype fast, then architecture right. AI will give you a working prototype before lunch. Great. Use it. Show it. Get feedback. But when the feature is real and it needs a proper PRP, do not just let AI design the architecture. This is where your gut matters more than any suggestion AI can give you. AI tends to over-engineer. It loves abstractions. It will give you a beautiful pattern that nobody on your team can maintain. Good architecture is not impressive architecture. Good architecture is the one that survives when you are not in the room.
Iterate and revalidate constantly. Do not trust the first output. Do not trust the second. Run another round. Check it in a new conversation. Ask AI to challenge its own answer. This is not slow. This is how you avoid spending three days debugging something that felt right on the first pass.
Document everything. Keep it alive. Create markdown docs for everything. Architecture decisions, API contracts, onboarding notes, product context. And here is where AI changes the game quietly. Updating documentation used to be the thing nobody had time for. Now there is no excuse. You can take an outdated doc, feed it back in with what has changed, and get a clean updated version in minutes. Documentation is not a chore anymore. It is part of the flow.
Backend first. Always. I know. The frontend is what people see. The frontend is what gets the applause in the demo. But if you build frontend without backend, without back-office tools, without the admin panel your support team needs at 2 AM, you are not building a product. You are building a promise that someone else will have to keep. The app support engineer connecting directly to the database to debug a customer issue? That is not an edge case. That is what happens when you skip the boring parts.
Build once, reuse everywhere. This is the laziest and most important rule. Every component, every service, every API should be designed with the question: will I need this again? If yes, build it properly now. If you are not sure, build it properly anyway. The lazy engineer builds things once so the lazy engineer can sleep well later.
Everything I just described works. It works well. But I need to be honest. It works for me.
The bulldozer with AI is fast. The lazy rules keep things clean. The discussion, the prototyping, the documentation, the reuse. When it is just me and the algorithm, the system flows.
But one bulldozer is still one bulldozer.
I cannot copy my 30 years of gut into another person. I cannot copy the instinct that says “this architecture is over-engineered” or “this prototype is good enough to show but not good enough to ship.” That instinct came from decades of building things wrong first. AI does not transfer that. AI amplifies whatever the person already has.
And the way we build software together adds another challenge. AI works best when it sees the whole picture. The database, the API, the frontend, the admin panel, the edge cases. That is why it works so well individually. You let it see everything. But in a real organization, people own different pieces. They have boundaries. And when AI builds something that crosses all those boundaries in one sweep, who maintains it? Who owns it?
This is the part I have not solved yet. I have experiments. I have things I am trying. But I would be lying if I told you I figured this out.
I started this article talking about an idea that came in the bathroom. I want to end it there too.
The lazy mind is not an empty mind. It is a mind that has done enough work to know what matters and what doesn’t. It is a mind that refuses to solve the same problem twice. It is a mind that would rather build the foundation right once than patch it forever.
AI did not make me lazy. I was always lazy. AI just finally made it a strategy.
So if you are a bulldozer like me. If you have spent years pushing through walls and wondering if there is a smarter way. There is. Discuss first. Build once. Document everything. And let yourself rest long enough for the next good idea to arrive.
It might come in the bathroom. That is fine. The best ones usually do.
Footnotes
Since this was written, "context engineering" has grown into the broader term for what this article was reaching at. Discuss first, coding later still holds. It is part of doing vibe coding well.
This is the last backfill story from LinkedIn related to the book “AI Has No Morality. It Has Yours.
I am writing this book one chapter at a time.
If you want to read it as it happens, subscribe below
If this made you think, share it with someone who needs to read it.
BØY (Chaiharan) has spent 30 years in tech — building products, recovering disasters, and turning around the things nobody else wanted to touch. Based in Bangkok. Writing a book in public about what AI reveals about the humans who use it.