Lately I've been using generative neural networks in agent mode more and more in development; for simplicity, let's call it vibe coding, like everyone does. Why not? These days every toaster and its grandmother is vibe coding and telling everyone how great it has become. And in terms of opening up development to those who couldn't develop before, it really is great, by the way.
But those who could develop on their own before still look at the subject from a slightly different angle. So I decided to let my thoughts wander a bit, grumble, be a bit of a bore and reflect not on how to set up Codex or an MCP server, or how to unleash Claude Code on KWork. But on the effects, on the inevitable changes that neural networks have brought, are bringing and will bring into our daily work — into software development by living human people.
First, let's briefly define our place in space and time relative to the very phenomenon of neural networks (here and below — in software development). It's too late to discuss whether they are needed, whether they help, whether we should use them. That question is off the table. If you somehow haven't started yet, you should. The cat looks at the clock and says: it's time!
So,
What it changes
When you are the lead on a project, most of the work comes down to the following cycle. You study the requirements, plan the architecture, break it all down into tasks, attach estimates and assign them to developers. Then you get the results from the developers, do the review, study the implementation, discuss the bottlenecks and subtleties, and in the end you are responsible for the finished task getting to production.
And in this sense, developing with an agent is very similar to a lead's work: you do the same things, discussion included, only the part where you wait for the results goes somewhat faster. And the part where you describe, discuss and check them, on the contrary, takes somewhat longer. So if you're a lead, or just inclined to exactly this kind of work, vibe coding clicks with you right away.
Plus, some may like that the machine isn't alive, and with it you don't have to try to master all those soft skills like talking so that people listen to you, or talking to people at all.
When you are a developer, the process is a bit different. You get a task from somewhere (from the team lead, the boss, the client, yourself), write it, then test it, then send it for review. And suddenly you have a miracle tool in your hands that takes away writing the code and even part of the testing. What can we say about this part of the work? It is:
- Usually the longest — actually implementing the task, writing and debugging the code usually takes longer than all the other stages. Sometimes it doesn't, but then a neural network won't speed the task up much either.
- The most balanced — the task is already set, the architecture is designed (or handed to us), we have more or less figured out how we're going to work. All that's left is the technical implementation. Tap the keys, think, tap again, look, check, think, tap…
And this is exactly the vibe we lose. The balanced and fairly long part of the work, when we can write code, maybe even in a state of flow, while controlling both the pace of writing and the intensity of our thinking along the way. That's it, this part is gone. All we can do is watch the AI's reasoning until our heads spin from the scrolling lines.
But. Instead of coding, we have to set the task twice as clearly (we're not setting it for ourselves) and check the result five times as carefully (again, it wasn't us who wrote it). And there's almost no time left to rest between setting the task and checking it. As a result,
The cognitive load goes up
We save time on the more routine part — writing the code, but in return we have to think much harder and longer. Even if we assume that in total we would have thought just as much if we had written it ourselves, with a neural network it takes less time. The load on the brain goes up.
Yes, of course, in the end we'll solve more tasks, but by cutting out the most routine part of the solution, the long but not always hard one, we leave a concentrated load on the brain as we move on to the next task, then the next one, and the next. Of course, we can take a break: just do nothing, since the robots did everything faster anyway. But then we'll lose the productivity race to someone who didn't take that break and so will get more done while we relax. Not an option.
And if, again, it's less scary for team leads, since this is mostly how they work anyway (though with a neural agent as the developer the load is still higher), it may be much harder for plain programmers without that experience. So it may be time to stock up on vitamins that boost brain activity.
Over time, of course, the brain will adapt — just as it adapted to writing, reading and endless scrolling on phones. But for now we'll have to try hard.
Robots do the routine, humans indulge in pursuits worthy of humans — creativity. Isn't this the dream of the progressors?
It's worth noting that a robot assistant can also reduce the cognitive load. Each of us has surely come across
Tasks you don't feel like doing
Because it's something unclear, because you need to dive in for three hours and you only have an hour and a half free right now, and it seems better not to start. Because it's shotgun surgery — you need to make lots and lots of small changes all over the project. Just a feeling of sudden inner gloom every time you see this task in the backlog.
I've certainly run into this, and not only myself. Once I even had to ask a person to leave a project, because he dug in his heels, said he didn't want to do this task and had to be given another one.
Here the agent is a great help. It can go through the API documentation, think over the architecture, and scan the project to find those 150 files where a couple of lines need changing. And write it all down into a clear plan. With a helper like that up your sleeve, the thoughts of "I don't want to do this" quickly go to zero, since the barrier to entry into an unpleasant task gets lower.
And that means that, along with the load, our
Estimation of work tasks
changes rapidly too. Yes, sometimes tasks we used to budget 50 hours for get solved in 25, or even 15, hand in hand with an AI agent. But the thing is, correct task estimation is still the most important part of commercial development. And with all the modern agile methods, story points, PERTs and planning poker, at its core it's still empirical.
We break tasks down and calculate estimates based on our past experience of solving the same or similar tasks. And so we can't just go and cut all the budgets in half. Not yet. There's no long-term experience yet that lets us say that if we take this black box and put any task into it, it will become exactly twice as cheap (and not three times, or 20%). That's the experience we have to build up now.
Yes, the act of writing code has become faster. But the process of planning and setting tasks takes longer (and is more precise in some ways). The process of checking takes longer and is more demanding. And part of the effort didn't evaporate from writing code, but flowed over into other processes.
By the way, overestimating our abilities with a wonderful new tool in hand can play a nasty trick on us at first. We took a task and split it into parts to make it easier to grasp and know where to start, solving it piece by piece. And before, we would have planned — according to our estimates — what we'd finish today, tomorrow, and so on. We'd finish each subtask, check it, roll it out, as usual. But now we have a tool in our hands that cracks our little subtasks like nuts. Look how fast, close this one too, and another one. Oh well, it's going well. Writing prompts is easy and pleasant. Monsieur Claude, close all the subtasks at once, s'il vous plaît.
And if you get into this flow, catch the notorious vibe of coding, you may end up looking at a PR of 100+ files. And what do you do with it? We split everything into subtasks precisely so that it would be easier for our brain to solve a big task by solving the small tasks that add up to it, one at a time. And now we've got a finished big solution to a big task, which our brain has to grasp all over again — to check, fix and approve it. For which, apparently, we'll have to break down the solution itself all over again (see the increased load). Because if we're coding not a little tool for ourselves but a project for money, we need to have
Trust in the result
Generative neural networks are often described as a black box: put a task in, take the result out, don't torment yourself about what happened inside. But while we can agree not to torment ourselves, there's no way we can just take the result and accept it. We have to know that the result is what we need, that it works as it should, that the technical debt created by this result is minimal and that this result hasn't broken anything.
Let's start from the end — tech debt and regressions. The code we wrote ourselves we checked along the way, we know how it works — we need less effort to fully approve it (even if we missed a couple of bugs and didn't notice). But with someone else's code, figuring it out sometimes takes time comparable to developing that code all over again. Yet we can't keep rejecting it forever either, since the work has to move forward. And given this pressure of the development pace, there's always a risk of accepting something we didn't fully understand. All the more so since shutting your eyes, waving your hand and taking the step is tempting: the brain will gladly save energy when it can.
So errors, regressions, antipatterns and even vulnerabilities will crop up every now and then, no matter how hard we try to be demanding and vigilant. They crop up in teamwork now too, a coding agent doesn't change anything here.
But what an agent can definitely change is our attitude to tests. Of course, I've long been drawn to TDD, but in today's conditions with neural network agents, tests are simply our everything. They are our criterion of truth. They are what will keep us from going cuckoo when the neural network's context window is no longer enough to notice what broke after a new feature. But most importantly, agents write them very well.
Especially those very 10 validation edge cases that you know need checking, but writing tests for them is so tedious and dreary… Write one, tell the agent, and it will add the other 9 and 3 more you didn't think of.
I've been checking this for the last year and a half or so; tests are actually where I started my little baby steps in vibe coding.
Of course, it's not enough to ask the agent to work by TDD — I tried, it still forgets to test some things. You need to understand testing a bit yourself. And under the influence of neural networks, I think this is something all of us should pay attention to.
And once there's a test suite, refactoring against it, reducing technical debt and making sure there are no regressions, is a pleasure, whether by hand or through a neural network.
But there's still the first part of what we have to know: that the result is what we need, that it works as it should. It would seem that everything is clear here: if we're such experienced programmers, we should be able to tell by looking at the result. Otherwise, what kind of programmers are we?
But will we be able to keep understanding it?
This problem somewhat echoes the question "Should a team lead write code themselves?" Yes, they should, but not to keep their hands from withering. It's because if they don't, after a while the code of their team — especially if they're cool, smart guys — will start raising questions: what is this new solution? I haven't seen it before.
And the problem isn't that you have to figure it out. It's that this newly seen solution may have three alternatives you didn't see at all. And if this happens often enough, the lead may turn from the one who leads into the one who is led. Into someone who silently clicks "Approve", rather than offering solutions and innovations and bringing value with their code reviews.
On top of that, without regular practice we won't make our own mistakes — so we won't learn about them and won't be able to tell anyone about them.
And while with developers you can more or less get by like that, with a neural network it won't work. You have to keep writing code yourself — and this isn't about how we'll survive in the woods with one knife when our internets and electricities get cut off and tokens become more expensive than gasoline. It's about being able to find a solution better than the one the agent offered. You need that to see when the code is good enough to accept, and when it's bad enough to reject.
What's more. Where will new patterns, new examples of code development come from, if code is now developed by neural networks, while neural networks learn from our code?
As David Lynch told us through the charming mouth of Monica Bellucci,
We are like the dreamer who dreams and then lives inside the dream. But who is the dreamer?
Over the past decades we've dreamed up billions of lines of code, feeding them to the generative dreamer. And now we see, wide awake, how these lines come together into new dreams with only our indirect participation. But here's the question: who will dream up new dreams when the old ones are no longer enough? Who will create new patterns, architectural techniques, ways of solving problems?
Who, if the value of yet another article "How to integrate A with B?" tends to zero as fast as the reader who asked that question gets ready-made code from a neural network in response? If there's nobody to read this article, there's no reason to write it. And if nobody writes it, the neural network won't read it either. But its training has to go on. It has to, right?
At the same time, programming keeps changing. These days few people need to be able to break bits into flags in their head, or remember De Morgan's laws. Compilers spare many (though not all) of us from thinking about registers, DMA, SIMD and other low-level things. Many abstractions and patterns are needed only by people anyway, to understand and maintain code better.
We can write a function following DRY so as not to repeat code 20 times — and the compiler will paste its body into the code 20 times, because it's small and that's faster than messing with the stack.
Perhaps generative neural networks, in turn, will make knowledge of good architecture practices, as we understand them today, unnecessary for the average developer. But how exactly is still unclear. For now, it seems to me, this knowledge has become even more valuable.
In conclusion, I'd like to say this. Neural networks as programming agents are a wonderful tool. We do a lot with it, and we'll be able to do even more. But you can't claim with 100% certainty that all of this now comes at the price of one dinner a month. We have to adapt, think more, decide, plan. Stop in time. Reflect in time.
And yes, tap your card on the terminal in time to pay for extra tokens.