Published 22/07/2026 By nAG
An organisation may have a perfectly stable and valuable application yet find that its future is constrained because it can only be built using a particular vendor’s tools, operating system or a collection of scripts understood by a small number of developers.
The development team may want to introduce more comprehensive testing, run builds in the cloud or adopt modern CI/CD practices, only to discover that the build environment has become a barrier. Before modernising how the software is developed and tested, the organisation must untangle years of dependency on its existing toolchain.
Modern software quality tools such as memory sanitisation, static analysis and fuzz testing can identify issues that conventional testing may miss, while testing with multiple compilers can reveal different types of potential problems. Ideally, these checks should run regularly within a CI/CD environment, using on-premises or cloud servers to provide the resources required for complex builds.
Linux environments are readily available from major cloud providers, while technologies such as Docker make builds easier to reproduce and are widely used by platforms including GitHub Actions and GitLab. However, established codebases can be closely coupled to build systems or frameworks such as Arm Keil, Qt or Microsoft Visual Studio projects, creating vendor lock-in and, in some cases, a dependency on Windows-based environments that can be harder to deploy and manage within automated infrastructure. The reverse can also be true, the build system might work perfectly well on Linux but struggle when the need arises to build on other platforms (Windows, MacOS), due to customer demand.
Moving to a platform-independent build system, such as CMake, may appear to be the obvious solution, but it can involve interpreting and reproducing hundreds or thousands of accumulated rules covering compiler options, dependencies, platform-specific behaviour, testing and packaging. Some of this knowledge will be documented, while other parts may exist only within scripts written many years ago, making manual migration time-consuming and potentially risky. For complex systems a full build system migration can easily be a multi month project. If the original authors are not around anymore a migration might also pose risk, due to missed side-effects of legacy scripts.
AI coding agents can reduce this burden by analysing project files and scripts, identifying dependencies and platform-specific assumptions, generating equivalent configurations for a more portable build system and comparing the outputs produced by the old and new environments. Where the original system cannot immediately be retired, it can continue to act as the ground truth while an agent helps keep the replacement aligned with it.
Experienced software engineers must still define the migration approach, validate generated configurations and investigate any differences, but AI can accelerate the repetitive elements of the work so that engineers can concentrate on the decisions and verification requiring deeper technical judgement. A quick one-off prototype might also convince stakeholders that modernising is worthwhile (“There is no glory in prevention”), because the benefits of modern tooling become visible on production codebases.
nAG has encountered this challenge within its own development infrastructure, where the build system was historically based on Makefiles and shell scripts that did not transfer easily to Windows. Supporting these systems required workarounds such as Cygwin ports of shells and Linux utilities, which became increasingly difficult to maintain.
To create a more platform-independent environment, nAG began migrating Shell scripts to Python, which natively manages operating-system differences such as path handling. Further, Makefiles and custom scripting contained within them were transferred to CMake, which supports platform-independent operations, improved build parallelism and integration with testing tools such as CTest. Although this work initially relied on manual rewriting, AI coding agents can now help similar projects progress more quickly, particularly during the demanding early stages of analysing and translating existing build logic.
The objective is not necessarily to abandon an established toolchain or rewrite valuable software simply because its development environment has become restrictive, but to give the organisation more options. A platform-independent build system can make it easier to use cloud resources, strengthen software testing and adopt modern CI/CD practices while reducing dependence on a particular vendor, operating system or small group of specialists.
If your build environment is limiting how you test, deploy or modernise important software, we can help you assess the existing system and explore where AI-assisted migration could reduce the effort and risk involved. Do get in touch if you are experiencing these issues. We’d love to hear from you.