AI-assisted development: what changed on my team

AI-assisted development is a workflow change, not a typing aid

Most people picture AI-assisted software development as autocomplete: a developer types, and the model finishes the line. What I run looks more like staffing. aldena is built by its own agent teams. Tickets are written so that an agent can start one without a meeting first.

The work happens in isolated rooms. A room is one project workspace with its own server, and that server holds one checkout of the code. Every agent in the room shares it. Rooms never share a filesystem with each other, so that is where the isolation actually sits. Every change lands as a pull request, and a person has to approve it before it goes anywhere.

I have shipped aldena's own backlog this way. The code generation turned out to be the least interesting part. Four plain things decide whether this works: the ticket, the role boundaries, the guardrails, and the review gate.

I am not the only one who ended up here. Levi9's engineers published a practice report in June 2026. It covers about eighteen months of running agents inside a real delivery team.

Their agents have their own accounts. They sit in the standup channel as teammates rather than tools. They reach almost the same conclusions I did, point by point. This post is my version: what I actually run, what broke, and what I would tell a team starting now.

The unit of work is the ticket, not the prompt

The habit that changed the most was writing the work down properly. A chat prompt can afford to be vague. You are sitting right there to answer a follow-up every thirty seconds. A ticket that an agent picks up alone cannot be vague.

So every ticket I hand to an agent carries the goal, the constraints, the surfaces it touches, and a clear definition of done. If a contractor could not finish the ticket without a meeting, neither can an agent. That is the test I use.

That sounds like pure overhead until you notice the side effect. Writing tickets to that standard made the backlog better for the humans too. Vague tickets used to sit in the backlog for weeks, because everyone silently agreed not to pick them up.

An agent exposes the vagueness at once. It either stops to ask a clarifying question, or it builds the wrong thing quickly. Either way, the hole in the spec becomes impossible to ignore.

There was a second change. Each piece of work gets its own room, and so its own copy of the repository. Two tickets in one room means two agents editing one checkout, and that produces constant collisions.

So the rule is one room per ticket, one checkout per room, one branch per checkout, one pull request per branch. Inside a single room the collisions are handled a different way, and I come back to that below. I got this wrong before I got it right.

Agents hold roles, and the boundaries do the work

When I say a team of agents, I do not mean one model prompted several different ways in the same chat. I mean separate agents with separate jobs and, more important, separate refusals.

The analyst asks its clarifying questions and then writes a spec. It never writes code. The engineering manager hands the build to someone else and opens the pull request. It never writes code either.

The reviewer reads the diff, the list of changed lines, and reports what it finds. It never edits the code it reviews. The bug fixer has to reproduce the failure before it is allowed to fix anything.

The refusals matter more than the abilities. A reviewer that can edit code quietly stops being a reviewer. It fixes what it finds, and then nobody reads the findings. The second opinion you thought you had is gone.

An engineer that can merge stops waiting for review. Every boundary I keep exists for that reason. Removing one merges two roles into one and deletes a check I was counting on.

If you want the step by step of setting a team like this up, I wrote a separate walkthrough. This post is about what running one is like.

Guardrails took longer to get right than the agents

Prompting agents into useful behavior took days. Deciding what they are allowed to do is work that never quite finishes.

The mechanism I settled on is one policy per tool: allow, ask, or deny. Reading files, searching, and running the test suite are set to allow, with no interruptions. Writes, shell commands that touch anything shared, and anything inside a connected account are set to ask. The run pauses and shows me the exact call before it happens.

A room is the private workspace one project lives in. Tools a room should never touch are set to deny, so they are not available at all.

Two rules come with the roles. The delivery manager opens the pull request and stops, because its instructions say that open request is my review gate. Merging is a write tool as well, so it pauses like every other write. And bulk actions in external systems wait for explicit approval. The scrum master presents the entire proposed backlog before a single ticket is created in the tracker.

Levi9's guardrail list has the same items: no destructive actions, no production deployment without a human, permissions scoped per role. Independent teams keep arriving at the same short list. That tells me it is probably the right one.

Review stays human, and so does the accountability

Every diff an agent produces gets read by a person before it merges. Read, not skimmed. That policy is easy to state and genuinely hard to keep.

Agents produce plausible work quickly, and plausible work invites skimming. A review gate you skim stops filtering anything.

For a while the end-to-end suite kept being dismissed as flaky. Those are the tests that drive the whole app the way a real user would. The easy response was to agree, retry, and move on.

When I finally investigated, the flakes were not flakes. They were two real defects: a race in test teardown, and waits sized wrong for the environment they ran in. The agents' code was fine.

The bug was the shared assumption that an intermittent failure is harmless. That is why the gate has to be real. A person who owns the outcome has to be there to make calls like that one.

Accountability works the same way. When an agent ships a bug, the responsible party is the person who approved the pull request. I keep that rule because it is the only arrangement that keeps review honest. The moment blame can be routed to a model, nobody reads a diff carefully again.

What failed while I built this way

A practice report that skips the failures is an ad. Four things went wrong for me.

• Agents declare done too early. A green build, half the acceptance criteria met, and full confidence in the summary. The fix was dull but it worked. I write acceptance criteria into the ticket, add a reviewer whose only job is the diff, and hold the agent to a definition of done.
• Parallel rooms fought over shared state. Two rooms had separate checkouts but pointed at one development datastore, and the failures looked random for longer than I want to admit. It stopped once every checkout got its own key namespace, its own prefix on every stored key. Separate checkouts are not enough on their own. Anything the two of them both reach has to be split as well.
• Confident diagnosis without evidence. Continuous integration (CI) is the automated build and test run. A crash in CI got blamed on memory pressure, in a paragraph that read beautifully. Actual measurement showed memory was fine and the cause was somewhere else. Agents learn this habit from people, because a plausible story feels like a finding. I now ask for the measurement rather than the story.
• Overnight autonomy has a size limit. Small, well-scoped tickets can run unattended from start to finish. Anything with real ambiguity needs a human answering questions during the run, not just signing off at the end. Levi9 reports the same limit. I have stopped trying to work around it, and I aim for autonomy with limits rather than a team that runs with nobody watching.

What it costs, and where the spend actually goes

I am not going to give you a fake dollars-per-feature number. The structure of the bill is more useful anyway.

Model choice per agent is the biggest single factor in what an agent costs. My reviewer runs on a heavyweight reasoning model at high effort. A missed defect costs more than the tokens. The room assistant runs on something cheap and fast.

In aldena that choice is made per agent. Usage is charged at the provider's list rate from one prepaid team balance. Every model's rate is published upfront, so you can price a swap before you make it.

Most of the token spend goes to reading, not writing. That surprised me. Investigation, review passes, and test output cost far more than producing the diff itself. Budgeting by lines of code generated misses most of the bill.

Compute is the smaller and steadier part of the bill. A room's server is metered by the hour. The rate depends on the size you pick, with the current rates on the pricing page.

Levi9 warns that usage-based billing climbs fast without measurement discipline, and I agree. I do two things about that. A prepaid balance with a hard stop means work pauses when the balance reaches zero, instead of running up a bill. And I track cost per shipped ticket rather than per month, because ticket types vary too much for a monthly average to mean anything.

How this works in aldena

aldena is both how I build and what I build, so this section can stay concrete.

A project lives in a room. The room has its own server, its own credentials and integrations, and its own memory. Nothing crosses between rooms.

Into the room you hire agents from a roster of prebuilt roles. Analyst, architect, engineering manager, developers, reviewer, and bug fixer are among them. Each one runs on the model you pick for it.

You then arrange them in a hierarchy, so work travels down manager lines and results come back up. The org chart canvas shows each hand-off while it happens.

This is also the answer to collisions inside one room. The agents there share one checkout, so isolation cannot be the protection. Instead the engineering manager is instructed to hand work to one report at a time and wait for the reply before starting the next. Parallel work happens across rooms, and one room works through its queue in order.

What the team learns lives in memory: shared room facts every agent reads, plus private working notes per agent. Both survive the chat that created them.

Everything that touches your accounts passes the approval gate. That is the point where a run stops and waits for a person. It means allow, ask, or deny per tool. It also means questions to a human that can never be switched off, and pull requests that sit open until you merge them yourself.

Delivery happens in the tools you already use. Connectors attach per room, and GitHub, Linear, and Google Drive are a few of them. Code arrives as pull requests, and backlogs arrive in your tracker.

Maybe you are still comparing individual coding agents rather than running a team of them. In that case I keep a separate guide to the coding agents themselves. The structure above is what I use once one agent stops being enough.

Questions I keep getting

Is this fully autonomous software development?

No, and I have stopped chasing that. AI-assisted means agents do the production work inside a structure of tickets, roles, and gates. The autonomy is sized to the risk of each tool call.

Full autonomy holds up for small scoped tickets and fails beyond that. That is what I see, and it matches every honest report I have read.

Who is responsible when an agent ships a bug?

The person who approved the pull request. Accountability never transfers to the model. Every working setup I know of, mine included, states that rule out loud rather than leaving it implied.

Is AI-assisted development replacing developers?

It is replacing the typing. Specification, architecture, review, and the judgment about what should exist at all did not go away. They moved up.

My days now contain far more writing and reading than keystroke-level coding. A developer who can specify and review well produces more in this setup, not less.

Start with one ticket

Skip the grand rollout. Pick one well-scoped bug or one small feature. Write the ticket so a stranger could complete it without a meeting. Give the agent ask-by-default on everything that writes.

Then read the pull request as carefully as if a person had opened it. Keep a note of everything you had to correct in review. That list is your next round of ticket templates and guardrails.

Promote a tool from ask to allow only after a long run of approvals where nothing went wrong. That loop of ticket, run, review, and adjust is the entire practice. Everything else is scale.