{"id":4447636,"date":"2026-06-09T10:40:12","date_gmt":"2026-06-09T08:40:12","guid":{"rendered":"https:\/\/www.deptagency.com\/?post_type=article&p=4447636"},"modified":"2026-06-09T11:41:05","modified_gmt":"2026-06-09T09:41:05","slug":"ai-can-write-code-enterprise-delivery-is-harder","status":"publish","type":"article","link":"https:\/\/www.deptagency.com\/en-uki\/insight\/ai-can-write-code-enterprise-delivery-is-harder\/","title":{"rendered":"AI can write code. Enterprise delivery is harder."},"content":{"rendered":"
\n\t\n\t\t\n\t\t\t<\/mask><\/g><\/svg>\t\t\t\n\t\t\t\tInsights\t\t\t<\/span>\n\t\t<\/div>\n\t<\/div>\n\tAI can write code. Enterprise delivery is harder.<\/h1>
\n\t\t\t\n\t\n\t
\n\t\tJonathan Whiteside\t\t
\n\t\tGlobal EVP Technology\n\t\t\t<\/div>\n<\/div>\n\t
\n\t\t\t\t\t
\n\t\t\t\t\n\t\t\t\t\tDate\t\t\t\t<\/span>\n\t\t\t\t\n\t\t\t\t\tJune 9, 2026\t\t\t\t<\/span>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\n\t\n<\/div>\n\n\n\tAI has made it much easier to create software.<\/p>\n\tA product manager can describe an interface and get a prototype. A developer can scaffold a feature in minutes. A founder can turn an idea into a demo before hiring a team.

That is useful. But enterprise software is not judged by time-to-working-demo. It’s judged on whether it can be supported, extended, and run safely as a real system.

It has to meet enterprise architecture standards. Integrate into the existing ecosystem. Handle customer data properly. Meet infosec, accessibility, performance, analytics, localisation, testing, documentation, and release requirements. It has to be maintainable by the next team that touches it. And that is where vibe coding breaks down.

The problem isn\u2019t that AI writes bad code. Often, it writes code that looks surprisingly good. The problem is that \u201clooks good\u201d and \u201cproduction-ready\u201d are not the same thing.

We are past the question of whether AI can write code. It can.\u00a0
<\/strong>
The better question is whether a team can turn that capability into a delivery model that works in an enterprise environment and yields lasting value.<\/p><\/div>\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t<\/div>\n\n\t\t\t\n\t<\/div>\n\n\n\tThis isn’t really agentic engineering. It’s agentic software delivery.<\/h2>\n\tThe industry has landed on a name for this: agentic engineering. That name undersells it. ‘Engineering’ points at the code – but the code was never the hard part. The hard part is everything around it: the architecture, the integration, the security, the route to production.

So while the industry calls it agentic engineering, what actually matters is agentic software delivery. The whole process, not just the generation of code.

How we define it: a governed delivery model where specialist AI agents work across the software lifecycle, while engineers and architects direct them, review what they produce, and own the decisions that matter.”

This is a very different thing from asking a coding assistant to build a feature. It is also bigger than speed. The real value shows up when AI is not just helping someone type faster, but helping the whole team move with more clarity, more consistency, and less rework.

Recently, we conducted an A\/B test in which five architectural improvement tickets were assigned to the same foundational codebase.\u00a0<\/p>\n\n\t
  • One path was executed manually by a principal engineer.\u00a0<\/li>
  • The other used a structured agentic workflow, with human review at defined control points.<\/li><\/ul>\n\nThe traditional path was estimated at roughly 18 working days. The agentic path took eight days of setup and refinement, then projected one to two days of execution once stabilised. Including setup, that was nearly a 2x improvement. Excluding the reusable setup, the comparable execution was more than 10x faster.

    The more interesting part was where the senior engineer spent their time: less on repetitive implementation, more on shaping the system around the work. Better planning prompts, cleaner guardrails, stronger observability, sharper pull requests.
    That is the shift from AI-assisted coding to agentic engineering delivery.<\/p>\n<\/div>\n\t\n\t<\/div>\n\n\n\tThere are really two jobs here<\/h2>\n\tOne thing that gets missed in conversations like this is that agentic software delivery has two distinct kinds of work baked in.<\/p>\n\n\t
  • The first is engineering the delivery system itself. That means the reusable setup: standards, prompts, workflows, guardrails, review points, and the tooling that makes the whole thing repeatable.<\/li>
  • The second is using that system to deliver an actual feature or change.<\/li><\/ul>\n\nThe first job is the one that pays off repeatedly. Build the system once, and every feature after it ships faster and cleaner.

    If you mix these together, the conversation gets muddy fast. But once you separate them, the model makes a lot more sense.

    Instead of asking \u201chow do we ship this feature?\u201d you also ask, \u201cwhat is the system that lets us ship features like this well, again and again?\u201d That is where planning becomes the control surface.<\/p>\n<\/div>\n\t\n\t<\/div>\n\n\n\tPlanning is the control surface<\/h2>\n\tIn an agentic workflow, the most important work happens before any code is written.

    The agent should produce an implementation plan that covers the files to change, the tests to add, the architectural implications, and the approach it intends to take. That plan gets reviewed and refined before execution.

    Without planning, AI-assisted coding can become a reactive loop. You ask for something, inspect the output, correct the tool, and repeat until it finally works.

    With planning, ambiguity surfaces earlier. Misalignment is easier to catch. Review happens before implementation, not after the damage is already in the git history.<\/p><\/div>\n\t\n\t<\/div>\n\n\n\tBetter inputs create better outputs<\/h2>\n\tIf the ticket is vague, the output will be vague. If the design system is inconsistent, the component will be inconsistent.\u00a0

    That is why defining intent and expectations is critical for agentic software delivery.\u00a0

    A useful agentic workflow needs clear specifications, structured acceptance criteria, platform-specific standards, design-system discipline, machine-readable documentation, and explicit quality gates.

    The brief should not be: <\/strong>Build the checkout component.<\/em>

    It should be: <\/strong>Build the checkout component using approved design-system components. Pull copy from the CMS. Preserve existing analytics events. Follow accessibility rules for keyboard navigation and error states. Stay within the performance budget. Do not introduce new dependencies without approval. Generate tests for happy path, validation errors, and failed payment states. Flag anything that needs human review.<\/em>

    That level of instruction is how teams turn AI from a fast code generator into a reliable delivery system.
    <\/p><\/div>\n\t\n\t<\/div>\n\n\n\tQuality has to be part of the workflow<\/h2>\n\tSpeed without quality leads to rework. Quality without speed is the old delivery model (too slow for the level of change most businesses now expect).

    Agentic engineering only works when quality controls are built into the workflow.

    The goal is not to chase the theoretical maximum speed of AI. A reckless 25x improvement is not useful if it creates instability. A governed 10x improvement is far more valuable if it protects quality, maintainability, and trust.<\/p><\/div>\n\t\n\t<\/div>\n\n\n\tHumans stay accountable<\/h2>\n\tAgents can gather context, generate code, write tests, validate integrations, update documentation, and propose fixes.

    But engineers and architects still own the decisions that affect architecture, security, release readiness, and production outcomes.<\/p>\n\n\t
  • An agent can generate a migration script. It shouldn\u2019t approve the migration plan.<\/li>
  • An agent can flag a performance issue. It shouldn\u2019t change a caching strategy without review.<\/li>
  • An agent can create an A\/B test variant. It shouldn\u2019t decide the winner.<\/li><\/ul>\n<\/div>\n\t\n\t<\/div>\n\n\n\tFrom faster coding to governed delivery<\/h2>\n\tAI has changed the starting line. It is much easier now to build software.

    But enterprise technology<\/a> needs more than momentum. It needs context, constraints, verification, observability, governance, and ownership.

    Agentic engineering isn\u2019t about replacing engineers or producing more code for its own sake. It is about building a delivery system that can absorb more change without losing quality or control.
    Enterprises don’t need faster code. They need better-governed delivery, from idea to production.<\/p><\/div>\n\t\n\t<\/div>\n\n
    \n\tOn our mind<\/span><\/h2>\n\tVIEW ALL INSIGHTS<\/a>\n\t\n\t\t\n\t\t\t
    \n\t\t\t\n\t\t\t\t\t\t\t\t\"\"\n\t\t\t<\/picture>\n\t\t\t\t\t<\/div>\n\t\n\t
    \n\t\t
    \n\t\t\t
    \n\t\t\t\t<\/svg>\t\t\t<\/div>\n\n\t\t\t\n\t\t\t\tInsight\t\t\t<\/span>\n\t\t<\/div>\n\n\t\t\t\t\t
      \n\t\t\t\t\n\t