10x what?
10x productivity, 10x outputs or 10x frustration?
Are we actually more productive? Aren’t we working even more? Where are the productivity gains?
Depends who you ask. You can hear bold claims all over the place.
No doubt software engineering is changing due to improvements in AI. So is it in my company - Coralogix. I work as a software engineer mostly on the backend side of things - data ingestion pipelines and search infrastructure. My work is vastly different than it used to be.
If you ask me it is for the better - I feel much more empowered and productive. Seemingly I am not an isolated case. I ran a short survey among 40 fellow software engineers at Coralogix, asking how they feel about the changes.
To my surprise, everyone I asked reported gains in productivity. Majority feel significantly more productive. Though we may be well positioned working in an observability company. Especially in one increasingly becoming AI-native.
What are the changes?
Probably the most profound is that I no longer write code. In fact, I’d go even further - I don’t even use an IDE anymore. I almost exclusively work from the terminal with all code being written by agents. Majority of colleagues follow the same approach.
Interestingly no one is writing fully by hand anymore.
What used to be the core pillar of my work, what I used to practice for years in university is no longer there. Many engineers struggle with that.
Do I miss it? Not really.
What brought me to the field was rather solving problems not writing code. I treat code as a tool for solving problems and I believe I can now do that at a higher level and more efficiently.
Sure “getting into the flow” was great, but remember those long hours being stuck with only StackOverflow at hand? The “joy” of writing boilerplate or unit tests?
How I work now
So the agents produce all the code now.
First, what agents?
We are fortunate enough to have all frontier lab models/harnesses at our disposal and freedom to choose.
Claude Code is near-universal at 95%, Codex is second at 55%. Everything else is a long tail. People run about two agents each on average, and the dominant setup is Claude Code plus Codex (15 people). This is my current setup as well.
The culture is terminal-first: 90% use a CLI, and 18 people use the terminal exclusively. A dedicated desktop app comes next at 38%, while IDE extensions (15%), web chat (8%) and API integrations (5%) are marginal. This makes me question the future of IDEs.
Second, what does it actually look like?
For simple or low risk changes it can be as simple as asking “Do X make no mistakes”. What we can reliably put in “X” changes all the time.
However, as the complexity and stakes grow, so does the upfront planning. For that purpose, I especially like the /grill-me skill from Matt Pocock. It helps me stay close in the loop.
No matter the stakes, I make sure the agent has all the required context to perform the job well. Be that ticketing system, docs, knowledge bases. At the same time I try to stay in model’s “smart zone”. Breaking the work to not exceed 150-200k input tokens in a single session.
Once the implementation is done I tend to do “simplification rounds”. Despite my best efforts in prompting and planning, the output is often more complicated than it needs to be. Who hasn’t seen the classic line:
Then come adversarial reviews. For that I set up a draft PR with all the context and design rationale then run reviews in a new session. Usually by a completely different model. Interestingly, I found that the reviewer model was less likely to raise some flaws when it matched the author model.
This part also takes a few iterations, I stop when the added complexity outweighs the issue.
Naturally, the coding part is greatly sped up. What comes after not as much.
We leverage agentic code reviews, they are definitely helpful, still the final decision is made by a human. Call it trust issues, but because of regulations I don’t think this will change, even if models get much better.
Therefore, there is also more code to review than ever. Unless you blindly trust the models, this can cause “review fatigue”. We deal with that by moving the reviews to a higher level - spending much more time upfront on PRDs and system architecture design.
This is similar to what Dex Horthy describes in how to optimize a “lights-on” software factory.
Maybe our decisions haven’t bitten us yet, but so far it is working great. Not only do you (hopefully) get a clean and maintainable architecture, but with the alignment the implementations become a joy to read instead of a slop to untangle.
Still, the code review is only a part of the verification and no matter how great your tests are, the final one is on production. Agents are pretty helpful there too.
Coralogix as a product places a huge bet on that, so we have a helpful tool at our disposal.
When agents can access all telemetry, be it logs, metrics, spans - you can detect any warning signs faster and easier. Recent models are probably better than me on that. Though maybe it is just a skill issue. Also, when it is so cheap, we also found ourselves making “ephemeral” dashboards tailored to the change.
While I am still the one deploying the changes, I definitely feel more confident.
Similarly when eventually incidents happen - I usually start by having an agent investigate. Some teams have it automated, but still there is a human involved in any case.
If you ask me, I have no issue at all with AI taking over the on-call part of my job.
Contrary to the trends in the industry, the increased speed hasn’t had a negative impact on our reliability. Quite the opposite. Not only did the number of incidents drop, so did the mean time to resolution (MTTR). I guess agents have an edge over humans at 2 AM.
For the maintenance of the code, agents can be a double edged sword. When you no longer write the code you also don’t feel its frictions and pain points as much.
Agents will happily come up with creative workarounds and shortcuts to solve the task at hand. Until you reach the point where rewriting the code from scratch is simpler than adding a new feature or modifying an existing one.
However when you are proactive about the tech debt they can be equally effective at tackling it. For this purpose we use scheduled loops. On a daily basis we have agent scanning for architectural issues, missing tests, dead or duplicated abstractions etc, but also scanning production telemetry in search of bugs or performance issues.
Comprehension debt
This can be really helpful, but it does not hide the fact there is another debt creeping up which may be even more serious - comprehension debt. It is the growing gap between how much code exists in your system and how much of it anyone genuinely understands. Coding agents can decouple software production from software understanding.
Does it really matter or can we also offload the understanding to agents? I think it does.
It is fine if understanding goes higher level but not lost whatsoever. I may not know system to the low implementation details. Nobody ever understood all the code anyway. However, I am never offloading my understanding beyond a certain point.
Owning software is a different job that never went away. Keeping it running when it breaks, fixing it when a dependency changes, knowing what else it touches, deciding whether it’s safe to modify, being the person who gets paged. It’s about being accountable for the thing over time, and it still requires someone who understands the system well enough to be responsible for it.
What if the agent fails you in a live incident at 2 AM?
What if you face a bug that the agent can’t solve? - Do you wait for a stronger model release?
There are moments when comprehension is the only tool you have.
Humans still have the advantage that they accumulate knowledge. Agents have to start from scratch each time. If you give up on that, what is your role and added value after all? Are you just becoming a proxy for the agent? Well, I don’t think it will play out in the long run.
On the other hand, when producing software no longer requires understanding it, it is accessible to a much wider group of people. Non-developers are building personal tools, dashboards, or prototypes. When reporting an issue, technical support also provides an initial investigation made by our observability agent “Olly”.
Also, all the execs and directors who used to code and stopped because of their calendar can now go from idea to working prototype in an evening. That changes the conversation with engineering.
The ceiling is where to be careful. The friction appears when non-engineer-built software crosses into production, because then the comprehension debt lands on whoever maintains it.
Also, the same tools that let you skip understanding also make it radically cheaper to get when you want it. An agent can be your private mentor that you can ask virtually anything. No matter how basic the questions are, it will not get tired.
This puts you in a much better position to stay up to date with changes in your system, but also significantly speeds up your learning. Be it technologies, concepts or most importantly - codebases. The traditional timeline for onboarding to a new codebase or project began to collapse from weeks to hours. I can tell that from first hand experience.
Gains and costs
So with all that increased speed, where are the actual productivity gains?
I won’t cite number of PRs, or even worse - lines of code. I consider those vanity metrics.
However we were able to accomplish things that were postponed for a long time or would not be done at all. This is where I think the real productivity gains are visible.
Projects that were estimated for months of engineering effort took weeks or even days.
For example:
We replaced generic serialization in few parts of our ingestion pipeline with hand-written codecs. Well, agent-written.
Writing and maintaining such codecs by hand is tedious and error-prone.
What made it work was a tight verification loop. The agent could compare its output byte-for-byte with existing serializer, so it could keep iterating. That made it cheap enough to do it and it cut CPU utilization in half.
Or a rewrite of a legacy service everyone had more or less forgotten about. We managed to rewrite it in Rust in a little bit over a week. It didn’t work right away, though. The agent missed edge cases that only showed up with real traffic. We caught them by shadowing production traffic to the new service and comparing results, then moving traffic over gradually using the strangler pattern, with both versions running during the transition.
In both cases the old code was the best spec we had.
Overall, we managed to pay off a big chunk of our tech debt. Migrating libraries or transforming internal commands into polished apps (by a team of backend engineers) were done mostly on the side, without much dedicated effort.
Though the gains are not for free. Literally.
Obviously agents can be really costly. Industry quickly went from tokenmaxxing to smart routing and open models. This is an interesting topic, but I will not cover it here. Lately my subscriptions cover all my needs. And believe me I am quite a heavy user.
That said, bills are not the only cost.
With a few agents running in parallel, my day is jumping between sessions: answering one agent’s question, reviewing another’s output, unblocking a third. Each switch is small, but together they wear you down. The “getting into the flow” I mentioned earlier is mostly gone, replaced by short bursts of attention spread across many sessions.
Agents make it very easy to keep going. There is always one more prompt to send, another session running in the background, a quick check on what the agent did before dinner. Work no longer stops when you stop typing. Are we becoming addicted to agents?
More than half said yes, and only a third said no. Nobody forces us to work longer. The feedback loop is just so fast and rewarding that stopping feels like wasting time.
Ironically, seems like the thing that made us more productive at the same time made us work even more.
On top of it, the field itself never stops moving.
I’m too young to have lived through the big software breakthroughs of the past. Still, I believe none of them moved as fast as what we’re living through now with AI and agentic coding. Tools, models, and best practices change almost weekly, and something you learned a month ago can already feel outdated. That pace takes a real toll.
It’s overwhelming to keep up, there’s a constant fear of missing out on the next big thing, and underneath it all sits uncertainty about what our work will even look like in a few years.
I asked colleagues how they feel about the future of software engineering.
People picked about four emotions each, and I split them into positive (Excited, Optimistic, Hopeful, Curious, Empowered, Confident, Motivated, Surprised) and negative (Skeptical, Overwhelmed, Anxious, Cautious, Insecure, Threatened, Frustrated, Pessimistic, Confused).
Overall, negative mentions outnumber positive ones 87 to 71.
The single most common emotion is “Curious” (55%), but it rarely stands alone: of the 22 curious respondents, 19 also picked something negative. Even enthusiasm comes bundled with worry: 12 of the 13 who picked Excited also picked a negative emotion. Over half the group selected at least one of Anxious, Threatened or Insecure. Just 4 chose positive only.
I’m genuinely excited about what’s possible, but I think it’s worth admitting that this speed is exhausting, and that it’s okay not to chase every new release.
The timeline is wild. In just a few years we went from tools that autocompleted a single line, to chat assistants that wrote whole functions, to agents that can read a codebase, plan changes across many files, run tests, and fix their own mistakes. The famous winter break of 2025 with Opus 4.5 was less than a year ago. Thus it is really bold trying to predict what happens next.
There have been significant voices inside frontier AI labs arguing that development should be slowed or paused due to lack of enough safety measures. I really wish safety would get at least half the attention that chasing meaningless benchmarks gets. Nonetheless, I don’t think models are going to hit the wall anytime soon.
So, 10x what?
If you ask me, a bit of three. 10x output, definitely. Code gets written faster than ever and work that sat in the backlog for years finally gets done. 10x productivity? Yes, but not where people usually look for it. You’ll find it in projects that otherwise would never have happened. And 10x frustration? Sometimes. The pace is exhausting, and the survey shows I am not the only one feeling it.
What I am sure about is that the job didn’t shrink, it moved. Less typing, more deciding. Agents took over the part of the work I miss the least and left me with the part that matters the most - understanding what we build and being accountable for it.
So use agents for everything they are good at, just don’t hand over your understanding along with the code. And you don’t have to chase every release to stay relevant. Find what works for you, go deep on it, and let the rest wait. Chances are it will be outdated next week anyway.
Judging by the survey, curiosity rarely comes without some worry, and I think that’s a healthy combination. I’m still curious, sometimes worried, and definitely more productive. 10x? Hard to say. But I wouldn’t go back.