I had a blast at ElixirConf 2026.

Keynote — José Valim

• José gave an introduction to set-theoretic types — a long-running work in progress.
• Set-theoretic types make it possible for authors to specify types using sets like unions, intersections, and negations.
• The system is gradual: the dynamic() type bridges typed and untyped code, so existing Elixir keeps compiling while the checker still flags code that will certainly fail. See Gradual set-theoretic types and The Design Principles of the Elixir Type System by Castagna, Duboc, and Valim.

Update from the Nerves Core Team — Jon Carstens

• Small embedded devices now exceed the specifications of the machines the BEAM was originally designed for. It makes sense for embedded devices to be a target platform for Elixir.
• nerves_burner downloads a pre-built Nerves firmware image and writes it to a MicroSD card.
• nerves_discovery — run mix nerves.discover to find Nerves devices on the local network.
• Nerves Desktop
• Nerves Kiosk
• Nerves Starter Kit (Protolux Electronics)
• Nerves 2.0

Hologram — Bart Blast

• Hologram takes the Elixir application’s expanded AST and compiles it to JavaScript.
• Hologram also builds an Elixir/Erlang runtime in JavaScript.
• The Elixir application can then execute on the above runtime.
• The approach is somewhat inspired by Svelte.
• A local-first approach means that the UI is never blocked by the network.
• See a 2019 Ink & Switch essay about local-first software.
• In Hologram, actions in the browser call commands on the server.
• Components subscribe to channels.
• A lightweight DSL describes the above.
• Migration is a function between two schema versions, rather than a one-off mutation — this means clients don’t have to update immediately to continue using the application.
• Regarding DSLs, reducing code duplication and diffs makes agents easier to use.

Let it Crash — Stephanie Lane & Joe Harrow

• The Observer CLI looks handy.
• BEAM processes can be visualized in dashboards like Grafana.
• When writing Elixir, authors need to think in terms of the BEAM’s architecture — supervisors, processes, messages. The actor model, essentially.

A Dev Environment for Every Branch — Jason Axelson

• Jason came up with a clever way to create and switch between environments for each branch — Fast Worktree.
• Fast Worktree is a bash script which manages tmux sessions, copying of assets, database instances, ports, a Caddy config, and GitHub issues.
• He had a great quote: “Treat [git] worktrees like cattle, not pets.”
• With agentic development, an easy way to manage multiple local environments is going to be crucial.

Round Table Discussion — AI and Junior Engineers

• Engineers (regardless of experience) should be able to explain the code they write VS Engineers should focus on “architecture” and avoid creating pointless bottlenecks — the code is disposable.
• Junior engineers will no longer have or be able to get jobs VS Junior engineers armed with AI provide more value than ever.
• Demand for software engineers will increase VS Demand for software engineers will decrease.
• Will more small- to medium-sized businesses form and successfully compete with large corporations?
• Will AI lower the appeal of software engineering due to its removal of the “craft” which initially drew many to the profession?

I don’t see consensus among software engineers on how to handle AI.

Agent Self Determination — Chris Ertel

A thought-provoking talk.

• Can the BEAM itself be used as the orchestration framework for agents?
• Imagine agents as actors and tool calls as side effects.
• What if we had a stack of context — not subagents?
• Move functionality into tool calls as soon as possible for more determinism.

Chris is only scratching the surface here. Elixir/OTP seems like an ideal platform for an agent harness.

The Agentic Experience Crisis: How Juniors Become Seniors in 2026 — Bruce Tate

An overview of principles/discoveries which Bruce has found helpful.

• Agents tend to write accurate Elixir.
• Ash is a cheat code.
• Outcomes from vibe coding can be similar to the Vasa.
• There is a tendency to pack too much into too few changesets.
• Agentic engineering is a trainable skill.
• Principle: Portion Control — work in small changesets which you can understand.
• Principle: Red/Green indicators — learn to look for red/green signals (e.g. Pyramid of Doom).
• Principle: Throw it away — Don’t try to rescue context — start fresh.
• Principle: Layered Designs — Teach more about Behavior, Protocol, Concurrency, GenServers; teach more architecture (less syntax?).
• Principle: Skills codify patterns and triggers.
• Principle: Anchor ideas to AGENTS.md.

Managers are collecting an AI dividend — some of it should be invested in juniors.

What Comes Next — Chris McCord

