The prevailing advice for engineering leaders in 2026 is simple. Buy your developers AI coding assistants, measure the adoption rate, and wait for productivity to follow. It is clean, it is easy to budget, and it is mostly wrong. New research from INSEAD and Harvard Business School puts a number on why.
In a 2026 working paper titled "AI-Native Firms", the authors study startups built around AI and find that they are organized differently from their peers. Relative to non-AI startups in the same industry and cohort, AI-native firms are roughly 25% smaller, carry about half a seniority level less hierarchy, and devote a larger share of their workforce to engineering. They reach comparable valuations with fewer people, which means each employee creates more value. These are not lower-quality entrants getting by with less. They are a different kind of company, and the finding that matters most for technology leaders is not the headcount difference but the explanation behind it.
The authors separate two ways a firm can use AI. The first is the process channel, where workers use AI tools to do their existing jobs faster. The second is the product channel, where AI capability is embedded directly into what the firm sells, so the product itself performs work that once required a team of people.
When the researchers measured the process channel by checking whether firms named specific tools such as ChatGPT, GitHub Copilot, or Cursor in their job postings, they found something that should give every CTO pause. That measure did not predict smaller, flatter firms. Handing workers AI tools, by itself, did not change the shape of the organization. What predicted the difference was the product channel. Firms that embedded AI into their products operated with meaningfully fewer people and flatter structures, even after controlling for internal tool use.
This aligns with a related finding the authors cite, often called the mapping problem. The binding constraint on AI value is not access to the technology but rather the discipline to understand your own processes and products first, then re-engineer them so AI does the work directly. Access is the easy part. Mapping is the hard part, and it is where the value lives.
Forte Group built its AI strategy around three pillars: AI features and products, AI in software delivery, and AI in operational workflows. The research validates the logic behind that structure.
Two of those pillars, products and operational workflows, are the product channel in practice. They move capability into what a company sells and into how it runs, rather than leaving it as a convenience layer for individual workers. The third pillar, AI in software delivery, is the process channel done correctly, which means re-engineering the delivery process around AI rather than scattering tools across a workflow that was never designed to receive them. The research is clear that the second approach is the one that pays.
The strategy was not derived from this paper - it reflects a three-year trajectory and investment in a strategy that yields business results. The paper describes, with a large dataset, what Forte Group’s disciplined practitioners were already learning in production.
Xceptor builds a data automation platform that financial institutions use across the trade lifecycle, running on more than 170 SaaS instances for enterprise clients. Its engineering team is small, fewer than 40 people. Working with Forte Group, Xceptor moved from ad-hoc AI tool adoption to a fully embedded AI delivery model in under twelve months. The full case study is worth reading in detail, but the arc is exactly the one the research predicts.
Xceptor began where most firms begin. The team rolled out GitHub Copilot and experimented with Claude. Individual developers wrote code faster. Team-level delivery metrics did not move. Over six months the team logged more than eighteen thousand AI events with no connection to outcomes, and could not answer whether AI was making them better or merely busier. That is the null process-channel result from the paper, observed inside a single company. Tools alone did not change the firm.
The change came from re-engineering the work. Forte and Xceptor rebuilt the product delivery lifecycle in three stages, from augmenting individuals, to embedding AI in the process itself, to AI agents executing pipeline stages with human approval at every gate. The results moved because the process moved. Two connectors estimated at two weeks were delivered in two days, an 83% reduction. A new configuration builder delivered its first use case in six days against a 26-day estimate. Rework fell from roughly 30% to under 10%.
The product and operational pillars showed up next. Forte built agent products that run on the Xceptor platform and are architected as Xceptor intellectual property, including an extraction agent that turns unstructured settlement documents into structured, audited data, and an operations agent that monitors every instance and cuts exception triage from days to hours. Capability that would have required larger teams now lives in the product and in the operating model.
None of this is automatic, and candor about the constraints is what separates strategy from marketing. The work requires process understanding before tooling. Xceptor succeeded because it diagnosed its sequential handoffs and rework before applying AI, not because it bought better tools. Organizations that skip that step will reproduce the flat metrics, not the gains.
The methods themselves demand iteration. The Xceptor team found that breaking work into small user stories, the correct instinct for human developers, was the wrong instinct for agents, because each story forces a costly reload of context. Expect two to three iterations per process before agent output matches how a team actually works. Token consumption ran higher than planned, which is now driving a more deliberate choice of which model to run at which stage. Cost governance is a first-class design concern, not an afterthought.
The talent implication is also real. The research finds that AI-native firms employ more senior and more technical workers and fewer entry-level workers, the opposite of what task-level studies of AI might suggest. Building this way changes who you hire and how you develop early-career engineers, and that is a question leaders should confront directly rather than discover later.
Finally, a measured note on scope. The research is descriptive and cross-sectional, and the authors themselves caution against reading firm-level results as labor-market predictions. A smaller firm is not the same as a smaller industry, because lower entry costs may produce far more firms. The lesson here is about how to build a competitive company, not a forecast of aggregate employment.
The research and the Xceptor engagement point to the same conclusion. AI tools are not a strategy but an input, and on their own they do not change what a company is.
For engineering leaders, the practical guidance is direct:
The firms that win the next decade will not be the ones that bought the most licenses. They will be the ones that understood their own work well enough to rebuild it around AI, and had the discipline to measure whether it actually mattered.
Let's talk about where you are today and where you want to go - our experts are ready to help you move forward.
