AI Should Make Engineers Better, Not Replace Engineering
AI is becoming a major part of network operations and software development and we think that ISPs that want to be successful should begin adoption as soon as possible.
At Archous, we use AI internally and are actively working to extend those benefits to customers as a naturally integrated part of our service offering. Rest assured though, for us, using AI doesn’t mean removing experienced engineers from the process.
Our approach is simple: AI should make good engineers more capable, not replace the engineering behind critical infrastructure.
AI in Network Operations
AI is very good at processing large amounts of information quickly. It can analyze telemetry, alarms, configurations, logs and historical data at the same time.
With the right integrations, context, and guardrails, it can identify relationships between events, investigate problems and recommend what an engineer should examine next.
That is the capability we’re working toward:
AI observes → investigates → recommends → engineer reviews → engineer approves → results are validated
The human part still matters because networks aren’t always as straightforward as the data suggests.
A backup circuit might be undergoing maintenance. Documentation might be wrong. An unusual configuration might exist for a legitimate reason. A proposed change might fix one problem while creating a larger one elsewhere.
Sometimes the most important decision an experienced engineer makes is: “Something about this doesn’t make sense. I’m not changing it until I understand why.”
AI can help that engineer reach an answer faster. The engineer should still own the decision and remain accountable for the execution.
The Same Applies to Software Development
AI has made it remarkably easy to create software. You can describe an application, iterate on it and end up with something functional without fully understanding the code underneath it. That’s useful for prototypes, simple tools and experimentation.
Things become more concerning when the software supports critical operations.
An application working today doesn’t tell you whether it has a sound security model, sensible database architecture, appropriate testing, maintainable dependencies or a reliable recovery process.
These are key distinctions between “vibe coding” and AI-assisted software engineering.
AI should make a software engineer or architect dramatically more productive. Let AI generate code, tests, documentation, and repetitive implementation work. A real human who understands software architecture should still decide how the system fits together and review what goes into production.
Just Because We Can Build It Doesn’t Mean We Should
AI makes it tempting to look at every piece of software an ISP uses and ask:
“Why are we paying for this? We could probably build it ourselves now.”
In many cases, that’s technically true. The harder question is whether you want to own and maintain it. Especially in the context of the current operational burden on your staff and what that burden may look like years from now.
Think about it. You’re not paying a software vendor only for the code that exists today. You’re also paying for years of testing, upgrades, security fixes, compatibility work, documentation and edge cases discovered across many deployments.
If you replace every commercial application with something homegrown, you take responsibility for maintaining every one of those applications. For an ISP, that can quickly mean running a software company on top of running the network and other functions of the business.
Where “AI Slop Creep” Becomes a Problem
The bigger concern isn’t usually one terrible AI-generated application. It’s what happens gradually.
Someone needs a feature, so it gets built. Another system needs an integration, so that gets added. Six months later, somebody modifies it again. Eventually, several internally developed applications depend on each other.
Every individual decision might have made sense at the time. But eventually you can end up with a stack where every application works and nobody fully understands the architecture of the whole thing anymore.
That’s what we think of as AI slop creep.
The danger appears when something significant breaks and the people troubleshooting it must determine not only what the software is doing, but why it was designed that way in the first place.
AI has made code cheap. It hasn’t made complexity free.
How We Approach AI With ISPaaS
At Archous, we know we can’t be experts at building every type of software our customers need, and we don’t think we should try.
Our existing ISP as a Service (ISPaaS) platform uses established software including:
- PRTG for network monitoring
- Unimus for configuration management and backups
- Nautobot as the network Source of Truth and automation platform
- WANGuard for traffic visibility and DDoS detection and mitigation
- Whalebone DNS for centrally managed DNS with policy enforcement
- AnyDesk for secure remote desktop access
- Big Network for resilient ISP pseudowires and service delivery VPNs
These products solve different problems, but their real value comes from how they work together.
Today engineers configure these tools based on their own best intentions but ideally we want to move towards an AI-driven holistic operating approach around good network hygiene. This starts with implementing accurate source-of-truth data which is necessary to feed all of the various software systems to yield consistent configurations, reliable backups, version control, security, and visibility (essentially properly maintained network devices and servers).
The point being is that the approach to how data is populated directly affects day-to-day operations. A clean network should generate fewer alarms and preventable incidents so that when something does go wrong, there is less noise and better information available to determine what happened.
Our goal isn’t simply to detect outages faster. We want to reduce preventable problems and make the remaining ones easier to detect, understand and mitigate.
It’s Also About Business Continuity
Using established software is also part of how we think about business continuity.
Through ISPaaS, we can incorporate commercial tools into the service and spread their cost and operational overhead across our customer base. That gives smaller operators access to a broader operational stack without having to purchase, deploy and maintain every component independently.
We also compartmentalize systems through individual instances, containers and other isolation mechanisms where practical.
The last thing we want are our customer’s entire operation dependent on one enormous proprietary Archous application.
If circumstances change, established platforms also provide portability. Other engineers understand PRTG, Nautobot, Unimus and the other technologies we use.
The goal is to have customers to stay with Archous because of the engineering and operational value we provide, not because we’ve made it technically painful to leave.
We Build Software Too
None of what has been expressed here means we’re against homegrown software.
Archous develops in-house applications including IP Provisioner, ArchRADIUS, MACdb, and the upcoming ArchNOC portal + ArchAI agent.
The difference is that we’re deliberate about what we choose to own.
If an established product already solves a complicated problem well, we’d generally rather integrate with it than recreate it. When we build something, we want it solving a specific business or technical problem with clear boundaries, guardrails and human oversight.
That being said, our applications are intended to be compartmentalized services that fill particular gaps rather than one giant platform that everything else depends on.
We aren’t against building software. We’re against building software just because we can.
Human-Owned, AI-Assisted
The model we’re building at Archous combines AI-assisted operations, proven software, sound network hygiene, and humans who remain accountable for the systems they operate: all delivered as a service to our ISP customers.
Let AI correlate telemetry, investigate alarms, analyze configurations, assist with troubleshooting, generate code, and help engineers reach answers faster. Let mature software products continue solving the complex problems they were built to solve.
Keep experienced engineers responsible for how those pieces fit together; and for every decision that can affect a production network.
Safely generating and deploying configuration shouldn’t be the hard part anymore.
Understanding what you’ve built, why it works, how it fails, and what to do when it does — that is still engineering.