Wie man ein 30x-AI-Ingenieur mit Geschmack wird

• Im Zeitalter massenhaft von KI erzeugten Codes ist die entscheidende Fähigkeit, die den Wert von Ingenieuren trennt, nicht Geschwindigkeit, Wissen oder Erfahrung, sondern „Geschmack (taste)” – also das Urteilsvermögen, zu entscheiden, was gebaut werden soll
• Mitglieder des OpenAI-Codex-Teams kamen unabhängig voneinander zum selben Schluss: Wer guten Software-Geschmack hat, kann ein 10x-Ingenieur werden
• Geschmack lässt sich in drei Formen einteilen: Erkennung (recognition) · Kompass (compass) · Vision (vision); alle laufen auf denselben Mechanismus hinaus, nämlich die Qualität einer internen Bewertungsfunktion
• Wert entsteht konzentriert in fünf Bereichen: Problemauswahl, Systemarchitektur, Qualitätsbeurteilung, Nutzerempathie und Kommunikation
• Jetzt, da das Schreiben von Code zur Commodity geworden ist, sind Urteilsvermögen und Denken die eigentlichen Kernfähigkeiten – und sie müssen bewusst entwickelt werden

---

Die Welt hat sich verändert, aber die meisten Ingenieure haben es nicht bemerkt

• Anthropic-CEO Dario Amodei prognostizierte im März 2025, dass KI innerhalb weniger Monate 90 % des Codes schreiben werde; damals klang das absurd
• Claude-Code-Entwickler Boris Cherny berichtete im Dezember, dass 100 % des von ihm committeten Codes von KI geschrieben worden seien und er kein einziges Mal seine IDE geöffnet habe
• Andrej Karpathy, der KI-Coding-Tools als „slop“ bezeichnet hatte, revidierte im Dezember seine Haltung vollständig
  • „Als Programmierer habe ich mich noch nie so abgehängt gefühlt, und der Beruf wird gerade dramatisch umgebaut.“
  • Ruby-on-Rails-Schöpfer DHH räumte ein, sein Widerstand habe daran gelegen, „dass die Modelle noch nicht gut genug waren“ – inzwischen habe sich die Lage gedreht
  • Vercel-CTO Malte Ubl sagte, „die Produktionskosten von Software konvergieren gegen null“
• Zwischen November und Dezember 2025 überschritten Opus 4.5, GPT-5.2 und Gemini 3 unsichtbare Fähigkeitsgrenzen; bei einer breiten Palette von Aufgaben erreichte KI-Code das Niveau erfahrener Ingenieure, während sich die benötigte Zeit von Stunden auf Minuten verkürzte
• Wenn Codegenerierung zur Commodity wird, bleibt Software Engineering übrig: Probleme zerlegen, entscheiden, was gebaut werden soll, für Tests, Zuverlässigkeit und Skalierung entwerfen sowie Trade-offs beurteilen – also Geschmack

Was ist Geschmack eigentlich?

• Unter dem, was Spitzenteams im Engineering als Geschmack bezeichnen, gibt es drei Definitionen; sie betrachten dieselbe Fähigkeit nur aus unterschiedlichen Blickwinkeln

• Geschmack als Erkennung (Recognition)

  • Die Fähigkeit zu spüren, welche von zwei Implementierungen besser ist, noch bevor man erklären kann, warum
  • Emma Tang: Ob ein System wirklich sauber, skalierbar und frei von Duplikaten ist und sich einfach verstehen lässt, ist eine Frage des Geschmacks
  • So wie ein Koch beim Abschmecken sofort merkt, dass Säure fehlt, noch bevor er es bewusst identifiziert, arbeitet Pattern Matching schneller als bewusstes Schlussfolgern
  • Ein Beispiel ist die Entscheidung des Codex-Teams, die CLI mit Rust statt TypeScript zu bauen
    • Beides hätte funktioniert, doch man erkannte, dass Rusts Einschränkungen – strenges Typsystem, explizites Speichermanagement, minimale Abhängigkeiten – über technische Vorteile hinaus einen Effekt auf die Engineering-Kultur haben
    • Das Urteil lautete nicht „technisch überlegene Sprache“, sondern „die Sprache, die das Verhalten formt, das man im Team sehen will“
  • Schlechter Geschmack: Rust zu wählen, weil es gerade im Trend ist oder weil irgendein Blog sagt, es sei schnell, ohne die Effekte zweiter Ordnung zu verstehen

