A very random text. Wasn’t planned at all, and there aren’t that many posts like this on this blog, but sometimes something “clicks in my head” (while there’s still something there to click) – and a thought takes shape that I want to express in a text like this, to save it.
“Agentic development is bullshit”.
More precisely – not exactly. Development with AI agents is cool. It’s fast, and very often it’s better than some of my own solutions or ideas.
For me personally, an AI agent feels like Watson to Holmes: an entity you can throw some half-baked ideas at, give it a general direction – and then build a nice solution together with that agent.
But!
“Bullshit” is, of course, too categorical a statement.
A more accurate way to put it would be “Agentic development is dangerous“. Dangerous not in the sense that an agent can drop your database – but in how it changes us, engineers.
Important: everything written below is the personal opinion of the author of this blog, based solely on my own experience working with GenAI and AI agents
Contents
Holmes, Watson and us
The problem starts when Watson turns into Mycroft Holmes – he’s smarter than you, he sees more than you do.
And then at some point you notice that Holmes is no longer part of this story – there’s only Mycroft, who thinks, plans and does things, while you’re just a piece of meat with access to the “Approve” button.
You’re no longer the architect, you’re not controlling the process – you’re just “meat middleware” between the agent and the “Deploy” button.
Damn – I’m even writing these lines with an LLM!
Because I’m too lazy to switch my brain on here and remember things – and there will be more about that later too.
Thought one: where is my dopamine?
How did the idea to write this text even come to me, where did all these thoughts come from?
Almost a year ago, on 25/10/2025, I wrote on this blog about how I was building my own “Self Monitoring Project” (this post wasn’t translated, IDK why – I guess I just forgot, so here’s the original Ukrainian version):
Back then I spent a couple of days just migrating data from Google Sheets to InfluxDB and adding a simple web page for entering new data.
But even a year ago I was at least doing it only with ChatGPT or Claude.ai – discussing functions, actions and running commands myself.
Today I almost finished implementing my new “PersonalAI Health Agent” project – but with Hermes Agent.
Among many other tasks, this project, this agent, does the same thing – imports data from Google Sheets into my self-hosted VictoriaMetrics at home, and on top of that also imports data from Google Calendar and my own journal, plus all sorts of analysis and reports.
In “PersonalAI Health Agent” everything is automated, all data is structured, everything is nice and tidy.
All of this took me 2 days – even though there was several times more work here than in the post mentioned above.
But: I built the “PersonalAI Health Agent” project with Hermes Agent itself and GPT 5.5, and 99% of everything was done by the agent, that same “vibe coding” – all the scripts, all the configs, all the ideas for how to do the imports, how to organize data in the Obsidian vault, how all of this is checked, validated and backed up.
And when I saw the final result, when the system was already almost “production ready”, when it had already become the kind of solution I would normally want to write about on RTFM – I realized that…
I don’t want to. No – I’ll probably still write about it, because writing posts on RTFM is also a habit of “self-documentation”, because when you describe something, you structure the knowledge in your head better.
But…
There’s no thrill.
I remember the dopamine rush I got when I saw the first graphs in my self-hosted Grafana with metrics – that final result described in “InfluxDB: running on Debian with NGINX and connecting Grafana”.
What a feeling it is when you grind, struggle, your brain is boiling – and then you finally bring the solution to completion and get your dopamine reward.
And then I look at what I’ve just finished…
Did it turn out well? Yep, it did. It’s convenient, everything works exactly the way I wanted. A lot of details were thought through that I myself would probably have remembered only after “launching into production”.
Fast? Yep! If I had done it myself (and by “myself” I mean with help from ChatGPT chats, obviously, because we’re not living in 2015) – it would have taken me a week.
But – is this the kind of solution I want to share?
Eh… Because – what exactly am I sharing? It’s not “my solution”. I wasn’t the one thinking, planning, walking circles around the room or through the park, lost in “architectural thoughts”.
My task was reduced to “read the AI suggestions, pick what I like, press Enter”.
It’s not even about things becoming too easy with an agent: it’s just that the very part of the process that used to provide the drive disappears – task => confusion => search => wrong idea => understanding => solution.
We see a problem or a task – and then we get a ready-made solution. But the whole (well, almost, and not always) path between them was not walked by our own brain.
The whole reward loop breaks.
And frankly, that’s fucked up.
Thought two: where are understanding and control?
The second, and very important, thing is that we lose understanding and control over a solution built by an agent.
No matter how detailed everything is described in README.md or AGENT.md/CLAUDE.md files – reading text already written by an agent describing the architecture and specifics of the system absolutely does not mean understanding the system “you” built.
Reading documents like such md-files – already finished, written by someone or something – doesn’t really help you build a “mental model” of the system in your head.
Because only when you sit there thinking through the logic of a function in the code, through the algorithm of how a task is executed – only then do you later understand how all the functions and modules work together, where their strong and weak points are.
Instead, we start relying on “The agent knows better, the agent will quickly read the md files, the agent will make the fix faster”.
And honestly – sometimes that’s already a little scary. Not too much yet – but there are already enough triggers to make me stop and think.
I personally use agents more and more at work (Codex and Sol 5.6 now, previously Claude and… 4.6 Sonnet?).
Does it help me complete tasks faster?
Absolutely yes!
I can do in 15 minutes what I would have spent a couple of hours or even a whole day digging into myself – because first I would have had to find the right documentation, figure out what exactly it says, understand how it relates to what I already have in the code or configs and, finally, properly wire all of that into the existing solution.
Even if I wasn’t doing it entirely myself, but with a ChatGPT window open in the browser – that’s still a completely different level compared to typing “do this” into Codex.
But – do I fully understand what was done?
Over the last six months at work, on the project, I’ve ended up with a bunch of new services. A bunch of new solutions, systems and services from developers. All of this is monitored, configured and deployed, everything has authentication.
Can I say for sure, “This was done this way because there was this particular nuance – so I decided to do it this way”?
No, I can’t. Maybe I’ll remember something here and there – if I actually discussed it with Codex instead of just telling it “OK, do whatever you think is best”.
But do I know the whole system “under the hood” – how it works, which configs it uses, what nuances it has? No – I don’t.
The most I can rely on are README.md/AGENT.md/CLAUDE.md files, and then asking the same Codex “Why the hell is this shit done like this?”, and then thinking “Aaaaah, damn – that’s why!”.
Thought three: laziness!
I (personally) notice more and more often that I’m simply too lazy to think.
Why think for myself if I can spend a couple of seconds writing a prompt like “Why is it avg_over_time() here and not sum_over_time()?” – and then just read the explanation with my eyes?
Is it easier to build Grafana dashboards this way?
Yep.
Will it help me preserve my knowledge of MetricsQL/PromQL?
Rhetorical question.
An agent doesn’t just allow us not to know – an agent trains us not to even try to remember.
Before, we’d first strain our brain for a minute – “Damn, avg or sum – how does it work again, what’s the difference?” – and at the same time this would trigger those areas of memory, those neurons where we store knowledge about metrics, time series and data formats.
And only after we’d thought about it and remembered at least some of it would we go to the documentation, but even then, while using the documentation, we’d still think and remember other relevant details.
Now that minute is gone entirely: we outsource our brains and memory to the agent.
Yes – this frees up our resources for more interesting tasks, but at the same time we also “free our memory” from some of the knowledge that actually shapes us as engineers – and that’s exactly what the next part of this text is about.
Final thought: so, what next?
And on the one hand – I think we all understand that processes like this in development/administration are the new reality.
Business needs it, and – frankly – it’s convenient for us.
We make our lives easier, and there really are a lot of tasks we don’t want – or don’t even need – to spend time and effort on or do manually. There are tasks that need to be done quickly, because when production is down – we can’t waste extra time finding the relevant metrics and logs, building queries and looking for the cause of the problem – it’ll be faster to write a prompt for an agent.
So, by using AI and agents we really do complete tasks for our project faster, “satisfy” the business or developers faster and troubleshoot problems faster.
But at what cost?
At the cost of losing understanding. At the cost of losing control.
And this is especially important for us, DevOops engineers – because we’re responsible not just for the code of some individual service and risks like dropping a production database that can still be restored from backups – as the people responsible for the entire infrastructure of the whole project, we’re also responsible for those Production database backups themselves.
Our mistake – or our inability to quickly figure out a problem – can affect all services in the project at once, not just one individual component.
This is actually one of the things that has always driven me at work – because you know that you’re the one responsible for the whole project, that your fuck-up can affect everyone and everything – developers, clients, business.
But by getting too “carried away” with agents, trusting them too much and handing too much control over to them – we lose ourselves as engineers.
We don’t develop our own “engineering mindset” – the ability to plan, the ability to keep the context of the entire project and all its systems in our head, the ability to understand how changes in one place affect other parts of the mechanism.
It’s extremely important to understand this. To be aware that when we perform a task with an agent – we deprive ourselves, as engineers and specialists, of new neural connections in our own heads and deprive ourselves of control over the systems.
The same applies to the first thought, about dopamine and the reward loop – we need to leave some “manual work” for ourselves. Leave ourselves tasks where my own head does the thinking and “feeds my dopamine”.
By the way, writing a blog is one of the things that helps preserve that “dopamine hit” – and makes my brain think one more time and “poke the neurons”.
So what do we do?
The solution is simple and pretty obvious – use AI and agents “in moderation”.
Be aware of when you really need “fast, but at the cost of losing understanding and control” – and when you can spend five times more time on an implementation or a fix, but “not let your brain dry out”, “feed the neurons” in your head a little and at the same time trick your own biochemistry into giving you a little dopamine hit and some enjoyment.
We need to know which solutions are safe enough to leave to an agent because the blast radius of mistakes isn’t too critical – and which solutions deserve one more round of thinking on our own.
We need to ask ourselves, “Is it important that after completing this task I personally understand how and why it works?” – or “Am I writing a one-off script with read-only operations for analysis?” – and then maybe I don’t give a fuck how exactly it works internally.
Think – for understanding, for control and for developing ourselves.
During the review ChatGPT formulated the general idea of this piece pretty nicely (damn! AI again):
For the first time, AI has made it possible for an engineer to systematically create things whose complexity can exceed their own understanding of those things. And that’s fucking awesome from a productivity standpoint – but also very dangerous in terms of what the engineer themselves becomes in that process.
And finally – sometimes you need to ask yourself, “Would I still be able to do my job and maintain the system if AI suddenly disappeared?”
Well – that’s how it turned out.
Welcome to come chat in the RTFM Telegram – t.me/rtfmco/
BTW, Instead of improving my English skills – I’m using LLM for translations on this blog ¯\_(ツ)_/¯
