Seria C Blacksmith zapewnia status jednorożca, gdy kod AI obciąża testowanie

Blacksmith ogłosił 21 października rundę Serii C o wartości 66 mln dolarów, prowadzoną przez Sequoia Capital, osiągając wycenę 1 mld dolarów. Seria C Blacksmith wspiera konkretną tezę: firmy tworzące więcej oprogramowania z pomocą AI potrzebują więcej infrastruktury do jego sprawdzania. Ciągła integracja, czyli CI, automatycznie buduje i testuje zmiany w kodzie, zanim zespoły połączą je z główną bazą kodu. Blacksmith chce przejąć tę pracę w miarę, jak jego klienci generują więcej zmian.

Bezpośrednia presja spada na zespoły inżynieryjne, które muszą zdecydować, czy rozbudować infrastrukturę zarządzaną samodzielnie, czy powierzyć tę odpowiedzialność specjaliście. GitHub Actions, usługa automatyzacji przepływów pracy GitHub, stanowi znajomy punkt odniesienia, ponieważ zespoły mogą wybierać różne maszyny do wykonywania kontroli. Szansa Blacksmith leży w tej decyzji infrastrukturalnej, a nie w konkurencji dotyczącej generowania kodu.

Finansowanie potwierdza wsparcie inwestorów dla skalowania biznesu. Nie dowodzi, że szybsze kontrole tworzą bezpieczniejsze oprogramowanie ani że każda dodatkowa kontrola oznacza użyteczną pracę. Te rozróżnienia mają znaczenie dla nabywców oceniających ogłoszenie. Kluczowe pytanie brzmi, czy wyspecjalizowana infrastruktura CI może przekształcić rosnące zapotrzebowanie obliczeniowe w krótszą i bardziej niezawodną drogę od proponowanych zmian do zatwierdzonego oprogramowania.

Seria C Blacksmith finansuje ekspansję wykraczającą poza sam kamień milowy finansowania

Nowe finansowanie daje Blacksmith kapitał na rozbudowę infrastruktury stojącej za jego działalnością w zakresie testowania kodu.

W finansowaniu Serii C Blacksmith uczestniczą Premji Invest oraz dotychczasowi inwestorzy: Peak XV Partners, GV i Y Combinator. Firma podaje, że jej całkowite finansowanie osiągnęło 125 mln dolarów. Planuje powiększyć zespół i zwiększyć moc obliczeniową.

Te szczegóły sprawiają, że jest to historia o rozbudowie infrastruktury w równym stopniu, co o finansowaniu venture capital. Usługa uruchamiająca kompilacje klientów musi zapewniać rzeczywistą zdolność wykonawczą. Rekrutacja wspiera ten wysiłek, podobnie jak serwery, ustalenia dotyczące centrów danych oraz oprogramowanie przydzielające pracę dostępnym maszynom.

Wycena odzwierciedla warunki transakcji inwestycyjnej. Nie należy jej traktować jako miary oszczędności klientów, niezawodności oprogramowania ani rentowności operacyjnej. Każda z tych kwestii wymaga odrębnych dowodów.

Dla klientów praktyczne znaczenie nowego kapitału jest węższe. Daje Blacksmith dodatkowe zasoby do realizacji planów ekspansji. Nabywcy nadal muszą ocenić wydajność usługi, zobowiązania umowne oraz dopasowanie jej infrastruktury do własnych obciążeń.

Seria C Blacksmith daje również liderom inżynieryjnym powód, by ponownie rozważyć istniejącą decyzję dotyczącą odpowiedzialności. Wewnętrzne uruchamianie kompilacji może zapewniać kontrolę, ale wiąże się ona z ciągłą odpowiedzialnością operacyjną. Outsourcing wykonania zmienia podmiot ponoszący tę odpowiedzialność.

Ta decyzja rzadko zależy od szybkości pojedynczego testu. Zespoły interesuje też, jak długo praca czeka na rozpoczęcie, jak bada się awarie i kto reaguje, gdy infrastruktura staje się niedostępna. Szybsza maszyna rozwiązuje tylko część całego problemu.

Ogłoszenie inwestycyjne nie może rozstrzygnąć tych kwestii. Może jednak zmienić zasoby dostępne dostawcy próbującemu na nie odpowiedzieć. Blacksmith ma teraz więcej kapitału, by stać się większą częścią systemów dostarczania oprogramowania swoich klientów.

