I loved working at Cisco. I want to say that first and without any clever framing, because people usually write about a former employer either to settle a score or to ask for a job. I am doing neither. I just loved it.

I arrived in San Jose in 1999 believing I knew networking. I had two CCIEs, I had led engineering teams at KPMG, and I was, by my own estimate, fairly impressive. That estimate survived for about a week.

A small fish, a very large ocean

The best way I can describe it is Nemo swimming in the ocean. A small fish, water in every direction, and something interesting behind every rock. The difference is that Nemo spent the whole film trying to get home. I had no intention of being rescued.

At Cisco, knowledge was not a department. It was the water. You could ask a question in a hallway and get the answer from the person who had written the feature. Sometimes you got the answer plus a short lecture on why your question was wrong, which I came to appreciate. Eventually.

There were labs full of equipment I could never have afforded to touch anywhere else, and I was allowed to break it. I broke a great deal of it, strictly for educational purposes. There were mailing lists where a question sent at midnight had three answers by morning, from three time zones, two of them disagreeing with each other in impressive technical detail. There were people who had designed the protocols I had studied from books, and they stood in the same lunch line and complained about the same parking.

The resources felt unlimited. Whatever you wanted to learn, somebody in the building already knew it, had written it down, and was usually willing to explain it if you brought coffee.

What I actually did there

I started in Professional Services, supporting Cisco's large service provider accounts, and later joined Central Engineering in Customer Advocacy. Most of my years went into IP routing and MPLS: Layer 3 and Layer 2 VPNs, Metro Ethernet, and later data center, storage and security. Over twelve years I helped design and build more than 80 networks for Fortune 100 and 500 enterprises and top-tier service providers.

Every one of those networks was a classroom with a deadline. A customer does not care that you learned the feature last month. They care that it works on Monday. Nothing teaches like that, and nothing concentrates the mind like a service provider's operations team watching you type.

Then the obsession started

I became obsessed with learning. I do not mean that as a figure of speech. When you are surrounded by that much knowledge, not learning feels like standing in a bakery and refusing to eat.

So I kept taking CCIE labs. I arrived with two and I left with five. Some took me two attempts and some took three. By the third attempt at one of them I felt I should be paying rent at the lab.

If you hold two, three or five CCIEs, you understand me better than anyone, and I do not need to explain. If you hold none, you probably think we need help. Both groups are correct.

Normal people have hobbies. They fish, they golf, they restore old cars. I had a rack of routers and strong opinions about label distribution. My idea of a relaxing weekend was a topology that finally converged. I am told this is not how other people describe a good weekend.

The strange thing about an obsession with learning is that it never feels like work. I would finish a long day with a customer and then open a lab at night, not because anybody asked me to, but because there was one more thing I did not understand, and it was sitting right there.

The people

The real resource was never the equipment. It was the people. I worked next to engineers who were better than me at almost everything, and they were generous with it. Nobody guarded what they knew. The culture I remember was simple: if you understand it, you explain it.

Some of those colleagues became my co-authors. Writing a technical book with other engineers is the only project I know where four intelligent adults can argue for an hour about one line in a configuration example. We were all right, which was the problem.

For ten years I also presented at Cisco Live. Standing in front of a room of engineers is the fastest way to find out what you do not know. Someone in the third row always knows. They are very polite about it. They wait for the questions.

Knowledge is power

People say knowledge is power, and it sounds like a poster in a school corridor. At Cisco I saw what it means in practice. The engineer who understands the problem is the one the room turns to, whatever the org chart says. Customers trust them. Managers leave them alone. Colleagues call them at two in the morning, which is admittedly a mixed blessing.

Knowledge is also the only asset I know that grows when you give it away. Every time I explained something to a colleague or a customer, I understood it better myself. That is why I wrote books, why I presented, and why I am writing this.

Everything good in my career since then, the patents, the company, this blog, grew out of what I learned in those years. I did not know it at the time. At the time I just thought I was having fun.

Find your ocean

If you are starting out, my advice is to find your ocean. It does not have to be Cisco, and today it may not be a company at all. It may be an open-source community, a user group, or a team with one great architect who answers questions. The test is simple. Are you surrounded by people who know more than you do, and will they let you ask?

If the answer is yes, stay, swim and ask everything. Do not worry about looking small. Everyone in the ocean started small.

And if you are the smartest person in the room, you are in the wrong room. Or a very small aquarium.

I left in 2011 to start my own company, and I do not regret it. But I still miss the water.

My CCIE number is 4460. I have carried it for most of my career, and it is still the first thing many engineers ask me about. People assume the story is about a hard exam. It is really about what one credential can do to the direction of a life, for better and for worse.

It did not come easily

I hold five CCIEs: Routing and Switching, Security, ISP Dial, Storage Networking and Service Provider. Some of them took me two attempts and some took three. I say that plainly because almost nobody does. You see the plaque on the wall and assume the person behind it walked in and passed. I walked in, failed, went home, rebuilt the lab and went back.

I also did it in my second language. Russian is my native language, and an exam that punishes one misread requirement is harder when the requirement is not written in the language you grew up with.

Failing taught me more than passing did. A pass tells you that you were ready on that day. A fail shows you exactly which parts of your knowledge were memorized and which were understood. Every second attempt I made was better than the first, because by then I knew where I had been guessing.

What it gave me

It gave me a seat in rooms I would not otherwise have entered. At KPMG I was the only double CCIE in the firm worldwide, and that opened the door to the engineering and architecture groups I went on to lead. It took me to Cisco and its large service provider accounts, and eventually to five certifications, three books and ten years on stage at Cisco Live.

Credibility compounds. When a customer knows what the number means, the conversation changes. If you say a design will not work, they ask why, and they listen to the answer. That trust let me work on bigger problems earlier than I would have otherwise, and bigger problems are where you learn the most.

More than the title, the lab changed how I think. You learn to read a broken network under time pressure, to decide what to ignore, and to trust a method over a guess. I still use that every working day, including on problems that have nothing to do with routing.

It also gave me a community. There is a small group of people who have been through the same thing, and the number works like a handshake. Some of the best engineers I know, including the people I wrote books with, I met because of it.

What it took

Nobody earns it during office hours. The study comes out of evenings, weekends and the patience of the people around you. While you are preparing, the exam becomes the most important thing in the house, and that is not a small thing to ask of anyone. Multiply that by two or three attempts, and then by five tracks.

There is also a trap in it. After the first number, the next track starts to look like the obvious next step, and it is easy to keep studying because studying is the thing you know how to do. At some point the more valuable move is to stop collecting and start building.

What I would tell a younger engineer

The number is a key. It opens a door once. What you build after you walk through is the career. The patents, the books and the company I founded did not come from another exam. They came from asking what the industry was missing and deciding to make it.

Would I do it again? Yes. I would fail the same exams, go back the same number of times, and carry the same number. I would only start building sooner.

Nobody outside the industry sees the schedule. From the outside, a network engineer has an office job. From the inside, the job runs on a clock that has very little to do with office hours, and the people who live with you run on that clock too.

The hours nobody sees

Maintenance windows open at midnight because that is when the fewest users are affected. Major upgrades are scheduled for holiday weekends because the business is quiet. A change that goes well ends at three in the morning. A change that goes badly ends with a rollback at five, and you are still expected to be coherent on the nine o'clock call.

Outages do not check the calendar. A bridge call can last longer than a birthday dinner. When you are on call, the phone sits on the nightstand, and everyone in the house learns what that ringtone means.

The map

My work has been based in Milwaukee, Brookfield, Chicago, San Jose and Palo Alto. Every line like that on a résumé is a decision that affected more people than the one who signed the offer.

Then there is travel. A design workshop in another city. A week on site for a migration. At Cisco I worked on a network integration for an acquisition of more than 80,000 employees. Projects of that size do not fit inside a normal week, and they do not pause for school events.

The study

Certification is a second job that you do after the first one. Each of my CCIEs took two or three attempts. That means months of evenings and weekends, more than once, for each of five tracks. In the years when a home lab meant real routers, it also meant heat and fan noise in the house.

The person studying sees a goal. The people around them see a closed door.

What it does to you

The job follows you home in less obvious ways. After an outage your body is still running on adrenaline at the dinner table. You get into the habit of diagnosing instead of listening, which works on a routing table and fails badly with a person. And you forget how to be unreachable, even when nothing is broken.

What I learned, slowly

Put the change windows on the family calendar, weeks ahead. A planned absence is easier to forgive than a surprise one.

Give every certification an end date. Open-ended study turns into a permanent state, and the people at home never get you back. Decide how many attempts and how many months, say it out loud, and keep to it.

When you are on call, say so. When you are off call, be off, and hand the pager over properly so that nobody phones you anyway. Half-present is the worst of both.

Explain what the network is for. A family will forgive a lot more when they understand that the thing you were fixing at two in the morning carries a hospital, a payment system or an emergency line.

And after a big cutover, take the time off. Do not let the next project start on Monday.

What it gave back

This work can also give a family stability and a front-row view of how the modern world is wired together. Very few jobs let you point at something that large and say you helped build it. The honest version of the story includes both columns, and anyone entering this field should read both before they start.

Certification did a lot for me, so I am allowed to say this. There is an ugly side to it, and new engineers should hear about it before they spend the money and the years.

Cheating devalues everyone

Exam dumps are everywhere. People memorize answers, pass, and arrive at a job unable to do the work. Some pay someone else to sit the test. Every one of them makes the next honest candidate a little less trusted.

You can see the result in interviews. Hiring managers who have been burned no longer believe the letters after a name. They put a broken network in front of you and watch what you do. That is the right response, but it means the certificate you worked for honestly now buys you much less than it should.

It is expensive, and failure is normal

An expert-level lab attempt costs well over a thousand dollars before travel, hotel and time off, and most people do not pass on the first try. Some of my own CCIEs took two attempts and some took three. I was not unusual. I just do not hide it.

Around the exam there is an industry selling boot camps, workbooks and promises. Some of it is excellent. Some of it sells the idea that a pass can be bought in two weeks. Nobody posts the failed attempts or the invoice. You only see the plaque.

You become a headcount

Partner programs require a certain number of certified engineers. That means some employers value your number more than your judgement. They will push you to collect certificates that serve the company's partner status and not your growth, and they will notice the day your certification lapses faster than they notice the day you solve a hard problem.

It tests the exam, not the job

A lab is a puzzle built to be marked. It rewards speed, memory for syntax and reading the question carefully. The real job rewards documentation, change control, patience and the ability to explain a risk to someone who does not want to hear it. You can be very good at one and poor at the other.

A vendor certification also teaches the vendor's answer. That is fine, as long as you remember that it is one answer and that the exam blueprint follows the product catalogue.

It never ends

Recertification comes around every few years. The technology you were tested on is retired, and you are studying again while doing a full-time job. Continuing education credits make it easier than it used to be, but the time still comes from somewhere, and it is usually from home.

It can become your identity

The worst part is quiet. When the number is who you are, a failed exam feels like a failed person. It is not. An exam measures one day, on one blueprint, under artificial conditions. I have known brilliant engineers without a single certificate and certified ones I would not let near a production router.

What I would do

Certify to learn, in the lab, the slow way. Choose the track by the work you want to do and not by what a partner program needs. Set a budget and a limit before you start. And when you fail, tell people. It makes the next engineer's failure easier to survive.

If the letters arrive, good. If they are the only goal, the ugly part wins.

It is tempting to say my generation had it easy. We did not. We had it simple, and those are different things. Understanding the difference explains most of what frustrates engineers who are starting now.

Then: knowledge was scarce, the path was clear

In 1990 equipment was expensive and documentation was thin. There were no forums, no video courses and no free lab images. If your employer did not own the hardware, you could not learn it. You learned from the one senior engineer who was willing to explain, or by breaking something and staying until it worked. Good books were so rare that some of us ended up writing them.

Access was the hard part. Geography mattered, employers mattered, and the expert lab was offered in only a handful of places in the world.

But the path was obvious. One dominant vendor, physical boxes you could touch, a ladder of certifications, and a job waiting at the top of it. If you did the work, the market noticed.

Now: knowledge is free, the path is not

Today you can lab almost anything on a laptop and find a tutorial for every feature. The scarcity moved. What is rare now is direction. There are ten possible specializations, each with its own tools and its own community, and each one insists it is the future.

The target also moves faster. Thirty years ago I could learn a protocol and rely on it for a decade. OSPF and BGP are still here, but the platforms, controllers and tooling around them turn over every two or three years. You can master something and watch it be deprecated before your certificate expires.

The stakes went up

The network matters more than it did. Every business process depends on it, so tolerance for failure is close to zero. In the 1990s a short outage was an inconvenience. Now it stops payments, production lines and hospitals, and it is in the news by lunchtime.

Security is part of every decision. A change that used to be a routing question is now also an identity question, a compliance question and an audit trail.

The economics changed

Teams are smaller. Work that used to be done in-house has moved to managed services and cloud providers. Competition for each role is global, because the job can be done from anywhere. Even buying equipment became complicated: licensing tiers and subscriptions are now part of the design.

And an assistant can produce a configuration in seconds, which changes what an employer thinks a junior engineer is for.

What has not changed

Packets still move the same way. The engineer who understands why, and who can explain it to the business, was valuable in 1990 and is valuable now. The work of becoming that person is the same. There is simply much more noise around it.

So my advice is about noise. Choose a direction on purpose and stay with it long enough to get deep. Learn the fundamentals that have survived thirty years, because they will survive thirty more. Find one person further along than you and ask them real questions. And accept that you will not know everything. Nobody does now, and nobody is expected to.

There are engineers with a CCNA, a CCNP and a home lab who cannot get a first interview. They are not doing anything wrong. The ladder changed underneath them.

The apprenticeship disappeared

For my generation the first years were made of small jobs. The NOC shift. The VLAN ticket. The firewall change request. Racking a switch and tracing a cable. None of it was glamorous, and all of it was training. You learned the network by doing a thousand low-risk tasks next to someone who knew more than you.

Those bottom rungs are missing now. Much of that work is scripted. Some of it was handed to a managed service provider. Some of it is gone because the workload moved to a cloud provider that runs the network for you. AI assistants are taking the next layer up: the first-pass configuration and the first-line diagnosis.

Each of those changes made sense on its own. Together they removed the place where engineers used to be made.

Why it is hard right now

Teams are smaller and each person covers more ground. A posting labelled junior asks for automation, cloud, security and three years of experience, because the team has no slack left to train anyone. They are not looking for a junior. They are looking for a cheaper senior.

Layoffs across the industry have put experienced engineers into the same candidate pool. Remote work means you compete with the whole world for a single opening. And before a human reads your résumé, software filters it by keyword.

Certifications no longer separate people the way they once did. My CCIE number is 4460, and the numbering started at 1025, so there were only a few thousand of us. Today a certificate gets you past a filter. It does not get you hired, partly because too many people have passed exams without being able to do the work.

What I would do

Show the work. A public lab repository, a write-up of a problem you solved, a small tool that automates something tedious. Hiring managers trust evidence more than acronyms, and very few candidates bring any.

