The Boolean and the Watcher: Two Sides of AI-Assisted Coding
We were knee-deep in a legacy AngularJS component. The kind of file nobody touches if they can help it — the original author had left the company long ago, the codebase around it had moved on to Angular 2+ and beyond, and this one file had just quietly survived every migration, doing its job, asking nothing, understood by no one currently on the team.
We were trying to improve its rendering performance. Batch the updates, reduce the churn, stop it hammering the DOM on every cycle. It was genuinely tricky work — the kind that requires you to understand not just what the code does, but why it was written that way in the first place, by someone who is no longer there to ask.
In the same session, I watched AI be both the worst and best thing in the room.
The Flag
Early in the session, we needed to do something simple: hide the component while the batch rendering logic was being rebuilt, then show it again once it was done. A visibility flag. isReady = false at the top, flip it to true when the loop completes, let ng-if respond.
My coworker opened his AI assistant and prompted it.
I watched him type out the request — describing the component, explaining the loop, asking what the cleanest approach would be. The AI came back with a snippet. He pasted it in. It worked.
I didn’t say anything. But it stayed with me.
This wasn’t a hard problem. It wasn’t a tricky async edge case or a nuanced question about digest cycle behaviour. It was a flag. A true and a false. The most atomic unit of programming logic.
What bothered me wasn’t the laziness — we all cut corners sometimes. What bothered me was that it didn’t look like laziness at all. It looked like instinct. His first move when encountering any decision in the code, regardless of how small, was to immediately offload it.
And I started quietly wondering: does he actually know how to solve this? Or has he just never had to find out?
The Watchers
Then the session turned, and AI earned its keep.
We were looking at a performance issue deeper in the component — the kind that’s invisible until you know to look for it. The AI, with the component code in context, pointed out something none of us had caught: the way the $watch expressions were written was causing an enormous number of watchers to be registered. With a bit of probing, it surfaced the real problem — a pattern that could be replaced with $watchCollection or restructured using an observer pattern to avoid the watcher explosion entirely.
Here’s the thing: none of us on the team had written AngularJS in years. Some of the junior engineers had never touched it — their entire careers had been in Angular 2+. The $watch API, the digest cycle, the performance implications of watcher count — these are things that simply aren’t in the vocabulary of someone who joined after the migration. The knowledge had walked out the door with the original author.
Without AI, we would have been doing archaeology. Reading old AngularJS documentation, digging through Stack Overflow threads from 2015, hoping we were asking the right questions. The AI gave us a direct line to that institutional knowledge — not just the syntax, but the reasoning behind why the observer pattern was the right fix for this specific case.
That’s AI doing exactly what it should do.
Two Uses, Same Session
What struck me, thinking about it afterward, was that both of these things happened in the same hour of the same session — and they felt completely different in kind.
In the first case, the AI was a substitute for thinking. The problem was within reach. The solution was a thought away. Reaching for the tool wasn’t necessary; it was just faster than engaging.
In the second case, the AI was a bridge across a genuine knowledge gap. The problem was not within reach. The knowledge required had left the building. No amount of thinking harder was going to surface the AngularJS watcher internals from the minds of people who had never worked in AngularJS. The tool didn’t replace thinking — it gave us something to think with.
The difference isn’t subtle once you see it, but I suspect most engineers don’t consciously make this distinction as they work. The prompt box looks the same in both cases.
What the Research Says
A few days later I came across a study published by Anthropic: How AI assistance impacts the formation of coding skills. Researchers ran a randomised controlled trial with 52 software engineers, split into two groups — one coding by hand, one with AI assistance. The task was learning Trio, a Python library for asynchronous programming.
The results were stark. The AI group finished slightly faster, but scored 17% lower on the comprehension quiz that followed — nearly two letter grades. The biggest gap wasn’t on syntax. It was on debugging — understanding when code is wrong and why.
But the study also found that not all AI use produced the same outcome. Participants who scored well on the quiz used AI differently. They asked conceptual questions. They requested explanations alongside code. They followed up with “why does this work?” They were using AI to build understanding, not bypass it.
The AngularJS watcher discovery was that kind of use. We didn’t just take the fix — we asked why so many watchers were accumulating, what the observer pattern was doing differently, what the digest cycle was actually doing under the hood. The AI became a teacher for a technology none of us had learned the hard way.
The boolean was the other kind of use entirely.
The Real Danger Is the Invisible Line
I don’t think the risk of AI in software development is that it will make us lazy. Lazy has always existed. The risk is more specific: AI makes it possible to produce code without understanding it, at a pace and polish that makes the gap invisible.
A junior engineer in 2025 can ship working features in frameworks they don’t understand, using patterns they couldn’t explain, fixing bugs through prompting rather than reasoning. The output looks the same. The understanding underneath is completely different.
And that gap matters most precisely when things go wrong — which is when understanding is the only thing that saves you. When the AI-generated code hits a production edge case. When the watcher explosion isn’t flagged because nobody thought to ask. When the original author of the legacy component is gone and the only thing left is the code itself.
If you’ve never been stuck and had to think your way out, you don’t have the muscle memory for it. The Anthropic study puts it plainly: cognitive effort — and even getting painfully stuck — is likely important for fostering mastery.
The Distinction Worth Carrying
There’s a version of AI-assisted development that compounds your skills over time. You bring a point of view to every prompt, you interrogate what comes back, you leave each session understanding something you didn’t before. The AngularJS moment was that version.
There’s another version that quietly hollows out the foundations. Not dramatically — no single boolean flag breaks anyone. But habit by habit, prompt by prompt, the instinct to think first atrophies. You stop reaching for the understanding and start reaching for the answer.
The flag and the watcher happened an hour apart in the same session. One was a missed opportunity. The other was AI at its genuine best — surfacing knowledge that had genuinely been lost, from a technology that predated half the team.
The tool was identical. The use was entirely different.
That distinction is worth being deliberate about. Not just for junior engineers — for all of us.
The Anthropic study referenced is: “How AI assistance impacts the formation of coding skills” (Shen & Tamkin, 2026). Read it at anthropic.com/research/AI-assistance-coding-skills.