Pakkit.net

Speaking & workshops

Technical talks without the buzzword fog.

Practical technical conversations for people who want to build useful systems without losing safety, clarity, or ownership.

I'm a technical speaker and workshop host drawing on hands-on experience across software architecture, cybersecurity, AI-assisted development, automation, infrastructure, and the work of shaping weird ideas into something buildable. The goal is a real conversation a room can act on — not a keynote of slogans.

Topic tracks

Subjects I'm equipped to dig into

Starting points, not a fixed catalogue — each adapts to your audience and what they're actually trying to build.

AI-assisted development with validation loops

How to actually use AI agents in a real codebase without handing over the steering wheel. We cover the validation loops, review habits, and small-diff discipline that keep generated work honest. An AI development workshop framing, grounded in code you'd be willing to ship.

Best for Engineering teams adopting AI tooling who want speed without losing trust in the output.

AI-Assisted Development Without Losing Architecture

Why AI acceleration is not architecture

AI makes typing faster; it does not make decisions for you. This talk separates raw output speed from the design judgment that decides whether a system holds together, and where teams confuse the two. The fix is narrow, validated slices instead of heroic big-bang generation.

Best for Founders and leads deciding how much of their build to hand to AI.

Small Slices Beat Big Bang AI

Safe automation: dry runs, logs, rollback, and human approval

Automation without a panic button is just a faster mistake. We walk through dry-run mode, logs that mean something, least-privilege scope, rollback thinking, and explicit confirmation on anything destructive. A safe automation conversation you can apply the same week.

Best for Ops-minded builders and teams automating real, consequential systems.

Automation Needs a Panic Button

Turning messy ideas into small buildable slices

Most good builds start as something half-formed and a little too big. This session is about shrinking a vague idea to the narrowest slice that does something real, then iterating from there. It's the difference between a roadmap you trust on faith and a step you can take today.

Best for Anyone sitting on an idea that feels too big to start.

Building Weird Ideas Into Real Systems

Software architecture that survives implementation

A clean diagram is easy; an architecture that's still clean after three months of real work is the hard part. We talk about boundaries, naming, and the judgment calls that decide whether a system stays maintainable. A software architecture talk aimed at decisions, not diagrams.

Best for Software and product teams who want structure that holds up under change.

Security as an architecture input

Security works best as a design discipline, not a bolt-on at the end. This is a cybersecurity discussion about threat modeling, least privilege, and the boring-but-right habits that belong in the design phase. The point is fewer surprises later, not security theater now.

Best for Security-minded builders and teams who want guardrails baked into the design.

Security Is Architecture, Not Decoration

Infrastructure and homelabs as systems-thinking laboratories

A homelab is a low-stakes place to learn the messy parts of real infrastructure — containers, networking, observability, and the failures that teach you the most. We cover what running your own systems teaches that tutorials can't. Hands-on systems thinking, not a hardware brag.

Best for Self-taught engineers and infra-curious builders learning ops by doing.

Homelabs Teach the Messy Parts

Documentation as operational infrastructure

Docs aren't a chore bolted on at the end — they're part of how a system runs and how the next person (often future-you) recovers. We talk about writing the path down as you build, and treating runbooks and notes as load-bearing. If it isn't written down, it isn't finished.

Best for Teams whose knowledge lives in one person's head and shouldn't.

Documentation Is Infrastructure

What gaming and community systems teach technical builders

Games and the communities around them are full of real systems thinking — incentives, feedback loops, and emergent behavior. This is a lighter, still-technical look at what running and playing in those systems teaches about building better ones. Useful for anyone who underestimates how much play sharpens engineering.

Best for Developer, gaming, and creator communities interested in technical systems.

Gaming Taught Me Systems Thinking

Formats

Ways this can take shape

Adaptable starting points rather than a fixed package — we shape the format around your audience and goal.

Podcast or livestream conversation

A recorded or live back-and-forth on a topic you pick — questions welcome, slogans optional.

Panel discussion

A seat on a panel where the value is honest disagreement, not everyone nodding along.

Internal team session

A focused session for one team — tuned to your stack, your constraints, and what's actually slowing you down.

Community talk

A talk for a meetup or community group, pitched at the room's real experience level.

Practical workshop

A hands-on, work-along format where people leave with something they actually did, not just heard.

Technical Q&A

An open question-and-answer format — bring the real problems and we'll dig into them together.

Project or architecture walkthrough

A guided walk through how a real system is put together and why, decisions and trade-offs included.

Good audience fit

Who tends to get the most out of this

If you're somewhere in here, there's probably a useful conversation to be had.

  • Software and product teams
  • Technical founders
  • Security-minded builders
  • Developer communities
  • Self-taught engineers
  • AI-curious teams that want practical guardrails
  • Gaming or creator communities interested in technical systems

What organizers should include

A short checklist for a first message

None of it has to be polished — rough answers are plenty to start.

  • Who the event or audience is
  • The topic or problem you want covered
  • The format you have in mind
  • Approximate timing, even rough
  • Whether it's remote or in a location
  • Any accessibility or recording expectations
  • What a useful outcome would look like for your room

Please don't send secrets, private access details, or confidential architecture through the contact form. A short, high-level description is plenty to start — we can get specific over a more appropriate channel.

Related material

Where to look before reaching out

Context on how I work and the write-ups behind most of the topics above.

Let's talk

Bring the real question.

The best sessions start with an honest, practical problem — not a request for polished thought-leadership theater. If something in your build is messy, risky, or genuinely interesting, that's the conversation worth having.