Dla Sequoia i pozostałych inwestorów udział wskazuje na poparcie dla tej ekspansji. Ich zaangażowanie nie zapewnia niezależnego punktu odniesienia dla usługi. Przekonanie inwestycyjne i walidacja operacyjna pozostają odmiennymi formami dowodów.

Istotna zmiana jest więc konkretna: Blacksmith zabezpieczył dodatkowe finansowanie dla biznesu wykonującego kompilacje i testy. To, czy ekspansja poprawi dostarczanie oprogramowania przez klientów, będzie zależeć od tego, co nastąpi po ogłoszeniu finansowania.

Większa ilość generowanego kodu wywiera presję na właścicieli infrastruktury

Decyzja infrastrukturalna staje się pilniejsza, gdy proponowane zmiany napływają szybciej, niż istniejące systemy mogą je ocenić.

Dane Blacksmith dotyczące wzrostu obciążeń CI stanowią najczytelniejszy dowód stojący za narracją o ekspansji. Firma podaje, że tygodniowa liczba zadań CI wzrosła z 5 mln w styczniu do ponad 90 mln. Zadanie jest pojedynczą jednostką pracy wykonywaną w zautomatyzowanym przepływie pracy.

Ten tygodniowy pomiar ma znaczenie. Opisuje bieżącą aktywność, a nie skumulowaną sumę zebraną w historii firmy. Pozostaje też wskaźnikiem raportowanym przez firmę, bez niezależnie zweryfikowanego podziału według złożoności zadań lub struktury klientów.

Blacksmith twierdzi, że roczny przychód powtarzalny, będący zannualizowaną miarą powtarzalnych przychodów, wzrósł 17-krotnie w tym samym okresie. Firma podaje również, że obsługuje ponad 10 000 przedsiębiorstw. Wśród nazwanych klientów są Mercury, Granola, Handshake i LangChain.

Łącznie te ujawnienia wspierają tezę o rosnącej adopcji i wolumenie obciążeń. Nie pokazują jednak, jaka część aktywności pochodzi od obecnych klientów, nowych klientów lub zmian w sposobie dzielenia pracy przez przepływy pracy. Te rozróżnienia wpływają na interpretację wzrostu.

Rozważmy sytuację operacyjną zespołu korzystającego z agentów programistycznych AI, czyli systemów oprogramowania, które mogą proponować i modyfikować kod. Agent przesyła zmianę, uruchamiane są automatyczne kontrole, a po otrzymaniu wyników agent poprawia swoją propozycję. Każda iteracja może tworzyć więcej pracy wykonawczej, zanim człowiek cokolwiek zatwierdzi.

To przykładowy przepływ pracy, a nie zweryfikowany opis konkretnego klienta Blacksmith. Jego znaczenie polega na pętli sprzężenia zwrotnego. Szybsze generowanie zwiększa wartość szybkiej informacji zwrotnej, podczas gdy opóźnione kontrole przerywają tę pętlę.

Presja najpierw dotyka tego, kto odpowiada za środowisko wykonawcze. Może to być zespół inżynierii platformowej odpowiedzialny za współdzieloną infrastrukturę deweloperską. Mogą to być również inżynierowie aplikacji utrzymujący własną automatyzację obok pracy nad produktem.

Zespoły te mierzą się ze sprzecznymi wymaganiami. Potrzebują wystarczającej przepustowości, gdy pojawia się praca, ale muszą też unikać utrzymywania zasobów pozostających bezczynnie. Muszą badać awarie infrastruktury, nie myląc ich z rzeczywistymi defektami proponowanego kodu.

Większa moc obliczeniowa nie rozwiązuje problemu automatycznie. Niektóre testy zależą od wcześniejszego zakończenia innych testów. Niektóre awarie wynikają z usług zewnętrznych. Inne odzwierciedlają niewiarygodne testy, które przechodzą lub kończą się niepowodzeniem bez odpowiadających im zmian w oprogramowaniu.

To sprawia, że szansa biznesowa jest bardziej konkretna niż stwierdzenie „AI tworzy więcej kodu”. Blacksmith potrzebuje klientów, których problemy z wykonaniem są wystarczająco istotne, by uzasadnić wybór specjalisty. Najsilniejszy popyt powinien pochodzić od zespołów potrafiących połączyć usprawnienia infrastruktury z mierzalnymi wynikami dostarczania oprogramowania.

