AI Engineer Melbourne 2026

Welcome back to day two of AI Engineer, another day full of amazing talks and conversation.

You feel more productive than you’ve ever been. You put on the Iron Man suit and now you’re building things in hours that used to take weeks. And you’re exhausted by Wednesday. The craft that used to sustain you — the flow of writing code, the satisfaction of making something work — has given way to a middle loop of supervisory engineering: directing, evaluating, and correcting AI output. You’re getting more done while enjoying it less, and that’s a tension worth navigating. If the system is producing more output while eroding joy, that’s not a you problem, it’s a system design problem. Drawing from her recently completed Masters research on AI’s impact on software engineering and conversations with practitioners and researchers at the frontier of this shift, Annie explores why this transition hits so differently for those entering the industry, those deep in it, and those who haven’t written code in years — and why who thrives most comes down to mindset, not circumstance. The good news is, that’s within your reach. This talk offers a lens to see your own situation clearly, and a path through it. Joy and pride in work don’t happen by accident. They’re system outcomes. And we can engineer the conditions for them.

This talk argues that without a deliberate focus on long horizon tasks, even the most impressive models will remain brittle and unreliable for real world applications. Short form benchmarks and isolated prompts cannot capture the complexity of extended reasoning, planning, and execution that real world problems demand. When models lack the ability to maintain coherence across hundreds or thousands of steps, they fail in subtle but critical ways: losing track of sub goals, failing to recover from errors, or drifting away from the original objective. To address this, the talk proposes a new framework for measuring and training long horizon capabilities, including explicit mechanisms for sub goal setting, robust error recovery, and sustained persistence over extended timeframes. These are not mere incremental improvements but fundamental shifts in how we design and evaluate AI systems.

Notion’s Developer Platform gives developers and coding agents the building blocks to programmatically build on Notion. Connect to external systems, bring context into a shared workspace, and take permissioned actions across your tool stack. We’ll show what’s possible with the core primitives: the CLI (ntn), Workers (Notion-hosted custom code), and the External Agent API (bring external agents into Notion as native workspace participants). You’ll see how these pieces fit together to create reliable, governed workflows where every action and output lands back in Notion for team visibility, review, and follow-through.

In 2026, most engineering teams have the frameworks, the cloud, and the AI tooling. Velocity still breaks. It breaks between commit and production - in the deployment systems, the infra tickets that sit in someone's backlog while the feature waits. This session is for engineering leaders who've modernised the stack but still can't answer why shipping feels harder than it should. We'll examine where delivery actually stalls in modern web stacks, whether managed platforms and AI are genuinely fixing the problem or just masking fragile foundations, and what it looks like when the layer between development and production finally stops being a liability.

Large AI models often struggle to meet the latency, memory, and power constraints required for real-world edge deployments. This talk explores practical techniques for making modern AI models efficient enough to run on-device using model distillation, quantization, and hardware-aware optimization strategies. Attendees will learn how to reduce model size and inference costs while maintaining accuracy, covering approaches such as post-training quantization and efficient runtime optimization across modern AI frameworks and accelerators. The session will also highlight real-world tradeoffs between performance, memory footprint, and power efficiency when deploying AI applications on edge devices.

AI demos are easy. Production systems are not. In this session, we move beyond hype and explore what it actually takes to deliver AI systems that work in the real world. Not experiments. Not playgrounds. Proper, spec-driven, commercially accountable systems. You will see how clear specifications, structured prompts, testing frameworks and disciplined engineering turn AI from a novelty into a reliable asset. We will cover what goes wrong when you skip the spec, how to avoid costly rework, and how to design AI systems that survive compliance, security reviews and real users. If you are building AI for clients, boards or production environments, this session will challenge your assumptions and give you a practical blueprint.

