TL;DR: AI can produce a lot, quickly. Your job is still to keep the work coherent: what are we changing, why, what breaks, how do we know, and how do we roll it out. Delegation is the win; responsibility doesn’t go away.
I’m talking about tools like ChatGPT, GitHub Copilot Chat/agent features, Cursor, and Windsurf used as delegated, parallel workers, not just autocomplete.
Not a policy. It’s my working mental model while the ground is still moving.
Autocomplete - “Intellisense on crack”
The version of AI I’m not excited about is predictive autocomplete that confidently guesses whole functions, control flow, or behaviour from a few lines of context.
When I’m choosing to do the coding myself, I want to think: shape the solution deliberately, reason about constraints, edge cases, and failure modes. Having an LLM jump ahead and guess my intent often interrupts that process more than it helps.
I am a fan of mechanical shortcuts. Typing ctor in C# and getting a constructor is useful. Generating a test skeleton is useful. That kind of acceleration has been around forever.
What I don’t want is intent guessed for me.
It’s also worth being fair: most of us initially framed AI-assisted coding around less boilerplate and smarter in-editor suggestions. Reasonable place to start.
The problem is that this framing has lingered, and it obscures where the leverage actually is now.
Code review as an example
I’m seeing the same sales pitch around code review: treat review as a throughput problem, then sell AI as the fix.
That’s risky, because review is one of the places we most need human attention. It’s where we check intent and system impact: what are we changing, why, what could break, and what does this do to everything around it.
If a draft was generated in seconds, review can accidentally become the first time a human brain really processes the change. That is a massive shift in responsibility, and it’s not a shift you want by default.
I do use AI for code reviews, but more for broad coverage, like automated tests or static analysis. It catches obvious issues and asks awkward questions early, so I (the human) can spend time on the high-value part of review. Even here, model choice matters: fast models for surface-level checks; stronger reasoning models when I want it to challenge risk and trade-offs. (See my quick picks.)
But AI-in-review has to be intentional. I’ll pull the diff down, ask targeted questions, and treat it as one of the steps in my review. Always-on analysis in a PR risks becoming ambient noise. I want AI to sharpen attention, not dilute it. That may change as the tools improve, but for now I prefer to use it deliberately.
And anyway: a developer working well with AI should already have challenged their own code before it reaches review. Review often does not need accelerating. It needs less volume arriving in the first place.
The mode that actually changed how I work
For the medium term at least, we’ve settled into a different shape of collaboration with AI, and it is not autocomplete. It is agentic chat: chat, plus delegated tasks that can read code, suggest edits across files, run checks, and iterate.
(Some people dismiss this as “vibe coding”, a term that started as a description of exploratory work, but has since been weaponised to mean undisciplined, unserious, and amateur.)
Instead, delegation: working the way I already work with a team, just faster and more parallel. Delegation also requires more discipline than doing it yourself.
This feels natural if your day already involves coordinating work, managing risk, and holding the system in your head, rather than staying deep in one implementation thread.
On non-trivial work there are always multiple threads: explore an approach, test assumptions, read docs, check edge cases, and do setup/testing. Agentic AI lets me run those threads in parallel. I’ll put one agent on a migration strategy, another on a data model, another on a library I don’t fully trust yet. I question the answers, push back, redirect, discard a lot, and I’m still the one steering: scope, priorities, and what “done” means.
That doesn’t feel like automation. It feels like leadership.
Why this feels familiar to experienced engineers
Agentic AI clicked for me quickly because it doesn’t require a new way of thinking about engineering.
Many of the practices we rely on now, exist to reduce risk, not maximise speed: pairing, design review, parallelising work, challenging assumptions. Agentic AI fits into this perfectly.
The work does not fundamentally change. What changes is where leverage sits.
This is why the mockery around “AI-assisted juniors” misses the point. When code is cheap, unclear intent is expensive, and you feel it faster. The answer isn’t to reject the tool. It’s to double down on what good teams already do: strong review, explicit assumptions, and real ownership.
Agentic AI makes it much faster to try ideas, but it does not remove the need to do the work engineers have always done: understanding requirements, thinking through design, checking assumptions, and considering system impact.
Even if “debugging AI code takes longer” were true, it wouldn’t mean AI is the problem. It would mean the change wasn’t thought through and the cost showed up later. Agentic AI lets you do that thinking faster and in parallel, it doesn’t let you skip it.
Experience compounds here. The hard part was never typing code. It was knowing what mattered, what could go wrong, and where to be careful.
Where things actually go wrong
What I’m seeing in teams is not about seniority. It is about mode selection.
- Overuse without discipline: the AI does good local work, but the developer stops leading the system. Scope, constraints, and checks aren’t made explicit.
- Underuse out of principle: treating failure as proof it has no place in serious work. We wouldn’t judge a human collaborator this way.
- Confusion about responsibility: oscillating between over-trust and total dismissal, because no one has a clear model for what humans must still own.
Where the real cost shows up
Idea → What/Why (spec) → Draft (AI or human) → Validate (tests/checks) → Review (PR) → Merge
The engineering pipeline doesn’t change. AI just compresses the Draft step, which increases pressure on Spec and Validation.
AI makes exploration cheap and parallel. It does not remove responsibility. If you don’t do the normal engineering work, what’s changing, why, what might break, how you’ll know, and how you’ll roll it out, the cost shows up later.
In my experience so far, this is not showing up first as dramatic bugs. It shows up as larger diffs, slower reviews, fuzzier intent, and a gradual erosion of trust. That is where guardrails become necessary.
The guardrails I rely on
These are not rules. They are pressure points I use to keep myself honest.
Think of them as speed bumps: not to slow progress, but to stop momentum turning into accidental scope.
AI can explore options, but it cannot decide. It can propose and draft, but it cannot silently redefine scope or intent. If something changes behaviour, widens scope, or alters assumptions, I want that called out explicitly.
Diff size is the first smell. Large diffs collapse multiple decisions into a single review moment. If something small turned into something big, I stop and ask why before I ask whether it is “correct”.
AI output never replaces quality checks. Tests, edge cases, and system impact do not become optional because the code looks good. If anything, faster drafting makes automated checks more important, because you can produce a lot more change before your intuition catches up.
Friction marks decisions. Switching models, changing behaviour (not just refactoring), touching multiple concerns, or widening scope should feel noticeable. If everything feels easy, something important is probably being skipped.
One thing I am watching (and may try next) is lightweight “guardrails for agents” kept close to the code, such as a simple repo file (agent.md, .cursorrules, or similar) that captures conventions and “Definition of Done” expectations. I am cautious here: heavy process is easy to ignore. If it works, it will be because it is short, specific, and enforced by review and tooling, not because it exists as policy.
How I work right now
Sometimes I code by hand because I want to think. Sometimes I delegate aggressively because I want to think and create in parallel.
Doing this well in a team needs a bit of humour. AI will occasionally do something brilliant, and occasionally do something confidently bizarre. I would rather we can say “that was the model” without embarrassment than pretend none of this is happening. The goal is not secrecy, it is shared habits.
Working with agentic AI looks similar to how I work as a lead developer: I hand off scoped work, review what comes back, and step in to keep the delivery connected, so intent does not get lost as things move faster.
With developers, moments of uncertainty become conversations. With AI, when output isn’t right, I treat it as a local optimisation problem, not a teaching moment.
I am not trying to replace engineers. I am trying to make sure their attention is spent where it pays off most.
What I’m watching next: The systems thinking gap
This model works best for people who already know how to keep a system coherent: what matters, what can break, what to validate, and what to roll back. My biggest question is how a new generation learns that judgement when the act of drafting has become near-instant.
You always had to care what happens after shipping. The difference is you now hit that part much sooner, because code is cheap.
Systems thinking is the habit of asking “what else does this touch?”, other services, data, users, operational load, and failure modes.
Part of that is learning the end-to-end lifecycle of a change. For example: Requirements → Design → Tests → Rollout → Ops
Agentic AI doesn’t remove responsibility; it concentrates it.
The teams that win won’t just be the ones with the best tools. They’ll be the ones that realise delegation is a senior skill and start teaching it deliberately.
Comments