Na początek

Twoja architektura oprogramowania nie jest „zaprojektowana” przez zespół techniczny — jest „wyrastana” przez twoją strukturę organizacyjną. Ta zasada sformułowana w 1968 roku jest powtarzalnie potwierdzana w erze AI.
Empiryczne badania Harvard Business School wykazały: odległość organizacyjna lepiej przewiduje częstość błędów w oprogramowaniu niż złożoność kodu. To, co uważasz za „dług techniczny”, w istocie może być „długiem organizacyjnym”.
Imperium mikroserwisów Amazon, model zespołów Spotify, kryzys Siri w Apple — trzy firmy o wartości bilionów dolarów, z zupełnie innymi losami, ilustrują tę samą zasadę.
Agenti AI wchodzą do organogramów organizacyjnych. Gdy „węzły” w zespole przestają być wyłącznie ludźmi, prawo Conwaya zostanie przepisane w sposób, którego nie przewidziano.

W 1968 roku nieznany programista napisał artykuł, który „Harvard Business Review” odrzucił z uzasadnieniem: „nieudowodniono tezy”. 56 lat później, jądro tego artykułu stało się powszechnie akceptowaną zasadą całej branży oprogramowania — a w 2026 roku, w erze AI, która przekształca wszystko, ma większą wagę niż kiedykolwiek wcześniej.

I. Jak zaprzeczony artykuł stał się „prawem grawitacji” inżynierii oprogramowania

Prorok odrzucony przez HBR

W kwietniu 1968 roku Melvin Conway opublikował w magazynie „Datamation” artykuł o zaskakująco monotonnym tytule: „How Do Committees Invent?” (Jak komitety wynalazają?).
Jego główne twierdzenie zawarte jest w jednym zdaniu — i wystarczy, by każdy CTO nie spał nocami:

„Organizacje projektujące systemy tworzą projekty, które są homomorfizmem ich struktur komunikacyjnych.”
Przetłumaczone na język potoczny: Twoja organograma to „odwzorowanie” twojej architektury oprogramowania.
Conway w artykule opisał subtelny przykład: firma przydzieliła ośmiu osobom do stworzenia dwóch kompilatorów, podzielając je na dwie grupy: pięcioosobową i trzyosobową. Co się stało? Grupa pięciu osób stworzyła kompilator z pięcioma etapami, a trzyosobowa — z trzema etapami. Nie dlatego, że technicznie wymagało tego takie podzielenie, ale dlatego, że każdy potrzebował „własnego” jednostki pracy.
Conway opisał tę zależność jako „homomorfizm” — strukturalną, zachowującą formę relację między organizacją a projektem systemu. Nie jest to przypadek, nie jest to los — to prawie matematyczna konieczność.

Ironią jest to, że Conway pierwotnie wysłał tę pracę do „Harvard Business Review”, ale redakcja odrzuciła ją z powodu „nieudowodnionego twierdzenia”. Siedem lat później Fred Brooks w klasycznym dziele „The Mythical Man-Month” poważnie odwołał się do tego spostrzeżenia i oficjalnie nazwał je „Prawem Conway’a” (Conway’s Law).
Od tego czasu obserwacja odrzucona przez najwyższe czasopisma biznesowe stała się jednym z najbardziej cytowanych praw w inżynierii oprogramowania.
## „Zakończenie” Martina Fowlera
Jeśli Conway był Kopernikiem sformułującym hipotezę, to dwadzieścia lat badań empirycznych to teleskop.
W 2022 roku Martin Fowler, główny naukowiec ThoughtWorks, napisał fragment, który szybko rozprzestrzenił się w branży: „Jeśli istnieje jedno prawo w architekturze oprogramowania, z którym zgadzają się wszyscy praktycy, to jest to Prawo Conway’a. Jest wystarczająco ważne, by wpływać na każdy system, jakiego kiedykolwiek widziałem; jest wystarczająco potężne, by każdy, kto próbuje mu się przeciwstawić, był skazany na porażkę.”
To nie jest teoretyczne rozumowanie uczonego z wieży słoniowej. Fowler w swoich praktykach konsultacyjnych w setkach firm na całym świecie wielokrotnie obserwował ten sam fenomen: organizacyjna struktura firmy jest cieniem architektury oprogramowania — niezależnie od tego, czy menedżerowie to zdają sobie sprawę, czy nie.

