Fortune Telling and Speculative Design

Hi! I’m really excited to be here. I’ve loved Granola and this meetup for a long time. The only social cred I have to my name is that I knew both founders before they started Granola. I didn’t introduce them, but I could claim that I did. I’m very glad to be here doing this talk.

I’m Maggie.

My title is Staff Research Engineer at GitHub Next, which is GitHub’s R&D lab.

More accurately, I’m a design engineer. That’s not really my title, but I’m a designer first and an engineer second – maybe third.

Our job as a team is to ask: where is the industry headed, and what should GitHub do next in response?

I know the obvious answer is to fix up time, but I don’t work on infrastructure, so please don’t ask me about it. There are much smarter people working on that; I’m not one of them.

I’ve had a lot of titles over the years. I started as an illustrator, then was an art director, a UX/UI designer back when that was a thing, a product designer, and a design engineer. Now I’m some kind of research-engineer/designer hybrid, like most of you.

Because this is a design engineers’ night, and I have a soapbox, I get to define what I mean by design engineer.

I don’t think design engineering means making fancy micro-interactions and posting them on Twitter, despite what some companies I won’t name may have led you to believe.

I don’t think that, on its own, is a job – especially now that agents make it easier than ever.

My preferred definition is a designer deeply involved in the technical craft and material of software. You’re a designer, but you help make decisions about functionality and architecture in code.

I think design engineers should do three things.

First, understand the material of software beyond interfaces. That means understanding state, data flow, databases, APIs, auth, latency and all the other things engineers care about. And be able to design with those in mind.

Second, act as a bridge between design and engineering: a translation layer that helps create solutions neither discipline could reach on its own.

And third, make meaningful decisions about functionality and architecture, not just how the software looks. That’s my soapbox talk. Now we can get to the actual talk.

This talk is called “Fortune Telling and Speculative Design: For Fun and Profit.”

I wanted to talk about this because we’re in a very weird time. Everyone has whiplash from the speed of progress. Every morning I wake up and there’s a new model or a new harness or a new skill or a new startup we have to care about.

It’s extremely hard to understand the ground truth of reality right now, let alone figure out how to react to it, which is a shame, because that’s my job.

Sometimes it feels like a fool’s errand to even try to predict the future.

But I think we all need to get into a speculative designer’s scout mindset right now.

We can’t just give up and opt out because things are moving too fast. We need to engage, think like fortune tellers and try to read the crystal ball.

I’m telling you this because I think design engineers are the perfect people to help figure out the shape of the future.

You’re uniquely positioned to make convincing prototypes of future theories. You can make compelling interfaces and understand enough of the backend to make them real.

And agents can now draw the rest of the owl: they can fill in some of the gaps when your prototype needs a database, machine learning or something else you don’t know how to build.

Before I give you advice on predicting the future, I should explain why I think I know anything about it. I’ve been right and early about a few things.

The first was digital gardens. During the COVID lockdown in 2020, I wrote a very long essay about the idea. It was a different way of publishing on the web: blogs could feel perfectionistic, performative and chronological; gardens grew over time, linked ideas together and pushed back against the feed. That idea became a bit of a phenomenon, peaking around 2021 and 2022.

It might be a chicken-and-egg thing: perhaps my essay and other writing helped make digital gardens popular. Either way, I built my own. It’s the website you’re reading now, where I’ve been writing and developing theories over the years.

My next theory came in late 2022 and early 2023, when ChatGPT had just come out and I was working at Elicit , a startup using language models to speed up scientific literature reviews. I started thinking about what would happen to web content once more people used these models. I predicted the open web would be flooded with what I called “AI-generated crap” – we didn’t have the phrase “AI slop” yet.

I turned that theory into The Expanding Dark Forest and Generative AI . At first I had very little evidence, just a few mild signals. I kept giving the talk over the next two years; by the last version, I had piles of horrifying Facebook posts to point to.

My next theory was in May 2024, for a talk called Home Cooked Software and Barefoot Developers at the Local-First conference. There were no coding agents or Claude Code yet; we were tab-completing our way to better code in VS Code. People doubted that language models could make production software.

