I have been travelling to conferences across Europe this year, running workshops and giving talks, mostly on code review and CVE analysis. The new dynamic at these events is hard to miss. If a venue has a big room and a small room, never put the AI talk in the small room. And if you are giving a non-AI talk in the slot opposite an AI one, your room will not fill.

That made me realise I should probably talk more about what I am doing with AI. But there is a catch.

The four-month CFP problem

Submitting a talk today for a conference four months out is far scarier than it used to be. Four months was once a normal delay: you did the research, submitted the CFP, waited, got accepted, cleaned up the slides, and gave the talk. Now, if your work is about AI-assisted code review, AI-assisted vulnerability research, AI-assisted triage, or agents pointed at a real codebase, four months is an eternity. You spend weeks building a workflow, gluing tools together, writing prompts, running agents, and validating their output, and by the time you are on stage a frontier AI lab has shipped a feature that makes half of your system look obvious. Your careful triage pipeline becomes a checkbox in someone's product.

You can picture standing there and admitting: "When I submitted this talk four months ago, this was a whole system I had built. Since yesterday, it is now basically a command in Claude Code or Codex." It is funny, and it is a real problem. The talk you submitted is no longer the talk you should give.

The ugly version that actually works

Security people share very little about their AI workflows. I think it mostly comes down to two reasons. Some do not want to give away their secret sauce, which is fair. But many are embarrassed by what the secret sauce looks like. It is not a clean platform with a beautiful architecture diagram. It is a few shell scripts, a tmux session, a folder of prompts, a wrapper around a CLI, a pile of notes, and some bash they did not really write themselves.

That is exactly what I would like to see more of. Not the "we built an autonomous AI security platform powered by agentic workflows" version. I want to see the ugly version: the one where someone points a model at a real repo and says, "This part is terrible, but it saved me six hours," then explains what was too noisy to triage, what broke, what flagged false positives all day, what only ever worked on toy examples, and which secure-by-default assumptions fell apart in production. None of that fits on a slide, but it is the part other appsec people can use. Something that felt impressive six months ago is now boring.

A format that fits the moment

The fix is not to declare talks dead. It is to add formats that match how security work happens now. The best one I have seen was at DevOps Wollongong. The morning ran traditional talks. The afternoon did not. Before lunch, anyone could go on stage and pitch a subject in one minute. The audience voted, and the top nine won: three rooms of three sessions each. Those were not talks but discussions, with the person who pitched the subject acting as a mediator rather than a presenter.

None of this is new. What Wollongong ran is basically an unconference, an open-space format that has been around for years. The difference now is that AI-speed security is the case that finally makes it worth adopting. If the field moves too fast for polished talks locked in four months out, we need room to compare what people are seeing right now, in their own queues and code reviews: which tools are catching real bugs, where the false positives are hiding, and what breaks when you point an agent at a live codebase. Nobody is going to solve prompt injection or reliable automated triage in a forty-minute talk, but a room full of practitioners trading what worked last week gets you an honest map of what currently works. It also takes the pressure off any one person to pretend they have all the answers, and for most AI-assisted security work, nobody does.

Show me your process, not your tool

So I would move CFPs for fast-moving security topics closer to the event, sometimes only weeks out. I would make room for lightning talks, workshops, live demos, and discussion sessions, and for unfinished work instead of only polished conclusions. More talks about process. More talks about failures.

Because the durable part is never the exact tool, the exact prompt, or the exact command someone is running this month. Those change constantly. The durable part is how people think, how they test things, how they validate output, how they deal with false positives, how they review code.

That is what I want more of. Not "look at my tool," but "look at my process." Show me what broke. Show me what surprised you. Show me the ugly workflow that saved you time.