LLMy zabierają fun ;-)

Pisząc poprzedni post o nazwiskach i przypadku Anny Nowak wychodzącej za Piotra Nowaka wspierałem się Gemini od Google w pisaniu, dałem mu też wersję postu i dopisałem, że później napiszę skrypt który zrobi symulację.... a ten drań napisał ten skrypt za mnie....

Najpierw nawet chciałem twardo go nie używać, ale wymiękłem i użyłem....

No używanie LLMów zabiera fun. Pisanie tego skryptu byłoby pewnie zabawne, a tak Gemini to za mnie zrobiło.

Później Copilot dopisał z moimi drobnymi sugestiami uruchamianie tego 10 razy, kolekcję danych i wrzucenie tego do CSV....

Podobne posty^beta
Case "Anny Nowak" ;-)
[Wikipedia fun facts] Coraz więcej stacji kosmicznych
Pomysł na pewny biznes ;-)
3 plusy ;-)
"Chciałabym a boję się" ;-)

Case "Anny Nowak" ;-)

Wyobraźmy sobie sytuację, że mamy pannę Annę Nowak, i kawalera Piotra Nowak.

Mają to samo nazwisko, ale nie są spokrewnieni (przynajmniej w kilku pokoleniach, bo później to już nikt nic nie wie ;-)).

Pobierają się. I teraz zaczynają się ciekawe rzeczy z nazwiskiem.

Oboje muszą zdecydować jak się będą nazywać.
Ich opcje:

• Oboje zostają przy swoim nazwisku,
• Jedno przyjmuje nazwisko drugiego,
• Oboje przyjmują nazwisko łączone (Nowak-Nowak),
• Jedno przyjmuje nazwisko łączone.

W Polsce zwykle nadal to kobieta przyjmuje nazwisko męża.
Rozpatrzmy ten case, czyli case Anny Nowak.

Jeśli pani Anna Nowak przyjmie nazwisko męża Piotra Nowak to będzie to zmiana z Anna Nowak na Anna Nowak ;-)

W dowodzie się nic nie zmieni, więc nie musi zmieniać ;-) ale w PESELu zostanie dokonana zmiana która uwidoczni, że to Nowak jest z małżeństwa, nie z domu ;-)

Ciekawa sprawa, jeśli Anna Nowak(po mężu) i Piotr Nowak się rozwiodą, to Anna Nowak musi podjąć w ciągu 3 miesięcy decyzję czy chce zostać Anną Nowak(po mężu) czy Anną Nowak(z domu) ;-)

Ale okazuje się, że najpewniej w bazie PESELa nazwisko jest free flow, bo Anna Nowak(z domu) stając się Anną Nowak(po mężu) nie będzie miała zmienionego linkowania do innego nazwiska Nowak ;-) a tylko coś co możemy sobie nazwać "źródłem nazwiska" ;-)

Teraz czekam aż spotkam kogoś o nazwisku Nowak-Nowak, albo Kowalski-Kowalski ;-) (bonus points za Nowak-Kowalski lub Kowalski-Nowak ;-))

Ale wróćmy do Anny Nowak, jeśli sama jest bardzo konserwatywna czy staroświecka to może chcieć trzymać się polskich zasad odmiany nazwisk ;-)

Więc przed ślubem byłaby Anną Nowakówną, po ślubie jeśli przyjęłaby nazwisko męża byłaby Anną Nowakową, ale zostawiwszy sobie nazwisko panieńskie nadal byłaby Nowakówną, chociaż byłaby mężatką ;-)
Najlepsze jest jakby postanowiła mieć podwójne nazwisko, bo wtedy byłaby Anną Nowakówną-Nowakową ;-)

(czy tylko ja miałem w szkole podstawowej polonistkę która tęskniła za odmieniowywanime nazwisk?)

Inna sprawa, że obecny model przyjmowania nazwisk prowadzi do "wymierania" nazwisk ;-)

Jak sobie zasymulujemy układ, że startujemy z 1000 nazwisk losowo przydzielonych 3000 osób, i te osoby się "losowo" spotykają i w każdym pokoleniu para ma 2 dzieci o losowej płci i dzieci mają nazwisko zawsze po ojcu to liczba nazwisk maleje tak jak na obrazku (to są wyniki dla 10 symulacji)

W Chinach to jest widoczne bo oni tam de facto teraz mają koło ~100 nazwisk ;-)

A czemu nazwiska wymierają?

Bo jak w danym pokoleniu są tylko dziewczynki o zadanym nazwisku to w kolejnym nie będzie dzieci z tym nazwiskiem....

Podobne posty^beta
LLMy zabierają fun ;-)
Nowa ba(k)teryjka dla G1 :-)
Komuś zdrowo odbiło - znowu....
Spryciarz z Londynu i kilka uwag o tłumaczeniu
Z jednej strony ludzie żyją dłużej i lepiej, z drugiej "upadek moralny"... to co w tym "upadku" złego?

Bez człowieka ani rusz ;-)

Wszyscy, zresztą słusznie podniecają się raportami mówiącymi, że np. 97% wszystkich wdrożeń AI pada...

IMHO powód jest prosty, acz trudny do zrozumienia dla "nietechnicznych".

LLMy są genialne, potrafią robić cuda. Problemem jest to, że czasem robią głupoty... a jeszcze większym to, że nie mamy na razie narzędzi, które potrafiłyby stwierdzić "to rozwiązanie jest piękne i dobre" i "to rozwiązanie jest szalone i niemożliwe". Próbuje się to obchodzić ale nie działa to tak jak byśmy chcieli.

Gdy używamy LLMa w trybie chatu to prowadzimy z nim rozmowę, on może "kłamać" bo wszedł w obszar na którym się nie zna (w cudzysłowach bo on nie ma intencji kłamania, on odpowiada tak samo jak odpowiada gdy mówi sensowne rzeczy), ale po to jest human in the loop, by to wykryć i poprawić.

Jednak gdy coś gdzie używamy LLMa staje się częścią API to jest problem. Nawet jak raz na 100 query odpowie źle to trzeba obudować odpowiedzi czymś co sprawdza wiarygodność odpowiedzi. A to jest trudne. Albo niemożliwe ;-)

A powiedzmy szczerze 1% błędów to to jest marzenie wielu rozwiązań z LLMami ;-)

Stąd np. LLMy dla wielu programistów stały się takim niewkurzającym pair programming partnerem (bo wszystkim zwykle podoba się idea pair programmingu, ale masa ludzi jak zrobi 1-2 30 minutowe sesje w ciągu dnia to jest max, bo po prostu nie chcą być ciągle tak blisko i pisać z kimś kodu), z którym można pisać ciut szybciej, a na 100% mniej wkurzająco.

Ale już systemy agentowe chociaż potrafią coś robić to często potrzebują człowieka, który "sprawdza".
W przypadku kodu to jest postęp bo jednak programiści są drodzy i jak razem z agentami człowiek momentami będzie 10 razy szybszy, a czasem 9 razy wolniejszy to zwykle to się uśredni tak, że będzie "ciut szybszy", a nadzieja jest, że z czasem to będzie się przesuwać ku jeszcze szybszemu.

Jednak wiele firm próbuje używać podejścia bez człowieka w pętli i na tym padają te rozwiązania. A wprowadzenie człowieka zwykle mogłoby podnieść koszty tak wysoko, że nie warto się męczyć... 

Podobne posty^beta
Czy vibecoding zmienia ważność ludzi? Czy PM/PO stają się bardziej niezbędni od inżynierów?
LLMowa ściana ;-)
Jak VHDL obalił komunizm
Seks w ujęciu informatycznym ;-) - rozmnażanie ;-)
Dwa tygodnie z Linuksem - na razie na 4-

Definicja szaleństwa, czyli ja i konsole przenośne

Podobno powtarzanie 3 razy tego co nie udało się dwa razy to definicja szaleństwa ;-)

Ja tak chyba mam z konsolami mobilnymi ;-)

Kupiłem kiedyś Switcha z myślą, że na wyjazdach czy podobnych będę sobie grał w Dooma.... jakoś nie wyszło, bo za mały telewizor. Chociaż wziąłem go nawet do Wenecji kiedyś i grałem wtedy w Zeldę... ale nigdy nie doszedłem zbyt daleko.

Później był SteamDeck OLED czy jakoś tak.
Jakże pięknie się na tym gra w Dooma... brałem ze sobą parę razy na różne wyjazdy, ale tak naprawdę używałem tylko przez pierwsze kilka dni zaraz po zakupie... Największym problemem jest to, że drań jest po prostu za duży żeby go wygodnie brać do samolotu...

Teraz po głowie chodzi mi Switch 2...

