I want you to steal my job ... again
Out stealing jobs again
I wrote an article a few years back (four and a half, actually) called “I want you to steal my job”. It was an attempt at distilling some of my accumulated knowledge into a recipe for success (or disaster, depending how you look at it) or a blueprint to become a Security Engineer.
A few years have passed, and if I was to write the same type of post again I would probably write it a bit differently (as I am currently doing right now). Things have changed since 2022 with the wide adoption of AI and agentic workflows, and I’ve also learned some things along the way (who could have guessed, right?).
Now, let’s get one thing straight - this article isn’t out to paint either “AI bad or AI good”.
I prefer to treat AI as what it is, a tool. Similar to when I learned math, it’s good to know some base level of math without the calculator. I don’t think anyone could have guessed the rapid rise of smartphones, but here we are.
In the same vein, getting code to run without an IDE and solving problems without AI. I think this is a baseline level of understanding and competency we should strive to achieve.
Of course, experience is everything and no one expects you to have this inherent level without work experience (unless you look at some hiring managers demanding ten years’ experience in a two-year-old technology as an entry-level job? What is that about?).
I still stand behind the idea I presented in my original blog, that you build practical, basic knowledge first. Keep it limited to a single platform (Windows or Linux) for client devices, similar for networking (i.e., learn the syntax of Cisco/Palo Alto and functionalities) then similar for a hyperscaler and programming/scripting.
Knowing how to navigate a singular technology in my experience lends itself to adapting that knowledge to new products of similar types.
What you need to succeed (or fail fast)
If I was to pick out one trait I believe is important for success in technology it would have to be curiosity. You can give it many names, but it is the drive to understand what is going on in the background.
Technology is getting easier to use and the mechanics of what’s going on are all behind layers of abstraction. Most people will operate in portals and user interfaces are how most people “understand” how things function. But, as they used to say:
“Here be dragons”
Or rather, “here be APIs and other backend functions” - lurking beneath the murky waters. We want to know what these APIs and backend functions do and how we can utilize them effectively.
I would also say, pair that curiosity with knowing when you know enough. You don’t need to know how the entire internet works, or every single detail. This should be enough, initially:
Know enough to do your job. That’s good enough, I think. It’s fair to dive deeper, but you also have to have a modicum of productivity in certain jobs and that’s hard if all you do is watch YouTube-videos of John Savill, even if I do love a good John Savill-binge every now and then.
The impact of agents
Of course, we also have to consider a bit more in detail the impact agentic workflows have on our ability to perform tasks and acquire knowledge. I would hazard a wild guess that some people have become more efficient, but I would also speculate that our understanding of what the AI does and our general knowledge retention decrease.
flowchart LR
A["More work delegated to AI"] --> B["Less work done manually"]
B --> C["More efficient output"]
B -.-> D["Less personal understanding"]
classDef ai fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e;
classDef outcome fill:#dcfce7,stroke:#16a34a,color:#14532d;
classDef risk fill:#fef3c7,stroke:#d97706,color:#78350f;
class A,B ai;
class C outcome;
class D risk;The diagram above is just visualizing my speculation (emphasis on speculation). Again, zero science involved, just feelings, friendship and rainbows. There are of course things we can do to prevent this skill atrophy from happening.
First of all, be mindful about what AI does on your behalf. Always test, always verify, understand the output.
Desired state outcomes
I like to reverse out from a desired state - say if I wanted to deploy a solution, I’d define what that looks like when it’s been properly implemented. Here is where experience comes in, because I know how that script should look (the skeleton of the script) or what components I want to use in my architecture:
flowchart LR
E["Desired state"] -->|"Reverse engineer"| C["Success criteria"]
C --> R["Components<br/>Config<br/>Permissions"]
R --> S["Implementation steps"]
S -->D["Deploy"]
D --> V["Verify"]
V -.->|"Check"| C
classDef target fill:#fef3c7,stroke:#d97706,color:#78350f;
classDef planning fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e;
classDef execution fill:#dcfce7,stroke:#16a34a,color:#14532d;
class E,C target;
class R,S planning;
class D,V execution;This is also a great tip for prompting AI - the more you can outline what you want and the architecture, the better it will be.
Do an experiment for me: Try to get your agent to build you a simple webapp in Azure with some features and see what runtime and service it picks. In my tests it has defaulted to Node.js 20, which is end-of-life. As of August 2026, Node.js 22 is in Maintenance LTS, 24 is in Active LTS and 26 is the Current release. If you don’t specify a static webapp (SWA being a type of resource in Azure), it sometimes creates a container app instead.
This will vary a bit on what you are building, but simple prompts without proper context give you non-optimal solutions. This is not rocket science, but just something to keep in mind. Unless we are specific, the agent will work on what it knows, which will usually be a bit behind the current versions.
I’m not saying using AI makes us dumber by default, as long as we take a conscious approach to using it. Again, it’s a tool, and good tools used in good ways make us better and more efficient. Reminds me of this quote:
Basically translates to “electronic data processing creates problems, it costs money and it’s difficult”.
Of course this turned out to be a bit right and a bit wrong.
So you want to work with Cloud Security
Now, let’s say you want to steal my job in particular and you want to work with Cloud Security. Cybersecurity in that sense is a field that lends itself to experience from other fields. Not required, but certainly very beneficial.
Breaking down “the cloud”
Now, if we break the “cloud” down, it’s just an abstraction layer (or multiple) that allows you to accomplish varying degrees of complex tasks without investing in your own hardware. Simply put, someone else’s computer in someone else’s basement that you can use, easily. That’s not quite correct, but it’s close enough (ish).
At the end of the day, virtual machines run a guest operating system, while containers usually share the kernel of the host or node operating system. Pods group one or more containers. So the OS-knowledge is helpful to have.
Now compute needs to speak to other compute, hence networking is neat to know. Again, routing and switching gets you quite a way, then of course sometimes we need some compute to not always leave the door unlocked and let everyone in - here we bring in firewalls and segmentation.
Much of this compute is virtualized on hypervisors, while networking spans both physical and virtual infrastructure. So knowing virtualization and understanding things like Hyper-V helps out.
Scripting or programming will be useful to automate. PowerShell is still the language of choice for many administrators using Azure, while Azure also has specific command-line tools such as Azure CLI (az).
Of course for this example, much of the management experience is packaged into the abstraction layer that is the Azure (Ibiza) portal. The portal, PowerShell and Azure CLI use Azure Resource Manager to manage Azure resources. Microsoft Graph handles Microsoft Entra, Microsoft 365 and related cloud data and services, which is also loosely related to Azure.
If we map out Azure, it could look something like this (ish):
flowchart BT
PHYSICAL["Datacenters"] --> FABRIC["Azure infrastructure"]
FABRIC --> COMPUTE["Compute"]
FABRIC --> NETWORK["Networking"]
FABRIC --> STORAGE["Storage"]
COMPUTE --> SERVICES["Azure services"]
NETWORK --> SERVICES
STORAGE --> SERVICES
SERVICES --> PROVIDERS["Azure resource providers"]
PROVIDERS --> ARM["Azure Resource Manager"]
ENTRA["Entra ID and Microsoft 365"] --> GRAPH["Microsoft Graph"]
ARM --> PORTAL["Azure portal"]
ARM --> SHELLS["PowerShell and Azure CLI"]
ARM --> CLIENTS["SDKs and REST"]
GRAPH --> GRAPHCLIENTS["Graph clients"]
classDef foundation fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e;
classDef resources fill:#dcfce7,stroke:#16a34a,color:#14532d;
classDef control fill:#fef3c7,stroke:#d97706,color:#78350f;
classDef interface fill:#fce7f3,stroke:#db2777,color:#831843;
class PHYSICAL,FABRIC foundation;
class COMPUTE,NETWORK,STORAGE,SERVICES resources;
class PROVIDERS,ARM,ENTRA,GRAPH control;
class PORTAL,SHELLS,CLIENTS,GRAPHCLIENTS interface;And just to be clear, I’m not saying you need to know how the backend of Azure works in terms of, say, networking. But I think knowing how routing and switching works in physical networks helps you grasp the concept of connecting two virtual machines via virtual networks in Azure as well.
A firewall could translate into multiple types of Azure-resources, it could be an Azure Firewall, or an Network Security Group (NSG), an Application Security Group (ASG) defined for a set services used in an NSG, or even resource-level network firewalls. The concepts are the same, even if the type of resource and details will differ.
Similarly, once you know networking, virtual networks (VNETs) in Azure also become easier to understand. I’m being generalistic, but subnets being routed inside the VNET, and having to peer and route two separate VNETs.
There are different methods for getting that connectivity, either from inside a single Azure-tenant, other hyperscalers or on-premise, but again the concepts are all the same or very similar - so understanding the details becomes easier once the basic principles and core concepts are known. At least, that’s my take.
Securing the “cloud” (or anything, really)
I haven’t even mentioned security, but that’s more to do with applying concepts like segmentation and least privilege to the technology that we use. Yes, yes, I know, that’s vastly over-simplified. But that’s why security is complex - there are layers to it.
At the base level of security it’s just about good, basic IT. If we take something like the CIA triad, it combines the three principles of confidentiality, integrity, and availability.
My amazing drawing from pre-covid.
These principles have been expanded upon multiple times, and there are countless standards and models we can use to measure our security today.
Of course, if we decide upon a standard, we can reverse engineer it to understand what configuration changes we need to make in order to be compliant with these standards and models. Of course, there is more to compliance than just configuration changes.
I would advise you to “keep it simple, stupid” as you would learn in the army. Reduce complexity to the simplest level you can understand, then build from there. A recommended starting point would be the immutable laws of security.
“Architecture exists to identify challenging requirements and translate them into actionable guidance to reduce security risk, limit damage, and keep systems available over time. At the foundation of this work are the immutable laws of security.”
A thought experiment for you - why do we want endpoint detection and response (EDR) on our server, versus anti-virus (AV)? And why would we want either in the first place?
When we dive even deeper, is just installing it enough, or should we also seek to have different configurations across our entire estate based on the value of the server? Why, why not?
What determines the value of a server? Depending on if you work in public or private sector that answer might change, but in private sector you would look for “what makes my company money” and try to protect that. Of course, other factors play in as well, such as data sensitivity, legal obligations, operational impact.
Abstraction layers are also a thing in security. Know that the terms XDR, CWP, CSPM and more are not standards. They are umbrella terms for a bunch of tools. Defender XDR will be completely different to SentinelOne XDR for instance.
You should know that just enabling tools is not enough to be protected. Enabling and configuring the tools as well only gets you part of the way, sometimes. If you know that, you can go look for when logs and detection rival or even outmatch tooling.
If there’s one thing you should know about security, it would be threat modelling in my humble opinion. I wrote about it previously and OWASP has great resources for it, but it can be easily summarized in four simple questions:
- Assess Scope - What are we working on? This might be as small as a sprint, or as large as a whole system.
- Identify what can go wrong - This can be as simple as a brainstorm, or as structured as using STRIDE, Kill Chains, or Attack Trees.
- Identify countermeasures or manage risk - Decide what you’re going to do about each threat. That might be to implement a mitigation, or to apply the accept/transfer/eliminate approaches of risk management.
- Assess your work - Did you do a good enough job for the system at hand?
The scope can be as small as setting up a new firewall or the outcome of a security gap analysis, or as big as a new system, solution or even the entire company.
I would also say, the same principles for learning apply to security. Learn a single EDR, and most EDRs will be the same (in theory/concept). Of course some things will vary, like telemetry, schemas, APIs, licenses and more. Did I say it was the same?
Maybe I thought that at the beginning of the sentence. The concepts are similar, and knowing one very well allows you to learn another at a faster pace.
Some principles apply across as they are technology-agnostic, but if you want to master a specific piece of technology or tooling and become an “EDR-expert”, start with mastering one.
Applying concepts and principles across different technologies
The general idea is, you learn a concept once, it’s easier to apply that concept to another piece of technology. Example, an if-statement in PowerShell looks like this:
if ($truls) {
Write-Host "ccc"
}And one in Python looks like this:
if truls:
print("ccc")The concept stays the same, the syntax is different. The same would apply to a virtual machine in Azure vs GCP vs AWS. Similar concepts, but names and some functionality will differ a bit.
Don’t get me started on rust, please.
The two most important things
When starting out from school, changing jobs or even changing specialties or fields there are two skills I believe are key to success. Those two being mindset as it relates to tasks and learning, and knowing how you learn.
I’ll dive a bit deeper into both, but let me first state that under no circumstances should you need to put in “extra work” or spend time outside of work on this.
Some people like to believe that time spent = value, but as you get more experience you’ll realize you can do more in less time and that’s skill, not spending a lot of time for the optics of it. Of course, you need to learn something to be able to do it faster.
I will admit when I started out, I did work a lot of overtime and spent my free time researching problems for work, often showing up to work the next day with some notes in my book ready to continue troubleshooting where I left off. I was really into solving practical problems and this gave me joy and motivation.
You don’t need to do this, but it speeds things up, just make sure you are intentional with your time. Just putting in time without rhyme or reason is time wasted for everyone.
Mindset
If you really want to learn and get ahead, we need to discuss how you approach it. First of all, let’s outline two extremes of approaches to work:
- Asking for help with everything
- Never asking for any help
Someone claims having a “try harder” mindset is the way, smashing your head into every single wall you face without asking for help, while others will never try to even take a look if you are in fact facing a wall or a small hurdle.
My take on this, if you want the TL;DR:
- No, don’t ask for help with everything
- Yes, do ask for help after trying a moderate amount of things yourself
How long is a moderate and adequate amount of time to try yourself before asking for help?
You’ll figure it out, but let’s do a quick experiment.
I’m assuming you’ve had some level of introduction and training, and have been given a task to accomplish. Maybe you’ve been told who to ask for help if you need to understand something.
The first tasks you are given will likely be something you can accomplish without asking anyone. Will you be slow? Yes, but that’s “part of the equation”. Try, fail, try again, fail again. “What does it help me to fail” you might ask?
Well, you just tried to solve an issue, but it didn’t work. Now you know that’s how to not solve that issue. Sometimes you figure out the task - it wasn’t an insurmountable wall, simply a small hurdle that was easy to clear once you changed your perspective.
To be clear, sometimes the hurdle is one of those obstacle-course walls where you’ll need help to get up. You’ll learn which ones those are, but keep trying first.
If you approach someone asking for help with a clear idea of what doesn’t work, that also helps whoever is helping you understand what you are struggling with and to better guide you.
To continue with the example of an obstacle-course wall, you want people to help you up - but you also want to do your part so you’re not doing a full Weekend at Bernie’s reenactment.
On the flip side, imagine what happens if you are constantly asking for help, maybe even getting other people to give you the answer? It’s like being carried through the obstacle course, and while people will always help in the beginning, after a while it gets tiring to carry someone else.
To summarize mindset, you should be hungry to learn. Curious, dig and try and fail on your own. Know (learn) when to ask and how to ask, and in time, you too will be able to help other people get up their own obstacle-course walls.
I guess it translates roughly into “try smarter”, know when to try on your own and when to ask for help.
flowchart LR
A["Define the task"] --> B["Try"]
B --> C["Observe the result"]
C --> D{"Next step?"}
D -->|"Retry"| B
D -->|"Ask"| E["Ask with context"]
D -->|"Solved"| F["Verify and retain"]
E --> FAlso, how does AI relate to this? Well, treat Claude or whatever solution you use as a coworker. In the beginning, I would research manually to learn.
Some AI has research features, but make sure you know how to run your own code, understand how it’s written and what it does.
AI, like your coworkers, might be wrong. And, you yourself, like AI and your coworkers, might also be wrong. If I base it on experience, I’ve been wrong more times than anyone I know.
I’m not sure if it’s even “food for thought”, but what happens in 2 years when the cost of using agentic tooling skyrockets and you can no longer use it to basically do your job for you? Can you still maintain your codebase, troubleshoot your solutions and systems without AI?
I think you should.
Know how you learn
No matter if you are fresh out of school or have been in the business many years, you should have some semblance of an idea about how you best learn. In what way can you consume information in a way that helps you retain it and learn it?
Even if you have a great mindset, being able to try and fail on your own, having the required curiosity to explore solutions - it won’t matter if you can’t properly retain knowledge and build on it.
There’s no definite answer here. I personally learn from doing stuff practically, either through guided labs like PwnedLabs or blind boot-to-root boxes like those offered by Hack The Box.
I also learn from trying things in my own cloud/on-premises labs or reading practical blogs (usually copying and pasting commands, modifying scripts and seeing what it does when run in my environment).
I “learned” assembly and C in school and can barely remember a thing. It wasn’t until I started using PowerShell for work and automating tasks, and making a wine lottery in Python that I really got into scripting and programming.
So if you’re like me, find something practical you want to solve. Find issues and tasks that are manual and menial, then try to find ways to approach it using code and automation.
Again, this is something you need to figure out on your own. But you should know how you learn and strive to tailor how you approach learning in that specific way.
Time is limited, so make the most of it.
Translate mindset and learning into growth
The title of this chapter makes it sound like I’m trying to sell a self-help book or start cosplaying as a lifestyle guru on Instagram. I’m not (yet), don’t worry about that (yet).
With today’s agentic tooling, it’s hard to focus on a singular topic at once. I would say one of the better ways of learning is to focus on a single task and take it from start to finish without context-switching, but of course that’s harder now that multi-tasking has been outsourced to agents.
While agentic workflows allow you to dispatch multiple sub-agents, you must yourself become the sub-agent focused on that single task. Now I sound like a martial arts teacher from a 1970s kung fu movie - “flow like water, bend like straw” - but there is merit to this.
I usually do my best work when I can draw (whiteboard, shower) or think in long sequences (biking, running) without interruption.
I can break down the issue, draw the logical flow or discuss it with myself out loud. I’m one of those maniacs mumbling to themselves while running in the forest, sorry not sorry.
Another thing that works well for me is explaining the problem to a coworker or myself - so-called rubber duck debugging.
Context-switching works if it’s something I know well (or just ish), but learning something new requires singular focus in my experience. This is subjective, of course.
Again, this leans on the principles of mindset, try and fail (a few times) and then explain what you’ve tried and what is not working. Most times you’ll find that the answer to making it work drops into your lap as you are ranting about how it’s not working.
Finishing words
Where my previous post mainly focused on what you should learn and where, this post focuses more on why you should learn and how.
In this day and age, knowledge is still power and being able to research, understand and learn will help you get better and faster at what you do - even prompting your army of sub-agents.
While you might be able to quickly get from A to Z using agentic workflows, I think it’s short-sighted unless you are able to verify that your output is seemingly okay-ish and doesn’t introduce errors, bugs and vulnerabilities that take you straight back to A.
Short-term gains that severely impact the long term are not really gains. It’s like the idiom “peeing your pants to keep yourself warm”. It’s a short-term, self-defeating solution that brings a brief moment of relief followed by much worse long-term consequences.
Instant gratification is the name of the game and has been for a while. While I don’t think googling Stack Overflow and attempting to run that code raw is better than asking an agent, I would argue that having to adapt the code and parameters, troubleshoot and manually run it gives a better insight than just having an agent run it in the background.
Is this me at the moment? Maybe.
Anyway. Whether you agree with my takes or not doesn’t really matter, because if you bother to read all of this and have an opinion, that means you are at least thinking about and reflecting on it. That’s far better than most, I would argue.
And I don’t have to be right, I seldom am.