Let the Steering Begin
Where I’m coming from
I spent over three years at a decacorn doing platform engineering. In that environment, every technical decision—performance tuning, abstractions, defaults—had org-wide impact. You learn quickly that systems thinking matters more than clever code.
This was the pre-LLM era.
Where I am now
I’m currently at a recently funded startup. The systems were designed to serve multiple customers with different needs. The direction is clear: scale is coming, and today’s decisions will either enable it or slow it down.
This is the post-LLM era.
What I used to believe about AI
- AI-generated code is useful only for prototypes.
- Production systems still need humans end-to-end.
What changed after one month
- Roughly 80% of AI-written code works well in production.
- When given sufficient background, LLMs solve real problems reliably.
One word explains the difference: context.
The real failure mode
Consider a simple requirement:
“Show total file/blob downloads for a service.”
In modern workflows, an engineer opens an agentic editor, types the request, and lets the AI start coding.
This works well when:
- the codebase is small, or
- the service is isolated.
It fails when:
- the system is a monolith, or
- multiple services and historical decisions are involved.
We usually blame the LLM.
That’s incorrect.
The failure is ours.
The model didn’t have enough context—and we didn’t give it one.
What was missing: an Alignment Layer
LLMs don’t reason in a vacuum. They need a structured understanding of:
- reality,
- constraints,
- system state,
- and intent.
That structure doesn’t appear automatically. It has to be designed.
I call this missing piece the Alignment Layer.
After exploring this idea in my earlier work, I refined it into something more concrete: not “agents”, but systems coordinated through orchestration.
This framing removes personality and turns the problem into infrastructure.
A system-first cognitive stack (compressed view)
Think of this as a control plane for AI-assisted engineering:
- Reality – what is objectively true (constraints, pressure, blast radius)
- Gravity – how values and tradeoffs bias decisions
- Legitimacy – whether a request is even worth solving
- Legibility – making the current system understandable
- Synthesis – generating bounded architectural options
- Intent – translating raw human input into structured execution
Each layer does one job:
- Systems do the work
- Orchestrators coordinate
- No layer assumes intelligence or intent from the model
The output isn’t code first. It’s clarity first.
Why this matters to technical leaders
This approach:
- Treats LLMs as deterministic infrastructure, not teammates
- Prevents premature coding on poorly defined problems
- Scales better than ad-hoc prompting
- Makes AI reliable in complex, interdependent systems
In short:
AI doesn’t fail because it’s weak. It fails because we ask it to operate without alignment.
Experimentation
To validate this, I simulated the model as a decision-making system:
- Connected a GitHub MCP server to Claude Code
- MCP was given access to source code of all the services that does the job
- Introduced an orchestrator layer
- Let the AI decide whether and how to add functionality
My only Query: I want to display a webpage for internal org users where we can visualise daily attachments.
Instead of one more frontend and one more backend.
It just told me edits we need to do in our existing codebase in order to achieve it.
The difference wasn’t better prompts.
It was better structure.
Below screenshot was just a validation:
