# AI as Multiplier: Strategic Software Architecture

**Podcast:** Software Architektur im Stream
**Published:** 2026-09-03

## Transcript

A note from our team.
Software Architecture in Stream will be streaming live from the ISAQB Software Architecture Gathering in Berlin this November.
Join us on-site.
You'll find more about the program and special discount code for our community on our website software-architecture.tv.
Hello and welcome to another episode of Software Architecture in Stream.
It's hard to pronounce this German in an...
Kevlin Henne An independent consultant, speaker, trainer, writer, thought guy.
These days I think I've reached the point where I just like, let's explore ideas and play around with those as well.
I don't think that's a professional role, but I think it's certainly something that I enjoy doing.
And I'm based in the UK.
As I say, I'm independent, so therefore I'm not affiliated with any company.
Sometimes this means good stuff in the sense that I can see different companies or either at the very minimal level of doing a talk and sometimes I do some consultancy and get a little bit closer to things.
But it gives me a very different view, I guess, than other people might get of what's going on in software right now.
But again, I'm also guided by my interests on that.
So regarding your interests, Wir haben uns ein bisschen über dein Buchshelf gesprochen und dass du ein paar Sachen geschrieben hast.
Und könnte es sein, dass du 97 Sachen begonnen hast?
Ja, die 97 Things-Series begonnen hat in den 2000en, in 2010.
Es war ein Mann, Richard Monsen-Hafel.
Ich habe das erste Buch mit 97 Things Every Software Architect Should Know und dann habe ich in die, die wahrscheinlich am besten, die in der Serie 97 Things Every Programmer Should Know.
Und diese Buchs sind quasi Crowdsourced, viele Kontributors und natürlich 97 Things und normalerweise sind sie zwei Pages lang, für die Reckommendation oder Idee, um zu explore.
Und ich fand das ein wirklich tolles Projekt.
Open source code, but with words and concepts.
And that was very enjoyable.
And then just around the time of the pandemic, myself and Tricia G.
did 97 Things Every Java program I should know.
And I've recently been thinking about maybe doing another 97 Things book, but maybe that will come up in conversation.
We'll see how this one goes.
So I jotted down a starter question, which was, let's start easy.
Your favorite...
Du hast es noch ein Favourite Sprache?
Ist es noch ein Favourite Sprache?
Ich denke, das ist die beste Frage.
Ich denke, wenn ich noch ein Favourite Sprache war, war es viel mehr wichtig, wie ein Favourite Sprache oder etwas.
Aber ich habe auch noch etwas anderes, ich bin wirklich schlecht mit diesen Fragen.
Wenn jemand fragt, was ihr Lieblings-Favorite ist, ich kann nicht wählen, weil ich weiß, was ich will.
Es kann auch in einem Tag werden, aber es verändert in einem Tag.
Es verändert auf mein Mood oder was ich habe einfach nur ein paar Dinge.
Ich habe ein paar Dinge, die ich statistically kann, ob ich ein Lieblings-Favorite kann, ob ich nicht, ob ich ein Lieblings-Favorite kann.
Und ich glaube, ich glaube, ich glaube, es ist nicht mein Lieblings-Favorite.
Es ist nicht...
Ich bin nicht so engagiert mit es, gerade ich habe.
Ich habe nicht viel Java gemacht.
Wenn ich es mit dem Programm, habe ich den meisten dieses Jahr benutzt, ich denke, es wird Python, wenn wir von diesem Punkt aussehen.
Ich habe ein paar Mal mit C-Sharp gemacht.
Und habe ich ein Bunches C++ mit Bits of C.
Ja, ich weiß nicht, dass ich unbedingt nicht mehr als Favourites spielen.
Ich finde es schwer zu sagen, welche von den Toppen der Stacken sind die ich wirklich liebe.
Und wenn ich mich mit einem Spiel mit einem Spiel mit einem, und es funktioniert, dann ist das mein Favourite.
Wenn ich mit einem Spiel mit einem nicht funktioniert, dann ist das nicht mein Favourite.
Es ist ein sehr emotional und Zeit-Based-Judgment.
Do Sie still schreiben, Code, Code yourself?
Yes, I do.
Yes.
Well, I'm currently not working on any major projects or doing anything production-oriented, so most of the code I write is small fragments.
And so I, you know, small fragments and experiments.
So some things I'm going to generate, some things I'm going to write myself, because...
Ich weiß, dass ich das einfach nicht so gut bin.
Es ist einfach so einfach.
Es ist ein Beispiel, wenn ich ein bisschen mehr, ich glaube, es ist einfach so.
Es ist ein Beispiel, wenn ich ein bisschen mehr, ich glaube, es ist ein bisschen mehr, ich glaube, es ist ein bisschen mehr praktisch.
Es ist einfach, ich habe das, ich habe das, ich habe das, ich habe das, ich habe das, ich habe das, ich habe das, ich habe das, und dann habe ich das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, was das, oder wenn ich das ist, das ist wie off-base, dann muss ich das, wie ich das, oder ich jetzt verstehe, was ich jetzt verstehe, was ich jetzt verstehe, was ich möchte.
Es wird mir weniger Zeit zu bekommen, als es zu spätigen und Prod an LLM zu bekommen.
Ich mache eine Pointe, um die Code zu machen, weil es manchmal mehr Zeit zu machen, um es zu machen, um es zu machen.
So it's kind of more mixed mode.
And yeah, in that sense, I guess a more hybridized way of working.
Before we dive deeper into coding and maybe also coding with an LLM, you influenced lots of people.
I remember some talks where you talked about the shortcomings of the Java language.
But what influenced?
Me, myself, most were your collection of software failures in the wild.
And every time I see some screen where, a boot screen or something like this on an airport, I always think about, hey, that's a Kevlin Henney.
Should I take a picture?
Should I send it to him?
Do you still collect those?
Yeah, yeah.
I mean, what I do is...
So, for those of you who are not aware of this, I mean, years ago, it was one of those things that I started taking photographs for which we can thank, ultimately, the integration of cameras into phones, because obviously then you walk around with a camera everywhere.
And I started noticing more...
I'm starting noticing errors.
Und natürlich, als mehr unserer Leben und unser Publikum ist mediated by software-related devices, werden wir mehr Errors haben.
Und ich habe mich gedacht, diese sind interessant, weil ich mich für mich interessant war, dass sie eine, sie sind fun, aber sie zeigen uns wo die reale Aktion ist.
Ich denke, ein paar von Unternehmen ist nicht was wir in Software Development, das ist warum ich manchmal...
Das ist, dass wir jetzt die Wahrheit machen.
Ich weiß, dass sie ein Stück aus dem Art ist.
Sie sind die Software-Developers, ohne die Liebe zu, die die Schwerden der meisten accidentalen Art auf der Welt.
Hier ist ein Schwerden.
Wenn du es durch die Artistik Lensens hast, ist es ziemlich funny.
Aber in der Zeit, was ich finde, ich finde, was ich finde, ist, wenn etwas breaks, wenn etwas crashes, es zeigt, wie es wurde.
Es zeigt, wie es wurde.
Vielleicht ist es ein Stacktrace.
Es war ein Information Screen, vielleicht in einem Shopping Mall oder so.
Aber dann plötzlich sieht man ein StatTracer und man denkt, oh, auf der Backend ist sie eine SQL Server.
Und auf der Frontend ist das all das JavaScript Error.
In other words, man sieht die Technologie, particularly in StatTracers.
Manifest ist ein Shopping List, ein Manifest, von alles, was er gemacht hat.
Aber also, man sieht wie es wurde.
In other words, you get a sense for what was tested and what was not tested.
So I find it's interesting.
It's like in software development, ultimately what we do is we create an illusion.
We create an illusion of something perfect.
At this point in time, everybody here is experiencing the illusion that we are kind of doing almost like a live studio, old school.
Das ist ein Telefon.
Eigentlich ist es nicht ein Telefon in der Tradition sense.
Es ist ein Computer, die sich ein Telefon anzunehmen.
Wir sind ein Telefon anzunehmen, was traditionell ist, und wir haben das Format in die modernen Age, die Podcast-Era und so weiter.
Und wir haben das.
So mein Universal Computing device ist jetzt behaving wie ein Talking Heads device, wenn du like.
Aber wenn es erlöscht, dann verliert das Illusion.
Es wird dann wieder etwas anderes.
Und wir sehen wie es war.
Für mich ist es eine Faszination.
Und so mit Software, wenn wir auf Social Media haben, Leute haben, weil ich diese Fotos in meine Talks oder in Workshops, ich würde sie in den Break zeigen, und Leute haben sie zu mir.
Und so ich habe sie retweeting.
Und es hat sich gemacht, und ich habe gesagt, dass hier die Errors sind, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was das hier ist, was Und so, therefore, es hat keine Sicherheit, keine Sicherheit.
Should wir be worried?
Ja, wir sollten.
In other words, es zeigt etwas zu uns.
Wenn du es so, hältst du ein mirror, was wir tun.
Ja, so du denkst, es ist wirklich ein security-issue.
Ich habe, ich habe, auf einem weekenden, einen Banking Terminal.
Und da war ein Keyboard connected zu es, weil du hattest, wer du sendest, und so weiter.
Und ja, es ist auf einem Shell.
Und es hat versucht, und es funktioniert.
Und wow.
Ich habe gesehen, ja.
Ja, ich habe das Problem mit dem Kunden nicht testet.
Ich glaube, dass drei Probleme sind, die diese Fehler-Schreens, auf der Bildung des Schraens und wo es ist, stellen.
Erstens, wir haben die Verwaltung in die Firma oder die Plätze, die es verabschieden.
Zweitens, sie können sie nicht sehen.
Ich will nicht sehen, was ich an Error-Schreens.
Ich will sehen, was die Zeit mein Train ist.
Ich bin nicht hier zu sehen, zu sehen, zu sehen, zu sehen, zu sehen, zu sehen.
Wenn es ein App, ich bin mit, ich bin probably versucht, zu tun, ich bin versucht, zu kaufen, und jetzt kann ich nicht.
In anderen Worten, es ist es, es ist ein Diener eines Service.
Es ist nicht ein Intentional, aber als ein User, ich habe den Diensten, was ich versucht, das zu tun.
Das ist ein Software Reliability concern.
Das ist ein Software Quality concern.
Und dann haben wir...
Das ist die Sicherheit, dass wenn wir ein Fehler haben, oftmals ein Fehler ist, ist eine Angriffspunkte.
Bugs sind Angriffspunkte, ist eine sehr einfachste Art.
Wir sind nicht nur ein Highlighter, dass etwas nicht funktioniert und das Inconvenient ist, sondern wir sind eigentlich ein Highlighter, dass es quasi Indistinguishable ist.
ein security-brich.
Und ich möchte euch alle sagen, Crowdstrike war zwei Jahre, das letzte Mal.
Und eine der wichtigsten Dinge ist, dass das die größte Sicherheit in der Geschichte ist.
Und was wichtig ist, dass die CEO gesagt, das ist nicht ein security-incident.
Es ist nur ein bug in unsere Software.
Und es ist einfach, nein, du bist die Unternehmen, die Leute zu für security sind.
Und ein security-large-scale failure ist nicht aus dem Angriff.
Das war, was ein Anweserbieter.
Es war nicht intentional.
Es war kein Echt.
Aber es ist ein Echtes-Ichtes-Ichtes.
Und so, wir können, uh, most, uh, failures kann, wie ein Echtes-Ichtes-Ichtes-Ichtes, um, even wenn es nicht ein Echtes-Ichtes-Ichtes war.
Um, so, das ist ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein, ein ist in diesem Sinne sehr interessant, weil es ein Reminder ist.
Ich denke, wir werden in unsere Unternehmen, unsere Code, unsere Prozesse, unsere Tools verletzten, dass irgendwo aus dem Menschen, die nicht all das interessiert.
Und deswegen, vielleicht unsere Prioritäten sind nicht immer woanders sie sollte.
Der Impact von solchen Fällen kann, wow, sein, was huge.
CrowdStrike war interessant, sogar fun, zu sehen.
Aber ich kann mir vorstellen, dass viele Leute in der Flugzeuge zu finden, in der sie nach Hause zu kommen, in der sie nach Hause zu kommen, in der sie zu negatieren, und sie haben es nicht gewonnen.
Wann da nicht der Stimme, dass sie das so ausgesprochen hat, dass sie das so ausgesprochen hat?
Oh, ja, ja, ja, ja.
Ich habe vergessen, das Mann, der CPM war auf dem Flugzeug.
Weil die Welt könnte mit einem sehr unterschiedlichen System sein sein können.
Aber ja, es turns out, dass es das Stimme ist 80% der Erfolg.
Ja.
So, wir haben das Stream, etwas mit AI und Mirror.
Your talk at Software Architecture Gathering has another title.
It has AIs Through the Looking Glass, I think.
Yes, that's right.
And to be honest, as a non-native speaker, yes, I know this title, Alice Through the Looking Glass or something like this, Alice in Wonderland.
And Looking Glass, I thought about what does it really mean?
And so I...
This time I used the term mirror.
Looking glass seems to be an old word for mirror.
So, you will...
I will actually just say, by the way, even as a native speaker, looking glass is not...
I'm not even sure my grandmother used that term.
So in other words, by the time we hit 20th century, people didn't call them looking glasses.
So it's a very...
If I ask my kids what a looking glass was, they might remember...
Ich habe das Wort gelernt, weil ich das Thema gelernt habe.
Aber ja, ja.
Es ist sehr viel über AI in the mirror.
So, du hast bereits gesagt, du still schreiben code bei dir selbst.
Du hast nicht alles geöffnet.
Ja.
Wir arbeiten mit AI, alle von uns, seit drei Jahren, oder so.
Wir haben mit dem, hey, AI only creates slop.
Jetzt sind wir wieder an einem Punkt.
Hatte deinem Meinung auf AI und mit AI verändert, durch die letzten drei Jahre?
Es ist ein yes und ein no.
Es ist ein yes, in smallen Weise.
Und noch in others.
Ich denke, die andere Sache we also haben zu veröffentlichen ist, dass in der Industrie, man in der Bühne ist, dass man in der Bühne ist.
Und viele Menschen nicht benutzen AI für Bühne.
Ich werde mich nicht schocken, aber wir sind in der Bühne, wo wir uns auf social media und den Resten haben.
Most Menschen nicht benutzen AI für Bühne.
Wir haben nicht yet über das Punkt.
Oder eher exclusively.
So die Punkt ist, dass es da sind, viele Menschen, Genuinely, pretty much don't look at the code.
And they're doing a whole load of stuff.
And they think everybody's doing that.
And they live in a bubble where everybody's using that language and they're talking about it.
And they're all very excited by that.
That's not most developers.
Most developers are working in much more hybrid contexts.
And they are still taking initial steps into the world of AI.
Sometimes it's just simply through a more elaborate autocompletion.
Für mich, die meine, some of meine views on this haben nicht so viel weil die LLM haben besser, sondern weil wir jetzt sehen die consequences.
Und die Dinge, die ich drei, vier Jahre habe, sind, das ist eine der wenigen Zeit, ich kann sagen, ich habe die Zukunft gekämpft.
Ich werde nicht alles, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde nicht alle, ich werde One of the things I said about three years ago, three years ago I made a couple of tweets on Mastodon, one of which was, we are going to have to be really serious about testing.
In other words, my specific wording was, code generated by LLMs is going to need more testing than code written by developers.
Und das ist wirklich wichtig.
Das hat nicht verändert.
Was ist funny, ich habe auch gesagt, dass in 2016 ein Video von mir war, und das ist vor LLM, das ist vor der Transformer Architektur.
Somebody hat gesagt, was über die Zukunft der Software-Developung?
Und ich denke, sie hat eine lange Zeit in der Zukunft, und ich glaube, wir alle alle.
Und funnily enough, an der Zeit, ich sagte, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir werden müssen, was wir Das ist die Sache.
Das ist die Funny Sache.
Ich sehe jetzt mit Menschen, dass sie jetzt nicht mehr wissen.
Das ist jetzt nicht so, dass sie jetzt nicht mehr wissen.
Das ist jetzt nicht so, dass sie jetzt nicht mehr wissen.
Es ist einfach, dass sie wirklich slow sind.
Sie haben eine Chance, um es nicht mehr zu tun.
Ich meine nicht in einem Baden-Würfe.
Es ist nur, collectively, als ein Industrie, wir haben ein Blindspot.
Und so 21st...
So, diese Zeit, talking about testing, ist viel mehr acceptable als es, in den 1990s oder 2000s.
In that sense, my view on a number of things has not changed.
Do we need to have good architecture, good understanding of our systems?
Yes, we do.
Has that changed?
No.
Did I say that this was important when people started talking about AI?
Yes, I did.
I have not changed that.
And in fact, now we have evidence that we've got a bigger problem at play.
One of the other observations I made is that LLMs are now...
und das war über drei Jahre, werden sie zu generieren, und ohne zu meaning, developers haben sich von einem Rolle von der Reise zu der Passive agents in der processen, wo sie einfach fixieren und überlegenen Dinge.
Und das ist pre-Agentic.
Und boy, war ich right.
Ich habe nicht gemeint, aber wow.
Und so...
Wir sind komplett ignoriert all die realen Probleme mit Software Development.
Und viele Leute haben in dieser Mode gefallen.
Und das ist eigentlich nicht so viel die Tool-League.
Das ist warum ich sage, die Mirror ist wichtig.
Weil es zeigt uns, wer wir sind und wie wir arbeiten.
Und AI ist ein viel besser Mirror, die uns unsere Schott-Comings zeigen.
Und wenn ich sagen, unsere Schott-Comings, manchmal ist es ein individuelles Ding, aber manchmal ist es unsere Businesses.
So, ich habe gerade den Terme Meat Proxy.
Ja, ich habe das auch.
Ich habe das nicht gesehen.
Ich habe das nicht gesehen.
Ich sehe das mit Software Development, aber auch mit anderen Leuten.
Die Dinge, die Leute immer noch nicht zu remember, ist, dass die meisten Leute, die AI nicht mehr, sind die Software Developers.
Und mit Proxying ist viel Zeit.
Es ist passiert in Schulen, es passiert in regularer Workplaces.
Ich habe jetzt einen Moment mit mir aus dem Projekt.
Es ist ein Schuss, dass wir uns so dass wir unsere Fehler haben, unsere Schott kommen.
Ich bin nicht gut an zu sagen, aber es ist eine Schuss, das eine große Projektion, und bei der Kontraktion, sie müssen 80% der Länge für ihre Tests haben.
Und die Senior-Developers werden nervös, wenn es um die deadline ist.
Und die Junior-Developers werden nervös, die Senior-Developer sagen, oh, no problem.
Und eine Woche vor dem deadline, der Senior Developer hat die Automated Test für alle Getters und Setters in Java und erreicht den 80%.
So, ich glaube, das ist nicht die Testung wir wollen.
Und ich glaube, das ist auch unser Zukunfter Problem.
Ich meine, die Tool Providers zeigen uns, wie gut die LLM ist in creating software.
After creating software, it writes the test and then it writes the documentation.
In all my trainings I say we want to do test-driven development and not development-driven testing.
Do you see this as a problem?
I do.
I think the problem that we have in this space is that So, let's borrow this idea that's become particularly popular since last year's DORA report on this, is that we understand AI as a multiplier.
And this is something I found myself saying a couple of years ago, because I said, okay, a lot of people are using AI, whether it's just a simple, you know, this is, before we really hit the agentic era, and honestly, I'm going to say that, that doesn't actually change the narrative that much for this particular aspect.
A lot of people felt they were being better.
They felt they were being more productive.
The statistics actually did not show that.
But what we find with any tool is that the tool is neither good nor bad.
So, you know, although there are a whole load of questions we have about AI, intellectual property, how the companies who are pushing these things are doing that and all the rest of that, that's a different discussion.
If I am given a multiplying tool.
There will be some group of people who really understand what they're doing and they will do incredibly well with it.
There are people now who are using AI who are multiplying to great effect and they are doing incredibly well.
Now everybody wants to be them, but a lot of people assume that by using AI they become them.
It's like that's not how any of this works.
This is why the mirror thing is important.
What you're doing is you are multiplying a skill and competence that was already...
in die individuellen oder die Kulturen der Existenz.
Sie bereits hatten diese Kultur und das war der Ethos, individuell und collectively.
Und du siehst ihnen diese unglaublich-fähige Geräte und du wirst, ja, du wirst du was, von such an Arrangement.
Was die meisten Menschen sind blind, ist die Fakt, dass sie in dysfunctional environments arbeiten.
Die meisten Menschen sind nicht going zu bekommen.
Und in fact...
In other words, when you're using AI, developers are either going to find they get what happens is better, the same, the same remixed, or worse.
And most people are actually doing worse than they were before they adopted AI tools.
They just don't know it.
They're busier than they were before.
They are hitting more metrics.
You just talked about statement coverage.
It's like, yeah, they're filling the metrics.
We've got ticket-driven development.
Now, ticket-driven development was already a problem before AI.
I remember visiting a company.
I was just running some training courses for them.
And what was fascinating is that I just made some comments about some things, and they sort of said, oh.
Wir wissen nicht, dass du so viel über die Firma, Kevin, weil du einfach all unsere Probleme beschrieben hast.
Und ich war über die Zusammenarbeit zwischen der Produkt-Team und der Development-Team und wie sie, und wie sie, was ich würde, was ich würde, Ticket-Driven-Developen.
Und ich sagte, das ist ein Schmerz-Werrücker-Werrücker-Developpapier.
Und eine der Leute, die ich in, die ich in, zu machen, zu machen, aber, ultimately, die Firma nicht wollte, das message.
Und was sie jetzt haben, ist sie haben eine massive AI-adoption, aber ich habe nichts zu tun mit ihnen.
Und das hat nur die Problem gemacht.
Ich sah wie sie war, ohne einfach nur AI-adoption.
Aber wenn sie jetzt gehen für eine voll AI-adoption haben, dann sind sie nicht gut für das Unternehmen, wenn ihr arbeiten da.
Ich denke, dass ihr...
Ich denke, ihr habt viele Tickets.
Ich denke, ihr seid sehr busy.
Ich denke...
Das ist die Problem.
Das ist das Problem.
Das ist das Problem.
Das ist das Problem.
Das ist das Problem.
Das ist das Tool, das kann uns zu lösen, die wir uns zu lösen, die wir in Software haben, für decades.
Und wir können sie wirklich, wir können sie wirklich schnell, wir können sie wirklich, wir können sie wirklich leicht machen.
Wir können sie legacy code address.
Wir haben eine Tool, das wir uns zu lösen, in einer Weise, wir haben in einem Weg, das wir nie haben vorher gemacht.
Und ist das was Leute machen?
Nein, sie sind eigentlich mehr legacy code.
So, rather than reducing die Menge, wir nutzen AI zu multiplyen und zu arbeiten die Probleme der vorherigen Generationen, um die Probleme zu verändern, um die Probleme zu verändern.
So, wir haben ein bisschen ein Problem hier.
Und das ist human nature.
Und da sind, ich sage, ich bin ein AI-skeptiker.
Ich bin ein human-skeptiker hier.
Ich bin in dieses Business lange genug, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich in diesem Business habe, dass ich mich nicht verwendet habe.
What you're basically saying is, first, when I want to use a tool, I have to know which way around I should hold the hammer to use the hammer.
So if I don't know it, then I will not have success.
I will not have the multiplication of my work.
Yeah, I will multiply the negatives rather than the positives.
Yeah, yeah.
When you talk about the multiplication factor, Ich erlebe verschiedene Dinge mit AI.
Ich meine, die Multiplikation von meinem Arbeit ist ein Traum.
Aber ich erlebe, was ich erlebe, ist, dass ich AI benutze, um mehr Tests zu schreiben, um mehr Dokumentation zu schreiben, nicht mehr Features zu schreiben.
Ich habe jetzt die Zeit, um besser zu machen.
Und das ist nicht der Anzure der Manager.
Der Manager will es weniger Entwicklungen.
Und was ich auch erleichtert ist, dass AI mich erneutt.
Und das ist warum die erste Frage über die Sprache ist, ich denke, so fascinating.
Es ist einfach, AI lässt mich in jeder Sprache es möchte.
Nicht, ich möchte, aber AI möchte.
Und in fact, du hast die Hammer point.
Warum benutzen wir ein Hammer?
Weil es lässt mich zu extendieren.
Ich kann versuchen, ein Nail in zu versuchen, oder ich habe das, oh, ich habe mehr Momentum.
Ich habe das Moment Arm, ich kann etwas tun.
Und genau die Art du beschreiben, deine Usage ist eine der größten Worte.
Es ist eine der größten Worte, die ich kann etwas tun, aber jetzt kann ich etwas weiter.
I can do more complete work.
My documentation can be better.
My test can be more thorough.
I can get this kind of feedback loop and completeness that I might not have been able to, rather than merely go faster.
And that's the problem is, in many organisations, and we see that you can take AI out of the equation, and you still see this desire for speed has been...
Particularly, I would say, it's increased the last few years.
I think that there's a...
That has been...
So AI came along at the time when everybody was trying to go faster.
The problem is what we find is...
And this actually relates also to the Alice in Wonderland reference, the Looking Glass reference, with the Red Queen's race.
And the Red Queen, she has to run...
Sie hat sie zu run, nur zu stehen, sozusagen.
Und wenn sie eigentlich wollen, sie hat sie zu run twice as fast.
Und das ist wo wir heute sind.
In other words, wir sind viel busier, collectively.
Und wiederum, ich muss immer qualifizieren.
Ich bin nicht sagen, dass individuell, alle haben die gleiche Erfahrung.
Aber organisativ, wie Sie sagen, wir wollen mehr features mit fewer people.
Und es ist einfach, ich will sagen, wir wollen mehr features mit fewer people.
Ich will sagen, ich will sagen, wir wollen mehr features mit fewer people.
mit den Leuten du hast.
In diesem Sinne, alles was du nicht zu tun.
Du musst nicht mehr aufhören, weil es wird ein bisschen zu tun.
Wenn du alles gut machen kannst, dann wird es ein bisschen zu tun.
Wenn du alles gut machen kannst, dann wird es gut.
Denn es ist alles besser.
Du bist nicht zu spüren.
Und die Sache, die ich wirklich starte mit Ihnen darüber sprechen, ist ein Gedan von John Senn.
Ich sah ihn zu sprechen, der erste Lean Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban-Kanban- Value demand versus failure demand.
This idea that if we are going to measure something, we should always be careful about what we measure.
But when we are looking at where is the demand for our work, so the economic sense of demand, what is it that is causing me to do this work?
So if I have, and the simple way of looking at it is if you have a developer who is sitting there and you say, okay, Why are you here?
At this moment in time, what are you doing?
And if the developer says, oh, I'm adding a new feature that that customer wanted, and here's the details of it, it's just like, oh, okay.
Now, that sounds like value demand.
We are adding something of value to the system.
In an ideal universe, we want all of our work, all of the demand for our work to be value-driven.
But clearly, there's something else.
Certainly, we know that no system can be 100% efficient.
Physics tells us that we're not going to get a perfect system anyway.
There's going to be another kind of demand, and that is failure demand.
And failure demand is the work that we do because something's not right.
Either organisationally it's not right or technically it's not right.
You know, if I ask that developer and say, oh, I'm fixing a bug.
Well, that's not value demand.
They're not adding value to the system.
I mean, they're removing a loss of value.
So you might say there's a net positive, but that's not the same as actually adding value.
In other words, their work is fixing a problem that existed.
Oder sie haben zu tun extra work, weil sie ein Problem haben.
Und was wir finden ist, dass die meisten Arbeit in Software Development ist failure demand.
Und das ist die Sache, das ist nicht sogar ein AI-Conversation.
Aber wenn du AI in den letzten Jahren herausfinde, du wirst es beinwärt.
Wenn du auf den Weg machst, wenn du 8 Stunden arbeiten, 8 Stunden arbeiten, Honestly, Statistisch, wenn du eine Stunde anstattest, wenn du eine Stunde anstattest, wenn du eine Stunde anstattest, wenn du eine Stunde anstattest, wenn du eine Stunde anstattest.
Because most of your work is dealing with problems.
And I don't mean that in the troubleshooting sense.
If I am trying to understand something, I'm looking, I mean, somebody's got me a 10,000 line method in front of me.
And we'll come back to that 10,000 line method because that's quite important.
That 10,000 line method, and I am wondering how to add a feature and that feature logically will, I need to do something in this 10,000 line method.
All of that extra time that I'm having to deal with is to do with this unmanaged technical debt.
And it builds up, a term that's recently been used, particularly in connection with AI, is cognitive debt.
I'm not entirely sure that it's a good use of the word cognitive debt, but I'm not going to be the one to change the term.
And actually, it's not a new concept.
Most technical debt is cognitive debt.
Most legacy code is cognitive debt.
It just gives a name to the bit is that I genuinely don't understand this.
It's not even that it's bad, but we can tell 10,000 line method is bad.
Es ist einfach, dass ich nicht verstehe.
Ich habe es nicht verstehe.
Und das ist Fähler Demand.
Ich habe es zu tun, re-einanderzusetzen, aber auch mit dem Werk, mit dem alles zu tun.
Die Arbeit, die Leute machen, wenn sie sich an die Verlust, wenn sie die Verlust, wie lange das ist, wenn sie das gut machen können?
Wenn sie das gut machen können, dann wird es 30 Minuten.
Aber es ist nicht gut gut.
Ich habe es all die Zeit, wie ich das nicht verstehe, wie ich das nicht verstehe.
Das ist Fähler Demand.
So, das ist Fähler Demand.
Das ist Fähler Demand.
Das ist Fähler Demand.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Fall.
Das ist der Wir haben eine Möglichkeit, hier ist unsere Möglichkeit.
Wir können die Reutkurs der Failure Demand, okay?
Oder wir können die Rate der Rate zu haben, die wir unsere Probleme fixieren.
Und so, therefore, was wir machen, ist wir besser at fixieren mehr Probleme.
Und unsere Value Demand auch creates mehr Probleme.
Was wir finden, ist, dass wir sogar Anthropik finden, ist es, wie sie ein slighter Unstieg mit der Nutzung der Bugs bekommen.
Sie haben mehr Bugs.
Wenn Sie mit AI benutzen, Sie werden mehr Bugs bekommen.
Das geht zurück, weil es das Tests ist viel mehr wichtig.
Es hat immer noch immer wichtig, aber es ist immer noch wichtig.
Was passiert wenn ich die Nutzung der Bugs bekommen habe, die ich in der System habe?
Ich habe die Arbeit zu machen, um die Bugs zu fixieren.
Jetzt haben wir die Kognitive Debt.
Wenn Sie sich nicht mehr Bugs bekommen, wenn Sie nicht wissen, was Ihr System ist, wenn Sie nicht wissen, was Ihr System ist, wenn Sie Wenn du ein bisschen mehr Arbeit hast, wenn du nicht wissen, was die Architektur ist, dann ist das extra work.
Wenn du Probleme hast, das ist extra work.
Wenn du Probleme hast, das ist extra work.
Was wir machen, ist wir werden progressively productive, bei mehr Arbeit zu machen.
Aber die Arbeit ist nicht value-based, sondern es ist eigentlich failure-based.
Das, für mich, ist die blinde spot, die Leute haben, über AI, in der Sinne von wie sie es, wie sie es, und nicht sehen...
Sie sind optimiert, sie sind besser zu fixieren, sie fühlen sich besser zu fixieren.
Sie fühlen sich mehr progressiv, aber eigentlich, wenn sie die Reut-Course-Probleme fixieren, ich manchmal liken das zu, ich habe gesagt, dass jeder will, wenn man schneller geht.
Wenn du drivingierst, es ist Zeit für ein driving metaphor, wir haben nicht mehr mit der driving.
Okay, du bist in deinem Auto und jemand sagt, wir müssen schneller gehen.
Du denkst, ich will, ich will, mein foot down auf den accelerator.
Das macht mich schneller.
Es ist eine der einfachsten Worte zu gehen in ein Vehikel ist, dass ihr den Weg von der Fahrt auf den Brick ist.
Das ist das, was die meisten Organisationen nicht verstehen.
Sie haben ihre Fahrt auf den Brick, auf der Fluss, die etwas zu dem, die sie zu dem, die sie zu dem, die sie zu dem, und sie sind auch zu tun, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, die sie zu dem, Hey, wir können etwas tun und ändern unsere Arbeit, unsere Arbeit, unsere Arbeit, und tatsächlich die Reaktionale Probleme zu lösen.
Und nicht.
Sie versuchen zu schnellen, die Foto auf den Ancelerator zu pushen.
Wenn viele Organisationen genommen haben, die Foto auf die Brake haben, haben sie einen sofortigen Speedup.
Und ich denke, das ist...
Mein Tipp an jemandem ist, AI ist ein sehr guter Tool für ein paar Dinge, aber sind Sie die richtige Sache?
Anyway, that's a whole load of thinking that you've just released in me.
Thank you, Ralph.
Wow.
I didn't manage to trace everything in my mind, everything I wanted to ask.
But in the chat, I see that people find this conversation quite interesting.
I also find it quite interesting because of the speed analogy.
Du sagst, wir sollten schneller gehen in order zu werden, um zu werden, um zu werden, um zu werden, um zu werden, um zu werden.
Aber die Red Queen's Race sagt, wir müssen in order zu werden, um zu werden, um zu werden.
Und das hat mich über security gehalten.
So security, du musst in order zu werden, um zu werden, um zu werden, um zu werden, um zu werden, um zu werden, um zu werden, um zu werden.
Und ich denke, dass AI will also be a problem in this case.
Absolutely.
Because attackers will be able to use AI to attack our systems.
And we only have some models with the guardrails which say, oh no, I will not test your software.
This might be an attack.
Yeah.
Wow.
And then there's also the other speed that...
I think that the other company is going faster because of AI, so we have to be faster.
We have to push the gas pedal while standing on the brake.
Wow.
These are huge problems, which are...
They are.
And I think you're right to point out this emphasis.
And I think the way to understand, and yes, and certainly this whole issue of...
All these guardrails in place do prevent you from doing sometimes the thing you intentionally mean to do.
They are well intended, but it's actually, no, I want to be that attacker.
We need to be that attacker to understand our system.
But there is also another point in terms of the efficiency and effectiveness distinction.
And I think I probably, I mean, the idea's been around for a long time, but I think I first learned about it through a talk and then a book by Tom DeMarco called Slack.
Obviously, nothing to do with the tool.
This predates the tool.
But the idea, Slack, is he was encouraging the idea that you cannot have one, you cannot, you should not in your organisation have high utilisation in terms of the time I'm spending working on something.
You need to have Slack because of manoeuvrability.
In other words, you cannot have your time being 100% efficient and organised and ticketed with priority items because then it means you have less manoeuvrability.
So, although in one sense you are efficient, like a machine, then that's great as long as nothing else happens, as long as nothing else needs your attention.
And security is the thing that, you know, let's put it this way, if I'm so busy doing all the other stuff and we have a continual, we have a security incidence, then I'm too busy doing the other stuff to deal with that.
Or now I have to reprioritize.
We have a competition within the organization as to whose priorities matter most.
Was man wirklich will, ist die Möglichkeit, dass unser Workflow stabilisiert und stabilisiert wird in der normalen Mode gewartet.
Das gibt uns die slack.
Es gibt uns die Möglichkeit, zu beherrschung zu beherrschung, aber auch die größten Sicherheit.
If we are running flat out, in other words, if I am sprinting, I cannot go any faster.
And then suddenly a security issue comes along.
I'm now really tired.
I'm also dealing with that.
But also I'm going to miss some things.
I don't have the space to think.
And that's a really important idea is that we need to keep reminding ourselves we are knowledge workers.
In software development, we are knowledge workers.
This is how we work out and arrange the tools.
This is how we ask better questions.
This is how we do these things.
Wenn wir halbwegs burnt out sind, dann sind wir nicht in die Position zu machen, selbst selbst, unsere Tool-Einheit und unsere Intelligenz und unsere Intelligenz über andere Menschen.
So, Sicherheit ist ein reminder.
Das Accelerated Landscape ist ein reminder, warum all diese Dinge ist wichtig und warum man sich die Level-Dämpfe ein bisschen anziehen.
Wir wollen AI zu tun die aktuellen Arbeit besser, so dass wir eine Peak-Response haben, wenn es notwendig ist.
Aber wenn wir immer versuchen, dass wir immer auf Peak-Response haben, dann jemand, der sich über die Burnout hat, oder jemand, der sich über die Sprint lang-distance hat, will wissen, dass du nicht das kannst.
Und deswegen hast du eine Dysfunktion in der Organisation.
Und das wird wieder zu kommen, zu biteen.
So, again, was das das uns?
Es wird uns über uns.
AI took the thing that was already there and it's allowed us to see how we as tool users, but also in our business environment, how we can accidentally end up taking some of the decisions against ourselves without meaning to.
So the speed analogy, it's really great.
I mean, you just talked about burnout.
I mean, if I'm standing on the brake and also pushing the gas pedal, the brake will also...
Und das ist immer so, dass ich immer die car analogies habe.
Ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja Untertitelung des ZDF, 2020 Ja, und das ist wirklich ein great picture.
Ja, die Karten haben, so Sie können schneller gehen, ist die einfachste Weise, aber wir können nachdenken, dass Sie haben, so Sie haben kontrollieren.
Und das ist eine wirkliche wichtige Idee, dass das Kontroll ist genau das Sie brauchen.
Und das ist die Idee, dass viele Organisationen, es fühlt sich wie sie einfach versuchen, sie versuchen, sie einfach zu gehen schneller.
Es ist als wenn sie versuchen, 100 Jahre zu gehen.
Und die ganze Meinung ist, 100 Meter race is a race in a straight line.
And the goal of that race, I mean, I'm not saying it's trivial.
I can't run 100 meters very fast at all.
But the goal of that race, and if you look at any 100 meter race, is go fast.
But if you look at a long distance race, software development is long distance.
And it's a shame we use the sprint analogy.
I know historically why we use the sprint terminology.
But people picked up on the sprint terminology and heard something different.
The idea with a sprint is that you have a period of sustained, consistent, high unsustainable, you know, for a short period of time, you sustain something that is unsustainable.
Okay, you can, you know, you can run 100 meters, you're not going to run 1500 meters.
Although honestly, if I ran 1500 meters at the speed, if I could run 100 meters at the speed that Olympic runners run 1500 meters, I think I'd be very happy.
The point there is you cannot sustain.
The whole point of the sprint metaphor is that when you're done with your sprint, you take a break because it's not sustainable.
And that seems to be the way that a lot of companies and their cultures and management and product owners and whoever, I don't want to point the finger at any one individual, but culturally this seems to be a problem, is that they are trying to run marathons using sprint.
Sie versuchen, das nicht wie du runnst, das ist nicht wie du runnst, das ist nicht wie du runnst, das ist nicht wie du es effectively.
Ich habe ein bisschen distance-running und eine Sache ist, wenn du jemanden in einer 10,000m-race verhinscht, dass du, insbesondere an der Olympic-Level, die 10,000m-runners gewinnen, der Person die gewinnen die Race ist oft nicht die Person, die Anfang an der Anfang an der ersten.
Ich habe meine Kinder, wir haben die 2012 Olimpics in London und meine Kinder gesagt haben, oh nein, Mo Farah, er wird nicht gewinnen.
Er ist in der Backen.
Und ich habe gesagt, just wait, just wait.
Er ist in der Backen für den Moment.
Aber in den letzten 1,000, 2,000 m, du siehst, er bewegt.
Er hat er understood die pacing.
Und das ist die ganze Sache, wir brauchen in Software.
Also in software, just to make it hard, it's dark and there isn't a track.
Apart from that, the race analogy is perfect.
The point there is that we need to understand product development is something that happens with lots of surprises.
You need genuine agility to be able to respond to a situation, which means you cannot always be working flat out.
Optimizing your current approach to be hyper-efficient is not helpful because that's not the product landscape.
Products change in a way that requires maneuverability.
You need a steering wheel.
You need to understand.
Sometimes you need to slow down and say, wait a minute, let's not do this.
There is a skill in not doing something and then changing something.
And sometimes, and this is the problem, is one of the things I think we are finding is that people are finding that they have People who have historically perceived software development as a typing activity now think that we've solved the typing problem.
And it's just like, no, it was never a typing problem, because otherwise we'd have solved that problem years ago.
We'd just send everybody in touch typing courses.
It's just like, that was never the problem.
And that whole issue is that they are optimizing the wrong bit.
And so now we see this in organizations that they, They now create bottlenecks in different places in the organisation.
In other words, if I am producing lots of code, how do I know it's any good?
And that's a very broad question.
But then who are the other people that need to depend on this?
And what's the relationship with the customers, the product owners, the QA department, all of this kind of stuff?
And we now slam into other things and we may be producing...
The code that's produced now is not the same kind of slot that's been produced two years ago.
But it can still end up being slop in the sense of nobody's reviewed it, nobody's really tested it, nobody's really explored it, and now we're going to pass that on to the next person to deal with.
And that's unfortunately a pipeline model that some organizations seem to be walking into without realizing it.
So that's, yeah, you just answered another question of me.
Because I think, yeah, in the beginning we all said, oh, that's AI slop.
Now I think it changed that the quality of the reviews AI can do is, yeah, I would say better than the quality of the reviews I do manually.
So I won't judge anybody else, but the code is also better than what I produced the last 30 years and so on and so on.
Isn't it also about expectation management, which is going fast?
So you just told about racetrack and you told your kids, hey, wait a moment, it will be faster.
And while watching television, I think it was not such a big timeframe.
So the kids said, yes, let's wait and see whether that is right.
Aber mit Software Development, alle sagen, wir haben so viel Geld investiert und wir können nicht warten.
Es muss sich auszupassen.
Ja.
Und ich denke, das ist ein enormes Problem.
Und von Anfang an, wenn du den ersten Proof-of-Concept in nur ein paar Stunden und der Kunde sagst, okay, es funktioniert Software.
Why do you need some more weeks?
And then you tell reasons that you have to implement some more things, some more layers.
Security.
Security logging so that it also can be operated and maintained.
And then you hit a roadblock.
You can't keep up the speed because you had a roadblock where dass AI nicht mehr succeed ist, dass man nicht mehr nutzen kann, dass man nicht mehr multiplierer AI mehr benutzt, man sich auf normalen Speed zu verändern.
Und ich wirklich sehe, dass das passiert.
Oder normalen Speed oder slower.
Und ich denke, das ist die Sache.
Und wie du gesagt, es ist ein bader Expectation Management.
Und das Problem ist, dass...
Das geht zurück zu dieser Frage, der die verschiedenen Expectations people haben von AI.
So eine der Dinge, die ich finde, insbesondere wenn ich Das ist nicht was ich, dass ich ein guter Beziehungsweise für mich, um, das ist, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was ich, was, was ich, was Sie sind jetzt die erste Lösung, das ist er.
Sie sind jetzt die erste Lösung, das ist er.
Und Sie sagen, das war wirklich sehr convenient, dass das so schnell gemacht wird.
So, kurz, wir schauen, dass wir noch eine andere Option haben.
Und wir schauen, was wir machen?
Was wir machen?
Was wir machen?
Was wir machen?
Was wir machen?
Was wir machen?
Was wir machen?
Was wir machen?
Und wir schauen, insofern.
The relationship there is that that enhances us.
In other words, what we're doing is we are saying, what are the options?
There's this quote that I use from Émile Auguste Chartier that in English translates to, there's nothing more dangerous than an idea when you have only one idea.
And we often get locked into something, and I think it's a good quote for life, by the way.
I think it's great.
But we often anchor on one idea, one way of doing something, or the first design that comes to mind.
So here we have this impressive tool that allows us to explore multiple ideas with ease.
And do people use it like that?
Not that many do.
I mean, I'm sure a number of people watching now are doing it.
But the thing is, as a percentage of the industry, no, most people are just doubling down on doing one thing, trying to do it faster, rather than saying, oh, this is interesting.
Our job is to think, it is to come up with a reasoned approach and go, no, this is the better approach.
And you spend less time than historically you would have done, but you've now explored more options.
The idea of being able to explore more options is incredibly powerful.
It's one of the, you know, I have a kind of a mental hit list of things that AI allows us to do that we should probably spend more time focusing on, generating options and exploring them at a cost that is far reduced from how we used to use this.
Das ist fantastisch.
Wir sollten das.
Wir sollten das.
Wir sollten das.
Wir sollten das.
Wir sollten das.
Wir sollten das.
So dass alles, was wir tun, oder mehr, was wir tun, kann man bevaltet.
In other words, es verändert die Balance des Work.
Aber was ich sehe, ist das nicht was viele Leute.
Ich denke, dass viele Leute wissen, was sie in diesem Sinne, von der Big Picture point.
Und wie gesagt, die expectation oft kommt an zu...
Wir sind ein sehr viel Geld in die Welt.
Ich denke, dass alle Leute sehr überrascht sind, wie viele Token man kann in einem kurzen Zeit verwendet werden.
Und wir haben alle das Geld, es besser funktioniert.
Aber ich denke, dass in viele Fälle, und das ist nicht neu mit AI, aber auch AI wirklich in der Tat, ist, dass Leute nicht wissen, was sie wollten.
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
Warum?
No, that's not a reason.
People who've got kids will know that eventually their kid will come back from school one day and say, I want this.
And you go, why?
And they say, well, everybody else has got one.
Yeah, you know, it's just like, wait a minute, that's not really a reason to have it.
And that's the problem.
So that's not a good expectation.
You can't measure that.
So the real question is, with any tooling, is what problem are you trying to, what are the problems you have?
Und das ist die erste Frage.
Forget AI.
Was ist es, was sind die Breaks in Ihre Organisation?
Was sind die Dinge, die Sie sich auf die Schleuner anziehen?
Und was sind die Dinge, die wir nicht können, und was sind die Dinge, die wir nicht können?
Und was sind die Dinge, die wir nicht können?
Und was sind die Dinge, die wir nicht können?
Und einfach nur auf eine Whiteboard und das collectively ist ein sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, You know, our biggest problem is this.
Is AI going to help with it?
It might do.
Or yes, this is perfect.
It's a good match.
I don't know what the answer is in your organization, but if you don't ask the question, there's no way that answer is going to magically match up.
And I think that's the problem is people are going over this big fluffy idea of AI.
You need to be, need to remember it's a tool.
It's a very powerful tool.
It's a tool with a great deal of breadth, but it also has a great deal of latitude, a huge amount of possibility for nicht eigentlich als effektiv als du denkst.
Und das ist, glaube ich, das Problem, wir in Gesprächen.
Du hast gesagt, dass die Tade von 80% Statement Coverage durch Testung getters und setters sind.
Und das ist die Gespräche, viele Leute haben.
Sie haben ein, wir brauchen besser Testung.
Und eine Person kann ein bisschen TDD-Style, descriptive ...
BDD-style test, and another person could just be testing getters and setters, and they don't know they're having a different conversation.
They're using the same words and the same metrics, but they don't know they're talking about different things.
But the competence level between them is hugely different.
And I see that with people talking about AI, is that you've got somebody who's truly mastered and understands the relationship between the organization, the developers, and their tooling, and how AI can shape that.
And then you've got somebody else who is...
Ich liebe die Idee von den Optionen.
those options until we have to make a decision.
And someone once said that a decision without options is a constraint.
You don't make a decision, you just take this constraint.
And I think that's quite interesting.
In the chat we have one comment I would like to reference it.
How about following standards like Ich denke, es ist Software Engineering, von Knowledge und anderen Büchern.
Und ich denke, wir begann mit den Tests und ich denke, es bereits answerset.
Die Knowledge, die wir bereits haben, die wir in den letzten Jahren, still hält es mit AI, nicht?
Ich denke, und das für mich, da ist ein interessanter Punkt, dass ich ein paar Jahre, ich joked über es auf Social Media, das Jahr, ich sagte, ich bin ein paar Leute rediscoveren oder reinventen Ideen, die Leute sagen sind sehr wichtig für ein lange Zeit.
Ich denke, es war in der Antwort zu jemanden, Hey, here's a really good idea when you're using LLMs in your development flow and all these things are happening.
How do you know what's happening when it's addressing the question of cognitive debt?
Basically, what they've done is reinvent the ADR.
It's just like, thank you for joining the party 15 years late.
In other words, I'm seeing a lot of people reinventing stuff and people discovering that things like coupling and cohesion, Sie haben die Worte, es ist, dass...
Let's gehen zurück zu der 10,000-Line-Method, die ich gesagt habe.
Es gibt zwei Dinge, die 10,000-Line-Method sind.
Erstens, Menschen finden es wirklich schwierig, um 10,000-Lines-Method zu verstehen, in einem einzigen Method zu verstehen.
Sie wissen, was LLMs?
Sie sind nicht so gut, über lange distances.
LLMs lief Dinge, die sind kleine, loosely coupled, well-named, clearly structured.
haben wir eine Kontrolle und Datenfläche.
Wenn wir zu diesen Verlangen sind, dann wir besser werden.
Das ist nicht ein Verlangen.
So, also, haben wir in unsere Architektur, die Punkte von Interchange, Decoupling, gut Interfaces, klar Bezeichnisse, was passiert auf dem Weg, so wir nicht mehr über die Implementation haben, ist das was viele Leute sagen für eine sehr lange Zeit.
So, in other words...
Es schreitzt diese Ideen.
Und wie Sie sagen, das ist auch, dass es eine gute Option an diesem Punkt ist, weil die Veränderungen in zwei Jahren verändern können.
In zwei Jahren, ich kann das Ergebnis aus dem Thema, weil die Landschaft der Technologie oder der Markt verändert hat.
Und ich möchte, was die Option sind, und ich möchte, was die Option sind.
Und ich möchte, was die Option sind.
All diese sind genau wie sie vorher waren.
Und in einem senschenkel, wir sind in einem besseren Position, um sie zu nehmen.
Aber ich denke, dass die Problem ist, dass viele Leute nicht mehr davon sind, weil sie denken, hey, Code Generation ist all ich zu worry.
Es ist nicht ein Feuerhose von Code.
Ich möchte ein System, das die richtig ist, in einer Weise, dass nicht die Sicherheit, die Probleme, die höchste, die Probleme, die Kosten, all diese Probleme, in der Zukunft.
In anderen Worten, ich bin constantly exploring, dass Landscape.
Wenn wir es aus diesem Punkt, wir haben einen sehr unterschiedlichen Rolle, oder wir sehen uns aus AI durch sehr unterschiedliche Lens.
Wenn wir es als, kann ich mehr Lens-Code produzieren?
Dann natürlich Sie können.
Aber das war nicht der Problem.
Es ist, kann wir verstehen die Landschaft und die Trade-Offs und balance es, und so mit effectiveness und awareness und erreichen weiter als wir before?
Und das, ich denke, ist das die Möglichkeit.
Aber ich denke, es ist eine Inevitabilität.
Ich denke, das ist das Problem, dass wir uns alle besten Demos haben und die Unternehmen, die wirklich das gut sind, und die Entwicklungen, die die EFFECTIVE-Use sind, und wir sagen, ja, ich will so sein, und wir sind in einem Moment, das wir uns in die Kommentare.
In fact, ich kann das in die Kommentare sehen, dass es in die Kommentare, die wir uns in die Opposition in die Opposition.
Es discourages uns, es nudges uns aus.
Das ist das Idee, das wo du begann mit dem, zu sagen, du hast es um das zu schaffen, besser documentation zu machen.
Es ist das Wichtigste für die Qualität und Qualität.
Und ich denke, das ist unser Opportunity, dass wenn wir es nicht jetzt nehmen, dann, ich werde nicht sagen, wir werden es nicht mehr tun, aber haben wir gesehen, dass das 10,000-Line-Method.
Das 10,000-Line-Method, ich sage Ihnen, das ist in Java.
Und diese Methoden existieren.
Hier ist die Frage.
Java hat sich die Faktoren für Jahre altes Jahr.
Das ist die Faktoren in der Faktoren grew.
Es ist die Faktoren in der Faktoren wurde normal.
Und so für über zwei Jahre, wir haben alle die Faktoren, die wir brauchen, die die meisten Dinge, die Leute überlegen, in Legacy Code zu verändern.
Wir haben es ja, es ist ein Signal.
Ja, es ist ein Signal.
Aber es ist ein Fall, hier ist ein Einwohner in der Refactoring ist ein normales Ding.
Und die Tool Support hat sich über...
hat sich über...
hat sich über...
hat sich über...
hat sich über...
hat sich über...
hat sich über...
hat sich über...
das ist wirklich gut, working in Languages durch Refactoring Tools.
Du hast immer noch Legacy Code.
Und Leute sagen, das ist nicht ein Tool Problem.
Das ist ein Problem.
Regarding the refactoring tools, and I think we could go on with this talk on and on.
So it's quite really interesting, but we have to come to an end.
So with those refactoring tools, we use the refactoring tools.
They helped us to extract methods and getting classes under control and so on and so on.
And it seems to me that we now...
Forget about those deterministic tools.
When we work with AI, AI doesn't have those tools.
AI knows how to refactor, but in a slightly non-deterministic way, without those tools.
And this brings me to the closing question.
The next generation will grow up with AI, with code generators.
They will not learn the...
wie wir durch die Manulierung typen code machen, die unsere Fehler, schreiben die Big Ball of Mud System.
Sie haben keine Erfahrung.
Ich denke, das ist die hardest Frage.
Was ist Ihre Anwesendung für die nächsten Generation, die mit dem A.I.?
Was ist die Skill sie brauchen?
Okay, so we could probably spend an hour on that question.
We obviously are not.
But my advice is to make sure that they understand that they need to be involved in the coding.
They don't have to be involved in the coding the way that people were in the past, but it will be healthy.
If they don't feel comfortable writing a simple function, then that tells you something.
It's a case of like, oh, You should do, because you still have to know how to read this stuff.
Because the code is a precise and deterministic specification of what you want.
The code is not an implementation, it's a specification.
That's what all programming languages are.
They are specification languages.
And that's a really important understanding.
So the idea is that you still need to be able to read this.
Why?
Because you need to understand what you have.
You need to understand um, how to change it.
You need to understand what to do when things are wrong.
Now, that doesn't mean you can't use an LLM in that process, but the idea is you still need to have that kind of level of being able to do it.
Now, perhaps you, but let's, let's relate this to something else.
Um, Latin.
There's not a lot of, you know, um, if I, if you, if you, if you learn a language, um, so yeah, my German's not great.
I always talk about my German has been a Speiserkarten Deutsch, you know, so I can, I can, you know, I've got a certain level.
Aber ich kann aus dem Essen, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich habe die basicen Bits und Pieces, aber ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, ich kann aus dem Toilet, wenn ich lasse Dinge, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich lasse, wenn ich las Learning Latin is actually really different.
It's not like learning a modern language because you don't need to introduce yourself.
You don't need to ask where the toilet is.
You don't need to order a meal.
You are typically reading things that already exist, written texts.
And the point there is that even when you learn Latin, you learn the intricacies of the language.
Okay, the same goes for ancient Greek.
And you're reading classical texts.
And I guess also...
Das ist nicht so, was es ist, was ich sagen, dass es nicht so, was es ist.
Wenn man nicht auf die Lage ist, dass man nicht die Verlusten und die Code verwendet, nicht genug von der Sprache zu machen, das ist ein Problem.
Du hast einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, einen Laufenden, Ich habe ein paar Gespräche auf den meisten von der Tool-Link und von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Art von der Es gibt mehr.
Das ist wahr.
Ich bin nicht ein Latin-Latin-Ger.
Sie haben mich studiert in der Schule.
Aber es gibt Möglichkeiten.
Spoken Latin ist ein Ding, nicht nur Church-Latin, nicht nur die Vatikan.
Ich habe mich überrascht, dass das nicht mehr Lattenskinder ist.
Du hast ein wenig, aber es war ein bisschen.
Kevlin, wir sind bereits über Zeit.
Es war so...
Great talk with you.
I learned so many things.
I bended my mind a little bit.
And wow, I'm really looking forward to meeting you in Berlin at the Software Architecture Gathering.
This will also be quite interesting.
You have a workshop, you have a talk.
So, wow.
Thank you for being here.
Thank you for inviting me.
And I hope we can have a coffee in Berlin.
Yeah.
Bye.
Hi, I am Alargo Schumbach.
Do you organize any user groups, conferences or other tech events?
Then feel free to add them to Treff.dech, an uncommercial platform for tech events in the German-speaking community.
It's free without any advertising or tracking.
Just visit treff.dech.dech.
oder scannt die QR-Code.
Du kannst das Link auch in der Video-Description finden.
Und btw, du kannst auch alle Software Architecture Stream Events finden auf Treffpunktes.
Und wenn du Fragen hast, dann bitte bitte zu mir.