Inside the Cyann Framework: AI-Assisted Architecture and Engineering

Most firms that claim to have an AI methodology can explain what their AI does. Far fewer can explain where the AI stops, where engineering judgment takes over, and how that relationship is managed throughout the delivery process. That distinction matters because AI-assisted engineering is not simply about using AI to write more code, generate more tests or produce documentation faster. It is about changing how engineering work gets done while retaining the architecture, context and human judgment that make the outcome reliable.

That is the thinking behind the Cyann Framework.

The Framework makes the relationship between AI and engineering expertise explicit and repeatable across the delivery lifecycle. Rather than treating AI as a tool that engineers use whenever it seems useful, it establishes where AI can create leverage, where engineers need to apply their expertise, and how governance should operate across both.

Architecture before AI

The Framework starts with architecture, not code.

Before AI generates a single change, the system it is working within needs to be understood. That means mapping services, dependencies, data flows, existing constraints and the decisions that have already shaped the system. This context is critical because AI can produce something that looks completely correct in isolation while creating a problem somewhere else in the environment.

A function can pass every local test and still be wrong for the system it is entering. A change can solve the immediate requirement while creating an unexpected dependency or introducing complexity that becomes expensive to maintain later. These are not necessarily failures of the AI itself. They are often failures of context.

This is why architecture sits at the beginning of the Framework. Before asking AI to build, engineers need to establish the environment in which that building needs to happen. Once that context exists, AI can work within it more effectively, while engineers retain responsibility for understanding the wider implications of what is being produced.

Where AI accelerates and engineers decide

From that foundation, the Framework applies the same principle across five stages of delivery: requirements, code generation, testing, review and documentation.

At each stage, AI takes on work where it can provide meaningful acceleration, particularly where that work is repetitive, time-consuming or benefits from being explored at scale. Engineers, meanwhile, remain responsible for the decisions that require context, experience and judgment.

This does not mean drawing an arbitrary line between what AI can and cannot do. The boundary changes as the technology develops. Instead, the Framework is designed around a more important principle: AI should increase the capacity of engineering teams without transferring responsibility for engineering decisions to a system that does not own the context.

That distinction becomes clearer when you look at how the Framework operates at each stage.

Requirements and architecture

At the requirements and architecture stage, AI can help engineers explore possible approaches, identify trade-offs and surface questions that might otherwise take considerable time to work through manually. It can provide multiple options based on the constraints and information available, giving the engineer a broader view of the problem before a decision is made.

The decision itself remains with the engineer.

They need to evaluate those options against the business requirement, the existing architecture, the client's operating environment and the direction the system needs to take over time. AI can make the exploration of a problem faster and more comprehensive, but it does not own the context required to determine which option is right.

The value is therefore not simply that AI produces an answer faster. It is that engineers can spend more of their time evaluating meaningful options and applying their expertise to the decision.

Code generation

Code generation is perhaps the most visible application of AI-assisted engineering, and it is also where the distinction between local correctness and system-level correctness becomes particularly important.

AI can generate implementation approaches and produce working code at a speed that would be difficult to match manually. But the question cannot simply be whether the code works. The more important question is whether it works within the system it is entering.

A generated change still needs to be considered against existing dependencies, architectural patterns, security requirements, performance considerations and the broader behaviour of the system. A piece of code can be technically correct and still be the wrong implementation for the environment.

The Framework therefore treats generated code as an acceleration of implementation, not an automation of engineering responsibility. AI can produce the change, but an engineer needs to understand what that change means in context before it becomes part of the system.

Testing and validation

The same principle applies to testing.

AI can generate large numbers of test cases and explore edge cases that an engineer might not immediately consider. It can also reduce the time involved in creating the initial test suite, allowing teams to explore a wider range of possible failure scenarios.

But more tests do not necessarily mean better validation. The engineer still needs to determine which scenarios represent meaningful risk based on the system, the business requirement and the consequences of failure.

This changes the nature of the work rather than removing it. Instead of spending all their time manually generating possible tests, engineers can use AI to broaden the field of possibilities and then apply their expertise to determine where the real risks lie.

