Agenty tworzą użyteczny kod szybko wtedy, gdy projekt jest prosty, opisany i przewidywalny. Rails pomaga, bo ma mocne konwencje. MongoDB pomaga, gdy dane już istnieją i aplikacja nie potrzebuje migracji SQL. Główna zasada zostaje ta sama: KISS. Complexity jest wrogiem.

README Jako Źródło Prawdy

Najlepsza optymalizacja pod agenty jest też dobrą dokumentacją dla ludzi: krótki i aktualny README. Powinien mówić, czego używa aplikacja, jak ją uruchomić, jak testować i jakie reguły są ważne.

Stack:
- Rails 8.1.3
- Ruby 4.0.5 w Dockerze
- Ruby 3.4.9 lokalnie
- Mongoid 9.1.0
- Bootstrap 5.3.8

Reguły:
- KISS
- bez nowego gema, jeśli nie jest potrzebny
- cienkie kontrolery
- preferuj konwencje Rails
- weryfikuj testami

To oszczędza tokeny, bo kolejne zadania mogą mówić: „trzymaj się README”. Agent nie potrzebuje za każdym razem tego samego opisu architektury.

Podawaj Konkretne Wersje

Wersje mają znaczenie. „Użyj nowoczesnego Rails” jest słabsze niż „użyj Rails 8.1.3”. Konkretne wersje zmniejszają zgadywanie, unikają starych przykładów i ułatwiają pracę z Dockerem, gemami, authentication i testami.

Dobrze:
Użyj Rails 8.1.3, Mongoid 9.1.0, Bootstrap 5.3.8. 
Docker celuje w Ruby 4.0.5. # a najelpiej zapisz to w README

Źle:
Użyj najnowszego Rails i zrób nowocześnie.

Dlaczego MongoDB Przyspiesza

MongoDB jest praktyczne dla paneli admina, danych crawlera, logów, kolejek i importowanych kolekcji, bo schemat może już wynikać z danych. Agent może utworzyć model Mongoid dla istniejącej kolekcji i zbudować ekran Rails wokół niego. Nie trzeba migracji SQL dla każdej małej funkcji admina.

Dobre zadanie:
Utwórz model Mongoid dla istniejącej kolekcji.
Dodaj prosty Rails resource i formularz Bootstrap.
Bez migracji SQL.

Ważne jest, żeby nadal używać modelu. Model daje nazwy, walidacje, helpery formularzy i stabilne miejsce na zachowanie.

Pracuj Przez Modele

Szybki kod to nie znaczy kod wklejony do kontrolera. Jeśli agent pracuje przez modele, Rails pomaga formularzami, ścieżkami, błędami walidacji i testami.

Lepiej:
Utwórz model, potem resource route, potem akcje kontrolera, potem partial formularza.

Gorzej:
Czytać params ręcznie wszędzie i przerzucać raw hashe między widokami i kontrolerami.

To jest tańsze w czasie. Pierwszy model może mieć kilka linii więcej, ale każdy kolejny formularz i ekran edycji robi się prostszy.

Rails Reload To Funkcja Przyspieszająca

W development Rails przeładowuje zmieniony kod przy kolejnym żądaniu. Dla zmian w widoku, kontrolerze, helperze, route i modelu odśwież stronę i sprawdź wynik. Docker rebuild rób tylko wtedy, gdy zmienia się runtime, paczki systemowe albo Dockerfile.

Dobrze:
Zmień widok, odśwież stronę, uruchom właściwe testy.

Marnowanie czasu:
Budować cały obraz po każdej zmianie HTML albo kontrolera.

Nawigacja Jedną Warstwą

Nawigacja też wpływa na szybkość pracy agentów. Prosta nawigacja jedną warstwą jest łatwiejsza dla ludzi i dla agentów. Unikaj głębokich menu, wyjątków i powielonego markupu. Jedno jasne grupowanie zwykle wystarczy.

Dobrze:
Jedna prosta warstwa nawigacji.
Wspólny partial.
Jasne nazwy.

Źle:
Zagnieżdżone menu, powielone linki, własne zachowanie w wielu miejscach.

Małe Prompty Są Lepsze Niż Wielkie Zrzuty

Nie wklejaj całej wyrenderowanej strony, jeśli jeden powtarzalny blok wyjaśnia problem. Podaj route, oczekiwane zachowanie i ograniczenie.

Kontekst: trzymaj się README.
Cel: skompaktuj układ jednego wiersza tabeli.
Ograniczenie: raw JSON ma zostać pretty printed.
Weryfikacja: uruchom testy Rails i podsumuj zmienione pliki.

To wystarczy, żeby agent obejrzał kod i zrobił skupioną zmianę. Duże zrzuty HTML zostaw na błędy layoutu, gdzie wyrenderowany output jest faktycznym dowodem.

Praktyczne Reguły

  • Trzymaj README krótkie i aktualne.
  • Pinuj wersje frameworka, Ruby, bazy danych i biblioteki UI.
  • Preferuj konwencje i generatory Rails, potem upraszczaj.
  • Używaj modeli Mongoid dla istniejących kolekcji MongoDB.
  • Trzymaj nawigację płaską i oczywistą.
  • Dla zmian aplikacji odświeżaj stronę Rails; Docker rebuild tylko dla runtime.
  • Zlecaj jedną zmianę zachowania naraz.
  • Usuwaj complexity wcześnie. Jest droga dla ludzi i dla agentów.