Strategy

Dispel’s goals align toward a sustainable, cash flow positive, high multiple company delivering best-in-class access, data streaming, and security. Dispel is not a services business, we sell software products. Engineering acts as the reactor that powers us toward our goals and we will use AI aggressively to build and ship delightful product.

AI tools are reshaping how engineering work gets done. This memo sets our position on adoption through the end of 2026: what we will invest in, what we will avoid, and what we expect our environment to look like by year end.

We build security-critical products that operate in regulated, often air-gapped environments. Our adoption of AI must be deliberate—fast enough to stay competitive, careful enough that the gains do not come at the cost of code quality, ownership, or engineers’ depth of understanding in what they ship. The sections that follow lay out the factors driving this strategy, the principles we will hold to, the actions we will take, and the state we aspire to by the end of 2026.

The models we use are available to everyone, including our competitors. Speed from AI is easy to copy. Calibrated judgement that compounds over years is not. When AI collapses the floor of software creation industry-wide, “good enough” becomes table stakes—commoditized and worth nothing as a differentiator. The only durable moat left is the ceiling: taste, the right problems chosen, and judgement good enough to tell delightful from merely functional.

Our AI strategy encompasses this dual approach:

1. Use AI aggressively to win the floor — automate execution ruthlessly so we move faster than the competition.
2. Protect our people’s judgement fiercely to own the ceiling — because that judgement is the asset our success actually rests on.

Everything below follows from this.

The major factors our strategy must address

• AI tools are materially changing how software is built. This is not a trend to watch—it is already visible in engineering team output. Reviewing, testing, refactoring, and writing code now happen with AI in the loop by default.
• The pace of change is accelerating. The tools available at the end of 2026 will be substantially more capable than those available today. Our strategy must account for that trajectory, not just the current baseline.
• Without guardrails, quality erodes. AI-generated code can be fast and wrong. Defects that are not caught automatically compound, and AI lowers the unit cost of producing new code without lowering the cost of fixing it.
• Knowledge can silo. When AI does more of the implementation work, engineers risk losing depth of understanding in what they ship. This must be actively managed, not assumed away.
• Tooling fragmentation carries overhead. Each AI tool added to the stack introduces context-switching cost, divergent workflows, and coordination drag. Fragmentation is a net negative on team velocity.
• Engineers expect AI tooling. Candidates and existing team members increasingly factor this into how they assess an employer and a codebase. Failing to invest here is a recruiting and retention risk.
• Access to AI is not a competitive moat. Everyone has access to the same foundation models. What we build with them—and how reliably—is the differentiator.

Our guiding principles to solve for those factors

• AI democratizes software development. The act of writing high-quality code has become cheap with AI. Value is derived from the craft, knowledge, and creative thinking of its users. AI democratizes the feature development process, giving teams traditionally adjacent to Engineering direct access and control over product development.
• Guardrails are our quality strategy. Invest in automated testing, linting, and static analysis ahead of problems—not as a reaction to them. The better the safety net, the faster we can move.
• Consolidate on Claude and Claude Code. This is our primary AI harness. Evaluate alternatives only when Claude demonstrably underperforms for a specific task, and weigh integration cost against the benefit. Fragmentation is a net negative on velocity.
• Do not make long term AI tooling investments. This is a period of rapid change. How the harness is used will continue to evolve. We invest in guardrails, integration, and shared skills—not in long term contracts, custom model training or fine-tuning until the landscape stabilises.
• Engineers own their output unconditionally. AI is a tool. The person who planned, directed, reviewed, and shipped the work built it. We do not attribute work to models.
• Code readability matters more in the AI era, not less. A codebase that degrades is a liability for both engineers and AI agents. Maintain quality aggressively, technical debt is now an AI performance problem as well as an ergonomics one.
• AI affects the SDLC at every stage. From idea capture and specification, through implementation and review, to deployment and monitoring. We do not treat AI as a coding-only tool.
• Knowledge sharing is team infrastructure. Reusable agent skills, documented workflows, and effective prompts should be committed, maintained, and improved like code.
• Buy the foundation model layer; do not build it. We do not invest engineering resources in model training or fine-tuning. We build differentiation through integration, application logic, and the quality of our engineering environment.

Actions to implement

