Two agents, two contexts: Claude Code at home, Kiro CLI in an enterprise codebase

TL;DR: I run two coding agents in two very different contexts. At home, Claude Code on my own products, where I set every guardrail and the blast radius is mine. At my day job, an approved agentic CLI assistant inside a large enterprise codebase, where someone else owns the rules, the repository is enormous and split across many packages, and "move fast" meets change management. The operating discipline transfers almost completely. The autonomy does not. This is what actually changes when the agent is the same idea but the environment is a different sport, and why the constraints are a feature rather than a cage.

Same idea, two environments

On my own products I have described the setup elsewhere: a safety-checked permission mode, hard deny rules, a pre-execution hook, and an instruction to work to completion. I own all of it. If I want the agent to grind through a migration overnight, I decide the guardrails that make that safe, and if I get it wrong, I am the one who cleans up.

Inside a large company none of that is mine to set. The tool is whatever the organization has approved and standardized on - in my case an agentic command-line assistant that is the sanctioned AI co-engineer in that environment. The permission posture, the review culture, the branching and release rules, the design system you must build against - all of it is decided above you and applies to everyone. You are a participant in a system, not the author of it. That single difference cascades into everything else.

What transfers

The encouraging part: the habits that make an agent useful are the same in both places, because they are about how you work, not about which tool you hold.

Lean context beats a stuffed one. A focused session on one clearly-bounded task produces better output than a sprawling one, whether the repo is a weekend project or a decade-old enterprise platform. If anything the discipline matters more at scale, because a huge codebase gives the model far more rope to wander.

Every claim gets verified at the level it was made.An agent reporting "done" is a claim, not a fact, and that is true regardless of who owns the repo. Build it, run the tests, open the page and look. In an enterprise context this is not optional politeness - it is the thing standing between you and a production incident on a platform that serves a lot of people.

Small chunks with review at each step.The defense against the endless-fixes spiral - work in fragments, catch mistakes early - is identical. The stakes just change what "early" is worth.

What changes

The autonomy ceiling is lower, and correctly so. On my own product the worst realistic case is a branch I never merge. In a shared enterprise codebase the worst case is much larger - other teams depend on the same packages, releases move through several environments, and a bad change has a wide blast radius. So the mode is more conservative by design. You lean on the agent for the same tedious, mechanical, verifiable work, but you keep a much tighter rein on anything that reaches shared surfaces.

You do not write the deny rules. This sounds like a loss of control and is mostly a relief. The boundaries are set centrally, they apply uniformly, and they are not yours to weaken in a moment of impatience. Your job shifts from designing the guardrails to working effectively inside them - which is a genuinely different skill, and a valuable one.

The codebase is too big to hold, so retrieval discipline dominates. A solo product fits in your head; a large polyrepo platform does not. More of the work becomes pointing the agent at the right slice, giving it the right conventions, and resisting the temptation to let it range across the whole thing. The context architecture question - what loads, what the agent should even be looking at - stops being an optimization and becomes the main event.

Change management is a real actor. At home, shipping is a decision I make. At work, shipping moves through process - reviews, release trains, environment promotion. The agent accelerates the engineering inside each step, but it does not get to skip the steps, and pretending otherwise is how you become the person who broke the release.

Why the constraints are a feature

It would be easy to frame the enterprise version as the diminished one - less autonomy, more process, someone else's rules. I have come to see it the other way. The constraints are exactly what let a large organization allow agents at all, and learning to be fast inside them is a more transferable skill than being fast in a sandbox you fully control. Anyone can move quickly when they own every rule and the blast radius is a hobby project. Moving quickly when the rules are fixed, the codebase is huge, and the cost of being wrong is real - that is the version that matters to a company deciding whether AI-augmented engineering is safe to adopt.

The two contexts end up reinforcing each other. Owning the full setup at home taught me exactly why each enterprise guardrail exists, so I stopped experiencing them as friction. Working inside someone else's guardrails taught me which of my own were theater and which were load-bearing. The tool is almost incidental; the discipline is the thing that travels.

What carries over

• Discipline transfers, autonomy does not. Lean context, verification, and small chunks work everywhere; how much rope the agent gets depends entirely on the blast radius.
• Match the leash to the blast radius. A branch you never merge is a fine worst case; a shared release is not, so the shared context gets a shorter leash.
• Not owning the rules is mostly a relief. Central, uniform guardrails you cannot weaken in a weak moment are a feature.
• At scale, retrieval is the main event. A codebase too big to hold makes pointing the agent at the right slice the core skill.
• Being fast inside fixed constraints is the transferable skill. Speed in a sandbox you fully control proves less than speed where being wrong costs something.