How to Get Fired as an AI Engineer

Let's start with, you know, some show of hands. You know, like so put your hands up if AI has helped you build something in last year that you have previously either postponed or, you know, just, like, needed more people or didn't try. Yeah. Alright. So keep it up if you think that it it just pulled you pulled you pulled across more problems than you were originally anticipating. You might be researching it, you know, planning it, You were, you know, shaping it then just like building it.

Yeah. Okay. Last one. So keep it up if you think that, even though you delegated this to AI, right, AI was doing a lot of work for you, yet you were the one who was responsible for the outcome of it. Like, how the good the outcome was. Alright. That's a lot of people. Cool. So How to get fired as an AI engineer?

I don't think AI makes the engineers unnecessary. I believe it makes a much bigger job available to us. The only trouble I believe we get into, the only time we get into any trouble is when our ideas of engineering stay smaller than the job that we can own today.

So it's not just about writing code faster, you know. We've been talking about it. We know it. It's getting easier. It's for me looking at the ideas and the product problems that previously I felt was too big, you know, I was too I was too slow, you know. I I it was always out of my scope, but now I'm feeling that I can attempt them now.

So the job got bigger. This is the, you know, the the innermost of the implementation. This is what we all did. This is the whole job. This is where we build things. Surrounding it, coordination, sequencing the work, the people, then evaluation, judging whatever you build, you know, how good that is. Of course, the product calls, you know, they were the one who decided what we build first and where are we going next for that. And outcome, this is owning that it actually solves the problem.

So I know you've all seen some version of all these five, you know, in your job. So just be honest with yourself. Where do you think like you spend most of your time today? Do you feel that you're moving more towards the outer the outer loops? The loop was always there way before AI.

You know, this is the most internal of the implementation. You build, you test, you fix around it. It's the engineering loop. You know, you design, you hand off, you review what comes out. And the product loop, you decide, you ship, you measure. Of course, each, you know, like this is a very simple illustration of what the real life looks like.

You know, you can imagine way too many concentric loos, way too many nodes, all these nodes are connected to each other. Might you might have legal and, you know, some logistics, you know, crossing all of them, you know. But this is not new. AI didn't invent any of this, but AI is now inside the loop. The deeper you go, the more of it.

The build, fix test, this is becoming AI today. Wherever you see the green part, that's where AI is taking over. But the outer calls, you decide what to build, what to ship, and how to delegate. So you don't have to do everything all by yourself. You know, let's take this simple example.

So you own the objective. You decide how and what to delegate to AI. You own the evidence that it actually worked and you decide you decide where the human intervenes. This is what it means to own the loop. So let's let's do a thought experiment.

You know, which engineer do you think get fired first? So there's engineer a on the first side, the left side, refuses to delegate anything. You know, everything hands on, don't wanna move up, just still at the implementation there. And we have engineer b delegates everything including the judgment. Do anybody thinks engineer b is doing the right job?

Oh, alright. Okay. Well, I mean, most of you get it. Like, it's a it was a great question. I mean, like, it's not it's it's a wrong question to ask, you know. It's I feel like both of them is avoiding the new responsibility. The real move is somewhere in between. Is you understand the work deeply enough that you can delegate it and still own the outcome.

You know, that's why the engineer who understand the loop doesn't get fired. So how to survive? You you stay at the implementation, you know, you don't move up. You know, of course, if you if you don't know how to evaluate it, fight away, then delegate. It is the blast radius. Nobody's watching. You know, agent setting his own permissions.

You know, if it's running, it doesn't mean it worked. It's no more about how many lines of code we write or how many PR we open. Of course, if it is aligning, not directly aligning with, you know, solving the problem. And definitely, you're protecting the old job instead of expanding what you can earn.

So by, you know, like, you know, like listing this, you know, there's so many that we can talk about. By no way, I'm saying that I figured it all out. Of course not. You know, like recently I was working with you know, I use Cloud Code a lot, you know, as my agent. And I was working with some test data, but it was in production daily. And so what what happened, my cloud code started accessing, making some started making some database call that I didn't want it to make. So my first go was I did like, you know, added some cloud rules.

Like, you know, if if for those who don't know, cloud rules cloud rules. You know, let's you add path specific thing is, you know. So whenever the path matches, that particular rule is injected in the context. It's very fresh. But I see that, you know, in like a longer conversation, me being me, like, know, wanting AI to do all my job, you know, so it was like confusing.

There's a rule, but I'm like, go for it. Just do it. You know, do my job for me. So what I did, I ended up moving both my KITRI and my cloth coat inside a container and blocked it at network. So this is like, you know, you might have heard it, we call it network guardrail, I guess now.

And so I made a deterministic. You don't always have to make a deterministic. In other words, why are we using AI? Right? We do wanna control the the behavior of the agent at each level and of your L and M at each level. And it usually depends, you know, I feel it depends on how easy it is to revert back if something goes wrong.

In this case, you know, like what I discussed, it's just didn't want it to go bad, you know, so I made a deterministic. So we are, you know, we are all learning, you know, how to survive in this very fast changing terrain, you know, finding ways to thrive. So, you know, we have discussed it, you know, way more times now. Code is getting easier, but the judgment gets scarcer and the confidence is no longer something that you can assume, but you need to earn it.

So how to thrive? You understand the inner loops, so there's no way out of it. You know, you still need to know your share. You should know how the shit works. The judgment of the outer loops, the like, you know, what is worth doing and what have you built what like, you know, is it good enough? And responsibility across all of them.

The outcome is still yours. So the engineer doesn't disappear. They become more valuable because they understand the system deep enough that they can evaluate it, delegate it, and own a bigger outcome. So this is not just fast work. This is not this is a completely different set of work.

This is where this is bigger than any developer productivity. When the system can when the system act and can observe and improve, the entire knowledge system starts to reorganize. So I'm gonna say it again. The code is getting easier, but the easier isn't about doing less.

The radical part isn't about doing less. It's being able to own more. So leave you all with one question. How much more are you willing and able to own? That's it. That was my time. I'm punished. Did anyone wanna scan that?

Like, if you wanna know more about oh, I'm