Narcis Miclaus

8 min de citit

Python, de la zero Lecția 23 / 60

Dezvoltare Python asistata de AI: workflow-ul care merge

Unde Copilot/Claude/Cursor ajuta cu adevarat, unde fac rau si pattern-urile de prompt care produc cod pe care il poti livra.

În 2026, asistenții AI sunt parte normală din lanțul de unelte Python. Copilot e în editor, Claude e la o tastă distanță în Cursor, Aider trăiește în terminal, Codex are propriul CLI, Continue se conectează la VS Code și JetBrains deopotrivă. Să te prefaci că nu există e o taxă pe productivitate. Să-i tratezi ca pe oracole e o taxă pe calitate. Întrebarea interesantă e cea de la mijloc: unde îți întorc timpul pe care-l investești în prompting și unde te costă mai mult decât economisesc.

Lecția asta e workflow-ul la care am ajuns. Cinci categorii de ajutor care chiar funcționează, modurile de eșec care mușcă și pattern-urile de prompt care transformă un asistent AI dintr-o mașină de ghicit într-un junior pair competent.

Cinci categorii unde asistenții AI își câștigă pâinea

1. Generarea de boilerplate

Asta e cea sigură. Orice e structural, repetitiv și urmează un șablon, AI o face aproape perfect:

  • Un schelet de CLI click sau typer dintr-o descriere de o singură linie.
  • Un @dataclass dintr-un eșantion JSON.
  • Un tabel pytest.mark.parametrize din „uite șase cazuri”.
  • Stub-uri de teste dintr-o semnătură de funcție.
  • Un schelet de pyproject.toml.

Un exemplu real. Lipești un blob JSON și spui „dataclass pentru asta, frozen, cu slots”:

from dataclasses import dataclass

@dataclass(frozen=True, slots=True)
class Customer:
    id: int
    name: str
    email: str
    signup_date: str
    is_active: bool

Asta e treizeci de secunde economisite, de douăzeci de ori pe zi. Categoria e largă: oricând tastezi ceva a cărui formă tastatura o știe deja, un asistent AI o va tasta mai rapid decât tine și rareori greșește.

2. Reamintirea de API-uri

„Cum folosesc resample din Pandas ca să grupez săptămânal începând de luni?” Asta însemna înainte un tab spre docs și trei minute de scanat. Acum e o întrebare și un răspuns cu un bloc de cod care funcționează:

import pandas as pd

weekly = df.resample("W-MON", on="ts", label="left").sum()

Pentru biblioteci mainstream (pandas, numpy, requests, sqlalchemy, fastapi, polars), reamintirea AI e mai rapidă și mai focusată decât căutarea în docs. Avertismentul: e calibrată pentru cazul comun. Pentru API-uri obscure, biblioteci de nișă sau orice lansat în ultimele șase luni, fabrică încrezător. Verifică rulând codul, nu citindu-l.

3. Propuneri de refactor

Cursor și Aider strălucesc aici, pentru că au întreg fișierul (sau repo-ul) în scop. „Redenumește process în process_invoice peste tot unde se referă la fluxul de facturi, lăsând în pace process-ul nelegat din payments.py.” Asta e o muncă manuală de cinci minute, șaizeci de secunde cu o unealtă care poate citi toate call site-urile.

Refactor-ele mai mari („împarte clasa asta de 300 de linii în trei mai mici”) cer mai multă supraveghere, dar AI e excelent la partea mecanică: extragerea metodelor, înșiruirea parametrilor, actualizarea import-urilor. Tu oferi decizia arhitecturală; el face tastatul.

4. Code review

Surprinzător de bun. Lipești o funcție și întrebi „are probleme?” și rutinier primești înapoi:

  • Erori de off-by-one în slicing.
  • Nepotriviri de tipuri pe care linter-ul le-a ratat.
  • Argumente default mutabile.
  • Lipsa de tratare a excepțiilor pe un apel cunoscut ca instabil.
  • „Regex-ul ăsta are catastrophic backtracking pe input X.”

Nu înlocuiește un reviewer uman, nu cunoaște regulile tale de business, bugetul tău de performanță sau domeniul, dar pentru stratul mecanic al review-ului, AI e o pereche solidă de ochi în plus. Acum îmi trec propriile pull request-uri prin Claude înainte să le postez și rutinier repar două-trei lucruri înainte ca vreun om să vadă diff-ul.

