Slop – acesta este termenul pe care îl auzim din ce în ce mai des când vorbim despre produsele AI. Ceva de calitate scăzută, dificil de controlat, creat non-stop în cantități alarmante cu un singur obiectiv: captura atenția, ucide timpul, genera hype. , amploarea căreia, împreună cu consecințele potențialului său izbucnire, rămâne de văzut. Bubble în industrie Toate acestea alimentează încă o dată dezbaterea despre adevărata eficacitate și pericolele AI. Dezvoltarea software-ului nu este o excepție.Cercetarea arată în mod convingător că stăpânirea instrumentelor AI nu este ușoară, iar fără abilitățile corespunzătoare, efectul utilizării acestora poate fi chiar mai mare. . negativă Cu toate acestea, AI poate fi extrem de util în dezvoltarea software-ului. Tot ce este nevoie este rigoare, consecvență, disciplină. 1. obțineți o anumită motivație Dezvoltarea software-ului nu s-a schimbat fundamental în decenii.Am rafinat metodologiile, am reinventat limbile de programare, metodele de livrare, observabilitatea, QA și așa mai departe.Dar am scris întotdeauna codul linie după linie, ca text, menținând controlul asupra a ceea ce scriem pe măsură ce mergem. Această epocă este Indiferent dacă ne place sau nu, codul va fi în curând generat în primul rând de modelele lingvistice. Aceasta este o schimbare masivă.Trebuie să schimbăm multe dintre obiceiurile noastre – literalmente să ne schimbăm profesia. peste 
 
 
 De fiecare dată când reușesc să obțin AI pentru a lucra eficient pentru mine, mă simt cu adevărat fericit. Este inevitabil. Un punct destul de dur, dar unul dintre cele mai importante. Trebuie să vezi realitatea și să o poți accepta calm. Dezvoltarea alimentată de IA este reală chiar acum și va deveni forma dominantă în viitor. devine o cerință de muncă.Un bun exemplu este acest standard de angajare de la : Zăpezii Verificarea dacă aveți motivația potrivită este simplă - observați-vă emoțiile atunci când apar noi versiuni LLM și produse AI pentru dezvoltarea software-ului. Dacă, în loc de bucurie și curiozitate, simți anxietate, ar putea însemna că nu te-ai adaptat suficient la noile instrumente. Utilizați-l pentru a vă împinge să învățați noile instrumente.Relieful pe care îl simțiți atunci când acea anxietate se dizolvă devine un alt motiv puternic pentru a continua. productivă 2 Izolarea Din acest moment, toate elementele din lista de verificare vor fi conectate într-un fel la Abordarea aici este simplă - cu cât sunt mai concise, specifice și detaliate instrucțiunile pe care le primește LLM, cu atât este mai bună calitatea rezultatului. Inginerie contextuală Specificitatea contextului se realizează prin organizarea corespunzătoare a bazei de coduri - descompunerea lucrurilor în module independente, izolate, cu o răspundere limitată. Cea mai ușoară modalitate de a organiza astfel de module este în monorepos. Astăzi, nu este nevoie de mult pentru a crea un repository multilingv cuprinzător pentru întregul proiect. Începeți prin identificarea entităților de bază - aplicații implementabile și "pachete" partajate cu cod utilitar. Regulile sunt simple - aplicațiile ar trebui să depindă de pachete, iar pachetele pot depinde una de cealaltă, dar pachetele nu pot depinde de aplicații. Iată o structură de exemplu pe care o puteți utiliza. se potrivește majorității cazurilor: root/
├── applications/
│   ├── website/
│   ├── public-api/
│   ├── admin-dashboard/
│   └── ...
│
├── packages/
│   ├── js/
│   │   ├── ui/
│   │   ├── client/
│   │   ├── validation/
│   │   └── ...
│   │
│   ├── py/
│   │   ├── common-lib/
│   │   ├── models/
│   │   ├── auth/
│   │   └── ...
│   │
│   └── go/
│       ├── common/
│       ├── clients/
│       └── ...
└── Makefile
 Makefile va acționa ca un punct de intrare pentru tot ceea ce permite orchestrarea script-ului agnostic. Pentru JS, pnpm sa dovedit a fi cea mai bună alegere - astăzi aș alege peste npm și sârmă. Acest tip de monorepo este o structură foarte convenabilă, flexibilă și extensibilă. Și funcționează foarte bine cu agenții AI. Dezvoltarea unui pachet este simplă deoarece codul este strict izolat și servește unei funcții specifice. Când lucrați cu cod în aplicații, puteți: 
 
 
 
 Identificați în avans toate pachetele externe afectate Faceți modificări pas cu pas, modificând mai întâi pachetele, apoi stratul de aplicație real Corectați erorile în izolare, pas cu pas, într-o buclă de feedback. Instalați Feedback Loop Calitatea codului generat de AI se îmbunătățește dramatic atunci când agentul AI poate rula teste, lantere și poate utiliza ieșirea din aceste instrumente pentru a ajusta rezultatul în timpul procesului de lucru. Într-o lume ideală, cea mai bună soluție ar fi de a oferi AI acces la un mediu de execuție a codului – pentru proiecte web, adică browsere. . Fără soluții pregătite Acestea fiind spuse, chiar și testele de bază și de unitate sunt instrumente excelente pentru controlul calității și reducerea halucinațiilor. Mai ales că setarea verificărilor de cod static într-un monorepo este destul de ieftină. În timp ce unele instrumente AI (cum ar fi Cursor) rulează linters automat, totuși are sens să instruiți în mod explicit LLM pentru a rula verificări. De exemplu, o promptă ar putea arăta astfel: Update packages/js/api-client:

Add getUserProfile(userId) method:
- GET /users/{userId}/profile
- Include tests for success and 404 error

Run `make test-api-client` and fix any failures.
 Crearea unei bănci de memorie Memory-bank este un cadru care descrie cum să stocați și să gestionați două tipuri de entități: şi . Rules Documentation este destul de simplu - este produsul dvs. descris din diferite perspective: produs, arhitectură și niveluri de componente. Există o mulțime de articole online despre scrierea unei bune documentații tehnice. Ceea ce contează pentru noi este că cu cât documentația este mai granulară și cu cât se află mai aproape de cod, cu atât este mai ușor pentru un agent să o acceseze. Documentation Punctul de intrare standard pentru agenții AI este fișierul AGENTS.md. Acest fișier ar trebui să descrie structura generală și scopul proiectului și să furnizeze legături către alte fișiere de documentare. O setare monorepo face convenabilă organizarea documentației în cadrul modulelor specifice, menținând, de asemenea, o bancă de memorie la nivel de rădăcină. Iată cum ar putea arăta o structură de fișiere de memorie-bancă: monorepo/
├── memory-bank/                          # Shared across entire repo
│   ├── AGENTS.md                         # Root entry point
│   ├── monorepo-conventions.md           # Overall structure & rules
│   ├── shared-tech-stack.md              # Common technologies used
│   ├── development-workflow.md           # Git, CI/CD, deployment
│   └── architecture-overview.md          # High-level system design
│
├── applications/
│   ├── website/
│   │   ├── memory-bank/
│   │   │   ├── AGENTS.md                 # References root + specific context
│   │   │   ├── product-overview.md       # What this app does
│   │   │   ├── user-journeys.md          # Key user flows
│   │   │   ├── tech-stack.md             # Specific technologies
│   │   │   ├── api-integration.md        # How it connects to APIs
│   │   │   └── tasks.md                  # Current work items
│   │   └── src/
 sunt un concept relativ nou și, în opinia mea, una dintre cele mai productive idei pentru reutilizarea îndemnurilor.Reguli sunt codificarea liniilor directoare scrise în limbaj natural - în esență o combinație de şi Abordarea editorului Cursor cu privire la reguli pare deosebit de puternică, deoarece vă permite să atașați reguli la fișiere specifice folosind modele glob. Acest lucru „importă” automat regulile relevante în context atunci când lucrați cu diferite părți ale depozitului.Puteți defini regulile pentru Acțiunile TypeScript, Supabase sau GitHub o dată, apoi le puteți reutiliza pe parcursul proiectelor. Rules contribution.md .eslintrc Regulile sunt întotdeauna globale și universale.Cea mai bună practică este să le stocați în rădăcina depozitului - asta este ceea ce se așteaptă editorii de cod. Problema „paginii goale” atât pentru Documentație, cât și pentru Reguli este ușor de evitat.Documentația poate fi generată de AI cu o simplă invitație și apoi editată. , , . Unul două trei Deci, fiecare sesiune cu un agent AI începe cu citirea băncii de memorie și se termină cu actualizarea acesteia. Aflați pipeline-ul „Plan → Act” Abordarea Plan → Act este probabil cea mai mare schimbare în modul în care lucrăm cu asistenții AI și este într-adevăr singura modalitate fiabilă de a aborda sarcini complexe și la scară largă. Mulți asistenți de codificare AI au acest lucru încorporat în afara cutiei. Cursor, de exemplu, planifică automat execuția sarcinii fără a necesita instrucțiuni suplimentare. Abordarea se bazează pe principiul 90/10: fiți pregătiți să vă petreceți 90% din timpul de planificare și doar 10% pe implementare. Planificarea produce artefacte specifice – sarcini. Cu cât sarcinile dvs. sunt mai detaliate, mai detaliate și mai coerente, cu atât rezultatele vor fi mai bune. Fluxul de lucru tipic Plan → Act arată astfel: Planul 
 
 
 
 
 
 
 Pregătirea contextului. colectarea documentelor necesare din banca de memorie Descrierea contextului de afaceri. În esență, o călătorie a utilizatorului pentru caracteristică Descrierea specificațiilor tehnice - ceea ce trebuie implementat Descrierea procesului QA - care scripturi pentru a rula pentru testare, care teste pentru a adăuga Crearea fișierului tasks.md Iterarea prin fișierul tasks.md, clarificări, corecții, rafinări Actul 
 
 
 
 
 
 
 Deschiderea unei noi sesiuni (chat, tab) Începerea implementării. pas cu pas, secvențial Verificarea rezultatelor vizual și cu teste la fiecare pas. Rafinarea buclei de feedback, adăugarea acoperirii testelor Actualizarea documentelor Ștergerea fișierului tasks.md două Pentru utilizarea acestui gazoduct: important tips 
 
 
 Întotdeauna separați Planul și Acțiunea în sesiuni diferite. Este convenabil, plus îmbunătățește stabilitatea și economisește pe jetoane Dacă agentul produce rezultate incorecte, nu complicați lucrurile cu instrucțiuni suplimentare - reveniți la etapa Plan, perfecționați task.md, memoria și regulile. Stăpânirea Planului → Acțiunea nu este doar despre alfabetizarea AI. Este o abilitate importantă, chiar critică, de inginerie. În principiu, un Plan bun este un document de proiectare gata făcut - îl puteți discuta cu conducerea echipei sau cu echipa, aliniați-l înainte de implementare într-o relație publică și utilizați-l ca bază pentru documentație și stratul de testare. Plug-in agent de cloud Există atât de multe instrumente diferite pe piață și nu am vrut să mă concentrez pe niciun instrument specific, dar să desprindem cel puțin cele două tipuri principale: agenți locali (cum ar fi Claude Code, Cursor și Codex CLI) și cei pe bază de cloud (cum ar fi Codex Cloud, Jules sau noul ) din Codul lui Claude pe WEB Fie că este vorba de un editor de cod alimentat de IA sau de un instrument CLI, cele mai multe sarcini de lucru zilnice sunt pur și simplu mai ușor și mai eficient de gestionat în acest fel. Dar instrumentele bazate pe cloud au propriul lor punct dulce. Principalul lor lucru este că toată interacțiunea are loc printr-un browser - nu aveți nevoie de un mediu de dezvoltare sau de un proiect implementat local. Acesta este motivul pentru care acestea sunt perfecte pentru aceste cazuri de utilizare: 
 
 
 
 Orice analiză a bazei de coduri, estimarea timpului de implementare, evaluarea dificultăților potențiale sau crearea unui plan de lucru (task.md). Acest tip de analiză este un mare ajutor înainte de a începe lucrul la o sarcină mare.Veți înțelege imediat ce părți ale planului pot fi implementate împreună cu AI, ceea ce va reduce timpul de implementare și mai mult. Refactorizarea pe scară largă, dar repetitivă, care nu necesită supraveghere strânsă. Principalul lucru este să pregătiți mai întâi testele (vezi check #3). Modificări non-critice direcționate, ocolind echipa de dezvoltare. În loc să creați o sarcină în trackerul de activități, PO sau Designer cu acces Codex poate scrie o invitație pentru agentul cloud. Apoi revizuiți rezultatele mai târziu. Sarcina perfectă este una care se rezolvă singură, și chiar mai bine, un proces pentru rezolvarea sarcinilor similare. 7 Împărtășirea Poate că cea mai dificilă parte a codificării AI este munca în echipă. Cum împărtășești cele mai bune practici? Ar trebui să standardizezi fluxurile de lucru între colegii de echipă și toată lumea trebuie să folosească același set de instrumente? Asistentele AI ridică, de asemenea, o mulțime de întrebări foarte specifice: cum gestionați banca de memorie și cine ar trebui să fie responsabil pentru menținerea acesteia la zi? Furnizorii de AI încearcă să abordeze această nevoie într-un fel sau altul, dar nu există soluții gata făcute. Din experiența mea, cea mai bună modalitate de a răspândi cunoștințele este prin forumuri orizontale deschise.Dacă aveți deja întâlniri regulate cu dezvoltatorii pentru a împărtăși practicile, pentru a discuta despre știri și pentru a transmite experiență, faceți din adoptarea AI o temă importantă la aceste întâlniri.Dacă nu aveți încă un astfel de forum, poate că are sens să creați unul sau să susțineți adoptarea AI pe orice platformă este disponibilă.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Acest audio este produs în limba originală a poveștii!

Începeți să codificați mai inteligent cu AI

About Author

COMENTARII

Etichete suspendate

ACEST ARTICOL A FOST PREZENTAT IN

Related Stories

The World is Finally Ready for a New Internet

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/3/2024)

The Robots Are Taking Over

How Soon Can Google Investors Make Bank?

The World is Finally Ready for a New Internet

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/3/2024)

The Robots Are Taking Over

How Soon Can Google Investors Make Bank?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps