State of Agentic Coding #12 with Armin and Ben

Summary

Armin Ronacher and Ben discuss how agentic coding is changing software development, product design, and the relationship between people and their computers.

Models and agent workflows

• Armin says he has shifted from mostly using GPT models to relying heavily on Opus 5.5, which he finds especially useful because its explanations are readable and help him understand what code is doing. Ben also uses it, dividing work between different models and tools according to the task.
• They argue that the “best” model is not necessarily the newest or most capable one. Task fit, speed, cost, and reliability matter; fast, inexpensive classifiers can be valuable for sorting large volumes of information or checking translations and other project data.
• Armin describes experimenting with a small “software factory”: agents run in separate environments, test submitted pull requests, and communicate through IRC. After finding existing options inadequate, he built a TUI IRC client and then used an agent to improve its interface.
• In a project making games with his children, Armin largely gives agents prompts rather than prescribing the code structure. He says the agents have developed workable file organization and can use project files as a kind of practical memory—for example, noticing that the family adds children’s drawings to the game.
• Both speakers stress that an agent’s results depend on more than the model: its harness, prompts, tools, context, and permissions all matter.

Does AI mean software is “dead”?

The speakers reject the idea that software itself is disappearing. They see software being produced and used in new ways, while warning that the familiar model of locally owned desktop software may face pressure.

• AI-assisted reverse engineering can produce convincing alternatives to established applications. They discuss a Photoshop-like clone that reportedly opens files and draws faster than Photoshop, while cautioning that a separate hands-on video found serious limitations in another Adobe-app alternative. Their takeaway is that a clone can excel at selected core tasks without being a complete replacement.
• They raise concerns about whether users will continue to own and run software locally. Console security, game piracy, cloud streaming, and subscription services are discussed as examples of competing pressures.
• They connect cloud computing’s cost and hardware shortages to a possible future in which people rent computing resources rather than own powerful machines. This is presented as a concern and prediction, not a settled outcome.
• The speakers emphasize the trade-off: cloud services can be convenient, but local control, provider choice, data portability, and the ability to run software independently may be lost.

Security, data, and control

• They discuss the limitations of AI safety filters for legitimate security work. Armin describes an example in which a model refused to help compile an older PHP version for vulnerability research, and says some coding platforms impose stricter restrictions than others.
• They worry that commercial relationships could lead providers to restrict models’ outputs in response to copyright or business demands. These are predictions about incentives, rather than claims that a particular policy has already been adopted.
• Giving agents access to logs, deployment history, metrics, or databases could make them more useful, but broad access creates security risks. Ben describes work on a PostgreSQL extension that marks sensitive columns and provides agents with views that omit those columns, enabling safer read-only access to product data.
• They see a need for better infrastructure for limited, auditable agent access, especially for debugging and other software-lifecycle tasks.

AI-assisted development and software quality

• Armin describes building a game with his children, with roughly 220,000 lines of JavaScript. Agent assistance let him attempt features he previously would have avoided, including complex boss-fight physics, time-travel sequences, advanced shading, narration, and custom audio.
• He says this made game development more exploratory and enjoyable, while acknowledging that the result is a rough family project—not necessarily equivalent to a polished commercial game.
• The speakers discuss AI-generated code that is compact and organized in ways they find suitable for agent-led projects, but warn that code quality and architecture still need attention. Armin says he did not review all of the project’s code thoroughly.
• They are cautious about treating reversions or rapid fixes as cost-free. Moving faster can also mean creating technical debt faster, and removing useful features or instrumentation to meet a narrow performance goal may create new problems.
• They see documentation and architecture as useful when they preserve important decisions and make references between code and documentation easy to follow. They are less convinced that large, prescriptive AGENTS.md files or repeated formal evaluations are always worthwhile.

Discussion of Thorsten Ball’s agent-working advice

The speakers review several recommendations and add qualifications:

1. Use the latest and best models: Generally useful, but choose a model based on the task rather than prestige alone.
2. Don’t worry too much about “slop”: Some roughness may be acceptable, but unchecked complexity and harmful changes still matter.
3. Explain the desired outcome, not every implementation step: Often effective, but an overly narrow goal—such as “make it as fast as possible”—can lead an agent to remove things that matter, like source maps or monitoring.
4. Give agents access to more of the software development lifecycle: Logs, metrics, deployment history, and diagnostics can help, but access should be carefully scoped and safe.
5. Use agents to make tools or variations instead of repeating manual tasks: They agree with exploring alternatives, while favoring low-fidelity mockups or targeted experiments over generating many complete implementations.
6. Ask for evidence and explanatory artifacts: Demos, walkthroughs, algorithm explanations, and other materials can help people assess results without reading every line of code.
7. Reduce manual context management: Agent-managed memory and handoffs are improving, though users still need judgment about when to start a fresh session.

Local versus cloud development

Ben uses cloud development for some tasks, such as website updates, but says remote coding environments can struggle with databases, external services, and realistic testing. Armin prefers local development and argues that cloud work does not suit every workflow. They expect more hybrid approaches, including remote access to local machines, rather than assuming that agents make all remote-development problems disappear.

Reviews, guides, and tutorials mentioned

• Product and model impressions: Positive comments on Opus 5.5’s readable output; mixed comments on Photoshop-like software clones, which may be fast and capable in core areas but can fall short in serious use.
• Practical workflow advice: The discussion of Thorsten Ball’s agent rules functions as a review of agent practices, particularly model choice, context, iteration, permissions, and code quality.
• Tutorials: No formal step-by-step tutorial is presented, though the speakers share examples of agent workflows, safer data access, and AI-assisted game development.

Main speakers and sources

• Armin Ronacher — discusses Pi and related tools, model use, agent workflows, local development, and his family game project.
• Ben Vinegar — discusses Modem, customer-data context, agents, and remote development.
• Thorsten Ball — referenced as the author of the agent-work advice they analyze.
• Other referenced sources include a video reviewing alternative creative software and examples of software reverse engineering. Some claims about specific apps, devices, and services are presented as uncertain or anecdotal.