Large language models are often the default choice for production AI systems, even when the task does not require broad reasoning or generative depth. In this talk, I will share a real production case where an LLM-based solution underperformed on latency, cost, and reliability and was ultimately replaced, in part, by a small language model. The system in question supported a high-volume enterprise workflow involving structured extraction, classification, and validation. While the initial LLM implementation performed well in early prototypes, production usage exposed several issues: inconsistent outputs, escalating inference costs, and difficulty enforcing deterministic behaviour. These problems became more pronounced under scale. I will walk through the decision process that led us to introduce an SLM, the architectural changes required, and the criteria we used to evaluate success. The talk will cover where the SLM outperformed the LLM, where it clearly did not, and how we designed a hybrid pattern that escalates to an LLM only when necessary. The session includes a live demo showing the before-and-after behaviour of the system, along with production metrics such as latency, cost per request, and error rates. I will also discuss failure modes we encountered, trade-offs we accepted, and the signals that helped us decide early whether an SLM was a viable replacement. My aim is not to advocate for SLMs over LLMs in general, but to share the signals, metrics, and decision criteria that helped us choose the right tool for the job. I believe this perspective is timely as more teams move beyond experimentation into sustained production usage.

In the time it takes to train a frontier model, the open source libraries we rely on can undergo significant changes. This creates an ongoing delta between what an LLM coding agent suggests and what the best practices are, or what even works. For the team at Google DeepMind, this is an ongoing challenge as we publish both models and open-source SDKs. This talk will share some of the challenges that we, as SDK maintainers face, and we'll share some results from our experiments. We'll focus primarily on the "training cutoff knowledge gap", and how it is applicable for users and owners of open source projects, but we will also discuss some of the other challenges maintainers face in a world where producing code is trivial.

We built Claudish, a free open-source proxy that lets Claude Code work with any AI model. 15+ providers directly - Google, OpenAI, xAI, Kimi, MiniMax, and more. OpenRouter for even wider access. Or fully offline with Ollama. That was just the starting point. What came next was way more interesting. When you can run any model through the same interface, you start asking real questions. Which model works best for which task? Does mixing models actually help or is it just expensive complexity? How do you find the right combination for your team? And the hardest one - how do you measure any of this when LLM output is non-deterministic? You can't run the same prompt twice and get the same result. I'll share what we learned running multi-model setups across 100+ projects with a 70-engineer team. How we approach measurement, what surprised us, and a practical framework for engineers who need to evaluate AI tooling with something more than "it feels faster."

AGENTS.md started as a simple way to guide coding agents, but many teams are discovering that a default or poorly written one can actually make agents worse. Obvious facts, vague rules, outdated guidance, and generic instructions often confuse models more than they help. But manually crafting it won’t cut it once teams and organizations enter the picture. Because a single static file stops being enough. Agents need a harness that guides how they interpret context, what knowledge applies where, and which decisions carry authority. In this talk we’ll explore why effective agent systems require structured context, hierarchy, and memory — and how building that harness is the real challenge of making AI agents work reliably inside engineering organizations.

Despite all the hype and promise, we are in the Timeshare Mainframe moment of AI. Even our devices rely on the cloud for most inference. As AI moves beyond the cloud and into the physical world, the real opportunity lies at the edge. It’s where local intelligence meets local data and action. In this talk, we explore how AI systems can move from cloud agents to direct device control reducing round-trip latency, preserving user privacy, and enabling real-time responsiveness without constant cloud dependency. Drawing on experiments using platforms such as NVIDIA Orin Nano, ESP32 and Axera edge AI SoCs, we’ll examine how to architect low-power systems that combine local data and action with inference. This includes running compact speech-to-text and video models on-device and using USB and Bluetooth HID interfaces to translate AI outputs directly into keyboard, mouse, and other human interface device control signals. Attendees will gain an insight into tools such as Platform.io and ready-made modules like those from M5Stack that accelerate edge development.

In 2024 my team built 2 web-based Interactives for our Science Curriculum. In 2025 we built 50, in 2026 we expect to build over 100. In 2024 Engineers collaborated with Writers to build Interactives. In 2025 Writers built the Interactives and Engineers reviewed and deployed them. In 2026 we're getting Engineering out of the loop. With AI we're writing more code than ever, and more and more non-Engineers are involved in building with code. It is not sustainable for a human to read and review every line of code. Even if we do human review, the volume is so large and the context is totally gone - we can't expect them to do a good job. So how can we feel safe? What techniques do we need to apply? What technologies do we build? How do we Engineer in a world where we no longer read code? In this talk I'll go through our journey of building small low-risk software without human review. I'll talk about my experiments in building software without review, and the systems I'm building. I'll also talk about the systems we're using in production to drive high quality code and anti-fragility through AI review. Then how I'm thinking about the future of work in Software Engineering, and whether human review will be a part of that.

Modernization planning stalls when the business rules are locked inside decades of COBOL code. This talk shares a practical, production‑tested playbook I used to extract those rules, make them explainable, and serve them to teams in a usable form. It’s not economical to have humans extract this level of operational knowledge from COBOL at scale. The outcome of this work is an agent that saves hours for operational staff by surfacing what a batch job does, which input files it consumes, and which outputs it produces. I’ll walk through the end‑to‑end pipeline: how we used AI to parse COBOL into control‑ and data‑flow structures, generating diagrams that make execution paths and data dependencies visible, and assembling structured knowledge about each job (purpose, inputs, outputs, key rules). The emphasis is on trade‑offs: what we automated vs. where we needed human review, which COBOL constructs are most error‑prone, and how we scaled the approach across a legacy estate of ~2,000 COBOL jobs. Converting specific modules to Python is shown as one possible downstream outcome—but the core goal is understanding and planning. I will demo a self‑serve knowledge agent we built for developers and business analysts. It makes available the original code repositories plus the derived diagrams and extracted rules, so teams can ask questions like “where is premium eligibility calculated?” and get grounded answers with traceable sources. This will include a live demo using a public COBOL repository so the workflow is reproducible without proprietary code.

For decades, documentation has been the "sacred bridge" between human intent and machine execution. Historically, this was born of necessity: when computer time was scarce, we had to document our plans perfectly before touching a terminal. But in the modern era, documentation has morphed into a static snapshot—often serving more as marketing material than technical truth. Now, as we enter the age of AI-assisted development, the consumer of our code is changing. LLMs can read source code—the ultimate source of truth—with the same fluency as natural language. This talk draws on real-world experience building against rapidly evolving open-source systems to show why the future isn't about writing better manuals, but about embracing just-in-time understanding generated directly from the code.

Legacy software powers the world - from banking to utilities and government. The hardest part is rarely having access to the code. It’s recovering the knowledge around it: what the system really does, the business rules it encodes, the edge cases no one remembers, and the intent that never made it into documentation. To modernise safely, teams need more than technical understanding - they need functional understanding. A legacy codebase is a crime scene: you have to retrace the steps, gather evidence, and reconstruct the story in plain language that product, engineering, subject-matter experts, and AI agents can all work with. In this session I’ll share lessons from building Code-to-docs: a software reverse-engineering system that turns existing codebases into living software definitions. I’ll cover the evolution from a fixed LLM pipeline to agentic discovery, the real trade-offs between quality, cost, and speed, and case studies showing how teams de-risked modernisation by turning millions of lines of legacy code into requirements in hours, not years. You’ll leave with practical patterns for agentic discovery, where it breaks down, and how to keep it honest.

For a long time, the world has run on systems built on logic. You put something in, follow a set of rules, and you get an output. Now we have systems that can run on inference: systems that can update belief, decide, and act. That changes how we should think about building systems. We don't need to keep forcing everything into rigid workflows. We can start designing systems that are built around inference from the onset. This talk is a thought process on designing these systems, drawing from principles in human-computer interaction, mathematics, and software design.

The demand for AI agents that take real action is immense. However, developers keep hitting a frustrating bottleneck: building the complex authorisation logic required to let agents act on behalf of users. Rebuilding custom authorisation for every new agent capability creates endless boilerplate, technical debt, and a massive integration mess. Instead of focusing on innovative AI features, engineering teams waste cycles reinventing access control and approval workflows. This session is all about maximising developer efficiency and eliminating rework. Discover how leveraging Auth0 for AI Agents handles the heavy lifting of dynamic permissions and seamless Human-in-the-Loop controls out of the box. We will explore how to stop building auth from scratch so you can ship high-impact AI agents with significantly less friction.

