Why We Built It: Foundry for VS Code
Welcome back to our “why we built it” series! @jorienv has been sharing a bit of insider context on our product decisions in a few previous posts that I recommend you check out. Today, I’d like to share my team’s thinking behind our recent investments in VS Code, and how it ties into our broader Developer Platform strategy.
A Quick Note on Foundry Developers
Palantir’s mission is enabling our users to solve their hardest problems, wherever they are. As a company, we’ve significantly invested in low/no-code tooling over the past few years in order to enable less technical users to build workflows on top of Foundry.
More recently, and with the release of the OSDK as Foundry’s API and the interest we’re seeing from developers and startups picking Foundry as their backing platform, pro-code tooling and DevEx have come to the forefront again (we now even have a dedicated DevCon conference for Developers in case you missed that!). Here are some notes to keep in mind about our Foundry developers:
- Our pro-code user base is increasingly growing in sophistication and the bar you all hold for the tooling you would like to use. What developers do ranges from writing ETL data transformations to building full ETE operational applications with backend and frontend all in Foundry.
- Our user base is not uniform: we have to serve the full spectrum of people from users in highside, disconnected and locked down environments, but also software engineers who are working at tech startups and who want to build on or integrate with Palantir Foundry as a platform. If you’re a user in that second bucket, you often have a specific set of tooling you’re familiar with such as where you would like to host your code (for example on GitHub, Bitbucket or others…), where you would like to run your CI pipelines and what IDEs you like to use locally.
What are We Doing
The overarching theme is meeting developers where they are, while acknowledging the diversity of your landscapes and demands. To this end, we’re starting with unbundling our DevEx monolith around Code Repositories.
Code Repositories is a central piece of Foundry’s pro-code data pipelining capabilities. It provides a Git-based code hosting solution, a custom integrated code editor and language server, as well as a CI/CD tool all in one. This vertical integration has proven a great tool to carry Foundry’s developer users in the early days, whoever the current design no longer serves our full user base in 2025.
Our current developers want more open-source tools and libraries while making use of the powerful capabilities of our stack. You may already be hosting code in GitHub and want to only use the CI/CD capabilities in Foundry, or again, you may want to do your full development outside of the platform and then push your final artifacts to Foundry. We’ve decided that we must evolve the Code Repositories stack to meet the demands of our developers guided by those key principles:
- Lean into the open-source ecosystem as much as possible
- Embrace familiar tooling, including IDEs and other developer services
- Provide a vertically integrated solution while allowing different sets of developers to pick and choose what subsets of it enable them most without having to go with an all-or-nothing approach
The first subpart we’ve decided to tackle is the code editor, and have decided to embrace integrating with VS Code as Foundry’s preferred editor for the following reasons:
-
It is the most popular IDE by a wide margin for the languages our developers use, and has robust language servers for those languages.
- This is great for us because you all are no longer only writing data transformations, but also building React apps and Python backends which have great support in VS Code.
-
It is customizable and extensible through an extensions framework. We’ve therefore developed a Palantir Extension for Visual Studio Code to bring all of the Foundry capabilities right to where developers develop!
- This helps our engineering team focus on one great coherent experience which works consistently on your local machine or in the browser rather than spreading ourselves too thin building different experiences for each.
-
We provide a fully hosted version in Foundry through VS Code Workspaces to allow for a single-click install which spins up a dedicated VS Code machine in the cloud with all the environment and code repo setup for you in a matter of seconds.
- This is particularly powerful for our users in on-prem* environments, those with non-unix machines, those who need a GPU to test their Machine Learning code, or anyone who would rather use the resources on their machine for other tasks than running hungry IDEs and language servers!
-
AI editors and agents have recently become very popular, and most of them are either VS Code forks or VS Code extensions so you can also use our extension outside of Microsoft’s Visual Studio Code.
- Hint: we have also now rolled out one of those AI development extensions configured for Foundry in the in-platform VS Code!
-
This isn’t VS Code specific but accepting that we had to reinvent ourselves has pushed us to rearchitect older parts of the platform in much more ergonomic and performant ways. Preview Engine is the highlight here which provides the “Preview” functionality in Transforms: the VS Code version is now significantly more performant and closer to what you would get in a build than the old experience. (I’ll leave the engineering behind this for another post)
What I describe above is all rolled out and you can try it out today for your code repositories by simply clicking the “VS Code” button at the top. In terms of what’s next, we’re investing into adding more features to Preview Engine, improving the hosted VS Code setup (for extensions for example), as well as investing in more AI coding agents for VS Code!
What We’d Like From You
Thousands of you have already been using the new VS Code experience since its rollout a few weeks ago, and we’ve received great feedback. (Fun fact to the side: we’ve also heard of someone shaming their colleagues for still using the old experience ).
Our work is far from done though, and the editor is only one part of what we have planned. Our team monitors this Community closely and want to hear from you, the developers, what you would like to see in our tooling or where you think we’re not doing enough. Internally, it’s also planning season, and so it’s a great time for you to give the VS Code experience a try and leave any feedback (positive and negative) here by using the vscode tag as well as spring-2025-planning for DevEx feature requests.
We can’t wait to see what you build!
*Kubernetes required
VS Code workspaces and the Palantir extension for Visual Studio Code are not affiliated with or endorsed by Microsoft.