Jeremy Freeman, Co-Founder und CTO von Allstacks – Interview-Serie

Jeremy Freeman, Co-Founder und CTO von Allstacks, ist ein Software-Ingenieur, Technologie-Architekt und Unternehmer mit einer Karriere, die sich über Software-Entwicklung, Hardware-Engineering, maschinelles Lernen und Produkt-Innovation erstreckt. Seit der Gründung von Allstacks im Jahr 2017 hat er die Architektur und Entwicklung der Kernplattform des Unternehmens geleitet und dazu beigetragen, die Software-Lieferung durch predictive Analytics und AI-gesteuerte Prognosen zu transformieren. Vor Allstacks hatte Freeman Führungspositionen bei Ravioli Labs und CertiRx inne, wo er an Software-Engineering, Forschung, Anti-Konterfeitschutz-Technologien und Produkt-Entwicklung arbeitete. In seiner frühen Karriere sammelte er Erfahrungen in Start-ups, Unternehmen und der Akademie, einschließlich der Lehrtätigkeit im Bereich Web-Entwicklung am Wake Technical Community College. Sein technischer Hintergrund umfasst eingebettete Systeme, Hardware-Design, große Software-Plattformen, maschinelles Lernen und Engineering-Führung, was ihm eine einzigartige Perspektive auf die Entwicklung von datengetriebenen Produkten gibt, die Organisationen dabei helfen, die Software-Lieferung zu verbessern.

Allstacks ist eine Plattform für Software-Engineering-Intelligenz und Value-Stream-Management, die Organisationen hilft, die Vorhersehbarkeit und Effizienz der Software-Entwicklung zu verbessern. Die Plattform integriert Daten aus Tools, die während des gesamten Software-Entwicklungslebenszyklus verwendet werden, einschließlich Projektmanagement, Quellcode-Verwaltung und Deployment-Systemen, und wendet dann AI und maschinelles Lernen an, um Risiken zu identifizieren, Lieferergebnisse vorherzusagen und handhabbare Erkenntnisse zu liefern. Durch die Bereitstellung von Sichtbarkeit in die Projektgesundheit, Teamleistung und Entwicklungstrends für Engineering- und Produktleiter ermöglicht Allstacks es Organisationen, fundiertere Entscheidungen zu treffen, Lieferunsicherheit zu reduzieren und die Engineering-Bemühungen besser mit den Geschäftszielen abzustimmen. Die Technologie ist darauf ausgelegt, Unternehmen zu helfen, über die intuitive Planung hinauszugehen, indem sie Echtzeit-Betriebsdaten nutzen, um die Software-Lieferleistung und die strategische Umsetzung zu verbessern.

Sie haben eine einzigartige Reise von der Leitung von Forschungs- und Engineering-Teams, die maschinelles Lernen auf Software-Entwicklungsdaten anwenden, bis zur Gründung von Allstacks im Jahr 2017. Welche spezifischen Lücken oder wiederkehrenden Probleme haben Sie beobachtet, die Sie letztendlich dazu veranlassten, das Unternehmen aufzubauen?

Als wir Allstacks starteten, verbrachten wir viel Zeit mit der Kundenerforschung, und das Muster, das sich herausstellte, war konsistent: Unternehmen nach Unternehmen hatten enorme Mengen an Daten und hatten dennoch keine Ahnung, was tatsächlich vor sich ging. Die Lieferung von Software war unvorhersehbar, obwohl sie einige der intelligentesten Menschen im Raum hatten. Dieses Problem war nicht gelöst.

Was schnell klar wurde, war, dass dies kein Berichtsproblem oder ein Integrationsproblem war. Es war ein Beziehungsproblem. Um zu wissen, ob etwas gefährdet ist, müssen Sie wissen, wie ein Arbeitspunkt mit einem Zweig verbunden ist, der Zweig mit einem PR verbunden ist, das PR mit einem Sprint-Ziel verbunden ist und das Sprint-Ziel mit einer Geschäftsinitiative verbunden ist. Dieses Diagramm existiert standardmäßig nicht in der Standard-Toolchain. Sie müssen es aufbauen. Und es gut aufzubauen, ist im Grunde ein Inferenzproblem, bei dem der maschinelle Lern-Hintergrund direkt nützlich wurde.

Unser Ziel von Anfang an war es nicht, einen einzelnen Entwickler bei Funktion X zu beschleunigen. Es war, das gesamte Unternehmen zu verbessern. Wie können Sie die Engineering-Anstrengungen an die Geschäftsergebnisse anpassen? Wie können Sie die Engineering wirklich dem Geschäft dienen lassen, anstatt einfach neben ihm zu existieren? Dazu benötigen Sie ein besseres Verständnis der Datenbeziehungen. Es sind diese Fragen, die fast jede Produktentscheidung getrieben haben, die wir getroffen haben.

Allstacks konzentriert sich auf die Analyse von Daten über den gesamten Software-Entwicklungslebenszyklus. Welche Arten von Signalen oder Mustern sind am besten vorhersehbar, wenn es darum geht, Lieferungsrisiken frühzeitig zu identifizieren?

Ich denke, es gibt keine einzige Menge an Metriken, die gut und schlecht vorhersagt, sondern eher Muster für verschiedene Phasen und Arten von Organisationen. Was ich nützlicher finde, ist die Erkenntnis, dass Engineering-Organisationen durch Phasen der Verbesserung gehen. Dieser Monat ist es die Datenbankleistung. Nächsten Monat ist es die Kommunikation zwischen Teams. Dann ist es “Warum können wir keine PRs schließen?” Dann ist es Beobachtbarkeit. Als Engineering-Leiter schwimmen Sie in Signalen: einige diagnostisch, einige überwachend und viele, die einfach nur Rauschen sind.

Was hilft, ist, mit dem Problem zu beginnen, das Sie tatsächlich sehen, nicht mit einer Metrik, die Sie verbessern möchten. Wenn Sie fragen “Warum fühlt es sich an, als würden wir weniger liefern als im letzten Jahr”, ist das der richtige Ausgangspunkt. Von dort aus denke ich, dass Sie drei Arten von Metriken benötigen: erstens, wie wissen Sie, ob das Problem real ist (vielleicht PR-Anzahl pro Entwickler über die Zeit); zweitens, welche Änderungen machen Sie und wie verfolgen Sie sie auf dem Weg (sagen wir, die Einführung eines AI-PR-Reviewers, wenn das Ihre Intervention ist); und drittens, wie wichtig ist dieses Problem für das Geschäft. Ihre Intuition könnte richtig sein, dass Sie 20 Prozent weniger Code liefern, aber die wahre Geschichte könnte sein, dass QA jetzt dreimal länger dauert. Sie benötigen alle drei Linsen, um zu wissen, ob Sie das richtige Problem lösen.

Sie haben in Branchen wie Gesundheitswesen, Energie und Technologie gearbeitet. Wie unterscheiden sich die Herausforderungen in der Software-Lieferung zwischen diesen Sektoren, und wie hat das die Allstacks-Plattform geprägt?

Ich schätze meine Erfahrung in nicht rein technischen Sektoren sehr. In SaaS-Unternehmen ist es leicht, sich in der Idee zu verlieren, dass die Software selbst das Ziel ist. Wenn Sie in einem Geschäft sind, in dem Sie die Software nicht direkt verkaufen, wird Ihre Rolle viel klarer: Technologie ist da, um das Geschäft zu unterstützen. Ich scherze oft, dass, wenn das Geschäft alles auf die gleiche Weise und ohne mich zu tun, es diese Option ohne Zögern wählen würde.

Diese Perspektive ist tatsächlich nützlich. Sie kontextualisiert, was wir alle in dieser Branche tun, und setzt viele Tech-Debatten wieder an ihren Platz. Das Geschäft interessiert sich nicht dafür, ob Sie Python oder Go verwenden. Zeit zu verschwenden, um dies umzuschreiben, ist wahrscheinlich nicht, wo die wahre Rendite ist.

