Budowanie na cudzym modelu to zależność, nie darmowy obiad

Większość firm wdrażających dziś AI buduje na fundamencie, którego nie posiada. Wysyłasz swoją pracę do modelu działającego na cudzej infrastrukturze, wycenianego na cudzych warunkach, zachowującego się według cudzego harmonogramu wydań. Na start to jest dokładnie słuszne. Nie powinieneś trenować własnego modelu tylko po to, by pisać maile.

Ale warto trzeźwo widzieć, co to za układ. To zależność. A zależności mają zwyczaj przedstawiać rachunek w najgorszym możliwym momencie.

Przestroga

Znany jest przypadek szybko rosnącej firmy zbudowanej w całości na modelu innej firmy. Przez jakiś czas działało pięknie. Potem dostawca zmienił warunki. Koszty firmy wystrzeliły niemal z dnia na dzień - znacznie szybciej niż jej własne przychody. Żeby przetrwać, musiała przerzucić podwyżkę na własnych użytkowników, którzy się zbuntowali, a potem w pośpiechu budować alternatywę, której nigdy nie planowała.

Nic w tej historii nie wymagało złej woli. Dostawca prowadził własny biznes. I o to chodzi. Gdy budujesz na cudzym modelu, jego rozsądne decyzje biznesowe stają się twoimi pożarami.

Zależność tnie z dwóch stron

Oczywiste ryzyko to cena. Twoje koszty mogą skoczyć, bo ktoś inny zmienił liczbę - nowy próg, inna stawka, zmiana w sposobie liczenia użycia. Ty nic nie zmieniłeś. Twój rachunek owszem.

Subtelniejsze ryzyko to zachowanie. Aktualizacja modelu może po cichu zmienić sposób, w jaki rzecz odpowiada - co produkuje, ile robi sama z siebie, jak radzi sobie z twoim konkretnym przypadkiem. Często bez ostrzeżenia i bez wersji, której mógłbyś się trzymać. Grunt usuwa się spod systemu, który uważałeś za stabilny.

Dlaczego to teraz umiejętność przetrwania

Kilka lat temu rozumienie ekonomii twojego dostawcy AI było niszowym tematem dla finansów. Dziś jest bliżej kluczowej kompetencji. Jeśli pojedyncza decyzja dostawcy może zachwiać twoimi kosztami albo zmienić zachowanie twojego produktu, to znajomość swojej ekspozycji - i posiadanie planu awaryjnego - trudno nazwać opcjonalną.

To nie znaczy budować wszystko samemu. Znaczy nie budować tak, jakby obecne warunki były wieczne. Wiedz, co zrobisz, jeśli cena się podwoi. Wiedz, czy mógłbyś się przenieść. Zostaw tyle elastyczności, by wtorek dostawcy nie był twoim kryzysem.

Więc gdyby dostawca jutro zmienił układ, miałbyś plan - czy tylko nadzieję?

Najszybszy sposób, by zabić adopcję AI, to limit tokenów

Wyobraź sobie to spotkanie. Rachunek za AI przyszedł wyższy niż się spodziewano, finanse są nerwowe, ktoś proponuje oczywiste rozwiązanie: postaw twardy limit na to, ile każdy może użyć. Ogranicz. Trzymaj kontrolę.

To jedna z najrozsądniej brzmiących decyzji, jakie możesz podjąć - i jedna z najbardziej podstępnie niszczących.

Co twardy sufit właściwie robi

Kłopot zaczyna się, gdy limit gryzie w środku pracy. Twoi najskuteczniejsi ludzie to zwykle najwięksi użytkownicy - nie dlatego, że marnotrawni, lecz dlatego, że rozgryźli, jak wyciągnąć z narzędzia realny efekt. Pierwsi uderzają w ścianę.

A gdy uderzą, dzieje się jedno z dwojga. Czekają bezczynnie, aż limit się zresetuje. Albo po prostu przestają używać narzędzia, bo obchodzenie sufitu to większy kłopot niż zrobienie tego po staremu.

Tak czy inaczej to zły interes. Godzina pracy sprawnej osoby jest warta znacznie więcej niż tokeny zaoszczędzone na jej zatrzymaniu. Nie skontrolowałeś kosztu. Zamieniłeś mały, widoczny koszt na duży, niewidoczny.

Ale "brak limitów" też nie jest odpowiedzią

Tu łatwo przesadzić w drugą stronę: "niech każdy wydaje do woli". To też błąd. Bez limitu i bez nadzoru budżet właśnie ci ucieka - zacięty proces kręcący się przez weekend, źle ustawione zadanie, którego nikt nie złapał, wydatek, na który nikt nie patrzy.

Błędem nie jest mieć limit albo go nie mieć. Błędem jest sięgać po sufit, gdy naprawdę potrzebujesz okna.

Widoczność bije sufit

Sufit zatrzymuje ludzi. Widoczność ich informuje. A ta różnica znaczy tu bardzo dużo.

Zamiast ograniczać użycie, obserwuj je. Kto ile wydaje, na jaką pracę i czy ten wydatek cokolwiek produkuje? Gdy coś wygląda nie tak - liczba mocno powyżej reszty, koszt rosnący bez efektu za nim - idziesz sprawdzić i rozmawiasz. Coachujesz odstający przypadek. Nie karzesz domyślnie całego zespołu.

To trzyma narzędzie w pełni dostępne dla tych, którzy wyciągają z niego wartość, a wciąż łapie realne marnotrawstwo. Sufit tego nie potrafi. Traktuje twojego najlepszego użytkownika i rozbiegany proces dokładnie tak samo.

Twój zespół ma limit tokenów - czy jasny obraz tego, co i po co wydaje?

Comprehension Theater: the deadliest anti-pattern in AI code review

