Future Frontend 2026 - Recap

Author: Juho Vepsäläinen

Future Frontend 2026 took place 8-11.6.2026 at Dipoli, Espoo. The conference ran 8-9.6, followed by workshops on 10-11.6. This year the conference had separate days for design and development, and I'll cover the main bits of the event in this post. This event was most likely the last Future Frontend as we're pivoting towards AI in the form of SDLCAI (13.10, Espoo, Finland) seminar to see if that could become a whole conference.

Opening#

We kicked off the event on a relatively sunny morning 8.6.2026 at Dipoli, Espoo. The venue was the same as last year except now we used the main hall instead of the backroom. Mostly this worked well, although we still had some minor audio issues that seem almost unavoidable at this particular venue. The event was hosted by our MCs Tuuli Tiilikainen and Henrik Rinne. Roughly 140 people showed up for the first day focused on design.

Design day#

When crafting the program for the conference, I wanted to maintain separate days for design and development and treat the whole program as a cohesive whole. The idea was to focus first on the question of "why" and then go into "how". The first day covered designing futures, the future of work, resilience, and accessibility.

Across the day, the talks kept returning to agency. Who gets permission to act? Who gets included or excluded by the systems we build? What happens when products, teams, or bodies are pushed beyond sustainable limits? It was a design day in the broad sense: less about pixels and more about the consequences of decisions.

I think these kinds of questions become increasingly important as work becomes more about engineering and product design than ever before now that development is getting outsourced to machines. Even if you don't like it, most likely you'll have to learn something about design as a developer and my feeling is that people appreciate the day and this sentiment.

Designing futures#

Pasi Sillanpää and Joe Macleod opened the first themed session by looking at product design from broad, long-term perspectives.

Pasi argued that organizations do not usually suffer from a lack of ideas. They suffer from a lack of permission. Drawing from the turnaround of the USS Santa Fe, the creation of the iPhone, and examples from Finnish industry, he showed how innovation often appears when people are trusted to state intent and act instead of waiting for approval. His practical advice was simple: start from the customer, write ideas down before group discussion, and do not dismiss unfamiliar ideas too early.

Slides · Drawing

Joe brought the other end of the product lifecycle into focus. In "Endineering", he argued that digital products are designed to start, grow, and accumulate, but rarely to end well. That creates bad offboarding, lingering digital waste, and especially serious problems for AI systems that are difficult to decommission. His question, "how does this end?", is a useful design prompt for subscriptions, games, AI products, and even the businesses that build them.

Slides · Drawing

The panel made the two talks feel connected. Permission to begin and responsibility to end are not opposites. Together, they describe a healthier product culture where teams can explore without pretending that every system should live forever.

Future of work#

Laura Snellman-Junna and Anastasiia Zvenigorodskaia continued with perspectives on how work is changing.

Laura defined agency as "influence on purpose". Her point was that builders already shape the future through daily choices about what gets built, automated, measured, and prioritized, but often underestimate that power. Agency becomes stronger through practice: understand your skills, take ownership, observe the evidence that your actions mattered, and repeat. Her story of founding Wonna at 44 made the theme concrete. Sometimes the main missing piece is seeing that someone like you can do the thing.

Drawing

Anastasiia approached leadership growth as a systems problem. Instead of waiting for heroic managers or accidentally promoting the loudest high performer, teams should define what kind of leadership their organization needs, make expectations explicit, and grow candidates through gradually increasing responsibility. A recurring warning was that trust matters more than raw output. A low-trust high performer can damage a team faster than a reliable person with trainable skill gaps.

Slides · Drawing

The discussion after the talks touched on the tension between formal management and self-managed teams. A useful throughline was that leadership is not only a title. It can also mean taking ownership of a process, asking the question nobody else asks, or making good work visible, so the organization can learn from it.

Resilience#

Darío Gutiérrez Mori and Georgios Diamantopoulos continued the design day with resilience as the focus.