Look for the side doors. A data center technician job puts your hands on real equipment. A managed service provider NOC shows you fifty customer networks in a year. A vendor support role teaches troubleshooting faster than anything else. A small company where one person does everything is the best training there is, even if the title is unimpressive.

Go where the building is happening. AI data centers, industrial and OT networks, and service provider automation all need people who understand the network underneath.

And meet people. Go to user groups. Answer questions in communities. Ask an experienced engineer about a problem and not about a job. Most first jobs still come from someone who has seen how you think.

A word to hiring managers

You cannot hire senior engineers that nobody trained. If every team waits for someone else to do the training, the supply runs out, and it is already running out. Take one junior. Give them the small jobs back. In three years you will have the engineer you could not find.

When I started in 1990, depth on one vendor's command line was a career. You learned routing, you learned switching, and that knowledge stayed valuable for a decade. I earned five CCIEs by going deep, one track at a time, and each track was allowed to be its own world.

What is on the list now

A new engineer today is asked for all of that plus Python, APIs, Ansible or Terraform, at least one public cloud, a security model built on identity, wireless, observability, and a working opinion on AI.

Cisco's own program shows the shift. In February 2026 the DevNet certifications were folded into the main ladder as CCNA, CCNP and CCIE Automation, and AI topics now run through every level. Automation is no longer a specialty that sits beside networking. It is networking.

Look at an ordinary week. Monday is a campus switch upgrade. Tuesday is a route table in a cloud VPC. Wednesday is a firewall policy review. Thursday is a Python script that half works. Friday is a ticket about Wi-Fi in a conference room. Each one needs a different mental model, and the switching between them is tiring in a way that deep work on one problem is not.

Why it is hard

No single topic is the problem. The problem is that breadth arrives before depth. You can pass exams in six areas and still be unable to explain why a BGP session is flapping. Employers notice that gap in the first interview.

Shallow knowledge also fails at the worst moment. It works while things are normal and disappears during an outage, which is when you are being judged. And it does not transfer. Depth teaches you how to learn. Once you have understood one protocol all the way down, the next one takes half the time, because you know what questions to ask.

What I would do

Pick one protocol family and learn it until you can draw the packet. I mean the headers, the state machine and the failure cases, not the configuration commands.

Then automate the thing you just learned by hand. Automation of something you do not understand is only a faster way to make mistakes.

Choose one cloud, not three. The concepts carry over. Learn enough security to understand identity and certificates, because both now touch everything.

Decide what you are going to be bad at. Nobody can be good at all of it, and pretending otherwise leads to being mediocre at everything. Depth first, width second, and write down what you learn as you go. Your notes are the start of your proof of work.

A word to managers

Stop writing job descriptions that list every technology in the building. You are describing a team, not a person. Hire for depth in one area and curiosity about the rest, and give people time to go deep. The engineer who knows one thing completely is the one who fixes the outage.

A design teaches you how a network should work. An outage teaches you how it does work. Most of the instincts an architect relies on were built in the second classroom.

What the abstraction gave us

I am not arguing against abstraction. I build visualization software for a living, so I am the last person who would. SD-WAN, campus fabrics and data center fabrics are run from a controller, and that is progress. One policy replaces a thousand lines of configuration. Fewer people type commands into production, so fewer people mistype them.

What it took away

The protocols did not go anywhere. The routing, the overlays and the tunnels are all still there under the dashboard. But nobody types them anymore, so nobody sees them. Change windows are too tightly controlled for a junior engineer to experiment. Production is off limits, and it should be.

The result is that new engineers get far fewer lessons from failure than we did, in a job where failure is the main teacher.

Why it is hard

Abstractions leak. An MTU mismatch in the underlay, a certificate that expired overnight, a control plane that lost contact with half the fabric: none of these appear as a clean error message. The dashboard shows green, or it shows a symptom three layers away from the cause.