Tak to głupi pomysł, ale mi w głowie siedzi ;-)

Podobne posty^beta
Steam Deck OLED po 24h :-)
Weekend i będzie krótki tydzień.
Seriale na podstawie gier... na razie 2 się udały ;-)
Rozszyfrowałem w końcu znaczenie słowa "socjalizm" dla przeciętnego "libertarianina" ;-)
Nadal jestem zachwycony moim Macbookiem Air z M4 :-)

Koniec z socialami?

Mam wrażenie, że moja era social mediów się kończy ;-)

Tak, będę zawsze tęsknił do Google+ i wcześniej Google Buzz, ale to tyle.

FB jakoś w ogóle przeszedł w dziwny tryb. Instagrama nigdy nie opanowałem :-) A Mastodon mi padł... tzn. wydaje się, że moja instancja Mastodona czyli pol.social wzięła i umarła, bo jest niedziela, padła jakoś w tygodniu i zwykle jak padała to tak w sobotę wstawała... a dziś nic. Jest jeszcze LinkedIn.

Chociaż wydaje mi się, że byłbym szczęśliwszy bez social mediów.

Przez dość długo panowało przekonanie, że social media do takiej polaryzacji jaką mamy teraz doprowadziły przez tworzenie bąbelków informacyjnych, gdzie okno Overtona przesuwa się albo w lewo albo w prawo, może nawet nie w prawdziwej "wierze", ale w deklaracjach i ludzie chcąc być czyści ideologicznie identyfikują się z rzeczami w które nie wierzą.... 

Druga szkoła pojawiła się niedawno i mówi, że większym problemem jest to, że w social mediach spotykamy się z najbardziej skrajnymi przykładami postaw "drugiej strony" i w ramach "korekcji" przesuwamy się bardziej w kierunku swojej skrajności "bo jak oni takie straszne rzeczy to trzeba to bardziej poprawić".

Elonowy Twitter tu jest przykładem. Rozumiem, że Twitter to teraz domena alt-right, ale ja dostaję tylko alt-right ;-) bo Elon chce engagementu. 

Engagement jest wtedy gdy nas coś wzburzy. Wtedy nam się włącza chęć walki, a w social mediach nie działają nam filtry społeczne.

Stąd, może to i dobrze, że mi ten pol.social padł. Może po ~18 latach social mediów w końcu będzie spokój? ;-)

A jeszcze Meta utopiła masę monet w Metaverse... może porzucą też Facebooka? ;-)

Podobne posty^beta
Toxic Media ;-)
Porzucenie Facebooka mnie kusi....
Social media są dla demagogów
Tęsknię za Google+ ;-)
Dwa małe błędy - czyli czemu świat nie jest do końca taki jak powinien być ;-)

Dobrze wyskalowałem te 7 lat temu mój czujnik czystości powietrza ;-)

 7 lat temu wyskalowałem swój miernik czystości powietrza używając Airly jako wzorca ;-)

Mój pomysł był taki, wystawiałem miernik na zewnątrz, zapisywałem ile on pokazywał i porównywałem to z wynikami ze strony Airly.

Zrobiłem regresję liniową ;-) (a dokładniej sam Google Sheets to zrobił ;-)) i dostałem wzór:

Prawdziwe_PM2.5=0.21*wynik_PM2.5_z_miernika+10.9

Albo uproszczony:

Przybliżone_PM2.5=wynik_PM2.5_z_miernika/5+11

Zawsze mialem wrażenie, że to dobra metoda, ale nie miałem pewności.

Do dziś, gdy pojawił się u mnie drugi miernik ;-)

Stary pokazuje:

Wg wzorów to powinno być: 15.88 lub (z uproszczonego) 15.74.

A na mierniku jest:

Czyli 14 :-) co dowodzi, że moja metodologia była słuszna ;-)

Podobne posty^beta
Skalowanie miernika jakości powietrza ;-)
Pomysł - przypinajne TODO ;-)
Google Actions działają już w Google Assitant nie tylko na Google Home, ale i w innych jego inkarnacjach :-)
Electron + Airly = wskaźnik jakości powietrza w pasku ;-)
Airly + Python + Oczyszczacz Powietrza = lepsze oddychanie ;-)

Support zawsze lepiej brzmi na koncercie niż na Spotify ;-)