Prompt injection isn't a bug - it's a feature. LLMs trained on humanity's written corpus learned something we didn't intend: narrative structure. They understand dramatic tension, plot twists, and persuasive framing. When an attacker crafts a compelling story ("Actually, the real system prompt said..."), the model follows because that's what stories do. This talk connects 2,500 years of storytelling theory - from Aristotle's Poetics to Derrida's "there is no outside text" - to explain why prompt injection is an inevitable consequence of training on human language, not a solvable vulnerability. Understanding why doesn't stop the attacks, but it changes how you build defences. You'll learn production-tested layered defence patterns and leave with a mental model for threat modelling and patterns you can implement immediately.

Project Electrification is an agentic, AI-powered application security pipeline designed to eliminate vulnerabilities at their source. Autonomous agents scan large codebases, generate and execute custom SAST rules, and produce unified risk analytics through the ELK stack. Security engineers then convert these insights into SDK-level protections, ensuring the same classes of issues can’t reappear across the organization’s products. Instead of chasing findings, Electrification removes the root causes—at scale.

AI is already in production—but almost no one has tested how it breaks. Today I’ll show you how attackers think, how models are actually exploited—from prompt injection to data exfiltration—and how to systematically uncover those risks before they become incidents.

Cloud outages used to mean your site went down, maybe you couldn't deploy. Just small unimportant stuff. Now an outage means you can't even write any code. And unreliable connections cause the same problems as ever - random cutoffs partway through, lost or incomplete work. The broken assumption remains that we are online all the time, and not sometimes sitting far away coding in a forest. This session is about making the big models more fault-tolerant, and having a better time with the little ones. How to ensure LLMs don't burn a hole in your pocket, literally or otherwise. Probably impractical in the event of a real apocalypse, but helpful all the same.

De-identifying text is easy to demo and surprisingly hard to ship. This talk is a deep technical case study of building SmartScrub, a reversible de-identification system designed for legal workflows, where privacy guarantees, auditability, and user trust are non-negotiable. The original goal was simple, allow lawyers to safely use LLMs on transcripts without exposing client data. The reality was a long series of architectural failures that common PII masking approaches cannot survive in production. I will walk through what we actually built and why naive solutions broke down. This includes placeholder token design, collision avoidance, stability across edits, and why masking too aggressively destroys downstream LLM usefulness. I will show how reversible de-identification changes your entire data model, UI, and persistence strategy, and why this becomes a systems problem rather than an NLP problem. The talk covers hard trade-offs we made around local-first processing, cloud services, manual review tooling, user-defined PII patterns, and audit-safe re-identification. I will also share failure modes we only discovered after real users interacted with the system, including false positives that destroy trust, silent data drift, and UI decisions that unintentionally leak meaning. This is not a theoretical talk. It is a production story about building AI under legal risk, zero tolerance for silent errors, and users who will abandon the product instantly if they do not fully understand what the system is doing. If you are building AI systems that touch sensitive data, this talk will save you months of painful mistakes. What Attendees Will Learn - Why common PII masking approaches fail under real legal workflows - How to design reversible de-identification that survives editing, reprocessing, and audits - Placeholder strategies that preserve LLM utility without leaking meaning - Architectural patterns for isolating raw data while still enabling AI pipelines - UI and data model decisions that directly impact user trust - Failure modes you will not catch until real professionals use your system Technical Topics Covered - Reversible de-identification architectures - Placeholder token stability and mapping persistence - Manual scrub tooling and override precedence - User-defined PII pattern overlays - Auditability and re-identification guarantees - Local-first vs cloud processing trade-offs - Why this problem is systems engineering, not just NLP Plus. a short live walkthrough showing how a legal transcript is de-identified, reviewed, edited, and safely re-identified, including examples of failure cases and how the system prevents them.

When I joined my current team, it was a familiar pattern: 6-8 experiments over a year, each taking 10-12 weeks, 60-70% of the time burned on infrastructure, one thing in production held together with duct tape, and our entire agent lifecycle dependent on what our cloud provider made available in our region. The fix wasn't a new framework. It was an old playbook: ML engineering. Version artifacts like model checkpoints, define evaluators like loss functions, search hyperparameters systematically, and decouple your tooling from your cloud provider. The first experiment under this approach finished in 4 weeks, and other teams across the organisation started running their own experiments without us. In this talk, I'll walk through the methodology, the key trade-offs, and demo HoloDeck, the open-source distillation of everything I learned.

Are the AI agents you're developing truly secure? AI agents that execute actions autonomously offer unprecedented value. But what about the "privileges" granted to them to act "on behalf of the user"? Improper privilege management for agents is no longer a theoretical problem—it's a clear and present danger. An exploited AI agent with excessive privileges can lead to significant financial losses and devastating data breaches. This session dives deep into the biggest pitfall in AI agent development: privilege and authorization. I will demystify the latest risks, such as Excessive Agency and Identity Abuse, and discuss defensive measures you can take to protect your AI agents from malicious actors. This is the critical security state that every development organization must understand before deploying AI agents into production.

Autocomplete is *so* 2023. Chatbots were already tedious by 2024. Running agents locally was cool... back in early 2025. The future of engineering doesn't have a human in the coding loop at all. When it's within the AI's — rapidly growing — capabilities, *you* are the bottleneck in shipping code. How many PRs can you review? How many Claude terminals can you monitor at once before you lose your mind? I'll talk through our experiences building a fully automated maintenance loop at Stile Education, where we're scaling from 600k students in Australia to 6M across the US over the next 24 months. Issues from production are monitored, aggregated, ticketed, fixed, (increasingly) reviewed, and deployed without human involvement. Explain our conceptual models of how to build these systems, and highlight our hard won mistakes and lessons along the way. Then, I'll fumble awkwardly towards the broader implications for our industry: What does it look like to step back and engineer a system that produces software, rather than being a cog in that machine directly? How do we all begin to work *on* the business rather than working in it?

You add memory to your agent, it works great in testing, and you ship it. A few weeks later, outputs start getting worse and nobody can figure out why. The agent is pulling in old information that's no longer true, retrieving context that's loosely related but clutters its reasoning, and sometimes carrying forward bad data that quietly corrupts every response after it. Standard evals won't catch any of this because they test single turns, not how memory behaves over hundreds of sessions. In this talk, we will walk through practical design principles and evaluation patterns you can implement to detect memory degradation before your users notice it. You'll walk away knowing how to design and evaluate memory enabled agents so it actually makes your agent more reliable instead of silently breaking it.

Three things matter for AI coding effectiveness: the tool, the codebase, the developer. When we look at the nuance of sessions, we can see patterns across all these - what works, what doesn't, what you can control, what you can't. I can't fix everything for you but I'll give you a few useful steps forward.

AI agents aren’t magic. They’re distributed systems — with better marketing. Behind every impressive demo is a messy reality: multiple tools, remote services, auth boundaries, latency, retries, side effects, and deployment trade-offs. When I took a seemingly simple multi-tool agent built with MCP and Gemini ADK and pushed it into production, I stopped thinking about prompts — and started thinking about architecture. In this talk, I’ll share what changed when the agent left localhost. We’ll explore what happens when tools become independently deployed services, when stdio orchestration meets HTTP in the real world, and when generating an image, storing it, and emailing it turns into a reliability problem — not just a feature. You’ll see how treating the agent as a control plane — and exposing it as a service — transforms it from a demo into infrastructure. This isn’t a code walkthrough. It’s a systems story. If you’re building AI agents meant to survive outside a notebook, this talk is about the parts no one shows in the demo.

Your feed is full of warnings about an incoming tidal wave of AI slop. Unmaintainable code. Crushing tech debt. Anyone with a prompt and ten minutes shipping production code. The fear is real, but it misses what's actually going wrong. Slop happens when the standard isn't stated. AI drives for done. Without a bar to clear, done is all you get. The way through is configuration: writing the standard down, once, in a file the machine and the human can both point at. David makes the case that the same technology we fear will flood us with slop is the technology that can elevate the bar, if you set one. You'll leave with a simple framework to get started, a model for turning AI into a quality multiplier, and honest caveats about where this breaks down.