Code Reviews mit KI: Software-Qualität optimieren mit GenAI und LLMs
Nur wenige Jahre nach der ersten Präsentation von ChatGPT hat sich die Welt der Software-Entwicklung bereits deutlich verändert: War vor einigen Jahren noch Stack Overflow die erste Anlaufstelle für Problemlösungen, so nutzen heute viele Entwicklerinnen und Entwickler Generative Künstliche Intelligenz (GenAI) wie ChatGPT, um Lösungsvorschläge für ihre Probleme zu erhalten. Anstatt jede Zeile Code selbst zu tippen, erlauben es GenAI-basierte Tools, Code-Blöcke, Dateien oder sogar ganze Projekte zu generieren. Doch auch wenn der Code schnell geschrieben ist, bleibt die Herausforderung, dass der generierte Code hohen Qualitätsansprüchen genügen muss. Entwicklungsteams müssen die Code-Qualität sicherstellen und somit darauf achten, dass der Code verständlich, wartbar und sicher ist.
Da diese manuelle Qualitätssicherung zur Überprüfung von Code-Qualität immer noch sehr aufwändig ist, haben wir uns gefragt: Kann uns GenAI nicht auch beim Code Review unterstützen und die Qualität des Codes verbessern?
Im folgenden Artikel stellen wir unseren Ansatz vor, wie wir mit Hilfe von GenAI zu schnelleren und besseren Code Reviews kommen.
Technische Grundlagen: GenAI und LLMs in der Software-Entwicklung
Large Language Models, kurz LLMs, sind hochentwickelte KI-Systeme, die durch die Analyse und Verarbeitung großer Mengen von Code und technischer Dokumentation trainiert wurden. Diese Modelle bilden die Grundlage für GenAI im Software-Entwicklungsprozess. Viele Entwicklerinnen und Entwickler nutzen bereits KI-Tools wie ChatGPT zur Codegenerierung, stoßen dabei aber auf typische Herausforderungen wie fehlende Importe, Wiederholungen, da die KI nicht immer den vollständigen Projektkontext kennt, nicht deklarierte Variablen, da Abhängigkeiten manchmal übersehen werden, veraltete Bibliotheken, die zu Versionskonflikten führen können, und kontextabhängige Fehler, da die KI nicht alle Projektspezifika kennt. Entwicklerinnen und Entwickler müssen daher oft noch Fehler durch Debugging beheben, um den Code überhaupt zum Laufen zu bringen.
Die Anforderungen an die Qualität des eigenen Codes gehen jedoch weit über die bloße Lauffähigkeit hinaus. Der Code muss für andere Teammitglieder verständlich sein, damit das Projekt über Jahre hinweg wartbar bleibt. Außerdem muss er skalierbar sein und den Sicherheitsanforderungen des Projekts genügen. Damit der generierte Code der Qualität des Projekts entspricht, muss er mit den gleichen Ansprüchen behandelt werden, was am besten durch gezielte Maßnahmen im Projekt sichergestellt werden kann.
Code Reviews und Qualitätssicherung in der modernen Software-Entwicklung
Die Sicherstellung einer entsprechenden Software-Qualität erfordert einen mehrstufigen Ansatz mit spezialisierten Werkzeugen für verschiedene Qualitätsaspekte. Compiler und Linter prüfen die syntaktische Korrektheit und stellen sicher, dass der Code übersetzbar und ausführbar ist. Unit- und Integration-Tests validieren die Funktionalität einzelner Codekomponenten und deren Zusammenspiel. Tools für die statische Code-Analyse, wie z. B. SonarQube, analysieren den Code auf Komplexität, Redundanz und Einhaltung von Best Practices, während SaST-Scanner und Security-Analyse-Tools potenzielle Sicherheitsrisiken identifizieren. Profiling-Tools und Lasttests messen die Performance und identifizieren Engpässe und Dokumentationsgeneratoren und Style Checker fördern konsistenten Code und klare Dokumentation. Je nach Qualitätsanforderungen kommen dabei meist nicht alle Werkzeuge zum Einsatz, sondern es werden nur einzelne Aspekte betrachtet.
Diese spezialisierten Werkzeuge werden meist durch Code Reviews ergänzt, bei denen erfahrene Teammitglieder den Code überprüfen. Code Reviews können sicherstellen, dass die Architektur korrekt implementiert ist, technische Fehler gefunden werden und die korrekte Verwendung von Bibliotheken und Frameworks gewährleistet ist. Insbesondere wenn nicht alle anderen Werkzeuge eingesetzt werden, müssen auch deren Bereiche durch Code Reviews abgedeckt werden.
Code Reviews sind jedoch zeitaufwändig und man benötigt die Verfügbarkeit von entsprechend qualifizierten Sparringspartnern im Team. Hier kann KI-Unterstützung helfen, indem sie erfahrene Entwickler schneller macht, da sie repetitive Aufgaben übernimmt und auf mögliche Probleme hinweist. Gleichzeitig unterstützt sie unerfahrene Entwickler und Entwicklerinnen mit Hinweisen und Verbesserungsvorschlägen.
Ein besonderer Vorteil von GenAI ist, dass es auch Bereiche analysieren kann, für die es noch keine spezialisierten Werkzeuge gibt oder die noch nicht in das Projekt integriert wurden. Die KI kann Muster erkennen und Verbesserungsvorschläge machen, die über die Möglichkeiten herkömmlicher Analysewerkzeuge hinausgehen. Auf der anderen Seite kann sie spezialisierte Werkzeuge nur ergänzen, nicht ersetzen. Gerade im Bereich Security darf und sollte die Künstliche Intelligenz nie spezialisierte Werkzeuge oder das Vier-Augen-Prinzip ersetzen.
Technische Umsetzung von Code Reviews und Learnings
In Projekten finden Code Reviews meist beim Pull/Merge-Request statt. Die Workflows sind so gestaltet, dass eine Kollegin oder ein Kollege sich den neuen Code ansieht und überprüft. Es liegt also nahe, mit automatisierten Code Reviews ebenfalls an dieser Stelle anzusetzen. Der GenAI Code Reviewer wird direkt in die Merge Pipeline eingebunden. Dabei wird der Diff des Merge Requests mit einem speziell entwickelten Prompt an ein GenAI-Modell gesendet. Das Modell analysiert den Code und gibt ein detailliertes Review zurück. Im Folgenden wird beschrieben, wie der Ansatz des GenAI Code Reviewers umgesetzt werden kann und welche Erfahrungen wir dabei gewonnen haben.
Effektives Prompt Engineering für Code Reviews
Die Qualität von KI-gestützten Code Reviews hängt maßgeblich von der Gestaltung des Prompts ab, da dieser beschreibt, wie das Review aussehen soll. Aus der Praxis haben wir gelernt, dass ein gutes Review (und damit auch der Prompt) folgende Aspekte beinhalten sollte.
Kernelemente eines effektiven Prompts
- Strukturierte Zusammenfassung des Merge Requests erzeugen:
– Übersicht der wichtigsten Änderungen, die in dem MR umgesetzt wurden
– Kontext und Zweck der Implementierung
– Betroffene Komponenten und deren Zusammenspiel - Positive Aspekte hervorheben:
– Gelungene Implementierungen würdigen
– Gute Architekturentscheidungen betonen
– Effektive Nutzung von Design Patterns anerkennen - Priorisiertes Issue Scoring:
– Kritische Probleme (7.1-10.0): Sicherheitslücken, schwerw. Performanceprobleme
– Wichtige Verbesserungen (5.1-7.0): Signifikantes Refactoring, Testabdeckung
– Moderate Vorschläge (3.1-5.0): Kleinere Verbesserungen der Codestruktur
– Kleinere Hinweise (1.0-3.0): Formatierung, Dokumentation - Fokussierung auf das Wesentliche:
– Maximal 3-5 wichtigste Empfehlungen
– Unwichtige Issues bewusst weglassen
– Klare Handlungsempfehlungen priorisieren
Gerade die Zusammenfassung am Anfang hilft auch den weiteren Entwicklerinnen und Entwicklern, die dann eigene Code Reviews machen, sich schnell einzufinden und besser zu verstehen, worum es geht. Wir fanden es auch nützlich, eine Erinnerung an die Änderungen im Merge Request zu haben, wenn wir den Merge Request nach ein paar Wochen noch einmal durchsahen.
Die Hervorhebung positiver Aspekte motiviert die Teammitglieder und hilft insbesondere unerfahrenen Entwicklerinnen und Entwicklern zu lernen, was Best Practices sind und worauf sie in Zukunft achten sollten. Die Priorisierung trägt dazu bei, dass die wichtigsten Probleme im MR auch wirklich angegangen werden, was durch die klaren Handlungsempfehlungen noch greifbarer wird.
Beispiel eines optimierten Prompts für Code Reviews
Dieser Prompt ist der eigentliche Kern des Code Reviewers und in einem iterativen Prozess immer wieder verbessert worden. Feedback aus den Projekten hat dazu geführt, dass der Prompt sich stetig weiterentwickelt hat. Der Prompt ist hier nur in Auszügen dargestellt, den Link zum vollständigen Prompt finden Sie in einem Gist mit unseren Codebeispielen [1].
Objective: Provide a concise, balanced review of a GitLab merge request (MR), focusing on areas directly impacted by the changes. Present your analysis in a structured JSON format with two main keys: comment (containing a markdown-formatted critique) and approval (indicating your final decision). Include both actionable recommendations and condensed positive feedback, highlighting significant improvements, good architectural decisions, and effective use of design patterns.
Instructions:
Analyze only the provided changes in the MR.
Include only the evaluation areas directly affected by the current changes.
Structure your response in the specified JSON format.
Ensure all markdown formatting in the comment section is valid and properly escaped only when necessary.
Provide clear, actionable recommendations with code examples or references where applicable.
Highlight significant improvements and good practices observed in the changes in a single, condensed paragraph.
Key Sections:
Always include these sections:
Summary of the Merge Request
Highlights
Recommendations (with priority scores and actionable items)
Overall Approval Decision
...
Your response should look like this (but with your actual review content):
{{
"comment": "## Summary of the Merge Request
[Concise summary]
Highlights
This merge request demonstrates notable improvements in [area]. The changes showcase good architectural decisions, particularly in [specific decision]. Effective use of the [design pattern] enhances [aspect], contributing to [benefit]. The implementation of [feature/change] is particularly well-executed, improving [area] significantly. Overall, these changes reflect a strong understanding of [relevant principles/best practices].
Recommendations
[Short Title] [x.x/10]: [Clear, specific recommendation]
Example: [language]
csharp
[code example]
Where to Apply: [File name or code reference]
Rationale: [Brief explanation]
[more action items]
Overall Approval Decision
[Approval status]
[Only include sections below that are directly relevant to the changes]
[Relevant Section Title]
[Focused content on changes, with code references where applicable]",
"approval": "[Approved | Needs Changes | Rejected ]"
}}
...
Beispiel eines Code Reviews aus einem echten Projekt
Summary of the Merge Request
The merge request focuses on enhancing the server starting process by adding error logging to various critical steps such as database connection, reading the index file, and handling CORS errors. This ensures that potential issues are logged, providing better traceability and debugging capabilities.
Highlights
This merge request demonstrates notable improvements in error handling. The changes showcase good architectural decisions, particularly in wrapping critical operations within try-catch blocks. Effective use of the try-catch pattern enhances the reliability of the code by providing clear logging when an error occurs and preventing the server from running in unstable states. The implementation of custom CORS options is particularly well-executed, improving security and flexibility. Overall, these changes reflect a strong understanding of robust error handling and process management principles.
Recommendations
Format Error Log Output [4.0/10]: Consider adding more structured error log messages with identifiable string formatting to aid in log searching and analysis.
Example: JavaScript
logger.error(`Failed to connect to MongoDB: ${error.message}`, { error });
Where to Apply: In the catch blocks of database connection, index file reading, and request handling.
Rationale: Structured logs allow for easy searching and filtering in log management systems.
Implement Graceful Shutdown [5.5/10]: Introduce a mechanism for graceful shutdowns to allow completion of ongoing requests and proper cleanup of resources.
Example:
process.on('SIGTERM', () => {
logger.info('Received SIGTERM, shutting down gracefully');
server.close(() => {
logger.info('Closed out remaining connections');
process.exit(0);
});
});
Where to Apply: At the end of the server initialization process.
Rationale: Graceful shutdown support enhances reliability by preventing data corruption and allowing cleanup tasks to complete.
Overall Approval Decision
Needs Changes
Code Reliability and Error Handling
The code changes enhance overall reliability by logging errors during critical operations. The use of exit codes ensures that the server does not continue running in an inconsistent state, which is crucial for production stability. Further improvements can be made by formatting error log messages for better readability and implementing a graceful shutdown procedure.
**AI Review Statistics:**
- **Model:** openai/gpt-4o
- **Latency:** 5.84 seconds
- **Cost Estimation:** $0.0277150000
- **Token Usage:**
- Prompt Tokens: 4010
- Completion Tokens: 511
- Total Tokens: 4521
Wahl des LLMs für Code Reviews
Da der Prompt entsprechend komplex und vielschichtig ist, ist ein wirklich gutes LLM notwendig. Unsere praktischen Erfahrungen zeigen deutliche Unterschiede zwischen den verfügbaren Modellen. Im Folgenden zeigen wir die Qualitätsunterschiede anhand eines Merge Requests, wo wir das vielen bekannte Gilded Rose Kata von Emily Bache nutzen [2].
Code Reviews mit Cloud-basierten LLMs: Verbesserung der Code-Qualität durch GPT-4 und Claude
Modelle wie GPT-4 von OpenAI oder Claude von Anthropic liefern durchweg hochwertige Reviews. Einige Beispiele:
GPT-4
## Summary of the Merge Request
This merge request focuses on refactoring the `updateQuality` method and introducing the `UpdateStrategy` enum to enhance the item quality update logic in the `GildedRose` application.
## Highlights
This merge request demonstrates notable improvements in **code maintainability and readability**. The introduction of the `UpdateStrategy` enum significantly simplifies the `updateQuality` method, making it more modular and easier to extend in the future. The new architecture allows for better separation of concerns, as each strategy encapsulates its own logic for updating item quality, adhering to the **Strategy design pattern**. This results in cleaner code and a reduced risk of bugs in the future.
Claude 3.7 Sonnet
## Summary of the Merge Request
This MR refactors the GildedRose class by introducing a strategy pattern through the new `UpdateStrategy` enum. The complex conditional logic in the `updateQuality` method has been replaced with a cleaner, more modular approach where each item type has its own update strategy implementation. The `Item` class has also been modified to use the strategy pattern directly.
## Highlights
This merge request demonstrates **excellent refactoring** that dramatically improves code maintainability. The changes showcase good architectural decisions, particularly in the **implementation of the strategy pattern** via an enum with behavior. The extraction of update logic into dedicated strategy implementations **reduces cognitive complexity** and eliminates deeply nested conditionals. The addition of **helper methods** like `increaseQuality` and `decreaseQuality` further simplifies the code and enhances readability. Overall, these changes reflect a strong understanding of object-oriented design principles and clean code practices.Bewertung: Steigerung der Code-Qualität durch Code Reviews mit Cloud-basierten LLMs
Insgesamt wird das Feedback als sehr hilfreich empfunden, da es sowohl die Stärken der Implementierung hervorhebt als auch konkrete Verbesserungsvorschläge macht, die zur Steigerung der Code-Qualität beitragen können. Besonders beeindruckend ist, dass nur aus dem Diff der eigentliche Zweck des Refactorings, nämlich die Verbesserung der Lesbarkeit und Wartbarkeit, herausgelesen wurde.
Herausforderungen bei lokalen LLMs
Ollama: Wie die Komplexität des Prompts das Code Review beeinflusst
Wir haben auch lokale Modelle mit Ollama getestet. Leider haben die lokalen Modelle mit der Komplexität des Prompts große Probleme, dabei traten immer wieder die gleichen drei Hürden auf:
- Valides JSON zu erzeugen
- Valides Markdown innerhalb des JSON zu erzeugen
- Sinnvolle Kommentare zu erzeugen
Qwen2.5-coder:14b
{'result': 'Success', 'message': 'Code changes have been successfully applied and all tests passed.'}Deepseek-R1:14b
{'items': [{'name': 'Aged Brie', 'sellIn': 2, 'quality': 0}, {'name': 'Sulfuras, Hand of Ragnaros', 'sellIn': 10, 'quality': 35}, {'name': 'Conjured Item', 'sellIn': 1, 'quality': 20}]}Phi4
The provided data is a structured diff of changes made to source code files within a project directory. The primary focus appears to be refactoring and enhancing the design of an inventory management system for items with varying update strategies.', 'changes_overview': {'Item Class Refactoring': 'The `Item` class was updated from having an overridden `toString()` method to incorporating an update mechanism via a strategy pattern. An `updateStrategy` field is added, and the constructor now initializes this strategy using a static factory method in the `UpdateStrategy` enum.', 'Introduction of UpdateStrategy Enum': 'A new enumeration `UpdateStrategy` was created, encapsulating different item update behaviors such as normal degradation (`NORMAL`), improvement for aged items (`AGED_BRIE`), dynamic quality changes based on time left for event passes (`BACKSTAGE_PASS`), no updates required (`SULFURAS`), and double rate of decrease for enchanted/conjured items (`CONJURED`).', 'General Improvements': {'Design Pattern Usage': 'The code adopts the strategy design pattern to manage item quality updates, enabling easier extension and modification of behaviors associated with different types of items.Bewertung der Ergebnisse lokaler LLMs: Welche Modelle liefern brauchbare Antworten?
Einzig Phi4 hat ein Ergebnis gebracht, was den Erwartungen zumindest inhaltlich etwas gerecht werden konnte, auch wenn kein valides JSON geliefert wurde. Die anderen beiden Modelle haben leider keine nutzbaren Antworten gegeben. Wenn man so etwas mit lokalen Modellen umsetzen möchte, muss man den Prompt aufteilen und die Abschnitte (Summary, Highlights, ...) einzeln erzeugen lassen, um die Komplexität zu reduzieren, auch wenn wir es nicht selber getestet haben.
Workflow des Code Reviewers
Wenn der Code Reviewer durch einen Merge Request (MR) gestartet wird, wird zunächst über die API des Repositories der komplette MR als JSON-Objekt abgerufen. Dies beinhaltet neben diversen Metadaten auch die Diffs. Um Tokens zu sparen, könnte man hier noch viele Daten rauswerfen und nur die Diffs verwenden. Der Einfachheit halber haben wir uns entschieden, das JSON-Objekt as-is an das LLM weiterzugeben. Wir haben auch noch die Möglichkeit vorgesehen, dem LLM optional weitere Informationen mitzugeben, z. B. die Testergebnisse der Pipeline.
Daraus erstellt das LLM ein neues JSON-Objekt, das das textuelle Review sowie eine finale Bewertung enthält. Das textuelle Review wird dann über die API als Kommentar an den MR angehängt und die finale Bewertung führt dann ebenfalls über die API zu einem Approval oder eben nicht.
Eigene Experimente
Wer Lust bekommen hat, das einmal selbst auszuprobieren, findet im Anhang einen Link zu einem Gist mit einem Jupyter Notebook [1]. Dies verwenden wir vor allem, um Modelle zu testen, ob und wie gut sie mit dem Prompt klarkommen und natürlich als Werkstatt für die weitere Optimierung des Prompts.
CI/CD-Integration: Automatisierte Code Reviews in der Pipeline
Damit sich der Code Reviewer leicht in die Pipeline integrieren lässt, sehen wir zwei Möglichkeiten.
- Software-As-A-Service
- Als Docker Image direkt in der Pipeline
Software-As-A-Service
Man könnte für mehrere Projekte eine zentrale Instanz, gerne auch serverless, laufen lassen, die vom Repository per Webhook gestartet wird. Dies ist, wenn man viele Projekte einbinden will, wahrscheinlich die einfachste Möglichkeit, erfordert aber Infrastruktur, wo der Service läuft. Das Setup hat außerdem ein paar Sicherheitsimplikationen, weil der Service schreibenden API-Zugriff auf alle Projekte benötigt.
In der Pipeline
Wir haben uns daher entschieden, den Reviewer direkt in die Pipeline zu integrieren. Dafür haben wir ein OCI-Image (aka Docker) erstellt, das dann in die Pipeline integriert wird.
Technische Grenzen
Die Kontextfenster aktueller LLMs sind auf 100k bis 200k Tokens begrenzt. Es ist bei uns 1-2 Mal vorgekommen, dass der MR tatsächlich vom LLM nicht verarbeitet werden konnte.
Was sich zunächst einmal wie eine große Einschränkung anhört, ist in Wirklichkeit ein Hinweis darauf, dass möglicherweise ein Problem mit dem eigenen Entwicklungsprozess vorliegt. Denn seien wir ehrlich, ein MR, der so groß ist, dass ein LLM ihn nicht mehr verarbeiten kann, wird auch für die menschlichen Reviewer:innen zu einer echten Herausforderung. Eine ausführliche Erklärung, wie die Größe des Merge Requests die Qualität der Software beeinflusst, finden Sie unter [3].
Zu große Merge Requests vermeiden
Große Änderungen, die diese Grenzen überschreiten, können weder von der KI noch von menschlichen Reviewern effektiv analysiert werden. Um die KI-Unterstützung und die menschliche Review-Qualität zu optimieren, müssen große Änderungen in thematisch zusammenhängende Einheiten aufgeteilt werden. Präzise Commit Messages und Dokumentation sind Pflicht, um das Verständnis zu verbessern. Bei umfangreichen Änderungen müssen mehrere fokussierte Reviews durchgeführt werden. Das verbessert nicht nur die KI-Analyse, sondern macht die Änderungen auch für das gesamte Entwicklungsteam nachvollziehbar. Die KI-Kontextgrenzen sind dabei der natürliche Indikator für zu komplexe Änderungen, die vereinfacht werden sollten.
Kosten und Nutzen der automatischen Code Reviews
In einem unserer Vorträge wurden wir mal nach einer Kosten-Nutzen-Bewertung zu den automatischen Code Reviews gefragt. Die Motivation für KI-gestützte Code Reviews liegt primär in der Qualitätsverbesserung, nicht in der Kostenersparnis. Bei Kosten von wenigen Cent pro Review ist der finanzielle Aspekt ohnehin vernachlässigbar.
Die Kombination von AI und Peer Reviews fördert eine positive Teamkultur und konstruktiven Austausch.
Die wichtigsten qualitativen Vorteile sind eine verbesserte Dokumentation, da jeder Merge Request automatisch eine umfassende, strukturierte Dokumentation erhält, und kontinuierliches Lernen, da die Teammitglieder regelmäßig Feedback erhalten und ihr Wissen erweitern. Darüber hinaus stellen konsistente Reviews sicher, dass die KI zuverlässig alle definierten Aspekte prüft, und dass schnelleres Feedback gegeben wird, da automatische Reviews sofort verfügbar sind. Die Kombination von AI und Peer Reviews fördert eine positive Teamkultur und konstruktiven Austausch. Diese qualitativen Verbesserungen rechtfertigen bei weitem die minimalen Kosten der KI-Unterstützung. Praktische Erfahrungen zeigen, dass KI-unterstützte Code Reviews besonders wertvoll sind, wenn schnelles Feedback durch eine automatische Erstanalyse innerhalb weniger Minuten benötigt wird, die Reviewer entlastet werden sollen, um sich auf komplexe Architekturentscheidungen konzentrieren zu können, die Qualität durch die systematische Identifikation von Verbesserungspotenzialen gesteigert werden soll und kontinuierliches Lernen durch KI-Empfehlungen gefördert werden soll.
Ausblick
Wenn Agenten-basierte Tools wie Aider, Cline oder Github Copilot bei der Entwicklung zum Einsatz kommen, dann ist es auch möglich, das Ergebnis des Code Reviews direkt in das entsprechende Werkzeug zurückzuspielen und somit weitestgehend automatisch die Verbesserungsvorschläge umsetzen zu lassen.
Hierbei kommt der Priorisierung eine entscheidende Rolle zu. Die Coding-Tools funktionieren am besten, wenn sie eine einzelne, klare Aufgabe bekommen. Wir haben inzwischen eine abgespeckte Variante des Prompts im Einsatz, ohne Zusammenfassung und ohne Zuckerguss, die die wichtigsten 1-2 Probleme direkt in der IDE an den Coding Agent zurückspielt. Das Ergebnis ist dann meist faszinierend – und ein bisschen scary.
Fazit
Die Integration von GenAI in den Code-Review-Prozess stellt eine wichtige Ergänzung in der Software-Entwicklung dar. Durch die Kombination von KI-basierten Werkzeugen mit bewährten Best Practices können Entwicklungsteams die Code-Qualität nachhaltig verbessern und den Review-Prozess beschleunigen. Die Technologie wird sich weiterentwickeln und noch tiefer in den Entwicklungsprozess integriert werden, was neue Möglichkeiten für eine effizientere Software-Entwicklung eröffnet. Tools wie Aider, die automatisierte Fixes anbieten, und Shell-basierte GPT-Prompts, die in Reviews gefundene Probleme direkt beheben, können bereits heute im Alltag eingesetzt werden.
DevOps auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema DevOps erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
- Gist mit den Beispielen zum Artikel
- Github: Emily Bache: Gilded Rose Refactoring Kata
- Rodrigo Miguel: The Size of the Pull/Merge Request is More Important Than You Think
