When Simple Beats AI: RegEx, Rules, and Results

AI feels like the obvious answer when you need to automate judgment: scoring, classifying, and reading messy inputs. And to be fair, it often is the right solution: general-purpose models are flexible, quick to prototype, and handle input no RegEx survives. However, they can add cost, latency, and drift where simple, deterministic tools would do. Skip the comparison and you're pay a cost you never notice you're paying.

In this talk, we show how to run that comparison before you start building. We'll walk through a 2022 production system (scoring assignments against a rubric), where that era's models underdelivered, and why RegEx, static checks, and tiny heuristics carried the results. Items humans disagreed on couldn't be evaluated by any model. You get a prioritization formula for where automation pays off, per-item measurement that makes failures visible, and drift monitoring that catches decay. New for 2027: we run cost math against today's pricing and show what structured output changes on sample scoring problems. The simple route's upside is determinism and near-zero cost, with a hard ceiling on messy input. That messy input is where hybrid approaches pay off: rules handle the easy wins, AI takes the ambiguity. For engineers who want to pick the right tool; no AI fluency required.

Escaping the Trap of Self-Sabotaging Meetings

Meetings are so notorious for draining productivity that historic sabotage manuals listed them as a deliberate tactic. The uncomfortable reality is that modern teams still fall into the same traps unintentionally. Too many attendees, fuzzy objectives, and decisions that never quite stick. These failures compound into feedback loops: too many meetings leave no time to prepare, meetings run long, people multitask, and effectiveness drops even further. By the time everyone joins the call, the outcome is often already determined.

This talk focuses on how to break those loops before a meeting begins. Using lessons pulled straight from the sabotage playbook, we will contrast common meeting anti-patterns with practical countermeasures. This includes choosing the right type of meeting, deciding who actually needs to attend and who does not, designing agendas that force clarity, shaping environment and logistics for focus, and closing with explicit decisions and action items. Attendees will leave with reusable heuristics, agenda patterns, and follow-up structures they can apply immediately to design meetings that respect time and produce outcomes. Or, to misquote Arleen Lorrance, be the meeting you want to see happen.

This talk has been given at KCDC 2023 and CodeMash 2026

Can We Learn to Manage Uncertainty? Probably!

When we’re asked when something will be done, it’s tempting to answer the question. “It’ll be done on March 32nd” or “it’ll take 182.5 days” or “we need 15 sprints”. It doesn’t matter if that answer is the best-case, average, or worst-case scenario.

The answer is fundamentally wrong because using a single value hides the fact that what we really meant was a distribution of possible dates, durations, or outcomes. The exact value is uncertain. Development may be faster or slower than we thought. What if the tech lead wins the lottery and retires? What if a global pandemic forces us to change the way we work?

While we can’t control any of those factors, we can be mindful of their existence and communicate more clearly. In this talk we will introduce “bet” language, which makes uncertainty and luck an explicit part of the conversation. This mindset helps us accurately assess risks, pick the right risks to embrace, and avoid analysis paralysis. It also helps us learn in an uncertain world, where even if we make good decisions, we may experience bad outcomes (and vice versa!).

Same Attacks, New Surfaces: Prompt Injection, Poisoned Data, Hijacked Agents

Anyone who is working with AI, or considering it, should care about security. The traditional attack surfaces and mitigations still apply to an AI-powered system or product. New attack surfaces appear depending on the specific AI approaches used. In addition, because AI systems are typically more automated, they can do more harm, faster, when compromised.

In this talk, we show how to recognize the attack vectors AI shares with traditional software, and what those attacks look like. We then turn to attacks specific to AI: prompt injection (direct and indirect), hijacking an agent through the content it reads and the tools it calls, poisoned training data, and adversarial inputs that fool a vision model. Using a map of the AI pipeline's attack surfaces, we walk through real incidents at each stage. For each, we show what thwarts it, or at least mitigates it: validating training data, sanitizing and rephrasing inputs, and red-teaming the model. Every mitigation comes with a real cost of capability or convenience, which we describe.