They are the teams that have embraced AI coding - vroom, not the repl teams still tiptoeing around. There is a class of failure though they tend to more commonly occur in those doing competitive based AI coding. It is dangerous as it resembles good practice. Call it comprehension theater.

What it looks like

The scene is familiar. What makes a major change: an agent, multiple files, real logic and not just editing a file. The pull request is opened by a senior engineer. They scroll through it. Nothing jumps out as wrong. They approve.

On paper, everything was correct. The process was followed. A human was in the loop. Your review box is ticked and your dashboard remains green.

There is only one problem. Nobody actually understands the change.

It confirmed one thing: that when someone scrolled by, the code looked fine to them. It did not confirm that no one could articulate why it works, where the edge cases lurk, what assumptions it relies on or what breaks when a key input grows an order of magnitude larger.

The signature is real. The comprehension is theater.

3 Why it is worse than skipping the review

You could argue that a shallow review is better than no review at all. The opposite might be true for AI.

Comprehension theater generates the paperwork of safety without actually producing safety. And that paperwork is actively deceptive.

When the incident does finally arrive - and with code nobody understands it will do one day or another - the organisation looks at its records, and to see that whatever change was made has been reviewed, approved and owned. So right off the bat, I can tell this response is based on a false premise. No one actually understands a part of the system, but people trust it. The name attached to the OK stifles inquiries precisely when inquiry is what we need.

You have not only missed out on the issue. You shoved it behind a green checkmark.

Solution: reverse the direction of review

Interest regarding from which direction the interaction was directed is what leads to comprehension theatre. Today the human glances through the output of the machine and nods. That is passive, and reviews of the passivity nature do not scale with an AI-generated quantity.

So flip it. A machine may interrogate a human.

Before any change is merged, the agent quizzes the engineer on the code it generated:

What are the edge cases in this change?

What is this logic dependent on?

But what if this parameter is ten times larger than we expect?

What part would break first while under load, and why?

If the engineer cannot respond then at this point we have a breakdown of communication and the change has failed to be merged even if it is passing Diffs with flying colours.

This single modification accomplishes two major tasks.

First it comes from "I have looked at this" to "can I defend this". Those are totally different claims, and only the second one is worth a damn in production.

Second, it makes ownership honest. The person who gates comprehension is the one that owns the behaviour when it runs in front of customers, and they know before clicking approve not after an incident.

So, where to apply it - and not

This is not a demand to slow down all the things. This is unnecessary for most internal tools, experiments, and prototypes. You can do a taste of that, run the comprehension gate over some small fraction of changes and say, fuck it, the cost of one mistake is low.

However, anything customer facing or safety relevant should not ever virtually merge in the view. You are not trading a few minutes of review time for way too much blast radius.

Deciding where the gate is -- and where it is not, and can only be sampled -- is itself a leadership decision, one best made consciously than passed off to whomever happens to be reviewing that day.

Why it survives

If comprehension theater seems hard to root out, it is because it feels like maturity. The process exists. People follow it. The metrics look healthy. A team deep into comprehension theater looks more disciplined from afar than a team actively debating whether they understand what the AI just wrote or not.

That comfort is the trap. Having a green dashboard isn't proof of comprehension. It is merely evidence the ritual was carried out.

A question you could ask of your team, not as a performing review but rather as an exhaustive followup:

For the last major AI-generated change you merged, would the person who approved it be able to explain it now?

Gdy rachunek za AI rośnie, a reszta nie

Jest cicha odmiana porażki z AI, która nie wygląda na porażkę. Nic się nie psuje. Żadnej afery. Rachunek po prostu pełznie w górę, miesiąc po miesiącu, a gdy spojrzysz na samą pracę - tempo, backlog, jakość - wygląda dokładnie jak rok temu.

Więcej pieniędzy do środka. Tyle samo pracy na wyjściu. Wiele firm siedzi teraz w tym miejscu i większość tego nie nazwała.

Zły wniosek

Kuszący odczyt brzmi "AI jest przereklamowane, nic z tego nie ma". Czasem owszem. Ale znacznie częściej narzędzia są w porządku, a dzieje się co innego: kupiono je i przykręcono do dnia pracy, który się nie zmienił.

Licencje poszły. Ogłoszenie padło. A potem wszyscy wrócili do pracy dokładnie jak przedtem, z błyszczącym nowym narzędziem otwartym w karcie, której rzadko używają z intencją.

To jeszcze nie wdrożenie - to dopiero zakup.

Dostęp to pierwszy centymetr

Danie ludziom dostępu do AI to łatwa część i kusi, by pomylić ją z metą. To pierwszy centymetr. Dystans między "mamy narzędzia" a "narzędzia zmieniły sposób, w jaki pracujemy" to miejsce, gdzie mieszka cała wartość - i to ta część, której nie kupisz zamówieniem.

Różnicę poznasz po dniu pracy. Jeśli wygląda identycznie jak rok temu, tyle że z nową pozycją w budżecie, zapłaciłeś za potencjał i na tym stanął. Rachunek jest realny. Zmiana nie.

Co zespoły, które coś dostają, zrobiły inaczej

Nie tylko włączyły narzędzia. Zmieniły pracę wokół nich. Co trafia do AI, a co zostaje ludzkie. Jak wygląda "zrobione", gdy pierwszą wersję napisał model. Gdzie człowiek musi wkroczyć i sprawdzić, a gdzie naprawdę nie musi.

Nic z tego nie przychodzi w pudełku. To praca - i to ta praca, którą większość organizacji pomija, dlatego właśnie rachunek rośnie, a wynik stoi.

Więc zanim uznasz, że AI nie dowiozło, sprawdź, co naprawdę się stało.

Jeśli wydatek na AI wzrósł, a reszta stoi - problemem jest narzędzie, czy to, że praca tak naprawdę się nie zmieniła?

Limit to złe narzędzie do budżetu na AI