Tak mi się teraz skojarzyło.... (tak powinienem pójść już spać, ale co tam ;-)) bo akurat zobaczyłem w Spotify Aesthetic Perfection, a widziałem ich jako Support dla Tilla Lindemann, na Metallice był Five Finger Death Punch Band i Ice Nine Kills, na BabyMetal była Poppy.... i wtedy to brzmi nieźle, a później słucham na takim Spotify i jest tak sobie....

OK, kiedyś byłem na Rammstein (to był Wrocław Rock Festival czy jakoś tak) gdzie Gojira była pierwszym "supportem", a później Limp Bizkit... i tak, Limp Bizkit mogę słuchać normalnie ;-)

Chociaż z tego na czym byłem w 2025.... czyli BabyMetal, Linkin Park i Till Liderman (bo na Electric Callboy w końcu nie poszedłem....) Linkin Park i Till, choć BabyMetalki też są fajne, ale jakoś Linkin Park i to też te nowe kawałki...

Dobra, cały post jest o tym, że support brzmi lepiej live niż na Spotify ;-) [a w maju w Chorzowie dla Metallica'i supportem będzie znów Gojira... co prawda jestem tym razem na trybunach, ale może pójdę tak żeby trafić jeszcze na support? ;-) po tym Wrocławiu lata temu słyszałem ich jeszcze w Paryżu na otwarciu Olimpiady ;-)]

Może wybierają najlepsze kawałki? Albo chodzi o to, że zaraz będzie ten na kogo się czeka? Chociaż Abelard przed Rammstein nie działa ;-) dziewczyny są za cichutkie.

Podobne posty^beta
Eventy na żywo nie zawsze są bardziej wow niż w TV ;-)
Metallica ;-)
Kamerzysta na łyżwach – człowiek, przez którego pojechałem na Olimpiadę
Rammstein :-)
Ostatni Rammstein... przynajmniej w 2024 ;-)

Budowanie rusztowań

Dziś na LinkedIn ktoś zadał pytanie co by ludzie zrobili mając do wyboru dwie alternatywy:

• duża podwyżka i praca z Cobolem,
• średnia pensja i praca z nowoczesnymi technologiami

Dla mnie oczywista była bramka numer 3 ;-) czyli średnia pensja z nowoczesnymi technologiami jako sposób na zdobycie wiedzy by móc za jakiś czas szukać lepiej płatnej pracy.

Mój cel tu to "dobrze zarabiać i robić fajne rzeczy" i jak nie ma takiej opcji to wybieram "najkrótszą drogę" do tego celu z krokiem pośrednim. Wybór średniej pensji z nowoczesnymi technologiami to taki bootcamp gdzie mi jeszcze zapłacą za nauczenie się czegoś co mi pozwoli na kolejny krok. 
Ale to nie jest nawet tak, że ja ten cel "dobrze zarabiać i robić fajne rzeczy" mam jakoś jasno określony, on mi tu naturalnie wychodzi z opcji i że nie jest osiągalny wprost to myślę o tym jak go osiągnąć etapami.

To samo gdy buduję coś to za naturalne uważam robienie tego wersjami, mogę mieć oczywiście ideę jak to ma wyglądać na końcu, ale zwykle nie mam pojęcia i dlatego zaczynam od wersji minimum, od MVP i dodaję do tego rzeczy i przebudowywuję.

Buduję raz na jakiś czas rusztowania, które wspierają całą budowlę w czasie gdy to jest potrzebne.

Gdy w poprzedniej firmie budowaliśmy nasz produkt to zamiast wybierać bazę danych, projektować struktury danych i tak dalej, zaczęliśmy od prostego narysowania drzewa, później zrobiłem in-memory wersję "bazy danych" i kodowaliśmy resztę.
Wsparcie dla prawdziwej bazy danych zrobiłem siedząc w hotelu w Warszawie, ale przez blisko 2 miesiące kodowaliśmy wszystko bez bazy danych i działało.

Ten in-memory coś to było takie rusztowanie, które pozwoliło nam developować, sprawdzić koncepcję i w końcu wystarczyło dodać konkretną implementację. Co ciekawe to coś pozwoliło nam przeskoczyć później jedno z założeń, które okazało się błędne. 

Z drugiej strony nieraz nie mogłem dojść do porozumienia z kimś kto zakłada, że jak coś jest to ma być. Nie wiem, coś w stylu, mamy nowe API i proxy które tłumaczy nowe API na stare... starego API używa masa ludzi i będzie używać przez wiele lat w przyszłości. Dla mnie jakby naturalne jest uznanie, że "OK, klientów nie zmusimy, więc weźmy to na klatę" i wrzucenie tego proxy z czasem do codebase głównego API (bo proxy napisał inny team, w innej technologii). Ale słyszałem stwierdzenia w stylu "nie po to płaciliśmy za zrobienie tego proxy żeby teraz to włączać do naszego kodu" i ogólnie narzekanie, że "to takie nieporządne będzie". 

Podobne posty^beta
Pierwsza zasada wyboru pracodawcy - rozumieć co robi jego firma ;-)
Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)
Raport z emigracji ;-)
Wzór na zmianę pracy ;-)
Agent nie na wszystko pomoże ;-)

Najwięcej kodu != najlepszy developer

Z serii prawdy nieoczywiste ;-)

A wiesz, że jak masz w zespole developera, który pisze kodu więcej niż inni to jest duża szansa, że jest ten developer najmniej potrzebnym developerem? ;-)

W tej branży wszyscy lubimy pisać kod. Programiści, architekci, managerowie, nawet niektórzy PMowie.

Kodowanie jest fajne... ale sam fakt tego, że pisze się dużo kodu niczego nie dowodzi. Tzn. tak ma się lepszą technikę pisania, ale to tyle.

Jeśli w zespole jest ktoś kto pisze dużo kodu to często jest tak, że ten ktoś "pisze pod siebie", pisze dużo i inni muszą się do tego jakoś dopasowywać. 
Większość ludzi chce współpracować i nie ma tendencji do przepisywania "cudzego kodu", więc próbują się dopasować. Mamy wtedy sprzężenie zwrotne. X pisze na początku dużo kodu, narzuca swój styl, który jest "dziwny", inni próbują się przystosować więc piszą wolniej... a X pisze jeszcze więcej i szybciej.

Widziałem to 2 razy i 2 razy nie było to dobre. Reszta teamu się robiła smutna, byli sfrustrowani, zniechęceni, ale nie do końca wiedzieli czemu. 

Oczywiście to nie jest tak, że każdy taki przypadek jest zły.... ale zwykle o czymś mówi.

Jak masz zespół nierówny bo kogoś z dużym doświadczeniem i reszta ludzi jest młoda to to jest możliwe, i usunięcie tej osoby nie przejdzie bez problemów.... ale lepiej takiego kogoś zachęcić do oddania części pracy, bo inni będą mogli urosnąć, a ten ktoś zajmie się większymi rzeczami.
Jednak jak masz zespół, który jest w miarę równy jeśli chodzi o lata doświadczenia i nie ma tam jednej osoby, która wyraźnie odstaje umiejętnościami na plus, to masz duże szanse na problem. 
To nie jest wina tej osoby, pewnie team nie jest dopasowany. W dopasowanym teamie ludzie sobie patrzą na ręce i sobie pomagają. Jak ktoś się obsuwa to mu pomagają, jak ktoś umie coś nowego to uczy innych. Jak team jest niedopasowany to osoba, która ma najmniejsze opory przed pisaniem kodu (czyli jest najmniej podatny na bycie perfekcjonistą (w tej branży chyba wszyscy mają problem, tylko różni się intensywnością ;-)) zaczyna pisać tego kodu więcej, jeśli reszta teamu jest taka bardziej w trybie follow niż lead to się nie stawiają... 
Tu się przydaje radical candor, idealnie w wersji "Hej X, daj się innym bawić", też dobrze w wersji "X, weź k... zostaw ten kod i daj nam coś napisać, bo znów spartolisz"... niestety często jest mówienie managerowi "nie ma ticketów, bo X bierze".... albo jeszcze gorzej zamknięcie się w sobie.
Dodajmy do tego nietechnicznego PO, który chce szybko zbudować produkt i problem się będzie nakręcał... aż X się znudzi i postanowi sobie poodpoczywać i wtedy spada wydajność całego zespołu, bo inni się przyzwyczajali do wyjadanie resztek po X.... X nic nie je i jest problem.

Stąd ja zawsze próbuję zrobić test ważności przez "a co będzie jeśli Y zniknie z zespołu". I ten test dziwnie często potrafi wskazać, że osoba pisząca najwięcej kodu swoim zniknięciem może zrobić nawet więcej dobrego bo w jej miejsce wskoczą inne osoby.. To widać np. jak X jest na urlopie i nagle za kodowanie biorą się inni ludzie i fajnie to wychodzi.