• Geschmack als Kompass (Compass)

  • Das ist die Form, die Tibo meinte, als er sagte, Ingenieure müssten „ihren eigenen Kompass“ haben: nicht das bereits Existierende bewerten, sondern wissen, was als Nächstes gebaut werden sollte
  • Ein Ingenieur, der noch vor der ersten Codezeile sagt: „Das ist nicht das richtige Feature.“
  • Boris Cherny baute für die Todo-Listen-Funktion von Claude Code in zwei Tagen rund 20 Prototypen
    • Er probierte Inline-Todos, eine Drawer-UI, interaktive Pills, eine Anzeige am unteren Bildschirmrand und mehr aus und konvergierte zu einer Form, die nicht willkürlich, sondern unausweichlich wirkte
    • Im Nachhinein konnte er erklären, warum die finale Version besser war; die anfängliche Unzufriedenheit mit den Zwischenlösungen selbst war jedoch der als Kompass wirkende Geschmack
  • Kompass-Geschmack ist seltener als Erkennungs-Geschmack, weil er weiter stromaufwärts als die Ausführung wirkt

• Geschmack als Vision (Vision)

  • Ausdruck findet das in SQ Mahs Aussage „Menschen definieren Evolution“; es ist die schwierigste Form, weil es darum geht, nicht zu wissen, was jetzt gut ist, sondern was in zwei Jahren wichtig sein wird
  • OpenClaw-Macher Peter Steinberger lässt 5 bis 10 Agenten gleichzeitig laufen und verbringt den Großteil seiner Zeit mit Architektur und Systemdesign
    • Er sagte, „der Großteil des Codes ist langweilige Datentransformation“, daher solle man seine Energie auf Systemdesign konzentrieren
  • Die nächste Priorität des Codex-Teams ist Planung auf Basis reichhaltigen Kontexts, wofür Informationen außerhalb der Codebasis nötig sind, etwa Geschäftsziele, Marktdynamiken und Team-Prioritäten
    • Das ist Vision-Geschmack, angewandt auf Produktstrategie: nicht ein besserer Codegenerator, sondern eine Zukunft, in der das Modell versteht, warum die Software überhaupt existiert

• Integrierte Definition

  • Alle drei Formen laufen auf einen Mechanismus hinaus: Geschmack ist die Qualität einer internen Bewertungsfunktion
  • Bei Erkennung wirkt diese Bewertungsfunktion auf fertige Ergebnisse, beim Kompass auf Möglichkeiten und Richtungen, bei Vision auf Zukunft und Entwicklungspfad
  • In einer Welt, in der KI Code erzeugt, besteht die menschliche Aufgabe im Bewerten – zu entscheiden, was gebaut werden soll, zu beurteilen, ob ein Ergebnis gut genug ist, und zu erkennen, wann eine Architektur geändert werden muss; Bewertung ist damit der eigentliche Job

Warum manche Ingenieure sehr viel mehr verdienen

• Vor KI ließ sich die Vergütungslücke durch drei Faktoren erklären: Unternehmen, Berufsjahre und Fachgebiet; KI wirbelt nun alle drei Variablen durcheinander
• Die Lücke zwischen hervorragenden und durchschnittlichen Ingenieuren in Startups wächst von 3x auf 10x, weil die stärkeren mit KI den Output kleiner Teams erreichen
• Die Achse der Erfahrung verschiebt sich: Wichtiger als Erfahrung im Code-Schreiben ist Erfahrung im guten Urteilen
  • Der Wert von „kennt React“ sinkt, der Wert von „kann unter Last ein zuverlässiges System entwerfen“ steigt
