The Warning Nobody Wants to Hear
Some developers are going to end up driving for Uber again — and this time it won't be the market's fault.
When I say devs are going to become Uber drivers, I'm not being alarmist. I'm describing a pattern I've seen before: professionals who thought their job was to execute tasks discovered they were replaceable when technology automated that layer.
AI is doing that to code right now.
What a Code Laborer Is
A code laborer is someone who receives a task and executes it. "Build a CRUD here." Done. "Add this field to the form." Done. "Integrate this API." Done.
They're competent at execution. They know the syntax, know the framework, deliver on time.
The problem is that this layer — the mechanical execution of coding tasks — is exactly what AI does well. Very well. And getting better every day.
Cursor writes CRUDs. Claude integrates APIs. GitHub Copilot adds fields to forms.
If your value as a developer is concentrated in executing these tasks, you have a real problem.
What a Real Software Engineer Is
A software engineer understands the system.
Not just "how to write this code", but:
- Why this architecture was chosen
- What the trade-off is between this approach and that one
- How it behaves under load, with real data, in edge cases
- What will break when the requirement changes (and it will change)
- What technical debt is being accumulated and when it will come due
AI doesn't answer these questions — because the answers depend on business context, system history, constraints that are never documented, and judgment accumulated by someone who has worked on the problem for months.
The Difference in Practice
I use AI constantly across my projects. Laravel, Next.js, API integrations, data pipelines. AI writes an absurd amount of code for me.
But what do I do that AI doesn't?
I define the problem. AI solves the problem I describe. If I describe it wrong, it solves the wrong problem — perfectly.
I review with judgment. Code that works isn't the same as code that should exist. Sometimes the right solution is to not have that code at all.
I understand the consequences. When AI suggests a solution, I know if it's going to blow up in production, create a performance bottleneck three months from now, or violate a business constraint that's not in the prompt.
This layer of judgment — real engineering — is not automatable. At least not yet, and not for real systems with real complexity.
The Illusion of "I Can Code"
There's a slice of developers who think they're safe because they "know how to code." They type code, the system works, the client approves.
But the real test isn't "can you make it work." It's:
- When a bug appears in production at 11pm, can you diagnose it in 30 minutes?
- When the system needs to scale 10x, do you know where the bottleneck is before going to production?
- When the requirement changes radically, can you assess the real impact?
If the answer is "I don't know, I'll ask AI," you're in dangerous territory.
AI is a multiplication tool. It multiplies what you already know. If what you know is shallow, it multiplies shallow.
What to Do About It
I'm not saying to ignore AI. On the contrary — use it. Use it a lot. But use it with understanding.
The difference between who stays and who goes isn't who uses AI. It's who can:
- Define problems precisely — garbage in, garbage out
- Evaluate solutions critically — don't blindly accept what AI generates
- Understand systems, not just code — the difference between making it work and making it right
- Accumulate judgment — experience that contextualizes AI's answers
That's software engineering. It's not about which language you use or which framework you know.
Prefer to Watch?
I recorded a short video on this topic on TikTok:
