If I Started My Career Today…

Last year I shipped an entire ERP as a single engineer working with a team of AI agents. I watched three agents investigate the same production incident and confidently disagree about the root cause. I interviewed ten practitioners about agentic adoption for a peer-reviewed study. So when someone asks me whether starting a software career today is a mistake, I have material instead of opinions.

This is a career talk grounded in that material. What actually changed: the unit of work one person can own. What did not: someone still has to answer for what ships, and the machine cannot. We look at what junior and senior roles become when writing code is cheap, which skills compounded in value (reading code you did not write, architecture, evaluation, saying no), which quietly stopped mattering, and what I would honestly do differently if I started today.

No doom, no hype, no LinkedIn inspiration. Real stories from real projects, including the ones where the agents made everything worse. For developers and architects at any career stage wondering where they fit in the agentic shift, and for the people who mentor them.

I shipped an ERP alone with a team of AI agents, then watched agents confidently disagree about a production incident. A career talk from that material: what the agentic shift really changes for developers and architects, and what I would do if I started today. No doom, no hype.

Give Your Agent a Computer: Azure Container Apps Sandboxes

AI agents write code, and someone has to run it. Not in your production cluster, not on your laptop, and preferably not anywhere it can reach your database. Azure Container Apps Sandboxes give agents what they actually need: a disposable computer with strong isolation, snapshot-based suspend and resume, and an egress policy that says exactly what it may talk to.

This session comes from running agentic workloads on Azure Container Apps in production and repeatedly discovering that the app model fights you: always-on services for bursty work, stateless containers for stateful tasks, and scale-to-zero settings that quietly pause the wrong workers. Sandboxes are a different compute primitive, the same one underneath GitHub Copilot's cloud sandboxes and Foundry hosted agents, and now you can use it directly.

We build a sandbox group live, let an agent generate and execute code inside it, suspend it mid-task, resume it with memory intact, and try to sneak data past an egress policy. You leave knowing when to reach for sandboxes, dynamic sessions, jobs, or plain container apps, and what the preview does not do yet.

For engineers and architects running or planning agentic workloads on Azure.

AI agents generate code someone has to run. Azure Container Apps Sandboxes give them a disposable, isolated computer with suspend/resume and egress control. Live build, live suspend, live exfiltration attempt, and a clear map of sandboxes vs sessions vs jobs vs apps.

From Container to URL Before Your Coffee Cools

Somewhere between "I have a container" and "it has a URL", Azure traditionally asks you thirty questions: an environment, a Log Analytics workspace, ingress, scale rules, registries, sizing. I know the questions well. I wrote the Bicep, and I have paid for wrong answers with production outages.

Azure Container Apps Express removes the questions. A container becomes a public URL in minutes: no environment to manage, scale from zero to hyperscale, an optimized cold start, and nothing on the bill while nobody is calling you. It is the platform-as-a-service dream rebuilt on containers, and this session puts it on a stopwatch.

We race Express against a full standard Container Apps pipeline, live. We measure the cold start, trigger a burst, watch it fall back to zero, then do the cost arithmetic with numbers from my own systems. Then we try to run something real on it and meet the fine print: the features still in development, the workarounds that exist today, and the signals that you have outgrown the express lane.

For developers who want their containers on Azure without adopting a platform team, and architects deciding where Express fits.

A container becomes a public URL in minutes: no environment, scale to zero, pay per request. I race Azure Container Apps Express against the full standard pipeline live, measure the cold start, do the cost math, and read the fine print. The PaaS dream, container edition.

A Thousand Models in the Catalog, and You Still Picked Wrong

Every AI project starts with the same question: which model? It is the wrong question, or at best the fourth one to ask. In a year of shipping LLM features to production, the model name mattered less than everything around it: whether the step needed a model at all, how the deployment was hosted and versioned, and whether anything measured when answers got worse.

This session is a decision framework with receipts. A document pipeline where the model never sees a number that matters. A chat feature pinned to a model that is now deprecated, with token prices frozen in source code. An eval judge that itself became a deployment problem.

These decisions live in Microsoft Foundry: a catalog of thousands of models, and every way to mis-deploy them. We walk what matters there: deployment types and quotas, data-zone versus global hosting, keys versus Entra-only access, version pinning and upgrade policies, and the eval harness that makes swapping models boring.

The checklist you leave with: decide where a model belongs, pick the smallest one that passes your evals, host it like it will be deprecated, because it will.

For developers and architects taking LLM features to production.

Which model? Wrong question. Where does a model belong at all, how do you host it in Microsoft Foundry, and what tells you when answers get worse? A production-tested framework with receipts: deprecated pins, prices frozen in source, judge models, and evals that make swaps safe.

"Chat With Your Docs" and Other Lies: Production RAG on Azure AI Search

Every platform now promises the same thing: point an agent at your files and it will answer questions. It will, too. Confidently, pleasantly, and just often enough correctly to be dangerous.

This session is about the distance between that demo and a system a thousand accountants use to look up answers they act on. The distance is not one missing feature. It is a different discipline at every layer: content that has to be prepared before it ever reaches an index, retrieval that plans queries instead of matching keywords, answers that stay inside what was actually found, citations that link to sources because trust is earned per sentence, and evaluation that turns "it feels better" into a number you can defend.

I walk through that whole stack as built on Azure AI Search and a custom agent, in production, in German, for users who did not lower their standards just because AI was involved. Along the way: the shortcuts that looked fine and failed quietly, the real cost per question, and the eval harness that settled every argument.

For engineers and architects who have a working RAG demo and a nagging feeling about it.

Point an agent at your files and it answers. Confidently. Sometimes even correctly. This talk covers everything between that demo and production RAG: content pipelines, agentic retrieval, grounding, citations, evals, and real costs, built on Azure AI Search for a thousand users.

Architecting Agentic Systems Like a Grown-Up

What does “agentic” look like in a real codebase? In this deep dive, we’ll architect goal-driven systems using Microsoft Agent Framework—covering tool orchestration, planning cycles, state management, multi-agent composition, and governance. We’ll apply classic engineering principles to systems that reason, act, and adapt.

I programmed a better grandson for my grandma.

In this session I am showing you how I combined the hottest AI-topics to create an assistant for my grandma, in an attempt to help her with some of the difficulties that many older people face.

Upon an edge device, I designed, implemented and deployed a solution that acts as a communication bridge between the elderly and the outer world, including care takers, nurses, doctors etc. To achieve that, it uses local resources as well as Azure resources for multiple heavier tasks.

I will go through all the challenges I faced, stretching from hardware and software to people skills and the fear of the unknown.

Anatomy of a cloud based, multi tenant, SaaS product!

In this session, I’ll walk through the real-world process of designing and building a cloud-based, multi-tenant SaaS product using Azure. From managing multi-tenant architectures and backend services to integrating the frontend, you'll get a detailed look at the challenges I faced and the solutions we implemented. This is a technical, no-fluff breakdown of what it takes to build a scalable, maintainable system in the cloud, with lessons learned and practical advice you can apply directly to your own projects.