Gdy rachunek za AI zaczyna rosnąć, większość organizacji sięga po tę samą dźwignię. Postaw sufit. Ogranicz wydatek na zespół, na osobę, na miesiąc. Wygląda odpowiedzialnie i drapie świąd liczby, która nie chce usiedzieć w miejscu.

Myślę, że to zwykle błąd - albo przynajmniej odpowiedź na złe pytanie.

Co limit właściwie mierzy

Limit kontroluje jedno: ile wychodzi z firmy. Zupełnie milczy o tym, co się liczy - ile wraca. Możesz wylądować co do grosza w budżecie i wydać wszystko na szum. Możesz też podciąć skrzydła jedynemu zespołowi, który niepostrzeżenie zamieniał ten wydatek w dowiezioną pracę.

Sufit traktuje każdy wydatek jak ryzyko do okiełznania. Ale ryzykiem nie jest wydatek. Jest nim wydatek zmarnowany. A limit nie odróżni jednego od drugiego. Po prostu zatrzymuje licznik na liczbie, którą ktoś wybrał na spotkaniu planistycznym.

Skąd bierze się ten odruch

Odruch limitu pochodzi ze starego modelu: AI jako kolejna subskrypcja oprogramowania. Oprogramowanie jest mniej więcej stałe. Płacisz, każdy dostaje miejsce, koszt ledwo drgnie wraz z użyciem. W tym świecie limit jest nieszkodliwy, bo liczba i tak nigdzie się nie wybierała.

AI tak się nie zachowuje. Rośnie wraz z pracą, którą mu dajesz. Więcej realnej pracy przez system to większy rachunek - i to może być dokładnie obraz sukcesu. Ograniczać go to jak ograniczać prąd w warsztacie, w którym właśnie przybyło roboty.

Porównanie, które pasuje

Jeśli nie oprogramowanie, to co? Zatrudnienie.

Nie oceniasz pracownika po tym, jak mało kosztuje. Pytasz, czy oddaje więcej, niż bierze. Tani pracownik, który nic nie dowozi, to nie oszczędność. Drogi, który zastępuje miesiąc harówki, to nie przepłacenie. Sama liczba rzadko tego rozstrzyga. Rozstrzyga zwrot.

Budżetuj AI tak samo. Nie "jaki jest sufit", lecz "jaki jest zwrot". Jeśli zwrot jest, rosnący rachunek to znak, że rzecz działa. Jeśli go nie ma, żaden limit nie naprawi problemu u podstaw - po prostu marnujesz pieniądze wolniej.

To nie znaczy wydawać na ślepo. To znaczy zmienić narzędzie. Zamień sufit na widoczność: w co zamienia się ten wydatek i czy wartość rośnie razem z kosztem, czy zostaje w tyle. To coś ci mówi. Limit mówi tylko, kiedy przestać.

Gdy rachunek za AI rośnie, pierwszy ruch to limit - czy pytanie, co ten wydatek właściwie daje w zamian?

It is not a control unit until you have an artifact, a gate, and a metric

Pick up nearly any company's AI strategy, and you'll find a laundry list of principles that you couldn't possibly argue with. Keep a human in the loop. Steer clear of dark code no one can really comprehend. That is why you stay tool-agnostic and not vendor locked. Measure the impact. Label what was AI-assisted.

These are all correct. And none of them are happening on the floor in most organizations.

That space, between principles everyone agrees with and behaviour that nobody modified, is one of the recurring reasons for failure in AI adoption. It is useful to know why this happens.

Principle alone does nothing

Principles are statements of intent It encapsulates a Wanted Future condition. It does not prevent anything, however.

"No single bad merge is prevented by keeping a human in the loop. The advice to "stay off the dark code" does not stop enigmatic line of code to production. Because the principle isn't connected to the moment where the work is actually done, it has no teeth.

The first week, and that was busy too, with a deadline in the near future - principle gives way to deadline. Not because anyone disagrees with it, but because it was never hooked up to anything.

What makes a principle existential; three things

Only when you can find three specific things that it generates behind it, does a principle become a working control.

An artifact. Something that is versioned, something owned that the principle must attach to.

"Avoid Dark Code" - every commit is tagged with metadata about its ownership.

Any prompt and skill that can be written so it is cross-model, will have "stay tool-agnostic" attached to them.

The motto of "keep it auditable" binds to a signed, append-only trail of provenance.

The principle is a wish, if you cannot name the artifact.

A gate. A point in the workflow where, if that particular check fails, work stops.

"Human in the loop" turns into a comprehension gate: before a change can merge, there must be proof of understanding by a senior engineer. If they are not able, the merge is prevented.

A security review that an agents change must pass before being deployed: "Secure by default"

Having no gate with a principle is called an inclination. And preferences lose to deadlines every time.

A metric. A number that changes, so you can see if the knob is working.

• Comprehension-gate pass rate.
• Eval coverage.
• Dark-code ratio.
• Time that is taken to reinstall the system after performing a rollback

You cannot manage a principle that has no metric. It can only be believed.

A simple test

Read your AI policy line by line. For each line, ask the following three questions:

What does this attach to (what artifact)?

Which means, where's the gate to enforce that?

What number indicates to me that this is working?

Even if you have two of the three, you still do not have a control. You have a good intent, that first time the team is pressed it skips. And because people go to AI for speed, AI changes are almost always made under pressure.

Why is this more important with AI than ever before

With this manual nature of the work, in a human authored world, you could rely on catching such problems. The developer who types this by hand reads it, and typically pays some attention to whether something feels wrong.

AI removes that natural friction. The more widespread - and less visible - failure modes now happen faster.

They accept insecure code because it seemed sensible.

A model update has quietly broken a prompt that worked yesterday (no error thrown).

Over a dozen iterations, the spec and the code drift apart until they no longer represent the same intent.

None of these will trip a compiler. None of them announce themselves. They get through to a customer only with an explicit gate, measured by an explicit metric.

