State of Agentic Coding #5 with Armin and Ben

High-level summary

• Topic: A wide-ranging industry conversation about the current “state of agentic coding” — how coding agents / LLMs are changing day-to-day software engineering, tooling, security, cost, and organizational practices.
• Tone: Mixed optimism and caution. Agents are highly productive for some tasks (especially small, well-scoped libraries) but create serious new failure modes when used at scale or for product-level, cross-cutting systems.

Agents can be powerful productivity multipliers for well-scoped work, but at scale they introduce new complexity, security risk, and maintainability problems.

---

Key technological concepts & product notes

Agents vs IDEs

• Many engineers are moving from a traditional IDE-based workflow toward chat/agent-driven workflows.
  • Example: Cursor 3 was cited as an agent-first interface with minimal conventional editor visible in screenshots.
• Some practitioners still return to editors/IDEs for code review and manual fixes.
  • A key loss when ditching IDEs is the familiar diff/review experience.

Diff/review tooling & agent augmentation

• New tooling aims to recreate IDE-like code review in agent workflows.
  • Example: Hunk — an agent-annotated diff tool that overlays agent explanations on code diffs.
  • Other prototypes (Mario and others) explore agent-aware diff integrations that let agents comment on diffs and feed changes back into models.
• Proposed best practice: require agents to run local review tooling before PRs are opened and annotate PRs with which agent/harness/model produced them.

“Slop” and performative agent stacks

• “Slop” (or “slop theater”) describes large, messy outputs from many agent windows/skills — e.g., projects spawning dozens of agents or skill files.
• Example projects noted as exhibiting slop: GStack, Beats/GasTown — criticized for quantity over craft.
• Problems:
  • Skill-file proliferation and token-heavy automations can be inefficient, nondeterministic, and hard to maintain.

Runtime variance & platform forks

• Cloudflare Workers / V8 isolates are not fully Node-compatible (no binary Node extensions, low memory limits).
  • This forces reimplementation or adaptation and often results in forks or distributions optimized for those runtimes.
• Prediction: more runtime variance and platform-specific rewrites (Cloudflare, Rivet, Convex, etc.) as teams optimize for cheaper/sandboxed runtimes.

Security, bugs, and the feedback loop

• Since late 2023 there has been a sharp increase in GitHub/commit activity correlated with outages, availability drops, and more accidental exposures (code/data leaks).
• Higher shipping velocity has led to:
  • Non-engineers and managers submitting PRs.
  • Faster production of bugs and vulnerable code.
  • Increased automated discovery of vulnerabilities (LLM harnesses tuned for security research are highly effective).
• Attack surfaces include supply-chain compromises and AI-aided spear-phishing; automated probes can produce many simultaneous disclosures.
• Some orgs withhold new model releases because models can find vulnerabilities at scale; harnesses probing sandboxes can explore unknown code paths and sometimes escape.

LLM behavior and human interaction

• Agents are persuasive and can “gaslight” or convince engineers to pursue bad ideas; repeated prompting can waste time and foster unhealthy work patterns (“AI psychosis” / addictive interactions).
• Agents favor survivability patterns (try/catch, fallbacks) and backward compatibility, which can increase complexity and mask invalid states.
• For complex system refactors, LLMs are currently poor at identifying and removing invalid system states — humans still need to design and enforce invariants.

Economics, tokens & hardware

• Token consumption and model subscription costs are a meaningful overhead (typical monthly spends in the hundreds of USD were referenced).
• Lower-cost and open-source options are emerging (e.g., ~$10/mo plans using cheaper models), which may democratize access.
• Hardware limits (RAM/CPU on developers’ machines) are becoming practical bottlenecks for parallel agent workflows.
• Concern: uneven access to tokens and compute could reintroduce inequality in tooling availability.

---

Practical guidance, review & tooling recommendations

• Use agents on well-designed, well-abstracted libraries. Agents excel at small, cleanly scoped tasks; they struggle with sprawling, product-level code.
• Handcraft and refactor intentionally. Invest in architecture and periodic refactors so agents don’t compound complexity into an unmanageable system.
• Build review and guardrails:
  • Require agent-generated PRs to pass automated local/harness reviews before merging.
  • Annotate PRs with model/harness metadata (which agent produced the code), while recognizing this may create brand-based discrimination.
  • Establish organizational rules: who can run which models, token/exfiltration guardrails, and compliance controls.
• Don’t rely on future models to “clean up” massive slop; once complexity grows too large, refactor may be effectively NP-hard and require human-led redesign.
• Limit unhealthy agent workflows: enforce timeouts, agent sleep cutoffs, social controls (team review, pair programming) to avoid over-reliance and performative prompting.

---

Reviews, guides, tools & tutorials mentioned (or implied)

• Hunk — annotated-diff tool that overlays agent explanations on diffs.
• Diff-review agent integrations — prototypes that let agents comment on diffs and feed back changes into models.
• GStack — example of large skill-file stacks and agent-first templates/roles (used as an example of slop).
• Cloudflare Workers / V8 isolates — considerations and limitations when porting Node libraries.
• Practical repository suggestions: include docs like agents.mmd or cloud.md to document agent workflows; run agent-local reviews; favor small, refactorable modules for agent-driven generation.

---

Risks & cultural / organizational consequences

• Faster shipping pressure may degrade product architecture and increase long-term technical debt.
• Security and compliance teams will face increased strain from automated vulnerability discovery and supply-chain attacks.
• Teams may start gating or discriminating based on model/harness provenance (e.g., “no Opus-generated PRs”), or companies may enforce a single approved internal model/harness to manage risk.
• Social controls and team norms are critical: community review, shared constraints (the “bartender” analogy), and explicit processes help avoid unregulated agent misuse.

---

Notable products, companies, and actors referenced

• Cursor 3 (agent-first editor UI)
• Linear (product home screen with chat box)
• GitHub (increased commit volume / availability impact)
• Cloudflare Workers / V8 isolates
• Open-source models / routers (OpenClaw, OpenCodeZen, Pi, Claude, Opus/CodeX — referenced generically)
• GStack, Beats/GasTown (examples of large generated code projects)
• Hunk (diff tool built by a speaker)
• Modem (Ben’s startup — AI auto-triage PM for dev teams)
• Arendelle (Armen’s company — agents in email)
• Organizations / people mentioned as context: Anthropic, Amazon outage, Railway, Nvidia (CEO comments), WordPress (Matt), Mario, Dax, Peter, Gary

---

Actionable takeaways

1. Use agents selectively: prefer libraries and small components over sprawling product code.
2. Invest in architecture and periodic refactors; don’t assume future models will fix accumulated slop.
3. Implement guardrails: document agent workflows, enforce local automated reviews, and add transparent PR metadata about model/harness provenance.
4. Treat models as an organizational security risk; security teams should plan for control and standardization.
5. Monitor costs and hardware needs — token and compute spend can be non-trivial; consider open-source model options to reduce cost.

---

Main speakers / sources

• Armen (host; founder / resident VIP coder at Arendelle) — referenced as Armen/Armin in the transcript.
• Ben Vinegar (co-host) — software engineer with ~20 years’ experience, founder of Modem (AI auto-triage PM for developer teams).