How we’re using generative AI to scale engineering judgement and turn increased capacity into greater value for customers, partners, and our team
By Evans Nimako, Chief Technology Officer, Akkadian Labs
Every significant technology shift tends to produce two reactions.
One group dismisses it. Another assumes it will solve everything.
AI deserves neither.
At Akkadian, generative AI is engineering leverage. That’s it. It works when experienced engineers direct it, when clear controls bound it, and when we measure it by what customers actually get, not by how much code it produced.
We’re already seeing it. We measure engineering work in effort points, where one point was an hour. On comparable work (the same kind of feature, the same class of problem), what used to take 8 points is landing closer to 1.2. That’s measured against what we actually shipped, and it held up when we used it as the planning conversion for the Akkadian Platform roadmap.
A number like that should invite skepticism. So let me be clear about what it doesn’t mean. It doesn’t mean we ship six times the code. We don’t want six times the code. It means the hours that used to go into producing a working implementation now go somewhere else: into the edge cases that surface during a migration window, into validation that catches a problem before a customer does, into hardening the parts of the platform that touch privileged access, into delivering capabilities to customers and partners faster.
The ratio isn’t the achievement. What we do with the difference is.
Customers & Partners: Who This Capacity Is For
None of that matters if it stays inside our development organization.
For customers, greater engineering capacity shortens the distance between an operational need and a platform capability you can trust in production. We strengthen integrations sooner. We keep pace when something changes underneath you in the collaboration and UC ecosystem. We absorb the enterprise edge cases that never fit the standard path, and we keep improving how onboarding, changes, offboarding, and migrations are automated and governed.
That should show up well beyond our engineering team. When technology is easier to integrate, govern, support, and trust, IT teams spend less time working around it. Users get served more consistently. New capabilities reach adoption instead of stalling in a queue. And organizations get more out of the collaboration investments they have already made.
For partners, the opportunity is just as real, and it runs in the other direction.
You see customer complexity firsthand. You know where migrations slow down, where implementations demand too much custom work, where manual processes introduce risk, and where service delivery ends up dependent on the two or three engineers who have done it before. A more responsive development organization gives us a way to turn those field insights into repeatable platform capability: migrations that run more consistently across your customer base, less avoidable rework, proven practices extended to broader delivery teams, and managed services you can actually scale.
Additional engineering capacity becomes capacity for the ecosystem around us.
For our team, that is both an opportunity and an obligation. More capacity also does not grant permission to build more things simply because we can. It raises the expectation: solve the right problems, make better decisions, learn faster, and turn what we learn into something durable. If the result is just more activity or more code, we have missed the point. The result has to be better outcomes.
That is what this model is built for. Here is how it works.
What We Mean by an Agentic Development Factory
We use the word factory carefully.
This is not an assembly line where people are removed and software appears without oversight. It’s a coordinated development environment where specialized AI agents support defined parts of the engineering lifecycle.
One agent interprets a requirement against our established architecture. Another explores an implementation. Others handle testing, examine edge cases, flag inconsistencies, improve documentation, or evaluate work against our engineering and security standards.
The value doesn’t come from any single agent. It comes from how the agents are designed, governed, combined, and improved.
Senior engineers curate every one of them: teammates with 10 to 15 years across software automation, systems integration, security, and the platforms we manage. Those engineers define each agent’s responsibilities: what context it receives, which tools it may use, what success looks like, where its authority stops, and when a human has to decide.
We are not asking AI to define good engineering. We’re asking experienced engineers to make good engineering repeatable.
That distinction matters more than it might sound.
Over years of building automation for complex enterprise collaboration environments, our team has accumulated specialized knowledge: how platforms behave under load, where integrations turn fragile, which exceptions actually matter, how migrations fail, where security risk hides, what makes automation survive in production.
Historically, that knowledge traveled through people: architecture reviews, mentoring, hard-won experience. Those practices remain essential. But now we can also capture it in the systems, patterns, validation, and agents that shape how we build.
That doesn’t replace our team members. It makes what they know durable and useful to more of the team than any one engineer could reach.
Earned, Scoped, Reversible
Capacity only creates durable value if it can be trusted.
Generative AI produces output that looks convincing and is wrong. It handles the common case and misses the exception that matters. It will follow an incomplete assumption with remarkable efficiency.
So our operating principle is simple: Agent autonomy should be earned, scoped, and reversible.
A narrowly defined agent operating inside a controlled process may be permitted greater independence. Work involving security, shared architecture, or critical platform behavior receives correspondingly greater human scrutiny.
The level of oversight should reflect the level of risk.
Of course, our developers must still understand what they ship. They must still challenge results that do not look right. As always, they must be able to explain, maintain, and support everything that enters the platform.
AI can contribute to an implementation. It cannot be accountable for one.
That accountability is not something we are trying to automate away. It is what allows the model to scale responsibly.
The Same Discipline We Build Into the Platform
We built the Akkadian Platform around a specific conviction:
Automation without governance creates risk. Governance without automation does not scale.
The objective is not simply to automate a task.
It is to control who or what has authority to perform it, apply policy consistently, validate the result, maintain accountability, and make the process repeatable.
That is the discipline we build into the platform.
It is also the discipline we expect from ourselves.
We should not ask customers to trust governed automation in their environments while treating AI-driven automation casually in our own engineering organization.
Scoped authority. Defined boundaries. Approval where risk requires it. Validation before trust. Lessons captured back into standard practice.
The underlying principles are remarkably similar.
If we would not accept an unverified change in a customer’s environment, we should not accept one in ours.
A technology provider helping automate complex lifecycle, identity, collaboration, and compliance-related operations should be able to explain its own control model clearly.
Once the technical positions above are confirmed, we should be able to do exactly that.
Experience That Compounds
The hardest thing to scale in any engineering organization is judgment.
An experienced engineer recognizes a fragile integration pattern on sight. They know which migration edge cases surface three months later, where security concerns hide, which architectural decision gets expensive two releases from now.
A senior engineer can now establish an approved pattern, define the questions that should be asked, name the known risks, and build validation around what the team already learned the hard way. Once captured, that experience shapes far more work than that engineer could personally touch.
This is where the real leverage is.
Each strong pattern becomes reusable. Each hard problem improves how we approach the next one. A code review reveals something worth standardizing. A defect identifies a test that should have existed. A customer issue exposes an edge case that belongs in standard validation.
Experience compounds instead of evaporating.
This learning stays intentional. Agents don’t decide on their own to expand their authority or redefine our standards. Our engineers evaluate outcomes, decide what changes, and curate improvements back into the environment. The system improves because our people learn, not instead of them.
Back to Customers and Partners
I said this capacity has to leave our development organization. Now that the model is on the table, here is what that looks like concretely.
Customers shouldn’t have to care how many agents contributed to a capability. They should see the result: stronger integrations, deeper handling of enterprise complexity, and capabilities designed to be governed and supported over time, not just to work on day one.
That matters because enterprise collaboration never exists in isolation. Identity, licensing, service management, security, compliance, and organizational policy all intersect. Solving that well takes accumulated understanding, not feature velocity, which is exactly what the model above is built to accumulate.
For partners, it shows up in specifics. A reusable capability replaces a custom workaround. Validation catches an issue weeks before it would have surfaced in a migration window. A governed workflow makes an expert process executable by a broader delivery team. A capability informed by one engagement creates value across many.
The more complexity the platform absorbs responsibly, the more your expertise goes to architecture and customer outcomes instead of repetitive administration.
The Standard Has Not Changed
We’re still learning. The technology moves fast, and no honest engineering leader claims to have every answer. We’ll refine practices, challenge assumptions, and move boundaries as our understanding matures. That’s part of the model.
But the direction is clear. The future of software development isn’t people versus agents. It’s experienced people building systems that let their judgment reach farther.
Success won’t be measured by how many agents we deploy or how much code they generate. It’ll be measured by whether our team members get more capable. Whether the platform gets more capable. Whether what we learn becomes reusable instead of temporary. And whether customers run their collaboration environments more securely and with less friction than they did before.
The technology changes how we work. The people, the platform, and what we learn together determine the value we create.
More capacity. Built on trust.
Contact us. Or jump right in and schedule a discovery call.
