ConFoo 2026 Overview
A return to the stage
This week I had the pleasure of giving two new talks at ConFoo 2026 in Montreal, Canada. For those who don’t know, I’ve spoken at ConFoo multiple times before — though it’s been six years since I last took the stage. The more astute among you will note that was just before everything shut down. Over the last six years I’ve been excited to see where our industry has evolved, and I hope to impart some knowledge every so often to those who attend my talks.
Here are the two talks I gave and amazingly enough neither one had even the hint of AI or LLMs. I’m therefore hugely grateful for those who chose to spend time with me and listen to the “war stories” on building aviation software.
1st Talk
Offline-First at 35,000 Feet: When Your App Can’t Call Home
Abstract
Most offline-first apps assume you’ll reconnect in minutes. What happens when your systems operate for hours without connectivity and no team to monitor them?
Real lessons from building systems that must work reliably in environments where network access is unreliable and remote debugging is impossible. We’ll explore data sync strategies, conflict resolution patterns, and building bulletproof systems when remote support isn’t an option.
2nd Talk
Spring Boot and GraalVM: Lessons from 35,000 Feet
Abstract
What do you do when your Spring Boot app suddenly needs 75% less memory? Here’s our real-world GraalVM retrofit story.
Actual production performance metrics, reflection gotchas that break compilation, brutal build times that killed productivity, and what we’d architect differently from day one to avoid the retrofit pain entirely.
The slides are now available and can be seen at the linked URLs above and also at our new Talks landing page.
Throughout the 3-day event I was able to attend several talks and see where the industry is focusing. It’s no surprise to see that 75% or more of the talks are centered on large language models and the greater AI landscape. If you spend any time on Twitter (I still refuse to call it anything else), you may be swayed by a belief that a 12-year old with a laptop and tokens in his piggy bank can replace you now. When you look at who’s pushing this belief, it’s usually someone selling an agentic solution, someone financially tied to a frontier model, or someone who hasn’t yet seen what software engineers actually do.
I was on a panel in 2019 in Sofia and the topic centered around AI. One of the questions from the audience was a plea to the panelists to find out if AI would soon take their job. Most of the panelists gave well-meaning answers and were likely correct for the time. My response:
“If an AI can do your job, is it enriching enough of a daily activity for you to continue?”
I believe this even more today. What we’ve been experiencing is not an extinction-level event for software engineering but a democratization. This technology has released more ideas into the wild and enabled an entirely new cohort of builders. I’ve been coding professionally for three decades, so maybe I’m an old dog — but one-shotting a todo app, a CRM, or a replacement for that SaaS you’ve been paying $19/mo for doesn’t strike fear in me. The calculus is way off. These builds haven’t accounted for real architecture and design, feature development, data storage, security, privacy, and the ongoing cost of maintenance.
The tools we have access to when used well can not only bring in an entirely new pool of original ideas but also free up seasoned engineers to explore new areas and get curious about technology outside their usual domain. We would also be wise to level up our junior engineers and keep that learning and gaining experience continually. When I’m evaluating talent, I’m not counting features. I want to know that you understand what you built and how it solved a real problem for a real customer. We will see more layoffs as executives attempt to show increased revenue by decreasing labor before realizing that those who understood how DNS worked were worth every penny. Our elders are as important as our juniors in this industry and we’d be wise not to lobotomize nor hollow out the middle in our quest for “efficiency”.
Our industry has a cyclical way of proclaiming the end of the software engineer1. The last year has only proven how much more we will depend on talent in this area. In many of the talks the question of who’s using agentic coding tools went up and the majority of the room had hands raised. The question I have for you is however much or little you’re using it, do you understand what you’re committing? Look at the commit log:
% git log
commit ea7e4fd3d4f7af8825818d822590fe78d60147a8 (HEAD -> main, origin/main)
Author: Andrew Lombardi <a*@***.com>Look closely. My name is on this. That mantra should be the rally cry to ensure you aren’t adding slop. I wouldn’t accept an excuse of “Claude Code wrote this”, it’s yours.
When the system gets hacked they won’t blame the agent, they’ll blame you.
When the edge case gets tripped and your vibed code has leaked customer data, they’ll blame you.
When the 3AM page happens and you’re on-call the team needs your brain.
So stay curious and engaged. Read your commits and PRs before you ask for the review because nothing sucks worse than reviewing bloated and wrong code that the asking developer can’t explain.
Remember, your name is on this.
Anyone remember the 5GL craze from Peoplesoft back in the 90s? Oh right, old dog.