Vibe-scribing

Świat IT oszalał na punkcie agentów, którzy „sami” piszą kod. Teoria jest prosta – rolą programisty, a raczej vibe-codera, jest spisanie specyfikacji i nadzorowanie, czy AI generuje programy spełniające oczekiwania. To od jakości specyfikacji oraz nanoszonych na bieżąco zmian zależy, czy agenci wyprodukują pożądany efekt. Czas vibe-codera schodzi więc na uważnym śledzeniu zarówno założeń, jak i wyniku końcowego.

Widzę w tym mnóstwo analogii do tworzenia dokumentacji medycznej. To, jak różne są oczekiwania lekarzy co do generowanych dla nich pism – niezależnie od tego, czy użyjemy „najmądrzejszego” LLM-a, czy deterministycznej checklisty – sprawia, że wdrożenie asystenta lekarza to taki właśnie vibe-scribing. Jak zebrać oczekiwania medyka? Jak zweryfikować po wdrożeniu, czy dokumenty dokładnie na nie odpowiadają? Mamy na to swoje sposoby, ale to temat na oddzielny post.

Najbardziej problematyczne są dla nas sytuacje, w których brak kontaktu z użytkownikiem uniemożliwia nawet zebranie takich wymagań. 

Brakuje mi w medycynie tego, do czego w IT jesteśmy przyzwyczajeni – dopytywania „o co dokładnie chodzi z daną rzeczą?” i „po co ona właściwie jest?”. Wielokrotnie spotkaliśmy się z tym, że neutralne pytanie o to, co lekarz miał na myśli w swoim szablonie, kończyło się urażeniem czyjegoś ego. Każda próba doprecyzowania bywa odbierana jako audyt umiejętności, a nam chodzi przecież tylko o lepsze poznanie potrzeb, by móc na nie odpowiedzieć.

Design thinking czy wywiady to piękne narzędzia, ale wymagają chęci do dyskusji. Jeśli jej brakuje, pozostaje jedynie narzekanie na biurokrację i zastany stan rzeczy, a przecież bez zdefiniowania oczekiwań ani sztuczna, ani ludzka inteligencja nie jest w stanie zdziałać cudów.