• I found it curious that barely any mention was made of the Phoenix framework.
• Outcomes from agentic development vary; there is an element of operator skill (“prompt engineering”) that we haven’t learned how to articulate or teach. Some operators use skills, others don’t. Some have a natural intuition for agents, others are still learning. Agents are not an automatic win.
• Possible future (the present for some): agent loops with production as the artifact.
• Agentic environments are going remote; agents have environments they can change; agents outlive their requests; agents have state.
• Not all changes involve equal risk — some changes need more review than others.
• Look into sprites.
• The language runtime is part of the loop.
• As goes programming, so goes the world.

Erlang Ecosystem Foundation — Dan Janowski

• They need more funding.
• Erlang Ecosystem Foundation — the foundation itself
• Membership — individual and company membership
• Communication — the community communication hub
• Registry — a directory of companies building with Erlang, Elixir, and Gleam
• Sponsorship — funds the working groups, security advisories, and community events
• CNA — the CVE Numbering Authority for the BEAM ecosystem, assigning CVE IDs for vulnerabilities in Hex packages

Round Table Discussion — How Should Engineering Managers Adapt to AI?

• Everyone has the meat proxy problem.
• Everyone struggles with over-reliance.
• Agents should label their own contributions.
• Some teams require writing merge/pull request descriptions by hand.
• Spend time reviewing plans/architecture decision records before implementing.
• Some teams find that review takes longer because agents create so much noise.
• Other teams find the opposite and report large increases in shipping cadence.
• The optimal team size is probably going to shrink to 2–3 engineers.
• Some teams encourage individual exploration with agents, like twenty percent time.
• Use agents to encode architectural decisions in the linter.

Breeze and TUIs — Gary Rennie

Gary has created an insanely complete terminal/text UI library called Breeze. I’m definitely going to use it for a few experimental projects.

Stop Routing; Start Flowing: Guided Workflows in LiveView — Matt Milton

• Out of the Tar Pit — Paper
• Matt suggests creating a state machine for guided workflows.
• A failed attempt is the absence of transition (the movements between states).
• Routers can turn into state machines, accidentally.
• Workflow data can be stored in a struct; the struct includes state such as whether or not we can move to the next view.
• Screens own switches; workflows own transitions.
• Screens implement callbacks which are used by the workflow engine.

What Expertise Looks Like — James Gray

• The best way to understand how a proposed change will work in production is to measure the change by deploying to production.
• Mine production for intent — this is why observability is important.
• Knowledge comes from failures.
• With agentic development, failure occurs less — a good thing with a bad consequence.

Exoskeletons; Not Autopilots — Zach Daniel

Build AI for your team, not instead of your team.

Path

1. Learn to use the prompt alone
2. Learn to use AGENTS.md
3. Write human-facing documentation in docs/ (Focus on what is good for the humans, and make your agents use that. Not the other way around.)
4. Build a bot — run in an engineering harness

Useful things:

• mix hex.search searches the docs of all Hex packages in the current project
• Usage Rules copies/updates usage rules for Hex packages so that agents can read them

The Bot

• Agent participates in human-centric knowledge generation and curation.
• Run directly in CI.
• Run on a dedicated server, stateful.
• Fit agent to human workflows — add as a project member.
• Proactive; nightly run to keep docs up to date; craft handbook; find issues; perform QA; write release notes; manage work; tell people who aren’t working together that they should be talking to each other; adjust target dates for projects.

Home Base

At Remedy, Zach & team built something they call “Home Base”. It’s a dashboard/intranet for team-agent interactions. AI makes it possible for teams to build internal tooling like this.

Reflection

• It’s curious that the talks given by major framework authors (e.g. Chris and Zach) included barely any mention of the frameworks themselves, and instead were focused largely on AI. Will frameworks become less important?
• We’ve known for a while that compared to other languages, agents work well with Elixir. DSLs and metaprogramming are going to play a role reducing the cognitive load required to review an AI-generated changeset.
• Elixir/OTP looks like the ideal platform for an agent harness.
• I’m eager to try Hologram; Bart’s demo of a real-time local-first experience was impressive.
• Casual conversation showed how widespread the use of Elixir is. Sand mining, trucking and logistics, healthcare, SaaS control planes, sales, marketing, political campaigning, and space, to name just a few industries.

I had a great time hanging out with friendly, creative, and inspiring nerds.

I’m looking forward to next year.