There's No Substitute for Reps in an LLM Fantasy Land
Whether lifting weights or writing code, growth comes from cumulative, deliberate practice—not shortcuts. Large Language Models (LLMs) have become the modern-day snake oil for skill development, promising instant expertise while bypassing the messy, critical work of actually learning. Here's why relying on AI tools as a crutch will leave you stranded at the starting line.
Don't get me wrong; I'm the biggest proponent of LLM workflows. Nowadays, I baulk at putting one character before another. I'm writing less and less code, and speaking more and more instead. Even now, I'm thinking about how much faster it could be to dictate out loud and clean up the mess later. However, by skipping the manual writing process, I'm stealing something from myself—the integral practice and reps required to improve.
Back in my day, grumble grumble, you were expected to pick up the API reference and slam your head against it repeatedly until you'd mixed and matched enough combinations of example code to call yourself a dumbass and get over your own mistakes. Of course, nobody told me that learning to write software correctly would make this all second nature.
I stumbled into coding out of necessity, with just the slightest inkling of exposure over the last 30 years. At the time, I did not realize what a character-building exercise this was. But I owe my entire career—my wins, goals, thoughts, everything—to that messy, chaotic journey of falling in love with problem-solving.
The pain associated with hours spent debugging a well-hidden typo, a misread paragraph, or some random stranger's mistake is a rite of passage. It's one that every engineer, creative, and ambitious human experiences on their climb out of the caves and into the spotlight. It's the secret handshake we share as software developers.
From Necessity to Obsession
My code journey started of necessity—in the trenches of performance marketing, managing thousands of PPC campaigns for a voucher publishing site (later acquired by Groupon). It was the perfect storm of "I can't be arsed to do this" meeting "scratching paint with a toothpick is more fun than what I'm being paid to do right now."
So I did what any procrastinating geek would do—I turned my screen to the wall and my head to the sand. There was no way I would do that work manually,, not when I knew I didn't have to. I'd instead overcome an issue 100x tougher to avoid the dullards of a modern office function—not because someone told me to, but because I had to. I'm too lazy for that—I still am. And that's when another engineer was born.
It's an opening chapter that many in the martech space share—each going their way toward data, analytics, software, management, entrepreneurship, or everything at once, like mine.
The Evolution of a Problem Solver
Let's head back several years. I was a little shittling once upon a time—the person I'm warning about in this article.
Through others' hard work, I found myself forged in fire. In an act of euphoric mania, all my problems turned into nails, and JavaScript became the hammer to beat them down. Much like Smeagol pursuing his precious Ring, knowledge drove me to develop, automate, and create without questioning if I should. I did it because I could, not because I should have. And that's how a problem solver was born.
Over time, the problems grew more significant and the solutions more intricate. I found myself building to solve problems and creating problems to solve them again. What started as a necessity—a way to skip the hard work—had transformed into an artisanal love affair with code.
I automated my entire job, then teams of teams. I built my voucher publishing site and automated every second of my time, generating £10,000 per month on autopilot. Not your traditional passive income scheme, but systems and flows that, while flimsy and prone to errors, allowed me to add more weight to the bar—a progressive climb over many years.
I progressed through analytics, martech, data analysis, product development, and technical sales. I launched multiple businesses and exited twice, using code as my defining weapon.
The questions never stopped: What's React? How do I host this? What's a server database? Which database? How can I structure this data? What about TypeScript? Web apps? Mobile? Desktop with Electron and Tauri? What is Rust? Golang?
Where my marketing career started—selling products others built—I now know how the sausage is made. I now know how to make the sausage myself.
These were my reps. I put in the hard work. By accident. but still.
Why Struggle Builds Mastery
Much like development was an addiction that never let me down, I see LLMs becoming that same crutch to many others just starting—equally exciting and dangerous.
In weightlifting, hypertrophy occurs when muscles are stressed to failure, forcing adaptation. The same applies to engineering:
- A beginner lifter doing 15 reps with light weights builds endurance but minimal strength
- An experienced lifter doing five heavy reps recruits high-threshold motor units, triggering growth
Coding works the same way. Early in my career, manually debugging thousands of PPC campaigns taught me to spot inefficiencies invisible to automation. The hours spent fixing typos, untangling nested loops, and deciphering API docs weren't wasted—they rewired my brain to think like an engineer.
LLMs shortcut this process. They let beginners generate "functional" code without understanding why it works. For example, if you use a weight machine without learning proper form, you'll lift heavier weights but tear your rotator cuff at the first unexpected load.
Avoid Shallow Solutions for Deep Problems
LLMs excel at regurgitating patterns but fail catastrophically when faced with novelty:
Logical Blind Spots: They produce syntactically valid but ridiculous code that lacks proper patterns—patterns you only learn through trial and error and experience.
No Conceptual Grounding: LLMs lack real-world context like an octopus guessing the weather. They suggest outdated libraries or vulnerable dependencies. Anyone who's asked an LLM to set up ESLint knows the struggle with breaking changes, just like those fighting with ESModules vs CommonJS, functional versus OOP, or kebab-case vs camelCase.
Overconfidence in Errors: An LLM, like a consultant, delivers extremely confident wrong answers when unchecked—the kind of confidence that would make you hand over your house keys without hesitation.
Where Real Engineers Are Forged
Debugging is the ultimate rep-building exercise:
Rubber Ducking: Explaining code aloud exposes flawed logic no LLM can catch. You can replicate this with LLMs by conversing about what you need, challenging assumptions, and developing a solid spec document you can confidently reference.
Backtracking: Retracing execution paths builds systems thinking—a skill LLMs lack entirely. This requires your knowledge, expertise, and experience from previous failures. I've watched people frantically copy-paste terminal errors into LLMs repeatedly. I'm guilty, too; sometimes the quick answer seems best when you should be applying knowledge instead of losing it.
Edge Detection: Humans spot edge cases; LLMs amplify biases, creating insecure code and incomplete features. This comes with experience—you must put in the reps. Once you've built that knowledge, you're unstoppable. But if you're deferring all hard work to an LLM, you might build working software, but will you understand it? Can you explain it? Are you using current best practices? These questions matter; they earn you money and respect as a developer.
Hire Engineers Who've Put in the Reps
The market is now flooded with "LLM whisperers" who have never written a line of code without Copilot. Don't be fooled. The marketing teams behind Windsurf, Replit, Lovable, etc., have convinced everyone that no-code, low-code, and full-code LLM solutions are all they need, as if overnight entire civilizations and even Earth will be torn down and rebuilt in the name of progress.
Until they aren't. And you're still struggling with your six hundred lines of context, unable to make progress and taking to Twitter (Fuck Elon) to voice your disdain.
I see a market flooded with juniors who don't know the basics but exude confidence in their deliverables. They're commoditizing code and adding a net negative to the industry.
You need engineers who:
Think first, code later. Yes, it's thrilling to ship in a day what previously took weeks, but use your gray matter. Put in the reps. Fight knowledge entropy.
Anticipate Failure: We've all believed lies we wanted to hear and gotten burned. The same happens with over-reliance on AI. Think twice before shipping that code or posting that article. Proofread. Add your own experiences, as I'm doing now. My rule: LLMs excel at enhancing thoughts and structuring chaotic inputs, but they can't replace actual thinking. Never defer intelligence.
LLMs have their place—explaining concepts, drafting boilerplate—but mastery demands reps. Real reps. Painful, iterative, human reps.
Put down the chatbot and pick up the API docs. Wrestle with the errors. Log the hours. Or hire someone like me who already has.
Need systems that scale? Let's talk: https://www.linkedin.com/in/dougsilkstone/