Trebuie să vă mărturisesc ceva: sunt parte a problemei. Am scris articole despre cum să construim skilluri IA, am ținut prezentări despre diferența dintre agenți și skilluri, despre MCP, despre pluginuri. Internetul este plin de astfel de conținut, iar o parte din acesta este al meu. Am devenit foarte buni în a răspunde la întrebarea "Cum să construiesc un tool IA customizat?" Dar nu am răspuns la întrebarea care contează cu adevărat: "Ar trebui să fac lucrul acesta?"
Azi, doresc să vă conving că, în majoritatea cazurilor, nu ar trebui să o faceți. Cele mai bune explicații se dau prin exemple și prin imagini. Să le încercăm pe ambele.
Să zicem că echipa ta are un anume fel de a scrie user stories. Nu doar "Ca utilizator, eu vreau, astfel încât". Un template specific: situație curentă, situație țintă, abordare tehnică, scenarii, criterii de acceptabilitate. Vă sună cunoscut ? Sunt convins de acest lucru. În mod firesc, vă doriți ca toată această muncă să fie făcută de IA-ul vostru preferat, să zicem Claude.
Primul impuls: scrie un skill. Are nevoie de o descriere, de instrucțiuni, de headere în template, dar și de o cale de a se conecta la Jira. Optezi pentru acces direct la API: nu ai nevoie de MCP, ești purist. Deci: ceva cod, credențiale stocate, gestionare de erori. Ai construit soluția și funcționează. Ai scris chiar și un README.
Acum vreți să popularizați soluția la nivel de echipă. Aflați că este mai greu să convingeți oamenii decât să construiți soluția în sine. Unii se împotrivesc. În mintea voastră, îi catalogați drept ignoranți și mergeți mai departe. În scenă intră bugurile: formatarea este groaznică, tabelele nu se randează corespunzător și ați uitat criteriile de acceptabilitate live într-un câmp special. Subit, ați început să faceți calluri API pe care skillul vostru nu le-a specificat niciodată.
De acord! Simplificăm. L-ați auzit la un moment dat pe tipul acesta, Alex P., care a declarat că cea mai bună zi din viața unui programator este aceea în care lasă în repository mai puțin cod decât atunci când a început. Puneți deoparte codul API și treceți pe MCP. Poate a fost o idee bună, în cele din urmă Release v2: toți reconfigurăm. Canalul echipei este plin de comentarii.
Să ne oprim aici. Am putea continua la nesfârșit și să punem întrebarea pe care am ratat-o: Chiar avem nevoie de acest skill? Care este lucrul de care avem nevoie? Un template customizat. Conectivitate la Jira pe care serverul MCP o oferă deja. O singură instrucțiune. Prin urmare, de ce să nu scriem o singură instrucțiune în CLAUDE.md, o bucată de memorie, o regulă, oricum s-ar numi în toolul vostru: Când creezi Jira stories, folosește template-ul din templates/story.md. Finalizat. Fără a face release, fără campanie de adopție, fără buguri, cu mai puțin context consumat. Este magic!
Un exemplu mai amplu! Am observat că multe persoane își construiesc agenți care să revizuiască, să scrie cod, să planifice. Aș dori să critic constructiv această practică. Care este strategia ta de testare legată de acești agenți? Cum îți dai seama dacă agentul care revizuiește chiar identifică greșeli? Cum abordezi holistic și strategic un astfel de agent? Cum îți optimizezi folosirea tokenilor? Cum te asiguri că regulile sunt bune și complete? Vor cădea colegii tăi la picioarele tale pentru că l-ai rugat pe Claude să îți scrie un plugin?
Frameworkuri de workflow-uri agentice - perspectivă comparativă
Aceasta nu este o problemă de IA. Este cea mai veche problemă din software: orice bucată de cod customizat, că este vorba de un agent, un plugin, o librărie sau un pipeline vine cu un preț. Mai multe lucruri de întreținut, mai multe buguri fără timp de a le fixa, mai puțin timp pentru a fixa problemele de business pe care ești plătit să le rezolvi. Iar undeva la capătul holului, poate ai un coleg care construiește același lucru și care este foarte bucuros să explice de ce varianta construită de el este mai bună.
Răspunsul rămâne același ca întotdeauna: folosește ceea ce există. Ceva ce are o comunitate, suport și îmbunătățiri aduse zilnic. Să ne uităm la Superpowers: este open source, în marketplace-ul de pluginuri ale Anthropic, întreținut activ, cu dezvoltare pe bază de teste și cu workflow-uri de review care vin la pachet cu acesta. De ce am vrea să construim o versiune mai proastă a acestuia? Corporația la care lucrați s-ar putea să fie dispusă să plătească 10 dolari pentru varianta comercială. Dacă faceți dezvoltare pe bază de specificații, imaginea de mai jos oferă o comparație între frameworkurile mari de pe piață.
Mâinile vă transpiră, genunchii vă sunt moi și brațele vă sunt grele. Aveți scris deja pe jumătate un SKILL.md în repository. Știu, și la mine e la fel, dar fă ce îți spune preotul, nu ce face el. Să reținem trei situații:
Lucruri care nu există. Frameworkul pe care este construit proiectul vostru (nu vă voi întreba cum ați făcut alegerea), API-ul intern de care nu a mai auzit nimeni din afara companiei.
Skilluri efemere, o cale de mijloc ce merită împrumutată. Creați un skill pentru un task specific, lăsați-l să își facă treaba și ulterior ștergeți-l. O migrare de date, o refactorizare la grămadă, un raport pe care nimeni nu îl va cere a doua oară. Toate beneficiile unor instrucțiuni clare, fără efort și dependențe: fără README, fără campanie de adopție, fără v2. Toate lucrurile de care m-am plâns se aplică skillurilor pe care intenționați să le păstrați.
În caz că nu ați observat: Claude Code sau oricare alt agent nu are memorie. Deși pe internet ni se spune că are. Dar vă rog să mă credeți, nu are. Tot ce planează în jurul "memoriei" este sintetic: fiecare sesiune nouă reîncarcă fișierele CLAUDE.md, memoria și descrierea skillurilor într-o fereastră contextuală finită. O nouă sesiune arde 12,000 de tokeni înainte de a scrie un singur cuvânt, iar asta înaintea acelor trei server MCP, a celor 10 skilluri pe care le-ați construit sau a celor 7 pe care le-ați instalat și de care ați uitat.
Așadar, puneți accent pe managementul contextului: când încep o nouă sesiune, cum ajunge acolo informația corectă? Dacă nu faceți nimic, agentul vă redescoperă codebase-ul de fiecare dată. Workflow-urile voastre, businessul, prioritățile, stackul tehnic, ADR-urile, principiile arhitecturii voastre, toate împrăștiate pe sute de pagini de Confluence, jumătate dintre ele învechite. A transforma toate aceste date în context structurat, ușor de încărcat merită mai mult decât orice skill pe care l-ați scrie vreodată.
Ce s-a întâmplat cu contextul meu? Startul unei sesiuni brute (uncurated) vs. organizate (curated)
Dacă IA nu poate face ce faceți voi, nu aveți nevoie de IA. Dar, presupunând că poate face ce faceți voi, atunci clonați-vă, replicați-vă. Tu ești programatorul pe care l-ai angaja. Fă copii: minioni care fac ceea ce faci tu cel mai bine, doar că mai repede, mai constant și, ce este mai important, în paralel. Mecanismul pe care trebuie să îl învățați este git worktrees: fiecare agent primește copia de lucru a repository-ului, deci unul fixează un bug, în timp ce altul scrie un story, în timp ce al treilea refactorizează. Munca voastră se schimbă: de la editare se trece la revizuire și orchestrare, exact unde dorești să te afli.
Mai mult, dacă atingi acest nivel mai repede decât curba de adopție a companiei în care lucrezi, vei avea mai mult timp la dispoziție: sport la sală, PS5, orice vă doriți. Ține minte: peste un an, aceasta nu va mai fi o etapă de explorare, ci o cerință obligatorie la nivel de companie. Pregătește-te cât poți de bine și bucură-te de avantajul pe care îl ai.
Bonus! Următorul skill de succes nu va fi un fișier creat în .claude/skills. Va fi *multitaskingul: a rula mai mulți agenți deodată, fără a scăpa niciunul din vedere. Stereotipurile există din motive bine întemeiate: suntem notoriu de nepricepuți la multitasking. E timpul să evoluăm. Poate este vorba de un task de development și de încă un slide. Poate este vorba de un refinement, un story și un bugfix*. Identificați punctul de echilibru, folosiți-l în avantajul vostru, creșteți.
Am menționat "Claude" de multe ori, dar, poate, voi folosiți Copilot. Nu vă faceți griji. Dacă citiți despre Claude ca fiind "agentic", iar despre Copilot ca fiind "doar autocomplete", acest fapt este datorat unei strategii proaste de marketing. Din punctul de vedere al capabilităților, sunt remarcabil de similar. Diferența este rareori unealta, ci modul în care această unealtă este folosită.
Prin urmare, data viitoare când simțiți nevoia să construiți un agent customizat, un plugin sau un skill, întrebați-vă mai întâi "Ar trebui să fac lucrul acesta?" înainte de a vă întreba "Cum ar trebui să fac lucrul acesta?". În cele mai multe cazuri, răspunsul cel mai cinstit este că aveți nevoie de o linie de instrucțiuni, un plugin existent sau un context mai bine organizat. Cea mai bună zi a voastră trebuie să fie cea în care lăsați mai puțin cod în repository decât atunci când ați început, incluzând aici și instrumentele IA.
De la Vibe Coding la Production Engineering
Marți, 30 iunie, ora 18:00
Cognizant (Timișoara)
Facebook Meetup StreamEvent YouTubede Luiza Mihu
de Cosmin Sandu
de Andreea Roșu
