🤠 Hillbilly hacker manifesto

19 obserwacji, hipotez i loosely held bets po kilku miesiącach pracy z Cursorem.

Drodzy,

Chyba nie da się w ostatnich tygodniach przeglądnąć LinkedIna czy Twittera bez natrafienia na nowe środowisko programistyczne Cursor.sh, oparte na Visual Studio Code, które wprowadza szereg funkcji wspomaganych przez LLMy. W dużym skrócie faktycznie programujemy promptami i to działa.

Dziś wiwisekcja własnej duszy po kilku miesiącach używania Cursor.sh i moje 19 obserwacji, hipotez, loosely held bets wokół programowania oraz postawy “hillbilly hacker” gdzieś obok panteonu indie developer czy solopreneur.

🔔 Lektura tego artykułu zajmie około 8 min 20 sec. Dodaj go do swojego kalendarza, aby przeczytać później: Dodaj do Kalendarza Google | Dodaj do iCal | Dodaj do Outlooka

---

• AI jest za tanie. Subskrypcja $192 rocznie, czyli 754 PLN. Dosadniej: za tyle mam asystenta i junior developera na rok.

• Ryzyko wsobności. Moja uboga wiedza o programowaniu zatrzymała się praktycznie w 2014-2015 roku na Python, R + Bootstrap (JavaScript/jQuery, HTML, CSS). Widzę u siebie, że pokusa zbudowania czegoś na szybko bierze górę nad motywacją do uczenia się nowych i może lepszych rozwiązań typu React, Next.js, Typescript. W pliku .cursorrules definiuję reguły na poziomie repozytorium dla LLM (np. “Po stronie backendowej korzystaj z Flaska, frontend w Bootstrapie” - polecam cursor.directory) co może nie jest dobre długoterminowo, bo z lenistwa (?) omija mnie sporo ciekawych bibliotek UIowych np. MagicUI, nawet łapię się na tym, że wolę się trzymać Bootstrapa niż eksperymentować z Tailwind, który mi się bardziej podoba.

• Na plus: nowy feature jest promptem w Composerze, więcej sięgam w nauce częściej teraz nie “jak coś napisać we Flasku”, ale do wysokopoziomowych dobrych praktyk, artykułów związanych z architekturą, wzorcami projektowymi, czyli high-level i abstrakcja (bardzo cenię ostatnio Roadmap.sh).

• Platon i krytyka pisma / Copilota. Obawy dotyczące narzędzi takich jak Cursor.sh i Copilot, które automatycznie generują kod i odciążają młodych adeptów i adeptki z dogłębnej nauki języka programowania, mają pewnie analogie do krytyki pisma sformułowanej przez Platona w Fajdrosie spisanego ponad 2000 lat temu.
  
  Platon przedstawia rozmowę Sokratesa z Fajdrosem, w której Sokrates wyraża sceptycyzm wobec pisma. Uważa on, że pismo osłabi ludzką pamięć i zdolność do prawdziwego i głębokiego rozumienia. (“Pismo bowiem u uczących się sprawi w duszach zapomnienie z braku ćwiczenia pamięci, jako że zawierzając pismu od zewnątrz jego obcych znaków sami w sobie nie będą skłonni do zapamiętywania. (…) staną się nader bystrzy wzrokowo, bez nauki zdając się być erudytami, choć w większości to ignoranci i trudni do współżycia, staną się oni pozornie mądrzy zamiast mądrymi” - głównie w 274b-277a).
  
  Jest w tym może odrobina racji, choć więcej w tym widzę spazm elitaryzmu w reakcji przeciw demokratyzacji. Pewnie to samo mówiono, gdy przed promptowaniem było szukanie odpowiedzi po Stack Overflow.
  

  

• Nauka programowania = flow nauki języka naturalnego. Ostatnio mój częsty zabieg samo-edukacyjny, to po wygenerowaniu kodu aplikacji przez Cursor/LLM proszę go:

Stwórz dokumentację i komentarze do tego kodu jak dla Junior Developer, która wyjaśnia koncepcje i rozwiązania zastosowane w aplikacji. Dodatkowo przygotuj mi mini-lekcje, które omawiają kluczowe koncepcje i użyte rozwiązania, wraz z instrukcjami krok po kroku, tak aby początkowy programista mógł je zrozumieć.

Mam wrażenie, że to trochę kalka z nauki języka naturalnego: najpierw uczymy się mówić, później wtórnie w podstawówce uczymy się wyższego poziomu abstrakcji co to koniugacja, fleksja i zaimek. Myślę, że częstym błędem w nauce programowania czy podręcznikach jest ta tendencja do dogłębnego zrozumienia wąskiego wycinka (“poznasz teraz wszystkie operacje na stringach”), a osoby przystępujące do nauki nieraz chcą się nauczyć języka zamiast budowania.

