Why a retrospective

A little over a year ago I stopped just testing AI tools and started actually integrating them into my day-to-day engineering work. Today I can confirm that bet — with one important caveat: it depends almost entirely on how you use the tools. Not on which one currently counts as the top tool.

This retrospective is an attempt to condense the most important findings from twelve months into five lessons. None of them are spectacular. They're the result of real attempts, real mistakes, and real adjustments.

Lesson 1: the workflow matters more than the model

The most common discussion in AI engineering circles is about models. Which one is ahead right now, which has the biggest context, which is cheapest. Interesting discussions — but secondary in daily practice.

What actually counts is the workflow around it. Which skills are defined. How subagents are structured. Where MCP servers plug in. How the fallback chain is built. All of that together has a far bigger effect on productivity than the choice between model A and model B.

Consequence: invest in skills, prompt templates, tool integrations, review structures — not in model comparisons.

Lesson 2: robustness is mandatory, not a luxury

One of the more uncomfortable realizations: AI workflows can fail silently. Classic pipelines are loud when they break. AI pipelines are often quiet. For me that led to a multi-week silent outage — the workflow was technically running, but it had stopped classifying almost anything.

Four layers I now always build in:

  • Fallback chains: more than one provider, more than one model
  • Structured logs: what's currently happening, which stage is active
  • Smart alerts: no successful run in X hours → alarm
  • Rule-based fallback: when every AI stage fails, don't just stop

Lesson 3: persistent memory is the real multiplier

Workflows without persistent memory are throwaway workflows. Not because they don't work, but because they never get smarter. My first six months without memory were largely throwaway sessions.

Today my most important workflows read a memory file at session start: known quirks of systems, personal preferences, lessons learned. The effect is significant — the agent understands context better and makes fewer beginner mistakes.

Lesson 4: security from day one

AI workflows have their own security profile. Four everyday risks:

  • Data leaks: screenshots with internal URLs, log excerpts with tokens passed along unfiltered
  • Tool permissions: minimal permission per task — what isn't needed isn't accessible
  • Provider data handling: whatever you send to an external provider goes there
  • Action boundaries: what the agent may do automatically, what needs human confirmation

Lesson 5: team-readiness is the decisive step

AI tools that only work for solo engineers have a limited future. What my setup needs to become team-ready: shared skills, shared MCPs, clear tool guidelines, documented conventions, expected verification.

From where I stand, team-readiness is the next big step for AI-assisted engineering work. Personal workflows are largely mature by now.

My view after this year

In 2026, AI-assisted engineering work has reached a point where it's genuinely productive — provided you build it up seriously. What hasn't changed over the year: AI doesn't replace responsibility. It takes on neither architectural decisions nor domain judgment.

What has changed a great deal: the speed at which good technical work becomes possible once the setup is right. Good engineers who work in a structured way can achieve more than ever before.