Für die Python-Entwicklung steht eine Vielzahl von Werkzeugen zur Verfügung – von minimalistischen Editoren bis hin zu vollwertigen, integrierten Entwicklungsumgebungen.
IDLE (Integrated Development and Learning Environment)¶
IDLE ist die Standard-Umgebung, die direkt mit Python ausgeliefert wird. Sie basiert auf dem GUI-Toolkit Tkinter. Da sie ohne zusätzliche Paketmanager oder Konfigurationen sofort startklar ist, eignet sie sich für absolute Anfänger oder um sehr schnelle, kleine Skripte isoliert zu testen. Für den produktiven Einsatz fehlen ihr jedoch moderne Komfortfunktionen.
Text-Editoren für Power-User: Emacs¶
Für tastaturzentrierte Power-User in performanten Linux-Umgebungen bietet sich Emacs an. Der bevorzugte Major Mode für Python ist heute python-mode (bzw. python-ts-mode für modernes, schnelles Tree-Sitter-Highlighting). Um vollwertige IDE-Features zu erhalten, wird Emacs mit einem LSP-Client (wie eglot oder lsp-mode) gekoppelt, um die Code-Intelligenz asynchron abzufragen.
Jupyter Lab¶
Jupyter Lab ist der De-facto-Standard im Bereich Data Science, Machine Learning und für interaktive Skripte. Das Kernkonzept basiert auf interaktiven Notebooks, in denen Code in einzelnen “Zellen” ausgeführt wird. Dies ermöglicht ein exploratives Programmieren (REPL-Prinzip: Read-Eval-Print Loop), bei dem Variablen im Speicher bleiben und Datenvisualisierungen direkt unter dem Code gerendert werden.
Moderne IDEs¶
PyCharm¶
PyCharm wird von JetBrains entwickelt und baut technologisch auf der in Java geschriebenen IntelliJ-Plattform auf. Es ist eine sehr umfangreiche (“schwere”) IDE, die Entwicklern tiefe statische Code-Analysen, exzellente Refactoring-Tools und Out-of-the-box-Integration in professionelle Workflows bietet.
Visual Studio Code (VS Code)¶
VS Code von Microsoft ist ein leichtgewichtigerer Editor, der seine Funktionalität modular über Erweiterungen erhält. Ein großer architektonischer Vorteil ist die nahtlose webbasierte Nutzung: Unter vscode.dev oder direkt in GitHub (durch Drücken der .-Taste in einem Repository) kann VS Code inklusive vieler Basis-Sprachfeatures komplett im Browser ausgeführt werden.
Architektur: Das Language Server Protocol (LSP)¶
Das LSP entkoppelt den Editor von der sprachspezifischen Logik. Der Editor fungiert lediglich als visueller Client und fragt bei einem im Hintergrund laufenden “Language Server” analytische Features wie Go-to-Definition, Autovervollständigung und strenge Typüberprüfungen an.
Historisch war Jedi der Standard für statische Python-Analyse. Da strikte Typisierung und Geschwindigkeit im modernen Python-Ökosystem extrem an Bedeutung gewinnen, gibt es heute performantere Nachfolger. Ein herausragendes Beispiel ist Zuban. Zuban ist ein in Rust geschriebener Type-Checker und Language Server, der vom ursprünglichen Jedi-Autor entwickelt wurde. Er bietet eine hohe Mypy-Kompatibilität, verbraucht jedoch deutlich weniger Speicher und operiert 20- bis 200-mal schneller als Mypy.
Jedi: Historisch der Standard-Server für Autovervollständigung. Wird heute für große, typisierte Codebasen zu langsam sein.
Mypy: Der De-facto-Standard Type Checker. Er wird primär als CLI-Tool in der CI-Pipeline genutzt (
uv run mypy .), kann aber auch in Editoren integriert werden.Pyright / Pylance: Ein von Microsoft in TypeScript geschriebener, extrem schneller Type Checker und Language Server. Pylance (die proprietäre VS Code Erweiterung) basiert auf Pyright. Er ist exzellent im Ableiten von Typen (Type Inference) und oft strenger und deutlich performanter als Mypy.
Zuban / ty / pyrefly: Die modernste Generation. Zuban ist ein in Rust geschriebener Type Checker vom ursprünglichen Jedi-Autor, der Mypy-Kompatibilität bei 20- bis 200-facher Geschwindigkeit bietet.
Ruff (als LSP): Der extrem schnelle Rust-Linter
ruffbringt mittlerweile einen eigenenruff servermit. Er ersetzt keinen Type Checker wie Pyright, übernimmt aber das blitzschnelle Formatieren und Aufzeigen von Syntax- und Stil-Fehlern (Flake8-Äquivalente) in Echtzeit beim Tippen.
Integration der modernen Toolchain¶
In einer modernen Python-Umgebung konkurrieren diese Tools nicht, sondern ergänzen sich nahtlos. Eine saubere Integration in VS Code, Emacs oder Neovim sieht konzeptionell so aus:
Environment:
uvverwaltet das Projekt und das versteckte.venv. Der Editor wird konfiguriert, den Python-Interpreter aus diesem.venvzu nutzen.Diagnostics & Formatting: Der
ruff serverwird als LSP gestartet. Er liefert Millisekunden-schnelles Feedback zu Linter-Regeln und führt “Format on Save” (Ersatz für Black/isort) aus.Typ-Sicherheit: Parallel läuft
pyright(oder ein Mypy/Zuban LSP) als zweiter Language Server, der sich ausschließlich um die semantische Analyse und Typ-Inferenz kümmert.
Die IDE startet im Hintergrund selbst die Language-Server; von Hand würde man dies aufrufen:
ruff server
pyright-langserver --stdio
Agentic Coding¶
Während traditionelle KI-Assistenten (wie GitHub Copilot) primär als “Autovervollständigung auf Steroiden” agieren, leitet Agentic Coding einen fundamentalen architektonischen Wechsel ein. Agenten schlagen nicht nur passiv Codezeilen vor, sondern verändern den Code direkt. Der Begriff ‘Agent’ suggeriert eine gewisse Autonomie, bedeutet letzlich aber nur soviel wie eine Sequenz von Prompts, die auf einen Ordner und ausgewählte Kommandozeilenwerkzeuge oder Plugins zugreifen können.
Ein Coding-Agent durchläuft iterativ einen Plan-Execute-Verify-Zyklus: Er analysiert die Projektstruktur, plant die Änderungen über mehrere Dateien hinweg, führt selbstständig Shell-Kommandos aus (z.B. das Installieren von Abhängigkeiten via uv oder das Ausführen von pytest), liest die resultierenden Fehlermeldungen und korrigiert den Code iterativ, bis die Tests erfolgreich sind. Der Entwickler wandelt sich dabei vom operativen Coder zum Architekten und Reviewer. Weil das Review von gut formatiertem Code leich zu “sieht gut aus, passt schon” wird, muss man bereits im Vorfeld die Menge des zu sichtenden Codes klein halten.
Moderne AI-First IDEs und Agenten-Frameworks¶
Die Tool-Landschaft ist derzeit recht dynamisch und differenziert sich nach dem Grad der Autonomie der Assistenzsysteme:
Autocomplete-Plugins und AI-Assistenten¶
Die direkte Vorstufe zu vollautonomen Agenten sind KI-gestützte Autocomplete-Plugins. Diese integrieren sich nahtlos in den Editor und unterstützen den Schreibfluss in Echtzeit (Inline-Suggestions).
GitHub Copilot: Ehemals der etablierte Branchenstandard. Analysiert den unmittelbaren Kontext (geöffnete Dateien und Cursor-Position) und vervollständigt Boilerplate-Code, Docstrings oder komplexe Einzeiler.
Supermaven: Ein hochperformanter Copilot-Konkurrent mit einem enormen Kontextfenster (bis zu 1 Million Token). Es ist darauf spezialisiert, Muster über das gesamte Repository hinweg extrem verzögerungsfrei zu erkennen und zu vervollständigen.
Junie (JetBrains): JetBrains’ native KI-Integration für Umgebungen wie PyCharm. Junie verwischt die Grenzen der Kategorien: Es bietet klassische, kontextbezogene Unterstützung beim Tippen, fungiert aber zunehmend als Hybrid. Über spezielle Modi (“Code Mode”) kann es proaktiv das Projekt analysieren, Abhängigkeiten auflösen und selbstständig Tests oder Refactorings durchführen.
Cursor¶
Cursor gilt als der Vorreiter der AI-First IDEs und ist ein direkter Fork von VS Code. Es integriert LLMs tief in den Editor (für codebase-weite Chats und Multi-File Edits). Trotz der starken KI-Fähigkeiten bleibt der Ansatz konservativ: Der Mensch bleibt am Steuer und nutzt die KI als omnipräsenten, hochkontextuellen Copiloten.
Claude Code¶
Derzeit eins der beliebtesten Agentic-Coding-Werkzeuge. Ein von Anthropic entwickeltes Kommandozeilen-Tool, das direkt im Terminal läuft. Es ist darauf spezialisiert, als autonomer Agent im Dateisystem zu navigieren, Code zu schreiben und Systemkommandos auszuführen. Es integriert sich nahtlos in CLI-zentrierte Workflows, ohne eine grafische IDE zu erzwingen.
Aider (AI Pair Programming in the Terminal)¶
Ähnlich wie Claude Code ist Aider ein reines Kommandozeilen-Tool, das direkt im Terminal ausgeführt wird. Es zeichnet sich durch eine exzellente Git-Integration aus: Aider editiert Dateien im lokalen Workspace und erstellt für jede funktionierende Änderung automatisch einen logisch benannten Git-Commit. Es unterstützt den Wechsel zwischen verschiedenen LLM-Providern (OpenAI, Anthropic, Gemini) und harmoniert mit minimalistischen Editoren wie Emacs oder Neovim.
OpenClaw (Coding Agent)¶
Ein quelloffenes Framework für komplett autonome Agenten. Der Coding Agent (oft in Kombination mit dem CLI-Harness OpenCode) agiert autark: Er analysiert Repositories, schreibt Tests, nutzt Git und führt Commits aus. Die architektonische Besonderheit von OpenClaw ist die Entkopplung von der IDE: Agenten laufen als isolierte Hintergrundprozesse in Sandboxes und können sogar asynchron über Messenger (z.B. Telegram oder Discord) delegiert und überwacht werden.
Google Antigravity¶
Diese Ende 2025 eingeführte Plattform denkt die IDE explizit für das Agenten-Zeitalter neu. Neben einer klassischen Editor View bietet Antigravity eine Manager View. Hier orchestriert der Entwickler mehrere spezialisierte Agenten, die asynchron und parallel arbeiten (z.B. ein Agent recherchiert API-Docs, während ein anderer Frontend-Tests schreibt). Statt rohem Code produzieren diese Agenten überprüfbare “Artifacts” – strukturierte Task-Listen, Architekturpläne, Diffs und sogar automatisierte Browser-Screenshots für UX-Tests.
Weitere Lektüre¶
IDEs & Architektur¶
PyCharm vs. VS Code (Vergleich): Tech-Insider – Analyse von Monolith vs. modularer Architektur.
Emacs für Python: RealPython – Deep Dive in LSP und Tree-Sitter.
Oxidization des Toolings: Astral Blog – Warum Python-Tools (Ruff/uv) in Rust neu entstehen.
Type Checking & Performance¶
Mypy vs. Pyright: Microsoft Docs – Direkter Vergleich der Inferenz-Stärke.
Zuban: ZubanLS – Dokumentation zum Rust-Nachfolger für Jedi.
Agentic Coding & AI-First¶
Cursor vs. VS Code: Review-Blog – Warum “Multi-File Edits” den Workflow verändern.
Claude Code: Anthropic – Launch-Dokumentation zum Terminal-nativen Agenten.
OpenClaw: freeCodeCamp Tutorial – Architektur von isolierten Hintergrund-Agenten.
Google Antigravity: Google Codelab – Einstieg in die orchestrative “Manager View”.
Anleitung zum Vibe Coding¶
Der Begriff ``Vibe coding’’ wurde von Andrej Karpathy (2. Feb. 2025) geprägt:
There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
Darin wird die Vorgehensweise beschrieben, sich den generierten Code nicht gründlich anzusehen. Das ist zwar durchaus ein möglicher Zugang (ohne Ironie!), aber wir wollen hier eine andere Arbeitsweise beschreiben, vor dem Hintergrund dass diese ``Vibe coding’'-Arbeitsweise ohne hinreichende Erfahrung schnell eine Komplexitätsdecke erreicht, mit der ein LLM-System allein nicht mehr sinnvoll umgehen kann (und der Nichtprogrammierer dann auch nicht mehr).
Wir benutzen den Begriff jetzt auch im erweiterten Sinne: Wir lassen uns Code generieren und schreiben nicht mehr selbst direkt Zeilen Code. Im etwas engeren Sinne könnte man zur Abgrenzung noch von agentic coding sprechen, wenn man spezielle Sequenzen aus dem LLM-Output ``tool calls’’ an externe Programme füttert und mit dem Output wiederum das LLM in einer Feedbackschleife. Damit kann ein LLM so lange Code verändern, bis Compiler, Linter und Test-Suite durchlaufen. Wir profitieren aber davon, Erfahrungen mit dem einzelnen Schritt zu sammeln (da frühe Fehler im Iterationsprozess Folgefehler nach sich ziehen, und damit tendenziell größere Mengen verschwendeter Rechnungen bewirken).
Diese Erkenntnisse leiten dabei den Ko-Entwicklungsprozess:
LLM-Output lesen kostet Zeit und ist teilweise sehr anstrengend, weil der Output vor Allem aussieht wie korrekter Output, aber dennoch subtile Fehler jeder Art enthalten kann
Viel LLM-Output generieren kostet viele Token und damit Geld
Die Kontextgröße, die ein LLM erfassen kann, ist begrenzt.
Auch bei grundsätzlichen großen Kontextfenstern ist die Auswahl von relevantem Kontext eine der nützlichsten Maßnahmen, um Ergebnisse zu verbessern und Token zu sparen.
Wir müssen uns vorher überlegen, wie wir den Output sinnvoll bewerten können (woran wir erkennen, dass das Programm tut, was es soll). Entweder ist das Programm kurz genug, damit wir es lesen können, oder es ist anderweitig statisch oder zur Laufzeit prüfbar.
Wenn wir Prüfkriterien (Test cases, Type checks, Contracts) haben, können wir ein LLM iterativ dagegen anarbeiten lassen.
LLMs sind sehr gut im Extrahieren/Transformieren und erlauben damit facet-oriented development, indem man eine einzelne Facette (z.B. den Happy Path, oder das Exception Handling, das Logging) isoliert entwickelt und das LLM später Code zusammenfügen lässt.
Alle ``Entscheidungen’', die man einem LLM überlässt, werden willkürlich getroffen (mit einem Bias zu dem, was im Trainingscorpus vorkam). Insbesondere wird nicht Code für die aktuelleren APIs geschrieben, sondern i.d.R. für ältere, was immer wieder zu Fehlermeldungen oder unnötigen Performance-Einbußen führt.
LLMs sind nicht nur gut in Code-Transformationen, sondern auch darin, Dokumentation zu konsultieren und so eine neue API zu verwenden (denn das ist eine Form von Code-Transformation).
LLMs sind nicht nur gut in Code-Transformationen, sondern auch in allgemeinen Text-Transformationen. Somit lässt sich auch ein Design-Dokument (Anforderungsheft, Implementierungsentscheidungen mit Begründung) generieren und nach Wünschen anpassen. Das ist oft ein guter erster Schritt bei komplexeren Vorhaben.
LLMs haben kein eigenes Gefühl dafür, welche Teile eines Textes oder Codes bewahrenswert sind und welche flüchtig / gerne geändert werden können. Bittet man ein LLM um eine Änderung eines Codes an Stelle A wird daher oftmals Stelle B mit verändert, meist ohne die Semantik wesentlich zu ändern. Mit geringem Kontext wird dabei gern on the fly die API angepasst, was dann zu Konflikten führt. Hier hilft nur das Prinzip der minimalen Änderung.
LLMs haben kein eigenes Gefühl dafür, was der Einsatzzweck des Codes werden soll und welche Rahmenbedingungen herrschen (darf man viele Paketabhängigkeiten nutzen? Ist PyTorch für die Aufgabe Overkill und eine händische Methode tut’s auch? Muss es schnell laufen? Benötigt man eine Pause/Resume-Logik bei längeren Aufgaben?)
LLMs bevorzugen häufig genutzte Frameworks und sind besser darin, solchen Code zu generieren. Choose a Popular Tech Stack.
Baby steps¶
Als allerersten Schritt sollte man sich damit vertraut machen, was passiert, wenn man einfach promptet ``Schreibe ein Python-Programm, welches die n-te Fibonacci-Zahl berechnet’'. Dann gibt es zwei nützliche Übungen:
Iterativ am Output herumkritteln und neu generieren lassen (z.B. könnten wir spezifische Anfragen zum User Interface haben, oder Nutzung von Numpy einfordern oder einen Algorithmus, der dynamische Programmierung einsetzt).
Am Ende den finalen Output betrachten, und versuchen, einen Prompt zu schreiben, zu dem das direkt der Output sein könnte. Dabei kann das LLM auch helfen!
Staunen, wie schwierig es ist, exakt zu spezifizieren, was man haben will.
Serious steps¶
Manchmal kann man nicht einschätzen, wie viel Code eine kleine Aufgabe braucht. Lässt man sich schnell etwas Code generieren, merkt man sofort, ob sich dieser lesen (und dann direkt verwenden) lässt. Bei Instant-Throwaway-Code sind Typenannotationen, Logging usw. oft völlig irrelevant.
Stellt sich heraus (oder ahnte man bereits), dass willkürlich generierter Code die Aufgabe nicht zufriedenstellend lösen wird (oder es zu nervig ist, das zu lesen), arbeitet man mehrstufig:
Schreiben eines Designdokumentes: Grobe Zielformulierung, Pläne zur Aufteilung in Subsysteme/Dateien, zur Verwendung von Bibliotheken. Worauf liegt der Fokus? Woran erkennt man, ob es (gut) geklappt hat?
Einrichten einer Testumgebung anhand des Designdokumentes (in einfachen Fällen, ein Terminal, in dem man das Programm ausführt und den Output betrachtet).
Draft der Datenstrukturen, Datentypen und Interfaces (Hybrid aus Designdokument in Kommentaren und Code ohne Implementierung).
Kritische Teile der Business-Logik einzeln (mit Tests).
Zusammensetzen der Teile, generieren von Glue Code.
Generieren von passenden Type Hints, ggf. Contracts/Pydantic, Assertions, Docstrings.
Energie darauf konzentrieren, Tests zu generieren, die das Erfolgskriterium betreffen.
Offene Frage ``Welche Probleme könnte es mit diesem Code geben’’
Wenn zwischendurch etwas nicht (richtig) gelöst wird, z.B. wenn ein Test dauerhaft nicht erfüllt wird und das LLM keine Lösung findet, muss man das Problem in kleinere Teilprobleme zerlegen (lassen), die man einzeln debuggen kann.
Im agentic coding ist so eine Liste mit Schritten oft selbst als Skill-Dokument kodiert und kann so direkt auf ein Designdokument angewendet werden.
Achtung: im Moment ist es noch so, dass es manchmal viel günstiger ist, statt einer großen Test-Suite den generierten Code zu lesen (und sich zu erbitten, dass der möglichst kurz ist) und zu verstehen, um dämliche Fehler frühzeitig zu finden. Dazu muss man aber relativ gut im Lesen von Code sein, was man unter Anderem durch das eigene Programmieren lernt - und mit LLMs evtl. ein bisschen verlernt. Ein schöner Kompromiss ist ``Erkläre mir Zeilen 23--27, warum ist da XYZ’', um schnell nachzuvollziehen, was passiert.