Darío introduced permacomputing as a way to question the assumption that every problem needs more technology, more consumption, or more productivity. He connected software bloat, over-digitalization, AI dependence, and hardware waste into the same pattern: efficiency gains get consumed by more demand. The practical side was familiar to web developers, including smaller pages, fewer dependencies, longer hardware lifetimes, and local-first thinking. The harder side was social: individual choices matter, but structural incentives have to change too.

Slides · Drawing

Georgios followed by turning resilience toward the maker. Developers know how to design redundant systems, feedback loops, graceful degradation, and recovery paths, but often fail to apply the same thinking to their own bodies. Using his own MRI results as the case study, he showed how sitting and chronic stress create quiet decline before anything feels broken. His proposed system was not willpower. It was identity, environment, small defaults, feedback, accountability, and recovery.

Drawing

Accessibility#

Daniel Yuschick, Ramona Schwering, and Tejas Kumar brought accessibility and UX back as essential frontend and product concerns.

Daniel took the audience into forced colors mode, a Windows accessibility feature that overrides author colors with user-defined system colors. The key lesson was that this mode is not opt-in. If your focus state is a box shadow, it can disappear. If your button is a div, it may not receive the right system styling. Transparent borders, semantic HTML, @media (forced-colors: active), and layered communication through text, icons, and color make interfaces survive when visual assumptions are removed.

Slides · Drawing

Ramona used Portal as the frame for a talk about login accessibility. A broken login is not a minor bug if it silently blocks a screen reader user from entering the product. Through a live React demo, she added role="alert", aria-required, aria-invalid, and aria-describedby to make errors perceivable and connected to the right fields. She also covered authentication traps: do not disable paste in password fields, offer multiple sign-in paths, avoid CAPTCHA where possible, and make MFA forgiving.

Drawing

Tejas connected accessibility, AI, and product taste. If AI lets more people generate code, then taste becomes the differentiator: the ability to judge quality against external standards and apply that judgment consistently. He described the current web as hostile, full of cookie banners, sign-in walls, and dark patterns, then showed how agents and MCP apps can bring data into a trusted user environment instead of forcing users through hostile pages. The warning was that AI can remove friction, but only taste keeps the result humane.

Drawing

The joint Q&A tied the session back to safety. Accessibility work is part of making systems safer, not a separate checklist. The speakers also emphasized visible evidence: show management the broken experience with a screen reader or Lighthouse report, then connect the fix to users, law, and business impact.

Development day#

The second conference day focused on development and the question of "how". The program moved through simplicity, architecture, agentic development, and agentic use cases.

Where the first day asked what kind of systems we should build, the second day focused on how we build them. The strongest theme was that the platform and AI tooling are both getting more capable, but capability does not remove the need for taste, architecture, intent, and verification.

Simplicity#

Una Kravets and Juho Vepsäläinen started the development day by considering what simplicity gives web developers.

Una showed how much modern UI work the platform can now do natively. Her five principles were to respect user preferences, reduce noise, support natural interactions, guide navigation, and adapt to the form factor. The examples ranged from light-dark() and contrast-color() to popovers, anchor positioning, scroll-driven animations, view transitions, and container queries. The larger point was that in an AI-assisted era, knowing what good patterns exist may matter more than remembering every syntax detail.

Drawing

Juho traced hypermedia from Otlet, Bush, Engelbart, and Nelson to today's htmx and Datastar style applications. His argument was that many apps do not need the full complexity of SPA architecture. If state can live on the server and the browser can receive small HTML updates, the application can be lighter and easier to reason about. The agentic angle made the old idea feel current: hypermedia affordances tell humans and machines what actions are possible next.

Slides · Drawing

The panel sharpened the tradeoff. New browser features do not have to break older experiences if they are layered as progressive enhancement, and hypermedia does not mean abandoning modern UX. Both talks were about using the simplest capable tool first.

Architecture#

Matthew Mamonov and Rashmi Suralkar followed with a session on software architecture.

