SATISFACTORYBASE

Our tools. Our responsibility.

Built with love. And AI.

And we are proud to use it.

AI has helped create many parts of SatisfactoryBase: code, interfaces, images, text and tests. We use these tools deliberately and talk about them openly. They are part of how this project is built, and we see no reason to hide that.

How we build

Judge the work by what it does.

We do not understand why using AI should, by itself, make a project less worthy of attention, support or cooperation. A useful tool does not become useless when someone learns how it was built. The questions we want to answer are concrete: Does the calculation hold up? Can you understand the interface? Does the application respect your choices? Does the team fix its mistakes?

That applies to conversations with players as much as to potential partners. You do not have to like AI or use it yourself to try SatisfactoryBase. We ask for the same fair look at the result that any other project deserves. Dismissing the work with a label tells us little about what we should improve. A specific criticism gives us something to work on.

Where AI helps

More than autocomplete.

Our use of AI reaches across development. A suggestion may become part of the project, change through several revisions or be discarded. We do not treat everything a model produces as ready to publish.

Code & architecture

AI helps explore implementations, connect existing systems and investigate failures. It can propose a component or explain a difficult code path. The team still has to specify the behavior, understand the dependencies and decide whether the change belongs in the application. A successful build alone does not prove that a factory calculation is correct.

Design & images

We use AI to explore layouts, visual ideas and image variants. Choosing a direction, correcting an awkward composition and making it work on a phone still require attention. The project also contains game assets, ordinary interface code and hand-built graphics. Using AI does not mean every image here was generated by a model.

Writing & languages

AI helps structure explanations, draft text and translate between German and English. We work on the meaning, terminology and tone, and compare claims with the available sources. A fluent paragraph can still explain a game mechanic incorrectly. When evidence is limited, rewriting it more confidently does not solve the problem.

Game data & reference

The source for game values is the game export and the documented references. AI can help build the tools that read, transform and present that data. It is not a substitute for the source. Recipes, machine properties and resource rules need traceable inputs, and differences between our planning model and the game need to remain visible.

Tests & debugging

AI helps reproduce bugs, suggest test cases and inspect changes. We still need examples from actual use, sensible expectations and someone who asks whether a test checks the right thing. A passing test can protect a useful rule, or just repeat a mistaken assumption. Reports from players are an important check against our own view of the application.

Ideas & decisions

An assistant can list alternatives and help us see trade-offs. It does not know automatically which inconvenience matters most to a player or which promise we should make. Priorities, compromises and the decision to release or wait stay with the team. Saying “the AI suggested it” is not an answer to someone whose plan no longer works.

The work behind the prompt

The team still has a job to do.

The short instruction an assistant receives is only one part of the work. Before it come observations, discussions and decisions. Afterwards come reading, trying, checking and often another round. That work is spread across the people building this project.

Marco Foof

Development & Project Lead

Marco brings project direction and development together: deciding what the product should do, choosing priorities and carrying ideas through to implementation. Keeping the project moving also means deciding what to leave out and when something needs another pass.

Carlos Ziegler

Development & Architecture

Carlos works on development and architecture: how the pieces fit, what a change affects and whether a solution will remain understandable. An assistant can propose a local fix; fitting it into worlds, factories, permissions and existing behavior takes a view of the whole application.

Sam Ueberle

Game Data & Testing

Sam focuses on game data and testing: comparing what the tools calculate with what the available game data supports, trying different cases and following up on inconsistencies. A believable number is not enough. Inputs, recipes and assumptions have to match the question being asked.

Alexander Zink

Design & Experience

Alexander works on design and experience: what a player sees first, how a complicated control becomes understandable and whether the interface holds together across screens. Generating a layout is one step. Turning it into an interface people can actually use means choosing, refining and trying it again.

An idea is the beginning of a loop.

Define

Start with the player’s problem, the desired behavior and the constraints. A vague goal leaves room for a convincing answer to the wrong question.

Build

Use AI and existing tools to explore an implementation. Read the result, compare alternatives and adapt it to the project.

Check

Run relevant tests and try the actual interface. Check the awkward cases, the language variants and the smaller screen, not just the happy path.

Own it

Decide whether to release, listen to feedback and fix what fails. The team remains the contact when something is wrong.

A direct conversation about AI.

Does AI use make criticism unwelcome?

No. Concerns about training data, rights, attribution, privacy, energy use and the quality of generated work deserve a serious conversation. Our position is narrower: the label “made with AI” is not, by itself, a review of this project. Show us a wrong calculation, an unclear explanation or a concrete concern about an asset, and we have something we can examine and address.

Is this a claim that everything is checked perfectly?

No. SatisfactoryBase is in beta, and both people and models make mistakes. Tests and reviews reduce uncertainty; they do not erase it. We would rather describe a known limitation than promise that nothing can go wrong. Using AI openly also means being honest when an output was wrong and needs to be replaced.

Does using the site require AI?

No. Planning a factory, using Calc or reading a Guide does not require you to connect an assistant. AI-assisted development and optional AI features in the product are different things. The MCP connection has its own explicit account and world permissions and is currently being tested before general availability.

What do you expect from partners and the community?

A conversation about the actual work. Tell us which standards matter to you, where information is missing and what would make cooperation useful. We can disagree about a tool and still talk respectfully about the project. We will not pretend AI played no part just to make the story easier to accept.

What about the people whose work this builds on?

They matter. SatisfactoryBase depends on Satisfactory, its game data, open-source libraries and community knowledge. Using AI does not replace attribution or make somebody else’s work ours. We maintain a separate credits page for the tools and sources behind the application. The NPC profiles name our AI tools; they do not imply that their providers sponsor or endorse this project.

Our tools. Our responsibility.

We build it. We stand behind it.

We are proud of what this team is making and open about the tools it uses. Try the result, tell us what can be better and meet the people responsible for it.