I’ve noticed something a bit uncomfortable recently.

I've found myself in a situation where I, like many other devs, can build things faster than my company can decide what it or its clients want. Not because we're particularly slow, but because the software part is now so fast!

With AI tools now, spinning up APIs, wiring things together, scaffolding services it’s all quick. Like, really quick. Stuff that used to take days is now hours, sometimes minutes.

But everything around that? Still slow.

Conversations. Requirements. Sign-off. Priorities. Back-and-forth. Clarifications.

It feels like development isn’t the bottleneck anymore, everything else is.

Planning takes longer than building

This is the weird bit.

You can spend a few days planning a sprint, refining stories, going back and forth on requirements…

And then a dev can go off and build most of it in a day.

That doesn’t really add up anymore.

Agile made a lot of sense when writing software was the hard part. When iteration was expensive. When you needed structure to manage limited dev time.

Now the constraint has shifted, but the process hasn’t.

It’s not that Agile is “dead”

I don’t think Agile suddenly becomes useless.

But I do think parts of it are starting to feel… out of sync.

We’re still treating development as the expensive, slow part of the system. But it’s not, not in the same way anymore.

The expensive part now is getting everyone aligned on what we’re actually trying to do.

Where this gets a bit sketchy

The thing I’m slightly worried about is how AI starts getting layered into all of this.

You can very easily end up with something like:

• A client uses AI to write what they want

• Sales uses AI to summarise it

• Product uses AI to turn it into requirements

• Dev uses AI to build it

At every step, something gets lost or reshaped.

No one’s doing anything wrong, but the original intent just drifts.

You end up building something that technically matches the requirement… but isn’t really what anyone meant.

The job is changing a bit

I don’t think developers are going anywhere.

But the job definitely feels different.

Less time writing boilerplate and glue code.
More time trying to properly understand what’s needed in the first place.

If anything, it feels like the value is shifting toward:

• asking better questions

• spotting gaps in requirements

• understanding trade-offs

• knowing when something doesn’t quite make sense

The actual coding part is becoming the easy bit.

The real problem now

If developers can move 10x faster, the rest of the business kind of has to keep up.

Otherwise you just build the wrong thing… very efficiently.

It feels like we’ve sped up one part of the system massively, but left everything else as-is.

And now that mismatch is starting to show.

Not sure what the answer is yet

I don’t think the solution is just “remove process” or “let AI handle it”.

If anything, it probably means we need better ways of keeping things aligned, not fewer.

Clearer requirements. Better feedback loops. Less interpretation between steps.

Because right now, there are a lot of opportunities for things to drift without anyone really noticing.

This is something I’ve been thinking about a lot recently.

I’ve actually been building a small Jira app called DRIFT to try and tackle a tiny part of this — mainly around keeping requirements and implementation aligned as things move through the pipeline.

It’s early, and it definitely doesn’t solve everything, but it’s been interesting seeing where things break down in practice.

I’ll write more about that soon.

I can ship software faster than ever.

Agents can scaffold entire services, generate APIs, wire up integrations, and produce working code in minutes. Iteration is cheap. Regeneration is trivial. The bottleneck has clearly moved.

And that is exactly why understanding business requirements has never mattered more.

Speed has not removed the need for clarity. It has exposed the cost of not having it.

When Iteration Is Cheap, Ambiguity Becomes Dangerous

Earlier in my career, vague requirements slowed everything down.

Unclear acceptance criteria meant long conversations, back-and-forth with stakeholders, and repeated rework. You would hit friction quickly. Something would feel wrong. Progress would stall until someone clarified what the system was actually supposed to do.

That friction was annoying, but it served a purpose. It forced understanding.

AI removes much of that friction.

Now, I can prompt past uncertainty, ship something plausible, and tell myself I will iterate later. The system compiles. The tests are green. Something exists.

That is the trap.

When iteration is cheap, ambiguity no longer blocks progress. It silently compounds.

Agents Do Not Fix Ambiguity. They Amplify It.

Agents do not understand the business in the way humans do.

They do not know which rules are critical, which edge cases matter, or which failures are unacceptable. They optimise for success signals. If success is not clearly defined, they will choose a reasonable interpretation and move on.

I have seen this first-hand.

The code looks clean. The architecture is respectable. Everything passes. And yet, the behaviour is subtly wrong in ways that only show up when someone asks, “Is this actually what we wanted?”

From the agent’s perspective, it succeeded.

From the business’s perspective, it did not.

This is not an AI problem. It is a requirements problem.

The Real Bottleneck Has Moved

As agents take on more of the implementation work, the bottleneck in software delivery is no longer code.

It is understanding.

When writing code was slow, misunderstandings revealed themselves early. You would get stuck. The design would feel off. You would naturally slow down and ask questions.

