Delegowanie pisania kodu do AI ma ogrom zalet. W ciągu ostatnich dwóch lat, za sprawą narzędzi AI, wyprodukowałem wielokrotnie więcej kodu niż kiedykolwiek wcześniej. Przez ten czas zacząłem jednak dostrzegać sporo istotnych wad tego podejścia. O tym, jakie problemy dostrzegam w tym sposobie pracy, przeczytasz w podlinkowanym artykule.
#programowanie
#informatyka
#programista15k
#ai
#sztucznainteligencja
#naukaprogramowania
Z tym że nie warto to nie ma się co rozpędzać, ale problemy opisane w artykule są faktem
@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)
@Zielczan - w pracy mamy już ludzi co od ponad roku programują regularnie z LLMami - Ci co używają ich najwięcej już się uwstecznili - dwóch z nich zmniejszyło częstotliwości używania EjAj bo boi się, że będzie dupa blada jeśli kiedyś trzeba będzie coś samemu napisać.
@Zielczan mi dzisiaj jak dostęp do Claude Code się wysypał to aż przyjemniej w klawiaturę się klepało
@Zielczan nie no ja myślę że potrzebował byś chwili żeby odrdzewieć i spokojnie sobie przypomnisz
@ZohanTSW może tak, ale nie robimy już nic ręcznie, więc nawet nie ma jak. Muszę w domu jakiś prywatny projekt robić chyba
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.
@Catharsis bylem na hackatonie na ktorym mozna bylo uzywac AI. Napisalismy z kumplem wszystko z Opusem 4.6 nie piszac nawet linijki kodu.
Problem zaczal sie jak AI nie potrafilo naprawic bledu. Kilka promptow i nadal nie dziala, a code base tak urosl ze ni huja nie szlo ogarnac w krotkim czasie. Tak wiec AI z glowa i ciagla kontrola co pisze
@elszczepano ...bo to gówno jest potem nienaprawialne i nieutrzymywalne?
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.
Zaloguj się aby komentować