The new reflex: delegate everything
Over the past few months, we’ve seen the rise of AI agents capable of:
- generating full codebases
- modifying existing projects
- automating complex tasks
- making technical decisions
The reflex is simple:
“I’ll just let the AI handle it.”
And it works.
At least, on the surface.
The problem: we no longer know what we’re running
When an agent:
- writes code
- modifies files
- restructures a project
who actually understands what’s going on?
In many cases:
- the code is accepted without review
- the logic is not fully understood
- entire parts become opaque
We gain speed.
But we lose something fundamental:
understanding.
A system that works… until it breaks
It’s the same pattern we’ve seen before:
- it works
- we stack layers
- we trust it
- then one day… it breaks
And when it does:
- no one knows where to look
- no one understands the full logic
- the system becomes hard to fix
The question no one is asking
Today, the focus is on performance, productivity, speed.
But very few people ask the real question:
what happens when we no longer control what we execute?
Because tomorrow, the issue might not be:
- a bug
- a mistake
- a bad implementation
But something deeper:
total dependence on a system we don’t understand
What if we start hearing about compromised agents?
Today, it may sound exaggerated.
But we’ve already seen:
- compromised dependencies
- libraries injecting malicious code
- popular tools becoming attack vectors
So the question is simple:
if an agent controls part of your code… what happens if it’s compromised?
And more importantly:
who is able to detect it?
The real issue isn’t AI
AI isn’t the problem.
It’s a powerful tool.
Useful.
Sometimes impressive.
The problem is how we use it.
Assistant vs pilot
There’s a huge difference between:
- using AI as an assistant
- letting AI take control
In one case:
- you gain speed
- you keep control
In the other:
- you accelerate
- but you lose understanding
Taking back control
Using AI agents isn’t a bad thing.
But a few simple principles make all the difference:
- understand what is generated
- limit automated layers
- avoid delegating critical parts
- keep logic simple and readable
Conclusion
Technology is moving fast. Very fast.
And AI agents will take more and more space.
But as automation increases,
control can decrease.
And in technical systems,
speed is not what makes them reliable.
Understanding is.
Top comments (13)
It's not true for everyone , I understand what ai is generating , if you don't know anything,that anything is pronounced vive. If a person don't know coding is vive coding. Even you understand the code ,still Ai does mistake ai.
I think my point was misunderstood a bit.
I wasn’t talking about “AI helping developers write code”.
I was talking about autonomous AI agents controlling large parts of a system without visibility or understanding of what is actually happening underneath.
Also, saying “people who can’t code depend on AI” feels a bit simplistic.
Developers already depend on operating systems, frameworks, IDEs, compilers, Git, libraries, servers, documentation, StackOverflow, etc.
AI is still a tool.
The important part is not whether a tool is used or not, but whether the person using it understands, verifies and controls what is being built.
The risk isn't AI as a tool, it's the gap between what a system appears to be doing and what it's actually doing underneath.
That gap is exactly where security vulnerabilities live too. Autonomous agents making API calls, handling auth flows, or processing sensitive data often without the team fully understanding the attack surface they've just created.
At Faultline Security we see this a lot in AI-powered SaaS products: the code looks clean, the product works, but the actual security behaviour under the hood hasn't been tested by anyone. A human finds the things that neither the developer nor the AI model thought to check.
_Understanding, verifying and controlling _what's being built that applies to security posture just like the product itself.
Exactly. The loss of visibility and deterministic control is the part that concerns me the most too.
Reliance on agents is increasing fast, and so are the attacks targeting them (prompt injection, tool misuse, etc). But somehow security still gets treated as an afterthought.
Agents are genuinely powerful, great servants, great coworkers. But right now, the builders deploying them still need to deeply understand what they're putting into production. You can't secure what you don't understand.
For me, this all comes down to one principle: an agent can be an excellent servant, but a terrible master. Delegation is fine, but only if a human expert remains in the middle, reviewing, understanding, and taking responsibility for the outcome. Code without ownership is just a black box waiting to fail. Even with guardrails, an autonomous agent can drift in ways no one anticipates. That’s why the final accountability must always stay with the human, not the automation.
Exactly.
Automation is not the problem, loss of ownership is.
A system that no one fully understands becomes fragile very quickly, especially when it evolves over time.
That’s why I prefer systems where logic stays readable and controlled, even after deployment.
It's like cloning a repository from an unknown source and using it in production without checking it first. 🧐
A repository is static. You review it once.
An agent is dynamic. It keeps modifying, retrying and acting over time.
That’s a very different risk surface.
That's true, the risk is much greater here.
if you are leveraging the clone command- git clone , it should be trusted source and you should't copy ,you should type by your hand.
No but if you do, each loop needs guardrails -> no commits until all tests pass.
Guardrails don’t equal control.
When an agent can read, modify, retry and loop on a codebase, this is no longer a simple script.
Tests only validate what you anticipated.
They don’t guarantee that what’s running is still understood.