Nabywcy z działów inżynieryjnych powinni zatem traktować wzrost liczby zadań jako dowód aktywności. Aby ustalić wartość, potrzebują dalszego powiązania między tą aktywnością a czasem niezbędnym do podjęcia użytecznej decyzji dotyczącej zmiany.

Wyspecjalizowane CI konkuruje z infrastrukturą, którą zespoły już kontrolują

Główne wyzwanie konkurencyjne Blacksmith polega na przekonaniu zespołów, że warto delegować wyspecjalizowane wykonanie.

Istotną alternatywą nie jest po prostu inny startup. Jest nią rozwiązanie infrastrukturalne, które klient już rozumie, wraz z jego uprawnieniami, procedurami operacyjnymi i wewnętrzną odpowiedzialnością. Zastąpienie części tego rozwiązania wymaga uzasadnienia wykraczającego poza demonstrację.

Dokumentacja GitHub dotycząca self-hosted runners ilustruje ten kompromis. Runner to maszyna lub środowisko wykonujące zadania przepływu pracy. Zespoły zarządzające własnymi runnerami mogą dostosowywać sprzęt i oprogramowanie, ale ponoszą też odpowiedzialność za utrzymanie.

Daje to wewnętrznej infrastrukturze trwałą przewagę: kontrolę. Zespół może umieścić wykonanie blisko prywatnych systemów, instalować wyspecjalizowane zależności i dostosowywać środowiska do nietypowych wymagań. Te decyzje mogą mieć większe znaczenie niż wydajność przy ogólnym obciążeniu.

Odpowiadającym temu ciężarem jest praca operacyjna. Ktoś musi utrzymywać środowisko, badać awarie i zapewniać wystarczającą przepustowość. Wyspecjalizowany dostawca ma szansę, gdy te obowiązki pochłaniają uwagę, którą lepiej przeznaczyć gdzie indziej.

Granica konkurencji jest też bardziej złożona niż Blacksmith kontra GitHub. Koordynacja przepływu pracy i wykonanie zadań to odrębne funkcje. Zespół może zachować znane definicje przepływów pracy, jednocześnie ponownie rozważając maszyny wykonujące pracę.

To rozróżnienie zawęża decyzję zakupową. Klienci nie muszą koniecznie zastępować całego procesu rozwoju, aby zmienić infrastrukturę wykonawczą. Muszą jednak zweryfikować, czy nowe rozwiązanie zachowuje zachowania i mechanizmy kontroli, od których zależą.

Buildkite oferuje kolejne użyteczne porównanie. Jego dokumentacja opisuje równoległe wykonywanie testów, które dzieli odpowiednią pracę na wiele zadań wykonawczych. To podejście pokazuje, dlaczego wydajność kompilacji zależy zarówno od organizacji obciążenia, jak i od sprzętu.

Porównanie nie wyłania zwycięzcy między dostawcami. Pokazuje, że klienci mają kilka sposobów radzenia sobie z opóźnieniami. Mogą zmienić infrastrukturę wykonawczą, przeorganizować testy lub połączyć zmiany infrastrukturalne z usprawnieniami przepływów pracy.

Dla Blacksmith oznacza to, że „większa przepustowość” jest propozycją wyjściową. Przekonujący argument dla klienta powinien wyjaśniać, które źródło opóźnień się zmieniło i dlaczego. Krótsze oczekiwanie, szybsze wykonanie i mniej przerw operacyjnych to różne wyniki.

Porównanie powinno również zachowywać równoważność pracy. Jeśli test próbny uruchamia mniej kontroli lub pomija istotną zależność, krótszy czas ukończenia staje się trudny do zinterpretowania. Nabywcy muszą wiedzieć, czy ta sama decyzja otrzymała taki sam poziom kontroli.

Wewnętrzne zespoły posiadają również wiedzę, która nie pojawia się w wynikach benchmarków. Rozumieją nietypowe zależności kompilacji, powtarzające się wzorce awarii i historyczne powody wyborów konfiguracyjnych. Migracja musi zachować dostęp do tego kontekstu lub zastąpić go zrozumiałą dokumentacją.

W tym miejscu wyspecjalizowana infrastruktura CI przechodzi najbardziej praktyczny test. Musi dostarczyć wystarczającą wartość operacyjną, aby uzasadnić przeniesienie odpowiedzialności. Klienci powinni potrafić wyjaśnić tę wartość własnymi słowami, bez polegania na finansowaniu lub wycenie dostawcy.

