How we develop

Readable source code

The history of Setup Foundry goes back to 1995. That year, under Windows NT 3.51, the first tool was written in KiXtart. With Windows NT 4 came the first fully automated installation. We have developed in Python since 2013, and today's codebase dates from 2020.

A small tombstone in the source code still recalls those beginnings. A dedicated test makes sure it stays there.

In development we make sure the code remains understandable and traceable. We want to be able to understand, ten or twenty years from now, why something was done the way it was, and to change it when needed.

How we use AI

The technical core of Setup Foundry grew out of our own work over many years. It includes the database, logging, settings and numerous smaller tools. Their line goes back to 1995.

We have since developed a large part of today's code together with AI. In doing so we build on our existing components and our own programming style. We understand the code, develop it further ourselves and check every version before it is released.

We do not practise vibe coding. Having code generated without then understanding what it does is out of the question for us.

We also develop the systems around Setup Foundry ourselves. These include the website, the customer account, the licence server and telemetry. For them we use programming languages and technologies we have worked with for years. AI supports us in development, helps with technical details and takes on part of the documentation work.

How we test

For version 0.9.8.12 we ran a total of 18,321 automated tests. All of them passed.

In the interface tests, windows, wizards and controls are opened automatically and checked for correct function.

We then test the actual Windows installation in virtual machines. Setup Foundry installs a complete Windows system there, and we check its state afterwards with numerous individual checks. For version 0.9.8.12 that was 736 checks per machine.

We test Windows Home and Windows Pro in parallel. We also test with different Windows revisions and with Windows updates.

We also install every new version ourselves, both in virtual machines and on real hardware. We then work with the program and check that everything functions in normal use.

From change to release

Before a new version is released, it goes through a fixed sequence of nine steps. Every step must complete successfully. If an error occurs, the process is aborted. Only when all checks have passed can the version be released.

1. 1Lint, the automatic style check
2. 2Tests
3. 3Translation of the source code into C
4. 4Building the Windows programs
5. 5Installer
6. 6Signing with the certificate of Steidl IT GmbH
7. 7Writing and proofreading the README
8. 8Testing the installer
9. 9Release

How we work with AI

We work with AI somewhat differently from what the usual best practices recommend. Our sessions often stay alive for a long time. We do not treat the AI simply as a tool but as part of our team. Instead of only giving instructions, we discuss problems, debate suggestions and look for solutions together.

Over time a sense of team grows out of this. The AI knows the history of the project, understands many of our decisions and increasingly questions them as well. Not rarely this produces suggestions we would not have come up with ourselves. Sometimes the AI also shows us that code that has grown over the years is long since no longer the best way.

For us this is an enormous learning process. Almost every day we discover new possibilities, learn other approaches and question old habits. This now changes our own work as well. Our programming style keeps developing, and with it the whole codebase changes step by step. It becomes more modern, more efficient and in many places more stable.

In doing so we learn not only how to use AI better. Above all we learn to develop better software ourselves.

You will find part of what we have learned in our skill and role library on special.at. An MCP server is ready, even without an assignment; ask your agent.