(tu przygotowałem prosty skrypt i bazę promptów, który zamienia cały codebase w jeden plik .txt wraz ze strukturą zjadliwą dla LLMów. Przy większej bazie lepiej stosować Gemini-1.5 z kontekstem +1 mln. Np. “na podstawie kodu zrekonstruuj user stories i wskaż potencjalnie brakujące user stories lub wskaż udoskonalenia”)

• Git Master. Na pewno praca z Copilotem czy Cursorem, który ingeruje w kod, automatycznie poprawia (nieraz błędnie) wymusza biegłe korzystanie z Gita branchowanie, przywracanie poprzednich wersji. Nic nie jest lepszą szkołą z użycia gita i zmiennych systemowych niż pchnięcie na publiczne repozytorium pliku, w którym zapisany plain textem klucz API.

• Wzrost znaczenia QA. IMO rola QA engineerów będzie tylko rosnąć (“code editors”). Kiedyś słyszałem ładne określenie, że o “kulturze deweloperskiej organizacji nie świadczy ilość developerów, a QA engineerów”. Pisząc coś teraz łapię się, że jest to pierwsza grupa, do której chce się zgłosić po usługę czy konsultację (“sprawdź, co pominąłem, o czym zapomniałem”). Tak da się to zrobić promptem, ale mówię o intuicji.

• Hillbilly Hacker advantage. Brak formalnego wykształcenia inżynierskiego może być paradoksalnie przewagą w pracy z narzędziami typu Cursor:
  a) Bezobciachowość. brak lęku przed eksperymentowaniem, popełnianiem błędów przyćmiony ekstazą, że działa ("done >> nice and correct")
  b) myślenie w kategoriach "zrób mi całe" i oddanie się w ręce Cursora, który czasem może wiedzieć lepiej (mój case: ChatGPT-3.5 wskazał mi bibliotekę, której nie znałem, zamiast pisać od podstaw)
  c) “Debt is good”. Krótkoterminowa efektywność zorientowana na teraz, a nie na elegancję czy “dług techniczny” przy założeniu, że w następnej iteracji możemy przepisać wszystko uwzględniając lessons learned (to pułapka, ale koszt długu technicznego trzeba pewnie traktować inaczej, jeśli spada koszt produkcji).
  d) Adhoc. "przepisz mi na cokolwiek innego, żeby zadziałało x10 szybciej" (nie znam Go czy Rust ale jak skrypt przepisany z Pythona działa szybciej to tyle mi wystarczy na ten moment)

• Początek Eldorado cz.1 Jevons paradox. Nie kupuję tych wizji “że pora przebranżowić się z IT, programiści nie będą potrzebni” (więcej tu sensacjoznimu i chyba odwetowości względem uprzywilejowanej klasy, o czym pisałem w czerwcowym O pogardzie dla humanistów).
  
  Cały czas stoję na stanowisku, że odwrotnie: LLMy tylko zwiększą zapotrzebowanie na programistów/programistki, a rozwiązania typu Copilot czy Cursor doprowadzą do klasycznego paradoksu Jevonsa i będą tym czym Shopify dla e-commerce: : zwiększona wydajność może skutkować szybszym wykorzystaniem zasobów i wzrostem zapotrzebowania.
  
  Anegdotycznie: z osób, która zobaczy, że “da się stronę wygenerować” tak prosto jakieś 10% samo podejmie się tego, 40% zleci to mając z tyłu głowy, że to teraz proste (“tańsze”), pozostałe 50% uzna “o, może warto pomyśleć o stronie internetowej”.

• Jeśli wydaje Ci się, że ChatGPT jest mainstreamem to pamiętaj, że to zaledwie 180 mln użytkowników (wrzesień) z 5.45 mld użytkowników Internetu globalnie.
  
  Czyli 3.3%.
  
  Jeśli potrafisz na codzień korzystać z tych narzędzi jesteś w góra 4%, więc nie ulegaj bańce poznawczej.
  
  połowa globalnego systemu finansowego stoi na Excelu, wciąż większość ludzi nie wychodzi poza funkcję SUM. Na Wordpressie stoi pewnie z 1/3 Internetu, większość i tak zatrudnia kogoś do postawienia na nim strony.

• Początek Eldorado cz. 2: paradoks otwartej bramy / Access-Expectation Dilemma i efekt Św. Mateusza? Dziś zaklepanie microSaaSa wymaga YouTube'a, Cursora/Copilota i Claude/ChatGPT, ale dostęp do nowych możliwości powoduje jednoczesne zwiększenie standardów i wymagań - sprzężenie obniżenia bariery i podniesienia poprzeczki.
  
  Wracamy więc do dyskusji o developerach 100k robiących pracę 10 devów, przez co seniorzy będą odciążeni z pracy nad bzdurami (“teraz sobie to sam zrób, a mi zostaw trudne rzeczy”). Dobrzy devowie staną się jeszcze lepsi, słabych zastąpi prompting, juniorzy znów wrócą do łask, tylko wymagania pójdą w górę.