• Strengthen, Integrate, Codify
  • Strengthen testing and linting toolchains for speed and simplicity. Lower friction for engineers and for AI agents running checks in a loop.
  • Strengthen code with static analysis everywhere. Every codebase has a type checker, and stricter typing is added where it is missing.
  • Integrate SonarQube via MCP so Claude can identify and resolve findings before code reaches review.
  • Integrate Gherkin-style acceptance criteria into the SDLC, co-authored by product and engineering, before the build phase begins on any new feature.
  • Codify a structured AI workflow for engineering: Learn → Research → Plan → Execute → Review—published, maintained, and expected to be the default starting point.
  • Codify a shared, version-controlled repository of agent skills for common engineering tasks, with contributions encouraged and reviewed like code.
  • Codify a 1,500-line hard limit on CLAUDE.md and equivalent agent configuration files.
• Allocate two days per sprint per engineer to technical debt reduction. Track this as a team metric, not a soft suggestion.
• Keep engineers in touch with the work. Engineers are expected to be able to explain any change they ship. Bug fixes are not routed to the original author by default—working in code someone else wrote is a normal, expected part of the job, and our tooling and code quality investments exist to make it cheap.
• Operate a single primary AI harness. Claude and Claude Code are it through end of 2026. New tools require an explicit case before they enter the stack.
• Provide AI education. Run structured opportunities—workshops, paired sessions, internal brown bags, and a curated reading list—so every engineer builds a working personal AI workflow. Practice is the curriculum; the company creates the time and venue for it.
• Provide a sandboxed development environment for long-running agents. Engineers need to run autonomous agents over hours without granting them full access to their machine. Invest in containerised, isolated, network-scoped environments—devcontainers, ephemeral worktrees, or equivalent—so that agent autonomy and host safety are not a tradeoff. These types of runs may also turn into internal agents we host somewhere other than on developer machines.

At the end of 2026 we aspire to be in the following situation

• The JavaScript-to-TypeScript migration is complete across all active repositories.
• oxlint and vitest are adopted across all active repositories; no legacy linting or test tooling remains.
• SonarQube MCP integration is live and part of the standard engineering workflow.
• No active repository has automated test coverage below a defined threshold (set by engineering leads in Q3 2026).
• Every engineer has a documented personal AI workflow that has been shared with the team.
• Any engineer can pick up a bug or small change in a part of the codebase they did not write and complete it effectively; fixes are routinely made by people other than the original author.
• The shared skills library has contributions from at least half the engineering team.
• All new feature work has Gherkin acceptance criteria signed off before the build phase begins.
• Product, Engineering and Design shoulder the responsibility for quality together. PRDs, Tickets, and Acceptance Criteria are clear, complete, and created by all for consumption by agents and engineers.
• The relevant SonarQube metrics—duplication, coverage, maintainability, reliability, and total technical debt—are, taken as a whole, moving in the right direction from where they stood in 2025.
• AI tooling spend per engineer is tracked, budgeted, and within plan.
• There should be 1+ internal agent(s) acting upon the codebase or release pipeline in a meaningful way (e.g., triaging SonarQube findings, identifying and fixing common linting errors, automating dependency updates, identifying release bottlenecks, performing QA, generating documentation) with a clear roadmap for more (under the assumption they are working well).
• Claude and Claude Code remain our single primary AI harness, or a deliberate, documented decision has been made to change that.
• Every engineer is comfortable designing, configuring, and running a long-running agent—one that executes multi-step work autonomously over hours within a sandboxed environment, not just within a single prompt cycle.
• A sandboxed agent execution environment is available to every engineer, supported and documented.
• Have a standardized AI-first design system for cweb, using our code as the source of truth.

The four sections above state our strategy. What follows is the reasoning behind each position. If you work in or with engineering, we ask you to read it—not to audit our thinking, but to understand it well enough to act without a playbook in situations we have not anticipated.

Reasoning

Why Now: The Case for a Deliberate Strategy

Every engineering team has an AI strategy. Most have not written it down. The unwritten version is: we adopt what is available, when it is available, and figure it out as we go. That is a coherent choice—but it is not a good one.

Ethan Mollick, whose work on AI in organisations is among the most practically grounded available, makes an observation worth sitting with: the tools we are using today are the least capable we will ever use. The trajectory is steep and one-directional. A strategy calibrated to the current state of AI tooling will be obsolete before most of this document’s readers have finished reading it.

The right frame is not “what can AI do today, and how do we use it?” The right frame is: “what practices and structures, if we invest in them now, will compound in value as AI capability increases?” Guardrails become more valuable as AI produces more output. Shared skills and accumulated institutional knowledge become more valuable as the tooling can take on larger and more autonomous scopes of work. Code readability becomes more valuable as AI agents need to reason about more of the codebase. These investments compound. Deferring them does not save time—it transfers cost to a later date when it is more expensive.

