The case for staying independent

Stormhill does not resell platforms. We do not carry vendor quotas, earn referral fees, or steer clients toward a preferred technology stack because it appears on a partner tier list. That is not a marketing posture, it is an operating constraint that shapes every recommendation we make.

It matters now more than it did two years ago. AI capability is commoditising rapidly. Foundation models, development assistants, agent frameworks, document intelligence pipelines, and workflow automation platforms are converging in capability while diverging in packaging, pricing, and the workflows they actually suit. The market is full of credible options, and full of organisations being sold a single-vendor answer to problems that were never single-vendor problems.

This note sets out why independence is a practical advantage, not an ideological one: how development teams should be encouraged to find tools that fit how they work; why guardrails belong in repository and delivery standards, not in mandated product choices; and why the efficiency revolution visible in software development is a preview of what is available across almost every function in an organisation, including ad hoc work that has never been considered automatable.

Commoditisation changes the question

In 2023, the advisory question was often "should we adopt AI?" and "which model is best?" In 2026, the question is narrower and harder: "where does this specific tool create leverage in ourworkflow, and what do we standardise versus what do we leave to team judgement?"

The capability floor has risen dramatically. Tasks that required bespoke model training or specialist ML engineering eighteen months ago are now addressable with well-configured off-the-shelf tools. Vendor offerings overlap: the same provider may sell you a coding assistant, a contact centre bot, a document extraction service, and an enterprise search layer, each adequate, none universally optimal.

Commoditisation does not mean all tools are interchangeable. It means the differentiation has shifted from access to capability to fit with how your people actually work. That shift favours organisations, and advisors, willing to evaluate honestly rather than consolidate prematurely.

Why one vendor rarely fits all

Enterprise technology has a recurring pattern: a platform vendor achieves momentum, and procurement responds by consolidating around it, not because every module is best-in-class, but because single-vendor deals simplify contracting, security review, and executive narrative.

AI amplifies this tendency. A vendor with a strong foundation model partnership can plausibly offer an end-to-end story: develop with our assistant, deploy with our agents, serve customers with our contact platform, govern with our observability layer. The story is coherent. It is also frequently wrong for organisations whose work is heterogeneous.

We observe consistent mismatches in the field:

• A coding assistant optimised for greenfield web development underperforms on legacy mainframe-adjacent codebases where context windows and retrieval need different architecture, yet it is deployed because it ships with the enterprise productivity suite.
• A contact centre AI platform strong on scripted deflection struggles with resolution-centred service models requiring deep customer data integration, yet it is selected because it shares a vendor relationship with the CRM.
• A document intelligence tool excellent on structured forms fails on the idiosyncratic, handwritten, or multi-format correspondence typical of regulatory and legal workflows, yet it is rolled out organisation-wide because a single procurement gate exists.

None of these are failures of the tools in their intended context. They are failures of one-size-fits-all deployment, and of advisory relationships where the recommender benefits from the recommendation.

Plural tools, unified guardrails

For small and mid-sized development houses, and for internal engineering teams within larger organisations, we advocate a model we describe as plural tools, unified guardrails.

Plural tools means development teams are encouraged, and expected, to explore and adopt AI-assisted development tools that suit how they work: their language mix, their review culture, their test discipline, their appetite for agentic automation versus inline suggestion. One team may gain most from an agentic IDE workflow; another from a lightweight completion assistant integrated into a terminal-centric practice; a third from retrieval-grounded code search with minimal generation. That is acceptable. It is, we argue, optimal.

Unified guardrails means what enters the codebase and what reaches production remains standardised regardless of which assistant produced the first draft:

• Repository management. Branching conventions, pull request requirements, mandatory review, signed commits, and dependency policies enforced at the platform level, not negotiated per team.
• CI/CD and quality gates. Automated test, lint, security scan, and licence compliance pipelines that no tool output bypasses. AI-generated code is treated as untrusted input until it passes the same gates as human-written code.
• Observability and provenance. Logging of which tools were used in generation (where technically feasible), retention of review records, and clear ownership assignment on merge, so accountability remains human even when drafting was assisted.
• Secrets and data boundaries. Tool configurations that prevent training data leakage, restrict context to approved repositories, and enforce data residency requirements, regardless of vendor.
• Architecture standards. Shared patterns for API design, error handling, authentication, and logging that agents and assistants are instructed to follow, typically via organisation-maintained rules files and retrieval corpora, not vendor defaults.

The objective is not homogenised tooling. It is homogenised trustworthiness of output. Teams move faster with tools that feel right in their hands; the organisation moves safely because what those tools produce is subject to the same controls regardless of origin.

From early benchmarks to everyday practice

The early evidence on AI development tools was encouraging but narrow. Controlled studies of code completion assistants in 2022–2023 reported developers completing defined tasks roughly 30–55% faster in laboratory settings, with suggestion acceptance rates often below 35%, meaning most generated output was rejected or heavily edited. Productivity gains in real repositories were more modest and highly variable.

Current-generation tools, agentic editors, multi-file refactoring assistants, test scaffolds, and retrieval-grounded code agents, operate in a different regime. Teams in our observation set report:

The headline is not a universal multiplier. It is selective compression of low-value, high-volume activity, the work experienced developers describe as necessary but unrewarding: repetitive implementation, context-switching to recall how an internal API works, writing the fifth variation of the same integration test, updating README sections that drifted from the code months ago.

When teams are allowed to choose tools that match their workflow, we consistently see larger gains than when teams are mandated a single enterprise selection, often 15–25 percentage points difference in self-reported time saved on routine tasks, holding codebase and skill level roughly constant. The tool matters less than the fit between tool, team practice, and task type.

Speed comes not from the highest benchmark score on a leaderboard. It comes from tools that feel right in the hands of a team that knows what it is building, and guardrails that let them move fast without asking permission for every line.

If it works for code, why stop at engineering?

Software development is where the efficiency shift is most visible, because the tools are mature, the output is structured, and the feedback loop (compile, test, deploy) is fast. But the underlying pattern, remove low-value repetition, preserve human judgement for high-stakes decisions, measure throughput and quality rather than activity, is not engineering-specific.

Consider teams whose work is rarely discussed in AI keynotes:

• Finance and procurement. Matching invoices to purchase orders, chasing discrepancies, preparing recurring board reports from multiple source systems, hours spent on assembly and reconciliation that precede the actual analysis.
• Operations and scheduling. Coordinating field resources, re-planning around cancellations, compiling daily status from fragmented updates, work that is partly repeatable and partly ad hoc, and rarely served well by rigid RPA.
• HR and people operations. Policy interpretation for specific employee situations, drafting correspondence, preparing onboarding packs customised to role and location, high-volume, context-sensitive, and trust-sensitive.
• Legal and compliance. First-pass review of standard contracts, mapping regulatory changes to internal policy, assembling evidence packs for audit, work where speed without accuracy is worse than no speed at all.
• Customer-facing teams. Already discussed in our field notes on contact resolution, where the opportunity is not deflection but competent handling of routine reasons and honest escalation of the rest.

In each case, the question is the same one we ask in engineering: which activities are low-value and high-volume enough to assist or automate safely, which require human judgement throughout, and which benefit from a human-AI split where the machine drafts and the person decides?

The ad hoc dimension matters. Much organisational work does not fit clean process maps. It arrives as an email that is sort of a billing question and sort of a complaint. A request that needs three systems and a phone call to resolve. A one-off board question that resembles last quarter's but is not the same. Agentic approaches, classification, disambiguation, retrieval against policy and record, draft generation, structured handoff, handle this messiness better than the automation generation that preceded them, precisely because they are designed for under-specified input rather than perfect forms.

Throughput, quality, and people, not replacement

The narrative we reject is simple and seductive: AI will do the work, and you will need fewer people. It is also, in our observation, usually wrong, or at least incomplete in a way that damages implementation.