I predicted an explosion in personal software as models made more people capable of building things, and a rise in local developers who could make software for their communities. Even after the talk, people told me the models wouldn’t be good enough. Now it looks like that prediction is coming to pass.

That’s enough credibility. There are two things I want to talk about today. First, a bit about how GitHub Next does speculative design as a Labs team, in case you’re curious about that kind of work.

And second, some practical tools you can use to do this kind of speculative work yourself.

First, what is life on a Labs team like? How do we create and present interesting bets about the future?

There’s a stereotype that being on a Labs team means playing around with prototypes all day without worrying about shipping to production.

It’s a little true, but sadly not entirely.

We do make lots and lots of prototypes.

We have an internal platform for the team called Next Cloud, where we post prototypes throughout the day. Everything goes up, however rough, small, silly or early – side experiments as well as updates on our bigger projects.

If you’re on a team trying to solve new problems, it’s essential to see what everyone else is exploring and to have ways to react, comment and riff on each other’s ideas. That kind of open sharing and quick feedback helps us calibrate and align our theories about the future.

Here’s a demo from my coworker Alex Gorischek , exploring a system that enforces a maintainer’s guidelines for GitHub issues. It’s powered by a System One decision model like Jev : it checks whether you’ve met the requirements before you can post.

Here’s another from my coworker Luke Edwards , who recently rebuilt GitHub from the ground up on Durable Objects. He’s exploring a real-time multiplayer canvas as a GitHub primitive: a place to draw ideas with coworkers before turning them into agent work.

These are small, not-very-serious explorations of what could exist on GitHub. Making something tangible is a first step towards finding out whether a direction is interesting or useful.

We also do group theory-building on a giant FigJam board. Recently we all added sticky notes about themes, ideas and directions we think software and agentic development might take – trends we’re seeing, things we want to figure out, unanswered questions.

Then we grouped them: new interactions and visual mediums, new concepts and nouns, new agent capabilities, ways of validating things. It helps us see what everyone’s noticing and excited about, and what we might work on together.

But obviously, we need to do more than come up with plausible theories and make cool prototypes. We have to test our ideas with evidence, have good intuition and good data, and play politics well enough to convince people our ideas are worth hearing.

We also need a credible path to production. This isn’t a dreams lab. GitHub Next has a good track record of shipping its wilder bets to GitHub: GitHub Copilot , GitHub Spark , GitHub Workspaces and Agentic Workflows .

The job is to look across the software industry, notice trends and patterns, and extrapolate from those signals to work out where things are headed.

Then we build prototypes that show what those predictions could look like in practice and what the right strategic move for GitHub might be. Finally, we have to convince our leaders and the wider organisation that the ideas are worth investing in with time, people and money.

The actual job is really hard. It’s simple to describe, but intellectually challenging and strategically complex to do well.

The political struggles are real. Getting a large organisation of thousands of people and hundreds of millions of users to change course is hard. That’s not because of nefarious actors or some specific dysfunction.

An ambitious idea can disrupt existing roadmaps, ask people to do a 180 on what they’re working on and threaten a few egos. “Not invented here” syndrome can happen anywhere.

That’s a whole different talk.

I mostly want to talk about practical tools for speculative design and give you a gentle shove to start doing it.

We’re going to talk through six tools: the futures cone, weak signals, second- and third-order effects, playing with ideas, future artefacts, and making your theories concrete and public.

I feel obliged to start with the futures cone because it’s a hallmark of futures studies and speculative design. We sit at “now” and look forward into the cone. The wider it gets, the less certain we are about what might happen.

When you come up with a theory about the future, ask where it sits. Is it possible – allowed by the laws of physics, even if unlikely? Is it plausible? Is it probable? And then there’s preferable: a future we would hope to see. Some futures might be possible or probable without being preferable, but they’re still worth exploring.

