Dlaczego NIE warto delegować kodowania agentom AI - devszczepaniak.pl

AI trzeba pilnować i regularnie recenzować. Inaczej baza kodu przestaje być zrozumiała i uzywalna.

Na razie staram się zawsze czytać ze zrozumieniem. Wymagam też od AI komentarzy planistycznych (w sensie: robię X bo Y), bym nie musiał rekonstruować rozumowania.

Przykładowo:

* Przed rozpoczęciem prac poproś model o dostarczenie promptu zapewniającego komentarze, która wystarcza programiście o przeciętnym poziomie umiejętności, na przejęcie wlascicielstwa kodu oraz dalszy jego rozwój.

* Dodaj prompt do guidelines, z których korzysta model podczas właściwych prac.

Nie zawsze daje to oczekiwane efekty, ale przynajmniej gwarantuje, że otrzymany kod będzie opisany przez AI tak, jak go rozumiało.

Przykładowy prompt dla skryptu w Pythonie utworzonego przez ChatGPT:

*

Write production-quality Python code intended to be handed over to a mid-level programmer who will assume ownership of its future development and maintenance.

Include comments and documentation that explain information not immediately apparent from the code itself, especially:

* the purpose and responsibility of each module, class, and public function;

* important design decisions and why they were chosen;

* non-obvious business rules, assumptions, constraints, and invariants;

* complex algorithms or control flow;

* interactions with external systems, files, APIs, databases, or environment variables;

* expected input and output formats;

* error-handling and recovery behavior;

* side effects, performance considerations, and security-sensitive behavior;

* known limitations, technical debt, and justified workarounds;

* areas where future changes are likely to require coordinated modifications.

Use clear docstrings for modules, classes, and functions. Include type hints where practical.

Do not add comments that merely restate individual lines of code. Prefer explaining intent, rationale, dependencies, and maintenance implications.

Use `TODO`, `FIXME`, or `NOTE` comments only when they provide a specific, actionable explanation. Include the reason, expected resolution, and relevant constraint where known.

Structure the code so that a mid-level Python developer can understand the execution flow, safely modify it, diagnose failures, and extend it without needing undocumented historical context.

Before returning the final code, review every comment and docstring to ensure that it is accurate, useful, concise, and unlikely to become misleading after routine

implementation changes.

@elszczepano ...bo to gówno jest potem nienaprawialne i nieutrzymywalne? :grinning:

Piszę to jako freelancer solo dev który nad całością projektów pracuje sam. Jak dla mnie największy problem jest taki, że się nie ma pojęcia co siedzi w codebase. O ile jeszcze używa się AI do poprawiania starego kodu albo dopisywania funkcji to ok. Dalej się kojarzy co gdzie jak. Ale jeżeli używa się AI do pisania całkowicie od zera i leci prawie full vibecoding i jedynie zerka się względnie czy nie robi nigdzie jakiś ogromnych błędów. To tak naprawdę nie ma się pojęcia jak potem pracować z tym kodem ręcznie i jest się zmuszonym dalej korzystać z AI do jego ulepszania i poprawiania. Wszystko spoko dopóki AI sobie będzie z tym radzić. Jak przestanie bo np. kod urośnie do ogromnych rozmiarów to jest problem.

@elszczepano ja już ponad 3 miesiące nie pisze w ogóle nic ręcznie, w ogóle malomco robię ręcznie, bo u nas taka rewolucja i się zastanawiam czy jakby teraz przyszło co do czego to bym napisał test sam (co robiłem latami, ale czuję, że duża atrofia skilla nastapila)

Z tym że nie warto to nie ma się co rozpędzać, ale problemy opisane w artykule są faktem