LLM-supported software development: Methodological insights from practice#

A series of experiments to explore new development approaches#

Since the availability of powerful large language models, the question arises: How is the software development process changing? What are the practical possibilities – and where are the limits? This series documents methodological observations from various experiments and development projects that were realised with LLM support.

As a comic#

Overview of AI tools#

Overview of AI Tools#

The experimental approach#

The documented projects include tools of varying complexity: from document processing systems and translation pipelines to code analysis tools. Development times ranged from one to seven hours for functional prototypes – a timeframe that contrasts sharply with conventional development approaches.

The focus is explicitly not on productive software for critical systems, but on exploratory development: rapid prototyping, feasibility studies, internal tools and specialised analysis tools. The focus is on the question of how far one can get with systematic LLM support – and where methodological limits become apparent.

Key findings#

Specification as a success factor: Across all projects, the quality of the specification proved to be crucial. The clearer the functional requirements, technical dependencies and architectural decisions were defined in advance, the more error-free the implementation was. The investment in specification quality – typically 20 to 90 minutes – paid off in drastically reduced implementation effort and increased code quality.

Active control required: LLMs tend to favour complex solutions that are likely to be contained in their training data but cannot always be replicated cleanly. Consistently demanding simple approaches (KISS principle) proved to be a necessary control task during specification creation.

Structuring for maintainability: Clear modularisation with size limits per file (typically less than 1000 lines) improved both code quality and maintainability by LLMs. Greater complexity had to be broken down into manageable parts – a decomposition that LLMs are not always able to perform effectively.

Changed developer role: The workflow is shifting: requirement clarification, architectural decisions and critical evaluation of LLM proposals are becoming core competencies, while implementation details are less important for these types of tasks.

Limitations and fields of application#

The projects reached various levels of complexity: from 2,000 lines of code for focused tools to almost 20,000 lines for more complex systems. It became clear that the methodology shows its strengths in the area of prototypes, analysis tools and internal utilities – but not for safety-critical production systems or components with high quality requirements.

A sound understanding of software architecture remains a prerequisite: not for coding yourself, but for specifying realistic and controllable solutions and evaluating the appropriateness of LLM proposals.

Purpose of this documentation#

This series focuses on potentially transferable patterns and methodological limitations, not on the tools developed themselves. The findings are intended to help other developers and teams realistically assess and effectively use LLM-supported development approaches.

The documented projects show that LLM-supported development is not a substitute for professional software development, but a valuable addition to exploratory phases, rapid prototyping, and the quick validation of tool ideas.

The following articles document specific projects and their specific methodological findings in detail.