Tu jest subtelny, ale kluczowy nuans, którego wiele osób przeocza: Fowler mówi o „każdym, kto próbuje przeciwstawić się mu”, a nie o „każdym, kto próbuje wykorzystać go”. Jaka jest różnica? Przeciwstawianie się prawu Conwaya oznacza wymuszanie zmian architektonicznych bez zmiany struktury organizacyjnej; wykorzystanie go oznacza najpierw dostosowanie organizacji, by architektura „naturalnie rozrastała się”.
Ta różnica decyduje o sukcesie lub porażce projektów cyfryzacji. W kolejnej, drugiej części, podczas omawiania Team Topologies, rozwinemy kluczową strategię „odwrotnego działania Conwaya” (Inverse Conway Maneuver) — która w istocie polega na wykorzystywaniu, a nie przeciwstawianiu się tej zasadzie.

II. Od laboratorium do pola walki: trzy badania potwierdziły to prawo

„Hipoza lustrzana” Harvard Business School

W 2012 roku MacCormack i inni z Harvard Business School opublikowali znaczące badanie, znane w kręgach akademickich jako „hipoza lustrzana” (Mirroring Hypothesis).

Metodologia była bardzo sprytna: badacze wybrali oprogramowanie komercyjne i oprogramowanie open source, które wykonywały dokładnie tę samą funkcję. Oprogramowanie komercyjne było tworzone przez hierarchiczne zespoły korporacyjne, a open source — przez rozproszone społeczności.

Wyniki potwierdzają przewidywania prawa Conwaya: produkty tworzone przez organizacje o luźnych powiązaniach są znacznie bardziej modułowe. Ścisłe zespoły w korporacjach, nawet jeśli celowo dążą do projektowania modułowego, ostatecznie tworzą systemy o charakterystycznej, silnej korelacji z ich strukturą organizacyjną.

Struktura organizacyjna działa jak „pole grawitacyjne” — możesz na chwilę jej przeciwstawiać, ale z biegiem czasu architektura systemu zawsze wraca do kształtu odpowiadającego strukturze organizacyjnej.

Jaka jest prawdziwa nauka dla menedżerów biznesowych? Gdy twoje zespoły techniczne powtarzają: „Potrzebujemy refaktoryzacji”, prawdopodobnie nie chodzi o kod — tylko o organizację. Ale jak rozróżnić „dług techniczny” od „długu organizacyjnego”? Wymaga to systematycznej metody diagnostycznej — pełny model oceny przedstawimy w 12. artykule: „Ramy decyzyjne dotyczące wdrażania narzędzi AI w firmach”.

Eksperyment „Windows Vista” z Microsoft Research

W 2008 roku Nagappan i inni z Microsoft Research przeprowadzili ogromne badanie ilościowe nad projektem Windows Vista. Ich celem było odpowiedzieć na kluczowe pytanie: jaki czynnik najlepiej przewiduje błędy (bugi) w oprogramowaniu?

Kandydatami były: złożoność kodu, liczba linii kodu, częstotliwość zmian, doświadczenie programistów… oraz zmienna, która wydawała się nie mieć związku z „technologią” — odległość organizacyjna (tzn. odległość między zespołami odpowiedzialnymi za różne moduły w strukturze organizacyjnej).

Wyniki badań wywołały niepokój wśród wielu technokratów: odległość organizacyjna lepiej przewiduje częstość błędów w oprogramowaniu niż złożoność kodu. Innymi słowy, moduły rozwijane przez zespoły, które są „daleko od siebie” na organizacyjnej strukturze, są bardziej podatne na błędy niż bardzo złożone moduły utrzymywane przez blisko współpracujące zespoły. Myślisz, że błędy wynikają ze złego kodu — a może są skutkiem złego projektu organizacyjnego?

To odkrycie ma znacznie głębsze konsekwencje korporacyjne, niż się wydaje. Oznacza to — twoja strategia QA powinna być dopasowana do struktury organizacyjnej, a nie do złożoności kodu. Moduły wymagające współpracy między zespołami potrzebują bardziej rygorystycznego zakresu testów i procesów recenzji, nawet jeśli sam kod wydaje się prosty. W erze, gdy AI generuje ogromne ilości kodu (Copilot obecnie tworzy 46% kodu pisaneego przez użytkowników), ta zasada staje się jeszcze bardziej kluczowa — kwestię tę szczegółowo omówimy w artykule 8, wykorzystując przykład Coinbase.

„Przyspieszenie” i „zagrożenia” w badaniach DORA

Zespół DevOps Research and Assessment (DORA), należący do Google i prowadzony przez Nicole Forsgren, Jez Humble i Gene Kim, opublikował największe na świecie badanie wydajności dostarczania oprogramowania.

Kluczowe odkrycie jest zgodne z prawem Conwaya: „Jeśli zaimplementujemy architekturę o niskiej łączności i dobrze zapakowanych komponentach, wspieraną odpowiednią strukturą organizacyjną, możemy nie tylko przyspieszyć tempo i zwiększyć stabilność dostaw, ale także utrzymać liniowy lub nawet nadliniowy wzrost produktywności podczas znacznego powiększenia zespołów inżynierskich.” Jednak raport DORA z 2022 roku wykrył również ciekawe skutki uboczne: architektura o niskiej łączności, choć zwiększa efektywność dostaw, może zwiększać wypalenie zespołów. Powodem może być to, że gdy zespoły są wysokiej autonomii i wzajemnie izolowane, członkowie tracą poczucie globalnego znaczenia, czując się „tylko zębami w kole”.
To ważna przypomnienie — zgodność architektury z organizacją nie jest srebrną kulą; rozwiązuje problemy efektywności, ale może tworzyć problemy kulturowe. Wnioskiem, który zasługuje na głębsze zastanowienie: jeśli architektura o niskiej łączności + organizacja o niskiej łączności już sprawia, że ludzcy programiści czują się izolowani, co się stanie, gdy do zespołów dołączą agenty AI? AI nie „czuje izolacji”, ale ludzie będą czuli się jeszcze bardziej izolowani. Ten aspekt rzadko jest omawiany, ale w materiałach, które badaliśmy, raport BCG z 2025 roku wspomina o „problemie koordynacji menedżerów średniego szczebla” — co stanowi główne zagadnienie naszej 11. części.

III. „Moment Conwaya” trzech firm o wartości bilionów dolarów

Amazon: e-mail CEO, który wszystko zmienił

Wokresie 2002 roku Jeff Bezos wysłał wewnętrzny memorandum w Amazon znanego jako „API Mandate” — wszystkie zespoły miały komunikować się wyłącznie poprzez interfejsy usług (API), a bezpośredni dostęp do magazynów danych innych zespołów był surowo zabroniony. Ostatnia zasada tego memorandum, jak się mówi, brzmiała: „Osoby nieprzestrzegające powyższych zasad zostaną zwolnione.” Wiele osób traktuje architekturę mikroserwisów Amazon jako decyzję techniczną. Ale z punktu widzenia prawa Conwaya, Bezos podjął decyzję organizacyjną: najpierw za pomocą narzędzi zarządzania przerwał „skróty komunikacyjne” między zespołami, a następnie architektura oprogramowania naturalnie ewoluowała w izolowane moduły usług. Tak powstał później znany jako „zespół dwóch pizz” (Two-Pizza Team) — każdy zespół nie powinien przekraczać liczby osób, które można nakarmić dwiema pizzami (zwykle 5–8 osób), a każdy zespół posiadał własną usługę, wdrażał ją niezależnie i komunikował się z zewnętrznym światem poprzez API. Imperium mikroserwisów Amazon nie zostało zaprojektowane przez architektów — wyrosło z organizacji. To najbardziej klasyczny pozytywny przykład prawa Conwaya.

Ale tutaj jest aspekt, o którym wiele artykułów nie wspomina: sukces Amazon nie wynikał tylko z tego, że Bezos zrozumiał prawo Conwaya, ale także z tego, że jednocześnie rozwiązał problem „zgodności激励”. Każdy „zespół dwóch pizz” miał własną P&L (rachunek zysków i strat), był niezależny nie tylko technicznie, ale także biznesowo. Oznacza to, że zespoły miały wewnętrzny motyw do utrzymywania jasnych granic usług — ponieważ rozmyte granice oznaczały rozmytą odpowiedzialność, a rozmyta odpowiedzialność oznaczała rozmytą ocenę. Trójkąt zgodności: struktura organizacyjna + struktura激励 + architektura techniczna — to pełny obraz modelu Amazon. Firmy, które naśladowały tylko strukturę organizacyjną, a nie projekt激励, zazwyczaj zdobywały tylko formę, nie esencję. ## Spotify: idealny model napotykający „entropię” w rzeczywistości Model „Squad” Spotify był kiedyś uznawany w Silicon Valley za świętą księgę projektowania organizacji: małe, autonomiczne zespoły (Squad) liczące 5–8 osób, które tworzyły plemiona (Tribe), a ekspertów technicznych z różnych plemion łączyły kapituły (Chapter), a społeczności oparte na zainteresowaniach — gildie (Guild). Projekt tego modelu jest zgodny z prawem Conwaya — poprzez strukturę małych, autonomicznych zespołów generowano małe, autonomiczne usługi oprogramowania.

Ale Spotify sama później przyznała, że rzeczywistość jest znacznie bardziej złożona niż model. Gdy biznes osiągnie pewien rozmiar, zależności między zespołami nieuniknienie rosną, a czysta autonomia zaczyna generować koszty koordynacji. To ujawnia jedno z rzadziej docenianych wniosków z prawa Conwaya: struktura organizacyjna nie jest czymś, co projektuje się raz i na zawsze — ma tendencję do „zwiększania entropii”, podobnie jak oprogramowanie. Wraz ze wzrostem złożoności biznesowej granice organizacyjne stopniowo rozmywają się, ścieżki komunikacji wydłużają się, a architektura systemu się degradowuje. Doskonałe organizacje techniczne nie „zaprojektowały dobrej architektury” — budują zdolność do ciągłego dopasowywania struktury organizacyjnej do architektury. O tej zdolności rozszerzymy w drugim artykule o Team Topologies — oferuje ona systematyczniejszy i bardziej praktyczny framework niż model Spotify. ## Apple: Dlaczego Siri przegrała z ChatGPT W latach 2024–2025 plan ulepszenia AI Siri od Apple stał się prawie „antyprzykładem” prawa Conwaya.

Źródłem problemu nie jest technologia. Apple posiada światowo liderujących specjalistów od AI i obfite zasoby finansowe. Ale rozwój Siri obejmuje dwie drużyny, pomiędzy którymi istnieje strukturalna szczelina organizacyjna: zespół badań nad AI (kierowany przez Johna Giannandrea) i zespół rozwoju produktu (kierowany przez Craiga Federighiego).

Te dwie drużyny mają różne priorytety, różne tempo i różne kryteria sukcesu. Zespół badań dąży do przełomów na froncie możliwości modeli, podczas gdy zespół produktowy skupia się na stabilnym dostarczaniu doświadczenia użytkownika. Gdy struktura komunikacji między tymi dwoma „węzłami” organizacyjnymi jest rozłączona, wynikowy system musi być rozłączony.

Co ostatecznie otrzymuje użytkownik w Siri? „Średniego asystenta złożonego z fragmentów” — poszczególne moduły wydają się w porządku, ale po połączeniu brakuje jednolitego, inteligentnego doświadczenia. To dokładnie przewidziany przez prawo Conwaya efekt: szczeliny w systemie odbijają szczeliny w organizacji.

Przypadek Apple jest szczególnie istotny dla polskich decydentów biznesowych. Wiele firm przeżywa dokładnie ten sam problem — zespoły AI i biznesowe należą do różnych vice-prezesów, a projekty wdrażania AI stają się „polityczną grą między dwoma działami”, a nie „wspólnym, koordynowanym dostarczaniem produktu”.

Jeśli Twoja firma aktywnie wdraża AI, spojrzyj ponownie na swoją strukturę organizacyjną: zdolności AI istnieją jako niezależny dział, czy są wbudowane w zespoły biznesowe? Odpowiedź na to pytanie może mieć większy wpływ na sukces projektu niż wybór konkretnego modelu AI.

Cztery: Era AI – Prawo Conwaya jest ponownie zapisywane

Gdy „węzły organizacyjne” nie są już wyłącznie ludźmi

W 2026 roku prawo Conwaya napotyka najgłębsze wyzwanie od 1968 roku.
Conway zakładając to prawo, miał na myśli ukrytą przesłankę: każdy „węzeł” w organizacji to człowiek. Struktura komunikacji to komunikacja między ludźmi.