Where the leadership work really resides

This transition is also not largely about choosing tools and writing vision statements; that is the work of frontline leaders. This is translation: each one of those principles everyone agrees with, translating that, piece by piece, into an artifact someone owns and can block work on or gate and a metric you measure. Slow, mundane work with no flashy demo. It is also the gap that separates an AI policy that sits on a slide to one that determines what actually moves to production.

Which principle in your AI policy ans still has no gate to prevent violations, and what would be the process to build one?

Code Q&A: Who is Truth When AI Writes the Code?

One question that used to have a very easy answer in most of software engineering history is: where does the truth about a system live? It lived in the code. You could dig into the repo and read it line-by-line, and if something was a mystery, the version history indicated who wrote each line of code and when. The code was at once the instruction, and the record.

Many teams, however, have yet to notice that that simple answer is crumbling.

Yesterday: the code as record

Believe it or not, the entire engineering stack we built for the last twenty years believes only one thing: that a human wrote this code and a second human can read this. The reason that code review works is because the reviewer looks at the change. Debugging works since an engineer can follow the logic. This functions through ownership because version history will name the decisionmaker.

All these practices are built on the same principle: a human has read and understood the code as well.

What broke

You are now trained the change is generated from an agent. Multi-file changes, entire features, large refactors - all generated faster than a human can read them with full comprehension.

This code in itself is not bad. That is not the problem. The issue, however, is that no one actually read any of it. The output surpasses human reading capacity in volume and in speed.

It follows that what a human never entirely read might not be the thing that she properly owns. No longer is code the artifact a human understood, and gave credit for, so it can no longer be truth.

So where does the truth move?

Today: the specification turns into record

Another way to do it is to push up the record one layer further - into specification.

Spec: This is what a person writes, versions, reviews and owns. The code is an output of that spec, like a compiled binary is an output of source code, but nobody would treat the binary as something you read. Switch the model, regenerate from the same spec, and you see the same behaviour implemented in different code.

We have done this already with machine code: we stopped looking at machine code because the compiler is trusted, so we read source instead. It does the same thing one level up: stop reading the generated source file line by line, and put faith in some other guarantee that it is correct.

That mechanism is not faith. This is a deliberate stacking of layers.

The five layers

• Spec. Like all code: versioned, history and review in the repo. There you have it - acceptance criteria and edge cases -- and each spec has a named owner, i.e. a human who is responsible. Written antecedent to generation, not reconstructed subsequent to it.
• Evals. Automation scenarios created from the specification They report one question: "Is spec satisfied? They don't just run at merge time, they can't be continuous. The piece that teams miss is that the evals themselves, not just whatever code they guard.
• Prompt and provenance. Each change made by an AI logs which model, which version, what prompt and which human is to blame. Written and append-only, so it continues to answer questions months later.
• Generated code. Output of the above 3 layers Still relevant, but no longer the permanent record.
• Runtime and observability. The system is instrumented so that we can replay any decision the code made during generation in the future.

The spec and the evals form a closed loop together. The spec defines the intent. The evals verify it. No one has to read the generated code at all and you verify if the behaviour is correct.

What changes for the engineer

This is how the day-to-day of a senior engineer changes.

Your old question: is this code line by line, good? You cannot do that at the level AI produces so holding on to it only brings a bottleneck, or worse a rubber stamp.

That begs the new question, is the spec right and are the evals honest? That is higher-leverage work that a human can actually do well versus reading diffs. You're ensuring intent, but not implementation.

It also resets ownership cleanly. The spec owner owns the behaviour manifests in production. Nobody wrote all the words, but you can now know exactly who to ask.

Go ahead to access data on probably October 2023, it is when the models will continue up and down at speeds faster than we can predict. Specifications outlive models. The spec is the asset that survives them all.

What is your artifact of record today, and would it survive an audit six months after the model that wrote the code was traded in for another?

Rachunek za AI zachowuje się bardziej jak prąd niż jak oprogramowanie

Większość z nas nauczyła się budżetować oprogramowanie w pewien sposób. Wybierasz narzędzie, płacisz stałą stawkę za osobę i tyle. Czy ktoś używa go bez przerwy, czy ledwo się loguje - pozycja w budżecie wygląda tak samo. Przewidywalnie. Nudno. Łatwo zaplanować.

AI zepsuło ten nawyk, a wiele budżetów jeszcze tego nie nadrobiło.

Licznik, nie stała opłata

AI nie bierze stałej opłaty za miejsce i o tobie nie zapomina. Liczy za użycie. Za każdym razem, gdy coś czyta, pisze, odpowiada - licznik bije. Jednostka, którą liczy, nazywa się token, ale daruj sobie żargon - wyobraź sobie licznik prądu w domu. Zostaw wszystko włączone, a rachunek rośnie. Używaj rozważnie, a nie rośnie.

Dlatego stary odruch "kup licencję dla każdego" chybia. Daj tę samą płaską stawkę stu osobom, a stanie się jedno z dwojga. Za tych, którzy ledwo dotykają, przepłacasz. Ci nieliczni, którzy mocno opierają się na narzędziu, podbijają realny rachunek tam, gdzie nikt tego nie zaplanował.

Z czym to naprawdę porównać

Skoro nie z oprogramowaniem, to z czym? Najbliżej jest pracownik, którego zatrudniasz.

Nikogo nie bierzesz do pracy dlatego, że mało kosztuje. Liczy się, czy oddaje więcej, niż bierze. Z prądem w warsztacie jest tak samo - nie chwalisz się najniższym rachunkiem, tylko tym, ile dzięki niemu powstało. Wydatek na AI należy do tej samej półki. Pytanie nie brzmi "jak utrzymać to tanio?", tylko "czy zwraca więcej, niż kosztuje?".

