AI-fokus Talks #1

The idea that taste is the only moat we have against AI is basically a meme at this point. Still, as many developers struggle to understand their new roles and how to provide value in a world where AI does all the coding, the idea can offer some comfort. That comfort quickly turns into confusion when you try to understand what taste actually is.This talk is about making real what many consider a "fluffy" concept: taste. We will define what taste means in AI coding, share techniques for developing your own, and cover practical ways in system design, decision making and user experience to apply it to the projects you build. I'll share stories from my own journey of going from building for "good enough" to making projects that work and feel great.There is still so much work to be done outside of typing code. You will leave this talk with a new perspective on the craft of your work and a language for communicating with AI coding agents to reach higher levels of both technical and product quality.

Anyone can get a coding agent to produce an impressive proof of concept in an afternoon. The hard part comes later. A few weeks in, progress flattens. The codebase outgrows what the agent can hold in context, earlier decisions get quietly undone, and every fix seems to break something else.

The usual reaction is to start another PoC. But new prototypes aren’t scarce in the agentic era. What’s scarce is sustained attention on one product.

This talk is the practical playbook from building ObjectExplorer.com with a coding agent:

• Architecture the agent can hold: structure the code so every task fits in context
• Features the agent can understand: write specs that turn into working code, not guesswork
• Decisions that stay made: record choices so the agent doesn’t relitigate them
• Access you control: limit what the agent can touch, including secrets, production and destructive commands
• The last 1%: spot where the agent reliably fails, and finish that part fast yourself

The patterns don’t depend on any tool or tech stack. You’ll leave with practices you can apply to your own codebase the next day.

"Spec-driven development", "context as code" and "context engineering" each cover part of a larger whole. Context-Compiled Development (CCD) is a methodology that ties them together: planning, managing plans, extracting memory artefacts and curating the project’s living architecture.

Every compiler does the same thing: it takes something written for a mind and lowers it, pass by pass, until a simpler machine can run it, without changing what it means. CCD treats engineering work the same way. The decisions, patterns and prompts that make an AI-assisted project work are buried in conversations. Extracted into sourced, reviewed archefacts, they become material that can be compiled back into plans and into the architecture those plans keep current.

I will present the "Divide, Dilute, Direct" pipeline, which lives inside the execution plan itself. Divide: group tasks by difficulty, at most eight to a group, each area carrying its own short mandatory reading list, so no agent loads what it doesn’t need. Dilute: break down whatever is still too hard, pass by pass, until it fits the cheapest model that can do it reliably, thinning the difficulty but never the intent. Direct: tag every group so a router or decision model can dispatch it, and tell each agent where to look, when to stop, and what counts as done.Plans have to be managed as living documents: checkboxes that mean verified rather than written, recovery after context compaction, and groups that split when their tasks turn out bigger than planned.

The stakes are rising. Agents are FAST, and that speed is what lets one polluted session undo days of work. Compiled context is slower to write and safer to build on.

Meet old and new friends, grab some swedish fika and refill your coffee level

Just a few years ago, building a Dark Factory for code was mere science fiction. Today we know it's possible. But possible does not mean easy...

Join me for a tour to the bleeding edge of agentic coding, where we will discuss how I created one of these wondrous machines for a client. When you leave this session you will know exactly where you will need to focus your efforts to create your own automated Dark Factory.

I built one for a client, and this session is the tour: where the agents run, what they need to run, how to steer the agents to avoid creating just slop, and how to make agents check each other through adversarial reviewers, testers that try to break the feature, and janitors that run nightly against complexity and contract drift.

You'll leave this session knowing where to focus your effort after you pitch building one of these to your boss!

Remember back when we had to convince developers that unit tests, observability and automated testing were important? We are now in the same situation with AI solutions being built.

In today's world of fast moving LLMs and generative AI, "trust me" isn't a strategy, it's a liability. AI outputs are inherently non‑deterministic, especially given the factors of different models, temperature settings, provider switches and more. So, “it worked on my AI” is not a sustainable approach. This is why you need AI-aware observability, not just classic logging.

What really defines a working AI solution? At least, it has to be measurable, monitorable, and reliable. We need robust evaluation frameworks. We'll need things like automated evals, human-in-the-loop assessment, user-feedback, or even LLM-driven judging, to confirm expected behavior and detect regressions.

You wouldn't ship a classic app without telemetry, so why treat AI differently? This talk equips developers with the mindset and tools to build AI systems that are intelligent and production-ready: traceable, testable, monitored, and trustworthy.

How we keep pace with an ever-changing model market.

New frontier and open-weight models now arrive every few weeks, and each release eithermakes your product better or leaves it quietly falling behind. At Pirr, an AI storytelling platform, we built a model-launch loop. A domain-specific benchmark, in-app A/B tests onreal user behaviour and prompt re-optimisation. That takes a promising model from release to production quickly, measured against our own quality, engagement and cost metrics rather than public leaderboards.

This session walks through that setup, what it has delivered, and the lessons and setbacks along the way.

How far can you get in five days with AI agents embedded in your development workflow? Starting with Pip, a bird from my first app, Tiokompisar, launched in 2013. I’ll show how a character that once perched on my head during a Teams meeting became a 3D character in Multiplay and the starting point for a complete game, now available in the App Store.

Built in my spare time, the game features ten levels, a multilingual learning workshop in six languages, and 1,272 recorded voice clips. The process involved more than twenty parallel agent sessions.

I’ll walk through the workflow behind the build: defining rules before creating levels, turning lessons learned into reusable skills, and having agents playtest their own levels. I’ll also share what worked, where things went wrong, and what still required the judgment and expertise of an experienced app developer.

This is a practical look at the opportunities and limitations of agent-driven development and what changes when AI agents become active collaborators in the software development process, rather than simply tools for writing code.