Agents remove that feedback loop.

They will happily build on top of ambiguity. They will fill gaps with assumptions. They will keep going until something compiles and passes whatever checks exist. By the time a misunderstanding surfaces, it is no longer a small correction. It is embedded behaviour spread across generated code.

I have had moments where undoing the mistake took longer than building the feature would have taken in the first place.

That is the shift developers need to recognise.

The hard part is no longer turning requirements into code. The hard part is making sure the requirements are precise enough that the code cannot be confidently wrong.

Why “Just Get Something Out There” Is Riskier Than Ever

I used to be fairly relaxed about “getting something out there.”

In a pre-AI world, that usually meant a bit of mess, some technical debt, but broadly correct behaviour. You could clean it up later.

In an agent-driven world, “we will iterate later” often means incorrect behaviour that looks correct.

Agents are extremely good at producing systems that appear reasonable. Without clear constraints, assumptions harden quickly. Those assumptions get copied, reused, and reinforced across generated code. By the time the mistake is noticed, it is no longer isolated.

Velocity hides the error until undoing it is expensive.

Speed without clarity is not agility. It is chaos with better tooling.

Where Tests Actually Fit Now

This is where my thinking on testing has changed the most.

Tests are no longer primarily about catching regressions or validating syntax. Their most important role is to express business intent in a way a machine can verify.

When I am working with agents, a test answers a very direct question.

Did you do what I meant?

If the test does not make that clear, the agent will still pass it. It just might pass it for the wrong reasons.

Behaviour Over Implementation

When agents write most of the code, I care far less about implementation details than I used to.

What matters are the things that must never be violated. Business truths. Architectural constraints.

Things like:

• A frozen account must never initiate payments

• Daily limits must be enforced across concurrent requests

• Idempotent operations must not create duplicates

• Domain logic must not depend on infrastructure

These are not preferences. They are rules.

If I do not make them explicit, the agent will not magically infer them.

The Skill That Matters Most Now

As implementation becomes cheap, misunderstanding becomes the most expensive mistake a team can make. The developers who thrive in this world will not be the ones who generate the most code. They will be the ones who invest the most effort in getting the requirements right before anything is generated.

If an agent cannot tell whether it is finished, that is not an AI failure.

It is a failure to define success.

And the embarrassing part?
I got absolutely blindsided by code I wrote. (”wrote” might be generous.)

The Week I Took AI a Bit Too Literally

We recently updated our process, and without even noticing it, I had drifted into the habit of letting the AI handle more than it should. The output looked great: clean code, passing tests, tidy diffs. My brain basically shrugged and said, “Looks fine, let’s get on with the next thing.”

Spoiler: it wasn’t fine.

Everything behaved perfectly locally.
Then I deployed it to the cloud and walked straight into a wall of chaos.

Managed identity acting up.
Connectivity was doing as it pleased.
Authentication randomly failing.
All the usual cloud quirks that somehow hide until the moment you tell someone the work is finished.

Suddenly, I was hunting down “bugs” that weren’t actually bugs.
The real problem was that I had no mental map of what the system was supposed to do, because I hadn’t really built it the way you normally do through repetition, frustration, and slowly wiring the whole thing into your brain.

It genuinely felt like trying to debug a system I’d only heard rumours about.

When You Don’t Write It, You Don’t Know It

This was the big realisation of the week.
AI generated a lot of the heavy lifting. I skimmed it, thought it looked correct, and cracked on. But because I never really went through the grind of writing it myself, I didn’t have the usual intuition you rely on when debugging.

There were moments where I was staring at a piece of code thinking, “Did I do this… or did I hallucinate reviewing it at 5 pm on a Friday?”

I spent more time reconstructing how things worked than I would’ve spent writing the code manually. And that was a wake-up call.

AI can give you clean code, but it can’t give you the internalised understanding that makes debugging efficient. Without that, you’re basically wandering through your own system like a tourist with a blurry map.

AI Isn’t Magic. It’s a Power Tool.

This week forced me to re-ground myself.

AI absolutely helps productivity, but it doesn’t remove the need for the fundamentals. You still need to understand how the system fits together. You still need to think about the environment you’re deploying into. You still need to consider failure modes, configuration differences, and behaviour outside of happy-path tests.

Cloud issues don’t care how tidy your code looks; they care whether it’s built to behave correctly in a messy world.

A chainsaw is brilliant when used properly. It’s less brilliant when you’re half paying attention.

The Quiet Fear That Sneaks In

If I’m totally honest, I think part of why I leaned on the AI too much is because of that little voice developers have been hearing lately:

“This thing writes code way faster than I can… where does that leave me?”

But the moment you hit a real-world problem involving identity, connectivity, latency, environment differences, or system design, you’re reminded very quickly that raw code is only a small part of what engineering actually is.