• Ingenieure mit besonders großem Hebel haben gemeinsam, dass sie Entscheidungen treffen, die sich mit Zinseszinseffekt akkumulieren
  • Eine gute Architekturentscheidung kann über ein Jahr hinweg mehrere Monate Arbeit sparen
  • Eine gute Produktentscheidung kann darüber entscheiden, ob ein Feature überhaupt real genutzt wird
• Man kann trotz härterer Arbeit nur halb so viel Wert erzeugen wie jemand mit besserem Geschmack; zwei Agenten auf das richtige Problem anzusetzen erzeugt mehr Wert, als acht Agenten auf das falsche Problem loszulassen
• Bei OpenAI verlagerten die produktivsten Ingenieure ihren Fokus nicht darauf, mehr Code zu generieren, sondern mehr Zeit in Gespräche mit Nutzern, Produktrichtung und Empathie zu investieren
  • Manche kehrten zum Tab-Autocomplete zurück, weil sie „das Gefühl für die Codebasis verlieren“; beide Reaktionen sind valide

Wo Wert tatsächlich entsteht

• Es gibt fünf Bereiche, in denen Geschmack unverhältnismäßigen Wert schafft; die meisten Ingenieure konkurrieren nur in ein oder zwei davon

• Zone 1: Problemwahl

  • Zu entscheiden, woran man arbeitet, ist die Geschmacksentscheidung mit dem höchsten Hebel, doch die meisten denken kaum darüber nach
  • Ingenieure mit Geschmack fragen: „Wenn ich dieses Problem gut löse, verschwinden dann fünf andere Probleme?“
  • Peter Steinberger verfeinert Pläne in langen Dialogen mit Agenten, fordert sie heraus und widerspricht ihnen; erst wenn er zufrieden ist, lässt er den Agenten ausführen, der Plan ist die eigentliche Arbeit, die Ausführung wird delegiert
  • Beim Berechtigungssystem von Claude Code wurde statt komplexem RBAC und fein granulierten Richtlinien der einfachste Ansatz gewählt (Berechtigung anfragen und die Antwort merken), um schnell und intuitiv zu launchen

• Zone 2: Systemarchitektur

  • Es geht darum, wie die Teile ineinandergreifen; hier ist die Halbwertszeit von Geschmack am längsten: Gute Entscheidungen zahlen sich auch in zwei Jahren noch aus, schlechte sammeln sich als technische Schulden an und erzwingen Neuschreibungen
  • Die Entscheidung, die Agent-Loop von Codex als Zustandsmaschine zu bauen, die Entscheidung bei Claude Code, „so wenig Business-Logik wie möglich“ zu schreiben, und OpenClaws Obsession mit modularer Erweiterbarkeit sind alles Architekturentscheidungen, die von Geschmack geprägt sind
  • Boris Cherny: „Mit jedem neuen Modell löschen wir jede Menge Code und halten so wenig Code wie möglich um das Modell herum“
    • Die meisten Teams fügen mit jedem Release Code hinzu, das Claude-Code-Team entfernt ihn jedoch; das Modell ist das Produkt, und alles darum herum sollte so dünn wie möglich sein

• Zone 3: Qualitätsurteil

  • Es geht darum zu wissen, ob etwas reif für den Release ist oder noch Arbeit braucht — ein Bereich, in dem AI nicht helfen kann (weil sie nicht weiß, was in einem bestimmten Kontext „gut genug“ bedeutet)
  • Der hierarchische Code-Review von Codex: Nicht-kritischer Code wird nur von AI geprüft, kritischer Agent-Code muss von Menschen geprüft werden
    • Geschmack zeigt sich darin zu wissen, welcher Code wichtig ist: Das Berechtigungssystem braucht menschliche Augen, ein README-Update nicht
  • Das Codex-Team schreibt fast den gesamten Code per Prompt, andere Abteilungen im Unternehmen liegen eher bei etwa 70 %; die 30 % handgeschriebener Code sind die Teile, bei denen Qualitätsurteil am wichtigsten ist („30/70-Regel“)