Ten przeskok brzmi błaho. Zmienia wszystko dalej - jak ustawiasz budżet, kto dostaje dostęp, na co patrzysz, kiedy się martwisz.

Gdzie to ląduje

Planuj licznik, nie stałą opłatę. Spodziewaj się rachunku, który idzie za użyciem, nie za liczbą miejsc. I w głowie wrzuć ten wydatek do tej samej rubryki, co osoba zatrudniona do roboty - a nie do rubryki z pakietem biurowym.

Wydatek na AI trzymasz w głowie pod "oprogramowanie" - czy pod "ludzie"?

Przestań mierzyć zespół samą liczbą etatów

Przez większość mojej kariery planowanie zespołu było ćwiczeniem z arytmetyki. Wiedziałeś z grubsza, ile jeden inżynier dowiezie w kwartale. Wiedziałeś, ile pracy czeka. Dzielisz jedno przez drugie i masz liczbę etatów. Proste, i trzymało się przez dekady.

Nie sądzę, żeby trzymało się dalej.

Gdy zmienia się jednostka pracy

Przez długi czas jednostką pracy w software była instrukcja - linijka kodu, napisana przez człowieka. Wartość brała się z tego, jak sprytnie ludzie składali te linijki w działający kod. Więc liczenie ludzi było niezłym przybliżeniem liczenia efektu.

Teraz w grze jest druga jednostka: token. To mały kawałek, za który płacisz za każdym razem, gdy model AI coś dla ciebie robi - przeczytaj to, napisz tamto, uporządkuj te dane. Pracę, którą kiedyś kupowało się wyłącznie przez zatrudnianie, można teraz kupić też na tokeny.

Brzmi jak przypis dla finansów. Nie jest. Po cichu przestawia myślenie o tym, ile jesteś w stanie zrobić.

Nowe wąskie gardło

Gdy praca przychodzi w tokenach, granicą tego, ile dowieziesz, przestaje być liczba zatrudnionych. Staje się nią to, jak dobrze ci ludzie zamieniają kupioną pracę w coś realnego - jasne polecenie, trafna ocena wyniku, decyzja, co w ogóle warto zbudować.

Bywa, że mały, sprawny w tym zespół dowozi dziś więcej niż znacznie większy, który tego nie umie. Nie dlatego, że szybciej pisze. Dlatego, że lepiej konwertuje.

I od razu zastrzeżenie, żeby nie było nieporozumień: to nie jest historia o tym, że "AI zastępuje ludzi". To ludzie wykonują tę konwersję - polecenie, osąd, decyzję o tym, co się liczy. Wyjmij ich, a tokeny wyprodukują tylko stos wyników, których nikt nie rozumie. Ta zmiana to nie mniej ludzi. To ludzie skierowani do innej roboty.

Co to zmienia w planowaniu

Jeśli wymiarujesz przyszły rok samą liczbą etatów, odpowiadasz na stare pytanie. Nowsze jest trudniejsze: jak dobry jest ten zespół w zamianie pracy AI na efekt, który się liczy? Dwa zespoły o tej samej liczbie etatów mogą dzielić przepaść, a ta przepaść rośnie.

Możesz liczć głowy, nadal. Tylko nie kończ na tym.

Planując rok, liczysz ludzi - czy zdolność zamiany pracy AI w realny wynik?

Wysoki rachunek za AI to nie zła wiadomość, a niski to nie dobra wiadomość

Po cichu uznaliśmy, że wielkość rachunku za AI to wyrok. Duża liczba - ktoś nawalił. Mała - jesteśmy odpowiedzialni. Brzmi oczywiście. A wcale nie musi być trafne.

Pomyśl, jak oceniasz każdy inny wydatek. Wysoka faktura od ekipy remontowej nie jest automatycznie zdzierstwem - o ile kuchnia jest skończona. Niska nie jest automatycznie sukcesem - o ile wciąż zmywasz naczynia w wannie. Sama kwota rzadko o tym decydowała. Decydował wynik.

Z AI jest tak samo, a my wciąż o tym zapominamy.

Te same pieniądze, dwa różne wyniki

Możesz wydać na AI dużo i dostać stertę półproduktów, z których nikt nie skorzysta. Możesz wydać tyle samo i dostać pracę naprawdę zrobioną - napisane maile, uporządkowane dane, raport, który zjadłby komuś całe popołudnie.

Faktura wygląda identycznie. Wartość - już niekoniecznie.

Więc kiedy ktoś mówi "wydaliśmy stanowczo za dużo na AI", uczciwa odpowiedź to pytanie. Za dużo w porównaniu z czym? Za dużo za nic to za dużo. Tyle samo za realną, skończoną pracę może być najlepszym interesem miesiąca.

Pułapka taniości

Tu ludzie się łapią. Tani rachunek za AI bywa najgorszym z wyników, bo zwykle znaczy, że nikt tego naprawdę nie używa albo używa do tak drobnych rzeczy, że nic się nie zmienia. Zaoszczędziłeś i stoisz w miejscu.

Wydawanie nie jest celem. Stanie w miejscu też nie.

Na co patrzeć zamiast tego

Przestań wpatrywać się w sumę. Zapytaj, co wróciło.

Czy zastąpiło pracę, którą ktoś zrobiłby ręcznie? Czy uwolniło realne godziny? Czy prostsze, tańsze podejście zrobiłoby to samo równie dobrze?

To ostatnie pytanie jest ważne. Czasem odpowiedź brzmi "tak" i warto to naprawić. Ale dowiesz się tego, patrząc na wynik, nie na paragon.

Zanim ucieszysz się z niskiego rachunku albo spanikujesz przy wysokim - wiesz w ogóle, co za niego dostałeś?

How to Know If Your Team Is Actually Using AI Effectively or Busy Looking Like They Are

