Dlaczego Laravel, Yii i Rails są dobre do pracy z agentami

Jeden developer z zespołem agentów AI powinien wybrać framework z mocnymi konwencjami: Laravel, Yii2/3 albo Ruby on Rails. Takie frameworki dają przewidywalny kod i krótki kontekst, czyli dokładnie to, czego potrzebuje agent.
Pracuję z frameworkami od 20 lat i kieruję się zasadą: prostota przede wszystkim. Przez ten czas duże firmy rozdzielały frontend i backend, bo pracowały nad nimi osobne zespoły ludzi. Dziś zespół tworzą agenci (opencode, hermess, OpenClaw, paseo.sh), a podział na dwie aplikacje tylko zwiększa koszt tokenów.
Cztery powody przewagi
- przewidywalne wyniki: stałe konwencje i dobra dokumentacja, agent podąża za wzorcem zamiast zgadywać,
- tania tokenomia: mało kodu, dużo efektu, kontroler mieści się w kilku linijkach,
- fullstack: jedna aplikacja zamiast frontendu, backendu i API pomiędzy nimi,
- standardowe DDD: MVC i REST to wzorce znane modelom, więc łatwiej opisać zadanie.
Więcej o samym procesie opisałem w tekście szybkie generowanie kodu z agentami, Rails i MongoDB.
Krótki kod mieści się w kontekście
W naszym panelu crawlera landing page to trzy linijki, a widok tabeli to jedna pętla.
# app/controllers/home_controller.rb
class HomeController < ApplicationController
allow_unauthenticated_access
def index; end
end
<%# app/views/hosts/_field_table.html.erb %>
<% fields.each do |field| %>
<tr>
<th><%= field %></th>
<td><%= document_value(doc[field], field).presence || "-" %></td>
</tr>
<% end %>
Agent czyta taki plik w całości. Nie musi rekonstruować przepływu przez pięć warstw abstrakcji.
Baza danych dobrana do problemu
Nie bój się SQLite ani baz NoSQL. Dobór bazy do problemu usuwa migracje i całe warstwy mapowania. Model dokumentowy w panelu crawlera wygląda tak:
# app/models/crawl_host.rb
class CrawlHost
include AdminDocument
store_in collection: 'hosts'
admin_field :hostname
admin_field :kind, input: :select
admin_field :status, input: :select
admin_field :indexed_at, type: Time, input: :datetime
end
Te cztery pola opisują formularz, filtr i tabelę naraz. Podobnie jak w Astro, treść można też trzymać w plikach Markdown i parsować ją własnym, krótkim serwisem.
Dlaczego nie Django
Python jest świetnym językiem do redukcji złożoności, ale Django nie jest moim wyborem do pracy agentowej. Wolę wydzielić warstwę webową do Rails albo do frameworka PHP. Inny język wygląda na wzrost złożoności, jednak w praktyce daje krótszy i bardziej przewidywalny kod.