In Slam Dunk, Sakuragi doesn't become useful by learning to do everything. He becomes formidable by getting excellent at one thing everyone else neglects: rebounding. He doesn't score, he doesn't dribble, he grabs balls — and his team wins matches because of it.
That's the question AI puts to our trade. Not "will I be replaced?", but "what do I do that the machine doesn't, and do I do it well?"
I use these tools daily, on real projects in production. Here's what I observe, without enthusiasm or panic.
What it does very well
Plumbing code. A typed HTTP client from a spec, a form with validation, a schema migration, converting one format into another. That work was boring and slow. It now takes minutes.
Remembering syntax. The argument order of an obscure function, the exact incantation for a pipeline. That used to be documentation lookup. It has become a question.
The first draft. Starting from an empty file is psychologically expensive. Starting from an imperfect draft to correct, far less so.
Explaining unfamiliar code. When taking over a project, asking "what does this function do" genuinely speeds up discovery.
On those four points the gain is clear. Denying it would be dishonest.
What it doesn't do
Knowing which code to write. On the home-care platform I contribute to, a visit cancelled less than two hours ahead is still billed at 50% — for that client, under that contract. That rule is written nowhere. It lives in the head of a person you have to go and listen to. No model will guess it.
Arbitrating. Should this parameter be configurable per client? Yes to sell, no to maintain. The answer depends on commercial strategy, not on code. A tool will give you a reasoned argument in both directions; it won't carry the decision.
Saying no. "This feature will create debt we'll pay for two years, and the real need behind it is different." That sentence requires understanding the need and accepting disagreement.
Taking responsibility. When production falls over at 11pm, someone has to decide whether to roll back or patch live. That's a responsibility, not a technical skill.
Doubting in the right place. This is the most important point, and the hardest to phrase.
The real risk: misplaced confidence
The danger isn't that these tools write bad code. It's that they write plausible code.
A beginner produces visibly wrong code. A model produces code that looks right, follows conventions, carries good names — and contains a subtle error. It offers you payment handling with no idempotency: it works perfectly in test, and creates duplicates in production the day a user taps twice.
To spot that, you have to already know. Which creates a paradox: the tool is most useful to those who need it least, and most dangerous for those who'd use it most.
My personal discipline:
- I never merge code I can't explain line by line. If I don't know why a line is there, it goes.
- On sensitive areas — payment, authentication, data isolation — I start from official documentation, not from a suggestion. I can use it to review, not to write.
- I test failure paths first. The happy path is exactly what these tools produce best; the awkward cases, not so.
What gains value
If writing code becomes fast, scarcity moves. From what I see across my own engagements:
Understanding a business. Knowing how to interview a user, spotting the edge case that will structure everything, translating a field reality into a model. That's what separates software that gets used from software that gets delivered.
Judging. Facing three solutions that all work, choosing the one that will cost least in two years. That requires having lived those two years.
Operating. Knowing why a disk fills up, why PostgREST can no longer reach Postgres, why your site shows an empty page without raising an error. I spent a morning on that, and no assistant would have found it for me — because you first had to know which question to ask.
Communicating. Explaining a technical trade-off to someone non-technical. Writing a message that avoids three round trips. That skill, widely looked down on, becomes central as the rest automates.
Reviewing. Code review moves from quality gate to primary skill. There is far more code to review, produced faster, by people who thought about it less.
The underlying problem for the profession
What worries me isn't replacement. It's the erosion of the learning path.
You got good by writing mediocre code, watching it break, fixing it. That loop — write, suffer, understand — is the learning mechanism. If a beginner immediately gets correct code without ever passing through the suffering, where do they acquire judgement?
The simple tasks, the ones handed to juniors, are precisely the ones automation absorbs best. We risk creating a generation asked to have judgement without having been given the means to build it.
I have no general solution. What I do, at my own scale:
- Write first, ask second. On a subject I want to learn, I produce my version before comparing. Comparison teaches; copying doesn't.
- Do the hard part by hand. What costs me is exactly what makes me progress. Delegating precisely that is buying time with competence.
- Pass it on. I ran a React Native study group where we reviewed each other's code. Explaining your code to someone remains the best detector of what you haven't understood.
What I'd tell someone starting out today
Don't refuse these tools: that would be working with a voluntary handicap.
But deliberately choose where you accept not to go fast. The fundamentals — how a database works, what a transaction is, what a network call costs, why a query is slow — are only acquired through effort. They're what will let you, later, spot the plausible-but-wrong code.
And cultivate what the machine doesn't touch: understanding the business, judgement, responsibility. That's Sakuragi's rebound. It isn't spectacular, it doesn't make for great demos, and it's what wins matches.
If you want an outside opinion on a product, an architecture or a project handover, write to me — the first conversation is free.