Matthew live-coded a map-based review application to show that frontend code benefits from clean architecture too. The naive version mixed Vue.js, MapLibre, HTTP, debounce logic, and business behavior into one component, making tests painful. The layered version split entities, interfaces, use-case services, repositories, adapters, and the composition root. That made it possible to swap Photon for Nominatim, MapLibre for OpenLayers, and even Vue for Svelte without touching the core behavior.

Drawing

Rashmi proposed an AI-first frontend architecture where UI is generated from user intent instead of forcing everyone through the same navigation flow. Her e-commerce demo used a constrained component registry, live business data through MCP, and an LLM reasoning layer to assemble a shopping experience around the user's request. The important constraint was that the AI should compose approved components, not hallucinate arbitrary UI. In this model, frontend developers become context architects as much as page builders.

Slides · Drawing

The Q&A showed a healthy disagreement about how far AI should go. Matthew emphasized that good architecture makes systems easier for both humans and agents to work with, while Rashmi stressed that developers still need to verify and shape the experience. Testability came up as a signal of architecture quality, but not the whole definition of it.

Agentic development#

Ohans Emmanuel and Christoffer Niska explored how agents are changing the way software is built.

Ohans described the AI velocity trap: coding agents accelerate the build phase, but code review, QA, and monitoring do not automatically scale with them. His answer was to treat intent as a first-class artifact. Teams should capture what they want and how they know it is done, review plans before PRs, use QA agents against deployed previews, and monitor production after merge. The harness around the agent should be zero-trust, checking output against intent instead of trusting a favorite tool.

Slides · Drawing

Christoffer went one layer deeper by describing Acolyte, his own open-source coding agent. Building it showed that agents are mostly loops: prompt, model response, tool calls, appended results, repeat until a signal says done. His surprising lesson was to trust capable models more, not less. Guards, evaluators, and complicated mode systems added cost without improving output, while skills, deterministic harness logic, and smaller context worked better. The practical warning was also clear: vibe-coded output still needs timely review.

Drawing

The panel made the new developer role concrete. Engineers are moving from typing every line toward setting intent, reviewing plans, checking architecture, and verifying results. That shift is powerful, but it raises a hard learning question for juniors: if judgment used to come from writing a lot of code, teams need new ways to teach verification.

Agentic use cases#

Alex Booker, Tony Kovanen, and Rachel-Lee Nabors closed the conference by looking at concrete agentic use cases.

Alex and Tony presented Mastra as a TypeScript framework for building agents at the application layer. The demos moved from a simple weather agent to observational memory, workflow orchestration, human-in-the-loop approvals, and client-side tools that let an agent modify UI in real time. Their message was pragmatic: use workflows when you need determinism, keep agents small and specific for safety, invest in traces and evals, and do not hide every agent action on the server if the user should approve it.

Drawing

Rachel-Lee closed by revisiting the browser from the agent side. If agents are becoming a major class of web user, websites need affordances for them too. She compared MCP servers, MCP apps, and WebMCP, then demonstrated a rebuilt comic site that agents could search, read, and navigate. The talk was both practical and unsettling: expose structured tools now, watch the legal and standards landscape, and remember that the web may increasingly serve humans, standalone agents, and browser-using agents at the same time.

Drawing

Workshops#

The conference week continued with workshops on 10-11.6.2026. Ohans Emmanuel ran "Agent Skills driven design" workshop first and then Joonas Pajunen gave with his "Claude Code Development & Workflows" workshop. Both workshops were somewhat full, and it seems people had a lot to take back home from them.

Community notes#

This year's conference generated a healthy amount of recap kind of posts and other media. I've included links to them below:

Closing#

I want to thank everyone involved in this year's conference including our speakers, attendees, volunteers, sponsors, partners, and the production team from Polygame and of course our artist Timo Leppänen. Special shoutout goes to Ohjelmistofriikit, Nitor, and Alma Media for sponsoring us.

As mentioned in the beginning, most likely this was the last Future Frontend conference to run. That said, I hope you consider participating in our SDLCAI seminar (13.10, Espoo, Finland) as endings are new beginnings. If SDLCAI seminar works out, most likely there will be a related conference next year so do participate if you like what we are doing!