Introduction

Today, I want to talk about how to hire engineers.

The Two-Sided Problem: Engineers, Companies, and the End of Coding as an Edge

There is a two -sided problem. Let me rephrase this.

On one side, as engineers, we have to relearn whatever we're doing. Coding is not a competitive edge. If you're looking for a job or you want to build something, something, it's no longer an edge.

On the other hand, there are companies and for companies there's a big problem of hiring and training talent. And again, before we had these coding exercises and this and that and very complicated hiring processes. That's no longer working

and very few companies know how to hire talent and what to look for in people and most importantly what to do about the engineering teams they already have because you may have amazing senior engineers there maybe they're skeptical about AI and you have to explain to them what is their role now what they're gonna do in the next five to ten years so what are you gonna do and my take on this is that managers in

engineering teams already have the skills they just need to transfer them and explain those skills to the engineers and the parallel they're very very clear parallel between orchestrating workflows, for example, in coding agents or marketing workflows, that's what Alex Russo will talk about, and what managers do.

Because we, as managers, and I think I'm in an interesting position because I was working as an IC, as an engineer for many years, and then I transitioned into management and then then I started my own company. I can see this from multiple perspectives and it's working really well, so bear with me. I'll try to do everything in 15 minutes.

Maybe I'll have to click on myself.

The problem is not about AI. The problem is that there's a new tool tool that eliminates the coding, as I said.

Basically, that's what I said before, sorry.

What Great Engineering Managers Do (and Why It Matters More Now)

There is a very specific set of skills that makes a great engineering manager. For example, a great engineering manager is very good at communication.

They're very good at explaining explaining what is the problem, how do we approach it, what's the context. They're very good at prioritization, explaining deliberate steps that we need to complete, explaining what's important, what's not important.

They're very good at delegation. To delegate, you must know that you basically shouldn't touch any code yourself. That's what engineers struggle with.

They're like, well, what I'm going to do, I'm not going to write the code. Well, you're going to do everything else besides writing the code, and I'm going to show you that there's actually a lot.

Feedback Loops and “Loop Engineering”

The great engineer manager is really good at giving feedback because just like Cloud Code or Cursor or whatever coding agent you use, people make mistakes and now there's a lot of discussions on X and on different platforms about loop engineering.

By the way, who heard about loop engineering? It's a new hot term. You're going You're going to hear about it more in the next few months, I'm sure.

What is it? Well, have you heard about context engineering? That was the hot term before. Now loop engineering is basically creating these feedback loops.

So you have a coding agent that takes something like a PRD, a very good, well articulated description of a task. It goes to implement, but also in the PRD you describe the acceptance criteria. So, it knows not only how to implement, but also how to test the implementation.

And of course, you need like a full test suite to make sure nothing breaks and so on. So, a good loop is the one where a coding agent can go and, I don't know, pick up a ticket in JIRA, implement it, run some checks, and merge it safely. That's a good loop.

And the longer the loop, the better. better.

The better the model, we've seen over the past few months, we went from, I don't know, five minute loops to 30 minute loops. Now it can run for four hours, Cloud Code, for example. So that's going to be a hot topic of the next few months.

So returning to great engineering managers, they're good at conflict resolution because you may have multiple engineers working on a problem and they start clashing. They may have different opinions.

Well, with coding agents, you can have the same thing. You can can have Cloud Code implementing the feature, you can have Codecs reviewing the feature, they disagree, and how do you resolve it? So you can have specific workflows and rules in place to deal with this.

And of course, course correcting without jumping in and doing everything yourself. That's a very important management skill.

Parallels Between Managing People and Orchestrating Agents

So as I said, there's a lot of parallels between human management and orchestrating AI.

AI is a very broad term. You can mean so many things by AI.

In my case, it's about coding agents and about teaching engineers how to get away from coding and become more of a team leader of these coding agents.

The parallels are communication and context sharing is now prompt design and passing the context.

I would probably add collecting the context because because it doesn't appear magically.

And again, you need some rules and workflows in place for that.

Prioritization decision making is very similar to task decomposition and sequencing.

If you ever, raise your hand, whoever asked the coding agent to write a PRD. A PRD. It's like, hmm?

Yeah, for product requirements document. document. Basically, you don't start a coding task with just, hey, make me something beautiful.

You have to explain it in very specific terms because your idea of what is beautiful or what the feature should do would most likely be very different from what other person thinks or a coding agent thinks.

Decomposition sequencing is just the second step. It's no longer enough enough to describe what you want. You need to describe different phases of how you want

this implemented. Like, do this, then go test this, then do that, then go validate this way and so on.

That's what good engineering managers do with their engineers as well. Because otherwise, the more freedom you leave for people and coding agents, the more unpredictable predictable as a result. But you also need to leave some freedom for creativity.