Was über alle Branchen hinweg konsistent bleibt, ist das Fragmentierungsproblem. Unabhängig von der Branche hat jedes Engineering-Team Daten, die über ein Dutzend Tools verstreut sind, mit begrenzter Verbindung zwischen ihnen. Die Details variieren: regulierte Branchen haben längere Planungszyklen und eine geringere Toleranz für Unsicherheit in den Anforderungen, da der Aufbau des falschen Dings teurer ist. Hochgeschwindigkeits-Technik-Shops sammeln versteckte Schulden schneller. Aber der Kern-Fehlermodus ist der gleiche. Teams können Ihnen sagen, was geliefert wurde. Sie können nicht nachvollziehen, warum etwas verrutscht ist, was es gekostet hat oder wo das Risiko vorher sichtbar war, bevor es zu einem Problem wurde. Das ist es, was die Plattform geprägt hat.

Es gibt eine wachsende Erzählung, dass AI die Codierung selbst beschleunigt, während sie Schwächen anderswo aufdeckt. Warum werden Anforderungen, Planung und Spezifikationsbereitschaft zu den echten Flaschenhälsen?

Wir sehen dies täglich. Mit einem guten Agenten und einer soliden Umgebung können Sie von der Idee, manchmal direkt aus dem Mund eines Kunden, bis zur Produktion in buchstäblich wenigen Stunden kommen.

Ein Teil dessen, was diesen Wandel so bedeutend macht, ist die Änderung der Feedback-Schleife. Mit Copilot-Tools ist der Mensch in der Schleife bei jedem Vorschlag. Der AI bietet eine Vervollständigung; Sie akzeptieren oder lehnen es sofort ab. Wenn es falsch ist, fangen Sie es schnell auf. Die Blast-Radius einer schlechten Vorschlag ist eine Codezeile. Agentic-Coding funktioniert anders: Sie geben dem Agenten ein Ziel, er zerlegt die Arbeit, führt einen mehrschrittigen Plan aus und liefert ein funktionierendes Modul. Der Mensch überprüft die Ausgabe, nicht jeden Schritt. Wenn die Spezifikation falsch ist, baut der Agent die gesamte Implementierung zu dieser falschen Spezifikation und Sie finden es bei der Überprüfung heraus.

Das klingt wie reiner Vorteil, bis Sie erkennen, was die vorherige Verzögerungszeit tatsächlich getan hat. Die Verzögerung diente einem echten Zweck. Mehrere Runden intelligenter Menschen, die überprüfen, planen, testen und an Ideen arbeiten, um ein besseres System zu produzieren.

Die Versuchung ist jetzt, es einfach zu machen und all dies zu umgehen. Aber Agenten und Umgebungen sind noch nicht bereit für den gesamten SDLC. Die Geschwindigkeit ist real. Die Qualitätssicherung, die früher über alle diese langsamen Schritte hinweg stattfand, wurde nicht ersetzt. Das ist die Lücke.

Viele Organisationen messen die Produktivität noch immer mit veralteten Metriken. Was machen Führungskräfte grundlegend falsch, wenn es um die Produktivität in einer AI-gesteuerten Entwicklungsumgebung geht?

Die Menschen haben sich auf diesem Thema erheblich weiterentwickelt, seit wir Allstacks gegründet haben. Die Messung hat sich auf Dinge verlagert, die wirklich zählen, und die Rahmenbedingungen sind komplexer geworden. AI stürzt all dies um.

Die traditionelle Software-Entwicklung war grundlegend durch die Geschwindigkeit begrenzt, mit der ein Entwickler Code schreiben konnte, der den Anforderungen des Geschäfts und der zugrunde liegenden Technologie entsprach. Diese Kosten nähern sich Null. Wir bewegen uns auf etwas zu, das näher an einem individuellen Entwickler als Manager von Agenten ist. Dieses Modell erfordert einen ganz anderen Ansatz zur Messung der Produktivität, der auf etwas anderem als Token, die generiert werden, oder Entwickler-Stunden, die verbracht werden, basiert.