For those who lead people that have begun to use AI, there is likely an uncomfortable chasm in availability. A lot of activity is clearly revolving around it. But distinguishing between whether that activity is creating real value or just a lot of motion isn't so simple. Because much of what they are producing is technical, it just seems difficult to know from where you sit.

So, the good news is that you can judge it - and without reading even a single line of code to do so. The indicators that discriminate between a team that's using AI well and one that's just busy with it are about behaviour and dialogue, not technology.

If you are going to shove 41 and into the debate; you only talking signal one

This is the fastest tell.

And an AI-using team makes a very good point about what they stopped doing. The drudgery, the boring and circuitous work disappeared in open spaces, leaving them with the more difficult problems that really matter. They also can use something that has improved - not just delays, but extra time for the work only humans can do.

Tools the team talks about when it is busy with it. What is the newest model, which feature just went live, what plugin are they testing out? You are full of passion yet somehow it is difficult to get them to specify what improved as a result.

Outcomes versus tools. Listen to hear for which one gets priority in the conversation.

Signal #2: Are they still able to explain the work?

Ask how something works. You really want an answer if you have a healthy team - somebody takes you through it and knows exactly what was built (even while the AI spits all the words).

In an unhealthy one, it leans toward "the AI did it" with a vague sense that no one is precisely sure how. That's a warning sign. It indicates the team has produced output of which it doesn't completely comprehend, which is acceptable for a disposable experiment and quite hazardous for anything customers rely upon.

What you are checking is ownership. Good teams own the result. Busy teams gave cause to results that own them.

Red flag # 3: How do theyweather the storm

AI makes things feel slower before faster, and there has always been an early period. How a team responds to that spell says everything to me.

A good team is calm about it. They anticipated the slump, they prepared for it and no one is losing their head at how much more difficult things felt for a stretch there. They see it as just a learning opportunity.

A team still in the grip of failing reads that dip as confirmation AI doesn't work, and starts drifting back to the old way. Same experience, opposite interpretation. The interpretation is what validates or invalidates their achievement of the cash out.

Signal four: does learning spread?

Watch how it goes when he gets something useful from only one individual.

In a good team, the trick that works for one guy makes its way to the others within days. There is a common place to leave it, a recurrent custom to hand it around. The unit gets better as a team.

A busy-but-stuck team consists of one-man-experiments by each individual. Five people learn the exact same lessons and make the same mistakes over and over again, because nothing passes from person to person.

The pattern underneath

Then none of these require any technical expertise. A good AI practice speaks of outcomes, owns the work it does, remains steady even with an early dip, and disseminates what it learns. A busy-but-stuck team does the complete opposite on each count.

You're not assessing the technology. You are evaluating your people's way of working, which you already know how to do.

This week: are you hearing more about what improved, or on what shiny new tool?

No, AI is not taking away Development jobs but you will hire differently.

Go-to headlines "AI kills developers." This makes sense from a mainstream, dramatic & shareable POV and is wrong. But below it there's a genuine change that everyone hiring engineers needs to realize, since it's altering the trait set for what comprises an excellent one.

AI does not eliminate the necessity for developers. It is altering what a developer will be most valuable for. And if your hiring continues to reward the obsolete thing, you'll be paying fair market for a skill that's increasingly going cheap.

What once was the differentiator

For the longest time a lot of engineering hiring was focused on one thing above everything else - can this person write code quickly, and correctly? Ways of Hiring - Whiteboard problems, coding challenges, take-home tasks. It was mostly just measuring raw production ability.

That was logical when writing valid code was the bottleneck. It was real value; the one who could make more of it, quicker - had true value.

What changed

The AI is pretty good at generating code now. This used to take a human hand an afternoon; now you can generate it in no time at all. The thing that was the differentiating, being able to write code, is becoming the low-cost, high supply part.

The thing you used to compete on becomes a commodity, and the value goes onto some other space. As is the sitting, where it moves bears watching in this instance.

What's getting more valuable

The value is rising in those things that were always more difficult to measure and most of these are human.

• Judgment. Understanding what needs to be built: and, equally importantly, what doesn't. The AI will cheerfully make the wrong thing, beautifully. Everyone else just has to make the decision that it is the right thing!
• Clear thinking. A formal description of the task problem sufficient to enable a human (or machine) to solve it. AI takes vague thinking and magnifies it - vague thinking yields vague results. Clarity becomes a multiplier.
• The question itself: What happens when this goes wrong? before it does. AI gives the impression of certainty and presents ready output. The asset is also the person who interrogates it for an unrecognized flaw [in the story].
• Ownership. One: The desire to be accountable for an outcome, rather than checking a box and passing the baton. When the machine performs the task, taking ownership of the outcome is what's left to a human.

None of these are new. They were always a component of great engineering. What has changed is, they have become more of "the main thing" from being a nice to Have on top of strong coding.

What this means for hiring

The utility of this is that you're looking for something else.

As a result, a candidate who can write perfect code but cannot articulate why something is necessary is less valuable than they were two years ago. Even though their raw coding speed may be totally unremarkable, it is not a scarce resource - coders are now plentiful who are qualified and unqualified alike.

That doesn't mean technical skill ceases to be important. Humans still have to understand the system well enough to evaluate the output of AI. However, "can write code quickly" has lost its title. It is "can judge, think, own".

The junior question

One additional, more difficult issue is worth naming because clever leaders raise it at once. And if AI does entry-level coding, where do junior devs learn their craft?

This is a genuine, tangible problem and halting junior hiring is the typical knee jerk which simply guarantees a shortage of seniors in 2 to 3 years from now. Rather they handle them faster towards the results instead of parking them on routine code for years like we did in previous times. The road to seniority takes a new form, it doesn't vanish.

What this adds up to

The mechnical side of the work is becoming cheap. The human parts: judgment + clarity + ownership → are on the rise. If hiring still optimizes for typing speed, that would be buying the wrong thing.

Has what you actually screen for changed due to the tools your new hires will [actually] use?