Ale dziś agenty AI wchodzą do diagramów organizacyjnych. Claude Code może samodzielnie wykonywać wieloetapowe zadania programistyczne, system Minions firmy Stripe generuje ponad 1000 scalanych PR tygodniowo, Cursor zmienił sposób pracy 100% inżynierów NVIDIA. Raport Gartnera stwierdza, że w 2025 roku zapotrzebowanie na konsultacje dotyczące wieloagentowego koordynowania AI wzrosło o 1445%.

Co się stanie z prawem Conwaya, gdy niektóre węzły w organizacji przestaną być ludźmi?

Rozważanie tego problemu będzie się rozciągać przez drugą połowę naszej serii — zjawisko „Jednoczłonkowej Unicorny” w artykule 10, „Prawo Conwaya spotyka AI agents” w artykule 11, „Agentic Engineering” w artykule 14 — ale na początek przedstawiam trzy wstępne stwierdzenia, które pomogą Ci zbudować ramy myślenia:

Pierwsze: struktura komunikacji stanie się strukturą strategii. Komunikacja między ludźmi opiera się na kulturze, zrozumieniu bez słów i nieformalnych interakcjach. Ale między ludźmi a AI agents nie ma „zrozumienia bez słów” — musisz jasno zdefiniować granice interakcji poprzez strategie, reguły i uprawnienia. Zdolność do zarządzania zastąpi zdolność do komunikowania się jako kluczowy czynnik projektowania organizacji.

Drugie: schematy organizacyjne stają się schematami uprawnień. Tradycyjne schematy organizacyjne opisują relacje raportowania i podział funkcji. „Schemat” w erze AI przypomina raczej skierowany graf acykliczny (DAG), który definiuje możliwości i ograniczenia — który agent może uzyskać dostęp do jakich danych, wykonać jakie operacje i w jakich warunkach wymaga zatwierdzenia przez człowieka.

Trzecie: wiedza instytucjonalna przenosi się z ludzi na strategie. W przeszłości „kiedy doświadczony pracownik odechciał, zabierał ze sobą wiedzę” było bólem każdej firmy. W przyszłości kluczowa wiedza zostanie zakodowana w strategiach i kontekstach AI agents — to jednocześnie okazja (wiedza nie ucieka) i ryzyko (błąd w strategii może być systemowo wzmocniony).

Każde stwierdzenie opiera się na licznych praktykach branżowych i danych. Na przykład trzecie stwierdzenie dotyczące „przenoszenia wiedzy instytucjonalnej” dostarcza drastycznego przykładu pozytywnego i negatywnego — Klarna po zwolnieniu 40% pracowników odkryło, że system AI nie jest w stanie zastąpić ukrytej wiedzy, którą pracownicy ze sobą zabrali, i musieli ponownie zatrudnić ludzi. O tym przypadku szczegółowo opowiemy w 9. artykule „Lekcje Klarna”.

Pierwsze i drugie stwierdzenie nie jest naszym wyłącznym spojrzeniem. W odcinku a16z Podcast z lipca 2026 r. pt. „Software in the Age of Agents” Seema Amble, partnerka zespołu przedsiębiorstw a16z, oraz Steven Sinofsky, były prezes Microsoft Windows, na podstawie obserwacji inwestycyjnych z pierwszej ręki doszli do zgodnych wniosków. Steven jednym zdaniem ujawnił istotę pierwszego stwierdzenia: „Największy efekt sieciowy w oprogramowaniu przedsiębiorstw występuje wewnątrz firmy” (The biggest network effect in enterprise software is inside of a company): prawdziwą siłą przyklejenia jest sieć utworzona przez relacje międzyludzkie, procesy i systemy wewnątrz organizacji. Agent nie może się do tej sieci „dostosować” poprzez porozumienie, tylko poprzez jasne strategie i uprawnienia — to właśnie jest rzeczywista siła napędowa przekształcania struktury komunikacji w strukturę strategii. Seema potwierdziła drugie stwierdzenie z perspektywy dostępu agentów do systemów przedsiębiorstw: gdy agent ma „wykonać” działanie (zapisywać rekordy w systemie, zmieniać księgowość), natychmiast napotyka cały zestaw problemów — tożsamość, certyfikaty, miejsca licencyjne, uprawnienia do zatwierdzania — mapa organizacyjna jest przekształcana w mapę uprawnień: „kto może uzyskać dostęp do czego, kto autoryzuje co”. Te dwa stwierdzenia nie są prognozami — są rzeczami, które już się działy w projektach, w które inwestorzy z linii frontu wkładają pieniądze. (Goście: partnerzy a16z / byli menedżerowie Microsoft, stanowisko VC.)

