technology – Victor K's Stream of consciousness

By Victor Kuarsingh

AI is pushing the boundaries of technological abstraction further than ever before. While no one is arguing we should abandon modern tooling and code like it’s 1965, this rapid evolution introduces a silent organizational risk. Every previous era of computing has shown that when an abstraction breaks, the organizations that are impacted most are the ones where technology creates problems and few or nobody is left in the building can reason about what is underneath.

The Challenge Ahead

When we look back over the past 60-70 years, the industry has come a long way from our early computing and programming era. In those early days, the application user was most often the code developer with a necessarily deep understanding of the foundational computing system by which functions were built. As operating environments evolved, such as the release of Unix by AT&T Bell Labs in the 1970s, programmers and users were able to leverage a more abstracted environment resulting in productivity gains. As we approached the 80s, that further evolved where end users were rarely the programmer, and even more unlikely to have a deep understanding of the foundational computing platforms.

In the 1980s, the acceleration of networking was driven by the need to expand the early ARPANet that bloomed into the Internet by the mid 1990s. Those early networking experts were most often computer scientists that formed early connectivity protocols and systems morphing into a defined discipline by the mid-1990s. Early networking talent, just like the early systems and programming talent, was often very well versed in the foundational infrastructure’s base architecture, design and capabilities. Moving further into the 2000s, the rapid expansion of vendor supplied products, standard deployment models, and further abstraction began to distance users, administartors and programmers of networking systems from those foundational capabilities.

The advantage of these abstractions both within the software and networking space were revolutionary in allowing for scaling and acceleration of deployments, modern applications and outcomes. However, an artifact of this change is the slow and often silent deterioration of foundational expertise in many businesses. Areas where experience often now lacks includes networking, security, computing, operating systems and platforms. The deep learning curve that was needed to be functional years ago, no longer is mandatory for most designers and engineers to operate within their areas of the business. That separation and devolution of “making it work” contrasting to understanding “how it works” – poses a risk to business, especially when those foundations are needed for resiliency and overall business success.

AI, which has displaced so many foundational tasks and roles, not only further adds to the separation, but may further accelerate the deterioration of skills development and growth of cognitive reasoning when designing, using and improving systems or platforms. The new risk somewhat exacerbated by AI is the release of engineering rigor as a pillar of development teams are able to produce without really knowing how the product (code or config) is being generated.

With a declining population of highly competent engineers that understand the foundations, and an ever increasing demand for those people, its going to be interesting to see what transpires in the market and in businesses. Early impacts will likely be filled with outages and missed opportunities for businesses. The longer term impact may be foundationally anemic businesses unable to produce substantive products and services relegated to producing fragmented and unreliable technical products. The challenge we face as business leaders is – can we leverage AI to accelerate now without sacrificing our future success.

Modern examples where eroded engineering rigor and abstraction-layer failures caused significant business impact include CrowdStrike (2024), Meta (2021), and Knight Capital (2012) — each resulting in substantial financial loss and reputational harm.

So What

The challenge we face as leaders and within the Industry is clear. We must leverage AI to accelerate our velocity without sacrificing our future integrity. We need deliberate balancing between embracing this new layer of abstraction while still protecting our base of needed expertise.

Allowing AI to completely sever our engineering teams from the underlying mechanics of our networks, systems, and platforms introduces a business risk. When a catastrophic failure inevitably occurs beneath the AI-generated layer, the absence of deep, cognitive reasoning won’t just cause a routine outage—it could result in an entirely unrecoverable situation where no one in the building knows how to rebuild the collapsed foundation.

AI can generate the code and configure the platforms, it cannot assume the risk. Moving forward, engineering rigor cannot be outsourced. We must intentionally cultivate, value, and retain the talent that understands the “how,” ensuring that as our technology becomes increasingly abstracted, our ability to govern, troubleshoot, and recover our businesses remains firmly intact.

By Victor Kuarsingh

Introduction – The Shift Beyond Building and Administration

For decades, network was largely anchored to an administrator’s perspective: building, configuring, crafting and maintaining systems with the mindset getting to runtime and keeping the lights on. This approach solved immediate problems effectively, but it also constrained networking to incremental change and reliance on humans for many operations even if some automation was present. Today’s landscape that includes cloud, automation, distributed systems, edge computing and complex security; demands a substantive change in how we build systems. The future of networking is no longer about administering devices; it is about engineering solutions at the software layer, with networking as one of several domains in play.

Lessons From Past Practice – Why the Old Model No Longer Fits