• Zone 4: Nutzerempathie

  • Es geht darum zu verstehen, was der Mensch auf der anderen Seite tatsächlich braucht — der Bereich, in dem AI am schwächsten ist
  • Boris’ kontextbezogene Ladehinweise in Claude Code (die anzeigen, was das Modell gerade tut, statt nur einen Spinner zu zeigen) hat niemand verlangt, aber sie wurden gebaut, weil Warten mit Information etwas völlig anderes ist als Warten ohne Information
  • Auch die Sandbox-Standardeinstellungen von Codex sind eine Entscheidung aus Nutzerempathie; Tibo: „Selbst wenn es die Adoptionsrate senkt, empfehlen wir standardmäßig nichts, was potenziell unsicher ist“
    • Man versteht, dass viele Nutzer „nicht so technisch“ sind und versehentlich irreversible Dinge tun könnten; deshalb fiel die Wahl auf Sicherheit statt Bequemlichkeit

• Zone 5: Kommunikation und Storytelling

  • Es geht darum, wie man das Gebaute framet — ein Bereich, den Ingenieure systematisch unterschätzen, den der Markt aber belohnt
  • Peter Steinbergers OpenClaw verzeichnete in seiner viralen Woche mehr Google-Suchanfragen als Claude Code und Codex zusammen
    • Ein klarer Name, eine überzeugende Demo und die Erzählung, dass „eine Person die Leistung eines ganzen Teams erzeugt“, trieben die Verbreitung an
  • Die AGENTS.md-Datei von Codex (ein README für AI-Agenten statt für Menschen) ist eine Kommunikationsentscheidung mit Geschmack: Sie erkennt an, dass sich das Publikum der Dokumentation geändert hat, und passt das Format entsprechend an

Beispiele für Geschmack (und sein Fehlen)

• Wahl des Tech-Stacks

  • Kein Geschmack: „TypeScript, weil es am beliebtesten ist und alle es kennen“, per Konvention begründet
  • Mit Geschmack: Boris wählte TypeScript, weil es für Claude-Modelle „on distribution“ ist (das Modell kann bereits gut damit umgehen), also auf die Stärken des Modells optimiert statt auf den Komfort des Teams
    • Codex wählte Rust, weil man minimale Abhängigkeiten wollte, damit man „über die gesetzten Engineering-Standards nachdenken“ und alles direkt inspizieren kann; dieselbe Art von Entscheidung, aber in beiden Fällen gestützt auf konkrete Constraints statt auf allgemeine Vorlieben

• Umgang mit Code, den man nicht vollständig versteht

  • Kein Geschmack: „Wurde von AI generiert und die Tests laufen, also ab in den Release“, ohne über Testabdeckung oder Wartbarkeit nachzudenken
  • Mit Geschmack: Peter shippt Code, den er nicht vollständig gelesen hat, aber nicht fahrlässig; „ich kenne die Position und Struktur der Komponenten sowie das Design des Gesamtsystems, und das reicht normalerweise“
    • Tests, Linting und lokales CI bilden die Validierungsschichten; das eine ist Glücksspiel, das andere ein System, in dem Korrektheit strukturell abgesichert ist

• Umgang mit Feature-Requests

  • Kein Geschmack: Nach Ticket umsetzen und nach dem Release direkt zum Nächsten
  • Mit Geschmack: Boris baut in den zwei Tagen vor dem Release 20 Prototypen; das ist nicht langsam, sondern schnelles Experimentieren, um zur richtigen Lösung zu navigieren, Unvermeidlichkeit ist der Fingerabdruck von Geschmack

• Design für AI-Agenten

  • Kein Geschmack: Ein gewöhnliches README mit Setup-Anleitung und API-Endpunkten
  • Mit Geschmack: Codex schreibt ein AGENTS.md, das AI erklärt, wie sie sich in der Codebasis orientiert, Tests ausführt und Standards einhält, und strukturiert die Codebasis so, dass das Modell unvermeidlich erfolgreich sein kann