Podobne posty^beta
Nie lenistwo, a strach. Prawdziwe źródło długu technicznego
Kiedy zmieniać pracę i po co? (w IT)
Kwietniowe książki
Budowanie Boba ;-)
Głosowanie korespondencyjne jest tak dziurawe, że aż szkoda gadać - z perspektywy IT

Nie lejmy betonu na kod....

Jak można zdefiniować gentlemana? Jako mężczyznę który jest w stanie opisać piękną i zgrabną kobietę nie używając rąk...

Jak można zdefiniować dobrego inżyniera? Jako kogoś kto potrafi opisać złożony system bez machania rękami ;-)

Mnie się wydaje, że sztuka polega na tym by widząc problem dokonać jego rozebrania na mniejsze problemy i patrzeć na te problemy jak klocki, z których można budować rozwiazanie. 

Może niektóre klocki są niepotrzebne, a znów inne przydadzą się do czegoś jeszcze? Wtedy nie budujemy ficzera X, budujemy środki do osiągnięcia tego co ma robić ficzer X i zwiększamy ilość dostępnych klocków.

W komputerach zwykle nie rozwiązujemy za każdym razem nowych problemów, a raczej inną wersję tego samego problemu.

Nagle celem staje się nie tyle tworzenie tych klocków, a używanie tych klocków do budowania czegoś większego.

Nie znasz pełnych wymagań? Nie musisz na nie czekać, identyfikujesz kluczowe problemy i je rozwiązujesz tak, że w razie czego chociaż część z nich z niedużymi modyfikacjami pozwoli rozwiązać prawdziwy problem.

Przeszedłem w życiu przez kilka firm ;-) i widzę, że często popularne jest budowanie ficzera w którym sam ficzer staje się ważny. Wydaje mi się, że ja od pewnego momentu patrzę na kawałki i znając historię umiem mniej lub więcej przewidzieć, że ten kawałek przyda się jeszcze w innych miejscach. 

Patrzę na kod (bo kod jest wg mnie nadal ważny) ale bardziej patrzę na powierzchnie styku. Co jest w środku to szczegół implementacyjny. Ważne jest co jest na zewnątrz, jaki jest interfejs. 

Do tego patrzę na kod i staram się myśleć jak on się będzie mógł zmienić, większej zmiany nie zrobimy "na raz" ale na raty się może udać. Nawet nie wiedziałem, dowiedziałem się, że to jest Strangler Fig Pattern ;-)

Żeby nie było ja potrafię napisać brzydki kod ;-) ale zwykle potrafię też zbudować coś co można dalej modyfikować i rozwijać, nie zalewam tego betonem. Zawsze gdzieś można włożyć "coś pomiędzy" i ukryć zmianę przed resztą kodu... fakt czasem jest to trudne, ale zwykle się daje.

Ogólnie lubię robić to tak, żeby komponenty zbytnio o sobie nie wiedziały.... i też nie piszę jednak za bardzo OOP kodu bo u mine class members jako zmienne to głównie jakieś "serwisy" czyli instancje klas robiących coś... zwykle jak spojrzeć to moje klasy są takie semi-bezstanowe.... choć fakt nie jest idealnie bo zdarza mi się, że metoda może modyfikować swój input.... to jest jednak inżynieria nie religia ;-)

To samo podejście próbuję stosować do większych komponentów. W moim idealnym świecie zmiana jednego komponentu jest niewidzialna dla pozostałych... Tak, to znaczy, że może jak gdzieś jest np. pipeline który dostaje format A, pierwszy kawałek przerabia na B, drugi pracuje na B i go ulepsza i w końcu publikuje...  to ja bym wolał wejście A, ale pierwszy robi (A,B) i drugi pracuje na (A,B) i produkuje A... więc z czasem mogę funkcjonalności z pierwszego przenieść do drugiego i go później zabić.

Czyli ogólnie architektura czy kod to jest tylko snapshot całego rozwiązania tu i teraz. Nie musi być doskonały, musi robić tylko to czego od niego na dziś wymagamy, a do nowych wyzwań zawsze może urosnąć.

Podobne posty^beta
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
Czy vibecoding zmienia ważność ludzi? Czy PM/PO stają się bardziej niezbędni od inżynierów?
Tagowanie postów MLem - trzeba to przepisać ;p
Rozdzielanie dwóch światów ;-)
Agent nie na wszystko pomoże ;-)