Ask a room of engineers how much they let AI agents do on their own, and you’ll get multiple different answers. All of them may be right. Put their reasoning side by side, though, and three factors seem to drive the difference: team size, what existed before AI showed up, and how much of the development pipeline each engineer owns end to end.
I was the guest host for Scaling Tech Podcast Episode 65: Different Teams, Different Rules: What Senior Engineers Actually Let AI Do. I brought in three senior engineers from our team, each working under a different kind of engagement: a nearshore software development team embedded in a large telecom build, a custom nearshore staff augment team inside a healthcare-regulated enterprise, and a single WebRTC developer staff augment.
I asked all three the same question: how much are you actually comfortable letting AI do?
More dependencies, less agent autonomy
Tahir Gölge is working on a nearshore software development team of 13-14 people, building a large telecom product across backend, two mobile apps, QA, and a DevOps layer, in addition to multiple outside partners. His rule is to give agents almost no autonomy.
“I am giving a very very very limited context and very small things. Because giving a huge context can actually make [the agent] overfit to the context you give, and they don’t have a mechanism to weigh the context you have given”
This is a mechanical argument. An agent handed a stack of conflicting or partially-relevant documents doesn’t know which one matters more. It averages them, which is a common issue in a complex environment. Tahir’s fix shrinks the task until there’s little ambiguity and the context is correct, explicitly mentioning what’s out of bounds: “do not involve this component, do not re-work or get involved with this.” The alternative can get expensive fast. Earlier on, a less cautious developer gave the AI broad access:
“I’ve seen it quite a lot. I’ve seen one case where the AI just deleted the staging branch.”
That is what autonomy looks like in a high-dependency environment: smaller tasks, tighter permissions, clear boundaries, and guardrails that get stronger after every incident.
AI agents didn’t change the rules. In this project, they upheld how important the rules already were. Clear ownership, defined roles, and appropriate permissions matter whether your team is made of people, agents, or both.
Existing guardrails buy room to relax, not room to trust
Andrea Phillips is working on a small nearshore staff augmentation team inside a large, healthcare-regulated organization where the architecture, frameworks, and standards already existed before she arrived. That structure changes what autonomy means.
“Not necessarily trust it, but yeah, I can relax a little bit more. All of the alarms are there … It’s easier to see where it’s not supposed to be going.”
Existing guardrails make failure cheaper to catch. They don’t make the agent smarter. Andrea’s enterprise framework also limits what agents can do.
“It does limit what the agents can do. The limits are there for a reason, and protect an entire organization or code base. So errors or bugs or things that shouldn’t be there don’t spread all over.”
For a client in a regulated industry, existing architecture becomes the thing that makes AI-assisted work safe to scale, rather than overhead to work around.
Deep familiarity earns more autonomous AI coding
Justin Williams is a single WebRTC developer staff augment who works embedded in a small client team. He has significant ownership and autonomy. He’s known the codebase since before AI tooling existed. That history lets him hand over more, on the parts of the system that history actually covers.
“For work on a well-defined codebase, as I mentioned that we’ve had for at least five years, that work is quite well defined in itself. In those cases, if it’s like a feature or a bug fix, I can actually provide the agent more autonomy since it has more context, and the guardrails as well as the existing design patterns and tests actually do steer the agent quite well.”
The unattended stretches he allows stay short:
“Those do tend to be on the order of like up to tens of minutes, nothing too crazy more than that.”
The boundary holds firm around infrastructure and cost:
“If it’s like spinning up a server or something like that, I prefer to have it write a script rather than call the command line tools itself. I’ll have it generate the script for me and I’ll review it.”
Justin turns autonomy up for logic he’s seen play out repeatedly, and down to zero for anything that spends money or touches production infrastructure directly.
What determines AI agent autonomy across nearshore teams
A senior engineer answers the autonomy question from experience, project by project, not from a formula. Team size and project complexity determine how many boundaries a task needs. What existed before AI arrived determines how much of the safety net is already built. And how closely an engineer can actually watch the work determines how long a leash makes sense.
In the end, this is less about having a “good agent” or even a particularly good programmer. It is about good engineering hygiene: clear ownership, well-defined responsibilities, defined permissions, reliable review processes, and a team structure that makes it obvious who can change what, when, and why. AI does not replace those fundamentals. It makes their absence much easier to see, and much more expensive to ignore.
That calibration doesn’t look the same across a nearshore team, a staff augmentation placement, or a single embedded developer, and it shouldn’t. It’s exactly what our engineers bring to whichever engagement model fits your project: the judgment to know when to shrink a task, when to lean on existing guardrails, when to add new ones, and when a well-understood system can genuinely support a longer unsupervised stretch.
Just as important, they bring the engineering practices that make that autonomy safe: clear permissions, scoped access, code review, testing, deployment controls, defined ownership, and explicit boundaries around what an agent can and cannot touch. Good agentic development is not about giving AI more freedom. It is about building the right framework so you can give it exactly as much freedom as the work can safely support.
If you need to scale your software development team, we can help you build one with AI-enabled engineers who know how to make these calls. Build a nearshore team with AgilityFeat.