Najsilniejsza pozycja konkurencyjna wynikałaby z konsekwentnej użyteczności w ramach istniejących praktyk inżynieryjnych. Wymaga to niezawodnego wykonania, zrozumiałych awarii oraz modelu odpowiedzialności, który klienci uznają za łatwiejszy w obsłudze.

Szybsza informacja zwrotna zmienia ekonomikę każdej rewizji kodu

Mechanizmem stojącym za tą szansą jest krótsza pętla informacji zwrotnej między zaproponowaniem zmiany a odkryciem, czy przechodzi ona kontrole.

Dostarczanie oprogramowania zależy od decyzji. Deweloper lub agent coś proponuje, otrzymuje dowody i decyduje, co zmienić dalej. Infrastruktura wpływa na to, jak szybko te dowody stają się dostępne.

Czas oczekiwania może się kumulować, nawet jeśli poszczególne testy działają w rozsądnym tempie. Zadanie może czekać na dostępną maszynę, zanim rozpocznie się jego wykonanie. Późniejsze etapy mogą czekać na zakończenie wcześniejszych prac. Przerwa w działaniu infrastruktury może zmusić zespół do powtórzenia części procesu.

To są różne ograniczenia i wymagają różnych działań. Dodatkowa pojemność może pomóc, gdy praca czeka na maszyny. Szybsze procesory mogą pomóc w odpowiednich zadaniach wykonawczych. Przeorganizowanie zależności może pomóc, gdy postęp ogranicza sam przepływ pracy.

To rozróżnienie wyjaśnia, dlaczego dowody specyficzne dla klienta mają znaczenie. Dostawca może ulepszyć komponent bez poprawy całej ścieżki dostarczania. Kupujący muszą wskazać etap, który decyduje o tym, kiedy użyteczna odpowiedź staje się dostępna.

Efekt ten staje się szczególnie istotny, gdy agent wykorzystuje wyniki testów do poprawiania kodu. Opóźniona informacja zwrotna sprawia, że kolejna wersja musi czekać. Szybka informacja zwrotna pozwala systemowi lub programiście kontynuować pracę, gdy pierwotny kontekst jest nadal dostępny.

Mimo to szybka odpowiedź ma wartość tylko wtedy, gdy odpowiada na właściwe pytanie. Pomyślne zbudowanie projektu potwierdza, że wykonano określony zestaw operacji. Nie potwierdza, że proponowana funkcja spełnia wszystkie wymagania użytkowników.

Seria C Blacksmith wspiera rozbudowę infrastruktury wykonawczej, lecz to klienci określają, co ta infrastruktura ocenia. Projekt ich testów, praktyki przeglądu oraz kryteria wydania kształtują znaczenie wyników.

Zespół inżynieryjny oceniający tę usługę powinien zatem oddzielić efektywność wykonania od jakości decyzji. Pierwsza dotyczy tego, jak skutecznie działają kontrole. Druga — czy kontrole dostarczają wystarczających dowodów, by zatwierdzić zmianę.

Oba aspekty mogą poprawiać się równocześnie, ale żaden nie gwarantuje drugiego. Zespół może otrzymywać wyniki szybciej, nadal nie mając testów dla istotnego warunku awarii. Może też dysponować dokładnymi testami, które pozostają trudne w użyciu, ponieważ wykonanie trwa zbyt długo.

Najbardziej użyteczny rezultat łączy terminowe wyniki z istotnymi kontrolami. Daje to recenzentom dowody, gdy nadal mają możliwość działania. Ułatwia też odróżnienie defektu od problemu z infrastrukturą.

Jasna dokumentacja wspiera ten proces. Zespoły muszą zachowywać decyzje dotyczące pokrycia testami, wyjątków, założeń migracyjnych i odpowiedzialności za awarie. Przeszukiwalna baza wiedzy może pomóc zachować te wyjaśnienia obok dokumentów technicznych.

Utrwalanie wiedzy pełni inną funkcję niż infrastruktura wykonawcza. Jego znaczenie ujawnia się, gdy zespół musi zrozumieć, dlaczego dana kontrola istnieje lub dlaczego zatwierdzono wyjątek. Szybsze wykonanie nie eliminuje potrzeby takiego kontekstu.

Dla kupujących mechanizm jest więc mierzalny, ale nie powinien być nadmiernie upraszczany. Pytanie brzmi, czy zmiany infrastrukturalne skracają czas potrzebny do podjęcia wiarygodnej decyzji inżynieryjnej. Samo liczenie ukończonych zadań nie daje odpowiedzi.

