NTU Singapore Researchers Cut Decision-Software Development From Months to an Hour

A team at Nanyang Technological University in Singapore (NTU Singapore) has unveiled an AI framework that automatically builds complex decision-making software. According to the researchers, developing such a system used to take months of work by narrow specialists. Now it takes about an hour. If the figure holds up in practice, that is a reduction of two orders of magnitude.

What is known about the project

The published description contains few details, and that is worth stating up front. It indicates that the framework takes over a task usually handled by a domain expert working with an engineer: turning a problem statement into a working program that chooses actions under given constraints and goals. Classic examples of such software include route planning, scheduling, resource allocation, and inventory management. The announcement does not say which of these the framework covers.

Key facts that can be considered established:

• Developer: NTU Singapore.
• What is automated: building complex decision-making software.
• Previous timeline: months of specialized engineering work.
• Claimed timeline with the framework: about one hour.
• System type: AI framework. Whether a large language model sits underneath is unknown.

Why these systems take months to build

The bottleneck is not writing code as such. A decision program first has to be formalized: you define the variables, constraints, and objective function, then pick a suitable algorithm, tune it, and test it on real data. Every step requires people who understand both the business problem and the underlying mathematics. There are few such people, and iterations with the client stretch out the project.

If the framework really does take over formalization and solver selection, the savings come not from lines of code but from the cycle of approvals. That is why the claimed one-hour timeline looks bold: it is not yet clear whether it includes validating the result or only generating a first version.

What the announcement leaves out

The figure of "about an hour" says little without context. Several questions that determine the value of the work remain unanswered:

• On which tasks, and how many, the measurements were run.
• Whether the output was compared with a human-written solution in terms of quality and cost of the solutions found.
• How much manual preparation the input requires: a natural-language task description, a formal specification, or ready-made data.
• How the system behaves with non-standard constraints and how it detects its own errors.
• Whether the code is available, and in what form the work will be published.

Until a paper or preprint with this data appears, the result should be treated with caution. Automatically generated decision software most often fails on non-obvious constraints: the model produces a program that runs and looks convincing but violates a rule nobody stated out loud.

What to check before adoption

For companies with their own planning and optimization problems, the practical sequence is as follows. First, take one problem that has already been solved and has a known reference result, and compare the automatically built solution against it. Next, test how the tool reacts to changing conditions: add a new constraint and see whether it requires a rebuild from scratch. Finally, work out who will check the outputs. If the answer is "nobody," an hour of development becomes a risk rather than a saving.

Watch for the publication of NTU Singapore's full paper. It should include benchmarks, the limitations of the approach, and access terms. Those will show whether development time dropped for all tasks or only for convenient demo cases.