I’ve heard one question in almost every analytics team I’ve worked with over the past decade. It usually comes from quality control, and it usually comes after the code is finished:
How do you know the numbers are the same?
PolyKode is my answer to that question. In a way, I’ve been building it for about ten years. I just hadn’t written the code yet.
From ProCogia 1.0 to an AI venture studio
PolyKode is also a sign of how ProCogia itself is changing.
ProCogia 1.0 was a consulting firm. Clients brought us hard data problems and we solved them one engagement at a time. We were good at it, but what we learned mostly stayed in people’s heads and slide decks, and every new project started close to zero.
ProCogia 2.0 is an end-to-end AI venture studio. We still consult, and we always will. But now every engagement also tells us which problems keep coming back, and we turn those into products. PolyKode grew out of a decade of translation and validation work. CallYeah, ZeroBoxx, Dataegis, and Haigent grew out of other work. The products make our consulting faster, and the consulting keeps the products grounded in real work. The line between the two gets thinner every month. That’s by design.
We’re not the only ones betting on this model. Sequoia’s Julien Bek wrote this year that “the next $1T company will be a software company masquerading as a services firm”, because “if you sell the work, every improvement in the model makes your service faster, cheaper, and harder to compete with.” Foundation Capital calls the same shift “service as software” and sizes it as a $4.6 trillion opportunity. General Catalyst points out that US service industries generate more than $6 trillion a year, compared with a $370 billion software market.
Our reading of all three: the next great companies will know a field well enough to deliver the result, and build the software that makes delivering it repeatable. That’s what a consulting firm with a product engine can be. PolyKode is the first product we’re telling that story through, because it’s the one I’ve carried the longest.
A decade at the crossroads
For most of that decade, ProCogia has helped analytics teams in pharma, banking, insurance and the public sector work across SAS, R and Python. We wrote a lot of code in all three, and translated a lot of it between them. The translating was rarely the hard part. Proving the result was.
From 2020 to early 2026, I also served on the board of the R Consortium, the nonprofit that supports the R language and its community. From July 2023, I was its chair.
That role gave me a front-row seat to one of the most important shifts in regulated analytics. Through the R Consortium’s R Submissions Working Group, pharmaceutical companies and FDA staff worked together in the open on test submissions built with R: first tables and figures, then a Shiny app, then the analysis datasets themselves. FDA staff reproduced the results. Their feedback kept coming back to the same things: document the computing environment, be clear about package versions and explain the data processing rules.
Three lessons I carried out of that room
- The real question was never “which language?” It was “can we trust this result, and can someone else reproduce it?” The strongest teams I met used SAS, Python and R together and respected what each one does well.
- Reproducibility makes approval possible. Pinned environments and documented runs are what let a reviewer say yes.
- Good interfaces build trust. When reviewers can explore results in an app instead of reading static tables, the conversation changes.
Every one of those lessons is in PolyKode today. What was missing, for years, was a practical way to translate and check code at scale without a building full of expert programmers fluent in two or three languages.
Why now: AI made it buildable
AI changed that. A model can now read a 2,000-line SAS program and write the R or Python version in seconds. The industry sees it too: the same R Submissions Working Group has started a pilot on AI-assisted generation of analysis datasets and tables.
But AI solved only half the problem.
- Writing code got cheap. Checking it did not. Output went up. Review capacity didn’t. The bottleneck moved from typing to trusting.
- Reviewers are asking how AI-generated code was checked. “The model wrote it” is not an answer a validation team can file.
- Regulated teams need AI they can run privately. Open-weight models now make it possible to run a specialist model inside a customer’s own cloud or data center.
PolyKode is built for the half AI didn’t solve.
What we built
PolyKode is an AI-native platform for enterprise analytics teams that work in SAS, R and Python. It translates code in every direction, runs both versions and produces a parity report showing, row by row and value by value, that the numbers match. Or it shows exactly where they don’t.
Underneath it is one belief, which we call co-existence: SAS, R and Python, and the platforms around them, are better together than apart. We share that belief in two ways. SAShiny is our open-source version. PolyKode is our enterprise version.
Ten years ago, building PolyKode would have taken an army of consultants. Today it takes the right models, the right engines and the discipline to prove every result. That’s why we’re building it now.
In this series
- Part 2: Co-existence, and what it means for teams working across multiple languages.
- Part 3: Introducing SAShiny, our open-source take on the same idea.
- Part 4: How a parity report is made, from our product and platform team.
- Part 5: Why we’re building a specialist model, from our LLM team.
- Part 6: What we learned, and what comes next.
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. PolyKode is an independent ProCogia product and is not endorsed by SAS Institute Inc. or the R Consortium.