Wzrost liczby zadań nie potwierdza jakości oprogramowania ani trwałej ekonomiki

Zgłoszony przez Blacksmith wzrost wspiera narrację o popycie, lecz pozostawia istotne pytania techniczne i komercyjne bez odpowiedzi.

Pierwsza niepewność dotyczy jednostki objętej zliczaniem. Zadania CI mogą znacząco różnić się czasem trwania, wymaganiami zasobowymi i przeznaczeniem. Zadanie wykonujące niewielką kontrolę nie jest równoważne zadaniu kompilującemu i testującemu dużą aplikację.

Projekt przepływu pracy również wpływa na łączną liczbę zadań. Podział istniejącej pracy na większą liczbę zadań może zwiększyć wynik bez proporcjonalnego wzrostu użytecznego rezultatu. Powtarzanie nieudanej pracy tworzy aktywność, niekoniecznie przybliżając zmianę do zatwierdzenia.

Żadne z tych spostrzeżeń nie wskazuje na problem z danymi Blacksmith. Wyjaśniają one, dlaczego wskaźnik wolumenu wymaga kontekstu. Czytelnicy nie powinni traktować każdego dodatkowego zadania jako dodatkowo ukończonej funkcji lub zapobiegniętego defektu.

Ujawnione dane o przychodach mają podobne ograniczenia. Wielokrotność wzrostu opisuje zmianę względem wcześniejszego poziomu bazowego. Bez szczegółowego zestawienia finansowego nie potwierdza rentowności, koncentracji klientów ani kosztu obsługi dodatkowych obciążeń.

Firmy infrastrukturalne muszą także równoważyć dostępność z wykorzystaniem, czyli udziałem dostępnych zasobów faktycznie używanych przez klientów. Utrzymywanie zapasowej pojemności może wspierać szybkość reakcji. Może też generować koszty, zanim pojawi się popyt klientów.

Blacksmith podaje, że zarządza nieco mniej niż 10 megawatami mocy obliczeniowej w centrach danych w Stanach Zjednoczonych i Europie. Megawat mierzy moc, a ta liczba wskazuje fizyczną skalę opisywaną przez firmę. Blacksmith twierdzi, że zamierza pięciokrotnie zwiększyć ten zasięg w 2027 roku.

Te ujawnienia sprawiają, że realizację rozbudowy mocy warto obserwować. Nie dostarczają jednak wystarczających informacji, by obliczyć efektywność operacyjną. Czytelnicy potrzebowaliby większej liczby szczegółów o rzeczywistym zużyciu, dostępnej pojemności, wzorcach obciążenia i kosztach infrastruktury.

Bezpieczeństwo wprowadza osobne ograniczenie. Środowiska CI wykonują kod i często współdziałają z poświadczeniami lub systemami wewnętrznymi. Zwiększenie przepustowości nie eliminuje potrzeby kontrolowania tych interakcji.

Wskazówki OWASP dotyczące bezpieczeństwa runnerów podkreślają ryzyka związane z samodzielnie hostowanymi środowiskami wykonawczymi, w tym dostęp do sieci i przechowywanych sekretów. Są to ogólne wskazówki dotyczące bezpieczeństwa, a nie ustalenie dotyczące Blacksmith.

Dla kupującego korporacyjnego oznacza to konieczność zbadania rzeczywistej granicy usługi. Istotne pytania dotyczą tego, jak obciążenia pozostają odseparowane, jak obsługiwane są poświadczenia i jak środowiska wykonawcze są czyszczone między użyciami. Odpowiedzi powinny wynikać z udokumentowanych mechanizmów kontroli.

Istnieje także granica języka zaufania. Przejście testów oznacza, że oprogramowanie spełniło kontrole uruchomione w określonych warunkach. Nie potwierdza braku nieprzetestowanych defektów, niebezpiecznych założeń ani źle zrozumianych wymagań.

Sceptyczne odczytanie jest zatem konkretne. Blacksmith ujawnił wskaźniki zgodne z rosnącym popytem, a inwestorzy sfinansowali dalszą ekspansję. Niezależne wyniki klientów i pełniejsze dane operacyjne wzmocniłyby argumenty wykraczające poza te ogłoszenia.

Taki standard utrzymuje analizę na solidnym gruncie. Nie odrzuca zgłoszonego wzrostu ani nie przekształca go w twierdzenia, których dostępne dowody nie mogą poprzeć.