No prior AI or security experience needed. You'll leave able to threat-model an AI-enabled feature or product, choose mitigations for the attacks that apply to it, and know where to look as the landscape evolves.

Why Not Just ChatGPT?

We built an AI research agent for a large enterprise research organization, and within weeks frontier labs shipped the same features. Next quarter, different features, the same thing happened. Users started asking why they shouldn't just use ChatGPT. When you can't answer that, adoption dies.

In this talk, we show how to tell which advantages an internal AI tool has, and how long they last. We'll walk through how we pivoted an internal product eclipsed by ChatGPT. Audit which data sources, clearance levels, and placements only your system reaches. Log how often users ask 'why not ChatGPT?'; when the rate climbs, that's a signal to pivot or shut down. Track how long your public-data features take to reappear in frontier tools; ours reappeared in days. The longest-lasting fix was merging the tool into the chat app staff already used, so trying it cost nothing. The upside is increased user adoption; the cost is that the tool now lives or dies inside an app we don't control. Meanwhile the data advantage is expiring too, as enterprise ChatGPT connectors reach internal sources that were once ours alone. For engineers building internal AI tools, you leave able to run these checks and decide whether the tool is worth keeping.

Faster Coding Means Slower Everything Else

AI tools accelerate coding, but writing code isn't the slowest part of shipping software. That speed just moves the bottleneck downstream to review, testing, and acceptance. Individual output metrics look great; actual delivery stays flat, and reviewers and testers are drowning in a flood of code.

In this talk, we show how to locate your real delivery constraint. Per the Theory of Constraints, improving anything except the constraint changes nothing for the system. We'll walk through how three teams restructured their review and testing process. One reviews solution design docs before code exists, giving reviewers stated intent to verify the code against. Another maintains agentic review pipelines as versioned infrastructure plus structured mob review. A third constrains AI test generation to a DSL (Domain Specific Language), so any deviation flags the change for extra review scrutiny. The trade-off is more up-front infrastructure work to get review and testing that scales with output. If your AI adoption is outpacing your review bandwidth, you'll leave able to find your constraint and fix it.

Six Constraints That Cap Your Team's AI Autonomy

Every team is being asked to use more AI for their coding, but more doesn't mean better. The right amount of AI use depends on the constraints the team (and organization) is under. Use more AI than your constraints support and you're just shipping defects faster. Use less and you're leaving velocity on the table. The expensive failures are mismatches.

In this talk, we show how to match your team to one of three modes of agentic coding, where AI agents write, test, and change code with growing autonomy. Individual mode lets each developer choose their own harness or workflow, at the risk that learning stays with the individual. Shared mode checks domain context files, guidelines and standards, and tools and skills into a shared repo, where improvements compound across the team. Orchestrated mode grows that shared infrastructure into a workflow agents can run semi-autonomously, with humans at defined checkpoints. Which mode you can sustain comes down to six constraints, from whether domain knowledge lives in heads or written down, to whether you must inspect every line or can verify outcomes. The upside of a higher mode is throughput; the cost is infrastructure and verification built first. We walk through three real teams, one per mode, all successful in their own situation, including one mid-transition from individual to shared. For teams deciding how far to push, you leave able to de-risk the decision with a clear idea of what needs to change.

Refactor Your AI Workflow Like Your Code

Your AI workflow is a codebase. When did you last refactor it? You write a rules file for your coding assistant once and then have the same argument with the AI every session: same wrong assumptions, same corrections, same wasted time. That right there is process debt, and it costs you a lot of the value that makes these tools worth using.

In this talk, we show how to run the refactor step your AI workflow is missing. In the metaphor of test-driven development, coding with the AI is red/green, but everyone skips refactor. We walk through three practices our teams do daily: the end-of-session question, what instruction change would make the next session smoother; mistake clustering, logging AI errors and investing in a fix only when they form a category; and self-assessment prompts, to make the AI list its assumptions with every meaningful response, so wrong ones are surfaced to you. The upside is a workflow that gets better every day; the cost is instruction bloat and meta-work that only feels productive. For engineers tired of repeating themselves to their AI tools, you leave able to evaluate your configuration, reduce its debt, and choose when to start clean.