I spent the last month asking developers one question: “How are you actually productive with LLMs?” Not the hype, not the demos — the real, gritty, daily stuff.
The answers surprised me. Almost everyone who was getting real value wasn’t using ChatGPT to spit out finished code or perfect prose. They were doing something weirder — and far smarter.
The difference between a mediocre output and a breakthrough isn’t the model — it’s the question.
One engineer told me he’d stopped asking for solutions entirely. Instead, he asks the model to explain trade-offs. “Give me three ways to solve this bug, ranked by maintenance cost.” He doesn’t copy-paste anything. He reads, chooses, and writes the final version himself. His output per day doubled.
Another founder used an LLM to critique his product roadmap — not generate it. He uploaded a document and asked: “What am I missing?” The model pointed out three blind spots that his team had debated for weeks. He saved a month of meetings.
Here’s the pattern: productive LLM users treat the tool as a thinking partner, not a vending machine.
We’re not outsourcing thinking; we’re learning to think in smaller, sharper chunks.
So I boiled down the common thread into three questions you should ask before you ever type a prompt:
1. What am I trying to decide, not just produce? If you’re writing code, the decision might be which architecture to use. If you’re writing an email, the decision might be which tone lands. Ask the model to help you decide, not to write for you.
2. What underlying structure am I missing? The best users decompose big tasks into tiny, ripe-for-critique chunks. “Draft three versions of the opening paragraph, each using a different rhetorical device.” They don’t want output; they want options.
3. What would a smart skeptic say? Ask the model to play devil’s advocate — on your code, your strategy, your argument. This is where the real productivity gain lives: not in generating, but in stress-testing your own thinking.
I’ve seen this pattern across 50+ conversations. The people who treat LLMs as output factories burn out. The people who treat them as co-pilots for their own cognition build faster, write sharper, and make fewer mistakes.
The real competitive advantage isn’t access to the best model — it’s the discipline to ask better questions.
Side projects? Same story. The successful ones weren’t built by having an LLM write all the code. They were built by someone who used the LLM to iterate on ideas, test assumptions, and break down a daunting vision into a one-week experiment.
So next time you open a chat window, don’t ask “Write X.” Ask “Help me think about X.” You’ll get less output — and far more value.
FAQ
Q: Doesn't this contradict the idea that LLMs save time by generating output directly?
A: No. The time saved comes from avoiding bad output. Asking better questions upfront eliminates the iteration loop of fixing garbage. It's slower in the moment, faster overall.
Q: What if I just want to code faster — isn't letting the LLM write everything more efficient?
A: Only if you never need to debug or maintain that code. In practice, code you didn't understand becomes tech debt. The three-question method ensures you understand every line, which saves weeks later.
Q: Isn't this just a fancy way of saying 'garbage in, garbage out'?
A: Partly, but there's a twist: even with great prompts, the real skill is decomposing a problem into decisions. That skill transfers beyond LLMs — it makes you a better engineer, writer, and strategist.