I strongly believe software engineers, security engineers, and IT professionals won't disappear because of AI.
Even if AI writes most of the code in a fully agentic workflow, I believe humans must stay in the loop. That includes a “dark factory” where agents write, review, and ship code.
People should take ownership of the system and decide which features should go out and which shouldn't. They should raise concerns about features, make architectural decisions, and decide how to handle scaling. There should always be trustworthy people who understand the system well enough to support it and act fast when things go wrong.
Letting agents run your entire business without technical oversight is like trusting an AI agent to design your home's electrical system and assuming nothing dangerous could go wrong.
Of course, trusting a human can also lead to mistakes. But I believe a professional who understands the work and uses automation effectively can deliver better results. If I hire an electrician who uses tools to work faster and check their work, I benefit from both their expertise and those tools.
I see software engineering the same way. I think the goal should be finding the right balance: human experts using AI effectively to deliver useful features faster and with better quality.
A practical use case of agentic workflow keeping human in the loop
You can use agents to create skills around clean-code practices, monitor errors, track issues, and regularly check code quality. I believe experts in engineering, cybersecurity, and infrastructure should supervise those workflows, evaluate the results, and improve the instructions when something goes wrong.
For example, humans define what an agent should investigate, how it should approach the problem, and what it is allowed to do. Monitoring agents check tools like PostHog, Sentry, or Datadog through configured integrations and record issues in a shared system. Other agents evaluate those reports and propose who should handle them.
The relevant engineering team reviews that classification. If it looks wrong, the team updates the instructions and asks the agents to try again. Once approved, development agents work on the issue and open a PR. Humans review the changes, request revisions when needed, and approve the merge. The team then validates that the issue is resolved in the appropriate environment.
Architecture, code design, database patterns, and tool selection still matter throughout this process. I don't expect a general-purpose agent to understand every trade-off in my business without clear context and direction.
This is the balance we should aim for: agents doing continuous work, with knowledgeable people checking results and deciding what to approve or decline. Building a product that scales and delivers value to clients still needs that human ownership.
Conclude
I don't want us to keep shipping features nobody uses, or slop apps that barely work and fall apart when they need to scale. I want us to use AI and agentic workflows with humans in the loop, building reliable software that people and other agents can use efficiently.

Top comments (5)
The oversight layer only works if the human can see what the agent actually did. A log of tool calls with the arguments and the resulting artifacts is cheaper to audit than a summary. In a SOC that is the same requirement as a detection rule, the reviewer needs the evidence and not the conclusion.
Appreciate your comment, Sammi. I agree, observability is one of the most important and fundamental parts of a system, no matter if it is an ai agent or software service.
For ai agents I find Langfuse extremely helpful and flexible since it’s open source.
A summary alone would leave too much guesswork in that review step. Seeing the actual tool calls, arguments, and artifacts makes the approval decision a lot clearer.
Hey Odinaka, thanks for your comment. Yes I agree, observability is important. Although, this is a high level analysis and does include logs or artifacts handling. The tools or optimization techniques that each team uses varies based on their product and working environment.
tolerate the partial answer but mark the gap, otherwise one slow service takes down the rest.