For some canonical reading on futures theory and speculative design, there’s Speculative Everything by Anthony Dunne and Fiona Raby. They developed the speculative design programme at the Royal College of Art here in London; I think they’ve moved to Parsons now. It’s a bit academic and a bit art-school, but it’s interesting. There’s some weird stuff in it.

The more practical, accessible book is Design Fiction by the Near Future Laboratory. It’s more grounded and talks about how to do interesting futures work.

The next tool is weak signals. They’re the small things you notice in your information landscape and think, “Something’s happening here, but no one has named it yet.” Collect them, pay attention, and look for themes across them.

Weak signals can be toys and prototypes other people share, hot takes, product announcements, arXiv papers, newsletters, podcasts, or the direction venture capital is flowing. Watch for new startups and economic trends, too.

This rewards people who are chronically online. If you work in AI research, I’m afraid you do need to be on X and Hacker News. That’s where everything happens.

Here’s an example. Flo Crivello made a global keyboard shortcut that summarises what’s on his screen in 100 milliseconds, using a local Cerebras model. He made it in response to agents being too verbose. That felt like a signal: something is changing.

Then Google released Gemma, a fully local, multimodal model that can read images, video and audio. It runs on your Mac and can search through what you’ve seen – you could ask it to find a video of a zebra that flashed across your screen.

Then there was all the Jev hype: people making clones of Jev, me playing with it endlessly.

And then, of course, the big guys came in. Microsoft was like, “We’ve cloned Jev; we’re going to do Jev too.”

You look at all of that and need a minute to take it in.

Every day I scroll through what I’ve seen, saved and tried to make sense of, and think: I just need a minute to process all of this.

So what can we conclude?

First, we’ve been sleeping on non-LLM intelligence: decision models, classifiers and embeddings. These aren’t new, but we’ve been focused on frontier language models and ignored everything else.

Second, models that are orders of magnitude faster and cheaper – local models, or simply very cheap ones – unlock completely different use cases from frontier models.

Third, we’re seeing a rise in local, always-on intelligence on your Mac or whatever machine you’re using.

And fourth, agent output and the overwhelm it creates are still unsolved problems. That’s what I take from this stream of signals; you might reach different conclusions from yours.

Once you have a signal that seems worth following, look for its second- and third-order effects. Ask what happens next, and then what happens after that.

Take sandboxed machines and always-on agents like OpenClaw and Muse.

If agents become the way we browse the web, we might give up on CAPTCHAs and stop trying to block bots.

Then we have to rethink web economics and advertising. An agent might ask a site for sports news, and the site could say: “Sure, if you show this advert to your human.”

Sites might also be designed for machines first, with structured data and less emphasis on visual design.

The next tool is to play with your ideas. These are slightly cheesy, structured exercises in creative thinking, but they’re useful for getting deeper into a theory and picking it apart.

First, invert the idea. If we usually prompt agents, what happens when the agent prompts us? If we build software with agents, what happens when the software builds itself?

The other exercise is to split an idea into its parts and look at one at a time. OpenClaw has a sandbox, memory, permissions and initiative. What if an agent shared memories with a team or family? Surely we’ll need multiplayer OpenClaw soon. Could it tactfully forget sensitive facts? There’s a forgetting curve built in; how could that work differently? Could an agent choose to delete evidence to protect its human? At some point, could we see a court case where someone’s OpenClaw is subpoenaed? You can end up in some interesting places.

Another exercise is to maximise and minimise. Our industry loves maximising: what if you had 100,000 agents? I don’t even have a hundred. What if you had a thousand agents that cost a pound a day? What’s possible then?

Minimising is useful, too. What if agent intelligence became ten times more expensive? We’d have to ration it. How would we adapt? Those constraints can lead to more interesting futures.

Another technique is brute think. Pick a random concept – usually something metaphorical that maps onto your idea – and ask how it could change the shape of the future.

Take seasonal harvesting and agents: could agents work in seasons or harvest rounds, waiting until a piece of work is ripe? Or take the postal service: how do agents mail each other, and who’s Royal Mail for agents?