Code review

Code review provides another example of where the division between AI capability and engineering judgment matters.

AI can scan changes consistently for patterns, potential issues, inconsistencies and areas that deserve further attention. This creates an opportunity to make review more efficient while also reducing the likelihood that a mechanical issue is overlooked simply because of the volume of code being reviewed.

However, identifying a potential issue is not the same as determining whether it represents a genuine risk. That still requires someone who understands the purpose of the change and the context in which it operates.

The result is a review process in which AI can perform more of the scanning and engineers can focus their attention on the issues that require actual judgment. Rather than reducing human oversight, the aim is to make that oversight more focused and valuable.

Documentation

Documentation follows the same pattern.

AI can use the code, requirements and decisions made during delivery to produce a first draft of the documentation, reducing another area of work that can easily become a bottleneck for engineering teams.

But generated documentation is only useful if it accurately reflects what has actually been built. An engineer who understands the system still needs to validate the output, ensure that important decisions have been captured correctly and confirm that the documentation will make sense to the people who need to use it later.

Again, AI accelerates the work without becoming the final authority on the outcome.

Governance underneath, not after

Running underneath these stages is a governance layer that is designed to operate continuously rather than being added once the development work is complete.

As AI becomes capable of making increasingly complex changes, the controls around those changes become increasingly important. Validation checks, permission controls, dependency analysis and other safeguards need to operate as part of the delivery process so that potential risks can be identified while work is happening, rather than discovered after a change has already made its way into production.

This is an important distinction in how we think about governance. It should not become a separate process that slows delivery down or sits at the end of the lifecycle as a final compliance check. When it is built into the way AI-assisted engineering works, governance can provide the context and controls that allow teams to move faster without losing visibility or control.

The objective is not to put governance around AI after the fact. It is to build governance into the way AI is used from the beginning.

The Framework in practice: Microsoft Fabric

We are applying this approach to Microsoft Fabric implementations, where the same principles can be seen across pipeline design, data modelling, transformation logic and the wider data estate.

AI can accelerate the development of these components, helping engineers explore approaches, generate implementation logic and work through technical problems more quickly. At the same time, engineers remain responsible for the architecture decisions and for understanding how each change interacts with the wider environment.

That wider context is particularly important in data environments, where a seemingly isolated change can have consequences across pipelines, models, dependencies and downstream processes. The Framework therefore keeps architectural understanding and governance present throughout the build rather than treating them as separate activities.

The objective is not simply to build faster. It is to increase the amount of engineering work AI can accelerate without increasing the amount of risk the organisation carries.

That is ultimately what makes the difference between using AI as a productivity tool and building a genuinely AI-assisted engineering practice.

What this means for engineering

AI-assisted engineering does not make engineering expertise less important. In many ways, it makes that expertise more important because the ability to generate a solution is becoming less of a constraint.

As AI takes on more of the work involved in generating code, tests, documentation and possible solutions, engineers can spend more of their time on the areas where experience and context matter most: understanding the system, evaluating trade-offs, making architectural decisions, managing risk and determining whether an output is appropriate for the environment in which it will operate.

That is a meaningful shift in how engineering work gets done.

It is also why we believe AI-assisted engineering needs to be approached as a framework rather than simply a collection of tools. Tools will continue to change. Models will become more capable. New platforms will emerge. The underlying question remains the same: how do you structure the relationship between AI capability and human expertise so that both can contribute where they are most effective?

The question to ask your AI engineering partner

Any technology firm can tell you which AI tools it uses. Increasingly, that information tells you very little.

The tools will change, and the models will continue to evolve. What matters more is whether an organisation has thought carefully about how AI fits into the engineering process itself.

Where does AI contribute? Where does human judgment take over? How is architectural context maintained? How are generated changes validated? How is risk managed? And what happens when the AI gets something wrong?

Those questions reveal far more about an organisation's approach to AI-assisted engineering than its technology stack ever will.

So when evaluating an AI engineering partner, don't just ask "What AI do you use?"

Ask them to walk you through their framework.

Because the tool stack will change.

The framework is the thing that has to hold.