AI Is a Terrible Engineer — and a Great Partner (If You Know How to Use It)

The more I’ve used AI inside real engineering teams at Microsoft, SAP Labs Munich, and SuprSend, the clearer one thing became:

AI is a terrible engineer.
It misses context. It hallucinates architecture that doesn’t exist. It panics in distributed systems. It’s confidently wrong in the most unhelpful ways.

But here’s the twist:
AI is also the best “extra brain” I’ve ever had on tough debugging days.

This talk is about that paradox and about how developers can get massive leverage out of AI without falling for its traps.

Instead of talking about AI “replacing” developers, I’ll show what actually happens when you pull an LLM into real engineering:

• messy logs

• conflicting traces

• flaky workflows

• integrations that break silently

• symptoms that look unrelated

• dashboards that show everything is green while everything is broken

This is how I’ve learned to use AI as a partner, not a problem-maker.

We’ll cover:

• Why AI fails spectacularly when systems get stateful, concurrent, or event-driven

• How to talk to AI like a junior engineer or a puppy whom you need to train

• Patterns that actually work: log comparison, trace summarisation, hypothesis checking

• A real debugging story where AI helped, and one where AI confidently misled me

• Why open-source models (Ollama/Mistral) are better suited for engineering workflows

• A small demo: using an open model + OpenTelemetry/Jaege­r output to reason about a broken flow

The goal is simple:
Help developers use AI in a way that makes them sharper, faster, and more careful, not dependent or misled.

• AI can speed up debugging, if you control its role carefully.

• Practical patterns for using open-source LLMs as reasoning tools, not code generators.

• How to structure prompts for logs, traces, failures, and event ripple effects.

• When to trust AI vs. when to challenge it.

• A reproducible “AI + OSS debugging workflow” attendees can implement immediately.