AI-assisted development
Transparency and community trust are fundamental to the flight simulation hobby. Given the current discussions surrounding the use of artificial intelligence in software development, and understandable concerns about poorly constructed, rushed applications - this page provides an honest, open look at exactly how the MSFS Livery Toolkit was built, what role AI played, and how human oversight shaped the final product.
- Why this tool exists
- Human-driven architecture vs. “vibe coding”
- A note on modern software development
- Our shared goal
- Help keep the development lights on
Why this tool exists
The MSFS Livery Toolkit was created to solve a universal frustration for livery painters. While laying out designs, aligning panel lines, and crafting realistic weathering is deeply rewarding, wrestling with nested folder structures, texture.cfg fallback chains, and strict SDK syntax is a repetitive, time-consuming chore. This utility exists entirely to automate those back-end logistics so creators can focus on the creative side of painting.
The reality of this project is straightforward: without AI assistance, this tool would not exist. The alternative to an AI-assisted development workflow wasn’t a hand-coded application; it was no application at all. Building a fully realized Windows desktop application with complex configuration management, automated file-structure branching, and deep user-interface handling requires software engineering capabilities far beyond a hobbyist like me - my previous ImageToMSFSKTX2 script (a small local batch-file utility) was about as far as I could take things with my coding skills. Leveraging advanced Large Language Models (LLMs) made it possible to build a complex, dedicated utility from scratch during personal spare time and release it completely free to the community.
Human-driven architecture vs. “vibe coding”
There is a significant difference between an application generated by a single-sentence prompt and software systematically engineered using AI assistance. While an AI model generated the code syntax, human intent, domain knowledge, and oversight drove every single step of the process.
The development pipeline
- Strict specifications: Before a single line of code was generated, a comprehensive structural blueprint and logical workspace workflow were written out using Claude Opus. Every behavioral decision - how the tool handles Microsoft Flight Simulator 2020 versus 2024 aircraft, how it branches between monolithic and modular frameworks, and how texture flags are parsed - originated entirely from hands-on livery creation experience.
- Milestone-driven checkpoints: The application was not built in a single, massive automated pass. Development was carried out in VSCode using the Claude Code extension; it was split into rigid milestones, architecture reviews, and iterative code checkpoints. Every phase was audited, tested, and approved by me before advancing.
- Solving simulation anomalies: AI models do not innately understand the undocumented quirks of third-party flight-sim add-ons. Complex, simulator-specific problems — such as multi-hop texture fallback chains and irregular asset folder structures — were solved by analyzing real-world example liveries and matching them against official SDK documentation. Where a technical outcome couldn’t be verified automatically, development stopped until it could be validated manually, rather than allowing the AI to guess or gloss over code logic.
- Professional standards: The development framework used to build this utility mirrors the strict specification, verification, and project management guidelines used daily within professional software R&D environments. It is a considered, step-by-step piece of software built to solve a concrete problem.
A note on modern software development
AI-assisted engineering has seamlessly integrated into the wider software industry. A significant portion of professional, enterprise-grade tools used daily across various industries are written, optimized, or debugged with some form of AI assistance - even if it isn’t explicitly stated on the packaging. Providing complete transparency regarding the development process is a choice of integrity, rather than pretending the code was assembled purely from scratch.
Our shared goal
Ultimately, the value of the MSFS Livery Toolkit is determined by its performance in your hands. If it saves you time, prevents broken .json or .cfg files, and gets your livery creations published sooner, then it has done its job successfully.
Because there is a real person behind every single design decision, project milestone, and line of documentation, your feedback is incredibly valuable. If you run into an unexpected edge case, encounter a bug, find something confusing, or have ideas for new features, please get in touch so I can continue to improve it for everyone. You can reach me at theflaknine@gmail.com, or open an issue.
Help keep the development lights on
I’ve funded this project out of my own pocket with a Claude Pro subscription. I will never monetize this application or offer a premium tier - I’m developing it as a perpetually free tool for the livery painting community. However, to keep enhancing and developing it, I would be grateful for any donations via my Buy Me a Coffee page.
See also: Trust & safety for how the app handles your files, why it’s unsigned, and what ooz.exe is.