Frameworki AI

jarekr000000
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: U krasnoludów - pod górą
  • Postów: 4727
4

Zbieram tutaj jakieś doświadczenia z frameworkami AI.
Czyli jak pracujecie z Klaudiuszem

Jak wrzucacie zadania?
Jak kontrolujecie itd.?
Macie jakiś worklog.md?
Co z gitem?

Przykład - jakiś miesiąc temu to był mój framework:
https://github.com/jarekratajski/plz/blob/main/ai/rules/general.md

Obecnie znacznie to uprościłem, ale nie mam przykładu w publicznym repo.
Na pewno za to są przykłady do użycia.

Moje do tej pory wnioski

  1. powyższy przykład jest mega przeinżynierowany :-( (powstał w czasach sonnet 4.5)
    obecnie tylko każe Klaudiuszowi prowadzić worklog.md i architecture.md -> żeby mieć aktualne stan prac
  2. Każe Klaudiuszowi samemu commitować do git - wygodniej niż wymyślać co wpisać w commity (pierwszy raz w moim życiu mam sensowne opisy commitów)
  3. Żadne reguły typu "remember to never use var" etc. nie działają w dłuższym czasie -> jak chcemy miec jakąś jakość kodu musi być twardy build i linter, który to sprawdza
SL
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1104
3

Jak wrzucacie zadania?

Albo adres do JIRY/Githuba z taskiem albo piszę z palca. Generalnie jeszcze pół roku temu starałem się pisać bardzo dobrego prompta z wieloma iteracjami tj. tworzę nową konwersację z poprawionym promptem jak widzę, że claud odjeżdza. Teraz po prostu wrzucam co mi się nie podoba, bo model (najnowszy Opus) trochę lepiej ogarnia bloat w kontekscie

Jak kontrolujecie itd.?

git diff . Ja mam ten problem, że pracuję teraz w projekcie, którego za bardzo nie da się testować (integracja z zewnętrznymi programami sterowanymi w czasie rzeczywistym), ale generalnie gdy się da to lubię najpierw skupić się na testach a potem niech kladiusz się poci

Macie jakiś worklog.md?

Mam swojego CLAUDE.md wygenerowanego przez clauda z niewielkimi modyfikacjami . Jak dojdę to momentu gdy dużo wiedzy na temat tego jak coś ma być zrobione zostaje w kontekscie to piszę prompta, żeby zachować tą wiedzę w formie dokumentacji dla przyszłych pokoleń

Co z gitem?

Używam po staremu tj. daję konkretne instrukcje co ma się wydarzyć tj. zrób commit, zrebasuj, zrób unstasha i napraw konflikty .

Każe Klaudiuszowi samemu commitować do git - wygodniej niż wymyślać co wpisać w commity (pierwszy raz w moim życiu mam sensowne opisy commitów)

Lubię używać wygenerowane commit message jako punkt startowy, ale Claud jak i wszystkie AI nie potrafią generować komentatrzy. Jest dużo niepotrzebnych ogólników a mało konkretnego mięska, który wzbogaca kod

Żadne reguły typu "remember to never use var" etc. nie działają w dłuższym czasie -> jak chcemy miec jakąś jakość kodu musi być twardy build i linter, który to sprawdza

Tak, dobre testy i dużo lintowania to konieczność. Ostatecznie trzeba założyć, że instrukcje i dokumentacja nie będą przeczytane

Co do twojego projektu: ja bym bardziej szedł z kierunku pisania linterów przy pomocy AI (lub niech szuka czegoś w internecie) zamiast opasłej dokumentacji

bagietMajster
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 455
3

Testowałem bardzo dużo różnych sposobów, metod, planów, wielo/jedno plikowych, MCP/bez MCP, modyfikowałem zadania, zostawiałem tak jak było, pozwalałem na dostęp do bazy/api, zabraniałem dostępów. Wyniki moich testów jest następujący: nie ma to znaczenia dla klaudiusza, i tak zrobi co chce, i tak pominie co chce a jak go manualnie nie przypilnujesz to zrobione nie będzie. Uważam że less is more w przypadku MD, ważne żeby sobie dodawać rzeczy które są ważne/które nas denerwują do Claude.MD żeby tego nie powtarzać ciągle.

Pyxis
  • Rejestracja: dni
  • Ostatnio: dni
2

Testowałem najświeższe GPT-5.x Codex-y na bardziej złożonych zadaniach, tak by przygotował produkt od A do Z. W zasadzie przekazałem mu w SKILLS-ach czego oczekuję, w czym piszemy, jakie ma dodatkowe biblioteki do dyspozycji, jakie frameworki i moduły dociągnąć, gdy będzie taka potrzeba. Zaznaczyłem również, żeby implementował tylko to, co niezbędne i rozbijał taska na mniejsze punkty (taki planner), który pozwalał mi je przeanalizować i sprawdzić, czy w ogóle to ma sens. Jeśli akceptuję, to przechodzi do implementacji.

Następnie z okienka z czatem z poziomu IDE ładowałem mu SKILLS.md i dawałem zadanie w stylu korpo-jiry taska: Przygotuj serwis, który poprzez API robi to i tamto. Kilka punktów, bardzo generyczny opis z ogólnymi wymaganiami. Do tego miałem jakieś proste testy, które pozwoliły stwierdzić, że aplikacja w ogóle działa. Dostawałem zwykle sensowny plan rozbity na parę punktów. Prosiłem o implementację, więc wyglądało to tak, że agent najpierw wykonywał pewne polecenia w oknie czatu. Zawsze prosił o potwierdzenie, czy wykonać tymczasowe zadanie, choć mogłem dać zielone światło na wszystkie komendy. Oczywiście nie dałem.

Takich iteracji było wiele, co pozwalało mu eksplorować środowisko, np. czy może się połączyć z bazą, czy mam zainstalowaną daną paczkę itd. Jak punkt z planu był pokryty kodem, to czekał na jego akceptację i szedł dalej. Gdy wykonał wszystkie punkty, a ja zaakceptowałem wykonywanie finalnej aplikacji, to na końcu wykonywał testy. Często musiał wtedy się poprawiać, ale generalnie było to autonomiczne, ja tylko akceptowałem wykonywanie kodu z jego modyfikacjami.

Wnioski: pomimo, że prosiłem o minimalny kod, to był on dla mnie dziwny, na zasadzie łapiemy generyczny Exception. Chyba lepiej, by w ogóle tego nie dodawał. Ogólnie kod był dla mnie niezrozumiały, umieszczał pomocnicze funkcje w celach debuggingu. Potem musiałem się upominać o refaktoryzację, by je usunął. Dodatkowo dodawał bardzo sprecyzowane wyjątki, czyli jak gdzieś w flow zrozumiał, że wysłanie wartości 10 powoduje błąd, to hardkodował tę wartość w if-e. Ja to odbieram tak, że jego celem było dostarczenie produktu, więc każde potknięcie po drodze to był hotfix, byleby działało. Natomiast LLM działa całkiem dobrze, jak mamy pogadać o koncepcji, czy nawet poprosić o napisanie jednej funkcji z dobrze zdefiniowanymi warunkami brzegowymi. Tylko że realnie takie coś nie przyspiesza pracy. Taki kod trzeba przemyśleć dokładnie w ten sam sposób, jak trzeba by go wymyślić od zera. W złożonych systemach, czy legacy, LLM raczej się pogubi.

Podkreślę, że to były testy na green field, by wyrobić sobie opinię i sprawdzić, czy rzeczywiście zawód programisty jest zagrożony. Nie podpisałbym się pod takim kodem na produkcji. W moim odczuciu dowiezienie produktu nie może być jednym kryterium i wiem, że biznes myśli inaczej, ale to nic. Dług technologiczny prędzej czy później się zemści i wtedy biznes zapłaci podwójnie, choć niewykluczone, że jakiś % firm wyrobi znaczne zyski i zwinie się, gdy narracja o AI się zmieni.

CZ
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 2657
0

W moim odczuciu dowiezienie produktu nie może być jednym kryterium i wiem, że biznes myśli inaczej, ale to nic. Dług technologiczny prędzej czy później się zemści i wtedy biznes zapłaci podwójnie, choć niewykluczone, że jakiś % firm wyrobi znaczne zyski i zwinie się, gdy narracja o AI się zmieni.

Tylko zapomniałeś o jednej ważnej rzeczy. Kod z AI stał się o wiele tańszy. W związku z tym być może zamiast utrzymywać jakiś produkt będzie się go pisać od nowa co iterację. Nie będziemy musieli pisać kodu który ma być „maintainable” i „scalable”. Jedynie nasz metajęzyk do komunikacji z AI taki będzie musiał być.

Pyxis
  • Rejestracja: dni
  • Ostatnio: dni
0
Czitels napisał(a):

Tylko zapomniałeś o jednej ważnej rzeczy. Kod z AI stał się o wiele tańszy. W związku z tym być może zamiast utrzymywać jakiś produkt będzie się go pisać od nowa co iterację.

Z takim podejście nie ma szans na innowacje, bo każda kolejna iteracja to sklejanie czegoś na bazie ograniczonego fundamentu. W końcu AI zacznie się uczyć na słabym kodzie, który wygenerowało i umyka jej już uniwersalność. Bo o ile generalizacja to taki trzon sieci neuronowych, o tyle generalizowanie na kodzie, który nie jest uniwersalny, a bardzo ograniczony do konkretnych danych, prowadzi donikąd.

CZ
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 2657
0
Pyxis napisał(a):

bo każda kolejna iteracja to sklejanie czegoś na bazie ograniczonego fundamentu.

Mi chodziło o generowanie kodu w całości od nowa tylko z zmienionymi wymaganiami. Jakiekolwiek bazowanie na poprzednim kodzie nie ma sensu, bo wtedy wchodzimy w pisanie w znany nam już sposób.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.