• Powrót akademii, episteme vs. techne. Postawienie prostej aplikacji nie wymaga już studiów informatycznych (tak jak czytanie Cycerona studiów w Padwie), ale żeby zabrać się za deeptechowe tematy trzeba już akademików. Mam wrażenie, że ta narracja “rzuć studia i idź do pracy” będzie się trochę osłabiać, gdy low hanging fruits zostaną już zebrane i wiele niskich barier obniżonych.
  
  Może to znów pokazuje klasyczną różnice między nauką (scientia, episteme) vs. technologią (ars, techne): "zaklepanie twierdzenia Pitagorasa w Pythonie to sekunda, opracowanie tego twierdzenia to inna para kaloszy".
  
  

  🗒 7 notatek o deep knowledge, Picasso, fermentacji i zemście normików

  

• Nihil novi i AI vs. comparative advantage. Czy łatwość z jaką LLMy generują kod, czy Replit umożliwia szybki deployment to coś nowego? Myślę że podobnie mogło być, gdy weszły języki wysokopoziomowe ("to teraz mogę niemal w języku naturalnym pisać instrukcje zamiast kartek perforowanych?"), później Github i YouTube ("przecież tu jest wszystko opisane i open source"). Wciąż zlecamy tworzenie aplikacji, nawet więcej.
  
  Noah Smith dobrze to ujął w Plentiful, high-paying jobs in the age of AI w oparciu o zasadę przewagi komparatywnej: nawet jeśli AI będzie lepsze od ludzi we wszystkim, ludzie nadal będą mieli pracę, np. jeśli godzina pracy AI jako lekarza jest warta 2000 zł, ale godzina pracy AI przy projektowaniu chipów jest warta 5000 zł, to opłacalne będzie zatrudnienie człowieka jako lekarza, nawet jeśli AI byłoby w tym lepsze, a AI przeznaczyć do projektowania chipów.

• Hipoteza: long bet na Dev Tools. Powtórzę: modele LLM i rozpowszechnienie klucza API jako nowego numeru karty kredytowej czy narzędzia jak Cursor tak zmniejszyły barierę wejścia do programowania, że Total Addressable Market dla narzędzi deweloperskich może znacząco tu urosnąć - jeśli w latach 60. obsługa komputera i terminala wymagała stopnia inżynierskiego, to może niebawem na porządku dziennym będzie generowanie czy hostowanie sobie prostych aplikacji pisanych językiem naturalnym i kupowanie wtyczek do IDE.

• Jeśli sprawdzi się powyższe (“everyone is a dev one”), marketing będzie czerpał więcej z developer relations i B2Dev? (wracam tu do rozmowy z Dawidem Ostrowskim).

• Sukces Cursora pokazuje, że w dobie niskich kosztów produkcji stopniowo “UX is the king” i wciąż można zrobić wiele w dotychczasowo zabetonowanych obszarach (let’s be honest: Cursor to VSCode z dodatkowym okienkiem). Powoli przekonuje się, albo przestaje się śmiać z tych tagline’ów “SAP. Finally done well”.

• Long/short bet na AI code agents? Tu mam dylemat. Widząc jak działa Composer od Cursora czy Replit trochę sceptyczniej podchodzę do potencjału dedykowanych AI agents do generowania aplikacji (wciąż są trochę niedetrministyczne, potrafią zabłądzić), ale nie tyle idei, co czy nie będzie to skomodytyzowana wtyczka do takiego IDE? Nie wiem.

• Long/short bet na no code tools? Taki sam dylemat mam z narzędziami NoCode.

  • Myślę, że awersja do kodu (“to nie dla mnie, zbyt skomplikowane, chciałbym sobie wyklikać”) będzie wciąż silnym motywatorem czy unique selling point, ale ten hybrydyczny model sytuujący się między w pełni customizowalnym kodem a ograniczonym ale szybkim WYSIWYG (Wordpress, Shopify etc.) może się zawężać.

  • Jeśli mogę rozmawiać z dokumentacją API różnych aplikacji, integracja to pare promptów to pokusa postawienia własnej bazy w miejsce Airtable może być wyższa. Ale może być też odwrotnie, bo powiększy się TAM half-developers (“wiem wystarczająco, mógłbym sobie to zaklepać, ale zrobię w Make.com, zepnę Airtable i Webflow”) i popadam tu w kolejny błąd poznawczy jak słynny komentarz pod launchem Dropboxa:

    

    “Dropbox? Przecież to już można sobie zrobić w Linuxie”

• Drastycznie maleje moja tolerancja na “potrzebujemy 1 mln PLN na zbudowanie MVP”.

Miłej niedzieli,

Kamil Stanuch

---

PS. Jak oceniasz dzisiejszy mail? Zostaw komentarz lub “❤️”, jeśli podobał Ci się artykuł - zawsze cenię komentarze i insighty od Was, a daje to też lepszą pozycję w sieci Substack. Możesz też anonimowo dać ocenę poniżej - krytyczne oceny są dla mnie bardzo ważne i pozwalają mi poprawić warsztat.

👎  😐  🙂  👍  🤯