Codecon Summit 2026, notes and takeaways

Codecon Summit 2026, notes and takeaways

I was in Curitiba again this year for Codecon Summit, my second time attending, and it felt bigger and better than last year. Same event, similar format, but the focus was clearly different: almost every conversation and a big chunk of the talks pointed back to AI in one way or another. That shift is what I want to write about, alongside a couple of things I picked up and the people I bumped into.

Curitiba

Curitiba is a great city with plenty to do and good restaurants, and it works surprisingly well as a tech conference destination.

If you ever end up there, a few personal recommendations:

  • Brains Coworking, in the Batel neighborhood, is a great spot if you need somewhere to work from.
  • OIDE is a must if you love Japanese food. Get there early, especially on weekends, because it gets crowded.
  • Jardim Botânico and Parque Barigui are both worth a visit if you enjoy nature and the outdoors.

On stage

Out of the whole schedule, the talk I keep coming back to is “Claude Says: The Tests Passed, Good Luck”, by Lucas, Software Engineer at Resend.

It resonated deeply with my day-to-day, and I could draw a clear parallel with what I do as a Product Engineer at Spoke. I lean on AI heavily at work, and lately the volume of PRs waiting for my review has started to feel overwhelming.

The idea that software has gotten worse over time, and that we are living through a crisis, is almost as old as the industry itself. AI is not the problem; the way we use it to build things is.

This is where things get interesting. AI now writes code faster, and often better, than we do, but the system as a whole no longer fits inside our heads. If we keep trying to manually review every single line, code review quickly becomes the bottleneck.

To break that bottleneck, engineers need to review code faster. Speed alone is not enough. Doing it the wrong way, without the right tools, breaks the shared theory of how the system works, and that disrupts the entire development lifecycle, day by day.

The talk introduced me to explainer artifacts, a Claude Code feature that generates short write-ups with diagrams, hosted as a static website, so you can understand what a PR is doing before going through it line by line. It's a low-effort habit that attacks a common problem in teams: reviewers approving PRs without understanding what they're approving.

My understanding is that there are always two versions of the system we are building:

  1. The system in our heads: our mental model of how it works. Each engineer has their own version of it.
  2. Reality: what the code actually does.

Bugs live in the gap between the two. We build something assuming X, but production is running Y.

AI can make that gap grow faster and larger, because we ship more code and spend less time reading it. Anything that helps us close it, like explainer artifacts, better code reviews, and using AI to learn the codebase and not only to write code, matters more than it used to.

That wasn't all, though. A few other talks also caught my attention:

  • The Laws of Frugal Architecture by Elton Mineto was a good reminder that “how much does this cost?” is a first-class engineering question, and that we should never underestimate small improvements in systems running at scale.
  • Beyond Box-and-Arrow Diagrams: Designing Systems You Can Actually Investigate by Alex Rios made me rethink who alerts are for and when it makes sense to trigger them. If no one can act on an alert, it is useless and should be deleted.
  • You Don’t Need an AI Team: Architectural Patterns for Engineers Building with GenAI by Victor Kazuyuki Shinya from AWS offered practical guidance, especially treating the model as an external dependency and always accounting for latency, non-determinism, pricing, and fallbacks.
Expand to see all my raw notes from the event

Day 1

Do You Really Know Anything About Security?

  • Don’t limit yourself to the OWASP Top 10
  • Creativity is key to protecting systems
  • There are 13 OWASP Top 10 lists, which means 130 items in total
  • Zero trust by default
  • There is no such thing as a 100% secure system

You Don’t Need an AI Team: Architectural Patterns for Engineers Building with GenAI

Things to watch out for:

  • Cost
  • Latency
  • Hallucinations

What makes a GenAI project different?

  • High latency
  • Non-determinism
  • Complex pricing

Architecture takeaways:

  • RAG is a data pipeline.
  • Treat the model as an external dependency.
  • What happens if the model is unavailable? What is the fallback?

How to Think About Efficient Architectures in the Age of AI-Generated Code

Beyond Box-and-Arrow Diagrams: Designing Systems You Can Actually Investigate

  • MELT: Metrics, Events, Logs, and Traces
  • Alerts should be triggered based on who actually uses or owns the system.
  • We need to protect human attention
  • Can someone take action on this alert? If not, don't trigger it.
  • LGTM framework

Day 2

Claude Says: “The Tests Passed, Good Luck”

  • AI writes code faster and better than we do.
  • The problem is that the system as a whole can no longer fit inside our heads.
  • Therefore, use AI not only to write code, but also to understand the codebase.
  • Use explainer artifacts and diagrams.
  • Good code reviews create a shared theory of the software being built.
  • Make impossible states impossible
  • Tests are cheaper than ever; using them, mocking as little as possible, and putting them into the agent loops is key to success.
  • Think of the test pyramid as a spectrum rather than a clear classification; some integration tests are closer to E2E than others.

The Laws of Frugal Architecture

Important skills:

  • Systems thinking and architecture design
  • Good communication with the business
  • Strategic problem-solving
  • Specialized knowledge

Three pillars:

  1. Design
  2. Measure
  3. Optimize

Key takeaways:

  • Always consider the cost of what is being implemented.
  • Ask yourself: How much does the system I work on cost?
  • The harder it is to understand how much something costs, the greater its potential impact may be.
  • Don’t underestimate small improvements, especially in systems operating at scale.

Other cool references

Off stage

The talks are only half of what makes an event like this worth the effort. The other half is the people you get to meet, reconnect with, and spend time with.

This time, I got to share that experience with my fiancée, who was attending her first big tech event. She loved it, which made the whole experience even more special.

I also reconnected with a few people I had met last year. It was interesting to catch up and see how much everyone’s day-to-day had changed in just twelve months.

Spending time with the folks from the Tech Leads Club community was easily one of the best parts of the trip. Interacting with people online through chat or on a call is one thing; sitting next to them at lunch, sharing stories and ideas, is different. There’s something about being in the same room that makes those connections feel much more real.

One thing that caught my attention is that almost every conversation had a version of the same story. We’re all using AI heavily, and because of that we’re rethinking how we design, review, and operate our systems.

Some are worried, others are excited, but everyone agrees this shift is unlike anything we’ve been through before, and it’s here to stay.

Closing thoughts

I could have watched most of these talks on YouTube in a couple of weeks, but the part that actually made the trip worth it was the conversations. The questions after the talk, the follow-up over coffee, the random “wait, how are you actually doing that?” between sessions.

That is also a reminder of something I’ve been thinking about a lot lately. The role of a software engineer has been changing, and events like Codecon make it obvious. Writing code is becoming the smaller part of the job. The bigger part is now everything around it: architecture, system design, observability, cost, and being able to reason about a system end to end even when an agent wrote 80% of it.

So go out there, meet people, make friends, and never stop studying the fundamentals. They are still the foundation of everything we build as software engineers.