AI, devs and 2025: staying useful when code is no longer the bottleneck
· AI · Alejandro Cantero Jódar
There’s a sentence that comes to mind every time I open the editor: we’re no longer valuable for writing code fast. A machine does that better. The real value is deciding what to build, how it fits the system, and why it makes sense for the business. Everything else is commoditized.
This post is for devs. For people who already know JavaScript/TypeScript/PHP or whatever, who already built CRUDs, who already fought the build, and who now see AI spit out a whole module from a prompt. This is not motivational. It’s a map of concrete things you can do to avoid becoming “the person who pastes AI answers into the repo.”
1. The mistake of thinking “using AI” = “being more senior”
In 2024–2025 almost everyone “uses AI.” That stopped being a competitive advantage. What does matter is how you use it:
If you use it to generate entire files with no context, you’re just adding debt.
If you use it to explore design options and then you choose, you’re leveling up.
If you use it to validate an idea in 30 minutes that used to take 2 days, you’re multiplying team throughput.
AI is good at producing variants. We have to be good at picking one.
2. Architecture first, prompts after
The pattern I see the most is this:
someone asks for a feature;
you open the AI chat;
you paste the code;
you merge;
one month later nobody understands the data flow.
That order is wrong. The right order to reduce entropy is:
Define the boundary: what comes in, what goes out, what side effects are allowed.
Pick the mental model: pub/sub, light CQRS, a very dumb service layer, whatever… but pick it first.
Only then ask the AI for implementations inside those limits.
AI fills gaps. It does not invent healthy boundaries. If you don’t mark the perimeter, the model will connect things that should not talk to each other and after three sprints you have an unmaintainable graph.
3. Good black boxes vs risky black boxes
To write a good prompt you have to know which parts of your system can safely be a black box and which ones cannot.
Safe black boxes (let AI handle them fully):
self-contained algorithms with clear I/O;
utility scripts;
transformers, exporters, parsers;
code you could have installed as an NPM package.
Risky black boxes (don’t hand them over fully to the model):
orchestration of business flows;
shared state management;
logic that crosses bounded contexts;
integrations with client-specific rules.
General rule: the closer you are to the business, the less you delegate.
4. The load-and-consolidate cycle
AI lets you “load” the system very fast: you add endpoints, components, scripts. But that load has to be followed by a consolidation phase where you:
rename things so the domain is clear;
move logic from components to services or use cases;
remove magic arguments the AI invented;
add contract tests around the boundaries that actually matter.
Think in cycles of 1 part generation → 3 parts ordering. If you only generate, the repo collapses. If you only order, you never ship. AI will not do the ordering for you because it requires understanding why that project exists.
5. Skills that are not automated yet
There are four zones where LLMs are still weak and where a dev can position themselves:
Prioritization: picking which feature actually creates revenue and which one is just nice to have.
Historical context of the codebase: knowing why that hack is there and what breaks if you remove it.
Communication with non-technical people: translating technical constraints into business decisions.
Security and performance in production: AI generates code that works, not necessarily code that resists real traffic or malicious users.
If in your day to day you’re not touching any of that, you’re exposed.
6. The broken reward loop problem
A lot of us became programmers because the cycle was short and addictive: think for a bit, write a few lines, it breaks, you fix it, and the browser says yes. That effort/reward loop is what keeps a dev in front of the screen for hours.
AI breaks that loop because now many of those micro wins are done by the model at once. There is no constant mini challenge. That’s why some people are a bit down or reconsidering staying in the field: the work is moving from solving micro problems to designing whole solutions and deciding trade-offs. It’s less instant dopamine and more deliberate design.
The way out is not going back, because the market already decided that fast code generation is the standard. The way out is shifting your focus to where AI doesn’t “have fun”: defining the right data model, separating responsibilities, naming well, anticipating change, negotiating requirements. There is still a reward loop there, it’s just longer.
7. Conclusion
The job of a dev in 2025 is not “writing code.” It’s shaping the system and then letting AI fill it in. If you do that, you stay expensive. If you don’t, you are interchangeable with anyone who can copy and paste prompts.
It’s that simple.