State of Agentic Coding #10 with Armin and Ben

Core theme: “Agentic coding” is spreading—bottlenecks are productization, incentives, and discipline

• Armin: A major innovation is finding new venues/surfaces for coding agents (IDE, Slack, tickets, etc.), rather than changing the core idea of agent-driven coding.
• Ben: “AI infrastructure” is about making coding agents easier to deploy—less about one-off apps and more about pluggable context, tooling, and connectivity.

---

Testing, quality gates, and the “software factory” vs. controllable automation

• Pi/Hunk approach: They reduce or remove tests because running them is too annoying/slow.
• Operational tradeoff discussed:
  • More automation (agents making PRs) increases the pain of “reject/repair” cycles.
  • Humans still must maintain quality via gates, not “ship and hope.”
• Ben’s “software factory” metaphor (Hunk):
  • Runs multiple parallel agent jobs (“checkouts”) with different harnesses and models.
  • Examples include:
    • Pi using other model providers
    • Open-weight via routers such as OpenCode Go / Zen
  • Emphasizes longer-horizon work (“jobs that can run for hours” so he doesn’t babysit).
• Armin’s view: In team/organizational settings, agentic coding can stagnate unless people have time and process to avoid regressions.

They both discuss the tension between:

• “Don’t block; merge fast; fix later”
• vs. the need to understand and maintain code long-term.

---

Watermarking & AI detection: likely less important than model “fingerprints” and editorial/rewriting behavior

• Ben on Anthropic watermarking:
  • Watermarking works by biasing non-determinism (token probabilities / RNG behavior) so generated text has detectable statistical properties.
  • Not necessarily perfectly reliable, but can increase detection confidence from large enough text blocks.
• Armin’s counterpoint:
  • Even without watermarking, AI detectors can be effective because they learn LLM-produced distributions.
  • Watermarking probably won’t be the deciding factor; instead, it’s increasingly noticeable that LLMs edit language stylistically (e.g., copy-editing artifacts and unnatural phrasing).
• “SLOP” spectrum:
  • AI-written content can range from acceptable to bad.
  • For security reports, “valid but horrible” output can be dangerous because incentives favor speed/correctness over readability—so bad artifacts proliferate.
• Panel suspicion: the main issue is model quality/cadence, not watermarking.

---

Subscription/model politics: defaults matter, and access can be cut off suddenly

• A major news thread: OpenAI cutting off access to a model provider inside Cursor (plus similar historical events like Windsurf losing Anthropic access).
• Key analysis points:
  • Corporate conflicts and licensing can abruptly change what models tools provide.
  • Users may not switch immediately due to defaults and workflow stickiness (e.g., “Cloud Code subscription” driving usage).
  • Example: Cursor defaulting to one provider longer, then shifting (e.g., Composer becoming default).
• Broader incentives:
  • Two “economies”:
    • Subsidized subscriptions (developer gets cheap/bundled usage)
    • API pricing / company budget constraints (limiting model switching)
  • When subsidies end, usage can collapse even if cheaper models are “good enough,” suggesting usage follows price more than quality.
  • Example mentioned: models like GLM 5.3 / Ox Alpha on routers see volume drop after subsidies end.

---

Open-weight models: useful, but cost and safety constraints change the calculus

• Ben’s usage pattern:
  • He uses open-weight models less than expected because they’re too expensive relative to his open-AI style subscriptions.
• Where he does use them heavily:
  • Cybersecurity tasks and reverse engineering workflows.
• “Security harness loop”:
  • Start with a model (“Kimmy”) that is willing to do reverse engineering.
  • Switch to an OpenAI model afterward.
  • This avoids refusals from proprietary models/restrictions (examples referenced include issues around “distillation” or special internal tokens).
• Pi security harnesses:
  • They mention building custom security harnesses in Pi.
  • They discuss frustration when proprietary safety mechanisms trigger prompt refusals/cyber restrictions.

---

Coding agents move back to the cloud: easier sandboxing and monetizable distribution

• Discussion: cloud agents returning (after local/IDE movement).
• Reasons cited:
  • Easier sandboxing in the cloud than on-device.
  • Security models can “escape” sandboxes, so cloud infrastructure is often more controllable.
• New agent surfaces/examples:
  • Slack coding agents (e.g., Linear agent, Devon via Slack, “proactive” behaviors)
  • Idea: agents consume tickets/messages and then propose/execute changes automatically.

---

GitHub & “alternatives”: availability, stability, and culture wars around AI contributions

• They connect GitHub downtime (long outages discussed) to competitive pressure and “competitors” announced after outages.
• Another angle: enterprise vs open source economics.
• Open source culture wars:
  • Communities take explicit stances: “AI okay” vs “AI not okay.”
  • Some Git hosting alternatives restrict AI contributions (e.g., Codeberg, SourceHut).
  • SourceHut: reportedly restricts hosting projects that accept AI contributions (including references to Linux kernel).
• Concern: if subsidies decrease or AI-restricted hosting narrows ecosystems, access to open source hosting may become harder over time.

---

Lessons learned / “what getting better means” (agentic engineering maturity)

• Ben defines “getting better” as:
  1. Turning ideas into functioning software
  2. Maintaining reasonable quality
  3. Having good, flexible architecture that supports future refactors
• Practical strategies he cites:
  • Teach agents tooling conventions (e.g., GitHub stacked PRs), because models can’t reliably infer workflow details without explicit “skill”/instruction.
  • Use PR structuring to reduce conflicts—e.g., stacked PRs queued to avoid tiny merge conflicts.
• Armin’s emphasis:
  • “Ship it” without understanding can degrade long-term maintainability and interoperability.
  • Middle ground acknowledged: merge when tests/gates pass, then learn by refactoring/fixing—but only with scrutiny.

---

Agent-generated extensions can fail architecturally even when they “work”

• Failure mode discussed:
  • An LLM-generated extension was syntactically correct and ran, but the architecture/design was wrong, creating an impedance mismatch.
  • It “worked in a glove-like way,” but the shim/connection undermined the intended abstraction.
• Key takeaway:
  • Success isn’t just “tests pass”—interoperability and design correctness require expert review.

---

Product/category insight: innovation is shifting toward “agentifying everything,” not new AI products

• They claim a “stable equilibrium”:
  • People don’t adopt totally new categories daily.
  • They adopt coding agents and move them across platforms (Slack, tickets, IDEs).
  • “AI products” don’t stick unless they meaningfully improve the day-to-day agent workflow.
• Future differentiation may depend on:
  • Agent integration with interaction surfaces
  • Agent-friendly constraints (languages/models/architectures that reduce “SLOP”)
  • But tools for long-horizon, team-scale usage are not fully mature.

---

Main speakers/sources

• Ben Vinegar (co-founder of Modem; builds Hunk)
• Armin (Armin/Armen; founded Arendel; builds Pi harness; discusses AI infrastructure/context graphs)