By Deepak Dastrala — CEO, Purple Fabric, Intellect Design Arena

In this article, Deepak Dastrala explores why AI-driven code generation exposes deeper architectural bottlenecks — and how enterprise knowledge engineering provides the missing link for autonomous systems.

Consider a seemingly simple instruction: make Sunday a working day.

Across a bank, what must change? Branch operations? Interest calculations? Batch schedules? Payment calendars? And does “working day” mean the whole bank, selected branches, or just a single service?

A calendar setting might be straightforward to update. But some applications could apply their own holiday logic. Interest calculations might depend on different conventions. Payment networks could continue to follow external calendars.

Before generating code, someone must establish what the instruction means and trace its consequences. That is the challenge at the heart of AI-native engineering: an instruction can be simple while its consequences are distributed across the enterprise.

Faster Coding Exposes a Deeper Constraint

A recent Forrester analysis revealed that a 30% to 40% improvement in raw coding speed yields less than a 10% gain in overall team productivity when planning, testing, and release cycles remain manual.

The reason is structural: writing code is rarely the real bottleneck in the enterprise. The real bottleneck is understanding, validating, integrating, and assuring changes across interconnected legacy systems.

Accelerating implementation leaves much of the work required to deliver a dependable change untouched. In conversations with enterprise technology leaders, five frictions recur:

1. Understanding cannot keep pace: Code arrives faster than teams can validate its underlying assumptions and dependencies.
2. Knowledge is fragmented: Business rules are scattered across code, databases, documents, and experienced colleagues — sometimes in conflicting versions.
3. Changes cross boundaries: A business instruction affects operations, risk, and technology in ways code alone cannot explain.
4. Plausible answers need verification: A convincing, syntactically correct proposal can still fail to meet real-world business intent.
5. Assurance rebuilds context: Reviewers repeatedly reconstruct system interdependencies that should have been established and preserved in earlier stages.

Every change across the technology estate pays for this fragmentation.

Enterprise Knowledge Becomes Engineering Infrastructure

We built MSOCK (the Multidimensional Multilayer System of Connected Knowledge) to address this gap.

Its foundation is a connected, machine-readable account of how an enterprise works across business, operations, risk, and technology. A unified ontology maps core concepts and dependencies, grounds insights in hard evidence, and keeps unresolved risks visible.

This isn’t basic context gathering — it is active rule governance. The system explicitly determines which policy governs, which version takes precedence, and who holds the authority to resolve conflicting logic.

The working-day example makes that distinction concrete. Finding every reference to “Sunday” would still leave the business question unanswered: what exactly should operate, and under which rules?

My view is that knowledge engineering must include the decisions needed to interpret a requirement. Without this context, we automate implementation while leaving ambiguity intact.

Get Intellect Design Arena’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Furthermore, the decisions and the knowledge around them also need maintenance. A map that was accurate before the last release may no longer reflect the system. Changes to policies, processes, and external dependencies can make it obsolete without a single code change.

Connect Knowledge, Action, and Accountability

MSOCK brings together three integrated pillars:

• SOCK (System of Connected Knowledge): Integrates code, live databases, documentation, and institutional expertise into a single, evidence-backed graph. For instance, when making a working-day change, SOCK maps which applications contain custom holiday logic, identifies applicable interest conventions, flags external payment calendars, and explicitly highlights unresolved dependencies.
• SOCI (System of Connected Intelligence): Applies this knowledge across key software lifecycle activities — building capabilities, updating existing systems, fixing live issues, and modernising legacy code. Before code changes are introduced, SOCI calculates the precise blast radius, determining what must change, what requires retesting, and what remains unaffected.
• SOCM (System of Connected Methodology): Governs delivery from requirement through release by establishing quality gates, mandatory evidence, and decision auditability. Product, architecture, engineering, quality, and release teams operate from a single source of truth, ensuring contextual continuity across handoffs.

Delivery begins with explicit business intent and governance policies. Humans define acceptance criteria and authority boundaries while resolving ambiguities surfaced by MSOCK. Automated agents execute engineering tasks within these guardrails, recording actions in real time for automated evaluation and gate sign-offs.

While connected knowledge and audit logs do not replace rigorous testing, they ensure that assurance teams can focus on evaluating complex behaviors, exceptions, and risks rather than spending time reconstructing lost system context.

Measure Where Autonomy Is Justified

In August, I proposed the Knowledge Coverage Ratio: the proportion of decisions intended for automation supported by engineered knowledge, multiplied by the proportion of that knowledge that is verifiably current.

Knowledge Coverage Ratio = (% Decisions Supported by Knowledge) X (% Verifiably Current Knowledge)

For example, 80% coverage at 90% currency yields a ratio of 72%. This metric quantifies how much of your intended automation is backed by verifiably current enterprise context. Crucially, it does not mean a change has a 72% probability of being correct. Rather, it measures how much verifiable knowledge exists to justify autonomous execution instead of human escalation.

In engineering, those decisions include which rule applies, what is affected, and what must be tested. Each decision requires all its essential knowledge dependencies. If a critical rule remains unresolved, that decision remains uncovered.

Leadership Must Redesign the Work

Transitioning to AI-native engineering requires changes to ownership and decision-making. Across the enterprise, roles must adapt accordingly:

• Leaders must decide who owns enterprise knowledge, who can authorise autonomous action, and what evidence is required before that authority expands.
• Engineers need to define intent, challenge assumptions, and design evaluations.
• Business and Risk Owners must resolve ambiguity. Reviewing every generated artefact manually hinders scale, but accepting AI output without evaluation puts reputation at risk.

The leadership mandate is to make these responsibilities explicit and ensure that learning from each change feeds back into the system to improve the next. Real success isn’t measured by vanity metrics — it must show up in delivery lead time, rework, cost, and production quality.

Before expanding AI across engineering, ask yourself:

1. Are delivery outcomes improving? Measure the journey from agreed intent to production, including rework and quality.
2. Where can agents act autonomously? Define the evidence that permits action and the conditions that require escalation.
3. How does enterprise knowledge stay current? Establish ownership and ensure each completed change updates the knowledge available for the next.

When your AI proposes a change, can your organisation explain what it affects, demonstrate why it is acceptable, and identify what it still does not know?

About the Author:

Deepak Dastrala is the CEO of Purple Fabric at Intellect Design Arena Ltd, focusing on AI-native engineering architectures and enterprise knowledge systems.

Originally published on the Intellect Design Arena Blog