When engineering leaders talk about the risks of AI adoption, the conversation usually follows a familiar path. They discuss data security, intellectual property, hallucinations, regulatory exposure, code quality, and the difficulty of governing systems that do not always produce the same answer twice. These are legitimate concerns, particularly for companies operating in industries where every decision must be explainable and every change must be traceable.
Mike Kinloch worries about all of them. As SVP of Engineering at Xceptor, a data automation company serving global financial institutions, he cannot afford not to. Xceptor’s customers operate in environments where governance is not an additional feature layered onto a product after it has been built. It is part of the product’s foundation.
Yet when Mike was asked what concerns him most about the rapid introduction of AI into software development, he did not begin with security or model performance. He talked about his team’s mental health.
He described the uncertainty created by a technology that appears to advance every few months, continually changing what people believe their roles will look like. Engineers who have spent years developing expertise are now watching AI absorb tasks that once defined their work. Managers are being asked to plan for teams whose future structure remains unclear. Even senior technology leaders are privately questioning what their own responsibilities may become.
Most people are thinking about it, Mike suggested. They are simply not talking about it.
That silence is becoming one of the most significant risks in enterprise AI adoption. Organizations are investing heavily in tools, agents, training, and experimentation while paying far less attention to the people expected to absorb the consequences. The technical implementation may be difficult, but the deeper challenge is helping an engineering organization remain confident, accountable, and effective while the nature of its work is being rewritten.
The first phase of enterprise AI adoption has been relatively easy to recognize. Companies purchase coding assistant licenses, give employees access to general-purpose models, and encourage teams to experiment. This creates useful exposure to the technology and often produces immediate gains in isolated tasks. Developers generate boilerplate faster, testers create scenarios more quickly, and product teams use AI to draft requirements or summarize research.
Xceptor began in much the same way. Employees were given tools and the freedom to explore them. The company was not initially attempting to impose a tightly controlled transformation program or require every team to adopt a prescribed workflow. At that stage, the objective was learning.
The difficulty emerged as individual experiments started producing meaningful results. Some teams began using AI extensively while others remained cautious. Engineers developed their own methods for fixing bugs, generating tests, and accelerating delivery, but the knowledge often remained within the team, or even with the individual, who had discovered it. Adoption was happening organically, yet the organization did not always have visibility into what was working or a consistent way to reproduce it.
This is a common point of failure in AI transformation. A company may have widespread activity without having an operating model. Employees are using AI, but the organization has not established how those practices should be evaluated, governed, shared, or incorporated into the way software is delivered.
That distinction matters because using AI is not the same as changing how the business works. Tool adoption can occur without meaningful transformation. A company may generate more code or complete more development tasks while preserving the same bottlenecks, handoffs, and inconsistencies that limited delivery before AI was introduced.
Xceptor’s response was not to automate the entire product development lifecycle at once. The team began by identifying specific problems where AI could create measurable value. Requirements were one example. Like many software organizations, Xceptor saw considerable variation in the quality and completeness of the artifacts produced at the beginning of the development process. When requirements were unclear, that inconsistency affected every subsequent stage, from design and implementation to testing and release.
AI offered an opportunity to improve the quality of those inputs, but the significance of the experiment extended beyond the artifact itself. Once the team demonstrated that AI could solve one clearly defined problem, it became easier to explore adjacent areas. Product leaders examined its potential in user experience. Engineering managers considered how it could support implementation. Quality teams explored automated test generation. A collection of point solutions gradually began to reveal what a more integrated AI-enabled delivery model might look like.
This progression, from experimentation to repeatable practices and eventually to a new operating model, is where many organizations struggle. They either remain indefinitely in the experimentation phase or attempt to leap directly into large-scale transformation before they have developed the knowledge required to govern it.
As AI development tools have become more capable, much of the industry has adopted activity-based measures of success. Companies cite increases in pull requests, code completion rates, development velocity, or the percentage of employees using approved AI tools. These figures are attractive because they are easy to collect and easy to communicate.
They are also frequently detached from the outcome the business is trying to achieve.
Mike’s view is that organizations should resist measuring AI merely by the volume of work it appears to produce. More pull requests do not necessarily mean better software. More generated code may introduce additional maintenance burdens, architectural inconsistencies, or defects. High adoption can indicate enthusiasm, but it does not prove that customers are receiving value any sooner.
Xceptor instead established a concrete objective: reduce the time required to build a connector to one day.
At the time, the goal sounded unrealistic. A connector could take approximately two weeks to deliver, and compressing that work into a single day required the team to reconsider much more than coding speed. Every stage of the process had to be examined, including how requirements were created, how architecture decisions were documented, how code was generated, how quality was validated, and how the resulting capability reached the customer.
This is what made the objective useful. It was ambitious enough to prevent the team from making small optimizations to an existing process and calling the result transformation. Achieving it required a different process.
It also gave the team a meaningful measure of progress. Success was not defined by how many agents had been deployed or how frequently employees interacted with an AI assistant. It was measured by the elapsed time between identifying the requirement and placing a working capability in a customer’s hands.
Once that outcome had been established, more detailed measures became relevant. The organization could examine efficiency across individual stages, the quality and consistency of the artifacts being produced, the cost of delivery, and the experience of the people working within the new process. Those metrics supported the outcome rather than replacing it.
This sounds straightforward, but it represents a considerable departure from the way many transformation initiatives are managed. Organizations often begin by selecting technology and then search for ways to demonstrate that the investment is being used. Xceptor began with an operational constraint and treated technology as one of several mechanisms for removing it.
That approach also helped the company avoid one of the more visible distractions in the current AI market: the belief that progress can be measured by the number of agents a platform or organization claims to possess. The industry has seen similar patterns before. During the rise of robotic process automation, vendors competed over the scale of their digital workforces and the number of software robots deployed. The numbers made impressive headlines, but they said relatively little about whether the underlying processes had improved.
Counting agents risks repeating the same mistake. An organization does not become more capable simply because it has automated more tasks. The more relevant question is whether those automations solve a valuable problem, operate within appropriate controls, and contribute to a better product or service.
The pressure to demonstrate speed can make governance appear to be an obstacle to AI adoption. In practice, faster software delivery makes governance more important because the organization has less time to detect and correct poor decisions before they propagate.
For Xceptor, this issue is particularly acute. Its customers expect determinism, traceability, and control, while generative AI is probabilistic by design. That tension cannot be resolved by pretending the technology is more predictable than it is. It must be addressed through the design of the system surrounding it.
Mike’s position is that human accountability remains non-negotiable. AI may produce requirements, architecture artifacts, code, tests, or release documentation, but a person must still be responsible for the result. The role of the human may change from creating every component manually to reviewing, directing, and validating the work, but responsibility cannot be assigned to the model.
This requires more than inserting a generic human-in-the-loop checkpoint at the end of the process. Organizations need visibility into how AI-generated outputs were produced, the reasoning and context that informed them, the standards against which they were evaluated, and the metrics used to determine whether the system is performing as expected. They must also control access to data and tools, secure the environment in which agents operate, and establish clear boundaries around what can be executed autonomously.
Done well, AI can support governance rather than weaken it. Human-generated artifacts vary in quality because people work differently, interpret standards inconsistently, become tired, and occasionally miss important details. Properly designed AI systems can apply the same structural expectations repeatedly, improving the consistency of requirements, documentation, and quality checks.
Consistency, however, should not be confused with correctness. AI can produce a polished and well-structured artifact that is still wrong. The organization therefore needs both the consistency introduced by automation and the judgment provided by experienced professionals.
This is one reason the future engineering organization is unlikely to be a fully autonomous software factory. In regulated and high-consequence environments, the more plausible model is a coordinated system in which AI performs a growing share of execution while people retain authority over objectives, tradeoffs, validation, and risk.
The prospect of increased automation naturally raises questions about headcount and job security. Many discussions about AI-enabled development frame the future as a choice between humans and machines: either engineers continue performing the work or AI replaces them.
That framing is too simplistic. The more consequential change is that the definition of engineering work is moving further away from implementation alone.
Mike describes a future structure organized around smaller cells containing product and builder roles. Product leaders remain responsible for determining what should be built, understanding the customer problem, and shaping the requirements. Builders operate across the development lifecycle, using AI to coordinate work that may include architecture, coding, testing, documentation, and release preparation.
In this model, the engineer’s value is not derived solely from the ability to produce code manually. It comes from understanding complex systems, framing the right problem, identifying constraints, evaluating AI-generated work, and making decisions when the available information is incomplete.
Quality assurance provides a useful example. AI can increasingly generate test cases, execute checks, analyze results, and identify patterns across large volumes of information. That does not make quality expertise redundant. It changes its application. Rather than functioning primarily as a downstream checkpoint, quality professionals can design the standards, controls, and services that allow multiple delivery cells to build quality into their work.
The same shift applies across engineering disciplines. Architects may spend less time manually producing diagrams and more time evaluating system-level consequences. Developers may write less routine code while taking greater responsibility for orchestration and technical judgment. Engineering managers may need to focus less on allocating tasks and more on creating the conditions in which people and AI can work effectively together.
These changes can make experienced people more valuable, not less. AI allows them to operate at a higher level of abstraction and address larger problems. But that possibility will not reassure teams automatically. Leaders must explain how roles are evolving, provide opportunities to develop the necessary skills, and be candid about the fact that no one has complete certainty about the final shape of the organization.
Pretending otherwise only deepens anxiety.
Mike’s willingness to tell his team that he sometimes shares their uncertainty is not a weakness in leadership. It is an acknowledgement of reality. AI is moving too quickly for any executive to promise that today’s organizational structure will remain intact. What leaders can provide is transparency about the direction of travel, clarity about the capabilities the company will continue to value, and meaningful involvement in shaping the new model.
Looking back on Xceptor’s progress, Mike identified one change he would make: involve more people earlier, particularly across the senior management and executive team.
AI initiatives frequently begin with a small number of enthusiasts because they have the curiosity and technical knowledge required to start experimenting. That is useful in the early stages, but transformation cannot remain the private project of a few specialists. The decisions eventually affect product strategy, investment priorities, workforce planning, risk, governance, and customer commitments. Senior leaders need to understand the technology’s practical capabilities and limitations before those consequences arrive.
At the same time, asking an existing engineering team to redesign its operating model alongside a full delivery roadmap is rarely realistic. Transformation work cannot be treated as an additional responsibility to be completed when normal commitments allow.
Mike’s advice is to establish a dedicated team, even if it is small. Give it a specific use case, a clear outcome, and a limited time horizon. Xceptor used six-week windows rather than attempting to map every stage of a multi-year transformation in advance. The fixed period forced the team to prioritize what mattered, demonstrate value quickly, and use the results to determine the next step.
External expertise also played a role, but not as a substitute for internal ownership. Forte Group worked alongside Xceptor’s team, bringing AI experience and additional capacity while internal stakeholders remained closely involved. The objective was not to outsource a finished solution and hand it back to the organization. It was to develop the capability together so Xceptor’s people could understand, influence, and eventually extend it.
That distinction is critical. AI transformation requires knowledge transfer in both directions. External specialists may understand the technology, but internal teams understand the product, customers, constraints, and institutional history. Neither perspective is sufficient on its own.
The easiest part of AI adoption may be proving that the technology can do something useful. A focused team can often build an impressive prototype within days. The harder work begins when that capability must be integrated into a real organization with existing responsibilities, standards, customer commitments, and human concerns.
At that point, leaders must decide what should be standardized, where experimentation should continue, how accountability will be maintained, which metrics genuinely matter, and how roles should evolve. They must move quickly without allowing urgency to become recklessness. They must encourage people to embrace new ways of working while recognizing that uncertainty is a rational response to the scale of change.
This is why AI transformation cannot be delegated entirely to an innovation team or reduced to a technology procurement decision. It is an exercise in organizational design.
The companies that make the greatest progress will not necessarily be those with the largest number of agents or the highest volume of AI-generated code. They will be the organizations that can connect experimentation to measurable outcomes, convert isolated successes into repeatable systems, and preserve human accountability as execution becomes increasingly automated.
They will also be the companies whose leaders are prepared to discuss not only what AI can do, but what rapid change is doing to their people.
The technical questions are difficult. The human questions are harder, and avoiding them will not make the transformation any easier.
83% faster delivery. Under 10% rework. See exactly how Xceptor got there.