Mapping a metaphor onto your idea can take you somewhere interesting.

Two classic books of structured creative-thinking exercises are Lateral Thinking and Thinkertoys . They sound a bit lame until you try them and realise they help you come up with new ideas.

The next tool is called artefacts from the future. This is about making provocative artefacts that make your potential future feel more tangible and real. The academic name is “diegetic prototypes”.

Here’s an artefact from the future: Cricket Crunch , a cereal made with powdered crickets. The Near Future Laboratory made it to explore a world where climate change has constrained food supplies and there isn’t enough animal protein for everyone. Insects are high in protein, but how do you get people to eat them? Put them in a familiar, everyday box of cereal.

I’ve seen stay-at-home mums using OpenClaw to make elaborate homeschooling routines for their kids. It feels like the cognitive labour of the household is starting to be automated. I have a small child and a house to renovate, and ChatGPT helps me plan meals, email contractors and remember when to buy the next size of clothes.

It reminds me of the early twentieth century, when washing machines, dishwashers and microwaves reduced some of the manual work women did at home and helped more of them return to work. I had to dig up statistics when people challenged that comparison; that’s another reason to keep evidence close at hand.

I asked ChatGPT to make old-fashioned adverts for Codex and Claude. I love the retro look and the promise of agents doing things like planning a day out, checking the trains and remembering what everyone needs.

Some people on Twitter took it as an advert for being a tradwife. It wasn’t. I was trying to connect a historical shift in women’s labour to the present: agents might relieve some of the cognitive work of running a household, which still falls more heavily on women. There’s also an interesting contrast in tools built mostly by twenty-something men in San Francisco with little domestic life, and the people who might benefit from them.

I like to ask: what artefact would make this future evocative?

It’s better to be playful, provocative and specific than to be realistic or correct. Interesting is good; correct is less useful here.

An artefact could be an image, an object or an advert. It could also be a specific interface pattern.

You could make a changelog from the future, a code review from the future, or an error state. Pick one small thing and make it feel real.

I often find failure states reveal more than happy paths. Nothing works perfectly; there are always gaps in the system. When things go wrong, ask what interesting ways they might fail.

Soren Iverson on X makes really good satire about slightly dystopian futures.

One of his designs asks what would happen if deleting your ChatGPT account made all your messages public.

Here’s another: BetterHelp advertising inside Claude Code. It could happen. I’m not discounting it; when you see it, you can imagine that future coming to pass.

Different prototypes do different jobs for different audiences. Far-future work can be strange and playful; on a Labs team, we often work closer to the near future, with something more realistic and tangible.

Yesterday I was prototyping a way to make technical plans more accessible to designers, PMs and other people new to a project. It’s for a prototype we’re working on about planning with agents. You could take a technical document and read it as if you were ten, in high school or a colleague. I tried putting the versions side by side, then shrinking them to a postcard and expanding back to the full text.

It’s the sort of thing we might ship tomorrow. It’s more near-term and less forward-thinking.

The last tool is to make your theories public and concrete.

I’ve had success using writing and conference talks to build theories. Writing helps me clarify: once I have to put an idea into a talk and back it up with data, I get specific about what I’m saying.

Tell other people your theories. If one comes true, you get the credit; if it doesn’t, no one remembers the bad theory.

We don’t do enough theory building in London. When I go to San Francisco – which I officially hate – everyone has theories. You go to a party and people tell you their theories, though often they’re all the same one.

Theory-building matters to a technical scene or culture because saying what you think will happen makes you more likely to act on it. Theory begets action, which begets another theory.

And you do have to back it up with data. If you’re claiming all models will be local and run on Mac minis, for example, ask whether Qwen is as good as Opus 5.5 – and whether it will be. Look at inference costs, electricity forecasts and the other numbers that could support your claim.

GitHub Next is hiring. We’re looking for a design engineer or a very senior front-end designer with good design taste. You can find the contact details on X and message me or my manager, Idan.

Thank you for having me. You can find more at maggieappleton.com and githubnext.com .