AI can generate code.
Engineers design systems, spot subtle issues, understand how components behave together, and know where failures hide.

They aren’t remotely the same skill.

And that difference is exactly why we still matter.

The Reset Button

So I’ve taken a breath and reset this week.
Back to using AI as a tool, not an autopilot.

It’s there to support my thinking, not replace it.
It helps me move faster, but it doesn’t free me from needing to understand what I’m building.
It can generate solutions, but it can’t be accountable for them.

This reminded me that the real value in engineering isn’t typing speed.
It’s the thinking, the planning, the understanding, and the ability to navigate the unpredictable parts of the real world.

AI handles the easy stuff.
We handle the stuff that actually matters.

And honestly, that’s a comforting thought.

“Some teams are seeing massive productivity gains from AI agents. Others… not so much.

The best teams don’t treat agents like magic coworkers. They treat them like part of the engineering system.”

Couldn’t agree more.
That line sums up exactly what I’ve experienced using AI Coding Agents over the last few months.

A lot of people expect an AI agent to “make them faster.”
They drop it into their workflow, start prompting, and then wonder why it’s not a 10x upgrade.

The thing is, agents don’t improve your process by themselves.
They amplify whatever process already exists.

If your workflow is messy, inconsistent, and full of context switching, your agent will simply move faster through the chaos.

Designing the System Around the Agent

Where it clicked for me was when I stopped treating Warp (My AI coding partner of choice) like a chat assistant and started treating it like part of my engineering system.

Instead of typing ad-hoc prompts, I started building a library of reusable, structured prompts, each one mapped to a real engineering task — things like:

• 🔍 Fix SonarCloud Issues

• 🧾 Prepare Pull Request Summary

• 💬 Review Code Against Jira Ticket

• 🧠 Implement Feature Based on Requirements

• 🧪 Write or Improve Unit Tests

Each prompt ties into a set of MCPs (Model Context Protocols) that give the agent the tools it needs —
Jira, Azure DevOps, SonarCloud, Context7, Microsoft Learn, plus a few of my own internal ones.

That combination turned Warp from “an assistant that helps me write code” into a co-pilot that runs my development workflow.

The Feedback Loop

The best part? Every time I notice the agent repeating a manual step or misunderstanding a pattern,
I don’t “fix the prompt”, I improve the system.

Maybe that means refining the MCP schema, updating how it fetches context, or adding a new reusable prompt for that scenario.

It’s like building CI/CD pipelines; the more you invest in the process, the more leverage you create.
That’s when the compounding starts.

The Role Shift

I’ve found myself spending less time writing code directly and more time engineering the system the agent operates within.
That’s a very different mindset, but it’s also incredibly freeing.

Instead of juggling Jira, IDEs, docs, and test pipelines, I focus on shaping the structure, rules, and tools that let my agent execute all of that seamlessly.

It hasn’t made me redundant.
It’s made me more strategic.

The Takeaway

The teams that are flying with AI agents aren’t just good at prompting; they’ve learned to design for them.

They think about:

• What infrastructure supports the agent

• What tools can it access

• How does it get feedback

• How it fits into the team’s engineering rhythm

The real difference isn’t in the model.
It’s in the system it’s part of.

#AI #SoftwareEngineering #AIagents #WarpAI #MCP #DeveloperTools #FutureOfCoding #AgenticCoding

What used to take me a few hours of context switching and manual debugging was done in less than an hour, and I didn’t even open an IDE.

Six months ago, I’d have done the usual dance: copy something from ChatGPT, paste it into my IDE, fix the import errors, adjust for project conventions, run the tests manually, debug the failures, rinse and repeat.

This time, I just described the problem.
- The agent read through the codebase
- Investigated the issue
- Showed me what it found
- Proposed a fix
- And wrote the tests to prove it worked

It traced through 20+ files, created a failing test to reproduce the bug, fixed it properly (with clean error handling), added four edge-case tests, and even optimised the logic for performance.

Then it:
- Created a Jira ticket
- Generated commits with detailed messages
- Cherry-picked to a hotfix branch
- Tagged the release

All while I just guided the direction and reviewed what it was doing.

The thing that surprised me most wasn’t the speed; it was the confidence I felt as I watched it work. Not blind trust, but confidence that came from seeing its reasoning step-by-step, watching it apply proper red–green–refactor, checking that all the tests passed, and realising it even followed our git workflow.

It still feels like cheating somehow, but the best kind. The kind that makes engineering fun again. I found myself thinking more strategically instead of mechanically typing.

The skill now isn’t about writing every line yourself; it’s about asking the right questions, evaluating the reasoning, understanding the architectural implications, and knowing when to step in.

This isn’t the future of software engineering. This is already happening.
And it’s only getting better from here.