5. Explicație

„De ce e asta lent?” „Ce face acest regex match?” „Ce face __init_subclass__ ăsta?” Pentru cod moștenit sau biblioteci nefamiliare, explicația unui asistent AI e de obicei corectă, completă și mai rapidă decât citirea sursei. Pentru onboarding într-un codebase nou, e transformatoare.

Avertismentul e același cu al categoriei 2: verifică. Explicația care sună corect și cea care e corectă sunt evenimente diferite.

Unde fac rău asistenții AI

Daunele sunt reale și merită numite explicit.

Cod plauzibil dar greșit pe teren nefamiliar. Când AI-ul nu știe răspunsul, n-o spune. Produce cod care compilează, arată idiomatic și e greșit într-un mod care îți ia mai mult timp de debug decât ți-ar fi luat să-l scrii singur. E cel mai dureros la biblioteci obscure, feature-uri recente de limbaj și orice unde datele de antrenare sunt subțiri.

Over-engineering. Cere o funcție care aduce un URL, primești înapoi o funcție cu retries, exponential backoff, un strat de cache, structured logging și un Protocol pentru clientul HTTP. Nimic din astea n-a fost cerut. Nimic, mai exact, nu e greșit, dar e zgomot pe care nu l-ai vrut și e mai lung de citit decât de scris.

Ignorarea convențiilor proiectului. Codebase-ul tău folosește httpx; AI-ul îți dă requests. Codebase-ul folosește loguru; AI-ul folosește logging. Echipa interzice try/except Exception; AI-ul le împrăștie generos. Fără context, AI-ul cade pe un stil generic „cod Python de pe internet”, nu pe stilul tău.

Sintaxă învechită pentru feature-uri mai noi. Asistenții AI produc adesea Optional[X] și List[int] în loc de X | None și list[int], pentru că datele lor de antrenare se sprijină pe stilul mai vechi. Produc from typing import Dict când nimic nu-l importă. Default-urile Python moderne trebuie impuse.

Capcana Tab-Tab-Tab. Cel mai mare mod de eșec din 2026 e oamenii care acceptă sugestiile AI fără să le citească. Autocomplete-ul e rapid, sugestiile arată corect, iar tu livrezi cod pe care nu l-ai citit niciodată. Așa ajungi cu bug-uri pe care nimeni din echipă nu le înțelege, pentru că nimeni din echipă nu le-a scris.

Workflow-ul care chiar funcționează

Câteva obiceiuri care transformă AI-ul din povară în atu.

Type-hint la tot. Sugestiile AI devin dramatic mai bune când există tipuri în scop. Modelul are mai mult cu ce lucra, sugestiile devin mai specifice, iar modul de eșec se mută de la „a inventat un atribut” la „a apelat metoda corectă”. E lucrul cu cea mai mare pârghie pe care-l poți face.

Arată-i AI-ului convențiile tale. Un scurt CONVENTIONS.md (sau STYLE.md, sau cum vrei tu) prins în contextul AI-ului îi spune ce bibliotecă de logging, ce client HTTP, ce pattern-uri de testare, ce stil de tratare a erorilor. Cursor și Aider îți permit amândouă să prinzi fișiere; Copilot ridică .github/copilot-instructions.md; Claude în Cursor citește CLAUDE.md. Petrece o oră pe fișierul ăsta o dată și fiecare prompt de după devine mai bun.

# Conventii

- HTTP: httpx, async by default.
- Logging: loguru, no f-strings in log messages, structured kwargs.
- Errors: domain exceptions in `errors.py`. No bare `except:`.
- Tests: pytest, parametrize over loops, fixtures in `conftest.py`.
- Style: ruff with our `pyproject.toml` config.

Revizuiește fiecare linie. Citește diff-ul. Faptul că nu l-ai tastat tu nu contează; tu îl livrezi. Schimbarea mentală e de la „autor” la „editor”, iar a edita înseamnă a citi efectiv.

Fixează asistentul pe pași mici. „Implementează tot feature-ul ăsta” produce un patch întins, greu de revizuit. „Implementează doar parserul” produce un diff focusat pe care îl poți citi într-un minut. Cu cât unitatea e mai mică, cu atât output-ul e mai bun.

Pattern-uri de prompt care funcționează

Câteva pattern-uri pe care le folosesc zilnic și cele la care am renunțat.

Pattern-uri care funcționează:

  • „Scrie un tabel pytest parametrize pentru aceste N cazuri.” Aproape întotdeauna perfect.
  • „Adaugă type hints la funcția asta.” Sigur, risc mic.
  • „Refactorează asta ca să folosească early returns.” Specific, mecanic, ușor de verificat.
  • „Explică ce face codul ăsta, linie cu linie.” Excelent pentru onboarding.
  • „Are bug-uri? Caută off-by-one, nepotriviri de tipuri și mutable defaults.” Prompt de review specific, mai bun decât „revizuiește asta”.
  • „Convertește acest unittest în pytest.” Mecanic, bine definit.

Pattern-uri care produc rezultate variabile:

  • „Scrie o funcție care face X.” Fără context, X e interpretat generos și rezultatul face over-engineering.
  • „Optimizează asta.” Optimizează pentru ce? Latență? Memorie? Lizibilitate?
  • „Fă-o mai Pythonic.” Vag. AI-ul ghicește, uneori bine, uneori adăugând abstractizări nedorite.

Pattern-uri de retras:

  • „Scrie tot modulul.” Vei petrece mai mult timp reparându-l decât scriindu-l.
  • „Generează teste pentru codul ăsta.” Tinde să producă teste care oglindesc implementarea, nu comportamentul. Mai bine: scrie tu numele testelor, cere AI-ului să umple corpurile.

Un ciclu real human-AI-review-ship

Un exemplu mic, real. Am o funcție pe care vreau s-o scriu: rotunjește un preț la cel mai apropiat ban, dar cu banker’s rounding.

Pornesc de la semnătură și un docstring:

def round_price(amount: float) -> float:
    """Round to the nearest cent using banker's rounding (round half to even)."""

Cer AI-ului să-l completeze. Produce:

from decimal import Decimal, ROUND_HALF_EVEN

def round_price(amount: float) -> float:
    """Round to the nearest cent using banker's rounding (round half to even)."""
    return float(Decimal(str(amount)).quantize(Decimal("0.01"), rounding=ROUND_HALF_EVEN))

Îl citesc. Conversia str(amount) e suspectă, ce-ar fi dacă amount e deja un Decimal? Dar semnătura e float, deci e ok. Aș prefera și să returnez Decimal în loc de float, dar semnătura zice float. Îl accept.

Apoi cer: „Scrie un tabel parametrize care acoperă: 1.005, 1.015, 1.025, -1.005, 0.0, numere mari.” Produce:

import pytest

@pytest.mark.parametrize("amount,expected", [
    (1.005, 1.00),
    (1.015, 1.02),
    (1.025, 1.02),
    (-1.005, -1.00),
    (0.0, 0.0),
    (1_000_000.555, 1_000_000.56),
])
def test_round_price(amount: float, expected: float) -> None:
    assert round_price(amount) == expected

Le rulez. Trec. Livrez.

Timp total: sub două minute. Scris de mână, asta ar fi fost zece minute de tastat și un mic ocol prin docs-ul decimal ca să-mi reamintesc numele constantei. AI-ul n-a făcut nimic ce nu aș fi putut face; a făcut lucruri pe care le-aș fi făcut, mai rapid.

Compromisurile uneltelor în 2026, pe scurt

  • Copilot: cel mai bun autocomplete inline, slab pe refactor multi-fișier. Implicit dacă trăiești în VS Code și nu vrei să te gândești la asta.
  • Cursor: fork de VS Code cu context la nivel de repo de prim rang și un panel de chat excelent. Merită schimbarea dacă vrei ca AI-ul să vadă mai mult de un fișier deodată.
  • Claude în Cursor / Continue: aceeași cochilie, model mai inteligent pentru sarcini mai grele. Combinația pe care o folosesc pentru refactor-uri non-triviale.
  • Aider: bazat pe terminal, conștient de git, face commits pentru tine. Excelent pentru refactor-uri în lot și workflow-uri headless.
  • Codex CLI: agentul de terminal al OpenAI, teritoriu similar cu Aider, cu ergonomie diferită.

Uneltele converg în timp; workflow-ul nu. Type-hint, documentează convențiile, revizuiește fiecare linie, prompt-uiește mic. Fă asta și oricare dintre ele funcționează. Sari peste astea și niciuna nu o face.

Caută