• Umgang mit der PR-Flut

  • Kein Geschmack: AI-generierte PRs strömen herein, aber der gleiche Review-Prozess bleibt bestehen; Reviewer werden überlastet, die Qualität sinkt
  • Mit Geschmack: Das Team von Emma Tang verlangt, dass PRs den Prompt beilegen; fehlt er, kommt in Slack die Frage „Wie lautete der Prompt?“
    • In einer AI-Welt ist es oft nützlicher, die Intention als den Code zu reviewen; Peter nennt PRs „prompt requests“ und interessiert sich stärker für den Erzeugungsprompt als für den Code selbst — wenn sich die Einheit der Generierung ändert, muss sich auch die Einheit des Reviews ändern

Ein Plan, um Geschmack zu entwickeln (nicht nur eine Impression)

• Der Rat „sammle mehr Erfahrung“ ist so nutzlos wie „mach mehr Sport“; hier ist stattdessen ein 90-Tage-Plan in drei Formen

• Monat 1: Wahrnehmungsgeschmack durch strukturierte Exposition aufbauen

  • Der Mechanismus ist breite Exposition gegenüber unterschiedlichen Ausprägungen, gefolgt von bewusster Reflexion
  • Wochen 1–2: Zehn Entwickler-Tools studieren, die du bewunderst
    • Installiere Codex CLI, Claude Code, Linear, Supabase, das Stripe-Dashboard, Vercel, Tailwind, Railway, Resend sowie ein nicht-digitales Produkt (eine gut gestaltete Museumsausstellung oder eine Speisekarte in einem Restaurant)
    • Schreibe zu jedem 15 Minuten lang auf: Was ist dir in den ersten 60 Sekunden aufgefallen, was hat Freude gemacht, was war verwirrend, welche Entscheidung würdest du stehlen
    • Gute Tools zeigen in den ersten 30 Sekunden das Ergebnis, bevor sie den Prozess erklären; schlechte Tools erklären die Architektur, bevor sie zeigen, warum es einen überhaupt kümmern sollte
  • Wochen 3–4: Zehn Papers studieren, nicht wegen der Entdeckungen, sondern wegen der Methodik
    • Das Original-Paper zum BLEU-Score, Anthropics Paper zu Constitutional AI, Googles Paper zu PageRank, die Aufzeichnungen zum Netflix Prize, Papers zu Scaling Laws
    • Schreibe auf: Was macht die Methodik elegant, welcher eine Insight bringt sie zum Funktionieren, wie würdest du sie auf deine Domäne anwenden
    • Du wirst feststellen, dass sich strukturelle Prinzipien wie klare Evaluationskriterien, ehrliche Offenlegung von Grenzen und einfache Formalisierung statt unnötiger Komplexität fachübergreifend wiederholen

• Monat 2: Kompass-Geschmack durch aktive Unterscheidung aufbauen

  • Wöchentliche Übung „Side-by-Side“: Finde zwei Beispiele derselben Art und schreibe 500 Wörter darüber, warum eines besser ist (zwei API-Dokumentationen, zwei technische Blogs, zwei Architekturdiagramme, zwei Evaluations-Frameworks)
    • „Ich bevorzuge …“ ist verboten; schreibe immer konkret „Das ist besser, weil …“ und benenne den Mechanismus
    • Beispiel: Die Dokumentation von Stripe ist besser, weil sie um das herum organisiert ist, was Entwickler tun wollen (eine Zahlung senden, Fehler behandeln), statt um die interne Architektur
  • Tägliche Übung „Practice Noticing“: Jedes Mal, wenn du ein Tool, ein Paper oder Code anschaust, notiere zu genau einer Entscheidung des Erstellers einen Satz: „Warum dies und nicht die offensichtliche Alternative?“ Nach 30 Tagen zeigen die Muster in 30 Beobachtungen, dass sich Geschmack entwickelt

• Monat 3: Visions-Geschmack durch generative Anwendung aufbauen

  • Woche 9: Etwas, das dir gehört, mit dem Gelernten neu entwerfen (der Onboarding-Flow deines Teams, das README eines Projekts, die Developer Experience einer Evaluations-Pipeline)
  • Woche 10: Den präzisesten Text schreiben, den du je geschrieben hast — nicht den längsten oder umfassendsten, sondern einen, in dem jeder Absatz seine Aufgabe erfüllt und das Denken des Lesers verändert
  • Woche 11: Ein System von Grund auf entwerfen und jede Entscheidung mit ersten Prinzipien statt Konventionen erklären (nicht „Microservices, weil Best Practice“, sondern „Monolith, weil das Team vier Personen hat, der Traffic vorhersehbar ist und die Einfachheit des Deployments mehr zählt als Skalierungsvorteile, die wir 18 Monate lang nicht brauchen“)
  • Woche 12: Geschmack teilen, die Unterschiede zwischen zwei Ansätzen lehren und ein AGENTS.md für die eigene Codebasis schreiben; die Fähigkeit, Geschmack in Systeme und Dokumentation zu kodieren, trennt individuelles Können von organisatorischer Leistungsfähigkeit

Fünf Projekte, um Geschmack schnell aufzubauen

• 1. Einen Bewertungs-Framework für AI-generierten Code aufbauen

  • Kein Linter oder Test Runner, sondern ein Framework, das die Frage beantwortet: „Ist dieser AI-Code gut genug für die Produktion?“; dazu eine eigene Rubrik definieren (Korrektheit, Wartbarkeit, Effizienz, Sicherheit, Stil)
  • Auf 50 tatsächlich von AI erzeugte PRs anwenden und bewerten, die Rubrik anhand überraschender Ergebnisse kalibrieren, die Resultate veröffentlichen und so Zone 3 (Qualitätsurteil) als Geschmack aufbauen

• 2. Onboarding für Open-Source-Projekte neu gestalten

  • Ein Tool forken, dessen Technik man respektiert, dessen Onboarding aber frustrierend ist; die ersten 5 Minuten der Developer Experience neu gestalten, README und Getting-Started-Guide schreiben und die Struktur so anlegen, dass neue Mitwirkende am ersten Tag einen PR einreichen können
  • So gleichzeitig Zone 4 (Nutzerempathie) und Zone 5 (Kommunikation) aufbauen

• 3. Einen „Geschmackstest“ für das Team entwickeln

  • Ein Dokument mit 10 Paaren von Implementierungsansätzen erstellen, bei jedem Paar hat eine Seite den besseren Geschmack; fünf Engineers fragen, welche Seite besser ist und warum
  • Das Interessante ist nicht die richtige Antwort, sondern Meinungsverschiedenheit; dort, wo Standards auseinanderlaufen, liegen die Ursachen für Bugs, technische Schulden und Nacharbeit; das ist der Hebel mit der höchsten Wirkung für organisatorischen Geschmack

• 4. Ein Produkt unter einer 48-Stunden-Beschränkung launchen

  • Kein Prototyp, sondern ein funktionierendes Produkt, das andere wirklich nutzen können; die Zeitbeschränkung erzwingt fortlaufend Geschmacksentscheidungen darüber, was enthalten bleibt und was gestrichen wird
  • Wer 6 Stunden für das falsche Feature ausgibt, verbrennt bereits ein Viertel der verfügbaren Zeit; die Folgen schlechter Entscheidungen sind also unmittelbar

• 5. Einen Tech-Blog schreiben, der Denkweisen verändert

  • Keine Tutorials oder How-tos, sondern Texte, die vertraute Konzepte neu zusammensetzen, sodass Leser sie danach anders sehen (die Einsicht, dass Geschmack letztlich Bewertung ist; oder die Erkenntnis, dass das Löschen von Code mit jedem Model Release keine Gewohnheit, sondern eine Architekturphilosophie ist)
  • So Zone 5 (Kommunikation und Storytelling) aufbauen; echte Perspektive ist die Grundlage jedes Geschmacks

Die eigene Karriere auf Geschmack ausrichten

• Den Geschwindigkeitswettbewerb beenden

  • Wenn AI Code mit Maschinengeschwindigkeit schreibt, ist ein Wettbewerb um Coding-Tempo ein Spiel, das man nicht gewinnen kann; wertvoller als jemand, der 500 Zeilen pro Stunde erzeugt, ist jemand, der 30 Minuten darüber nachdenkt, welche 50 Zeilen tatsächlich gebraucht werden
  • Umsetzungsgeschwindigkeit ist zur Commodity geworden; nicht commoditisiert ist das Urteil darüber, was wie implementiert werden sollte

