AI in Development and Engineering: Code, Documentation, and the Knowledge That Lives in People’s Heads

In development departments, design offices, and technical service teams, attitudes toward AI are usually split in two. One group has long since adopted it and wouldn’t want to do without it. The other group considers it overrated, because the results don’t hold up on demanding tasks.

Both are right – they’re just talking about different tasks. It’s worth sorting out more precisely where the real benefit lies.

Programming: useful, but not where you’d expect

A simple rule applies to code generation: the more familiar the pattern, the better the result. A data access call, a conversion, a test case, a script for parsing a log file – this succeeds reliably and saves real time.

The more specific the task, the weaker the support gets. With legacy business logic, with concurrency, with changes to a large codebase whose dependencies are only partially visible, suggestions emerge that look plausible and are subtly wrong. These are exactly the errors that are expensive, because they slip through review.

Where the benefit, by contrast, is rarely disputed:

• Understanding someone else’s code. Having a function that someone else wrote years ago explained to you is one of the most rewarding applications there is.
• Writing tests. Unloved, easy to automate, and the result is immediately verifiable.
• Interpreting error messages. Reading stack traces and log excerpts and offering hypotheses about the cause.
• Translations between languages and formats. Configurations, queries, data structures.
• Code review as a second pair of eyes. Not as a replacement for review by colleagues, but as a preliminary pass that catches the obvious.

What matters is how you treat source code as a trade secret. Whatever is entered into a tool leaves the building – with free services, with unclear consequences. For development departments, this is one of the strongest arguments for an approved, contractually secured solution.

Technical documentation: the underrated case

Documentation is chronically out of date in almost every technical field, because it’s always the task that gets postponed. This is exactly where there’s a lever that carries little risk.

A first draft of documentation can be generated from a change log, a ticket history, or meeting notes, which an expert then corrects. The difference between „writing from scratch“ and „correcting a draft“ is, in practice, what decides whether it happens at all.

Equally effective: deriving a version for other audiences from existing technical documentation – a quick-start guide for users, an overview for sales, a checklist for service. The substance has already been reviewed; it’s purely a matter of repackaging.

Preserving experiential knowledge

The most valuable use case in technical fields has nothing to do with code at all.

In every company there are people who have known a piece of equipment, a product, or a system for twenty years. They know why a design looks the way it does, which fault is typical for which customer installation, and which solution was rejected back then. None of this knowledge is in any manual. It disappears when they leave – and in the coming years, many will.

An assistant connected to tickets, service reports, design documents, and project files makes part of this accessible. Not the gut feeling, but the documented events: „Have we ever seen this fault pattern before on equipment type X?“ is a question whose answer today depends on the memory of individual colleagues.

For this to work, an uncomfortable topic has to be tackled: service reports and ticket histories are often terse and inconsistent. The effort lies not in the technology, but in raising documentation quality to the point where it can actually be analyzed.

Design and manufacturing

A sober view is warranted here. Language models don’t design components and don’t calculate strength values. What they can do concerns the surrounding work:

• Make standards, guidelines, and internal specifications searchable and provide source references.
• Compare bills of materials and data sheets and flag discrepancies.
• Match inquiries against earlier projects: what similar thing have we already built?
• Prepare test and acceptance protocols from existing data.
• Check supplier documentation for completeness.

All of this is supporting work. Technical responsibility remains entirely with the engineer – and where products fall into regulated areas, it’s also worth noting that AI embedded in products falls under Annex I of the EU AI Act, with full requirements applying from August 2028.

What technical teams need for it to be adopted

Technical experts are especially skeptical of tools that deliver imprecise results – rightly so. Three things determine acceptance.

Source references. An answer without a source is worthless to an engineer. With a source, it becomes verifiable and therefore usable.

Honest limits. A system that answers „That isn’t in the connected documents“ earns more trust than one that always produces something.

No compulsion. Rollout should happen as an offer. Those who see good results use it; those who don’t, don’t. Mandated tools are reliably undermined in technical teams.

Getting started

Don’t start with code generation, but with search over your own existing material. Choose a defined scope – say, the service reports from the last three years for one product family – and let the team spend a week asking it real questions.

The feedback from that week tells you more about the value for your company than any product demo – and it also reveals how good your documentation actually is.

How technical teams should evaluate the benefit

Experts aren’t won over by a demo, but by a test on their own cases. A lean approach that has proven effective:

Choose a defined body of material – say, three years of service reports for one product family. Collect twenty questions that actually come up day to day, whose correct answer an experienced colleague knows. Let the team work with it for a week and note where the answers held up and where they didn’t.

Then evaluate not just the hit rate, but also the causes of the misses. Experience shows that a large share of them come down to documentation quality – terse reports, inconsistent terminology, no clear marking of the valid version. That’s an uncomfortable but useful insight: it holds true regardless of the tool.

Handling source code and design data

For technical departments, how you handle your own trade secrets is the most important framework condition. Define three points: which codebases and documents may be entered into an AI tool at all, which tool is approved for that, and how libraries and licenses are handled when generated code gets adopted.

The last point is often overlooked: adopted code should go through the same review steps as any other contribution – review, tests, license check.

Frequently asked questions

Will younger colleagues lose their programming skills because of this?

That concern should be taken seriously. In practice, a simple rule helps: generated code isn’t adopted unless the person can explain it. That preserves the learning effect and also prevents code nobody understands from entering the codebase.

Can we run this on-premises?

For especially sensitive material, running it in your own data center is possible. Factor in the operational overhead – hardware, updates, availability – and honestly assess whether you want to carry that long-term.

What does it get us with highly specialized business logic?

Not much for generation. For understanding, documenting, and testing, on the other hand, a lot – and that’s exactly where the bigger time loss usually sits in legacy codebases.

Does AI in our products fall under the AI Act?

If your product is already subject to product regulation and has AI built into it, Annex I applies, with full requirements from August 2028. Clarify this early, because it affects design and documentation, not just the software.

Systematically catching up on documentation

In most technical fields, documentation isn’t outdated because nobody thinks it matters, but because it’s always the task that gets postponed. A pragmatic approach that doesn’t require an extra headcount:

Don’t try to catch up on everything retroactively. Trying to work off a three-year backlog reliably fails. Start with the present instead: every change from today onward generates a documentation draft.

Generate from existing traces. Change logs, ticket histories, meeting notes, and commit messages already contain the facts. Turning them into a structured draft is a reformatting task – exactly what language models are good at.

Have it corrected, not written from scratch. The difference in effort between „writing from scratch“ and „correcting a draft“ is the reason this actually happens this time.

Retroactively, only what’s actually needed. If a question about an old component comes up three times, that’s the trigger to catch up its documentation – not a plan that covers everything.

Preserving knowledge before people leave

The economically most valuable use case in technical fields has a deadline: it only works while the colleagues with the experiential knowledge are still around.

An approach that has proven effective consists of three building blocks. First, structured conversations: One to two hours of conversation per subject area, recorded and transcribed. Not as free-form storytelling, but guided by concrete questions – which faults typically occur with this type of equipment, why this design was chosen, which solution was rejected back then and why.

Second, connecting the existing traces: Service reports, tickets, project files. The transcript alone helps little; it becomes valuable in combination with the documented events.

Third, review by the same person: As long as the experienced colleague is still around, they can judge whether the system’s answers hold up. This review phase is the real knowledge transfer – and it turns a technology perceived as a threat into an enhancement of their own role.

Anyone who only starts once the resignation letter is on the table has already lost the greater part of it.

A word on documentation quality

An uncomfortable piece of feedback that almost every technical team takes away from the first test: a substantial share of the poor answers isn’t down to the system, but to terse, inconsistent service reports. „Customer called, problem fixed“ is a note to a human being and worthless for any analysis.

That’s annoying and, at the same time, the most useful insight of the project, because it holds true regardless of the tool. A handful of mandatory fields in the report form – symptom, cause, action taken, parts used – fundamentally transforms how analyzable it is within a few months.