Same AI, two outcomes: a faster team or a dead project

“

Everyone says AI makes developers faster. Why are we not faster?

It is a fair question.

My team did not write a single line of code by hand this year. Agents did, every day, in Angular and React Native codebases that people rely on, in healthcare and digital media. Our job became review: gatekeepers, agent babysitters. That is how we saw the same agent make some projects faster and nearly sink others, more than once. The model was the same. What differed was what we gave it first.

This track is about agents building your Angular.

The project that nearly sinks

Someone installs an agent, opens the biggest feature module and asks for a change. Two hours and a token bill later, there is a diff of well over a thousand lines. It touches four libraries. It imports a data-access service straight into a UI component. Every test is green, because the agent rewrote the assertions too.

Is the model stupid? No. It did exactly the task it got (why agents behave this way). The task was the problem. "Convert this", with no plan, no fences and no size limit, gives this result in most runs I have seen. The rules that keep an old monorepo alive live in people's heads, and the agent cannot read heads.

Now look at it from management's side, where the pressure comes from. Leadership hears "AI writes code" and expects the work to be fast now. Someone under pressure gets a working screen out of an agent in an afternoon and shows it in a meeting. Everyone sees the screen; nobody sees the diff behind it. From then on, a demo sets the expectation.

Then the engineers who own the codebase open the pull request. It is huge, it breaks rules the team kept for years for good reasons, and its tests were rewritten to pass. They are right not to merge it. Someone now carries the gap between what leadership saw and what the codebase can take, usually the person doing the work properly. Nothing was measured, so nothing can be argued. The demo took an afternoon, the review took weeks, and only the afternoon made it into a meeting.

“

Faster juniors, slower seniors: the work did not shrink, it moved to review.

If it gets merged anyway, the bill grows. Debt you chose on purpose is at least debt you know about. The worse kind is code nobody on the team can explain when production breaks at two in the morning. That is comprehension debt. No dashboard shows it, and an agent asked to "convert this" is the fastest way I know to grow it.

“

Technical debt you chose. Comprehension debt chose you.

The faster team

Same agent, same kind of codebase, different afternoon. The agent gets a short rules file, an architecture it cannot cross because a lint command fails when it tries, and a task with a scope and a size limit. Its first diff lands inside the fence, so the reviewer reads a decision instead of a surprise. A junior who runs it ships code that respects boundaries they have not learned yet, and learns them from the lint error.

One rule sits under all of it, and every part of this track comes back to it: the agent executes a decided scope. It never decides one. The rest of the track:

2. The three files the agent must read, pass and stay inside.
3. From ticket to task file: the agent drafts the scope, a person decides it.
4. Demote, don't delete: the migration plan that survives production.
5. Pin the behaviour first: step one of that plan, tests on the legacy code.
6. The readers your compiler cannot see: the same plan when the legacy is AngularJS.
7. What could I delete and stay green?: the agent's tests, and the migration in numbers.

Restyling with design tokens and security already have exercises in the demo repo; their written parts are coming soon.

When the demo is shown to you, one question settles most of it: do you want this to work this year, or do you want it still safe and maintained in five?

Before changing anything, look at how this repository is organised: its libraries, its lint config, and any rules file written for agents. Then tell me, in a short list, which rules of this codebase you would be most likely to break on a task like "migrate the transfers module to signals", and why. Do not write code.

Agents usually name their likely mistakes if you ask before they start. Treat the list as a draft of the rules file in the next part.

On Monday

• Someone shows you an AI demo: ask for the diff before the screen.
• Count one number per change from now on: review hours per pull request. The demo never shows it. Part 7 puts it next to the demo repo's diff sizes.
• Read the next part and spend one afternoon on the three files.

The demo app for every part is Atlas Bank, an imaginary Moroccan bank with two legacy corners waiting to be migrated: a transfer screen in an NgModule and a beneficiaries screen in AngularJS. Never client code.

---

Track 1, part 1 of the free series behind the Fast and safe: AI in your Angular codebase workshop. In the room you do it on your own codebase.