Anmelden
(Bild: hyper3d.ai)
Mit einem einzigen Handyfoto zur fertigen Figur aus dem 3D-Drucker: Mehrere neue KI-Tools machen aufwändiges 3D-Modellieren für viele Projekte überflüssig.
Jeder Maker, der einen 3D-Drucker besitzt, kennt das Problem. Die Hardware ist längst bezahlbar, aber um eigene Objekte zu drucken, muss man bisher 3D-Modellierung beherrschen. Programme wie Blender, Fusion 360 oder FreeCAD haben steile Lernkurven, verlangen räumliches Denken in Polygonen und Vertices, und selbst nach wochenlanger Einarbeitung gelingen Anfängern selten druckbare Ergebnisse. Deshalb drucken viele Maker nur heruntergeladene Modelle von Thingiverse oder Printables, statt eigene Ideen umzusetzen. Diese Hürde fällt gerade weg. Mehrere KI-Werkzeuge erzeugen inzwischen aus einem einzelnen Foto oder eine, kurzen Prompt dreidimensionale Meshes, die sich direkt als STL oder OBJ exportieren und auf den Drucker schicken lassen.
Konkret sieht das so aus: Man nimmt ein beliebiges Foto, etwa von der eigenen Hauskatze, lädt das Bild in Tripo oder Hunyuan3D Studio hoch und bekommt Sekunden später ein texturiertes 3D-Modell mit Rückseite, Unterseite und allem, was die Kamera nie gesehen hat. Die KI ergänzt die fehlenden Perspektiven plausibel.
Der erste nutzbare Durchbruch in diesem Bereich kam im März 2024, als TripoSR präsentiert wurde [1]. Ein Jahr später, im März 2025, haben wir das Tool Rodin von Hyper3D getestet [2] (hyper3d.ai). Seitdem hat sich das Feld in rasantem Tempo weiterentwickelt. Die Qualität, Geschwindigkeit und Zugänglichkeit dieser Werkzeuge haben sich drastisch verbessert. Inzwischen gibt es ein ganzes Ökosystem an Diensten, die um Nutzer konkurrieren.
Einer der sichtbarsten Player ist Tripo [3], entwickelt vom chinesischen KI-Startup VAST. Auf der GDC (Game Developers Conference) im März 2026 in San Francisco wurde ein Modell vorgestellt, das 3D-Objekte in rund zwei Sekunden erzeugt und ein Ergebnis mit weniger Artefakten liefert. Tripo bedient über 6,5 Millionen Nutzer und bietet ein Freemium-Modell mit begrenztem Kontingent.
Daneben drängen weitere Dienste in den Markt. Meshy, [4] mittlerweile Version 6, richtet sich gezielt an den 3D-Druck, PrintPal [5] hat in seinem ersten Jahr 200.000 Nutzer gewonnen, Hyper3D [6] bietet mit Rodin Gen-2 die Möglichkeit, generierte Modelle gezielt per Textbefehl nachzubearbeiten, und Hitem3D [7] punktet mit einem eigenen Portrait-Modus für personalisierte Büsten und Figuren.
Auf der Open-Source-Seite sticht Tencents Hunyuan3D [8] heraus. Es ist das derzeit leistungsfähigste frei verfügbare Modell und läuft lokal auf dem eigenen Rechner ab einer Grafikkarte mit 12 GB Speicher. Allerdings setzt die Nutzung eine Python-Installation voraus, und Tencents Online-Studio ist nur auf Chinesisch und mit chinesischem Login zugänglich.
Außer PrintPal und Meshy sind alle hier erwähnten Dienstleister chinesische Unternehmen.
Für Maker bleiben allerdings wichtige Einschränkungen. Die generierten Meshes bestehen aus Hunderttausenden Dreiecken ohne saubere Topologie. Für dekorative Figuren, Spielzeug und einfache Ersatzteile funktioniert der Weg vom Foto zum Drucker deshalb schon erstaunlich gut. Aber die Modelle entstehen als Oberflächennetze ohne parametrische Konstruktionslogik — eine Wand ist nicht „2 mm dick“, sondern besteht aus Dreiecken, die nur ungefähr 2 mm Abstand haben.
Zwar lassen sich in Tools wie Meshy reale Maße setzen und die Druckbarkeit direkt prüfen, und bei Hitem3D ist die Optimierung für den Druck von Anfang an eingebaut, aber für wirklich funktionale Bauteile, die exakt auf bestehende Teile passen oder mechanische Belastungen aushalten müssen, bleibt klassische Konstruktionssoftware unverzichtbar.
Für einfachere Bauteile gibt es einen anderen Weg über PrintMakerAI [9]. Hier werden aus einem Prompt keine Meshes, sondern echte parametrische CAD-Körper mit exakten Maßen und garantiert wasserdichter Geometrie erzeugt — allerdings beschränkt auf einfache funktionale Teile wie Halterungen, Gehäuse oder Aufbewahrungsboxen.
(Bild: Printmaker.ai)
URL dieses Artikels:
https://www.heise.de/-11273636
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Framework)
Interessierte können den Framework Laptop 13 Pro vorbestellen. Die Intel-Versionen sind deutlich attraktiver als die AMD-Varianten.
Framework nimmt wie versprochen Vorbestellungen für den Laptop 13 Pro entgegen. Damit stehen jetzt auch alle Konfigurationen und Preise fest. Der offizielle Store hält eine Überraschung bereit: Die Versionen mit Intel-Prozessor sind günstiger und voraussichtlich flotter als die AMD-Typen. Aktuelle Bestellungen will Framework ab Juli ausliefern.
Die sogenannte DIY-Edition ohne Speicher und Betriebssystem ist mit Intels Achtkerner Core Ultra 5 325 [1] ab 1349 Euro erhältlich [2]. Die günstigste AMD-Version mit dem ebenfalls achtkernigen Ryzen AI 7 350 gibt es ab 1579 Euro. Bei einer mittleren Konfigurationliegt die Differenz bei 60 Euro: Für die Variante mit dem 16-Kerner Core Ultra X7 358H ruft der Hersteller 1799 Euro auf, für jene mit dem 12-Kerner Ryzen AI 9 HX 370 sind es 1859 Euro.
Vom Topmodell mit Core Ultra X9 388H ist aus Preis-Leistungs-Sicht abzuraten: Die CPU-Kerne takten etwas höher, dafür kostet die Konfiguration 230 Euro mehr. Aktuell ist sie auch nicht verfügbar.
Die Preise sind nicht der einzige Unterschied zwischen den AMD- und Intel-Notebooks. Framework setzt ausschließlich beim Intel-Mainboard auf ein stromsparendes und schnelles Low Power Compression Attached Memory Module 2 (LPCAMM2) für LPDDR5X-7467-RAM. AMD-Nutzer müssen mit langsamerem DDR5-5600-RAM in SO-DIMM-Bauform vorliebnehmen. Ein LPCAMM2 mit 32 GByte RAM kostet 490 Euro. 32 GByte DDR5 kosten wahlweise 524 Euro auf zwei SO-DIMMs verteilt oder 452 Euro als einzelnes SO-DIMM.
Wie üblich verkauft Framework auch komplette Notebooks mit RAM, SSD und Betriebssystem. Aktuell bietet der Hersteller eine Intel-Konfiguration mit Core Ultra X7 358H, 32 GByte RAM und einer 1 TByte großen PCIe-4.0-SSD an.
Erstmals installiert Framework auf Wunsch ein Linux-Betriebssystem in Form von Ubuntu 24.04 LTS. Damit kostet die Komplett-Konfiguration 2369 Euro. Wer auf Windows 11 Pro besteht, muss 220 Euro Aufpreis zahlen.
Die gewünschten Anschlüsse kommen obendrauf. USB-C für Thunderbolt 4 etwa kostet jeweils 10 Euro. Neu ist ein 10-Gigabit-Ethernet-Adapter für 109 Euro.
Alle DIY- und Komplett-Konfigurationen des Laptop 13 Pro sind derzeit ausschließlich mit schwarzem Gehäuse vorbestellbar. Einzelteile und Nachrüstsätze erscheinen auch mit silberfarbenen Gehäuseteilen [3]; entsprechende Konfigurationen könnten also noch folgen.
Wer einen bisherigen Framework Laptop 13 besitzt, kann künftig die verbesserten Komponenten der Pro-Version [4] nachrüsten. Der Hersteller bietet dazu Einzelteile und Kits an. Der größere Akku erfordert auch die neue Gehäuse-Unterseite und den neuen „Input Cover Frame“. Mainboards mit den Core-Ultra-300-Prozessoren listet Framework noch nicht.
(Bild: Framework)
URL dieses Artikels:
https://www.heise.de/-11268365
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Orange Pi)
Der OrangePi Zero 3W kombiniert Octa-Core-CPU, NPU und Wi-Fi 6 auf kleinem Raum. Das ist spannend für kompakte Maker-Projekte.
Mit dem OrangePi Zero 3W [1] bringt Orange Pi einen neuen Einplatinenrechner heraus, der sich klar an Maker und Embedded-Entwickler richtet.
Im Zentrum arbeitet der Allwinner A733, ein Achtkern-SoC mit zwei Cortex-A76-Kernen (bis 2,0 GHz) und sechs energieeffizienten Cortex-A55-Kernen. Ergänzt wird das Ganze durch eine integrierte NPU mit bis zu 3 TOPS Rechenleistung für KI-Anwendungen sowie einen zusätzlichen RISC-V-Coprozessor für Echtzeitaufgaben. Für Maker bedeutet das: Neben klassischen Linux-Anwendungen lassen sich auch lokale KI-Inferenz oder zeitkritische Steuerungen direkt auf dem Board umsetzen.
Beim Arbeitsspeicher setzt das Board auf LPDDR5 mit bis zu 16 GByte. Beim Speicher zeigt sich das Board flexibel: Neben optionalem eMMC oder UFS-Modulen steht ein microSD-Kartenslot zur Verfügung.
Für die Konnektivität gibt es Wi-Fi 6 und Bluetooth 5.4, optional mit externer Antenne. Damit eignet sich das Board auch für IoT-Anwendungen oder als Edge-Gateway. Dazu kommen klassische Maker-Schnittstellen über eine 40-Pin-GPIO-Leiste mit Unterstützung für SPI, I2C, UART und PWM – also alles, was man für Sensoren, Bildschirme oder Aktoren benötigt.
Interessant ist auch die Videoausgabe: Neben Mini-HDMI (bis 4K@60fps) unterstützt das Board DisplayPort über USB-C sowie MIPI-DSI. Zwei unabhängige Displays lassen sich gleichzeitig ansteuern. Das eröffnet Einsatzmöglichkeiten für kompakte Multimonitor-Setups oder Systeme wie Infoterminals.
Auch für Kamera-Projekte stehen Anschlüsse bereit. Zwei MIPI-CSI-Schnittstellen ermöglichen den Anschluss von Kameramodulen, etwa für Bildverarbeitung oder Überwachungslösungen. In Kombination mit der integrierten NPU lassen sich hier auch KI-gestützte Anwendungen wie Objekterkennung direkt auf dem Gerät realisieren.
Als Betriebssysteme werden unter anderem Debian, Ubuntu, Android und OpenHarmony unterstützt. Zusätzlich nennt der Hersteller Kompatibilität mit gängigen KI-Frameworks wie TensorFlow oder PyTorch. Damit deckt das Board sowohl klassische Bastelprojekte als auch moderne KI-Anwendungen ab – zumindest auf dem Papier. Wie gut die Softwareunterstützung im Alltag wirklich ist, wird sich wie so oft erst zeigen, wenn die Community das Board durch die Mangel gedreht hat.
Mit PCIe 3.0 (über FPC) steht zudem eine schnelle Erweiterungsmöglichkeit bereit, etwa für SSDs oder spezialisierte Module. Das ist in dieser Größenklasse keine Selbstverständlichkeit und könnte für Bastler spannend sein, die mehr als nur Standard-I/O benötigen.
Für Maker ergeben sich daraus einige typische Einsatzszenarien: kompakte Smart-Home-Zentralen, lokale KI-Auswertung von Sensordaten, kleine Server oder auch portable Geräte mit Display. Durch die geringe Größe könnte das Board auch in mobilen Projekten oder selbstgebauten Handhelds landen. Das Board fällt mit seinen Abmessungen von 65 × 32 mm kompakt aus und dürfte damit auch in Projekten Platz finden, bei denen ein Raspberry Pi zu groß ist.
Erhältlich ist das Board auf Amazon für 73,99 US-Dollar [2]. Dort bekommt man auch direkt einen aktiven Kühler mit dazu.
Wer wissen will, was man mit einem Raspberry Pi Zero alles anstellen kann, sollte sich unbedingt unseren Artikel zu Hackinggadgets für die Hosentasche [3] anschauen.
URL dieses Artikels:
https://www.heise.de/-11267955
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: akf / Erzeugt mit Nano Banana durch Make)
Der Slicer spielt eine zentrale Rolle im 3D-Druck-Workflow. OrcaSlicer gewinnt zunehmend an Bedeutung und erweitert seinen Funktionsumfang stetig.
OrcaSlicer veröffentlicht seine Updates üblicherweise in so hoher Frequenz, sodass man sich daran gewöhnt hat, dass nicht immer „Killer-Features“ enthalten sind. In der neuen Version 2.3.2 hat sich jedoch einiges geändert und wurde ergänzt.
Hinweis: Es gibt einige inoffizielle Webseiten, die OrcaSlicer anbieten – die oben verlinkte Seite ist die offizielle Quelle. Lade dir den Installer herunter oder nutze die portable Version, falls du die alte Installation behalten möchtest oder musst.
(Bild: OrcaSlicer)
Mit Multiline-Infill kann man Druckobjekte stabiler machen, wenn man die Wandstärke nicht erhöhen will oder kann. Das Multiline-Infill ist sauberer geworden und weist weniger Überschneidungen auf [4] (dank Clipper2-Bibliothek). Zudem ist es besser mit dem Hauptobjekt verbunden.
Die Flussrate lässt sich jetzt pro Feature statt nur pro Filament einstellen – etwa eine andere Flow-Rate für Infill als für Wände. Die Option findest du unter „Set other flow ratios“ im Quality-Tab.
(Bild: OrcaSlicer)
Das Brim arbeitet nun zuverlässiger mit der „Elephant Foot Compensation“ zusammen. Sich ablösende, kaum nutzbringende Brims gehören damit weitgehend der Vergangenheit an. Elephant-Foot-Compensation verhindert die Überextrusion des ersten Layers auf dem Druckbett. Dieser Faktor wird nun bei der Erzeugung von Brims einberechnet.
(Bild: OrcaSlicer)
Unter Preferences Control Slicing lässt sich „Auto slice after changes“ aktivieren. Die Wartezeit ist anpassbar, sodass man mehrere Änderungen vornehmen kann, bevor der Slicer loslegt. Da ein laufender Slicing-Vorgang aber bei neuen Parametern abgebrochen und neu gestartet wird, ist es auf schnellen Rechnern kaum nötig, den Wert hochzusetzen. Ein Feature, das ich lange vermisst habe, seit ich vom PrusaSlicer gewechselt bin.
Der Drucker-Tab ist jetzt grafischer und übersichtlicher. Der Düsendurchmesser lässt sich jetzt getrennt vom Drucker einstellen.
Statt eigenständiger Kopien (Clones) lassen sich Objekte jetzt auch als „Instances“ vervielfältigen. Ändert man eine Instanz, folgen die anderen automatisch – sei es bei Filament-Zuordnungen für Multifilament-Druck oder anderen Einstellungen. Das spart auch beim Slicing Zeit, da nur eine Instanz berechnet werden muss. Die Anzahl der Instanzen ist einstellbar, oder man füllt direkt das ganze Druckbett.
Zusätzlich werden inzwischen Kollisionen zwischen (besonders Instanzierten Objekten) besser erkannt und so behandelt, dass keine Fehldrucke entstehen.
Für farbige bzw. aus mehreren Filamentsorten zusammengesetzte Drucke auf Materialwechslern und Toolchangern wurden die Wipe-Tower-Verbesserungen aus Bambu Studio zu Orca portiert:
Die Einstellungen müssen in den jeweiligen Druckprofilen aktiviert werden:
FreshRSS Multimaterial -> Prime Tower -> Enable tower interface featuresCool down from interface boost during prime towerDie Art des Wipe Towers lässt sich inzwischen auch direkt im Druckerprofil auswählen.
Wer das Beste aus seinen Druckern und Filamenten herausholen möchte, sollte beides kalibrieren. In Version 2.3.2 sind die Kalibrierungs-Tools jetzt in der richtigen Reihenfolge im Menü sortiert. Außerdem werden die Firmwares für Input Shaper, Cornering/Jerk erkannt und entsprechend ausgewählt.
Im Drucker-Konfigurator werden nun zusätzliche Materialwechsel-Einheiten und Toolheads unterstützt. Diese lassen sich direkt aus dem Slicer steuern, und die Filamentbelegung der Toolheads ist interaktiv anpassbar. Dies ist noch als experimentell markiert, da es sich teilweise um schlecht dokumentierte Hardware handelt und die Hersteller natürlich eher ihr Ökosystem unterstützen.
Orca 2.3.2 unterstützt jetzt auch die neueren Bambu-Lab-Modelle wie H2D (Pro) und H2S. Außerdem gibt es weitere spezielle Verbesserungen für Bambulab-Nutzer.
Viele zusätzliche Änderungen und Verbesserungen mit Beispielbildern findet man im ausführlichen Changelog: OrcaSlicer 2.3.2 Beta Changelog [6]
In der Make 1/26 hatten wir einen ausführlichen Artikel über Tipps&Tricks für Slicer [7] und einen Artikel über Orca Slicer [8] und warum er immer beliebter wird.
URL dieses Artikels:
https://www.heise.de/-11265708
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein neues Tool berechnet den CO₂-Ausstoß von Claude-Code-Sessions. Laut dem Autor hat sich dabei gezeigt, wie man ihn um bis zu 70% senken kann.
Um die Umweltkosten durch die tägliche Nutzung von Claude Code greifbar zu machen, hat ein Entwickler ein Werkzeug gebaut, das den CO₂-Ausstoß für jede Sitzung berechnet und in Echtzeit in der Statuszeile anzeigt.
Der Programmierer arbeitet nach eigenen Angaben als Wirtschaftsberater, spezialisiert auf die Berechnung von Treibhausgasemissionen für große Unternehmen. Bei seiner täglichen Arbeit mit Claude Code kam ihm irgendwann sein eigener sorgloser Umgang mit generativer KI zuwiderlaufend vor.
Seine Antwort ist Claude-Carbon [1], ein auf Bash und SQLite basierendes Tool, das sich nahtlos in die Claude-Code-Umgebung integriert und die CO₂-Emissionen pro Sitzung in der Statuszeile neben den Kosten anzeigt.
(Bild: Claude-Carbon)
Über vier Monate und 367 Sessions hinweg maß der Entwickler etwa 215 kg CO₂-Äquivalente – was er auf ungefähr eine Tonne pro Jahr hochgerechnet hat. Das entspricht einem Hin- und Rückflug zwischen Paris und New York, allein durch die tägliche Nutzung von KI-Code-Tools verursacht, schreibt er in einem Blogpost. [2]
Die Berechnung beschränkt sich dabei auf die sogenannte Inferenz, also die Energie, die in Rechenzentren verbraucht wird, wenn das Modell die Prompts verarbeitet und Antworten bereitstellt. Training, Hardware-Herstellung, Kühlung und Rechenzentren-Konstruktion sind nicht inbegriffen – der echte Lebenszyklus-Fußabdruck ist also noch höher.
Claude-Carbon unterscheidet sich grundlegend von bestehenden Werkzeugen wie CodeCarbon [3]oder EcoLogits. Während CodeCarbon lokale Hardware-Ressourcen misst und sich nicht für Remote-API-Calls eignet, und EcoLogits als generische Python-Bibliothek fungiert, die API-Responses verschiedenster Anbieter abfängt, ist Claude-Carbon speziell für Claude Code entwickelt worden. Das Tool nutzt native Hooks und Settings der Claude-Code-Umgebung selbst. Es speichert alle Daten lokal in einer SQLite-Datenbank, kann historische Sessions nachträglich analysieren und generiert sogar PNG-Reportkarten für Social Media.
(Bild: codecarbon.io)
Der Autor betont, dass die Werte Schätzungen sind und keine präzisen Messungen. Anthropic veröffentlicht nämlich keine modellspezifischen Energiedaten. Die Faktoren für Sonnet stammen aus einer 2025er Studie (Jegham et al.) [4] über LLM-Inference-Energieverbrauch. Die Werte für Opus und Haiku sind Extrapolationen. Opus wird mit dem Faktor 3× Sonnet berechnet, Haiku mit 0,5× Sonnet.
Auch die CO₂-Intensität basiert auf US-Durchschnittswerten, nicht auf echten regionalen oder tageszeit-spezifischen Daten. Trotz dieser Unsicherheiten ist das Tool wertvoll für ein Größenordnungs-Bewusstsein – nur eben nicht für formale Treibhausgasbilanzen, so der Autor.
Durch die eigene Nutzung des Tools hat der Entwickler einige Einsichten gewonnen, wie sich der Verbrauch ohne Effizienzverlust senken lässt. Der größte Hebel zur Reduktion liegt in der Modellwahl. Opus verbraucht etwa dreimal so viele Token wie Sonnet, Haiku könnte gegenüber Sonnet bis zu 80 Prozent einsparen. Für Aufgaben wie File-Exploration oder Code-Review lohnt sich daher Haiku. Darüber hinaus können Werkzeuge wie RTK (Rust Token Killer) 60–90 Prozent der CLI-Token-Ausgabe herausfiltern, ohne dass die Qualität leidet.
Weiter lässt sich Thinking-Tokens auf 10.000 pro Message deckeln, was eine Reduktion um etwa 70 Prozent ermöglicht. Früheres Context-Compacting bei 50 statt 95 Prozent Auslastung hält Sessions schlanker.
Insgesamt lassen sich durch diese Maßnahmen die Emissionen von Claude-Code-Sessions um 50–70 Prozent reduzieren – von rund einer Tonne CO₂ pro Jahr auf 0,3–0,5 Tonnen.
Der Ersteller betont zudem, dass das Tool ein fundamentales Problem in den Fokus rückt: Anthropic veröffentlicht keine modellspezifischen Energiedaten. Google hatte im August 2025 als erster großer KI-Anbieter Per-Prompt-Daten für sein Gemini-Modell offengelegt [5] (0,24 Wh, 0,03 Gramm CO₂ pro Median-Anfrage). Anthropic – ebenso wie OpenAI – hält sich weiterhin bedeckt. Diese Transparenzlücke zu schließen, argumentiert er, wäre ein wichtiger Schritt, um KI-Nutzung wirklich nachhaltig zu gestalten.
Claude-Carbon [6] ist open source und läuft auf macOS ohne zusätzliche Installation.
URL dieses Artikels:
https://www.heise.de/-11264352
Links in diesem Artikel:
[1] https://github.com/gwittebolle/claude-carbon
[2] https://dev.to/gwittebolle/how-i-measured-1-tonne-of-co2-from-my-ai-coding-sessions-3b3d
[3] https://codecarbon.io/#about
[4] http://arxiv.org/abs/2505.09598
[5] https://cloud.google.com/blog/products/infrastructure/measuring-the-environmental-impact-of-ai-inference?hl=en
[6] https://github.com/gwittebolle/claude-carbon
[7] mailto:mch@make-magazin.de
Copyright © 2026 Heise Medien
(Bild: Waveshare)
Mit integriertem Display und Tastatur wird der Raspberry Pi zum mobilen Linux-Terminal für Maker.
Mit dem PocketTerm35 bringt Waveshare ein tragbares Linux-Terminal auf den Markt, das für den Einsatz mit dem Raspberry Pi 4 Model B und dem Raspberry Pi 5 vorgesehen ist. Das Gerät kombiniert Display, Tastatur und Stromversorgung.
Die Abmessungen des Handhelds betragen 93,5 × 168,5 × 37 mm. Verbaut ist ein 3,5-Zoll-IPS-Touchdisplay mit einer Auflösung von 640 × 480 Pixeln. Ergänzt wird das Display durch eine 67-Tasten-QWERTY-Tastatur (QWERTY entspricht dem US-Layout, deutsche Tastaturen haben ein „QWERTZ“-Layout. Umlaute fehlen und Satzzeichen sind anders verteilt) aus Silikon. Das reicht für Terminalbefehle, kleinere Code-Anpassungen oder das schnelle Editieren von Konfigurationsdateien. Wer längere Texte schreiben will, wird trotzdem vermutlich irgendwann wieder zur „großen“ Tastatur greifen (oder zumindest hoffen, dass die Autokorrektur gut funktioniert).
Im Inneren arbeitet ein Raspberry Pi – je nach Variante entweder ein Pi 4B mit 2 GB RAM oder ein Pi 5 mit 1 GB RAM. Alternativ gibt es auch Bausätze ohne Board, bei denen man dann den eigenen Pi 5 mit 16 GB RAM aus dem Tresor holen kann. Für die Steuerung von Peripherie wie Tastatur, Helligkeit oder Lautstärke ist zusätzlich ein RP2040-Mikrocontroller integriert. Das ist ein interessanter Ansatz, da sich so Eingaben und Systemfunktionen unabhängig vom Hauptsystem regeln lassen.
Das Gerät versteht sich als vollwertiges Linux-Terminal. Über HDMI wird das Display angebunden, während Touch-Eingaben per I2C laufen. Für Audio steht ein integrierter 2-Watt-Lautsprecher zur Verfügung, zusätzlich gibt es einen 3,5-mm-Klinkenanschluss. Die Stromversorgung erfolgt über USB-C oder eine optionale 5000-mAh-Lithiumbatterie. Dank integriertem UPS-Management kann das System nahtlos zwischen externer Stromquelle und Akku wechseln.
Für Maker ergeben sich daraus einige konkrete Einsatzszenarien. Das PocketTerm35 eignet sich etwa als mobiles Terminal für Headless-Systeme: Statt Laptop und Adapter mitzuschleppen, kann man direkt am Gerät auf einen Raspberry Pi zugreifen, Logs prüfen oder Dienste starten. Auch für IoT-Projekte lässt sich das Gerät als Steuer- und Diagnoseeinheit verwenden, etwa um Sensorwerte auszulesen oder Aktoren zu konfigurieren.
Neben klassischen Terminal-Anwendungen unterstützt das Gerät auch grafische Oberflächen sowie Systeme wie RetroPie. Damit lässt sich das PocketTerm35 theoretisch auch als Retro-Handheld verwenden.
Die Konstruktion kombiniert eine CNC-gefräste Aluminium-Front mit einer Kunststoffrückseite. Verschiedene Schnittstellen und Adapter liegen je nach Variante bei, darunter HDMI-Kabel, Montageplatten und Verbindungskabel für den Raspberry Pi.
Unterm Strich positioniert sich das PocketTerm35 zwischen Bastelprojekt und fertigem Werkzeug. Es ersetzt keinen Laptop, kann aber in vielen Situationen ein praktischer Begleiter sein. Vor allem dort, wo Platz, Gewicht oder Aufbauzeit eine Rolle spielen.
Erhältlich ist der Handheld im Waveshare-Shop [1] für 179,99 US-Dollar in der Pi-4-Variante und 148,99 in der Pi-5-Version. Die Bare-Bones-Versionen sind noch nicht erhältlich.
Wer bei der Erwähnung von RetroPie aufgehorcht hat, findet mit unserem DIY-Arcade auf Raspberry-Pi-Basis [2] vielleicht ein neues tolles Projekt.
URL dieses Artikels:
https://www.heise.de/-11259004
Links in diesem Artikel:
[1] https://www.waveshare.com/pocketterm35.htm?sku=34462
[2] https://www.youtube.com/watch?v=oSNMRQo8NTM
[3] https://www.heise.de/make
[4] mailto:das@heise.de
Copyright © 2026 Heise Medien
This is a release focussing on bug fixing, in particular regressions from the release 1.28.0.
Selected new features ✨:
Improved performance 🏎️:
Many bug fixes 🐛
This release has been made by @Alkarex, @Frenzie, @Inverle and newcomers @ciro-mota, @eveiscoull, @hackerman70000, @Hufschmidt, @johan456789, @martgnz, @mmeier86, @netsho, @neuhaus, @RobLoach, @rupakbajgain.
Full changelog:
transliterator_transliterate fallback (when the php-intl extension is unavailable) #8427lastUserModified database column also during mark-as-read action #8346session.cookie-lifetime #8446CURLOPT_ACCEPT_ENCODING #8376, simplepie#960, simplepie#962<template> element #8443.gitignore to ignore installed extensions #8372This is a major release, just in time for the holidays 🎄
Selected new features ✨:
userdate:PT1H for the past hourImproved performance 🏎️:
Selected bug fixes 🐛:
Breaking changes 💥:
This release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @andris155, @horvi28, @math-GH, @minna-xD and newcomers @Darkentia, @FollowTheWizard, @GreyChame1eon, @McFev, @jocmp, @larsks, @martinhartmann, @matthew-neavling, @pudymody, @raspo, @scharmach, @scollovati, @stag-enterprises, @vandys, @xtmd, @yzx9.
Full changelog:
userdate:PT1H for the past hour #8093\b and \B for regex search using PostgreSQL #8141~ subsequent-sibling #8154
Retry-After rules for proxies #8029, #8218data: to CSP in subscription controller #8253Retry-After #8195f.kind to ease migrations from FreshRSS versions older than 1.20.0 #8148config.custom.php during install #8033window.bcrypt object #8166chart.js v4 update #8298WordPress.com HTTP duplicates with WebSub Automattic/pushpress#16cli/health.php compatibility with OpenID Connect #8040cli/access-permissions.sh to detect the correct permission Web group such as www-data, apache, or httpexec() function for git update #8228DOMDocument::saveHTML() scrambling charset encoding in some versions of libxml2 #8296php-intl #8334<select> #8190Promise to async/await: #8182move #8214lib_rss.php with potential breaking changes for some extensions #8193,#[Deprecated] #8325--no-progress #8315This is a security-fix and bug-fix release for FreshRSS 1.27.x.
A few highlights ✨:
healthcheckframe-ancestorsThis release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @math-GH and newcomers @beerisgood, @nykula, @horvi28, @nhirokinet, @rnkln, @scmaybee.
Full changelog:
Retry-After #7875no-cache.txt #7907.yml and SERVER_DNS example #7858overflow-wrap instead of word-wrap #7898make target to generate the translation progress #7905entry_before_update and entry_before_add hooks for extensions #7977A few highlights ✨:
429 Too Many Requests and 503 Service Unavailable, obey Retry-Afterc: for categories like c:23,34 or !c:45,56Content-Security-Policy: frame-ancestorsThis release has been made by @Alkarex, @Inverle, @the7thNightmare and newcomers @Deioces120, @Fraetor, @Tarow, @dotsam, @hilariousperson, @pR0Ps, @triatic, @tryallthethings
Full changelog:
429 Too Many Requests and 503 Service Unavailable, obey Retry-After #7760c: for categories like c:23,34 or !c:45,56 #7696s parameter of streamId #7695Content-Security-Policy: frame-ancestors #7677referrerpolicy, ping #7770clean_hash() #7813, FreshRSS/simplepie#48:newest updated to PHP 8.5-alpha and Apache 2.4.65 #7773FRESHRSS_INSTALL and FRESHRSS_USER variables #7725onbeforeunload #7554<video poster="..."> and <image> #7636<code> inside of <pre> #7797data-auto-leave-validation #7785chart.js to 4.5.0 #7752, #7816This is a bug-fix release for FreshRSS 1.26.x
A few highlights ✨:
This release has been made by @Alkarex, @Inverle and newcomers @CarelessCaution, @the7thNightmare
Full changelog:
bgcolor, text, background, link, alink, vlink #7606This is a security-focussed release for FreshRSS 1.26.x, addressing several CVEs (thanks @Inverle) 🛡
A few highlights ✨:
Notes ℹ:
This release has been made by @Alkarex, @Frenzie, @hkcomori, @loviuz, @math-GH
and newcomers @dezponia, @glyn, @Inverle, @Machou, @mikropsoft
Full changelog:
<iframe srcdoc=""> #7494, CVE-2025-32015<button formaction=""> #7506Content-Security-Policy HTTP headers to favicons #7471, CVE-2025-31136Referrer-Policy: same-origin #6303, #7478ext.php #7479, CVE-2025-31134mod_filter to ensure that AddOutputFilterByType works #7419[unable to retrieve full-text content]
[unable to retrieve full-text content]
[unable to retrieve full-text content]
(Bild: Pincasso/Shutterstock.com)
Eine neue Methode erlaubt die Multiplikation großer Zahlen.
Die Klassen für Ganzzahltypen Int32, UInt32, Int64 und UInt64 bieten jeweils eine neue Methode BigMul() für die Multiplikation, die die Ergebnisse als Int64 und UInt64 bzw. Int128 und UInt128 zurückliefert (ohne Überlauf).
public void BigMul()
{
CUI.Demo();
long Value1 = long.MaxValue;
ulong Value2 = ulong.MaxValue;
Console.WriteLine("Value1: " + Value1.ToString("#,0"));
Console.WriteLine("Value2: " + Value2.ToString("#,0"));
CUI.H1("Normale Multiplikation");
Int128 e1 = Value1 * 2; // Überlauf! -2
UInt128 e2 = Value2 * 2; // Überlauf! 18446744073709551614
Console.WriteLine(e1.ToString("#,0")); // Überlauf! -2
Console.WriteLine(e2.ToString("#,0")); // Überlauf! 18446744073709551614
CUI.H1("Multiplikation mit BigMul()");
Int128 e3 = Int64.BigMul(Value1, 2); // 18.446.744.073.709.551.614
UInt128 e4 = UInt64.BigMul(Value2, 2); // 36.893.488.147.419.103.230
Console.WriteLine(e3.ToString("#,0")); // 18.446.744.073.709.551.614
Console.WriteLine(e4.ToString("#,0")); // 36.893.488.147.419.103.230
}
URL dieses Artikels:
https://www.heise.de/-10331981
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock.com)
In .NET 9.0 kann man neuerdings einen Globally Unique Identifier in der Version 7 mit Zeitstempel erzeugen.
Die .NET-Klasse System.Guid bietet seit .NET 9.0 neben der statischen Methode NewGuid(), die einen Globally Unique Identifier (GUID), alias UUID (Universally Unique Identifier), gemäß RFC 9562 [1] mit reinen Zufallszahlen (Version 4) erzeugt, nun auch eine weitere statische Methode CreateVersion7() mit einem Timestamp und einer Zufallszahl.
Folgender Code zeigt sowohl den Einsatz von NewGuid() als auch den von CreateVersion7():
public void Run()
{
CUI.Demo(nameof(FCL9_Guid));
for (int i = 0; i < 10; i++)
{
Guid guid = Guid.NewGuid();
Console.WriteLine($"Guid v4:\t{guid}");
}
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
CUI.Yellow("Warte 1 Sekunde...");
Thread.Sleep(1000);
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
}
(Bild: Screenshot (Holger Schwichtenberg))
Der Timestamp ist in UTC-Zeit in den ersten 64 Bits der GUID enthalten.
Zum Extrahieren des Zeitpunkts gibt es keine eingebaute Methode, man kann ihn aber folgendermaßen extrahieren:
public DateTimeOffset GetDateTimeOffset(Guid guid)
{
byte[] bytes = new byte[8];
guid.ToByteArray(true)[0..6].CopyTo(bytes, 2);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bytes);
}
long ms = BitConverter.ToInt64(bytes);
return DateTimeOffset.FromUnixTimeMilliseconds(ms);
}
URL dieses Artikels:
https://www.heise.de/-10316051
Links in diesem Artikel:
[1] https://www.rfc-editor.org/rfc/rfc9562.html
[2] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock)
In C# 13.0 hat Microsoft den Einsatzbereich von ref struct unter anderem zum Implementieren von Schnittstellen erweitert.
Seit C# 7.2 gibt es Strukturen, die immer auf dem Stack leben und niemals auf den Heap wandern können: ref struct. In C# 13.0 hat Microsoft den Einsatz von ref struct erweitert.
Solche Typen können nun:
where T : allows ref struct verwenden.yield verwendet werden. Allerdings darf die Struktur nicht länger leben als der aktuelle Durchlauf des Iterator.Task oder Task<T> liefern, genutzt werden.Weiterhin gilt aber: Wenn man einen Typ als ref struct deklariert, ist ein Boxing nicht mehr möglich. Der Einsatz von ref struct ist daher begrenzt. So kann man beispielsweise kein Array und keine List<T> daraus erzeugen.
Folgender Code zeigt einen eigenen Typ mit ref struct, der eine Schnittstelle implementiert:
internal interface IPerson
{
int ID { get; set; }
int Name { get; set; }
}
// NEU seit C# 13.0: ref struct kann Schnittstelle implementieren
ref struct Person : IPerson
{
public int ID { get; set; }
public int Name { get; set; }
// ToString()
public override string ToString()
{
return "Person #" + ID + " " + Name;
}
}
}
class Client
{
public void Run()
{
Person p = new Person();
p.ID = 1;
p.Name = 2;
Console.WriteLine(p.ID);
Console.WriteLine(p.Name);
// Das ist alles nicht erlaubt!
// IPerson i = p; // Casting auf Schnittstelle
// List<Person> PersonList = new(); // List<T>
// PersonList[] PersonArray = new Person[10]; // Array
}
}
URL dieses Artikels:
https://www.heise.de/-10307583
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Vova Shevchuk / Shutterstock.com)
Psychologische Tricks werden scheinbar erfolgreich gegen ein LLM eingesetzt – aber ist das wirklich relevant?
Einem Psychologen ist es gelungen, Sicherheitsrichtlinien diverser Large Language Models (LLMs) mit Tricks auszuhebeln, die eigentlich zur Manipulation von Menschen dienen. Mit Gaslighting hat Luke Bölling LLMs [1] dazu gebracht, einen Text zu erzeugen, der scheinbar erklärt, wie man einen Molotowcocktail [2]herstellt (Siehe dazu auch der heise-Artikel [3] von Niklas Jan Engelking).
Gaslighting [4] ist ein psychologisches Konzept: Es ist "eine Form von psychischer Manipulation …, mit der Opfer gezielt desorientiert, verunsichert und in ihrem Realitäts- und Selbstbewusstsein allmählich beeinträchtigt werden". LLMs generieren jedoch lediglich Texte. Sie nehmen keine Realität wahr und haben kein Selbstbewusstsein. Der Artikel argumentiert, dass dieser Angriff trotzdem funktioniert, weil das Trainingsmaterial von Menschen geschrieben wurde und daher auch Konzepte wie Gaslighting darin vorkommen. Dennoch dürfen wir nie vergessen, dass LLMs nichts weiter als Textgeneratoren sind. Sie haben keine Emotionen, wie die zitierte Arbeit auch feststellt. Daher werde ich im weiteren Text den Begriff "Textgenerator" verwenden, da er besser beschreibt, was LLMs tatsächlich tun.
Textgeneratoren können offensichtlich einen Text erzeugen, der wie eine plausible Anleitung zur Herstellung eines Molotowcocktails erscheint – genau, wie sie scheinbar plausible Verweise auf Gerichtsentscheidungen [5] für einen Anwalt generieren können. Und obwohl diese Verweise für den Anwalt überzeugend klingen, sind sie in Wirklichkeit erfunden. Das ist eines der Probleme mit Textgeneratoren: Sie sind darauf optimiert, überzeugend zu klingen, und versuchen so, das kritische Hinterfragen ihrer Ergebnisse zu vermeiden.
Die eigentliche Frage lautet also: Würde die angebliche Anleitung zur Herstellung eines Molotowcocktails tatsächlich funktionieren? Ich habe mit Lucas Dohmen einen Stream über Textgeneratoren [6] gemacht, und eine der zentralen Erkenntnisse war: Man muss die Ergebnisse von Textgeneratoren überprüfen, um sicherzustellen, dass sie korrekt und nicht erfunden sind. Der zitierte Artikel scheint dies nicht zu tun – das heißt, die gesamte Information über Molotowcocktails könnte schlicht "halluziniert" sein. Das Problem der Generierung von Fake-Informationen durch Textgeneratoren ist nämlich so bekannt, dass es einen eigenen Begriff (Halluzination) gibt. Tatsächlich ist "halluziniert" der falsche Begriff, denn "unter Halluzination [7]versteht man eine Wahrnehmung, für die keine nachweisbare externe Reizgrundlage vorliegt". Textgeneratoren haben jedoch keine Wahrnehmungen. Daher sollten wir dieses Phänomen korrekt als "Generierung von Fake-Informationen" benennen.
Wir können die Information über den Molotowcocktail nicht überprüfen, da sie im Originalartikel unkenntlich gemacht wurde – was natürlich absolut sinnvoll ist. Ich würde mich aber nicht auf diese Informationen verlassen, um tatsächlich einen improvisierten Brandsatz zu bauen.
Der Artikel behauptet, dieses Problem sei ein Sicherheitsrisiko bei Textgeneratoren. Falls das wirklich der Fall wäre, bestünde die Lösung darin, sensible Informationen aus dem Trainingsmaterial auszuschließen. Das Anpassen der Trainingsdaten wäre ohnehin sinnvoll, beispielsweise aufgrund von Urheberrechtsproblemen. Aus irgendeinem Grund scheint Urheberrecht für Textgeneratoren nicht zu gelten, während es für Menschen schwere Folgen [8]haben kann. Warum sollte es nicht möglich sein, Anleitungen zur Herstellung von improvisierten Brand- oder Sprengsätzen aus dem Trainingsmaterial zu entfernen? Wenn das zu viel Aufwand ist, dann ist das Problem vielleicht gar nicht so groß.
Dieses "Sicherheitsproblem" wäre auch nur dann ein echtes Problem, wenn der Textgenerator keine Fake-Informationen generiert hätte – dazu sagt der Artikel jedoch nichts. Falls es Fake-Informationen sind, könnte man es vielleicht als eine Art Honeypot [9] betrachten, um Menschen von echten Informationen fernzuhalten?
Doch die eigentliche Frage ist: Wäre dies wirklich der einfachste Weg, um an solche Informationen zu gelangen? Angenommen, ich plane, einen Molotowcocktail zu bauen – würde ich komplizierte "psychologische Angriffe" auf einen Textgenerator durchführen, um eine möglicherweise falsche Antwort zu erhalten? Gibt es einfachere und präzisere Möglichkeiten? Also habe ich den naheliegenden Weg ausprobiert: eine Suche mit einer Suchmaschine. Zwei Klicks später fand ich ein Dokument, das detailliert erklärt, wie man anspruchsvolle improvisierte Sprengsätze herstellt – und ich habe guten Grund zu glauben, dass diese Anleitungen tatsächlich funktionieren. Zugegeben, dieses spezielle Dokument beschreibt nicht, wie man einen Molotowcocktail baut, aber es erklärt eine Vielzahl anderer Vorrichtungen. Diese Recherche selbst nachzuvollziehen, ist sicher spannend.
LLMs sind Textgeneratoren, die potenziell erfundene Informationen produzieren – das ist bekannt. Es mag ausgeklügelte Methoden geben, um sie dazu zu bringen, Texte zu generieren, die sensible Informationen zu enthalten scheinen – doch diese könnten schlicht Falschinformationen sein. Häufig gibt es einfachere Wege, um an sensible Informationen zu gelangen, insbesondere wenn es um improvisierte Brand- oder Sprengsätze geht. Daher sehe ich keinen Grund, "psychologische" Tricks auf Textgeneratoren anzuwenden – denn genau das sind LLMs letztlich.
URL dieses Artikels:
https://www.heise.de/-10334947
Links in diesem Artikel:
[1] https://humandataexperience.substack.com/p/librarian-bully-attack-gaslighting
[2] https://de.wikipedia.org/wiki/Molotowcocktail
[3] https://www.heise.de/news/Neuer-LLM-Jailbreak-Psychologe-nutzt-Gaslighting-gegen-KI-Filter-10332571.html
[4] https://de.wikipedia.org/wiki/Gaslighting
[5] https://news.bloomberglaw.com/litigation/lawyer-sanctioned-over-ai-hallucinated-case-cites-quotations
[6] https://www.heise.de/news/software-architektur-tv-KI-und-LLMs-kritisch-betrachtet-10287426.html
[7] https://de.wikipedia.org/wiki/Halluzination
[8] https://en.wikipedia.org/wiki/Aaron_Swartz#United_States_v._Aaron_Swartz
[9] https://de.wikipedia.org/wiki/Honeypot
[10] mailto:map@ix.de
Copyright © 2025 Heise Medien
(Bild: erzeugt mit KI durch iX)
Automatisiertes Refactoring klingt verlockend – doch lässt sich Codequalität wirklich auf Knopfdruck verbessern, oder braucht es am Ende doch den Menschen?
Heute habe ich eine große Ankündigung für Sie – eine, die für viele Entwicklerinnen und Entwickler wohl einem echten Traumszenario gleichkommt. Ein Gedanke, der so bestechend einfach klingt, dass man sich fragen könnte, warum es so etwas nicht schon längst gibt. Sicher kennen auch Sie Gespräche im Team, in denen dieser Wunsch immer wieder auftaucht – meist mit ironischem Unterton, aber manchmal durchaus mit einem Funken Hoffnung.
Stellen Sie sich vor, Sie könnten Ihren kompletten Codestand einfach in eine ZIP-Datei packen, per HTTP an einen Service hochladen – und wenige Minuten später erhalten Sie ihn vollständig refactored zurück: besser strukturiert, mit klaren Abhängigkeiten, sinnvoll modularisiert, mit sprechenden Namen, nachvollziehbarer Architektur und aussagekräftigen Tests. Inklusive aktualisierter Dokumentation, vollständig durchgelintet und formatiert. Einmal hochladen, und der Code sieht anschließend aus, als hätte ein erfahrenes Senior-Architekturteam drei Wochen intensiv daran gearbeitet. Genau das haben wir jetzt Realität werden lassen und nennen es: "Refactoring as a Service".
Die Idee ist so einfach wie genial: Haben Sie ein Repository, dessen Zustand nicht mehr ganz optimal ist? Kein Problem: Sie laden den Code einfach über unsere API hoch oder verweisen auf ein Git-Repository mit einem gültigen Token – der Rest passiert automatisch im Hintergrund. Unser Service analysiert den Code mit statischen und dynamischen Verfahren, führt eine kombinierte AST- und Graphanalyse durch, identifiziert strukturelle Schwächen, erkennt Anti-Patterns, bewertet essenzielle Metriken wie zyklomatische Komplexität, Kohäsion, Kopplung, Testabdeckung und Architekturkonformität – und erstellt daraus ein kontextsensitives, semantisch fundiertes Refactoring-Konzept, das automatisiert umgesetzt wird. Die resultierende Codebasis ist nicht nur schöner und verständlicher, sondern auch modularer, wartbarer und besser getestet. Selbstverständlich integriert sich das Ganze nahtlos in CI/CD-Prozesse und ist über eine OpenAPI-Schnittstelle vollständig automatisierbar.
Weil uns das noch nicht genug war, wird zusätzlich eine KI-gestützte Kommentierung vorgenommen, die basierend auf Codeverständnis sowie Projektkontext passgenaue Kommentare und Erläuterungen hinzufügt – sowohl auf Code- als auch auf Modul- und Architekturebene. Die Testabdeckung wird nicht nur erhöht, sondern zielgerichtet erweitert, mit besonderem Augenmerk auf Pfadabdeckung, Grenzfälle, Randbedingungen und semantisch relevante Kombinationen. All dies orchestriert ein auf Kubernetes skalierendes Service-Backend, das selbst größere Projekte in kurzer Zeit bewältigt. Für besonders kritische Projekte bieten wir zudem eine Audit-Funktion: Jede Änderung bleibt einzeln nachvollziehbar, jeder Commit wird semantisch kommentiert, jeder Refactoring-Schritt dokumentiert. Kurz gesagt: Der perfekte Begleiter für Softwareteams, die Qualität ernst nehmen, dabei aber ihren Fokus auf die eigentliche Entwicklung legen wollen.
Die eigentliche Magie entsteht durch die Kombination verschiedener Technologien und Ansätze: Statische Analyse alleine hilft wenig, wenn sie den fachlichen Kontext nicht berücksichtigt. LLMs alleine schreiben zwar Code, wissen aber nicht, ob dieser wirklich zu Ihrem Projekt passt. Clean-Code-Prinzipien sind essenziell, lösen aber nicht das grundlegende Problem der strukturellen Überarbeitung. Erst die systematische Verbindung dieser Ansätze schafft etwas, das sich wirklich als Refactoring im engeren Sinne bezeichnen lässt. Genau das macht "Refactoring as a Service" nicht nur zu einem interessanten Tool, sondern zu einem echten Gamechanger.
Natürlich – und das war uns von Anfang an bewusst – ersetzt "Refactoring as a Service" nicht den Menschen. Unser Ziel war es nie, die Expertise erfahrener Entwicklerinnen und Entwickler überflüssig zu machen. Ganz im Gegenteil: Wir wollten diese Expertise entkoppeln, also ermöglichen, dass sie unabhängig von individueller Verfügbarkeit, Projektkontext oder Zeitdruck eingesetzt werden kann. Deshalb haben wir all unser Wissen, unsere Erfahrungen und Prinzipien in diesen Service einfließen lassen – damit andere Teams davon profitieren können, ohne dass wir immer persönlich involviert sein müssen.
Das ist nicht nur für Entwicklerinnen und Entwickler spannend, sondern gleichermaßen interessant für Softwarearchitektinnen und -architekten, Teamleads und CTOs sowie alle, die sich intensiv mit Softwarequalität und Wartbarkeit auseinandersetzen. Denn Refactoring ist nicht nur ein technisches Hilfsmittel, sondern ein strategisches Instrument. Es entscheidet maßgeblich über Lebensdauer, Änderbarkeit und Erweiterbarkeit – und damit letztlich über den wirtschaftlichen Erfolg eines Projekts. Genau deshalb möchten wir mit "Refactoring as a Service" dazu beitragen, dass mehr Teams die Möglichkeit erhalten, ihre Codebasis auf ein solides und wartbares Fundament zu stellen.
An dieser Stelle fragen Sie sich vermutlich bereits: Klingt vielversprechend – doch wie viel kostet das Ganze? Wann und wie kann ich es ausprobieren? Die Antwort auf diese Fragen lautet leider: gar nicht. Denn heute ist der 1. April, und "Refactoring as a Service" existiert nicht.
Doch bevor Sie enttäuscht sind: Die Idee hinter "Refactoring as a Service" – also der Wunsch nach automatisiertem, reproduzierbarem und skalierbarem Refactoring – ist real und absolut verständlich. Wer von uns kennt nicht den Frust, sich durch Altlasten zu kämpfen, zu fragen, was sich jemand bei einem Stück Code gedacht haben könnte, und den Wunsch, einfach einen Knopf drücken zu können: "Jetzt Refactor" – klick, fertig. Leider ist es nicht ganz so einfach, und dafür gibt es gute Gründe.
Refactoring ist eben nicht nur eine technische Tätigkeit, sondern eine bewusste Entscheidung: eine Entscheidung darüber, wie Code strukturiert werden soll. Welche Konzepte getrennt, welche zusammengeführt werden müssen. Welche Benennungen welche Bedeutung tragen. Welche Architekturprinzipien zum Einsatz kommen, wann bestimmte Patterns sinnvoll sind und wann man bewusst darauf verzichten sollte. All das hängt unmittelbar mit einem fundierten fachlichen Verständnis zusammen: Sie können keine gute Struktur aufbauen, wenn Sie nicht wissen, was diese Struktur abbilden soll. Sie können keine Struktur sinnvoll bewerten, wenn Sie nicht verstehen, welche Anforderungen diese erfüllen muss. Genau deshalb ist Refactoring auch nichts, was sich rein nach Schema F automatisieren ließe. Es handelt sich eben nicht um einen rein technischen Akt, sondern um einen analytischen und diskursiven Prozess.
Natürlich gibt es Tools, Plug-ins und LLMs. Doch keines dieser Hilfsmittel kann Ihnen beantworten, ob eine Methode in einen Service oder in einen Controller gehört. Keines erkennt zuverlässig, ob eine bestimmte Implementierung noch zur aktuellen Realität passt oder lediglich ein Relikt früherer Feature-Iterationen darstellt. Keines entscheidet für Sie, ob ein Name tatsächlich treffend oder nur historisch gewachsen ist. Kein Tool abstrahiert Fachlichkeit umfassend, ersetzt Kommunikation oder übernimmt Verantwortung. All diese Dinge erfordern Erfahrung, Kontextverständnis, Empathie – also letztlich Menschen.
Deshalb ist gutes Refactoring stets gute Teamarbeit. Es bedeutet, innezuhalten, Code bewusst erneut zu lesen, zu verstehen, was er ausdrücken möchte, und anschließend in kleinen, wohlüberlegten Schritten etwas Besseres daraus zu machen. Etwas Klareres und Stabileres, das den Alltag erleichtert und nicht erschwert. Genau darin liegt auch die Verantwortung beim Refactoring. Wer refactored, entscheidet sich für langfristige Qualität – und gegen kurzfristige Bequemlichkeit. Das ist nicht immer einfach.
In vielen Teams fehlt dafür oft Zeit, Mut oder Rückendeckung. Features werden entwickelt, Stories geliefert und der Durchsatz optimiert – doch der Boden, auf dem alles steht, wird selten stabilisiert. Je länger das andauert, desto brüchiger wird das Fundament. Irgendwann wächst Refactoring dann zu einem Mammutprojekt heran, das niemand mehr anfassen möchte – obwohl anfangs nur wenige kleine Schritte nötig gewesen wären. Genau das darf nicht passieren.
Was also ist der bessere Weg? Sehen Sie Refactoring nicht als einmalige, große Aufgabe, sondern als kontinuierlichen Prozess. Machen Sie Refactoring zum festen Bestandteil Ihres Alltags, jeder Story, jedes Features, jedes Sprints. Refactoring ist nicht etwas, das man macht, wenn gerade Zeit übrig bleibt – sondern etwas, das man stets tun sollte, um sich die Zukunft deutlich einfacher zu gestalten. Das bedeutet konkret: kleine Schritte, regelmäßige Reviews, klare Verantwortlichkeiten, Mut zur Veränderung und ein gemeinsames Verständnis im Team, dass gute Software niemals Zufall ist, sondern das Ergebnis von Haltung, Prinzipien und kontinuierlicher Pflege.
URL dieses Artikels:
https://www.heise.de/-10333543
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] mailto:mai@heise.de
Copyright © 2025 Heise Medien
