From AI Skills to Situationally Aware Engineering

AI can now write code, review pull requests, and execute engineering workflows. But it still doesn't know whose service it just changed — or why that matters.

That gap is the most important unsolved problem in AI-assisted engineering today. And a recent post from Anthropic brings it into sharper focus than anything I've read in a long time.

Anthropic Validates the Direction

A few days ago, Anthropic published Lessons from building Claude Code: How we use Skills. It describes how their team packages reusable knowledge, workflows, and tools into capabilities that Claude can invoke when needed.

The categories they describe are recognisable to anyone running an engineering team at scale: code review and quality, CI/CD deployment, data fetching and analysis, business process automation, infrastructure operations, runbooks and incident response.

It's worth reading — not for the implementation details, but for what it signals. We are entering a phase where AI systems don't just answer questions. They execute work. Real engineering work, in real systems, with real consequences.

Skills are one of the key mechanisms that make this possible. And Anthropic building them into Claude Code is a meaningful step forward.

But There's a Question Nobody Is Answering

As I read the article, one question kept coming to mind.

How does an AI know whether a skill should be used — and whether it's safe to use it here?

A deployment skill might know how to deploy software. A code review skill might know how to review a pull request. A migration skill might know how to transform a service from one language to another.

But does it know:

• Which systems depend on this service?
• Which customers will be affected if this goes wrong?
• Who owns this component and who needs to be consulted?
• What broke the last time someone touched this?
• What production behaviours absolutely must be preserved?
• What operational constraints exist that aren't obvious from the code?

These aren't coding questions. They're context questions. And right now, no AI system can answer them reliably — because that context doesn't exist in a form AI can use.

Consider what this means in practice. An AI migration skill that doesn't know a service handles 40% of payment traffic will approach that migration exactly the same way it approaches a low-risk internal utility. Technically correct. Operationally dangerous.

The Real Problem Is Situational Awareness

Over the last year, we've spent a lot of time with engineering teams experimenting with AI-assisted development. The feedback is consistent.

Engineers are impressed by what AI generates. What they struggle with is trust. Not because the code is wrong syntactically — but because the AI lacks operational understanding. It can produce something technically correct that is simultaneously operationally wrong.

That's not an AI capability problem. It's a context problem.

Experienced engineers carry enormous amounts of contextual knowledge. They understand architecture. They remember previous incidents. They know who owns what. They understand dependencies, risk, tribal knowledge, and organisational history that was never written down anywhere.

When a senior engineer makes a decision, they're applying far more than coding knowledge. They're applying understanding. Situational awareness.

Modern AI systems need access to the same understanding if we expect them to participate safely in engineering work.

Skills Need Context. Context Needs to Be Structured.

This is where we believe the industry is heading — and what we've been building towards at OpenTrace.

Skills define how work gets done. Context defines where that work is being performed. Neither is sufficient on its own.

"A powerful skill without context can execute the wrong action extremely efficiently. A rich context model without skills cannot turn understanding into action. The future requires both."

The context that AI systems need isn't just source code. It includes code structure, runtime behaviour, service dependencies, architectural boundaries, ownership, expertise, operational history, and approval workflows. Structured, connected, and queryable — not buried in wikis, Slack threads, and the heads of your most experienced engineers.

That's what we've been building.

What OpenTrace Is Actually Building

When we started OpenTrace, we set out to build the context layer — a living knowledge graph of how your systems actually work. Not a diagram. Not documentation. A connected, always-current model of your codebase, your services, your people, and your operational history.

But as we've worked with engineering teams, we've come to understand something important.

The context layer alone isn't enough.

What teams need isn't just better context stored somewhere. They need agents and tooling that use that context to do real engineering work — and they need that work surfaced to the engineers who are responsible for it.

So we've been building that too.

We're developing a suite of engineering agents that are grounded in system context:

• Migration agents that understand service boundaries, ownership, and dependencies before touching a line of code — so when you're moving from Go to Rust, the agent knows which functions are critical, which have hidden callers, and which need human sign-off before proceeding
• Expertise graphs that surface who has actually touched a component, not just who nominally owns it — so the right engineer is in the loop when something changes
• Incident response agents that arrive with full operational context already loaded — previous incidents, hypotheses, affected services, and the team members who've seen this before
• PR review agents that understand blast radius, not just diff — so code review reflects real operational risk, not just syntactic correctness

These aren't hypothetical. We have working prototypes running against real codebases. And we're connecting all of this to a dashboard that surfaces what matters — drift, anomalies, pending approvals, and active hypotheses — to the engineers who need to act on it.

Why This Matters Now

Anthropic's Skills announcement validates something we've believed for a while: AI-native engineering won't be built around giant prompts. It will be built around reusable capabilities, connected to the systems and people they're operating within.

But we think there's a step beyond what's been discussed publicly. The teams that will actually unlock the ROI from AI-assisted engineering — the ones in that 20% who are getting real results — aren't just the ones with the best AI tools. They're the ones who have given their AI a deep understanding of their specific systems, their specific people, and their specific operational reality.

That's the problem we're focused on. Not AI in the abstract. AI that knows your systems.

We're Looking for Engineering Teams to Build This With

We're at an early but meaningful stage. The context layer works. The agents are developing quickly. And we're looking for a small number of engineering teams who want to be part of shaping what this looks like.

If your team is already using AI coding tools — Claude Code, Cursor, Copilot, Windsurf — and you're running into the trust and confidence problems I've described here, we'd love to talk. Not to sell you something. To build something together.