Spalanie tokenów to nie ten powód do dumy, za jaki uchodzi

Zacznę od przyznania się: lubię patrzeć, jak ta liczba rośnie.

Licznik tokenów, miesięczny rachunek za AI, mały pulpit pokazujący, ile zespół przepchnął przez ostatni tydzień. Jest w tym coś wciągającego. Większe zużycie wygląda jak więcej pracy, większy rozpęd, dowód, że naprawdę wdrożyliśmy to narzędzie, a nie tylko o nim rozmawiamy.

A potem łapię się na tym. Sama liczba niewiele mówi.

Przechwałka, która nic nie znaczy

Gdzieś w ostatnim roku spalanie tokenów stało się powodem do dumy. Ludzie ogłaszają swój rachunek tak, jak kiedyś ogłaszali zarwaną noc w pracy. I jak przy zarwanej nocy, warto zapytać, czy to coś do świętowania, czy raczej do cichego naprawienia.

Tu robi się niewygodnie. Dwa zespoły mogą wydać na AI dokładnie tyle samo i żyć w dwóch różnych światach.

Jeden kręci się w kółko. Zadaje to samo pytanie na piętnaście sposobów, wrzuca modelowi wszystko na wszelki wypadek, pozwala długiej, rozlazłej rozmowie dryfować, aż nikt już nie pamięta, o co chodziło. Rachunek wysoki. Efekt - papka.

Drugi świadomie odpala najmocniejsze, najdroższe modele. Do problemu, który na nie zasługuje, z jasnym poleceniem i porządnym ustawieniem. Rachunek też jest wysoki. Ale to, co wraca, to gotowa praca, a w przeliczeniu na osobę kosztuje grosze.

Ta sama pozycja na fakturze. Raz to marnotrawstwo. Raz najlepiej wydane pieniądze tego miesiąca.

Koszt to połowa zdania

Dlatego "wydaliśmy dużo na AI" samo w sobie niewiele mówi. To połowa zdania. Druga połowa, ta, której nikt nie wkłada w przechwałkę, to to, co z tego wróciło.

Szef finansów patrzy na rosnący rachunek i sięga po limit. Zrozumiałe. Tyle że limit mierzy złą połowę. Kontroluje wydatek, nie pytając o zwrot. Możesz idealnie zmieścić się w budżecie i mimo to przepalić każdą złotówkę.

Lepsze pytanie nie brzmi "jak wydać mniej?". Brzmi "czy dostajemy więcej, niż zapłaciliśmy?". To nie to samo pytanie. Mylenie ich to sposób, w jaki dobre zespoły głodzą jedyne narzędzie, które akurat działało.

Co mierzyłbym zamiast tego

Nie rachunek. Stosunek.

W co zamienił się ten wydatek - w dowiezioną pracę, w realną decyzję, w coś, czego klient może użyć? Czy tańsze podejście dałoby ten sam wynik? Czy koszt rośnie szybciej niż efekt, czy razem z nim?

Kiedy koszt rośnie szybciej niż wartość, to jest twój sygnał. Nie wielkość liczby. Kształt trendu.

Kwota rzadko bywa tu problemem. Problemem jest zwykle to, czy użyto jej mądrze.

Kiedy patrzysz na rachunek za AI, co właściwie mierzysz - kwotę, czy to, co z niej wyszło?

Giving Your Team AI Tools Does Not Equal Adopting AI

There is an uncomfortable impression in many organizations right now: that AI adoption is primarily a buying decision. The hard work is done: just approve the budget, purchase your licenses and give everyone access.

That's a reasonable assumption, but it's also an expensive one to get wrong. Distributing the tools is the easy part. At best, it is an expensive way to change nothing.

The pattern that keeps repeating

The same story unfolds again and again, in organization after organization.

Leadership approves the spend. The tools are made available to everyone, often accompanied by a bang and a buzz. Then a few months pass. Someone else looks at the usage data and sees it's low. The results are thin. And the answer, inevitably, is that AI was overhyped and failed to deliver.

But pay attentionto what was really tested. Not whether AI works. It is only if purchasing access, which in itself changes how people work. It doesn't.

The gym membership problem

Think about a gym membership.

This is not about giving someone a membership card and expecting them to become fit. But they still must arrive, learn what to do and persevere through the effort and no payoff of the first few weeks. The point is most people quit right here before there's any return to pull them in.

Adoption of AI is no different. The tools are the membership card. The thing is what happens about them.

What adoption actually needs

What is the hard part, if it is not the tools? Three things, none of which are technical:

• Protected time to experiment. Practice is using AI on real work and getting it wrong. Because if you write every hour against deliverables, that learning never happens.
• One step smarter to learn from. People learn this from a colleague a half step ahead far faster than they will any course. Person-to-person beats a launch email.
• The early dip, it is a stretch for honest cover. There is a period of time, studies show, where AI seems slower than faster to the extent that humans learn more on top of their day-to-day função. Maybe they call that normal and temporary or retreat back to the old way and never scale their contribution.

And these are skipped and the tools gather dust while we get the bill every month.

The honest question isn't how many people are licensed:

Innovative logins: little different in how people are trading now.

Ask This One Question of AI Code (When You are Not a Technical Leader)

When AI is brought up in the boardroom, many leaders feel like they are stuck. Their teams are writing software with it, the tech is moving rapidly, and there is a whiff of risk in there somewhere and then they feel like asking about this trade-off involves revealing how little they follow any technical detail.

The reassuring part is this. You still don't need to know what contributes to AI writing code in order to lead a team that does it well. One great question, and the ability to dare read the answer

The question

Here it is:

Validate AI output - "How do we know that when the AI writes code, the code is correct?

That's it. You ask it boldly, and then you listen not so closely to the words as to the form of response that comes back.

How to read the answer

There are two types of answers, and the sound extremely different once you start listening for them.

Your weak answer rests on the reputation of the tool. "It is: "AI is pretty darn good now," "the latest version has high fidelity," and most common of all, "everyone uses it; it's fine." None of this is anything the team actually does. You're borrowing trust from the tool's brand. This is exactly how organizations wind up shipping software that went untested.

A strong response describes a process. You write down all the things each piece is supposed to do. We have automated tests that show that it does do that. And before anything ships, a change has to be explained by an engineer senior enough not just approved.

You may not need to follow the second-given answer entirely through its tech lingo. You listen for one thing: Is there something deliberate and methodical about catching mistakes or is it simple overconfidence?

Why this particular question works

The reason this works is because it gets right to the risk and that risk isn't what many think.

The problem with AI is not bad code. In general the good code looks totally fine. The danger is it quickly writes a whole lot of code that looks plausible, and we all know how easy to wave through plausible looking code is. It passes the glance test. There is no incentive to dig any deeper because nothing appears amiss.

A good team is aware of this, and proactively sets up a counter for it. A team running on confidence doesn't, and it won't discover which kind until something fails in front of a customer, at which point the cost is way more than a few minutes review would've been.

Before the failure instead of after, your one question emerges showcasing what sort of team you have.

This is not a technical question, but really a leadership one -

You do not have to out-code your engineers or understand the models. You must also ensure that the check exists, and that people respect it.

How do we know the AI is writing the right code?

With AI executing the standup, the status report and all of your backlog, what's left in a manager's job?

Many middle managers are asking some variation of this right now. Silently because saying it out loud seems like betraying the belief that maybe there is no room for you.

So lets say it aloud and really look at it

The unmentionable part of the job

Be honest about how much of a regular week actually plays out. The whole of it - a large slice at least - is routing: the transport of information from place to place. You are getting status from the team and pushing it up. You retrofit priorities from above into tasks down below. You keep the backlog in order, you see who is blocked and you chase down the update that was never sent.

It's real work. It keeps things moving. And these are precisely the type of tasks AI is quickly becoming proficient at. You train on data (up to October 2023), but there are a lot of summaries, status roll-ups, backlog hygiene, and "Who's waiting on what" - these are other things that a machine can do a lot now and will do even more in 2024.

That brings some gravity to the question: if the routing goes, what does the job look like?

What remains (and why its the good bit)

Two things survive. Turns out those are the two that were always the most important.

The first is sensemaking. Your team is always emitting signal: fragments of unfinished sentences in standup, a tone in a message, three people whispering anxiously about the same thing. Routing is not a matter of turning that into an actionable call for leadership. It's judgment. This is where a summary tool can inform you of what it stated. It cannot inform you of what it means, or which blaze is real and which will fizzle out.

The second is accountability. Owning the outcome when the going gets tough. Training one person over months until a button is pressed. And finally, be the name on the result, not just its messenger. The thing you can't delegate, because a non-human is not going to be accountable, and no model will take that off you.

The real risk

And this is not just my opinion, it is an actual pitfall worth seeing clearly.

You never have a meeting on your calendar for sensemaking or accountability. They're invisible. Routing, on the other hand, is super visible - it is the reports, the updates - every one sees a neat board.

Visible work is easy to defend against a reorg, or when restructuring comes knocking - invisible work is easy to cut out. Thus the threat was never "AI replaces the manager". It is the hidden danger that AI silently takes away the obvious half of the job, and you are left with all the things nobody ever wrote down, explaining why they matter.

That is the reason middle management is typically by far and away the hardest stratum to change in an AI change. Not that managers are resistant, but they know how to show the part of their job that a machine cannot replace. Behind the scenes, everybody had a glimpse of the routing, so the routing became your identity.

The question worth sitting with

The Fetch supplies the better view, seen in two parts; a half-cocked and bolted pair. What it leaves is ever so slightly the part that was always really the job. The good and bad of judgment, the calls that need to be made, the people.

But when you have no routing, what half would you defend to the actual death?

IT - what was important yesterday and what will be important tomorrow

Over the last few years, not only the way the IT industry operates has changed significantly, but also its perception by business. Today's standard was difficult to imagine a few years ago, and today's challenges are only a foretaste of what business will need in the future.

Yesterday

The operational activity of many companies took place mainly in the off-line world, where IT and software development only supported their operation, and advanced on-line technologies were not crucial to achieving an advantage on the market. Many organizations were based on monolithic IT systems developed over the years, requiring costly refactoring emerging along with the need to integrate with new business elements. This was often the reason why IT was perceived as not responding quickly enough to the new needs of the business side. With limited budgets, IT departments had to implement solutions that continued to generate technological debt (on a smaller scale, but still). Buzzwords such as Agile, AI, Big Data, BlockChain, Marketplace, Micoservices, and the Cloud began to appear, being a breath of the upcoming new approach in IT.

 

Today

Currently, we all understand that efficient IT systems are not only necessary for the proper functioning of many organizations, but also often constitute the source of their competitive advantage. Customer expectations, and thus also business expectations in this field, resulted in a significant increase in IT budgets, which translated into an increase in the demand for IT specialists, and thus their price on the labor market. Thanks to new technologies and flexibility provided by the cloud, macro-services, machine learning, and the increasingly better understood Agile methodology, IT is able to deliver business value faster and tries to catch up with the ever-growing business needs. Hybrid and remote work have become a fact, although we are increasingly seeing the threats they pose.

 

Tomorrow

In the future, we will further automate the software development process, thanks to which we will be able to deliver new stable and reusable IT solutions necessary for the expansion of our business even faster. Flexible, self-scalable and self-learning IT systems will become a natural element of the organization's development. Maintaining the coherence of hybrid / remote working teams and their commitment to the company will become a key challenge, increasing the importance of team management and thus the demand for leaders. Strong and flexible IT in an organization will become like electricity at home - obvious to everyone.