Ein Teil der Gefahr bei den aktuellen Metriken ist, dass sie verbergen, was tatsächlich auf Team-Ebene passiert. Senior-Entwickler mit AI-Tools verdoppeln ihren Vorteil: Sie haben den Code-Verständnishorizont und das Urteilsvermögen, um die Ausgabe des Agents zu steuern und ihre Fehler zu erkennen. Frühere Karrieren-Entwickler generieren das gleiche Code-Volumen, verbringen aber mehr Zeit damit, die Ausgabe zu überprüfen, die sie nicht vollständig bewerten können. Die Gesamtgeschwindigkeit sieht gut aus, vielleicht sogar verbessert. Die Lücke zwischen diesen beiden Gruppen zeigt sich nirgendwo in einem Standard-Dashboard. Die richtige Frage, die man zuerst stellen sollte, ist nicht “Wie viel schneller sind wir?”, sondern “Wie viel von dem, was wir geliefert haben, war richtig das erste Mal?”

Wir haben noch keine Branchen-Konsens über das richtige Messmodell, aber Teams, die beginnen, die Ausgabe-Qualität und die Nachbearbeitungsrate zu verfolgen, nicht nur den Durchsatz und die Einführung, werden besser positioniert sein als Teams, die warten, bis jemand anderes es herausfindet.

Ihre Plattform verbindet Daten aus Tools wie Projektmanagement-Systemen und Code-Repositorys. Wie wichtig ist es, diese fragmentierten Datenquellen zu vereinen, und was passiert, wenn Organisationen es versäumen, dies zu tun?

Allstacks war in diesem Bereich erfolgreich, weil wir seit vor der Zeit, als dies ein Begriff war, Kontext-Graphen aufgebaut haben. Wir erkannten früh, dass die Verbindung aller Daten notwendig war, um die Fragen zu beantworten, die die Kunden tatsächlich stellten.

Wenn diese Verbindung nicht existiert, kann AI, die auf Ihren Engineering-Daten arbeitet, nur einen Teil des Bildes sehen. Es kann das analysieren, was in Ihrem Projektmanagement-System ist. Es kann das analysieren, was in Ihrem Code-Repository ist. Was es nicht kann, ist eine Lieferverzögerung auf eine blockierte Abhängigkeit über drei Tools zurückverfolgen, weil die Beziehung zwischen diesen Signalen nicht in der Daten-Schicht existiert. Sie erhalten oberflächliche Analyse zum Besten und selbstsichere, falsche Empfehlungen zum Schlechtesten. Die Modellqualität löst dies nicht. Sie können das leistungsfähigste Modell, das verfügbar ist, auf rohe API-Integrationen legen und immer noch die tatsächliche Ursache eines Problems verpassen, weil die Daten die Beziehung zwischen den Signalen nicht kodieren. Müll rein, Müll raus, unabhängig davon, wie intelligent das Modell ist.

Diese Verbindung ist die Grundlage. Es ist das, was es uns ermöglichte, als Erste mit Fähigkeiten auf den Markt zu kommen, die noch nicht nachgebildet wurden.

Wenn AI-Agenten mehr in die Entwicklungs-Workflows eingebettet werden, wie sieht eine gut vorbereitete Engineering-Organisation im Vergleich zu einer, die nicht bereit ist, aus?

Ironischerweise ist es nicht so unterschiedlich, wie wenn Sie eine Klasse von Sommer-Praktikanten einstellen. Sie benötigen starke automatisierte Test-Suiten, solide Dokumentation, eine reife CI/CD-Pipeline und die Schutzmechanismen, die Sie einrichten würden, wenn Sie einen vertrauenswürdigen, aber untrainierten Entwickler zum Team hinzufügen.

Was auch wichtig ist und was die Leute tendenziell unterschätzen, ist, regelmäßig zurückzukehren, um die Grundlagen zu überprüfen: Ihre Agenten-Regeln, Ihre AGENTS.MD-Dateien. Sie können eine solide erste Runde durchführen, aber es ist leicht, in einen Rhythmus zu geraten, in dem Sie in der neuen Weise liefern und vergessen, dass Sie tatsächlich viel von den schlechten Standardwerten wegtrainieren können. Dinge wie das Trainieren eines Agents, um vor jedem Commit zu testen, sollten nicht eine menschliche Erinnerung jedes Mal erfordern.

Eine diagnostische Frage, die ich jedem Engineering-Leiter stellen würde: Können Sie mir sagen, was Ihre Agenten im letzten Sprint produziert haben, welche dieser Ausgabe als solche akzeptiert wurde und welche überarbeitet wurde, und wo die Überarbeitungs-Anstrengung konzentriert war? Wenn Sie das beantworten können, haben Sie die Instrumentierung, um zu verbessern. Wenn Sie es nicht können, fliegen Sie nach Gefühl.

Sie haben die Bedeutung der Ausrichtung der Engineering-Arbeit an die Geschäftsergebnisse betont. Wie können Organisationen diese Lücke auf praktische und messbare Weise überbrücken?

Ich habe zwei Hauptfehler-Modi gesehen. Der erste sind Unternehmen, die ihre Engineering-Teams nicht mit Produkten paaren. Viele Team-Strukturen sind Legacy und haben sich seit langem nicht geändert. Ein Team könnte ein Stück von drei verschiedenen Produkten besitzen, während ein anderes vier vollständig besitzt. Die Engineering-Investitionen kommen größtenteils auf die Headcount zurück, und wenn Teams nicht an Produkte angepasst sind, wird es sehr schwierig, zu sehen, wo die Geschäftserwartungen von der Realität abweichen.

Der zweite Fehler-Modus ist, dass nicht alle Arbeiten, die in die Erstellung und Wartung von Software investiert werden, berücksichtigt werden. Es gibt eine enorme Kategorie von geschäftlich unsichtbarer Engineering-Arbeit. Mein Lieblingsbeispiel ist die Aktualisierung von Paketen. Nicht-technische Geschäftsleiter haben oft Schwierigkeiten, den Wert oder den Grund zu verstehen, warum es ein laufendes und unvorhersehbares ist. Aber sie können Investitionskategorien verstehen. Wenn Sie es als “kritische Sicherheits-Updates” darstellen und zeigen, wie viel Kapazität es im Durchschnitt verbraucht, sprechen Sie eine Sprache, mit der sie arbeiten können.

Wenn Sie einem Vertriebsleiter anbieten, zwischen einem npm-Paket-Update und der Funktion zu wählen, die er benötigt, um einen Deal abzuschließen, gewinnt die Funktion jedes Mal. Aber wenn Sie es als “wir fallen aus der SOC-Konformität oder wir liefern diese Funktion” darstellen, zeigen Sie ihnen zwei Kompromisse, die sie tatsächlich bewerten können. Diese Umformulierung ist das ganze Spiel. Wir haben gesehen, wie Kunden die Zeit für die R&D-Kapitalisierungsberichterstattung um mehr als zwei Drittel reduzieren konnten, indem sie diese Arbeits-Klassifizierung automatisch anstelle von manuell machten. Der Mechanismus ist der gleiche, egal, ob das Ziel die Kapitalisierungsberichterstattung, die Rechtfertigung des Personalbestands oder der Nachweis des AI-ROI ist: verbundene Daten ersetzen korrelierte Tabellen.

Angesichts Ihrer Erfahrung in der Handhabung von Engineering-Teams und der Lehrtätigkeit im Bereich Web-Entwicklung, wie sehen Sie die Rolle der Entwickler sich entwickeln, wenn AI einen größeren Teil der Codierungs-Arbeit übernimmt?

Ehrlich gesagt, mache ich mir ein bisschen Sorgen, obwohl ich vertraue, dass intelligente Menschen es herausfinden werden.

Meine Bedenken sind real. Frischgraduierte werden bald in die Arbeitswelt eintreten, ohne jemals in einer Welt ohne Coding-Agenten kodiert zu haben. Hat die Bildung mit diesem Schritt Schritt gehalten? Die Tools bewegen sich schnell; die Hochschulbildung bewegt sich nicht immer mit. Der andere Wandel, den ich beobachte, ist die Verschmelzung von Senior-Entwicklern und Senior-Produktleuten. Die erfolgreichsten Praktiker im neuen Modell sind Entwickler, die tief in die Produkt-Denke investiert sind.