So the first time many engineers see the underlay misbehave is at two in the morning, with the controller reporting that everything is fine. That is the worst possible place to meet a protocol for the first time.

The method still works

Troubleshooting is a method, not a talent. Ask what changed. Split the problem in half and find out which half is broken. Work up from the bottom: is there a link, is there an address, is there a route, is there a session. Prove each thing instead of assuming it. The tools change every few years. That sequence does not.

What I would do

Build a lab and break it on purpose. Virtual images and container-based labs make this cheap in a way it never was when a rack of routers cost as much as a car. Shut an interface. Corrupt a route map. Mismatch an MTU. Let a certificate expire. Then write down what you saw, in what order, and what finally told you the truth.

Keep those notes as a failure journal. After fifty entries you will recognize patterns faster than people with twice your experience.

Learn to read a packet capture. It is the one tool that never lies to you. Read other companies' post-mortems. And when the senior engineer is on an outage call, ask to listen. You will learn more in that hour than in a month of normal work.

The books I co-wrote for Cisco Press were built on the same idea: you learn it by configuring it, and by fixing it when it does not work. I would change the tools today and keep the method.

When I led a security team at KPMG in the late 1990s, the design conversation was mostly about the perimeter. Trusted inside, untrusted outside, a firewall between them. If you configured that box well, you had done the job.

Why the model broke

Users work from anywhere. Applications live in other people's data centers. Most traffic is encrypted before it reaches anything you own, so the box at the edge can no longer read it. Cameras, badge readers and factory equipment sit on the same network as the finance department and cannot run a security agent.

The perimeter devices themselves, the VPN concentrators and firewalls, have become favourite targets. The thing we installed to protect the network is now one of the first things an attacker tries.

Identity is the new perimeter

This is why I spent years on Cisco ISE, 802.1X and certificate-based access. The question changed from where a packet comes from to who and what is sending it. Segmentation, posture and policy now follow the user and the device, not the VLAN or the building.

It is a better model. It is also much harder to build, because it depends on things the network team never used to own: the directory, the certificate authority, the endpoint and the policy engine.

Most breaches are not clever

From the outside, security looks like a contest of brilliant attacks. From the inside it is mostly an unpatched device, a shared password, a flat network or a management interface that was reachable from the internet. Attackers log in more often than they break in. The fundamentals stop most of it, and the fundamentals are boring, which is why they get skipped.

Why it is hard for new engineers

You cannot hand security to another team anymore. A campus design is an identity design. A data center design is a segmentation design. That puts certificates, directory services and policy engines on top of everything you already had to learn about routing and switching.

Security and availability also pull in opposite directions. Every control you add is a new way to cause an outage. A badly planned 802.1X rollout can lock an entire building out of the network on a Monday morning, and the person who did it will be remembered for that and not for the risk they removed.

What I would do

Build 802.1X end to end in a lab: supplicant, switch, policy server and certificate authority. Break each piece and watch what the user sees. Learn enough about certificates to explain a chain of trust to someone else.

In production, start in monitor mode. Watch what would have been blocked before you block anything. Enforce in stages.

Protect the management plane first: central authentication for administrators, multi-factor login and an out-of-band path. Patch on a schedule and without drama.

And know what you have. You cannot protect a device you do not know is connected. An accurate picture of the network is the first security control. The unglamorous habits stop more attacks than the clever designs.

I have watched the data center network reinvent itself several times, and each time the people who had mastered the previous design had to start again.

Four reinventions

First there were three tiers and spanning tree, and half the links sat idle to prevent loops. Then virtualization moved the access layer inside the server, where the network team could not see it. Storage and data networks converged, which is the world my Storage Networking CCIE comes from: Fibre Channel, FCoE and iSCSI next to routing.

Then came leaf-and-spine fabrics, where every link carries traffic, and overlays that put VXLAN and EVPN on top. Then the public cloud took a large share of the workloads, and for a few years many people believed the enterprise data center was finished.

