"Someone opened a Miro board."

That's how I knew we were in trouble.

Not because I dislike diagrams.

I like diagrams.

I dislike what usually happens after someone opens a Miro board.

Boxes appear.

Then arrows.

Then more boxes.

Then someone says:

"What if we had a Requirements Agent?"

Someone else nods.

"What if that fed into an Architecture Agent?"

"Which then talks to a Coding Agent."

"Which hands over to a Testing Agent."

"Oh! And a Documentation Agent."

"Don't forget the PR Review Agent."

At this point we have accidentally hired an AI engineering department.

The funny part?

We still haven't solved the original problem.

We've built middle management before we've built memory

The thing that fascinates me about the current AI tooling landscape is that everyone seems obsessed with designing specialists.

Every prompt has a job title.

Every workflow has another agent.

Every new capability apparently deserves another box in the diagram.

Meanwhile the poor model starts every conversation by asking:

"Where are the coding guidelines?"

Again.

The average backend task isn't that exciting

Let's be honest.

Most of us aren't inventing new consensus algorithms before lunch.

Our work usually looks something like this:

  • Read a Jira ticket.
  • Figure out what the business actually meant.
  • Find the relevant code.
  • Check you aren't breaking an architectural decision someone made three years ago.
  • Implement the feature.
  • Write tests.
  • Open a PR.
  • Rename one variable because someone says it "reads nicer."

The difficult part isn't typing Java (or Python, or C#, or TypeScript, or Rust... or, God forbid, Visual Basic).. It's reconstructing context.

Every. Single. Time.

Congratulations, you've recreated a junior developer

Every fresh chat starts the same way.

"Can you fetch Confluence?"

"Can you open Jira?"

"Where are the guidelines?"

"Do we have an ADR for this?"

Eventually your AI spends more time talking to MCP servers than helping you write software.

Congratulations.

You've recreated a junior developer during week one.

Except unlike the junior developer...

...you wipe its memory every morning.

Documentation shouldn't be a runtime dependency

This was probably the biggest mindset shift for me.

Jira is... fine.

Confluence is... also there.

For humans.

But if every implementation requires the AI to continuously fetch Jira tickets, Confluence pages and random documentation...

...your documentation has become a runtime dependency.

Anything your AI repeatedly needs should simply exist in your knowledge base.

Coding standards.

Architecture decisions.

Business terminology.

Review expectations.

Common implementation patterns.

The "please don't touch this query after 4pm on a Friday" notes.

Markdown.

Markdown.

More Markdown.

If Confluence is still the source of truth, great.

Synchronise it.

Export it.

Embed it.

I don't particularly care how it gets there.

I care that the AI opens a local Markdown document instead of making its fifteenth MCP request of the day.

Less fetching.

More building.

Obsidian isn't a notebook. It's memory.

People ask me why I like using Obsidian alongside AI.

It's not because I enjoy collecting Markdown files.

It's because Obsidian becomes a second brain.

Every architectural decision.

Every naming convention.

Every lesson learned.

Every business quirk.

Every "we tried that in 2024 and production caught fire."

Once it's written down, the AI stops rediscovering it every conversation.

The boring part wins

This is where tools like Superpowers really clicked for me.

Honestly, replace "Superpowers" with SpecKit, Matt Pocock's workflows, or whatever orchestration framework you prefer.

The name doesn't matter. The orchestration does.

Imagine the flow.

One skill gathers context.

It reads the Jira ticket.

Finds related Markdown.

Loads business specifications.

Pulls architecture decisions.

Finds similar implementations.

Done.

The next skill takes over.

Loads project guidelines.

Checks architectural constraints.

Reminds the model about naming conventions.

Highlights business rules that everyone forgets.

Done.

Implementation finishes.

Another skill takes over.

Generate the PR description.

Check documentation updates.

Suggest release notes.

Identify defects.

Raise technical debt where appropriate instead of adding another immortal TODO.

Generate review comments that actually sound like your team.

Notice what didn't happen?

We never created a PR Agent.

Or an Architecture Agent.

Or a Documentation Agent.

They're just small reusable skills passing context to one another.

The clever bit isn't the individual skills.

It's the choreography.

Please stop giving prompts LinkedIn profiles

Some prompts start like this:

You are a Distinguished Principal Senior Staff Software Architect with twenty-five years of enterprise experience...

Mate. You're writing a commit message.
Take it easy.

Modern models are already ridiculously capable.

The difference is rarely intelligence.

It's context.

One good brain beats twenty clever employees

The more I experiment with AI-assisted development, the more I believe we've been optimising the wrong thing.

We don't need another specialist.

We need better memory.

We need better orchestration.

We need our project knowledge to be available before the first line of code is written.

Ironically, that's also what makes human developers productive.

Knowledge.

Context.

Shared conventions.

Not job titles.

Before you add another agent...

Next time someone opens a Miro board and proudly shows you twenty AI agents connected with colourful arrows...

Ask one question.

"Where are your coding guidelines?"

If the answer starts with:

"Well... they're mostly spread across Confluence..."

Close the Miro board.

Open Obsidian.

Start there.

Because most backend teams don't need another AI employee.

They need a second brain and a handful of well-orchestrated skills.

Everything else is just middle management.