The spec is the new code, so brush up on your prose, says Kaseya CTO

Domain expertise and clear writing will matter more than syntax, and yes, that means documentation

Software developers will need to get their kicks from becoming code coaches of AI, professors of prompt engineering, and masters of their domain. 

So says Pratik Wadher, chief technology officer at Kaseya, who oversaw a team of codesmiths rewriting software across the company’s managed services portfolio, which spans remote monitoring and management, backup and recovery, cybersecurity, and automation. 

“The goal is unifying our data, unifying our API, but as we are starting to also look at the product portfolio that we have, we're trying to understand what are the patterns that we can use to consolidate the product workflows,” he tells The Register. 

REG AD

Storage is a good example. The basic workflows involve reading and writing data to storage arrays, Kaseya's own cloud environment, or the racks run by hyperscalers. The team re-architected the back end of its storage products so the storage engine reads and writes to any kind of storage from ZFS to S3. 

REG AD

“This is where AI helps,” Wadher claims. “Fundamentally we have accelerated that piece of re-architecture.”

Since joining Kaseya in September 2025, the CTO has been trying to simplify what he admits can be a “confusing” number of individual products.

“The storage layer that we've been writing, we re-architected and wrote it in six weeks. And that's the actual writing, implementing and testing the code. There are years of domain expertise behind understanding how we want to write it.”

In the process, Kaseya used Anthropic coding agents to help a human write the spec. The meatbags at Kaseya then iterated on it and peer-reviewed it with critique agents, before the AI generated the code. Anthropic’s Claude is becoming the “de facto standard” for writing code at Kaseya.

“When I look at my engineers, it's not how I used to write code. It's almost like I'm manipulating these agents, but the best engineers are still critical, because you have developed a lot of experience in understanding what you need to do,” Wadher says. 

Does this take the fun out of coding? Yes and no, he claims. Mirroring the wider industry, some Kaseya engineers are embracing the new approach and some are more “hesitant.” 

“The fun part of coding is going to be the design, the architecture, the thinking. Writing code is fun but I don't think it's [the] fun [part]. The fun part is having the code run, seeing what it can do, and then tweaking it and changing it. If you can accelerate that and start seeing the results, I think that, for me at least, that would be the fun part: seeing the impact.” 

Developers must become proficient prompters and “you need the domain expertise,” he adds. “If you’re just using AI to generate code I don’t think you’re going to be useful and I don't think the code you're writing is going to be useful.” 

REG AD

Some Reg readers and some of the article-writing vultures may disagree. There is a clear split happening in the world of FOSS, for example, where some projects want only human-written code and others take what they describe as a more pragmatic view of AI tools. 

AI is already forcing change upon the tech sector. Research last year suggested the number of graduates starting a career in technology is plunging with certain functions being subsumed by agents. 

“I think basic tasks will be done by AI, so you're not going to need that,” Wadher says. “The skills that will be extremely important are critical thinking and writing.

“The worst part of coding, [the thing] engineers hate is writing the documentation. Well, guess what? That is going to become even more critical now. Being able to write clear, concise design specifications, the functional specifications, is going to be extremely important. The good thing is that you’ll now have an [AI] partner that can do this with you and you can iterate with this partner.

“I would say the new code is the spec. That's what you're going to check into GitHub now, because you want to make sure that the spec you wrote is going to generate the same type of code now over and over again. I have seen variances." ®