Delegation, very similar to agent role definition. So we're no longer in the place where we have just one coding agent.

The best teams they have, like the best engineers, they have multiple like cursor or cloud code instances with different roles and there are many ways they can interact with each other maybe they work in sequences maybe they send messages to each other there are systems for that as well coaching and feedback

loops is the loops I was talking about you build loops so that the agent knows if the work has been completed if nothing has broken so typically you You would give an agent access to something like logs or CI system with, that's probably also logs, with log of events, like how the deployment, was it successful or not successful? You give it access to the browser so that instead of you having to go, this is a very

typical problem for a manager, right? You assign a ticket to an engineer, they tell you, okay, this is completed. it. You go and test it yourself by hand, or maybe you're lucky to have a QA team and they go and test it themselves in the browser.

And they're like, well, it doesn't work exactly. Some of it works. And then they switch the ticket back to the engineer and say, go and test it yourself.

So the loops and these feedback loops is basically the agent, just like a human going and testing themselves before telling that something is complete.

Conflict resolution is arbitration and handling errors because sometimes agents, just like people, they give up. They say, well, I tried everything, now go do it yourself. And again, if you're building these loops and if you're orchestrating workflows, you want to give an agent a way out.

For example, you can add a bunch of MCP servers so that they go and search online. Or you can give them access to the knowledge base. Maybe there was a similar problem before. They can go and search it, just like people.

Because there are engineers who try a few times and they're like, well, I don't know what to do. I tried everything. As a good manager, you always have to give them the next step. And best engineers, they know what would be the best step. And sometimes it's just asking somebody else.

rails. Again, that can be part of this orchestrated process. Course correcting is basically guard rails. Again, this is part of building these loops.

Loops is just a new term for the same workflow orchestration. This is basically showing the agent where it is breaking out of the certain path you left for it.

I'll give you a very specific example and this is just an illustration of a well -orchestrated workflow or loop. You have a task, no matter how complex it is, the task has to be decomposed, assigned to different agents or different people with different roles, then they actually go and implement, that part is pretty much solved by new models.

When Fable and Mythos and whatever comes next comes out, I'm sure we'll be pretty much done with coding as in generating code. But in my opinion, that was never the biggest problem.

You verify. You make sure that nothing has been broken. You make sure that something actually works from what's been been implemented new.

Most of the times it doesn't, so some steps have to be made to correct the mistakes. And then you iterate, you just repeat until you go through all these steps and verification passes. Very same process as human teams do.

So, if we still have time I can give a very specific example.

A Practical Workflow Example: From Tickets to Merged Pull Requests

So, an example comes from the internet. A lot of of people are talking about these amazing workflows where they just assign a Jira ticket and the agent picks it up and then just merges pull requests.

I think Anthropic is talking about this all the time. Have you heard about these magical processes? Do you want to have this as well, more or less?

Okay. I just wanted to show you how it can be done to give you some food for thought because it certainly can be done, but I just want to illustrate that it's an engineering task. It's not magical AI this, AI that task.

So let's imagine the scenario. You have customer support tickets and you want an agent to pick them up and recommend fixes. Fixes recommendation would be a pull request that somebody has to review and merge but that's a very different story.

So the The constraints are that the agent should work alongside humans, so they should use existing ticket system, and so on. So you may have a number of agents that have specific tasks.

The instinct is that the human or the agent will research the problem, will code a solution, will test the solution, and update the documentation. implementation.

There was supposed to be another slide, I'll show you that one a bit later. That slide is missing. What was supposed to be there is a 15 -step process. In order for this to magically ... I just thought I will have a little bit less time. so

The Hidden Work: Research, Reproduction, Verification, and Testing

The interesting part that most engineers are thinking about is this step the coding part But in reality, they're like 14 other steps because if you want To even start working on a ticket first.

You need to do a lot of research You need to look at previous tickets. Maybe a similar problem was sir sold before

You need to try to reproduce the problem because if the human or the agent can't reproduce the problem that is reported then you won't have any kind of verification to make sure that you actually fixed it.

You need to search the knowledge base just to understand the code base, right? You need to read the documentation, you need to read the code and that's all part of the research and that's like four tasks.

So a good engineer would do all four instead of jumping straight into coding.

A good agent would do the same and if you want to build these orchestrated loops then you need to build this capability and typically it's at least that's the way

we do it it's a separate research agent that goes and gathers the context and prepares all this for the coding agents so that when the coding agent starts it knows exactly how to reproduce the problem where to look for the potential issues and so on then the coding agent just does the coding that's that's the

