DevRev's transition to AI-powered integration development
How *codeplain is helping DevRev automate integration development with spec-driven development.
Over the past year, the rise of AI-powered coding has changed how product teams build software. As models became capable of handling more of the implementation work, engineers began shifting focus from repetitive coding toward higher-level questions of architecture, validation, and intent. The result is a quiet change in how teams collaborate and moving away from manual implementation toward a shared language of specification.
With the rise of vibe coding and spec-driven development, the boundaries between roles are shifting. Product designers are now using vibe coding tools to build entire features and screens directly in code, exploring behavior instead of just using static interfaces. Engineers, meanwhile, shifted the focus from writing code to describing the system so that machines could build it reliably.
This makes a fundamental change in how teams plan, design, and execute work—one that aligns closely with Marty Cagan’s idea of empowered product teams, where design, product, and engineering operate as peers defining outcomes, not just deliverables.
At *codeplain, we saw these ideas come to life most vividly in our work with DevRev. Their journey from manual integration development to automated specification-based development became a live demonstration of this shift.
Inside the DevRev Partnership
Six months ago, our team at *codeplain partnered with DevRev, an AI-first product company that connects customer support, product management, and engineering into a single workflow. Their powerful AirSync integration platform powers hundreds of connections to third-party tools like Slack, Jira, GitHub, Salesforce, Google Drive, and Microsoft Outlook — ensuring that data flows seamlessly between teams and systems.
Our goal was to introduce a specification-driven approach to integration development — replacing manual coding with structured, executable definitions written in ***plain specification language. In this new model, integrations could be implemented and tested entirely through specifications, with *codeplain automatically generating production-ready, test-covered code.
From my perspective as a product designer at *codeplain, this partnership wasn’t just about code automation, but about redefining how teams collaborate with AI and with each other. I wanted to understand how engineers experience that shift: how it changes debugging, testing, and even the sense of ownership over the system they’re building.
Throughout the six-month collaboration, we worked closely with two DevRev engineers, Patricija and Gašper, who became our closest partners in shaping this new process. Patricija was the first to adopt *codeplain for integration development, exploring how acceptance tests1 could serve as both validation and debugging tools through implementing Wrike. Gašper, meanwhile, focused on observability through implementing Aha! by building a custom command-line interface to better understand how the ***plain rendering and generation pipeline behaved in real time.
Together, we created a repeatable and scalable process for integration development using specifications. What follows is the story of that transformation: how DevRev moved from hand-coded integrations to fully automated, specification-driven systems — and what that change looked like from the inside.
Developing a repeatable and scalable process
When we began working with DevRev, we decided to introduce spec-driven development incrementally. We wanted to verify, at each stage, that *codeplain could meet DevRev’s engineering standards for structure, reliability, and maintainability.
The process unfolded in five distinct phases, each validating a core principle of spec-driven development.
1. Reimplementing an Existing Integration
Our starting point was to prove functional equivalence. The engineers reimplemented one of the existing integrations, Asana, using ***plain specification language. The goal wasn’t innovation, but verification: could a spec-driven workflow replicate the logic, SDK structure, performance, and integration framework of manually written code?
We started by decomposing the entire integration into a set of functional requirements, each representing a small, testable unit of behavior. Every integration begins with making API calls to a third-party service, processing the response, and mapping data to DevRev data models. In ***plain, we captured each of these as a reusable building block, defining inputs, outputs, and validation conditions explicitly.
Here’s an example of how to fetch a list of projects in the Asana workspace in ***plain:
- Implement the :Function: that fetches the :ListofProjects: using the projects endpoint of the :API:.By defining integrations this way, the developer stayed in control of the high-level architecture and behavior, while *codeplain handled the implementation details and boilerplate. It shifted engineers’ attention to architectural decisions, leaving the repetitive implementation details to the code renderer.
The results demonstrated that *codeplain could generate functionally equivalent, production-ready code — delivering the same behavior, reliability, and maintainability as the manually built version, while eliminating repetitive boilerplate work.
2. Implementing a New Integration
After proving that *codeplain could reproduce an existing integration, we moved on to the real test: could we build a brand-new integration and do it with enterprise-level precision?
DevRev chose Trello as the first new integration to build with ***plain, since it’s a core part of DevRev’s AirSync platform. Engineers defined the integration entirely in specifications—data mappings, event triggers, API endpoints, and expected behavior—leaving *codeplain to generate the implementation.
Here’s an example of how to fetch boards in the Trello workspace in ***plain:
- Implement the :Function: that fetches the :ListofBoards: using the boards endpoint of the :API:.Just like in Asana, the integration boiled down to the same basic pattern: call the third-party API, process the response, and map the data into DevRev’s models. The specifics differed, but the structure was almost identical.
That similarity turned out to be important. Seeing Asana and Trello expressed as sets of functional requirements made it clear that most of the integration follows a repeatable shape. The only thing that really changes is the third-party service itself—a realization that would shape the next phase.
This step demonstrated that *codeplain could deliver new integrations that met DevRev’s engineering standards for performance, structure, and reliability. It also showed that engineers could now focus on defining intent and specifications instead of writing and reviewing code line by line.
3. Creating an Integration Template
After completing Asana and Trello, we had enough evidence that the approach worked: *codeplain could generate integrations that behaved the way DevRev expected, and the workflow held up across multiple services.
With two specs to compare, a pattern started to emerge. Even though Asana and Trello are very different products, the structure of the integration was largely the same. The team kept seeing the same building blocks repeat:
Standardized credentials
Boilerplate API schema definitions
Authentication and metadata synchronization logic
Reusable data-fetching
These similarities pointed to a simple conclusion: most of the integration doesn’t change. Only the third-party API does.
To accelerate integration development, DevRev pulled the shared pieces into a modular integration template. All the common logic moved into the template, while each new integration kept only the service-specific parts—its endpoints, authentication parameters, and API payloads. The rest was handled automatically.
This shift created a scalable process for AirSync development. Engineers no longer wrote integrations line by line; they defined how the integration should behave, and the system generated the implementation around that intent. It turned what had been a repetitive engineering workflow into a consistent, repeatable process—while keeping engineers in control of the architecture.
4. Testing the Template on New Integrations
Once the integration template was stable, DevRev set out to test its scalability across different APIs and authentication models. Engineers Patricija and Gašper worked independently, each implementing a new integration in parallel. Both integrations confirmed that integrations could be built, tested, and deployed in under two days using ***plain.
As more of the workflow became automated, a new issue surfaced: engineers needed better visibility into what the system was actually doing. When rendering, testing, and validation all happen behind the scenes, it can be hard to understand where something failed or why a run took longer than usual.
To address this, Gašper built a lightweight command-line tool that visualized each stage of the generation pipeline with timestamps. It replaced a stream of raw logs with a clearer view of the rendering flow, making debugging faster and helping engineers trust the system’s behavior. This tool became the foundation for improving developer observability inside automated workflows, something we’ve been improving at *codeplain ever since.
By the end of this step, the engineering workflow itself was fast and repeatable. Once a developer had a clear ***plain specification, they could generate and validate an integration without touching boilerplate code.
But this only solved the engineering side of the process. Engineering could now move quickly, but product inputs were too often still arriving through ad-hoc conversations, Slack threads, and scattered notes. In other words, the product organization now needed to provide requirements faster and in a more structured way. That gap is what ultimately led to the introduction of a PRD-driven workflow.
5. Introducing a PRD-Driven Workflow
As DevRev’s engineering speed increased, a new challenge emerged — the bottleneck had shifted upstream. Specs could now be generated and deployed in days, but only after someone had precisely defined what the system should do. The faster engineering moved, the more the product had to catch up.
To make that alignment part of the process, DevRev is restructuring around a Product Requirements Document (PRD). The PRD sits at the same abstraction level as an integration specification — it defines what the system should do, how it behaves, and what external dependencies it touches.
Instead of writing specs first and adjusting decisions afterward, teams iterated on the PRD until it captured the complete intent. From there, engineers could automatically generate most of the ***plain specification, refine any missing details, and validate it through automated tests.
This change didn’t just speed things up, but also created a shared foundation between product and engineering. The PRD turned intent into something concrete, making specification-driven development a natural extension of how teams already plan and design features.
Why Teams Like DevRev Are Adopting Spec-Driven Development Now
Working with DevRev over the past six months has made one thing clear: spec-driven development isn’t just a new engineering technique, but a structural necessity for AI-powered organizations.
Modern product teams can’t keep growing headcount every time complexity increases. The old model — growing engineering headcount in proportion to product ambition — no longer works. The constraint is no longer code; it’s collaboration. As systems multiply, so do handoffs, reviews, and the time it takes to align on intent. Automation helps, but abstraction is what truly unlocks scale.
Spec-driven development gives teams that abstraction. By capturing intent in structured specifications, engineers focus on architecture and validation rather than boilerplate, while product and design define behavior upfront. Designers and product managers define behavior and constraints upfront, ensuring alignment before a single line of code is generated.
The quiet shift we saw at DevRev is part of a broader change: teams are learning to collaborate with AI at the intent layer, not compete with it at the implementation layer. What started as an experiment in automation has evolved into a new foundation for building software — where the specification, not the codebase, is the real source of truth.
Acceptance tests verify requirements and validate user needs.
 | A guest post by
|