V. Samokontrola: Jaki błąd „Conwaya” popełnia Twoja organizacja?

Jeśli do tej pory myślisz: „To wszystko i tak wiem”, to zapraszam Cię do ćwiczenia.

Poniżej przedstawiamy pięć typowych wzorców niezgodności między organizacją a architekturą, wywiedzionych z prawa Conwaya i powiązanych badań. Sprawdź, które z nich pasują do Twojej firmy:

❶ Pozorna mikroserwisowość: Kod został podzielony, ale 50 osób nadal w jednej grupie się kłóci.
❷ Iluzja platformy centralnej: Platforma centralna stała się węzłem komunikacyjnym dla wszystkich linii biznesowych.
❸ Wyspy AI: Modele stworzone przez zespół AI nie mogą być wdrożone w biznesie, ponieważ organizacyjnie „nie są na tej samej trasie”.
❹ Degradacja współpracy zdalnej: Izolacja fizyczna prowadzi do niepotrzebnego rozdzielenia systemów.
❺ Zła integracja po przejęciu: Niezgodność kulturowa organizacji powoduje porażkę integracji technologicznej.

Kolejny krok

To pierwszy z 15 artykułów serii „Transformacja inżynierii oprogramowania w erze AI”. Wychodząc od prawa Conwaya, stworzyliśmy podstawową intuicję: architektura organizacyjna determinuje architekturę systemu — nie jest to metafora, lecz udowodniona przyczynowo-skutkowa zależność.

Ale znanie tej zasady to tylko początek. Prawdziwe pytanie brzmi: Czy możemy wykorzystać ją w sposób odwrotny? Przez celowe projektowanie struktury organizacyjnej, by kierować pożądaną architekturą systemu — oto jądro „odwrotnej operacji Conwaya” (Inverse Conway Maneuver). W kolejnym artykule „Team Topologies — metodyka projektowania organizacji w epoce po Agile” szczegółowo omówimy, jak Matthew Skelton i Manuel Pais rozwinęli tę ideę w kompletną, praktyczną metodykę, obejmującą cztery podstawowe typy zespołów, trzy modele interakcji oraz pojęcie „obciążenia kognitywnego”, które jest poważnie niedoceniane. Przykłady z praktyki Netflix, Adidas i Accenture pokażą: w jakich warunkach odwrotna operacja Conwaya działa, a w jakich zawodzi. — > Uwaga serii: Ta seria będzie śledziła najnowsze rozwój narzędzi AI do programowania, architektury organizacyjnej i paradygmatów inżynierii oprogramowania, takie jak nowe zastosowania prawa Conwaya w erze agentów AI w 2026 roku czy dojrzałość najnowszych ekosystemów narzędzi. Obserwuj serię, by otrzymywać aktualne spostrzeżenia. # O tej serii

„Transformacja inżynierii oprogramowania w erze AI” to głęboki serię badań skierowaną do decydentów technicznych w firmach, składającą się z 15 artykułów. Opierając się na systematycznym analizowaniu ponad 200 artykułów akademickich i raportów branżowych, dostarczamy referencje decyzyjne z oznaczeniem poziomu dowodów. Więcej treści wkrótce.

Źródła:

Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: „The biggest network effect in enterprise software is inside of a company” + Seema Amble o agentach napotykających bariery uprawnień, certyfikatów i licencji — wspierają sądy w sekcji 4; źródło pierwszorzędne — oryginalny nagranie podcastu. Oznaczenie stanowiska: partner a16z / dawny menedżer Microsoftu, stanowisko VC. Goście zweryfikowani: partnerka zespołu przedsiębiorstw a16z Seema Amble, dawny prezes Windows w Microsoft Steven Sinofsky (board partner), autorka a16z Elena Burger; wyemitowane 2026-07.)