Was wertvoller wird, ist das Urteilsvermögen: die Fähigkeit, ein Problem präzise genug zu definieren, damit ein Agent es lösen kann, zu bewerten, ob die Lösung korrekt ist, und die subtilen Fehler zu erkennen, die CI bestehen, aber später architektonische Probleme verursachen. Senior-Entwickler verdoppeln ihren Vorteil, weil sie die Ausgabe des Agents steuern und wissen, welche Ausgaben sie vertrauen können. Die Sorge gilt den frühen Karrieren. Der traditionelle Weg, dieses Urteilsvermögen aufzubauen, bestand darin, viel Code zu schreiben und von den Fehlern zu lernen. Diese Feedback-Schleife ändert sich auf Weise, die die Branche noch nicht vollständig durchgearbeitet hat.

Geschichte bietet jedoch einige Gewissheit. Es gab eine signifikante Gruppe von Menschen, die glaubten, dass Compiler die Arbeit von Assembly-Entwicklern überflüssig machen würden. Der Technologie-Wandel geschah, wie sie es vorhersagten. Was passierte mit den Entwicklern, die dem gleichen Skript nicht folgten? Im Laufe des nächsten Jahrzehnts wuchs die Gesamtzahl der Entwickler. Viele dieser Assembly-Programmierer lernten eine neue Sprache und beherrschten sie aufgrund ihrer grundlegenden Kenntnisse. Ich denke, eine Version dieses Musters spielt sich wieder ab.

Wenn Sie in die Zukunft blicken, wie sehen Sie AI die Software-Entwicklungs-Lebenszyklus über die nächsten drei bis fünf Jahre hinweg umgestalten, und wo werden Unternehmen den größten Wettbewerbsvorteil erzielen?

Wir werden einen Feature-Wettlauf sehen, wie wir ihn noch nie zuvor gesehen haben. Da die Kosten, um zu bauen, nahezu Null sind, stehen Unternehmen, sogar große, vor einer neuen Einschränkung: die Sammlung und Validierung von ausreichend Kunden-Feedback, um qualitativ hochwertige Dinge im großen Maßstab zu bauen.

Der Wandel, der eintreten muss, ist, dass die Messlatte für das, was gebaut wird, höher gelegt werden muss. Die aktuelle Einschränkung in den meisten Engineering-Organisationen ist einfach: fünf Top-Prioritäten, vielleicht zwei geliefert. Mit Agenten kehrt sich das Verhältnis um. Sie könnten fünf Top-, zehn nächste und zwanzig eventuell auf der Liste haben und hundert liefern. Die Frage, die noch niemand vollständig beantwortet hat, ist, wie Sie die letzten fünfundsiebzig davon abhalten, schlecht konzipiert und schlecht ausgeführt zu werden.

Zwei Dinge, von denen ich ziemlich sicher bin, für das Zeitfenster von drei bis fünf Jahren. Erstens: der Wettbewerbsvorteil in der Engineering-AI wird aus Kontext-Tiefe und -Breite kommen, nicht aus Modell-Qualität. Die Modelle werden zum Standard werden; jedes Tool wird leistungsfähige haben. Was die führenden Plattformen unterscheiden wird, ist, wie tief sie Ihr spezifisches Unternehmen verstehen: Ihre Repositorys, Ihre Team-Struktur, Ihre Liefer-Historie, Ihre Deployment-Muster. Die Tools, die Ihr System kennen, werden grundlegend andere Antworten liefern als die, die es nicht tun. Zweitens: der Wandel von reaktiv zu proaktiv. Heute beantworten die Tools Fragen, wenn sie gestellt werden. In ein paar Jahren werden die führenden Tools kontinuierlich beobachten und Risiken aufdecken, bevor Sie fragen. Organisationen, die diese Kontext-Schicht jetzt aufbauen, verdoppeln ihren Vorteil. Die nächste Generation von Tooling muss das Qualität-im-Maßstab-Problem lösen, und die Organisationen, die es zuerst herausfinden, werden einen echten Vorteil haben.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Allstacks besuchen.