simple part now but again that's not enough you need to test you did the research so you know how to verify the problem and you go and verify that the problem is gone but that's not enough because now you need to make sure that nothing else is broken exactly so you need to go and run the test suit and

And that requires some knowledge about how to run the test here. Do you run all the tests? Do you run part of them? Do you run full regression?

That depends on the ticket. So there's a lot of moving pieces there. And somebody has to describe this process because AI wouldn't magically figure this out.

And if you ever built a process in the human team, it's exactly the same. Because if you just drop a new engineer who never worked with your systems, with whatever you do, And you ask them to start working on the tickets. They will get stuck immediately because they don't know where to go

They don't know where to look. They don't know how to validate They're just they may do something but the probability of that not being a fix or just being something random Exactly and maybe with humans they will take a full week to understand the code base and the solution will still be crap

Because you know, you don't have the process in place, right? So So you have to do exactly the same thing with AI.

And again, managers know how to do this. We've been doing this all along. Engineers don't want to do this. And are there any engineers today in?

Okay, amazing. Are you skeptical about AI or optimistic? Not skeptical. Accepted.

Okay, you accept your fate. So, okay. Skeptimistic is a new term. I'll remember that.

that. So, I'm actually sceptimistic as well. Amazing term. I will ask about your name later

so that I can keep the copyright. I think there's a lot of opportunity for us as engineers and even though I've been working as a manager for the past ten years, I still think of myself as an engineer because, hey, with cloud code I can vibe code now.

Or, I'm not actually vibe coding. I know what I'm doing, but still, not as good as other engineers. I think there's

a lot of opportunity for us engineers if we get out of this coding block and we start thinking more like managers and thinking about other steps because AI is not going to do that. AI is going to do a very specific task that you gave it and you need to start orchestrating and and creating these loops, flows, workflows, whatever

you call them. Then the whole system starts working. And building those systems is engineering.

So it's just moving from writing code and putting the semicolon in the right place to the higher level architecture, not just architecture of the systems we build,

but the architecture of how the system is being built. In my opinion, that's a very interesting part. part.

When the System Breaks: Guardrails, Checkpoints, and Redundancy

This was supposed to be an example of you've orchestrated a very neat workflow when the agent knows exactly what to do, but at some point, the system starts to fail because the agent told you everything is perfect.

I validated everything. I even merged the pull request.

Maybe it acts as a junior engineer, so it just merges everything, and nobody reviews use this. So what do you do if this system starts failing?

There are bugs, new bugs. You were fixing some bugs, you get some new bugs as a result. Very common problem.

Research is hallucinating. Testing is missing the edge cases, because tests were generated by AI, and it just wrote the most amazing tests that always pass.

so you need to redesign the workflow and again I would think about this as redesigning the workflows with humans because this thing happens with humans all the time we've designed as you know as engineer managers we've designed the most amazing workflow every everybody knows what they're doing but you know

the whole system breaks still so you need to start building more complex complex loops, you need to start building checkpoints.

We passed the verification, okay, let's run another agent with another model to make sure that we actually passed the verification. And maybe let's do it three times to be 100 % sure, it costs more tokens and more time,

but there's a reason why when Portage's ships were sailing to, I don't know, to Brazil, In Brazil, they had three compasses because if one of them fails and you just have one, you don't know if it failed or not. If you have two, you don't know which one is working.

But if you have three, then you have a reasonable council. And if two of them agree on something, then that's your verification.

So you start thinking about these things and you start building these checkpoints and on checkpoints you start course correcting the flow and so on.

It's very interesting because with humans, when managing humans, we never could actually engineer this process because people are too unpredictable. They don't obey the rules. But agents do, and they would do whatever you tell them.

If you tell them, do this 100 times, and if 80 % runs, you got a good result, okay, you can do it. A human would never run it a hundred times.

The whole point was that we're way past prompt engineering, and it's less important to design a perfect prompt, and it's more important to design the right workflow. It shouldn't be perfect. It's a very iterative process.

You just need to start. It will fail somewhere. you build another guardrail, and if you're doing this for long enough time, then you have your perfect orchestrated workflow or loop, whatever you call it.

Takeaways and Conclusion

Yeah, takeaways. Agents behave like junior team members. You have to give them structure.

You have to build verification and and feedback loops, orchestrating loops is the most important skill, in my opinion. As a company, you can't hire your way around this, because there are simply not enough people out there who can do this.

I think there's a lot of opportunity for engineers to step up, and instead of being skeptical or skeptimistic, actually take action and learn to build these loops, because it's going going to be invalid.

And I think I should have a QR code. I have a newsletter on Substack. If you scan the QR code, you'll be able to read more about engineering leadership.

I'm done. Thank you. Wonderful. Thank you very much.

Thank you.