The most upvoted post on Habr this week hit a nerve. A developer wrote: "AI didn't just speed up my work — it devalued it." He described sitting in standups, letting Claude write his PRs, not even reviewing comments himself — just forwarding them to the LLM. And at the end of the day: nothing. No satisfaction. No sense of creation.
We read it at Gerus-lab and had a long argument about it. Because we're building things with AI every single day. And we've felt this exact thing — and we've also found a way through it.
This is our honest take.
The Symptom Is Real. The Diagnosis Is Wrong.
The author isn't wrong that something has changed. AI code assistants have become incredibly capable. What used to take a senior dev a day now takes an hour. That's real. And yes — when the bottleneck disappears, some of the ritual satisfaction goes with it.
But here's where we disagree: the problem isn't AI. The problem is how most teams are integrating it.
They're using AI to do the same job, faster — instead of using AI to do fundamentally different work.
When your role becomes "write a prompt, click approve, merge PR" — of course it feels hollow. You've turned yourself into a human YAML parser. That's not AI's fault. That's a workflow design failure.
What We Actually Experienced at Gerus-lab
We're a Web3 and AI engineering studio. We work on TON blockchain integrations, AI-powered SaaS products, GameFi mechanics, and backend systems. AI is baked into how we build.
And yes — we went through the devaluation phase. Around mid-2024, some of our engineers started feeling like code reviewers for an LLM, rather than engineers building things. Output went up. Morale went down.
So we changed the model.
Instead of using AI to write the code that engineers used to write, we pushed the AI into the grunt work layer — boilerplate, migrations, documentation, test scaffolding, repetitive CRUD endpoints. And we pushed engineers up into the design layer — architecture decisions, integration patterns, product logic, client conversations.
The result: engineers stopped feeling like prompt operators. They started feeling like architects.
The Actual Problem: Creativity Collapsed Into Execution
The Habr author makes a sharp observation: "Developers found creativity in the act of implementation — clean code, readable code, great docs. AI killed that."
This is true. But it assumes the implementation layer is where creativity should live.
For most junior-to-mid developers in enterprise environments, it was. Because they weren't invited into higher-level decisions. The business threw requirements over the wall, and devs caught them.
AI has now taken that layer. So if that's where your creativity lived — it's gone.
But here's what we've found: when you move creativity up the stack — into system design, product decisions, client problem-solving — it doesn't go away. It explodes.
At Gerus-lab, we've built projects ranging from TON blockchain integrations to full AI SaaS products to GameFi mechanics — and the engineers who thrived weren't the ones who fought AI. They were the ones who grabbed the creative space AI vacated at the bottom and ran upward.
The Side Project Exception — and What It Tells Us
Interestingly, the Habr author says he loves using AI for his side project. He built a Telegram bot that scrapes Reddit and generates personalized response suggestions — all via AI, zero manual code. And it made him happy.
Why the double standard?
Because on his side project, he owns the goal. He cares about the outcome, not the implementation. The AI is serving his vision.
At his day job, the AI is serving the corporation's backlog. He's just the middle layer.
This is the key insight: AI doesn't kill creativity. Alienated labor kills creativity. AI just makes the alienation more visible.
If your job was already "implement someone else's spec as fast as possible" — AI has now made that crystal clear by removing the last place where craftsmanship could hide.
The solution isn't to go back to writing code by hand to feel better. The solution is to change what your job actually is.
How We Hire for the AI Era
We've changed our hiring criteria at Gerus-lab. We used to optimize for coding speed and pattern recognition. We now optimize for:
- Systems thinking: Can you design something that will survive three pivots?
- Product intuition: Can you tell a good idea from a bad one before it's built?
- Communication: Can you translate between technical reality and client expectations?
- AI direction: Can you break a complex problem into pieces that AI can actually execute well?
None of these skills are made obsolete by LLMs. All of them are more valuable now than they were five years ago.
We look for engineers who see AI as a powerful junior developer — one who can write fast but needs clear specs, can't make judgment calls, and will confidently go in the wrong direction if you don't point it right.
Managing that junior developer well? That's the job now.
The "Is My Job Meaningful?" Question
Under all of this is a harder question the Habr author is circling: is software engineering still a meaningful career?
We think yes — but the meaning has shifted.
For the last 30 years, meaning in engineering often came from mastery. The feeling of deeply understanding a system, of knowing your codebase intimately, of writing elegant solutions to hard problems.
AI hasn't eliminated hard problems. If anything, it's pushed them up. The problems that feel hard now are higher-stakes: what should we build? How do we make this durable? What does the user actually need?
Those problems require judgment, experience, context, and creativity in exactly the way that LLM-generated code does not.
At Gerus-lab, our most valued engineers in 2025 are the ones asking "why are we building this?" before "how should we build this?" — and having the credibility to push back when the answer isn't good enough.
What We'd Say to the Habr Author
Don't let the AI take the job you still have. Let it take the job that was always a bit beneath you.
The scaffolding, the boilerplate, the "translate this ticket into working code" loop — that was never where the real work was. It was just where the work was visible, legible, measurable.
The real work — understanding problems, making decisions, designing systems that last — is harder to measure and harder to outsource. It's also far more interesting.
If you're feeling like a dying programmer, the answer isn't to fight AI. It's to stop being the person AI is replacing, and become the person who decides what AI builds.
We've rebuilt our entire team culture around this idea. It's working. Come build something real with us.
The Bottom Line
AI is not killing programming. It's killing a specific kind of programming — the mechanical execution of someone else's complete instructions.
For developers who were doing that work, this feels like death. Because it is, in a way. That role is going away.
But the space it opens up — higher-level design, product thinking, creative direction of AI systems — is genuinely more interesting. It's what the best engineers were always actually doing between the lines of their JIRA tickets.
We're a team that builds at the intersection of AI, Web3, and product engineering. We've watched this transition happen in real time, in our own studio. The programmers who thrived weren't the ones who clung to hand-coding everything. They were the ones who grabbed the new space fastest.
The programmer in you isn't dying. It's being asked to grow up.
Gerus-lab is an engineering studio specializing in Web3, AI, and SaaS development. If you're building something ambitious and want a team that thinks this way, let's talk.
Top comments (0)