Staying competitive does not mean chasing every new capability as it emerges. It means building a team and a codebase that can absorb improvement without reorganising around it each time. That requires deliberate choices, made now, while we still have the space to make them on our terms.

AI-first by default

AI is the default tool for execution, not a last resort. Everyone is expected to be fluent with our approved tools and to reach for them first. If a task is repetitive, low-discovery, and well-specified, doing it by hand is a choice you should be able to justify. Velocity is a feature of how we work, not a virtue we apologize for.

Ownership and Attribution

We all own our output. Engineers own the code they produce, marketing owns their generated materials and videos, finance owns their spreadsheets, etc.

The attribution problem with AI tools is subtle. It is easy to start thinking of the AI as an actor rather than a tool. The engineer who directed Claude to build a feature, reviewed the output, and shipped it built that feature. The model was no more the author than a debugger is the author of the fix it helped locate. We do not give Git credit for version control. We do not give a compiler credit for building the binary. We do not give Claude credit for the work.

The reason this matters is not credit. It is ownership of understanding. When an engineer treats AI as a tool they are directing, they maintain the mental model of what they are building and why. When they treat it as a collaborator doing the thinking while they edit, that model degrades—and with it, the ability to reason about the system, catch errors, and make sound architectural decisions. The Yegge framework for AI adoption levels is a useful map here: the direction of travel is toward higher trust in AI output, but trust must be earned through the guardrails we build and the understanding we maintain, not assumed because the output compiles.

There is also the sycophancy problem. AI models are optimised to be helpful. In practice, this means they agree with engineers more often than an honest colleague would. A model that tells you your plan is good when it has a structural flaw is not a useful critic. Engineers who use AI as their primary source of feedback on their own work are operating without genuine critique. Human collaboration—sharing plans early, seeking real pushback from teammates—is not optional. It is a quality control mechanism that no current AI tool reliably provides.

Democratization of Development

AI is the latest move in a very old pattern: a technology absorbs the execution of a craft into a tool, and value migrates to the person who knows what to make and can judge whether it’s any good. When execution gets cheap, the scarce resource becomes knowing what to build and judging whether it’s any good. The locus of power shifts each time toward whoever holds the creative intent and away from whoever holds the execution skill.

AI is collapsing the floor of software creation—making the good-enough version available to everyone—while leaving open what happens to the ceiling. That value migrates to intent, taste, and curation—which is good news only for people who actually have those things.

This cuts both ways: engineers must truly understand how the product deploys and sustains; and who our customers are and what they need. Likewise, designers and product will be delivering specifications and functionality in code because they know the customer needs. Both bring delight.

Understanding and Cognitive Debt

Because of how they function AI tools work better on well structured, readable code.

A model asked to reason about a tangled, undocumented codebase with inconsistent naming and implicit assumptions will produce worse output than one working with clear structure and coherent abstractions. The same is true of human engineers. In the AI era, the cost of that degradation is higher, not lower, because more work now happens at the interface between engineers and AI agents. Paying off technical debt and refactoring is a good idea for compounding gains to a codebase.

This is one reason the JS-to-TS migration, and the systematic refactoring of legacy code are strategic investments rather than housekeeping. They improve the environment in which both engineers and AI agents will operate.

Cognitive debt accumulates in people as well as in code. Every time an engineer ships work they cannot fully explain, they take out a small loan against their future ability to reason about the system. The interest comes due later during an incident, a code review, or the next feature built on top. Unlike technical debt, cognitive debt is invisible to static code analysis.

Our strategy is to manage cognitive debt in two directions. Personally: you should be able to explain any change you ship: what it does, why it works, and what it touches. The Plan and Review stages of our workflow exist precisely so that understanding is built before execution and verified after it. Directing an agent is engineering; rubber-stamping one is not.

As a team: AI must widen, not narrow, the set of people who can work on any part of the system. The practical test is whether an engineer can pick up a bug in code they did not write and fix it effectively, with AI tooling closing the context gap rather than papering over it. Readable code, a culture of understanding and sharing the work you are performing, self discipline during implementation and clear acceptance criteria are what make that possible.

Guardrails as Strategy

Lawyers cannot easily verify whether a legal argument is correct without substantial domain expertise. Engineers can. We have linters, compilers, static type checkers, unit tests, integration tests, SonarQube, and CodeQL. These tools do not verify whether something makes sense—human judgement is required for that—but they verify whether it is correct, and they catch a significant fraction of the errors that AI tools introduce.

