Stop Fighting GitHub Copilot in Your Servoy Solution — Build It a Workflow That Knows the Platform

If your team has tried GitHub Copilot in VS Code against your Servoy codebase and given up because the suggestions are wrong half the time, the problem is usually not Copilot. It is that Copilot is being used as autocomplete when it is now capable of much more, and that nobody has taught it what Servoy is.

Servoy 2025.09 reformatted solution files specifically to be more compatible with AI-assisted development tools like GitHub Copilot, and the official Copilot plugin for Eclipse is generally available. The platform is meeting Copilot halfway. The remaining gap is on us as developers to teach Copilot the conventions and patterns it does not know out of the box.

Out of the box, Copilot will invent QueryBuilder methods that do not exist. It will write API endpoints that bypass your security layer. It will generate scopes that violate broadcasting rules. It will write SQL that ignores your tenant isolation pattern. The code looks correct, compiles in the IDE, and breaks the moment it touches the platform.

The Dotzlaw team has built a structured agent workflow inside Copilot for a Servoy enterprise codebase with thousands of functions across hundreds of files and 22 modules. Full write-up here: https://www.dotzlaw.com/projects/copilot-agent-pipelines/

What changes when Copilot is set up properly:

- Specialized agents instead of one generic assistant. A researcher agent maps the relevant code first. An architect designs the implementation. A developer writes the code following Servoy conventions. A reviewer checks for security violations, platform violations, tenant isolation issues, and accumulated business gotchas. Each agent does one job well and hands off context to the next through structured artifacts, no copy-paste between chat sessions.

- Domain skills that capture your platform knowledge. Skills are structured files that load contextually when Copilot detects relevant work. A querybuilder skill loads when working with QBSelect, QBJoins, or QBFunctions so Copilot uses the actual methods that exist instead of inventing ones that do not. An api-endpoints skill loads when adding or editing REST endpoints so security checks, request validation, and response shaping follow your conventions every time. The skills hold the rules, gotchas, and patterns that are not obvious from reading the code itself, the kind of knowledge that normally lives only in the heads of long-tenured developers.

- A self-improving loop. Every code review automatically harvests new business rules and gotchas it discovers, and feeds them back into the skill files. Knowledge captured once is never rediscovered. New developers (human or AI) inherit it immediately.

- The right model for the right job. Code generation, code review, and skill writing each have different cost-performance profiles. Assigning the right model to each agent keeps quality high without burning through API budget on tasks that do not need a frontier model.

Why this matters for Servoy teams specifically:

Servoy is exactly the kind of platform where generic AI assistants fail hardest. A proprietary API for foundsets, datasources, QueryBuilder, and UI construction. REST endpoints that have to enforce security at the application layer. Patterns like data broadcasting, tenant isolation, and security tables that are enforced in application logic rather than in the database. None of this is in Copilot’s training data in any depth, and none of it is recoverable from reading a single file.

A properly configured agent workflow closes that gap. The agents learn your conventions, your modules, and your gotchas, and they apply that knowledge consistently across every developer on your team. The setup scales down too, a handful of skills and a couple of agents is enough to see real benefit even on smaller solutions.

Happy to help. If your team is using Copilot but feels like the output is more trouble than it is worth, or you want to build out a proper agent workflow with skills customized to your Servoy solution, reach out. The Dotzlaw team can help set up the agent definitions and the initial domain skills, and train your team to extend them as you go.

1 Like

That’s awesome Gary! Would be cool to open source something like that for the community. I think Servoy is continuing to develop their own in-house AI to replace or augment copilot, so I’m excited to see that as well.

I have something semi-similar but not as advanced :slight_smile: I had a customer that required converting their codebase from Servoy to NodeJS. I used AI tools to automate most of that, and through that process it required training the AI on Servoy and its nuances. This resulted in a folder-based knowledgebase system that made the AI 10x more reliable. It understands form inheritance, scopes, relationships, etc.

The cooler part though, is that I was also able to repurpose that knowledgebase to my other Servoy projects to actually help it write Servoy code! So, now I can open up Cursor, point it at a Servoy wokspace, drop in my Servoy knowledgebase, give it 1 prompt to ingest it, and then all future prompts are now “Servoy aware” and can write and modify existing Servoy code. Thinking I might open source it eventually, but I’m not sure how many people would find it useful since its targeted more towards use in Cursor or other AI IDE’s, outside of Eclipse.

1 Like

Thanks Scott, really appreciate that. What you built sounds excellent. A Servoy-aware knowledgebase that survives a Servoy-to-NodeJS conversion and then turns around and helps you write Servoy code in Cursor is exactly the kind of practical, hard-won tooling the community would benefit from.

The skill system is in a similar spirit but works a little differently from a flat knowledgebase that gets ingested up front. Skills are structured files that sit in the repo and only load into context when Copilot detects the work is relevant. Editing a QueryBuilder function pulls in the QueryBuilder skill. Touching a REST endpoint pulls in the API endpoints skill. Nothing else loads. On a large codebase that matters, because you want context budget spent on the actual code, not on rules for systems the current task does not touch.

A lot of this came from the year we have spent with Claude Code, where skills, agents, hooks, and structured handoffs have been first-class features for a while. When Copilot rolled the same capabilities into VS Code, we ported the patterns we had already proven over to Copilot agent mode. Different runtime, same underlying ideas.

Very curious to see what Servoy ships on the in-house AI side. And if you do open source your knowledgebase, please post here. Everyone would benefit from a structured Servoy reference they can adapt rather than rebuild.