Organisations that frame AI as headcount reduction tend to deploy cautiously where they should experiment, and recklessly where they should guard, because every automation decision becomes a political trade rather than an operational one. Teams resist. Quality suffers. Customers notice.

Organisations that frame AI as throughput and quality uplift tell a different story, and achieve different outcomes:

• Employees spend less time on work they experience as drudgery and more on work that uses their judgement, relationships, and domain expertise. Job satisfaction measures in functions where assistive tooling was introduced thoughtfully typically move before headcount discussions are even relevant.
• Quality improves when machines handle consistency-sensitive repetition and humans focus on exception handling, relationship repair, and decisions that require accountability. Error rates on routine processing tasks often fall when assisted; critical errors fall further when humans are reserved for genuine edge cases rather than exhausted by volume.
• Customers benefit from faster response, more consistent answers, and quicker access to competent humans when automation reaches its limit, provided escalation is designed honestly, as we have documented in contact centre work.
• Business throughput increases: more work processed, more enquiries resolved, more reports produced, more claims triaged, without proportional headcount growth. In growth-constrained or capacity-constrained organisations, that is often the difference between serving demand and rationing it.

Headcount may change over time as work mixes shift. That is not new, it has been true of every productivity technology. But it is a second-order effect, not a deployment objective. The first-order objective is removing low-value volume so that remaining human effort compounds.

What independence makes possible

An advisor tied to a vendor cannot easily say:

• "Use vendor A for coding assistance and vendor B for document intelligence, because they suit different teams and neither owns your delivery pipeline."
• "Do not buy the enterprise AI suite yet, the capability you need is available in tools your teams already use, and the integration risk exceeds the benefit."
• "This contact centre platform will inflate your deflection metrics and damage resolution, regardless of who sells it."
• "Your finance team's ad hoc reconciliation work is a better AI investment than another engineering copilot licence, because that is where your constraint actually lives."

Independence is not neutrality toward technology, it is alignment with the client's outcome rather than the vendor's pipeline. It allows recommendation of small, sharp tools over large, mediocre platforms; of team-level experimentation over enterprise-wide mandates; of guardrails in delivery standards over prohibition of choice.

It also allows us to say "not yet" and "not there" without a sales quarter to protect, which, in a commoditising market moving faster than most governance frameworks can follow, may be the most valuable advice of all.

A practical posture for leaders

For organisations navigating this landscape, we suggest a posture that mirrors what works in effective engineering teams:

1. Standardise outcomes and guardrails, not tools.Define what "production-ready" means; let teams find the assistants that get them there fastest.
2. Measure task-level efficiency, not licence utilisation. Adoption metrics tell you little. Time on low-value work, error rates, throughput, and quality on high-value work tell you whether anything changed.
3. Extend the lens beyond engineering. Ask each function: where is your low-value, high-volume work, including the ad hoc work that never appears on a process diagram?
4. Design for enhancement, not replacement. Communicate internally that the goal is better work, not fewer people, and mean it in how projects are scoped and success is measured.
5. Seek advice that costs the advisor nothing to give honestly. If your integrator, reseller, or platform partner cannot recommend against their own product line, you do not have independent advice. You have a sales motion with a consulting wrapper.

Closing view

AI is becoming infrastructure: widely available, rapidly improving, unevenly useful. The competitive advantage is not early access, it is thoughtful placement: the right assistance in the right workflow, with the right guardrails, chosen by people who understand the work rather than mandated by procurement categories.

Software development was the first domain to show what happens when low-value volume compresses and human effort redirects toward judgement, architecture, and problem-solving. That pattern is reproducible across functions, including the messy, ad hoc, trust-sensitive work that makes up most organisations and most customer experiences.

Staying independent is how we stay useful as that pattern unfolds: free to match tool to task, free to prioritise the workflow where leverage actually lives, and free to tell you when the answer is smaller, plural, and governed, not larger, unified, and sold.

This perspective reflects Stormhill's operating model and field observations across advisory and applied development engagements. Reported efficiency ranges are drawn from anonymised client and team data; individual results vary with workflow maturity, data quality, and the fit between tools and practice.