What AI changed

AI clusters broke the old assumptions. A rack that once drew a few kilowatts is now being designed for many times that. Air cannot remove that much heat, so liquid cooling is back. In many projects the first design question is no longer the topology. It is how much power the utility can deliver, and when. Sites are chosen by the grid before anyone draws a network.

The network changed too. A GPU cluster has a back-end fabric that connects the accelerators and a front-end network for everything else. The back end has to be lossless and very fast, because one slow link holds up an entire training job. There is a real argument between Ethernet and InfiniBand, and Ethernet is closing the gap. The number of optics and fibres in one hall is larger than whole campuses used to need, and each one is a component that can fail.

Why it is hard for new engineers

A data center engineer now has to understand the facility. Power distribution, cooling, cabling density and floor loading are part of the network design, and almost nobody was taught them. The people who know the building and the people who know the fabric often use different tools and different words for the same rack.

The scale makes automation mandatory. Nobody configures thousands of switches by hand. A mistake is expensive in a new way, because a large cluster of idle accelerators can cost more per hour than an engineer earns in a month.

And you cannot practise at home. A leaf-and-spine fabric fits on a laptop. A liquid-cooled rack does not.

What I would do

Learn EVPN properly, because it sits under almost every modern fabric. Learn how congestion is signalled and controlled in a lossless network, because that is where AI fabrics succeed or fail.

Learn to read a rack elevation and a power budget as fluently as a routing table. Walk a real data center floor whenever someone will let you, and ask the facilities engineer what worries them.

Get comfortable with the tools that describe the physical side: asset records, capacity plans, infrastructure management systems. It is the reason I have spent fifteen years on showing infrastructure in 3D. A data center is a physical object, and you run it better when the network team, the facilities team and the business are all looking at the same picture.

An assistant can now produce a clean BGP configuration faster than I can type the first line. That is real, and pretending otherwise wastes time.

What it is good at

It writes first drafts of configuration. It translates between one vendor's syntax and another's. It summarizes ten thousand log lines into the three that matter. It writes the documentation nobody wanted to write. For an experienced engineer this removes hours of typing every week, and I would not go back.

What it cannot do

It cannot carry responsibility. It does not know that this customer's change freeze starts on Friday, that the second circuit shares a conduit with the first, or that the last migration failed for a political reason and not a technical one. Design is the part of the job made of constraints nobody wrote down.

It also does not know the state of your network unless you give it that state, and it rarely tells you what it is missing. When it is wrong, it is wrong fluently. The configuration looks correct. The wildcard mask is inverted, or the route map is missing its final line, and nothing in the tone of the answer warns you.

Why it is hard for new engineers

The tool removes the repetitions that used to build judgement. If you never write the configuration yourself, you never develop the instinct that something in it looks wrong. You end up approving output you cannot evaluate.

This is why the tool helps senior engineers most. They can check it. A junior engineer gets the same answer and has no way to know whether it is right, which is the opposite of what a beginner needs.

At the same time, AI is also the workload. Training and inference clusters need lossless Ethernet fabrics, very high port densities, and power and cooling planning that used to be someone else's problem. That is new ground for everyone, which means a newcomer is not behind anyone.

How the job changes

The work moves from typing to reviewing. The valuable skills become verification and testing: knowing what a correct result looks like, and being able to prove it before the change reaches production. A model of the network that you can test against is worth more every year.

Accountability does not move at all. The name on the change ticket is still a person's name.

What I would do

Use the assistant every day. Verify what it gives you in a lab until you can predict its mistakes. Ask it to explain its answer, and then check the explanation against the standard or the vendor documentation.

Keep doing some of the work by hand on purpose, the way pilots still practise flying without the autopilot. It is not nostalgia. It is how you keep the ability to notice when the machine is wrong.

The engineer who can check the machine is worth more than the one who can only prompt it. That has been true of every tool this industry has ever adopted.