Pratik Wadher, chief technology officer (CTO) of Kaseya, says the company used AI to redesign its storage layer in just six weeks, completing everything from code implementation to testing. He made the remarks in an interview with The Register published on October 21, describing a new development approach in which humans write and verify specifications and AI generates code from them. "The spec is the new code," Wadher said, adding that future developers will need not only programming language skills but also a deep understanding of the business and the ability to communicate design intent in clear prose.
The six-week timeline, however, rests on years of accumulated expertise. This was not a case of simply instructing an AI and getting a complex system built quickly, nor has it been shown that saving a specification will always let you regenerate code of the same quality. What the case suggests is that as AI makes writing code more efficient, the developer's role is shifting toward clarifying design requirements and verifying what the AI generates.
Storage layer redesign, from implementation to testing, in six weeks
Wadher described a redesign of the backend that underpins Kaseya's storage products. The company developed a common storage engine that can work with storage destinations built on different mechanisms, such as ZFS and Amazon S3. After revisiting the existing architecture and redesigning the processing involved in reading and writing data, it reportedly completed code implementation and testing in six weeks. That period applies to development of the storage layer; it does not mean Kaseya integrated all of its products and systems in six weeks.
Wadher also explained that understanding what kind of system needed to be built required years of accumulated expertise. Beyond knowing storage technology, familiarity with the structure of existing products and the features customers want is what allowed the team to give the AI appropriate design requirements. The six-week figure reflects the time it took engineers with that knowledge and experience to make design decisions and carry the work from redesign through implementation and testing. It should not be read as a case of an AI understanding requirements from scratch and completing a system from a brief prompt.
It also remains unclear how many weeks the same work would have taken with conventional methods, how many people were involved, or how total effort and defect rates changed. For that reason, the case does not allow anyone to calculate how many times faster AI made development. It is an individual example presented by Kaseya's CTO, and there is no guarantee that other organizations could finish similar work in the same time using the same approach. Even so, how AI was built into the process from design through implementation and testing offers a useful reference for companies considering AI-assisted software development.
Writing and reviewing specs before writing code
The defining feature of Kaseya's approach is that it spends considerable time writing and reviewing specifications before the AI writes any code. At Kaseya, humans first draft a specification with help from Anthropic's coding agent and revise it repeatedly. In addition to peer review among developers, the company uses a critic AI agent to point out problems in the spec, and only after this verification does it move on to code generation. According to The Register, Anthropic's Claude is becoming the de facto standard for generating code inside Kaseya.
In this approach, what developers must check extends beyond the finished code to the specification that precedes it. Before handing implementation to the AI, they have to be clear about what is being built, what behavior is required, and which constraints must be respected. Wadher's emphasis on business knowledge and writing ability is tied to this change in the development process. Even clear prose cannot specify the right behavior and constraints if the author doesn't understand the business or the product's inner workings.
Wadher argues that critical thinking and writing skills will matter especially for future developers. In his view, design documents and functional specifications, which developers have often found burdensome, become the central work in AI-driven development. AI can help draft and revise specs, but deciding what should be achieved still requires human expertise. He says that simply having AI generate code increases neither a developer's value nor the usefulness of the code produced.
Kaseya's adoption of this approach is also linked to its push to consolidate its product lines. In an official announcement on April 28, 2026, Kaseya outlined a platform concept that unifies data from IT operations, cybersecurity, backup and other areas, and in which AI assesses situations and acts autonomously. In backup, it also introduced a way to manage data protection across on-premises environments, SaaS, endpoints and the cloud from a single portal. In this interview, Wadher likewise cited unifying data and APIs, as well as consolidating business workflows common across products, as goals.
It cannot be confirmed whether this storage-layer redesign is the same work as the concept announced in April, but both share the direction of organizing functionality common to multiple products. Designing a storage engine that supports different storage destinations requires deciding which functions to share and how to handle differences between destinations. Such decisions depend on understanding existing systems; even if code generation can be handed to AI, the design judgments are not automatically resolved.
Separating specification, technical plan and verification
A spec-centered development approach is not unique to Kaseya. In September 2025, GitHub released Spec Kit, an open-source tool that supports AI-assisted Spec-Driven Development. GitHub's official explanation describes a process in which the purpose and required functions of the software are first defined as a specification, followed by a technical implementation plan. The plan is then broken into small, verifiable tasks before moving on to AI implementation.
This does not mean Kaseya adopted Spec Kit, but the idea of clarifying specifications before having AI generate code is common to both. A specification describes user requirements and expected behavior, while a technical plan summarizes system architecture, conditions for connecting to existing environments, and implementation constraints. Tests and other checks then confirm whether the implemented functionality works as expected. Separating the definition of goals, the choice of implementation methods and the verification of behavior makes clear what should be checked at each stage.
Based on GitHub's approach and Anthropic's official Claude Code guidance, the deliverables to keep during development and their roles can be organized as follows.
| Deliverable | What it confirms or decides | What it cannot determine alone |
|---|---|---|
| Specification | Who it is built for, what is being built, and what counts as success | Whether the implementation works as expected |
| Technical plan | How it will be built and how it satisfies existing system constraints | Whether the expected results are achieved in a real environment |
| Verification results | Whether tests, builds, screenshot comparisons and the like confirm the expected behavior | Whether it works correctly under conditions that weren't tested |
This table organizes the role of each deliverable based on the approaches the two companies describe. The specification clarifies goals and requirements, and the technical plan defines the architecture and constraints for implementing them. Verification results then serve as the basis for judging whether the finished implementation actually meets the expected behavior. GitHub stresses the importance of humans reviewing the deliverables at each stage, and Anthropic recommends giving AI means of verification, such as tests, builds and screenshot comparisons, so it can check its own output.
Consider, for example, a case where writing data to storage fails. A spec that merely says "save the data" does not make clear what should happen when saving fails. If the spec defines conditions such as how the error is reported to the user, whether retries are allowed, and which states count as normal, it becomes easier to verify whether the generated code meets the requirements. This is not a description of a specification Kaseya actually used; it is an example of turning business requirements into verifiable conditions.
However, a correct specification and a correctly working program are separate matters. If the spec lacks necessary conditions, the AI may generate code exactly as instructed and still fail to deliver the behavior users need. Conversely, even a well-organized spec can lead to defects during implementation, and correctness cannot be confirmed without actually testing. And even when tests pass, the result does not guarantee behavior under conditions that weren't verified. Reviewing the spec and verifying the implementation are both indispensable steps.
"The spec is the new code," but accurate regeneration isn't guaranteed
Wadher suggests that as AI-driven development spreads, the key artifact stored on GitHub will shift from code to specifications. The idea is that if you keep the spec, AI can repeatedly generate the same kind of code from it. Yet he himself acknowledges having seen variation in what AI generates. The phrase "the spec is the new code" does not mean a spec uniquely determines the implementation the way a programming language does; it expresses that the specification is becoming important as the basis for development.
In practice, then, it is not enough to save a spec; teams need a mechanism for confirming that a regenerated implementation meets the expected behavior. If the technical plan and test results are kept along with the spec, then even when the AI produces code different from last time, teams can compare whether it respects design constraints and whether the required functions work. What matters is not that identical code is generated, but that, even with a different implementation, one can judge whether the required conditions are met. Lines of code or generation speed alone cannot measure quality.
The six-week development period Kaseya reported shows the potential of AI-based software development, but evaluating its effect requires additional information. Knowing the time and total effort conventional development would have taken, which tests the generated code passed and how much correction it needed would make comparison with other methods easier. Whether spec-centered development is truly efficient should be judged not only by how quickly code is generated but by whether it reliably delivers software that meets requirements.
What this case shows is less that AI will eliminate developers' jobs than that the expertise required of them is changing. The more of the code-writing AI can take on, the more important it becomes to understand business requirements, set appropriate design conditions and verify generated results. Whether Kaseya's approach can be replicated in other development settings awaits further validation, but putting specifications and verification results at the center of development is an important direction for ensuring the quality of AI-assisted software development.