Traditional approaches relied on command-line mastery and vendor-specific skills. These were critical in the 1990s and 2000s, but they locked engineers into reactive modes of work: troubleshooting configurations, responding to outages, or scaling networks by manual effort. Basic building and management of networks can be argued to be a “solved problem” insomuch that there is an abundance of operational techniques and tactics known by our industry to deal with them —protocols, routing methods, and device management frameworks exist that address the common cases. What remains unsolved are the problems of scale, velocity, and flexibility in the face of continuous change. These are not CLI problems; they are systems design problems.

Innovation by Inquiry – The Engineer as an Explorer

To move forward, network engineering needs the same culture of inquiry that drives innovation elsewhere. Extrapolated lessons from my post on Innovation by Inquiry, the emphasis should be on asking questions that reframe the problem space. So questions like – Why is this process manual? How could it be automated? What would a system look like if it were designed as code from the ground up? – are great ways to frame how to apply innovation to a problem. This mindset turns engineers from operators into explorers, willing to experiment, fail, and iterate. Software engineering brings the tooling—automation frameworks, APIs, CI/CD pipelines—but inquiry provides the compass to ensure those tools are used to solve meaningful problems.

The Case for Network Engineers as Software Engineers

The emerging reality is that network engineers must become software engineers who also understand networking. Not the other way around. Writing infrastructure as code, modeling traffic flows as software artifacts, and integrating with service-based architectures are now table stakes. A software-first engineer can scale networking far beyond what was possible with administrator-centric practices. They can build abstractions, enforce policy through automation, and design resilient systems that are tested, versioned, and repeatable—just like any modern application. Networking knowledge remains essential, but it is no longer sufficient on its own.

Shifts We’ve Made Before – Reinvention Is the Norm

This isn’t the first time networking has reinvented itself. In the 1980s, networking often emerged from system administrators wiring together early LANs with technologies like Ethernet (IEEE 802.3), ARCNET, Token Ring, etc – solving the basic problem of how to connect PCs and share resources. By the 1990s, the explosion of the Internet demanded new thinking about the physical and routing layers. Vendors like Cisco and Juniper built high-capacity routers to support the first backbone networks, while advances such as fiber optics and DWDM (Dense Wavelength Division Multiplexing) reshaped how bandwidth could scale displacing early SONET and ATM technoloiges. Entering the 2000s and 2010s, the challenge shifted again: distributing and accelerating content. Content Delivery Networks (Akamai, Limelight), broadband build-outs, and global peering fundamentally changed how information was delivered. Each stage forced a leap away from past practice.

Today, the limiting factor is not physical speed but complexity—interconnected systems, microservices, cloud-native architectures, and global scale. Managing that complexity requires more than manual configuration or incremental improvements. It requires software: abstractions to tame complexity, automation to eliminate toil, and orchestration to ensure resilience. Just as we rethought wiring in the ’80s, backbone scale in the ’90s, and content distribution in the 2000s, we must now rethink networking through a software-first lens.

Forward-Looking Examples – Signs of the Next Shift

The industry is already showing us where this evolution is heading. Hyperscalers such as Google, AWS, and Microsoft have moved to intent-based, API-driven network models, where engineers declare desired outcomes and automation systems translate that into actual network states. Emerging 5G and edge networks rely heavily on network slicing and service orchestration, concepts that cannot exist without a software-first approach. These examples prove that the shift isn’t theoretical—it is already happening, and it rewards those who can think in code while understanding the fabric of connectivity underneath.

The unique challenge

The challenge—one somewhat unique to this space—is how to encourage a larger segment of networking innovators to adopt and excel at software-based approaches to solving problems, while still maintaining deep proficiency in foundational networking concepts. Developing such a polymathic, interdisciplinary skill set is difficult; this transition will be challenging to both foster and sustain. It takes years to become proficient in networking, and likewise to master the craft of building reliable software—yet our industry must rise to meet this dual expectation.

In many ways, this moment feels like a return to our roots. During the mid-to-late 20th century, it was computer scientists who designed many of the the early networks and the protocols that made them function. Perhaps it’s time to rekindle that spirit—to begin again with a software-first mindset.

Structuring the Future Differently

The shift is not optional. If we keep structuring solutions as administrators, we will keep solving yesterday’s problems. To address tomorrow’s, we must structure solutions fundamentally differently—through code, inquiry, and engineering discipline. This is not just about personal skills, but about reshaping the culture of networking teams to value experimentation, automation, and systems thinking. As with any transformation, the leaders who thrive will be those who combine the technical fluency of software with the critical inquiry of innovators, shaping networking into a platform for the next era of digital infrastructure.

Tag: technology

Risk Of Foundational Knowledge Beyond 2026