Our quality strategy for AI-assisted engineering is this: invest in automated guardrails so thoroughly that wrong or unsafe code gets caught before it can cause harm. The better the safety net, the more confidently and quickly we can move. Guardrails are not a brake on AI adoption. They are what makes fast AI adoption safe.

Specific investments:

• oxlint replaces eslint: lower latency for engineers running checks in the normal workflow and for AI agents running checks in a loop.
• vitest replaces jest, vite replaces webpack: faster test cycles reduce the cost of verification and encourage more of it.
• SonarQube MCP integration allows Claude to identify and resolve findings in the workflow, before code reaches review.
• Completing the JS-to-TS migration and adding stricter Python typing narrows the surface area for type-related errors that AI tools tend to introduce.
• Gherkin-style acceptance criteria give AI agents a precise target and give reviewers a precise standard.

Code review principles remain in place. Review effort should match the effort that went into the work. AI-assisted review is encouraged—use it to catch edge cases and verify test coverage—but it does not replace human judgement on architecture, product fit, or team conventions. Pull requests should represent a single logical change that can be reverted cleanly; size matters less than cohesion.

Platform Consolidation and the Build vs. Buy Question

Sequoia Capital’s analysis of the AI market identifies where durable competitive advantage concentrates: in the quality of integration between AI and business logic, not in AI capability itself. Foundation model access is a commodity. Everyone has it. The moat, for companies building on top of AI, is in the depth and quality of what they build with it—the workflows, the institutional knowledge encoded in agent configuration, the quality of the feedback loops.

This applies equally to an internal engineering strategy. We do not gain advantage by having access to Claude. We gain it by accumulating team knowledge about how to use it effectively, by investing in agent skills and configuration infrastructure that makes our engineering environment meaningfully better, and by making deliberate platform choices rather than fragmenting across whatever tools are popular in a given quarter.

Claude and Claude Code are our primary AI harness through the end of 2026. We consolidate here not because there are no other capable tools, but because fragmentation has costs: divergent workflows, institutional knowledge spread thin across systems, coordination overhead when different engineers are operating in different environments, and the cumulative drag of context-switching. We evaluate alternatives only when there is a specific task where Claude demonstrably underperforms, and we weigh integration cost, context management overhead, and team coordination cost against the benefit.

We do not invest engineering resources in model training, fine-tuning, or proprietary AI infrastructure. The foundation model layer commoditises rapidly. Building there at our scale produces no durable advantage. We buy the model layer and build differentiation through the quality and depth of what we do with it.

The next meaningful frontier is agentic systems: AI that sequences tasks across tools, operates with reduced per-step human oversight, and completes work within well-defined scopes. Our current investments—in shared skills, in disciplined agent configuration, in SDLC integration—position us to adopt more autonomous workflows as the tooling matures. This is deliberate positioning. The idea is that as our code quality, understanding and level of automation will all grow in lock step.

Compound Engineering: Skills, Debt, and Education

Individual AI productivity gains do not automatically become team gains. They become team gains when knowledge is shared: when the prompt or workflow one engineer found effective is committed to a shared repository and available to the rest of the team; when reusable skills are built and maintained like shared libraries; when what we learn compounds over time rather than staying with the person who figured it out.

This is what compound engineering means in practice. The shared skills repository is infrastructure. The 1,500-line limit on CLAUDE.md and equivalent files is not arbitrary—bloated configuration consumes token budget, introduces noise, and tends to grow without discipline. Keeping it tight is part of keeping the system effective.

Technical debt reduction is a strategic priority right now for a specific reason: AI tools are unusually effective at mechanical refactoring, dependency upgrades, and migration work. An engineer directing Claude through the JS-to-TS migration is doing work that would previously have taken substantially longer and been deferred indefinitely.

On education: the evidence from AI adoption research, including Mollick’s extensive work in this area, consistently shows that structured training programmes have low return compared to direct experimentation. Engineers who develop genuine competence with AI tools develop it through practice—on their own work, encountering the failures and limitations firsthand, building intuitive understanding over time. The structured workflow we recommend—Learn, Research, Plan, Execute, Review—is not a curriculum. It is a pattern of practice that, once internalised, becomes a natural way of working. We expect every engineer to have an articulated and tested personal AI workflow by the end of 2026.

Finally: AI tools are not a substitute for human collaboration. Extended working sessions where the only feedback comes from a model are not a healthy pattern, and they produce worse work. Share plans early. Seek genuine critique from colleagues. The wellbeing of engineers is not incidental to quality—it is a precondition for it.

Signature:

This memo was signed via git commit. Verify authenticity using git log --show-signature