Experts point out that having AI write a lot of code will cause inspection costs to explode, highlighting the importance of reducing the amount of code generated.

Deepak Anupari, co-founder and CTO of AI app development company WaveMaker, wrote an article for the IT media outlet InfoWorld on the problem of AI-generated code, stating that we should consider not only 'how to inspect it' but also 'how to reduce the amount of code generated in the first place.'
How to stop the AI code generation treadmill | InfoWorld

Using AI-powered code generation tools allows you to quickly create templates for forms, data tables, and API integrations. While convenient for developing prototypes and internal tools, the burden of reviewing, correcting, and maintaining the code increases as the volume of generated code grows.
AI-assisted code is becoming widespread in development environments. (PDF file) According to Sonar's 2026 Developer Survey , 42% of committed code will be AI-assisted, and about 29% of that will be merged without manual human review. While the speed of writing code is increasing, the risk of quality control not keeping pace is also growing.
A common measure to maintain the quality of AI-generated code is to 'inspect the generated code afterward.' Specifically, this involves using static analysis, lintering, security scans, accessibility checks, and screen display comparison tests to find problematic areas.
However, these post-generation checks are mechanisms for finding problems after the code has been created. While this might work for a single app, the workload for checking and correcting increases significantly when the number of internal apps grows to dozens. Instead of speeding up development with AI, the verification process ends up consuming more of the developers' time.

Anupari proposes an 'AI assembly model.' Instead of having the AI write the entire code from scratch each time, it selects verified components and only performs the necessary settings. For example, in response to the instruction 'I want to create a searchable customer list,' the idea is that the AI would use an existing table in the company's component library rather than generating a new table.
A component library is a storage location for building components such as buttons, input forms, lists, and authentication screens. By reusing components that have been pre-validated for security, display, and accessibility, you can reduce the need to repeat the same tests for each application.
In the AI assembly model, existing components are used to cover parts that do not need to be generated. Next, only the essential parts such as property settings, data connections, and screen transitions are handled by the AI. Only special business logic and external service integrations that cannot be handled by existing components are newly generated.

The same principles apply to the backend, where design flaws can easily lead to major problems, including data storage, APIs, authentication, and access control. Anupari explains that sensitive information management, role-based access control, typed API contracts, and standards-based security validation should be incorporated into the structure.
In AI assembly models, additional tokens are needed for prompts and contextual information to help the AI understand the company's design rules and component libraries. While this may seem to incur additional costs, considering the cumulative costs of fixing, regenerating, security checking, and display verification when generating and checking large amounts of code each time, AI assembly models tend to be more cost-effective overall. Furthermore, reducing the amount of code to be checked lowers the risk of critical bugs slipping through the inspection process.
Furthermore, regulated industries such as finance, healthcare, and government require the ability to explain that an app meets the standards. Traditional methods involve explaining that 'the entire generated code was inspected,' which becomes increasingly burdensome as development progresses. In contrast, AI assembly models allow for explanations such as 'verified components were used, and only the independently generated parts were additionally checked,' thus reducing the burden.
Anupari points out that discussions about AI-generated code are too focused on 'how to inspect it.' He concludes by stating that the idea of 'generate more and inspect more' will cause verification tools to be unable to keep up with the ever-increasing volume of code, and that it is important to 'identify the parts that do not need to be generated and generate only the parts that are necessary.'
Related Posts:







