Ask any engineering manager where their week went and you will hear the same list. Reading through pull requests. Chasing status updates. Rewriting the same summary for three different audiences. Checking whether the ticket board still matches reality. None of it is wrong to do. Very little of it is where your highest-value contribution comes from.
The interesting thing about that list is how little of it needs judgment. It needs attention, consistency, and patience, and those are exactly the three things a person runs out of by Thursday afternoon. They are also the kinds of tasks where an AI agent can keep applying the same consistent attention without getting distracted or worn down.
The Two Kinds of Management Work
It helps to split the job in half.
The first half is routine: gathering information, formatting it, checking that things match, reminding people, producing the first version of a document. This work is predictable. The steps are the same every time. The output is judged on whether it is complete and accurate, not on whether it is insightful.
The second half is judgment: deciding what the team works on next, telling someone their approach will not scale, sensing that a quiet developer is about to quit, choosing which of two reasonable technical directions the company can live with for the next three years.
Managers burn out because the routine half quietly eats the judgment half. There is always another thread to catch up on, so the difficult conversation gets pushed to next week. Then next week has its own threads.
AI agents are very good at the routine half and genuinely bad at the judgment half. That is not a limitation to work around. It is the whole reason the split works.
What You Can Hand Over Today
You do not need a platform or a strategy document to start. You need one repetitive task and a clear description of what “done” looks like.
- Standup and status digests. An agent reads the commits, the merged pull requests, and the ticket movements from the last day and writes the summary. You read one paragraph instead of forty notifications.
- First-pass pull request review. Style, obvious bugs, missing tests, security smells. More on this below, because it is the clearest example.
- Ticket hygiene. Flag tickets with no owner, no estimate, or no movement in two weeks. Nobody enjoys this job, which is exactly why it never gets done.
- Meeting notes into actions. Turn a transcript into a list of decisions and owners, then check next week whether those owners actually did anything.
- Onboarding answers. A new developer asks where the deployment config lives. An agent that can read the repository answers in seconds and never gets tired of the question.
- Report drafts. The monthly summary for leadership starts as a draft you correct, not a blank page you dread.
Each of these saves maybe twenty minutes. That is not the point. The point is that twenty minutes of interruption costs an hour of focus, and you are paying that cost six times a day.
Depending on your stack, this might mean agents connected to GitHub or GitLab, Jira or Linear, Slack, Notion, or your internal documentation. The vendor matters far less than the access. An agent that cannot see the commits, the tickets, and the conventions you actually follow will produce something generic, and you will stop using it within a week.
Hand over the repetitive tasks to agents while focusing on the things that actually matter the most.
This is how a growing number of small engineering teams are starting to operate. Not by replacing people, but by removing the repetitive work that quietly consumes their attention.
An Example: The Pull Request Queue
Here is the case we see most often, because every technical manager has lived it.
You have eleven open pull requests. Three are small. One touches authentication. One is a dependency bump that nobody wants to read. You are the bottleneck, everyone knows it, and the queue grows faster on the days you have meetings.
Now put an agent in front of that queue. When a pull request opens, it does the reading you would have done first anyway:
- Checks the diff against the project’s conventions and points out where it drifts.
- Looks for the ordinary mistakes: an unhandled error path, a loop that will hit the database once per row, a test that asserts nothing.
- Runs a security pass. Is user input reaching a query unescaped? Did a secret get committed? Does this dependency bump pull in a package with a known advisory? Did an endpoint lose its permission check?
- Flags what is missing rather than wrong. New behaviour with no test. A migration with no rollback. A config value added in one environment only.
- Writes a short summary of what the change actually does, so you know what you are looking at before you open a single file.
By the time you sit down, the queue looks different. Six pull requests come with “nothing found, here is what it does” and take you two minutes each to confirm. Four come with specific comments the author has already fixed, because the feedback arrived ten minutes after they pushed instead of two days later. One comes flagged: the authentication change touches a permission check in a way the agent could not reason about confidently.
That last one is where you spend your afternoon. You read it properly, you talk to the developer, you think about what happens when it is wrong. That is the review that needed you.
Note what did not happen. The agent did not approve anything, did not merge, and did not decide that a trade-off was acceptable. It read carefully and sorted the pile, and a person still signed off on every change. A tireless reviewer who catches the boring problems is worth a great deal. A reviewer with the authority to ship is a different thing entirely, and we would not build that.
Start With One Thing
Pick the task you resent most this week. Write down what a good result looks like, precisely enough that someone else could check it. Hand it to an agent. Read the output yourself for a fortnight and correct it. If it holds up, keep it and pick the next one.
That is the whole method. Not a transformation programme, just a steady trade of your routine work for your attention.
How We Run It Ourselves
This is not theory for us. We are a small team of developers, and agents handle a real share of the repetitive load: first-pass reviews, digests, drafts, the checks that need consistency more than insight. It lets us take on projects that would otherwise be out of reach for a team our size.
What has not changed is who is responsible. The decisions, the reviews that carry risk, and the final word on anything we ship stay with a person whose name is on it. The tools do the groundwork; we do the thinking and stay in control of the result. The time we get back goes into the parts of a project that deserve real attention.
The teams that benefit most from AI agents are not the ones trying to automate everything. They are the ones that know which work requires human judgment and which work simply requires consistency.
If you are working out where agents could safely take friction out of your own workflow, we would be happy to talk it through.