Kaseya CTO Says AI Coding Makes Specifications the New Code, but Verification Still Matters

This is a vendor executive describing his own company's approach. It isn't an independent audit, and the details below should be read that way.

What Kaseya says it did​

Wadher joined Kaseya as CTO in September 2025. The company's own announcement is not in the search results I used, but the packet shows Kaseya announced his appointment on September 10, 2025. It described his remit as advancing a unified, AI-first platform that brings together 40+ products. That context explains the interview. Kaseya sells a sprawling managed-services portfolio covering remote monitoring and management, backup and recovery, cybersecurity and automation. Wadher says he is trying to simplify it by unifying data and APIs and by finding workflow patterns that can be consolidated.

Storage is his worked example. According to The Register's account:

• The team re-architected the back end of its storage products so one storage engine can read and write to different targets, from ZFS to S3. Those include storage arrays, Kaseya's own cloud and hyperscaler infrastructure.
• Wadher says the writing, implementing and testing took six weeks. He adds that this sat on years of domain expertise about how the system should work.
• Anthropic coding agents helped a human draft the specification. Engineers then iterated on it and peer-reviewed it with critique agents. Only after that did AI generate the code.
• Claude is becoming the "de facto standard" for writing code at Kaseya, per the report.

The six-week figure is Wadher's own estimate. The interview doesn't name the storage product or release, the models used, or the validation steps. It gives no measurements of code quality or maintainability. I won't fill in those gaps.

The "spec is the code" argument​

Wadher's reasoning is simple. If you want an AI to produce the same kind of code repeatedly, the thing worth checking into GitHub is the specification. He admits he has "seen variances" between generated outputs, which is the awkward part of the pitch. If the spec is the source of truth, then ambiguity in the spec becomes a defect in the product.

He also says routine tasks will be automated. The skills he expects to matter are critical thinking and writing, and he says an AI partner can help draft the documents. He concedes that some Kaseya engineers are enthusiastic and others hesitant.

Is this a real pattern or one executive's slogan?​

The idea isn't unique to Kaseya. GitHub's open-source Spec Kit, announced in September 2025, is built around the same premise. GitHub says it treats specifications as living artifacts that serve as the shared source of truth. It describes a four-phase flow of specify, plan, tasks and implement, with checkpoints where the developer verifies each stage. GitHub says it works with tools including GitHub Copilot, Claude Code and Gemini CLI. GitHub also argues the shift is "intent is the source of truth" rather than "code is the source of truth." That is close to Wadher's formulation, though it doesn't confirm Kaseya's results.

Search results suggest the toolkit has kept evolving. One review dated September 2026 describes a spec, plan, tasks, implement and converge workflow with many agent integrations. That is a third-party review and I haven't verified it independently.

GitHub's Copilot documentation adds a practical caveat. Repository custom instructions can describe project structure, coding standards, and how to build and test. GitHub tells users to review the generated instruction file before merging it. It also notes that Copilot may not follow instructions perfectly every time. Treat a spec as strong guidance, not a guarantee.

What teams can do with this​

These are my own conclusions, drawn from the sources above rather than from Kaseya.

1. Write specs a literal-minded reader can follow. Cover expected behavior, constraints, architecture and success criteria. Vague requirements make an agent guess.
2. Keep specs in version control. Review them like code, and update them when requirements change.
3. Don't confuse a spec with verification. A spec states intent. Tests and human review show whether the implementation matches it. Kaseya reportedly used critique agents and human peer review, but the interview doesn't describe its test regime.
4. Check for drift. If regenerating from the same spec gives materially different code, the spec is probably underspecified. It may also mean the process lacks controls.
5. Record build and test steps for the agent. That is the kind of context repository instructions are designed to carry.

Caveats​

• The Register notes a split in FOSS. Some projects want only human-written code, and others take a more pragmatic view of AI tools. The piece names no projects, so I won't generalize beyond that.
• The Register also cites research on falling numbers of graduates entering tech. It doesn't identify the study, so I can't evaluate the claim.
• Nothing here shows specs will replace source code as the authoritative artifact everywhere. For many teams, the checked-in code still carries behavior that no prose document captures. The claim is a forecast from a CTO whose company is investing in this approach.

The takeaway​

Wadher's pitch is that AI shifts the hard part of software work toward knowing what to build and saying it precisely. That fits where tools like GitHub Spec Kit and Copilot custom instructions are heading. The open questions are reproducibility, which Wadher himself raises, and verification, which the interview doesn't address. Teams adopting this style should invest in the prose and in the tests.