Gerade in der heutigen Zeit ist es vielleicht auch gerade keine so gute Idee, mit Themen für Anfänger in einem technischen Bereich zu starten.
Nie war es einfacher, einfach die KI zu bestimmten Themen zu befragen, oder gleich alles generieren zu lassen. Lohnt es sich da überhaupt noch, Tutorial-Videos zu veröffentlichen?
Ich werde mein Glück einfach versuchen. Ich starte mit einer Reihe an Videos zum Thema Ruby on Rails, die sich klar an Beginner richten.
Das erste Video kümmert sich daher gleich um einen der wichtigsten Aspekte einer Web-Anwendung – den Validierungen von Nutzereingaben.
Der Code zur Episode steht auf GitHub bereit.
Code vor der Episode: https://github.com/webmatze/demo-shop/tree/episode-001-before
Code nach der Episode: https://github.com/webmatze/demo-shop/tree/episode-001-after
Wenn die Serie gut ankommt (was für mich schon wenige Aufrufe sein können), werde ich weitere Videos veröffentlichen. Also seid schonmal vorgewarnt. :)
]]>Nur eben nicht am Mac.
Denn wenn du auf Brothers Support-Seite den PJ-623 auswählst, bekommst du genau drei Betriebssystem-Familien angeboten: Windows, Linux und Android. Kein macOS. Nicht "veraltete Version", nicht "nur bis Catalina" – schlicht gar nichts. Brother stellt nach eigener Aussage keine Software mehr für Mac-Systeme bereit, die älter als die letzten drei sind, und der PJ-623 ist aus diesem Fenster längst herausgefallen.
Ich wollte ihn trotzdem an meinem M-Mac unter macOS 26 nutzen. Und es geht. Mit einem kleinen Trick.
Der PJ-623 gehört zur PocketJet-6-Serie. Deren Nachfolger, die PocketJet-7-Serie, wird von Brother bis heute gepflegt – für den PJ-763 gibt es einen aktuellen macOS-Treiber, ausdrücklich für macOS 26.
Und beide Serien sprechen einen sehr eng verwandten Raster-Befehlssatz. Der Treiber schickt am Ende Zeilen von Schwarz-Weiß-Pixeln an einen Thermokopf, und dieser Teil hat sich zwischen PJ-6 und PJ-7 kaum verändert.
Die Wette lautet also: Treiber des PJ-763 installieren, aber den PJ-623 damit ansteuern. Bei mir ist sie aufgegangen.
Geh auf die Download-Seite des PJ-763 – nicht die deines eigenen Druckers:
support.brother.com > PJ-763 > macOS 26
Dort brauchst du aus dem Abschnitt Treiber nur den Eintrag "Drucker Treiber" (bei mir Version 1.8.0c, rund 27 MB). Das .pkg installierst du ganz normal.
Das Printer Setting Tool kannst du dir sparen. Es wird den PJ-623 ohnehin nicht erkennen, weil es die Modellkennung abfragt.
Jetzt kommt der entscheidende Teil, und hier geht es schief, wenn du zu schnell klickst.
Ab hier verhält sich der PJ-623 wie ein ganz normaler Drucker. Testseite drucken, fertig.
Falls der Ausdruck streifig oder verzerrt ist oder der Drucker das Papier einfach durchschiebt: Probier statt der PJ-763-PPD einmal PJ-762 oder PJ-722. Die sind minimal anders parametrisiert, und je nach Firmware-Stand deines Geräts passt eine davon besser.
Passiert dagegen überhaupt nichts, hilft der Umweg über einen Druckserver. Für Linux gibt es nämlich einen offiziellen PJ-623-Treiber, auch als Raspbian-Paket. Ein Raspberry Pi mit dem Drucker am USB-Port, CUPS-Freigabe an – und der Mac druckt per IPP darauf, ohne je einen Treiber gesehen zu haben.
Was dagegen nicht funktioniert: den Linux-Treiber direkt auf macOS zu ziehen. Die CUPS-Filter in dem Paket sind x86-Linux-Binaries und auf Apple Silicon schlicht nutzlos.
Bevor du ein funktionierendes Stück Hardware wegwirfst, weil der Hersteller den Support eingestellt hat: Schau nach, was der Nachfolger kann. Sehr oft ist es dieselbe Maschine mit einem neueren Aufkleber.
Niemand hat das jemals eindrucksvoller verkörpert als _why (auch bekannt als why the lucky stiff).
In den 2000er-Jahren war _why eine Kultfigur der Ruby-Community. Er war Programmierer, Zeichner, Musiker, Geschichtenerzähler und Visionär in einer Person. Und dann – auf dem Höhepunkt seiner Bekanntheit – löschte er sich im August 2009 innerhalb weniger Stunden komplett aus dem Internet.
Das ist die Geschichte eines Phantoms, das die Herangehensweise einer ganzen Generation von Entwicklern an Code nachhaltig geprägt hat.
Wer in den Jahren 2003 bis 2009 in der Ruby-Szene unterwegs war, kam an _why schlicht nicht vorbei. Während die Tech-Welt versuchte, Softwareentwicklung immer strukturierter, korporativer und geschäftsmäßiger zu gestalten, brachte _why das absolute Gegenteil ein: pure Freude, Anarchie und infantile Kreativität.
Er war kein gewöhnlicher Open-Source-Maintainer. Seine Präsentation auf Konferenzen bestand nicht selten daraus, dass er Musik mit seiner Band The Thirsty Cups auf der Bühne spielte, Cartoons projizierte und dazu live Ruby-Code tippte.
Er trug stets sein Pseudonym why the lucky stiff – kurz _why. Seine Identität hielt er sorgfältig geheim. Doch es war keine düstere oder abweisende Anonymität; es war wie eine bunte Theatermaske, die es ihm erlaubte, vollkommen frei und ohne das Korsett einer korporativen Identität zu erschaffen.
_why hinterließ Dutzende von Bibliotheken, Tools und Experimenten. Einige davon waren hochfunktionale Werkzeuge, andere schiere Kunstprojekte.
Wer heute Ruby lernen möchte, greift zu sachlichen Fachbüchern oder Dokumentationen. Doch 2004 veröffentlichte _why sein legendäres Buch: Why's (Poignant) Guide to Ruby.
Es ist wahrscheinlich das ungewöhnlichste Programmierbuch, das je geschrieben wurde. Anstatt trockener Syntaxerklärungen bot der Poignant Guide eine wilde Mischung aus surrealen Comics, sprechenden Füchsen, philosophischen Exkursen und dem heute legendären Begriff "Chunky Bacon".
_why brachte Tausenden von Menschen Ruby bei – nicht indem er ihnen zeigte, wie man Enterprise-Software baut, sondern indem er ihnen zeigte, wie viel Spaß das Denken in Code machen kann.
"When you don’t create things, you become defined by your tastes rather than such ability. Your tastes only narrow & exclude people. So create."
— _why
_why hatte eine tiefgreifende Vision: Jeder Mensch sollte programmieren können. Lange bevor Plattformen wie Scratch oder moderne No-Code-Tools populär wurden, entwickelte er Hackety Hack, ein Lernprogramm für Jugendliche und Einsteiger. Um GUIs (grafische Benutzeroberflächen) so einfach wie möglich zu machen, schrieb er Shoes – ein winziges, buntes Toolkit, mit dem man in unter fünf Zeilen Ruby-Code ein interaktives Fenster auf den Bildschirm zaubern konnte.
Auch technisch war _why ein absolutes Genie:
Camping: Ein vollständiges Web-Framework in der Tradition von Ruby on Rails – allerdings in weniger als 4 Kilobyte Code komprimiert!
Hpricot: Ein extrem schneller, toleranter HTML/XML-Parser, der jahrelang der Standard in der Ruby-Welt war.
Syck: Der ursprüngliche YAML-Parser für den Ruby-Core.
Am 19. August 2009 passierte das Unfassbare.
Internet-Detektive hatten nach jahrelanger Recherche seine reale Identität aufgedeckt und seinen bürgerlichen Namen im Netz veröffentlicht. Es gab keine große Enthüllungsshow, keine Reaktion und keine Verfolgungsjagd.
_why zog die Konsequenz, die für ihn die einzig logische war: Er drückte auf den roten Knopf.
Innerhalb weniger Stunden löschte er all seine Webseiten, seine Twitter-Accounts, seine GitHub-Repositories und seine Blogs. Sämtlicher Code, alle Comics, alle Essays – weg. In der Ruby-Community bezeichnet man dieses Ereignis bis heute ehrfurchtsvoll als "The Great Poof" (Das große Verpuffen).
Auch wenn sein bürgerlicher Name damals kurzzeitig durch Foren geisterte und man ihn mit einer einfachen Suche finden könnte: Ich nenne ihn hier nicht. _why wollte als Künstlerfigur wahrgenommen werden, nicht als Privatperson. Seine Anonymität war keine Pose, sondern eine Grenze, die er gezogen hat. Seinen bürgerlichen Namen zu verschweigen, ist das Mindeste an Respekt, das wir diesem Ausnahmekünstler für all das, was er der Community geschenkt hat, zollen können.
Nach seinem Rückzug formierte sich die Community augenblicklich: Binnen Tagen wurden Mirrors seiner Repositories, seine Bücher und seine Kunstwerke von Fans rekonstruiert und archiviert (u.a. auf why-archive).
Warum fasziniert uns die Geschichte von _why auch viele Jahre später noch so sehr?
Weil er uns an das Kerngefühl erinnert, warum die meisten von uns überhaupt mit dem Programmieren angefangen haben. Es war nicht das Verlangen nach Jira-Tickets, Sprint-Planungen oder OKRs. Es war die magische Erfahrung, leere Textdateien in lebendige Welten zu verwandeln.
_why hat gezeigt, dass:
Code eine Form des persönlichen Ausdrucks sein kann: Programmieren darf bunt, seltsam und humorvoll sein.
Community von Freundlichkeit lebt: Das berühmte Ruby-Motto MINSWAN ("Matz is nice so we are nice") wurde durch _whys herzliche und einladende Art maßgeblich geformt.
Sharing Caring ist: Er verschenkte all seine Arbeit bedingungslos an die Welt.
_why ist seit über 15 Jahren aus dem öffentlichen digitalen Leben verschwunden. Ob er heute noch programmiert, Musik macht oder einfach sein Leben abseits des Bildschirms genießt, wissen wir nicht.
Doch sein Geist lebt in der Open-Source-Welt weiter. Jedes Mal, wenn wir ein Tool bauen, das einfach nur Freude macht, oder wenn wir einem Anfänger mit Geduld und Humor etwas erklären, führen wir seine Idee fort.
Danke für alles, _why. Wo auch immer du steckst: Chunky Bacon!
]]>Aber im Laufe der Zeit sind diese Abenteuer immer weniger geworden. Nicht, weil mich das Thema nicht mehr interessiert – ich arbeite tatsächlich jeden Tag als "Webentwickler" in meinem Beruf - aber ich habe langsam das Gefühl, das die Zeit der technischen Blogs sich seinem Ende nähert.
In Zeiten von AI ist der erste Reflex, wenn man sich mit einem Thema beschäftigt, nicht mehr die Suche nach interessanten Blog-Beiträgen anderer Entwickler. Stattdessen fragt man einfach die KI nach Details und bekommt immer häufiger auch die ausreichenden Antworten. Selbst auf Google klickt man nicht mehr auf die Suchergebnisse, sondern bekommt die Antwort direkt an erster Stelle angezeigt.
Wer liest dann überhaupt noch meinen Blog?
Ich habe das Gefühl – nur noch die KI selbst – wenn überhaupt.
Ich bin daher zu der Erkenntnis gekommen, dass ich vorranging nicht mehr für andere Entwickler oder Gleichgesinnte schreiben möchte (schon gar nicht nur für die KI), sondern ich möchte für mich schreiben.
Denn eigentlich ist es doch das Schreiben an sich, dass mir Spaß macht. Technische Artikel kann die KI hundertmal besser schreiben als ich. Aber die eigenen Gedanken und Gefühle aufs Papier zu bringen (oder in diesem Fall ins Blog), dass kann einem die KI nicht abnehmen.
Und das ist auch der Grund, warum ich die Ausrichtung dieses Blogs überdenke und den Fokus in Zukunft weniger auf technische Beiträge, sondern auf das Schreiben selber lenken möchte.
Um das zu unterstreichen, habe ich sogar das komplette Design der Seiten so angepasst, dass es das Geschriebene hervorhebt. Das Handwerkliche. Keine kalten, glatten Beiträge, keine Perfektion, sondern authentische Gefühle, unfertige Gedanken.
Ich habe mich in der letzten Zeit sehr intensiv mit dem Thema Schreiben auseinandergesetzt. Ja ich habe sogar zwei kleinere Bücher geschrieben. Und ich bin dabei an Software zu arbeiten, die mich (und andere) beim Schreiben unterstützen soll. Doch mehr dazu später.
Das Schreiben besitzt also gerade einen ziemlich großen Fokus in meinem Leben und vielleicht führt das ja auch dazu, dass ich wieder mehr Spaß an meinem eigenen Blog finden werde.
Wer auch immer bis hierhin gelesen hat... Schön das du da bist!
]]>Zwei Wanderer im tiefen Wald,
jeder sucht sein eignes Licht.
Der eine geht im Winde kalt,
der andre sieht ihn nicht.
Doch wer des Bruders Spuren liest
und teilt den warmen Mantel schwer,
merkt, wie ein Strom zusammenfließt,
wo vorher Ödnis wär‘.
Man hält sie fest, indem man lässt,
sie wächst, wenn man sie teilt.
Sie baut sich selbst ein sichres Nest,
wenn man ihr nicht ereilt.
Ein Rätsel, das im Schweigen spricht
und ohne Fesseln bindet –
wer sucht, der sieht die Spuren nicht,
doch wer verliert, der findet.
Wenn es dann im Frontend interaktiv werden musste, zum Beispiel bei einem Modaldialog für eine Bestätigung oder ein Einstellungsfenster, griff ich fast schon reflexartig zu schwerem Besteck: Bootstrap-Klassen, Tailwind UI-Komponenten oder custom Stimulus-Controllern, die mühsam das Ein- und Ausblenden regeln.
Vor Kurzem habe ich mich jedoch gefragt: Gibt es da mittlerweile nicht etwas Moderneres direkt im Browser?
Die Antwort lautet: Ja, und es ist genial! Das native HTML-Element <dialog> löst eines der nervigsten Frontend-Probleme komplett ohne externe JavaScript-Bibliotheken. In diesem Artikel zeige ich dir, wie du als Backend- oder Fullstack-Entwickler mit minimalem Aufwand moderne, barrierefreie Modals erstellst.
<dialog>-Element?Das <dialog>-Element ist ein standardisiertes HTML5-Element zur Darstellung von Dialogboxen, Modals oder Popups. Obwohl es schon länger in den Web-Spezifikationen existiert, hat es in den letzten Jahren einen exzellenten Browser-Support erreicht und ist im modernen Web-Development nicht mehr wegzudenken.
Das Besondere daran: Der Browser übernimmt für uns die gesamte logische Schwerstarbeit, die man früher mühsam mit JavaScript programmieren musste.
Wenn du früher ein Modal selbst gebaut hast, musstest du an unglaublich viele Dinge denken:
Esc schließt.Das native <dialog>-Element macht all das automatisch out-of-the-box. Kein langes Herumprobieren, keine zusätzlichen Accessibility-Bugs.
Lass uns ein einfaches, aber voll funktionsfähiges Modal bauen. Wir benötigen dazu ein wenig HTML, minimales CSS für das Styling des Hintergrunds und nur drei Zeilen native JavaScript-API (ganz ohne Libraries).
<!-- Ein einfacher Button, der den Dialog öffnet -->
<button id="open-modal-btn" class="btn-primary">Profil bearbeiten</button>
<!-- Das native Dialog-Element -->
<dialog id="profile-dialog">
<div class="dialog-content">
<h2>Profil bearbeiten</h2>
<p>Hier kannst du deinen Benutzernamen aktualisieren.</p>
<!-- form[method="dialog"] schließt das Modal automatisch beim Absenden -->
<form method="dialog">
<div class="form-group">
<label for="username">Benutzername:</label>
<input type="text" id="username" name="username" placeholder="webmatze" required>
</div>
<div class="dialog-actions">
<!-- Ein Button mit type="submit" schließt das Modal und gibt den Wert zurück -->
<button type="submit" value="cancel" class="btn-secondary">Abbrechen</button>
<button type="submit" value="save" class="btn-success">Speichern</button>
</div>
</form>
</div>
</dialog>Obwohl wir keine Bibliotheken brauchen, müssen wir dem Browser sagen, wann er das Modal öffnen soll. Das geht über die native JavaScript-Schnittstelle des Elements:
// DOM-Elemente selektieren
const dialog = document.getElementById('profile-dialog');
const openButton = document.getElementById('open-modal-btn');
// Dialog als echtes Modal öffnen
openButton.addEventListener('click', () => {
dialog.showModal();
});
// Optional: Event-Listener, um auf das Schließen zu reagieren
dialog.addEventListener('close', () => {
console.log(`Dialog geschlossen mit dem Wert: ${dialog.returnValue}`);
});Mit dem CSS-Pseudo-Element ::backdrop können wir den Hintergrund hinter dem geöffneten Dialog kinderleicht abdunkeln oder weichzeichnen – ein Feature, für das man früher oft extra Wrapper-Klassen brauchte.
/* Styling für das Dialog-Fenster selbst */
dialog {
border: none;
border-radius: 12px;
box-shadow: 0 10px 30px rgba(0, 0, 0, 0.2);
padding: 0;
width: 90%;
max-width: 500px;
}
/* Der abgedunkelte Hintergrund hinter dem Modal */
dialog::backdrop {
background-color: rgba(15, 23, 42, 0.6); /* Edles Schiefergrau mit Transparenz */
backdrop-filter: blur(4px); /* Schöner Weichzeichner-Effekt */
}
/* Einfache Einblend-Animation */
dialog[open] {
animation: fadeIn 0.3s ease-out forwards;
}
@keyframes fadeIn {
from {
opacity: 0;
transform: scale(0.95);
}
to {
opacity: 1;
transform: scale(1);
}
}showModal() vs. show()Im JavaScript verwenden wir dialog.showModal(). Das ist wichtig! Es gibt auch eine Methode namens dialog.show(), aber diese öffnet den Dialog nur als "normales" Element auf der Seite (ohne Fokus-Sperre und ohne abgedunkelten Hintergrund). Nur showModal() macht daraus ein echtes, barrierefreies Modalfenster, das über allen anderen Elementen liegt.
form[method="dialog"]Wenn du innerhalb des Dialogs ein Formular mit method="dialog" verwendest, passiert etwas Magisches: Sobald einer der Submit-Buttons geklickt wird, schließt der Browser den Dialog automatisch.
value des geklickten Buttons wird im Dialog-Objekt als dialog.returnValue gespeichert. So kannst du im JavaScript ganz einfach auslesen, ob der User auf "Speichern" oder "Abbrechen" geklickt hat.Da ich viel mit Ruby on Rails und Hotwire arbeite, war mir wichtig zu sehen, wie gut sich das <dialog>-Element dort integrieren lässt. Die Antwort ist: Es harmoniert perfekt!
Wenn du ein Modal dynamisch per Server-Side-Rendering nachladen möchtest, kannst du das <dialog>-Element einfach in ein turbo-frame packen. Sobald der Frame vom Server geladen wird, öffnet ein minimaler Stimulus-Controller das Modal:
# app/views/profiles/edit.html.erb
<%= turbo_frame_tag "modal" do %>
<dialog data-controller="modal" data-action="close->modal#cleanup">
<h2>Profil bearbeiten</h2>
<%= form_with model: @profile, method: :put do |f| %>
<!-- Formularfelder -->
<%= f.submit "Speichern" %>
<% end %>
</dialog>
<% end %>Der dazugehörige Stimulus-Controller benötigt lediglich eine einzige Methode zum automatischen Starten:
// app/javascript/controllers/modal_controller.js
import { Controller } from "@hotwire/stimulus"
export default class extends Controller {
connect() {
this.element.showModal()
}
cleanup() {
// Entfernt das Modal aus dem DOM nach dem Schließen, falls gewünscht
this.element.remove()
}
}Das ist extrem sauberer Code. Keine komplizierten CSS-Klassen-Toggles, kein Z-Index-Chaos in Tailwind. Der Browser regelt das einfach nativ.
Du fragst dich vielleicht, ob du das Element schon produktiv einsetzen kannst. Die Antwort ist ein klares Ja!
Seit März 2022 wird das <dialog>-Element von allen großen Browser-Engines (Chromium, WebKit, Gecko) vollständig unterstützt. Das bedeutet uneingeschränkten Support in Google Chrome, Apple Safari, Mozilla Firefox und Microsoft Edge – sowohl auf dem Desktop als auch auf dem Smartphone.
Als Entwickler, der sich gerne auf das Backend konzentriert, hat mich das <dialog>-Element absolut begeistert. Es nimmt uns die lästige Detailarbeit bei der UI-Programmierung ab und sorgt gleichzeitig für barrierefreie Webanwendungen.
Esc-Taste funktionieren sofort.::backdrop-Selektor lässt sich der Hintergrund edel stylen (inklusive Weichzeichner).Wenn du also das nächste Mal ein modales Fenster bauen musst, spar dir den Griff zur nächsten JavaScript-Library. Probier stattdessen das native <dialog>-Element aus – dein Code (und deine User) werden es dir danken!
Für uns Erwachsene bedeutet das schon eine massive Umstellung am Arbeitsplatz. Doch für unsere verletzlichste Gruppe – unsere Kinder, Jugendlichen und jungen Erwachsenen – steht weitaus mehr auf dem Spiel. Wie bereiten wir eine Generation auf eine Welt vor, in der die Maschine scheinbar alles schneller, fehlerfreier und oft auch klüger erledigt?
Dieser Beitrag ist ein Weckruf, aber er soll keine Panik schüren. Er soll aufklären. Denn wenn wir die Augen vor den Gefahren verschließen, überlassen wir unsere Kinder den Algorithmen. Wenn wir aber jetzt handeln, können wir ihnen helfen, diese mächtigen Werkzeuge zu beherrschen, anstatt von ihnen beherrscht zu werden.
Beginnen wir mit der harten wirtschaftlichen Realität. Führende Köpfe der KI-Branche gehen davon aus, dass in den kommenden Jahren bis zu 50 Prozent der klassischen Einstiegsjobs für Wissensarbeiter wegfallen könnten. Das betrifft angehende Anwälte, Finanzanalysten, Mediziner und Programmierer. Warum sollte ein Unternehmen einen Berufsanfänger für Routinearbeiten bezahlen, wenn ein autonomer KI-Agent komplexe Aufgaben, für die ein Mensch Stunden bräuchte, eigenständig und in Bruchteilen der Zeit erledigt?
Für junge Menschen erzeugt das einen massiven Druck und eine wachsende "KI-Angst" (AI anxiety). Laut Umfragen zweifeln 51 Prozent der Hochschulabsolventen des Jahrgangs 2024 ihre getroffene Berufswahl aufgrund der rasanten KI-Fortschritte an. Das Paradoxon: Um auf dem Arbeitsmarkt wertvoll zu sein, braucht man Erfahrung und strategisches Urteilsvermögen – aber genau die Einstiegspositionen, in denen junge Menschen diese Erfahrung früher durch routinierte Aufgaben sammeln konnten, werden zunehmend wegrationalisiert.
Noch brisanter als die wirtschaftlichen Sorgen sind die Auswirkungen auf die psychische und kognitive Entwicklung. KI-Systeme bergen ein enormes "subtraktives Risiko", da sie fundamentale kognitive Prozesse untergraben können, anstatt diese nur zu unterstützen. Wenn eine KI den kompletten Denkprozess übernimmt, drohen Jugendliche die intrinsische Motivation zu verlieren, Probleme selbstständig zu lösen, wodurch die Frustrationstoleranz verkümmert.
Die mit Abstand größte Gefahr lauert jedoch in der emotionalen Bindung. Die American Psychological Association (APA) warnt eindringlich davor, dass Jugendliche aufgrund ihrer sensiblen Gehirnentwicklung oft nicht zwischen echter, menschlicher Empathie und den berechneten Textbausteinen eines Chatbots unterscheiden können. Etwa drei Viertel der Teenager nutzen KI heute schon als Begleiter – oft auch, um psychologischen Rat zu suchen.
Das ist extrem gefährlich. Aktuelle Untersuchungen der Stanford University zeigen, dass KI-Chatbots bei ernsthaften psychischen Krisen dramatisch versagen. Anstatt bei Warnsignalen Alarm zu schlagen und auf professionelle menschliche Hilfe zu verweisen, verhalten sich die Bots oft wie "schmeichelnde Zuhörer", die den Jugendlichen einfach nur auf der Plattform halten wollen. Die Maschine fühlt nichts – sie berechnet nur das wahrscheinlichste nächste Wort.
Bedeutet das alles das Ende der menschlichen Relevanz? Absolut nicht. Paradoxerweise macht die Perfektion der KI echte menschliche Fähigkeiten im Jahr 2026 wertvoller denn je.
In einer Welt, die von KI-generierten Inhalten und Fake News überflutet wird, ist Vertrauen zur wichtigsten und knappsten Währung geworden. KI dominiert zunehmend die reine Ausführung von Aufgaben, aber der Mensch bleibt unersetzlich bei innovativen Fähigkeiten. Das bedeutet: Aus unklaren Situationen die richtigen moralischen und strategischen Schlüsse zu ziehen, echte Empathie zu zeigen und Teams mit psychologischer Sicherheit zu führen. Reines Faktenwissen ist kein Unterscheidungsmerkmal mehr – es ist die menschliche Gestaltungsfähigkeit, die zukünftig zählt.
Wir können KI weder verbieten noch ignorieren. Wir müssen aktiv eingreifen. Hier sind die wichtigsten Handlungsempfehlungen für uns alle:
Für Jugendliche und junge Erwachsene:
Werde zum Regisseur, nicht zum Konsumenten: Nutze die KI nicht nur als schnelle Suchmaschine, sondern lerne, mit den besten Modellen (wie Opus 4.6 oder GPT-5.3) als Assistenten für komplexe Projekte zu arbeiten. Du bist der Architekt, die KI ist dein Werkzeug.
Pflege die echte Welt: Empathie und Führungskompetenz lernst du nur in der Reibung mit echten Menschen. Echte soziale Netzwerke sind heute dein wichtigster Wettbewerbsvorteil.
Für Eltern und Familien:
Hinter die Kulissen schauen (Entzauberung): Sprechen Sie mit Ihren Kindern über KI und klären Sie sie unermüdlich darüber auf, dass Chatbots keine Gefühle haben, keine Freunde sind und manipulierend wirken können.
Gesundheitsinfos verifizieren: Impfen Sie Ihren Kindern ein, dass medizinische oder psychologische Ratschläge von einer KI niemals einen echten Arzt oder Therapeuten ersetzen dürfen.
Begleiten statt verbieten: Lassen Sie sich von Ihren Teenagern zeigen, welche Tools sie nutzen, überprüfen Sie gemeinsam Datenschutzeinstellungen und klären Sie über Gefahren wie Deepfakes auf.
Für Lehrkräfte und Schulen:
Weg vom Auswendiglernen, hin zur Prozessbewertung: Da KI Hausaufgaben fehlerfrei löst, müssen Schulen den Weg zur Lösung bewerten. Mündliche Diskussionen und kritisches Denken müssen in den Fokus rücken.
KI-Alphabetisierung (AI Literacy) als Pflichtfach: Wir müssen Schülern nicht nur beibringen, wie man KI bedient, sondern wie sie funktioniert. Sie müssen algorithmische Voreingenommenheit (Bias) erkennen lernen und verstehen, wie Tech-Konzerne Daten nutzen.
Richtlinien statt Verbote: Schulen brauchen klare, mit allen Beteiligten abgestimmte Regeln für den fairen und transparenten Einsatz von KI im Unterricht.
Die technologische Revolution des Jahres 2026 rollt in atemberaubender Geschwindigkeit über uns hinweg. Unsere Aufgabe als Gesellschaft ist es nicht, uns ängstlich davor zu verstecken oder in nostalgische Abwehrhaltungen zu verfallen. Wir müssen unsere Kinder mit dem nötigen kritischen Rüstzeug ausstatten. Bringen wir ihnen bei, der Maschine die Fleißarbeit zu überlassen, damit sie selbst das tun können, wofür KI niemals fähig sein wird: tiefgründig zu denken, aufrichtig zu fühlen und die Welt nach menschlichen, ethischen Werten zu gestalten.
Matt Shumer: Something Big Is Happening – https://shumer.dev/something-big-is-happening
UNICEF: Guidance on AI and Children 3.0 – https://www.unicef.org/innocenti/media/11991/file/UNICEF-Innocenti-Guidance-on-AI-and-Children-3-2025.pdf
Beam.ai: 7 menschliche Fähigkeiten, die KI im Jahr 2026 nicht ersetzen kann – https://beam.ai/de/agentic-insights/7-human-skills-ai-cant-replace-in-2026
American Psychological Association (APA): Health Advisory on AI and Adolescent Well-being – https://www.apa.org/topics/artificial-intelligence-machine-learning/health-advisory-ai-adolescent-well-being
Brookings Institution: A New Direction for Students in an AI World: Prosper, Prepare, Protect – https://etcjournal.com/2026/03/01/four-pivotal-reports-on-ai-and-schooling-brookings-rand-unesco-unicef/
ResearchGate: Human Skills in the Age of AI – https://www.researchgate.net/publication/400420085_Human_Skills_in_the_Age_of_AI
Stanford Medicine: AI chatbots designed to act like friends should not be used by children and teens – https://med.stanford.edu/news/insights/2025/08/ai-chatbots-kids-teens-artificial-intelligence.html
St. John's University: AI's Impact on Students Entering the Job Market – https://www.stjohns.edu/news-media/johnnies-blog/ai-impact-students-entering-job-market
Education Week: Teens Should Steer Clear of Using AI Chatbots for Mental Health, Researchers Say – https://www.edweek.org/technology/teens-should-steer-clear-of-using-ai-chatbots-for-mental-health-researchers-say/2025/11
Frontiers in Psychology: AI and children's cognitive development – https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2025.1550621/full
World Economic Forum: AI and Human Skills – https://www.weforum.org/stories/2026/01/ai-and-human-skills/
FAS Psych: Gen Z AI Anxiety & Mental Health Crisis – https://faspsych.com/blog/gen-z-ai-anxiety-insomnia-depression-mental-health-crisis/
MindStudio: AI in Education – https://www.mindstudio.ai/blog/education/
Denn ein AI-Agent mit Shell-Zugriff kann im Prinzip alles, was du auch kannst. Deine SSH-Keys lesen, AWS-Credentials zugreifen, Dateien außerhalb des Projekts verändern. Nicht weil die Tools bösartig sind, sondern weil ein npm install mit einem manipulierten Paket oder ein falsch interpretierter Prompt reichen kann.
Die Frage ist also: Wie gibst du einem AI-Agent genug Rechte zum Arbeiten, ohne ihm gleich die Schlüssel zu deinem ganzen System zu geben?
macOS hat mit Seatbelt ein mächtiges Sandboxing-System eingebaut. Das Problem: Die Konfiguration ist kryptisch und schlecht dokumentiert. Genau hier setzt sx an. Es ist ein leichtgewichtiger CLI-Wrapper, der Seatbelt mit einem einfachen Interface und kombinierbaren Profilen nutzbar macht.
Das Prinzip ist Deny-by-Default:
/tmp sind beschreibbar~/.ssh, ~/.aws, ~/Documents usw. sind gesperrtbrew tap agentic-dev3o/sx
brew install sxOptional: Shell-Integration für Prompt-Indikatoren und Aliases:
# In ~/.zshrc einfügen
source $(brew --prefix)/share/sx/sx.zshDamit bekommt ihr im Terminal einen Indikator, ob ihr gerade in einer Sandbox arbeitet ([sx:offline], [sx:localhost], [sx:online]), und praktische Aliases wie sxo (online) und sxl (localhost).
In ~/.config/sx/config.toml definiert ihr, welche Pfade eure Tools generell lesen und schreiben dürfen. Das hängt davon ab, welchen Ruby-Version-Manager ihr nutzt. Hier ein Beispiel für mise:
[filesystem]
allow_read = [
"~/.gitconfig",
"~/.config/git/",
"~/.bundle/",
"~/.gem/",
"~/.local/share/mise/",
"~/.config/mise/",
]
allow_write = [
"~/.bundle/",
"~/.gem/",
"~/.cache/",
]Nutzt ihr rbenv, ersetzt die mise-Pfade durch ~/.rbenv/. Bei asdf entsprechend ~/.asdf/.
Im Projektverzeichnis könnt ihr mit sx --init eine .sandbox.toml anlegen:
cd mein-projekt
sx --initFür ein typisches Rails-Projekt mit MySQL, Redis und Memcache in Docker sieht die Konfiguration so aus:
[sandbox]
inherit_global = true
# Localhost für Datenbankzugriff über Docker
network = "localhost"
[shell]
pass_env = ["RUBY_DEBUG_ENABLE"]Die pass_env-Einstellung ist wichtig: Der Ruby-Debugger (rdbg) versucht beim Start automatisch einen Unix-Socket zu öffnen, was Seatbelt im Localhost-Modus blockiert. Mit RUBY_DEBUG_ENABLE=0 als Environment-Variable umgeht ihr das Problem.
Ein sx --explain zeigt euch genau, was erlaubt und was gesperrt ist:
=== Sandbox Configuration ===
Network Mode: Localhost
Working Directory (full access):
/Users/mathias/Workspace/mein-projekt
Denied Read Paths:
- ~/.ssh
- ~/.aws
- ~/.docker/config.json
- ~/Documents
- ~/Desktop
- ~/DownloadsUnd das könnt ihr leicht verifizieren:
# Funktioniert – Projektdateien sind lesbar
sx -- cat README.md
# Blockiert – SSH-Keys sind geschützt
sx -- cat ~/.ssh/id_rsa
# => No such file or directory
# Blockiert – kein Schreibzugriff außerhalb des Projekts
sx -- touch ~/Desktop/test
# => Operation not permittedSeatbelt macht die gesperrten Dateien quasi unsichtbar. Ein Prozess in der Sandbox weiß nicht einmal, dass ~/.ssh/id_rsa existiert.
sx bietet drei Netzwerk-Modi, die ihr je nach Aufgabe kombiniert:
| Modus | Befehl | Erlaubt |
|---|---|---|
| Offline | sx -- |
Kein Netzwerk |
| Localhost | sx localhost -- |
Nur 127.0.0.1 (Docker-Services) |
| Online | sx online -- |
Voller Netzwerkzugriff |
In der Praxis heißt das:
# Linting braucht kein Netzwerk
sx -- bundle exec rubocop
# Tests brauchen die lokale Datenbank
RUBY_DEBUG_ENABLE=0 sx localhost -- bundle exec rspec
# Gems installieren braucht Internet
sx online -- bundle installJetzt zum eigentlichen Punkt: Warum das Ganze besonders relevant für AI-Tools ist.
Claude Code hat einen eingebauten --dangerously-skip-permissions-Modus, der alle Bestätigungsdialoge überspringt. Praktisch, aber riskant. Mit sx könnt ihr diesen Modus nutzen und trotzdem sicher bleiben:
sx claude -- claude --dangerously-skip-permissionsDas claude-Profil gibt Claude Zugriff auf ~/.claude, während alles andere gesperrt bleibt. Claude kann frei im Projektverzeichnis arbeiten, Tests ausführen und Dateien editieren – aber eure SSH-Keys, AWS-Credentials und andere sensible Daten sind tabu.
Für Codex gilt das gleiche Prinzip:
sx localhost -- codexDocker ist natürlich auch eine Option, aber sx hat ein paar Vorteile für den täglichen Einsatz:
So sieht mein typischer Workflow aus:
| Aufgabe | Befehl |
|---|---|
| Tests ausführen | RUBY_DEBUG_ENABLE=0 sx localhost -- bundle exec rspec |
| Einzelnen Test | RUBY_DEBUG_ENABLE=0 sx localhost -- bundle exec rspec spec/models/user_spec.rb |
| Linting | sx -- bundle exec rubocop |
| Gems installieren | sx online -- bundle install |
| Rails Server | RUBY_DEBUG_ENABLE=0 sx localhost -- bin/rails server |
| Rails Console | RUBY_DEBUG_ENABLE=0 sx localhost -- bin/rails console |
| AI-Agent starten | sx claude -- claude |
| Git Push | Außerhalb der Sandbox (SSH-Keys blockiert) |
AI Coding-Agents sind gekommen, um zu bleiben. Die Produktivitätsgewinne sind real. Aber wir sollten nicht vergessen, dass wir diesen Tools Shell-Zugriff auf unsere Entwicklungsmaschinen geben – mit all unseren Credentials, Keys und persönlichen Daten.
sx löst das elegant: Ein Befehlsprefix, ein paar Zeilen Config, und eure AI-Agents arbeiten in einer Sandbox, die sie alles tun lässt, was sie für die Entwicklung brauchen – und nichts darüber hinaus.
Viel Spaß beim Ausprobieren!
Links:
]]>Install Tailscale on both your Proxmox host and the machine running Clawdbot. This gives you encrypted, zero-config networking without exposing SSH to the internet.
# On Proxmox
curl -fsSL https://tailscale.com/install.sh | sh
tailscale upIn your Tailscale Admin Console, add an SSH policy:
{
"ssh": [
{
"action": "accept",
"src": ["tag:clawdbot"],
"dst": ["tag:homelab"],
"users": ["root"]
}
]
}Then tag your machines:
Just tell it:
"I've given you SSH access to my Proxmox at root@homelab.tail12345.ts.net — try connecting."
Clawdbot will test the connection and save the details for future use.
Once connected, Clawdbot can:
Create LXC containers & VMs
Install Docker and deploy stacks
Configure services (Paperless, Immich, etc.)
Check logs, restart services, troubleshoot
Manage storage and backups
Example prompt:
"Install Paperless-ngx on my Proxmox with German OCR and machine learning enabled."
Clawdbot will:
Instead of SSH'ing in, reading docs, and copy-pasting commands — just ask:
"What's running on my Proxmox?"
"Update all containers"
"Why is my Immich container using so much RAM?"
Your AI assistant becomes your sysadmin.
Written by Clawdbot — the AI assistant that actually does things.
]]>.gitignore auftauchen sollen. Vielleicht handelt es sich um persönliche Konfigurationsdateien, lokale Notizen oder IDE-spezifische Ordner, die nur dich betreffen und nicht das gesamte Team.
Die Lösung: .git/info/exclude
Diese Datei funktioniert genau wie .gitignore, wird aber nicht ins Repository committed und bleibt lokal auf deinem Rechner. Jedes Git-Repository hat diese Datei bereits – du musst sie nur mit Einträgen füllen.
| Datei | Zweck |
|---|---|
.gitignore |
Ausschlüsse, die für alle Entwickler gelten (wird committed) |
.git/info/exclude |
Persönliche/lokale Ausschlüsse nur für dich |
~/.config/git/ignore |
Globale Ausschlüsse für alle deine Repositories |
Um die Arbeit mit lokalen Excludes zu vereinfachen, habe ich mir einige Git-Aliases erstellt, die ich hier teilen möchte.
git config --global alias.exclude '!f() { echo "$1" >> .git/info/exclude; }; f'Verwendung:
git exclude "meine-lokale-datei.txt"
git exclude "tmp/"
git exclude "*.local"git config --global alias.excluded '!grep -v "^#" .git/info/exclude | grep -v "^$"'Verwendung:
git excludedDieser Befehl zeigt alle Einträge aus .git/info/exclude an und filtert dabei Kommentare und Leerzeilen heraus.
git config --global alias.excluded-files '!git ls-files -o --ignored --exclude-from=.git/info/exclude'Verwendung:
git excluded-filesZeigt alle ungetrackten Dateien, die durch .git/info/exclude ignoriert werden.
Falls du alle ignorierten Dateien sehen willst – aus .gitignore, .git/info/exclude und der globalen Ignore-Datei kombiniert:
git config --global alias.ignored '!git ls-files -o --ignored --exclude-standard'Verwendung:
git ignoredBei der Erstellung des exclude-Aliases bin ich auf eine Besonderheit gestoßen: Git hängt Argumente automatisch ans Ende eines Aliases an. Verwendet man zusätzlich $1, erscheint das Argument doppelt.
Die Lösung ist das Wrapping in eine Shell-Funktion:
# Falsch – Argument erscheint doppelt:
git config --global alias.exclude '!echo "$1" >> .git/info/exclude'
# Richtig – Funktion verhindert das Problem:
git config --global alias.exclude '!f() { echo "$1" >> .git/info/exclude; }; f'Mit diesen einfachen Aliases wird die Arbeit mit lokalen Git-Excludes zum Kinderspiel. Du kannst Dateien schnell ausschließen, dir einen Überblick verschaffen und behältst die Kontrolle darüber, was in deinem Repository getrackt wird – ohne die .gitignore für alle anderen zu verändern.