AI-assisted programming: faster, but not without expertise and quality assurance

AI and Machine Learning

The AI assistant writes the skeleton of an AutoCAD add-in in seconds. It looks convincing – and calls a method that does not exist in the API. Or it compiles without errors and uses a class that throws an exception at runtime under .NET 10. AI noticeably speeds up programming. But whether the result is any good is still decided by someone who understands the subject.

What is shifting

Ebi F. Eilber, managing director of Cadida with more than 25 years in CAD development, puts it in a nutshell: AI is increasingly taking over the programming. That makes creativity, expertise, product understanding, innovation and quality assurance all the more important.

• Creativity: Which solution is the right one? AI answers the question you ask – not the one you should have asked.
• Expertise: How does a block reference behave, what does a standard require, how noisy is a sensor? Without this knowledge, a plausible error goes unnoticed.
• Product understanding: What does the user really need, and what must never happen?
• Innovation: New things come from experience and ideas, not from the average of known examples.
• Quality assurance: If code is written faster, it also has to be checked faster and more thoroughly.

Where AI helps today

AI is well suited for skeletons and repetitive code, for transforming existing programs – during a port, for example –, for test cases that would otherwise be skipped for lack of time, and for explaining unfamiliar code. The more widespread a technology, the better the AI knows it. With specialised APIs such as AutoCAD, Revit or FeatureCAM, with device drivers and across version changes, it becomes less reliable – and still sounds just as confident.

Where it gets it wrong

A well-studied example is invented packages. For a study presented at USENIX Security 2025, 16 language models generated 576,000 code samples. On average, at least 5.2% of the recommended packages from commercial models and 21.7% from openly available models did not exist. That is more than a nuisance: attackers can register such names and publish malicious code under them.

A second example is our own perception. In a randomised study by METR in 2025, 16 experienced open-source developers took 19% longer on average to complete their tasks with AI tools – and afterwards estimated they had been 20% faster. METR itself points out that the tools have evolved since then and the result must not be generalised. The lesson remains: measure, don't guess.

Quality assurance for AI code

• Review it like a new colleague's work: every change is read by someone who is responsible for the code.
• Tests first: acceptance criteria and test cases define what is correct – not the assistant.
• Check automatically: unit and UI tests, static analysis and security checks run with every build.
• Confidentiality: customer code and trade secrets only go into AI services whose contract and data processing have been clarified.
• Approve dependencies: new packages only enter the project after review. A small script in the build stops anything that has not been approved:

import re
import sys


def package_names(path):
    """Reads the package names from a requirements file, normalised per PEP 503."""
    names = set()
    with open(path, encoding="utf-8") as file:
        for line in file:
            line = line.split("#")[0].strip()
            if line and not line.startswith("-"):
                name = re.split(r"[\s\[<>=!~;@]", line, maxsplit=1)[0]
                names.add(re.sub(r"[-_.]+", "-", name).lower())
    return names


new = package_names("requirements.txt") - package_names("approved.txt")
for name in sorted(new):
    print("Not approved:", name)
sys.exit(1 if new else 0)

What counts is approval, not the mere existence of a package. An invented name may long since have been registered by an attacker. And responsibility stays where it was: the Cyber Resilience Act does not ask whether a human or an AI wrote the code. The manufacturer answers for the security of the product.

Typical mistakes

• Accepting AI code because it compiles.
• Not checking suggestions for specialised APIs against the documentation of the version in use.
• Installing packages the assistant suggests without checking them.
• Having the AI write the tests as well and only making sure they are green.
• Estimating the time saved instead of measuring it.
• Letting junior developers do nothing but write prompts. Without expertise, they don't spot the errors.

Sources: J. Spracklen et al., “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”, USENIX Security 2025; METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, July 2025; assessment: Ebi F. Eilber, managing director of Cadida Software GmbH.