Give an autonomous CLI agent a greenfield Laravel API with clear modules and it looks brilliant. Give it a ten-year WordPress plugin soup with three overlapping auth paths and it burns tokens rewriting the same broken helper.
That is the agentic coding paradox: the more autonomy you grant, the more honestly the codebase confesses its structure. Agents do not invent discipline. They amplify whatever boundaries already exist.
We ship client work from Lalitpur in Python, Laravel, React, and the usual CMS stack. We also use coding agents in our own studio workflows. The pattern is consistent enough to write down.
Autonomy is a force multiplier, not a substitute
A CLI agent that can read files, run tests, and open PRs is powerful when the next change is local and the feedback loop is short. It is fragile when:
- Domain logic lives in controllers, Blade templates, and a random
helpers.php - The React app talks to Laravel through undocumented JSON shapes
- Python scripts mutate the same tables the queue workers own, with no shared model layer
- "Just run the migration" requires tribal knowledge about which env file is real
Humans compensate with memory and Slack. Agents compensate with wider search and longer sessions — until the context window fills with contradictory clues.
What "bad architecture" looks like to an agent
Agents fail loudly on problems humans paper over:
- No single source of truth. Two invoice totals calculated in different places. The agent "fixes" one path and breaks the other.
- Hidden side effects. A Laravel observer that emails on
savedwith no test. The agent refactors a model; production spam follows. - Leaky boundaries. React components that know Postgres column names. Touch the schema and half the UI needs a rewrite the agent cannot see in one pass.
- Environment folklore. Seed data that only works after a manual SQL tweak. The agent loops on failing tests that a human would fix with a whispered ritual.
None of this is new. Agentic tools just remove the social filter. The failure mode shows up in a transcript instead of a quiet Friday hotfix.
What we optimize for when agents are in the loop
We do not redesign every client app for agents. We do bias toward shapes that keep both humans and tools effective:
Clear module edges
In Laravel, prefer domain folders (Invoices, Projects, Billing) over dumping everything into Http/Controllers. In React, keep server-facing types next to the API client, not scattered through form components. In Python helpers for AI features, keep prompt construction, retrieval, and side effects in separate modules so an agent can change one without inventing the others.
Contracts before cleverness
OpenAPI, Form Requests, Zod (or equivalent) on the React side — pick something that fails the build when shapes drift. Agents are excellent at updating a typed client. They are terrible at guessing which of three undocumented payload variants is "the real one this week."
Tests as the short leash
A focused PHPUnit or Pest suite around money, auth, and permissions is worth more than a thousand-line system prompt. Same for React component tests on the flows clients actually use. Agents need a red/green signal that matches production risk.
Boring deploys
Migrations in CI, queue workers with known retries, feature flags for LLM-backed paths. Autonomy without a rollback story is just faster regret.
How we use agents without romanticizing them
On our own site and internal tooling, agents draft blog rows, propose UI diffs, and sketch Laravel endpoints. They do not own production publishes. A human still decides what ships — the same rule we recommend for client AI features: assist, then approve.
For client portals and CMS work, we introduce agents where the architecture already has seams: a well-scoped Laravel module, a React form with a typed API, a Python job that reads from one queue and writes to one table. We avoid dropping an autonomous loop on a legacy Joomla customization and calling it "AI transformation."
The useful takeaway
If your CLI agent keeps thrashing, resist the urge to only tune the prompt. Ask whether a competent new hire would also thrash. Usually the answer is yes — the agent just fails faster and with a longer log.
Good architecture for agentic coding is mostly good architecture for people: small modules, explicit contracts, honest tests, and a deploy path you trust. Autonomy exposes the rest.
That is not a reason to avoid agents. It is a reason to treat every failed agent session as architecture feedback — then fix the seams, not just the session.
Further reading
- Anthropic — Building effective agents — workflows vs. open-ended agents
- 12 Factor App — still a useful checklist when tooling gets smarter than the repo