bbv KI Webinar - AI as Development Partner

On 23 April 2025 bbv held another episode of its webinar series on artificial intelligence, this time with a focus on software development. I moderate the session and guide participants through practical insights from the BBV AI Hub. Together with my colleagues Thomas Mannhart, Michèle Fundneider, Noah Hermann and Joel Barmettler we examine how AI is used along the development process, from requirements analysis and coding through to testing, reviews and architecture decisions. The goal is a sober, application-oriented look at which methods and working practices prove their worth in daily use and where deliberate context and quality management remains decisive.

AI in the Development Process: Practical Experiences from the BBV AI Hub

AI has arrived in the everyday life of software development. In the BBV AI Hub it is particularly clear how strongly working methods change when language models not only answer individual questions but participate in structuring, formulating, reviewing and understanding development artefacts. The goal here is not a tool comparison but a practical look at the methods and strategies that prove themselves in the development process, from requirements analysis and code development through to testing and review. The content is aimed at technically experienced people who already know software development processes, whether they are just starting with AI or already have experience.

"Our goal today is to provide practical insights into the possibilities and challenges of integrating AI into the development process."

In the webinar several roles from the team have their say in order to make different perspectives visible: condensing requirements from workshops, using AI productively for coding, getting up to speed faster in new codebases and concepts, and as an architect maintaining an overview of tools, frameworks and system decisions. One thread runs through all contributions: AI delivers the greatest benefit where context is managed cleanly and results remain verifiable.

From Workshop Results to Requirements: Making Unstructured Data Quickly Usable

Workshops often produce many artefacts: notes, sketches, post-its, flip charts, mockups. The bottleneck lies less in a lack of information than in its preparation: what was decided, how can it be played back in a structured way to the team and client, and how do actionable requirements emerge from it? Thomas describes a workflow that provides significant relief here.

One important step is capturing content directly after the workshop via speech-to-text. Instead of later laboriously reconstructing from memory, a rough draft is created early, deliberately unstructured but complete. This draft is then brought into a structured form by assistants, for example as epics and requirements including acceptance criteria. Additionally, photos of post-its or flip charts can serve as context: models extract content from images, cluster it and deliver summaries that in turn can be used for requirements, project logs or documentation.

"I just dictate everything that comes to mind about this workshop, and so I have it stored in an unstructured form for the first time."

A realistic view is part of reliability: for smaller, clearly bounded features the automatic creation works particularly well; with larger scope, the need for post-editing increases. A practical bonus is that AI does not only "generate" but also helps with reviewing: suggestions for non-functional requirements, notes on gaps, contradictions or overly vague formulations.

"Hey, do you notice anything else? Is something contradictory? Is something too vague?"

AI in Coding: Choosing Context Deliberately Rather Than "Throwing Everything In"

Michelle uses AI broadly in engineering daily life: generating code, refactoring, writing tests, validating ideas, both through IDE-proximate tools (for example Copilot) and through chat interfaces. The biggest challenge is less the model itself than context management. Two extremes recur constantly: too much context (unspecific, unclear where statements come from) and too little context (generic suggestions that do not match guidelines, language or architecture).

The workable solution is deliberate, often manual context management: selecting relevant code sections specifically, formulating goals and boundary conditions clearly, providing examples and consistently starting fresh chats when topics change. It is also worthwhile bundling recurring project information in specialised assistants (guidelines, output formats, typical constraints) to avoid starting from scratch with every task.

"Clarity over data flood: better less, but cleanly explained context."

Web search in AI tools is also used selectively: disabled by default to keep context controllable, and only enabled when currency is genuinely needed (for example library bugs, new releases). This follows the same principle: open context deliberately, not expand it randomly.

Onboarding, Learning and Reviews: AI as Navigator and Pre-Check

From a junior perspective (Noah), AI is particularly helpful when getting to grips with large codebases. When you do not yet know where something is implemented, AI can help map abstract questions ("how do we handle persistence?") to concrete places in the code. This creates orientation faster without constantly blocking the team.

For new concepts not directly present in the codebase, a second technique helps: telling the AI how you want to learn. Noah uses the metaphor of a knowledge tree (fundamentals, core concepts, details) and controls the pace explicitly: only move on when the current concept is truly understood. The result is a dialogic learning process rather than an overloaded "everything at once" text.

"Only move on to the next concept when I really say I have understood it."

AI is also used as a pre-review: pull requests can be automatically summarised and checked for anomalies (for example potential security issues). This does not replace a human review but helps with triage and preparation, for instance to see early how large a PR is and where the risky parts lie.

Architecture and Tool Landscape: From the Big Picture to Implementation

As an AI architect, Joel works heavily at the start of client projects: requirements, infrastructure, data protection, model selection and the question of which problems should actually be solved with AI. At the same time the platform perspective must consider which tools and standards will be "relevant in six months". To handle information overflows, deep research workflows help. What is decisive here is source control. Rather than broad web searches, trustworthy sources are preferred (papers, GitHub, selected communities) to reduce the risk of misinformation.

After the pre-selection comes the deep dive: new open-source projects are often poorly documented, so AI is particularly helpful for navigating codebases and finding relevant implementation points. For system questions a very large context window can be useful (for example a condensed codebase to identify sensible integration points). For the actual coding, context is then reduced again so that precise changes remain possible. The switch between "lots of context for overview" and "little context for implementation" is a deliberate pattern here.

"At every stage I use different tools, from the overview to the specific implementation."

Models, Benchmarks and Data Protection: Pragmatic Guardrails

When comparing models, benchmarks and leaderboards help, but they are not infallible: models can be optimised for benchmarks. Blind tests with user evaluations are more robust but less specific. In practice a mixture works well: rough classification via leaderboards, then cross-checking with coding or reasoning benchmarks, and finally a personal comparison with typical everyday tasks (the same question to multiple models). Data protection remains a framework that co-determines tool selection and hosting options, especially in client projects.