Obserwuj dostarczanie mocy, wyniki klientów i reakcje obecnych graczy

Kolejne dowody powinny pokazać, czy ekspansja poprawia wyniki klientów przy zachowaniu wykonalnego modelu operacyjnego.

W ciągu najbliższych kilku miesięcy pierwszym sygnałem do obserwowania będzie dostarczanie mocy. Deklarowane przez Blacksmith plany ekspansji wyznaczają kierunek, lecz kupujący potrzebują dowodów, że dodatkowa infrastruktura staje się dostępna tam, gdzie wymagają tego ich obciążenia.

Użyteczne aktualizacje łączyłyby nową pojemność z zachowaniem usługi. Dostępność, czas oczekiwania i wydajność w okresach dużego obciążenia byłyby bardziej informacyjne niż samo ogłoszenie ekspansji. Konsekwentna realizacja wzmocniłaby argument za powierzeniem wykonania specjaliście.

Drugim sygnałem są szczegółowe dowody od klientów. Wcześniejsze ogłoszenie finansowania Blacksmith oraz obecne ujawnienia wskazują na adopcję przez klientów. Kolejnym użytecznym krokiem byłyby relacje wyjaśniające, co zmieniło się w procesach inżynieryjnych tych klientów.

Przekonujący przykład opisałby pierwotne ograniczenie, wykonaną pracę i wynikającą z niej zmianę w dostarczaniu. Rozróżniałby skrócenie oczekiwania od szybszego wykonania. Wyjaśniałby również, czy zespół utrzymał równoważne kontrole.

Szczególnie wartościowe byłyby dowody obejmujące rutynową pracę i okresy dużego obciążenia. Usługa może działać dobrze w komfortowych warunkach, a mieć trudności, gdy popyt się kumuluje. Klienci muszą rozumieć warunki stojące za każdą raportowaną poprawą.

Słabszym sygnałem byłaby kolejna nagłówkowa liczba zadań bez informacji o reprezentowanej pracy. Wolumen pozostaje istotny, ale wyniki klientów ułatwiłyby ocenę jego znaczenia. To samo dotyczy deklaracji wzrostu bez towarzyszącego kontekstu.

Trzecim sygnałem jest reakcja obecnych platform i właścicieli wewnętrznej infrastruktury. Lepsze zarządzane wykonanie, łatwiejsza rozbudowa pojemności lub ulepszone narzędzia przepływu pracy dałyby klientom dodatkowe możliwości. Takie zmiany wyostrzyłyby porównanie, które Blacksmith musi wygrać.

Ulepszenia obecnych graczy nie wyeliminowałyby automatycznie popytu na specjalistów. Podniosłyby standard zróżnicowania. Blacksmith musiałby wykazać, dlaczego jego model wykonawczy pozostaje użyteczny dla obciążeń, które mogą obsłużyć również alternatywy.

Zespoły wewnętrzne również odpowiedzą własnymi decyzjami. Niektóre przekażą więcej wykonania na zewnątrz. Inne zachowają kontrolę, ponieważ ich wymagania czynią takie rozwiązanie korzystniejszym. Istotnym dowodem jest to, jak decyzje te zmieniają się po praktycznej ocenie.

Te sygnały należą do siebie. Pojemność umożliwia ekspansję, wyniki klientów potwierdzają wartość, a reakcje konkurencji określają, na ile ta wartość pozostaje wyróżniająca. Śledzenie wyłącznie finansowania pominęłoby pytania operacyjne, które je łączą.

Dla liderów inżynieryjnych punktem wyjścia powinno być opóźnienie, które zespół już obserwuje. Ustalcie, czy praca czeka na maszyny, działa wolno, zawodzi w nieprzewidywalny sposób, czy trafia do recenzentów bez wystarczających dowodów wspierających. Porównujcie alternatywy względem tego ograniczenia, używając równoważnych kontroli i udokumentowanych warunków. Zachowujcie zapis założeń migracyjnych, zmian odpowiedzialności i nierozstrzygniętych pytań, aby późniejsze wyniki pozostały interpretowalne. Seria C Blacksmith daje firmie zasoby do ekspansji, ale decyzja powinna wynikać z zachowania własnego procesu dostarczania. Przed zmianą infrastruktury zapytajcie, która część ścieżki od proponowanego kodu do zatwierdzonego oprogramowania wymaga poprawy i jakie dowody wykazałyby tę poprawę.