• In „angrenzende Fähigkeiten“ investieren, die Geschmack ermöglichen

  • Die besten Engineers haben gemeinsam, dass sie nicht bloß Coder sind: Boris ist Startup-Gründer, Emma war vier Jahre lang Lead für Dateninfrastruktur bei Stripe, Peter hat PSPDFKit zu einem globalen Business ausgebaut
  • Geschmack braucht Rohmaterial; Product Thinking, Designverständnis, Business-Verständnis und Kommunikationsfähigkeit sind die Materialien, aus denen Geschmack entsteht

• Rollen wählen, in denen Geschmack belohnt wird

  • Rollen, in denen klar definierte Spezifikationen umgesetzt werden, belohnen Geschwindigkeit; Rollen, in denen entschieden wird, was wie gebaut wird und was gut genug ist, belohnen Geschmack direkt
  • Rollen, in denen Geschmack besonders stark belohnt wird: Gründungs-Engineer in einem frühen Startup, Tech Lead in einem Produktunternehmen, Plattform- und Infrastruktur-Engineer, der Systeme entwirft, auf denen andere Engineers aufbauen, Developer-Experience-Engineer sowie Staff+-Engineers, die teamübergreifende Architekturentscheidungen treffen

• Öffentliche Arbeitsproben mit erkennbarem Geschmack aufbauen

  • Im AI-Zeitalter ist das Portfolio wichtiger als der Lebenslauf; der Beweis liegt in den Ergebnissen (gut designtes Open Source, ein Tech-Blog mit konsistenter Perspektive, Produkte, die Menschen tatsächlich nutzen)
  • Peters OpenClaw sagt mehr als jeder Lebenslauf, und Boris’ Claude-Code-Prototyp belegt Geschmack besser als jede Antwort in einem Behavioural Interview

Die unbequeme Wahrheit

• Geschmack ist ungleich verteilt und wird es auch bleiben; manche haben durch Tausende Entscheidungen über 15 Jahre hinweg einen Vorsprung aufgebaut, den man mit einem 90-Tage-Plan nicht aufholen kann
  • Das Codex-Team arbeitet in einem Unternehmen, das Models baut und unbegrenzten Token-Zugang hat, und Peter startet aus einer untypischen Position mit 20 Jahren Erfahrung und einem Company Exit
• Dennoch ist der Abstand zwischen „kein Geschmack“ und „etwas Geschmack“ in seiner Auswirkung auf die Karriere enorm und überbrückbar; der Sprung vom Menschen, der Tickets entgegennimmt und umsetzt, hin zu jemandem, der per Nutzerforschung vorschlägt, was gebaut werden sollte, und Tests wie Architektur mit AI umsetzt, genau das ist Geschmack
• Gergely Orosz’ ehrliches Eingeständnis: „Es fühlt sich an, als würde mir plötzlich etwas Wertvolles weggenommen. Es hat viel Mühe gekostet, gut im Coden zu werden, und zu meinen besten Erinnerungen gehört es, im Flow Ideen einzutippen.“
  • Das Gefühl des Verlusts, wenn Hands-on-Coding weniger zentral wird, ist real; aber die Fähigkeit zu wissen, welcher Code existieren sollte, wie er strukturiert sein muss und wann er gut genug ist, war schon immer die eigentliche Kompetenz
• Die Engineers, die als Nächstes aufblühen werden, sind diejenigen, die das erkennen; Geschmack war immer schon der eigentliche Job, er war nur im Code verborgen, und AI macht ihn sichtbar, indem sie das Tippen übernimmt

[clastneo]

Wow, jetzt reichen nicht mal mehr 10x, und man muss schon über 30x nachdenken, haha.

[channprj]

Ich würde solche etwas übertriebenen Ausdrücke wie x-facher Engineer ehrlich gesagt auch gern nicht mehr sehen.. T_T
Sie wirken zwar, als wären sie quantitativ, sind in Wirklichkeit aber ebenfalls qualitative Formulierungen.