Introduction
Every few months, every new LLM model release goes viral. Someone builds a working app on a weekend. An AI writes a thousand lines in minutes. The comment sections fill up with the same question: does this mean engineers are about to get a lot cheaper to hire, or a lot easier to replace?
It is a fair question. But the answer depends heavily on what you think engineers actually do.
This topic is also something we discuss on our podcast, where we break down what is actually happening in AI and engineering without the noise. You can listen to the first English episode here, or browse the full playlist on YouTube Music.
The coding time myth
Before 2014, writing code accounted for roughly 50 to 60 percent of a developer’s working day. That number has been shrinking for years, and the trend is accelerating. Today, most engineers spend somewhere between 10 and 30 percent of their time actually writing code. The rest goes to understanding the business, clarifying requirements, reviewing architecture, evaluating the output of AI-assisted workflows, communicating with stakeholders, and making decisions that cannot be made by anyone who does not fully grasp the system.
This matters because AI tools are very good at the part that was already shrinking. They accelerate code generation, test scaffolding, and repetitive structural work. But they do not replace the judgment needed to figure out what to build, how to build it safely, or what will break six months from now. Architecture is not just about making something work today. It has to be designed from day one to handle ten times the load, withstand unexpected traffic, and scale without requiring a full rebuild the moment the product succeeds.
What the productivity numbers say
The reality is more nuanced than the headlines suggest. Productivity gains are not automatic, and context, experience, and how deliberately the tools are used all determine whether AI helps or hinders.
Some phases of development respond extremely well to AI assistance: test generation, boilerplate scaffolding, code migration between technology stacks. Others still require strong human expertise and do not compress well. Architecture decisions, security reviews, debugging generated code in production, and maintaining long lived systems all fall into this second category.
Ralabs ran a project recently where a system needed to migrate from one technology stack to another. The original estimate was around one and a half months. With deliberate AI assistance, it was completed in a week. That is a real, documented outcome from our own work. But it required a senior engineer who understood the system deeply enough to supervise what the AI produced, catch its errors, and validate that behavior matched the original.
12.02.2026
AI-Driven Cloud Migration: How we cut migration time by 90%
The same principle applies beyond client work. Roman Rodomansky, our CTO with 15+ years of engineering experience, recently built a full product on his own: openthedoors.ai. It took two months. Without AI assistance, the same build would have taken six to eight months. That compression was not the result of shortcuts. It was the result of deep experience combined with the right tools, used correctly.
The last mile problem
We ran into the last mile problem firsthand when building our own internal agents at Ralabs. Our first was a legal Slack agent designed to help the sales team review new client contracts. The logic was straightforward: we maintained around 130 legal criteria in a Google Sheet, managed by our legal team. When sales messaged the Slack bot, it triggered an n8n workflow where the agent would take the incoming legal PDF, pull the criteria, and validate them against each other. We used OpenAI models for the task.
Testing revealed significant hallucinations. We switched to an LLM council approach, where multiple models cross-check each other, which improved accuracy. But for legal content, the error rate was still not acceptable. We made the decision to pause and wait for a better model. We are currently testing with Claude Opus 4.6.
The analogy that fits best is the last mile problem in self-driving vehicles. Ninety-five percent of driving scenarios are solvable. The remaining few percent involve judgment, context, and edge cases that do not appear in training data. Software has an identical dynamic. AI can handle the predictable majority. The unpredictable minority is where production systems actually break, and where engineering expertise earns its value.
Both cost and speed. And one depends on the other.
When product teams and engineering clients ask us about AI, the conversation usually starts in the same place: can we do this for less, and can we do it faster? Both are fair expectations. AI tools do create real opportunities to reduce costs and compress timelines. But there is a catch that does not appear in the demos.
Faster, cheaper development only works when the inputs are clean. Clear requirements, well-scoped specifications, and minimal change requests during execution. When those conditions are met, AI-augmented teams can move significantly faster and deliver more for the same budget. When they are not, acceleration in one part of the process simply moves the bottleneck somewhere else. The team ships faster, but keeps rebuilding. The cost savings disappear in the rework.
This is something we see consistently across projects. The teams that get the most out of AI tooling are the ones that invest in clarity upfront: defined scope, stable requirements, and a product owner who can make decisions quickly. AI rewards discipline. It does not fix the absence of it.
What changes for engineers, and what stays the same
The engineers getting the most out of this shift are not just the ones writing less code. They are the ones who understand what AI produces well enough to direct it, review it, and catch what it gets wrong. That combination of technical depth and AI fluency is what the market is rewarding right now, and the demand for it is outpacing supply.
Personally, I am more excited about engineering today than ever before. I no longer spend my time debugging style issues or fixing repetitive code. I delegate the boring parts to AI and focus on the work that actually requires thinking. After several months of very active AI coding, spending around $800 on tokens in January alone, I find myself going deeper on things I would not have had time for before: complex RAG pipelines, model retraining, specific tools like Voyage AI. AI did not make me less of an engineer. It made me more focused.
Roman Rodomansky, CTO at Ralabs
The profile that performs well in this environment is what is sometimes called the T-shaped engineer: someone with broad working knowledge across multiple domains rather than extreme depth in one. Security, architecture, infrastructure, performance, AI tooling, and product thinking. An engineer who can navigate AI-generated code with confidence, review it critically, catch what it gets wrong, and steer what it produces toward a system that will actually hold up.
Someone still has to be accountable for what ships. That accountability covers security, performance, correctness, maintainability, and whether the client’s actual problem gets solved. AI does not accept accountability. Engineers do.
What AI actually changes, and what it does not
Migrations, test generation, scaffolding, documentation, and discovery phase all compress meaningfully with the right tooling and the right engineer operating it. In complex product development, the answer is more nuanced. AI shifts where time is spent. It does not eliminate the need for engineering judgment, and it does not reduce the cost of building something that actually works at scale, handles real users, and survives contact with production.
Companies that treat AI as a way to cut headcount on complex products tend to run into the problems that skilled engineers were there to prevent. Companies that treat it as a force multiplier for strong teams get real, measurable results.
The difference is not in the tools. It is in how you use them and who is doing the using.
Working with AI in practice
At Ralabs, we invest in our engineers continuously. That means building internal frameworks for using AI tools daily, not occasionally, and developing the habits that separate engineers who save time with AI from those who spend it. We have also built internal systems to measure how AI actually affects quality across our projects — something Roman Rodomansky, our CTO, spoke about at WawTech and covered in depth in his article How to run software quality at scale. The result is a team that knows how to use these tools correctly, and knows when not to.
When you work with us, you are not getting engineers who have heard of Cursor or played with ChatGPT. You are getting engineers with structured, practiced workflows for AI-assisted development, code review, and problem-solving built into how they work every day.
That translates directly into what you receive: faster delivery, cleaner architecture built for scale, and a product that is secure and maintainable from the start, not patched into shape after launch.
If you are building something that needs to hold up, we are ready to talk.
See how we approach AI development or get in touch directly.
