Should I discuss with AI before asking it to write code?
This is a short, practical piece by someone who has built software for 30 years. He calls himself a bulldozer. He sees a problem, does the work, ships it, and moves to the next one. He also calls himself lazy. Not lazy about work. Lazy about doing the same work twice.
The essay is about how he works with AI every day. His main rule is simple: discuss first, coding later. He does not just type a prompt and take the code. He puts what he knows on the table, like PDFs, research and years of domain knowledge, and talks it through with the AI. The first answer is rarely right. The good idea tends to show up around the third or fourth round.
From there he lists the rules he follows. Build a prototype fast, but trust your own gut on architecture, because AI tends to over-engineer. Check the output again in a new conversation. Keep documentation alive. Build the backend and the admin tools first, so the support team is not stuck at 2 AM. Build once and reuse everywhere.
He is also honest about what he has not solved. His instinct came from decades of building things wrong first. AI does not copy that into another person. It amplifies what the person already has. How a whole team works this way is still an open question for him.
The tone is light. It is the easiest chapter in the book to start with.