A Gathering Designed to Avoid Product-Launch Logic
Simon Willison and Jesse Vincent will host a Birds of a Feather gathering in San Francisco on October 14, 2026, for people building coding agents or projects on top of them. The audience is not simply anyone interested in artificial intelligence. It is made up of engineers, experimenters, and project builders who are already putting these systems into concrete construction work. The event is framed as an agentic show-and-tell, where participants are encouraged to share what they are working on without preparing a formal presentation.
The constraints on the event reveal more than its date and location. The organizers explicitly welcome unpublished work, strange experiments, unfinished projects, and attempts with no obvious market. They also stress that the evening is not for product pitches, but for exploration earlier than the product stage. For a technical leader, that means the central question is not which model tops a leaderboard or which mature product should be procured. It is how coding agents are being fitted into real workflows, and which parts still lack a stable answer.
“Unfinished” Is a Methodological Signal
A field with stable demand, clear boundaries, and standard delivery practices usually organizes its events around case studies, performance metrics, interfaces, and commercial outcomes. This gathering does the opposite by inviting people to bring things they have not yet figured out. That is evidence that coding agents remain in a methodological trial-and-error phase. The supplied knowledge graph links Agentic Engineering directly with coding agents and records experiments involving an OCaml compiler, rclone, and native user interfaces. Those connections show that practice is spreading across different problem areas, but they do not establish a unified paradigm.
“Strange” is therefore more than a description of the event’s atmosphere. It suggests that much of the value still comes from local experiments by individuals or small teams rather than from reusable architectural patterns. The material offers no shared metrics, project results, or validated engineering standard, so the gathering cannot be treated as proof that a particular method has been accepted. The more precise reading is that participants are still working out how to divide tasks, when to involve people, how to adjust after failure, and how to turn an accidental success into a repeatable process.
Why Continuous Conversation Exposes Agent Friction
Experience in conventional software engineering can often be packaged as documentation, interfaces, and test cases. The behavior of a coding agent depends more heavily on how task context is assembled, how tools are connected, where a human takes over, and how the workflow changes after failure. A presentation can show one successful path, but it rarely captures the repeated edits, wrong turns, and manual rescue that were left out. Those omitted details often determine whether another team can reuse the system.
That is where continuous conversation and informal demonstrations matter. Participants do not have to turn an experiment into a complete story before discussing what they tried, what they learned, and what remains unresolved. For teams building internal agent systems, this may be closer to engineering reality than a polished success case because it preserves the points of friction. Lower barriers do not create higher comparability, however. Without shared demonstrations or metrics, experiences remain difficult to compare and may stay confined to a small circle of early adopters.
Technical Leaders Should Treat It as a Workflow Laboratory
This gathering should not be treated as a procurement list, and it cannot replace an evaluation of a specific coding agent. Its value is closer to an observation window for identifying which workflows are being tried repeatedly, which failure modes lack durable solutions, and which needs have appeared before products exist. Instead of recording that a model “works well,” a team should record the task boundary, the tools the agent may call, the points of human intervention, and who is responsible for correction after failure.
That also changes how an organization should evaluate agent projects. In the early phase, it should preserve more than the final generated code or a single successful demonstration. Inputs, tool calls, human edits, and failure causes are needed to determine whether an insight comes from a stable workflow or from one person’s familiarity with the context. If every experiment is immediately presented as platform capability, the team will make premature promises about reliability, cost, and delivery scope while the underlying method is still unstable.
Validation Separates Community Experience from Engineering Practice
A low-commercial-pressure setting has a clear advantage. Participants can bring experiments without a market story, without polished packaging, and even without a convincing explanation of what they are doing. In a field that is still taking shape, such a space can reveal pain points that have not yet become products and can keep failure from being rewritten as success. For a technical leader, the goal of joining or organizing a similar exchange should not be to bring back a fashionable term. It should be to find a hypothesis worth rebuilding in the team’s own environment.
Exploration does not automatically become a standard. Any practice brought back from the gathering still needs to pass tests involving a clear task boundary, reproducible inputs, failure records, and explicit ownership. The cost and location of human intervention must also be understood. The material does not indicate that this event will produce standards, benchmarks, or a unified conclusion. The safest reading is that it offers a view of agentic engineering culture taking shape, not proof of maturity. Agentic engineering crosses from experimentation into production only when unfinished work becomes a testable workflow with explainable cost and stable responsibility boundaries.