Reliable MPS builds and hard evidence on where AI can help.
I fix the build, CI, and migration problems your team can’t get to, and run controlled experiments to find out where AI agents can free your language engineers to focus on domain problems.
You already have people who know MPS and the project they maintain. But the hardest problems often sit beneath the platform itself—in build infrastructure, version migrations, or MPS internals—where ordinary fixes stop working.
Hi, I’m Sergej Koščejev. Those are the problems I work on with enterprise engineering teams.
Tell me where your MPS project is stuck →
“With Sergej we were able to grow our in-house talent as well as accelerate our project by working with an expert. He was an active participant in code reviews, as well as design discussions, enabling our internal developers to grow in their expertise. We also benefited from Sergej’s professional network and reputation.”
— Nat Peterson, Senior Principal Software Engineer, Workday
Your MPS tool works. The infrastructure around it doesn’t.
Your team built something important in MPS. A domain-specific language that lets system engineers, actuaries, or other specialists describe complicated things precisely. The tool works. People depend on it.
But the infrastructure around the tool can introduce its own problems.
Builds take an hour and fail for no clear reason. They are flaky or non-deterministic, and sometimes they fail for reasons that have nothing to do with your code.
Developers don’t bother to understand the cause of an error and just try things out to see what works. The real error is buried. Useful diagnostics are hidden under pages of exceptions that carry no information, and that is time not spent on the work your developers were hired for.
CI run times are unpredictable. Caching doesn’t work the way it should. MPS models are opaque to standard build tooling. Inputs and outputs need manual specification, conventions drift, and caches are missed—adding time to every CI run.
You’re stuck on an old MPS version. Moving to a newer MPS version means upgrading every dependency, then every project, then the infrastructure, then fixing the bugs that surface. When you have many projects on old versions, the bottleneck is as much organizational as it is technical.
Your best people are blocked by a failure nobody can explain. They are good developers. They built the language. But this failure doesn’t make sense, and nobody on the team has time to attach a debugger to MPS internals and find out why.
Off-the-shelf AI is a decent pair programmer on MPS. As an unattended agent, it falls short. Everyone is asking about AI, but the tools are not great at running autonomously in the background while your engineer does something else. A demo is easy. Deploying something useful inside enterprise security and approval constraints is a different problem entirely.
Predictable builds, staged migrations, and an evidence-based answer on AI
Imagine a world in which…
- Your builds are deterministic. When one fails, you know it’s because of a real problem and not some random race condition or caching glitch. Which means you can stop worrying about your builds and spend more time worrying about your DSLs.
- Your migration has a staged plan. Dependencies, projects, and infrastructure move in a sequence that keeps the current system usable at every step. Nobody is stuck on a version from three years ago because the upgrade looked too risky to start.
- When something genuinely difficult surfaces—a failure deep in MPS internals, a non-obvious interaction between plugins, a build-tool behavior that contradicts the documentation—there is someone who will reproduce it, dig in, find the root cause, and explain it clearly.
- Your language engineers spend their time on domain problems, not on fighting with infrastructure or automation.
- And if AI-assisted tooling can reduce real friction—issue reproduction, test generation, build diagnosis, model analysis—you find that out through a controlled experiment with a measurable baseline, not through a vendor pitch.
Why MPS infrastructure breaks down
MPS projects tend to accumulate neglected infrastructure. The build scripts, CI pipelines, caching logic, dependency management, and upgrade paths are not glamorous. Teams put them off because they are complex and because the people who can fix them are usually needed elsewhere. The problems compound until something breaks in a way that blocks the whole team.
I have spent years inside large, complex MPS environments where the projects number in the dozens, the domain models are deeply interconnected, and the organizational constraints are as real as the technical ones.
Where AI coding agents can work unattended on MPS projects, and where they can’t
With AI, my approach is the one I use for infrastructure problems: reproduce, measure, compare. I build
tooling—including mops, my open-source project for running coding agents on MPS projects—and test specific hypotheses
about where agents can be left to work on their own and where they add cost or risk. I treat “it doesn’t help” as a
valid finding.
Complex domains still need explicit models, rules, validation, and human judgment. AI doesn’t replace that. But it can reduce specific kinds of friction when the tooling, scope, and safeguards are right. The question is always whether it does, not whether it could.
Three ways to get help, from free to hands-on
1. Free: articles and emails on MPS infrastructure and AI
I publish articles and occasional emails about MPS infrastructure, build systems, editor design, debugging, and AI-assisted language engineering. They are short, specific, and based on real problems I’ve encountered.
Browse the articles → | Subscribe to emails →
2. Free: bring your problem to MPS Office Hours
MPS Office Hours is a free, public group call where MPS developers can share their screen, demo a problem, and get direct guidance.
3. Paid: a one-time call, or ongoing advice
When your team needs specialist help—a hard diagnosis, a migration plan, build and CI remediation, or an expert pair of hands on a problem that has the internal team stuck—I work with you directly.
MPS Troubleshooting — Got a quick question about MPS you need answered? Things like: Why is my UI so slow? How do I speed up my builds? How do I work around this MPS bug? How should I plan for an MPS version migration? Book a call with me, share your screen, and we’ll go through it together.
Book your MPS Troubleshooting call now →
MPS Advisory Retainer — Ongoing asynchronous technical guidance for a team lead, architect, or CTO. You describe the situation; I respond within one business day with analysis, recommendations, and next steps.
Book a free call and tell me about your project →
Open-source MPS tools I maintain, including mops CLI for running coding agents
mops CLI — An experimental, open-source project for running coding agents on MPS projects in isolated worktrees. Early-stage; I use it for my own AI experiments and welcome feedback.
Build Script Notifier — An MPS plugin that detects stale build scripts and can fix simple errors automatically. If you update module dependencies but forget to keep the build scripts in sync, this catches it before you start off a lengthy build. (Not actually open-source, but it is free)
MPS Gradle Plugin — Build tooling for MPS projects that integrates with standard Gradle workflows.
Pre-commit hooks for MPS — Catch basic problems and ensure project consistency in seconds, before CI.
“We learned everything we needed to fix our build”
“We learned everything we needed to fix our build and distribute our language automatically, which is going live as I write this.” — Sebastian Schöneberg, Actuary, Volkswohl Bund Lebensversicherung_
“Sergej managed to solve most of the issues prior to us even talking!”
— Thomas Mead, Doctoral Student, The Francis Crick Institute and King’s College London
“With Sergej we were able to grow our in-house talent as well as accelerate our project by working with an expert. He was an active participant in code reviews, as well as design discussions, enabling our internal developers to grow in their expertise. We also benefited from Sergej’s professional network and reputation.”
— Nat Peterson, Senior Principal Software Engineer, Workday
Over a decade in MPS, starting at JetBrains, now building AI tooling for it
I have worked with JetBrains MPS for over a decade—first at JetBrains, then as an independent specialist helping enterprise teams build, maintain, and evolve complex domain-specific tooling.
My longest engagements have been inside large MPS environments with dozens of interconnected projects, where I held an expert role and was trusted to identify what work mattered most—not just execute tasks. I co-maintain widely used open-source MPS ecosystem projects and contribute to the build tooling and infrastructure that serious MPS projects depend on.
I have trained teams, led architecture and design discussions, reviewed code, fixed obscure platform bugs, and rebuilt CI pipelines. I have helped teams navigate enterprise security restrictions, artifact-repository constraints, and the organizational friction that often matters more than the code.
More recently, I have been designing and testing AI-assisted workflows for MPS—building mops, benchmarking agent
performance on real tasks, and developing practical approaches to issue reproduction, test generation, and model
analysis. I present this work at conferences and share the results publicly.
If your MPS project is stuck, or if you want to find out whether AI can reduce real friction in your language-engineering workflow, I’d like to hear about it.
Tell me where your MPS project is stuck →
Overwhelmed by MPS? I send out occasional tips to help you build better MPS-based tools.