Toate drumurile au dus la Markdown
Un loop de startup-builder prin CEOgenerator, Framepath, governance în Paperclip, Paxlings și realizarea puțin incomodă că Build Right era, de fapt, harness-ul markdown.
Am lucrat dintotdeauna în startupuri. Rolul meu a fost adesea o variantă a aceluiași lucru: intru când lucrurile sunt dezordonate, construiesc fundații, descopăr părțile grele, fac sistemul mai puțin fragil și apoi îl țin așa.
Dar în paralel, adevăratul hustle a fost mereu să construiesc produse cool.
Grămada de idei
ADHD-ul dă întregului proces o textură foarte specifică. Nu mă chinui să găsesc idei. Asta ar fi convenabil. Vin prea multe, prea repede, și fiecare are destule detalii încât să pară, pentru scurt timp, inevitabilă.
Creierul meu e bun la primii 30%. Vede tipare, wedge-uri, sisteme, unelte lipsă, abstracții proaste, abstracții mai bune și uneori unealta care ar trebui să existe sub abstracția mai bună.
ideea 1 -.
ideea 2 -|
ideea 3 -+--> toate plauzibile
ideea 4 -| |
ideea 5 -' v
prototip de weekend
|
v
problema adiacentă mai interesantă
Partea enervantă este că ideile nu sunt, de obicei, proaste. Dacă ar fi evident stupide, aș putea închide tabul și aș merge mai departe. Dar tind să fie plauzibile. Uneori bune. Destul de bune pentru un weekend, apoi pentru un prototip.
Dar destul de repede, creierul meu găsește o problemă mai interesantă lângă problema inițială.
După ce am repetat asta de destule ori, am decis că problema reală nu era o anumită idee de startup. Aveam nevoie de un sistem care să-mi evalueze grămada de idei pentru mine: să cerceteze piața, să estimeze dificultatea de execuție, să compare impactul, potențialul de venit, distribuția, competiția și toate celelalte lucruri pe care știu că ar trebui să le fac.
Primul escape hatch
Așa că am început să construiesc CEOgenerator.
CEOgenerator trebuia să trieze ideile de startup înainte să investesc emoțional în ele. Nu să găsească product-market fit prin magie, ci să facă primul filtru mai puțin impulsiv: să strângă dovezi, să compare oportunități și să decidă ce ipoteze meritau testate în lumea reală.
Formulat mai onest, trebuia să mă protejeze de mine însumi, dar fără să-mi interzică să am idei.
prea multe idei de startup
|
v
CEOgenerator
|
v
cercetare de piață
dificultate de execuție
impact
potențial de venit
distribuție
urgență
competiție
|
v
"ce idee chiar merită construită?"
După ce, evident, rezolvasem totul în capul meu, următorul insight a fost că aveam nevoie de o fabrică de aplicații care să construiască lucruri pentru mine.
Îi spuneam lene, dar asta era doar pe jumătate adevărat. Impulsul mai puternic era leverage-ul: dacă puteam transforma munca repetitivă într-un sistem, puteam mișca mai repede fără să-mi târăsc atenția prin aceiași pași de setup de fiecare dată.
Așa că am coborât cu un nivel.
CEOgenerator răspunde:
"Ce ar trebui să construiesc?"
|
v
problema nouă:
"Cine construiește?"
|
v
fabrică de aplicații / sistem de execuție
Detour-ul prin control plane (Framepath)
Am început să construiesc ceea ce gândeam ca pe un control plane pentru workload-uri AI. Proiectul acela era Framepath.
Ideea era să coordonez munca AI mai fiabil: agenți guvernați, taskuri, scripturi, artifacte, pași de review și așa mai departe. Voiam ceva inspectabil, ceva care tratează execuția AI ca muncă reală, nu ca o secvență de mesaje trimise cu speranță.
munca AI, neguvernată:
prompt -> output -> speranță
prompt -> output -> speranță
prompt -> output -> speranță
munca AI, cu un control plane:
task
|
v
script / apel de model
|
v
artifact
|
v
pas de review
|
v
următoarea acțiune delimitată
Timp de aproximativ o lună, asta a parut corect. Nu era evident o distragere. Asta e problema cu detour-urile de genul asta: de obicei sunt defensibile. Fiecare abstracție rezolvă o limitare reală din stratul anterior.
Apoi am început să mă gandesc la lansare.
O lansare publica ar fi avut nevoie de poziționare, documentație, exemple, experimente de growth, conținut, poate comunitate, poate developer relations.
Framepath (control plane)
|
v
are nevoie de lansare
|
+--> poziționare
+--> documentație
+--> exemple
+--> experimente de growth
+--> conținut
+--> comunitate
+--> developer relations
|
v
"și asta este prea multă muncă manuală"
Asta nu mai era doar product engineering. Era munca în formă de companie din jurul produsului: să-l explici, să-l distribui, să-l dovedești, să-l susții și să păstrezi povestea coerentă în timp ce lucrul în sine încă se schimbă.
Din nou, instinctul de leverage a intrat în scenă. Următoarea concluzie a venit natural: aveam nevoie de agenți care să mă ajute să rulez compania din jurul lucrului.
Governance all the way down
Asta m-a dus la Paperclip.
Paperclip a fost încercarea mea de a face operațiunile unei companii executabile de agenți: research, planning, conținut, follow-up, review și muncă operațională recurentă din jurul unui produs. Era exact ce aveam nevoie. Problema era că agenții fără constrângeri își creează propria muncă. Fac lucruri, unele utile, unele plauzibile dar greșite, iar altele complete în sens îngust și inutile în sens larg.
Așa că am început să construiesc un strat de governance peste Paperclip.
Stratul de governance urma să definească roluri, rezultate, porți de review, issue templates, puncte de aprobare și configurația potrivită pentru taskuri. Nu voiam agenți care se plimbă prin proiect încercând să fie deștepți. Îi voiam în workflow-uri, producând artifacte pe care un om le poate verifica.
agenți Paperclip
|
v
strat de governance
|
+--> roluri
+--> rezultate
+--> porți de review
+--> issue templates
+--> puncte de aprobare
+--> configuratie de task
|
v
muncă delimitată
|
v
artifacte verificabile
Din nou, avea sens. Dacă agenții urmează să facă muncă reală, governance-ul contează.
Dar apoi a apărut următoarea problemă: să construiesc asta specific pentru Paperclip părea limitativ. Ideea utilă era mai generală. Voia să devină Paxlings: o platformă de AI workers mai extensibilă, mai pregătită pentru consumatori și inspirată de Paperclip.
Framepath, control plane-ul pentru AI, era infrastructura pentru coordonarea muncii. Paxlings, platforma de AI workers, era versiunea productizată: workeri reutilizabili, workflow-uri împachetate și un mod prin care altcineva să ruleze munca fără să înțeleagă mașinăria de dedesubt. Direcția era inspirată de aiworkers.so.
Așa că am început să mă mișc în direcția aceea. Până atunci, loop-ul era complet viu.
Pornisem cu prea multe idei de startup, construisem un sistem care să decidă pe care să o construiesc, am pus acel sistem deoparte, am început să construiesc Framepath ca un control plane pentru munca AI, am realizat că aveam nevoie de agenți care să mă ajute să lansez Framepath, am început să adaug governance agenților Paperclip, am realizat că governance-ul ar trebui să fie portabil și am început să-l transform în Paxlings.
Scris așa, sună nebunește. Din interior, s-a simțit ca un lanț de decizii rezonabile.
prea multe idei
|
v
CEOgenerator
|
v
are nevoie de execuție
|
v
Framepath (control plane)
|
v
are nevoie de suport pentru lansare
|
v
Paperclip / agenți de companie
|
v
agenții au nevoie de governance
|
v
governance portabil
|
v
Paxlings (AI workers)
Stratul markdown (Build Right)
La un moment dat mi-am dat seama că nu voiam, de fapt, să păzesc agenții pas cu pas. Voiam loop-uri rapide de execuție cu un harness real. Voiam să definesc un rezultat, să las modelul sau agentul să ruleze un proces delimitat, să producă artifactul potrivit, să se oprească la momentul potrivit și să-mi lase rezultatul pentru review.
Așa că am început să extrag părțile repetitive din propria mea muncă în repo skills și scripturi. Asta a devenit Build Right.
Build Right a venit din vechi project starters, scaffolds, interacțiuni cu agenți și workflow-uri de startup pe care le rulasem deja manual de prea multe ori: trierea ideilor, research de piață, cerințe de produs, împărțirea în GitHub issues, criterii de acceptare, planuri de lansare, checklisturi de review uman, loop-uri de critică.
vechi project starters -.
scaffolds -------------|
interacțiuni cu agenți +--> skill-uri Build Right
workflow-uri startup --|
procese manuale -------'
skill-uri Build Right:
triere idei
research de piață
cerințe de produs
împărțire în GitHub issues
criterii de acceptare
planuri de lansare
checklisturi de review uman
loop-uri de critică
etc
Apoi partea absurdă a devenit clară: skill-urile Build Right erau partea utilă din aproape fiecare strat pe care îl construiam.
Aveau ceva din ce voiam de la CEOgenerator, fără ca CEOgenerator să trebuiască să fie deja un produs complet. Aveau spiritul Framepath, control plane-ul, fără complexitate. Aveau governance-ul pe care îl voiam în jurul agenților, fără să mă lege de Paperclip. Aveau valoarea practică pe care o voiam de la Paxlings, fără să trebuiască să construiesc platforma mai întâi. Și erau în mare parte markdown.
După toată arhitectura, ajunsesem la instrucțiuni. Nu prompturi vagi de tipul "acționează ca un senior product manager" și speră că iese bine. Build Right era un set de repo skills în markdown, cu workflow-uri, inputuri, outputuri, constrângeri, puncte de review și definiții de done. Bucăți mici de judecată operațională scrise suficient de clar încât un model capabil să le poată urma și un om să le poată inspecta.
Un skill Build Right bun poate lua o idee vagă de produs și o poate transforma într-un task delimitat, criterii de acceptare, plan de verificare și checkpoint de review. Nu este o companie. Nu este o platformă. Dar este suficientă formă ca următoarea unitate de lucru să devină reală.
Cercul complet era aproape prea elegant.
Construiam skill-uri Build Right care puteau ajuta la construirea Paxlings, care putea ajuta la lansarea Framepath, care putea ajuta la construirea CEOgenerator, care putea să mă ajute să decid ce să construiesc, lucru pe care apoi îl puteam construi folosind aceleași skill-uri.
+-----------------------------+
| |
v |
skill-uri Build Right |
| |
v |
Paxlings (AI workers) |
| |
v |
Framepath (control plane) |
| |
v |
CEOgenerator |
| |
v |
decide ce să construiesc |
| |
v |
construiește lucrul ------------------+
La un moment dat, o diagramă de arhitectură devine o confesiune.
Produsul era harness-ul
Rezumatul ușor este că am complicat totul prea mult. Este parțial adevărat. Dar concluzia mai utilă este că am tot căutat produsul la stratul greșit. Lucrul de care aveam nevoie mai întâi nu era o platformă mai bună în jurul modelului: era un harness mai bun în jurul muncii.
LLM-urile de azi sunt deja suficient de bune pentru o cantitate surprinzătoare de muncă de product engineering dacă sunt folosite corect. Nu perfect, nu fără review, dar suficient de bune ca să urmeze instrucțiuni dacă sunt scrise bine.
Cum se leagă lucrurile
Modelul mai curat este acesta: Build Right este disciplina agentului, Framepath este control plane-ul repo-local, iar Paxlings este produsul pentru clienți. Build Right îi spune unui agent cum să lucreze: să ancoreze cererea, să separe dovezile de presupuneri, să planifice, să execute un singur task delimitat și să verifice. Framepath dă muncii acelui agent un mediu controlat: stare de repo, policy, adaptoare, validare, artifacte și traces. Paxlings este ce folosește clientul: AI workers delimitați pentru workflow-uri business, cu aprobări, control al side effect-urilor și auditabilitate.
De aceea proiectele acestea au continuat să pară legate fără să fie același lucru. Toate sunt răspunsuri la același failure mode: munca AI care pare completă pentru că modelul a spus că este, dar nu are scop explicit, autoritate, validare sau dovezi. Build Right atacă asta la stratul de metodă. Framepath o atacă la stratul de control plane. Paxlings o aplică la stratul de produs.
Greșeala ar fi să le colapsez. Build Right poate ajuta la construirea Paxlings fără să devină Paxlings. Framepath poate guverna munca în repo fără să fie SaaS-ul. Paxlings poate împrumuta aceleași principii fără să devină un framework general pentru agenți. Firul comun nu este un produs care le înghite pe celelalte; este aceeași convingere operațională care apare la trei straturi diferite.
Spune-mi ce părere ai.