Everyone I know got handed the most powerful tool of their career with no manual. No training, no onboarding, nothing. One day it just appeared, and everyone started using it their own way.
Which is fine. That's how it had to happen. But I keep watching people work with LLMs and thinking: the habits forming right now are the wrong ones, and the right ones are embarrassingly simple.
Here's the cheapest discipline I know. Any time I finish a task with an LLM, I ask:
"Am I wrong here?"
"Can you review this? What holes am I not seeing?"
"Do a second pass."
That's it. It feels too simple to be the answer, which is probably why nobody does it. People treat the first output as the final output. They rub the lamp, take what comes out, and ship it.
Now, the obvious objection: asking the model to check the model is still trusting the lamp. Correct. These questions are the floor, not the ceiling. They catch the cheap errors — the ones the model finds instantly the moment you stop nodding along. For everything else, due diligence looks the way it always did: read the docs, search for yourself, run the thing. The questions don't replace your judgment. They buy you a second draft before your judgment even has to show up.
Don't trust the lamp. The model is hardwired to sound certain, and certainty is not correctness. What you bring to this loop — the actually human part — is your train of thought. Outsource that too, and you're not using the tool. The tool is using you.
Here's the thing nobody tells you about engineering: a five-year-old can design a bridge that will outlive everyone. Just overbuild it. Pour more concrete. Add more steel. Anyone can do that, and an LLM definitely can.
Designing a bridge that lasts exactly twenty-five years — that's the job. That takes material science, tensile strengths, load calculations, everything you know. Because engineering was never about producing a solution. There are always ten ways to solve the same problem. Engineering is choosing between them.
I hit trade-offs every single day. Every task is a compromise between something and something else. The LLM will happily generate any of the ten solutions. Picking the right one for your constraints — that hasn't changed, and I don't see it changing.
In my years as a developer, nobody has once asked me whether my code was elegant. Not in a review, not from a manager, not from a client. The only question, ever, was: does it solve the issue? Yes or no.
This week I read someone complaining about the styling of Rust code an LLM generated. And I thought — this is a legacy mindset walking around in a new world.
Let me be precise, because this is where people will want to argue. Readability matters. Structure matters. A team codebase the next person can't follow is a real cost — that's not style, that's function, and it falls under "does it solve the issue," because unmaintainable code doesn't. What I'm talking about is the cosmetic layer: for loop versus forEach versus map, brace placement, your favourite idioms. That layer was always preference, and now it's preference you can enforce with a linter rule in thirty seconds. Which means it's no longer worth a human argument, let alone a blog post. Encode your taste in the config, let the machine apply it, and never speak of it again. Keep caring past that point and it turns into equestrian dressage. Beautiful, expensive, and a hobby. Nothing wrong with hobbies — but leave them to the hobbyists.
The abstraction I actually work at hasn't moved: I get a business issue, I translate it into code, code solves the issue. That layer is the same as it was five years ago. Everything below it got cheaper.
The other failure I keep seeing: rigor applied by habit instead of by judgment.
Building a prototype? Build a prototype. Does it need a test suite? No. Why would it? Its whole job is to answer one question and get thrown away. Spec-driven development for a throwaway proof of concept is a snowplow for a teaspoon job.
And no, that doesn't contradict the second-pass rule. Review effort should match the stakes, same as everything else. A prototype gets a skim: does it demonstrate the thing? Production code gets the full treatment — tests, review passes, the works — precisely because the model is confidently wrong sometimes and now it matters. Tests aren't a ritual you perform to feel professional. They're the due diligence, applied where failure has a cost.
Building a real product? Now you need engineering. Now you need to know which questions to ask — and knowing which questions to ask is most of the skill.
People over-engineer the prototypes and under-engineer the products, and the LLM will cheerfully help with both, because it doesn't know which one you're building. You have to.
Same disease, different symptom: over-invested scaffolding. I keep seeing people build elaborate skills around whatever the model struggles with today — instruction files, prompt rituals, multi-step workflows, entire techniques with names and courses attached.
Here's the problem. Models move fast. Extremely fast. The skill you carefully honed against last quarter's weaknesses? Next release, half of it is solving problems that no longer exist, and some of it is actively getting in the way. You're not steering the model anymore. You're dragging an anchor and calling it expertise.
Harnesses get thinner as models get better. So hold your techniques loosely. Build the minimum that fixes an actual, observed failure — not the imagined ones — and expect to throw most of it away soon. The durable skill isn't any particular workaround. It's noticing when your workaround stopped being needed.
I'm not writing this from above. Not long ago I knew nothing about any of this and was learning everything at once, and honestly, it was uncomfortable. Everyone hits that river eventually, and everyone's afraid at the start, because at the start you know nothing. The only way across is by doing it. You get better because you do it, not before.
So: patience with people. Criticism of outputs.
And one question, every time, that costs you nothing:
"Am I wrong here?"