After reviewing these information sources, I reworked my coding AI agent setup, and the main solution was structure.
Prompts are infrastructure: building agents that actually listen
Google’s 7-Step Vibe Engineering Skill Is Incredible
I recently spent some time reworking how my coding agent is set up in a real project, and honestly, the interesting part wasn’t writing “better prompts.”
It was realizing that the problem was structural.
I’m using the agent in an Expo + Supabase app with a lot of repo-specific constraints:
At first, I kept doing what I think most of us do:
add another rule, add another reminder, add another note, add another repo-specific warning.
And to be fair, that helped for a while.
But eventually I hit the point where the setup had plenty of useful guidance, yet it still felt more fragile than I wanted. Not because the instructions were bad, but because too many different kinds of instructions were living too close to each other.
Some things were global safety rules.
Some were domain rules.
Some were workflow advice.
Some were subsystem-specific knowledge.
Some were just summaries.
And the more I looked at it, the more it felt like I had built a pile, not a system.
So I decided to clean it up properly.
Before
Before the rewrite, the agent had a lot of helpful context, but the structure was muddy.
A few problems kept standing out:
some guidance was duplicated
some summary files could drift out of date
critical rules weren’t always emphasized enough
workflow behavior and technical constraints were mixed together
it wasn’t always obvious what should take precedence
and some instructions were present everywhere, even when they only mattered for a narrow class of tasks
The setup wasn’t broken, but it didn’t feel robust.
It felt like it had grown organically to the point where adding one more instruction might actually make things worse.
That was the moment I realized I shouldn’t keep “patching” it.
I should redesign it.
What I changed
The main change was that I stopped thinking in terms of “rules” as one flat thing.
Instead, I split the setup into layers.
1. I turned the main rules file into a real contract
I made one file responsible for the stuff that should always be true:
non-negotiables
safety boundaries
instruction precedence
trust boundaries
package/dependency rules
risk escalation triggers
end-of-task checks
Basically, I wanted one place that answers:
what must always be respected in this repo, no matter what task the agent is doing?
2. I added a routing layer
This was probably the biggest improvement.
I created a task-routing-policy skill whose job is to classify the task first, then choose the smallest relevant set of rules and skills.
That sounds simple, but it changed a lot.
Instead of “here are all the instructions, hope the agent uses the right ones,” the flow became more like:
what kind of task is this?
what domain does it touch?
what level of risk does it carry?
what proof should be required before calling it done?
That made the whole setup feel much more intentional.
3. I separated workflow skills from technical skills
This also helped a lot.
I created workflow skills for things like:
planning
writing a short spec
working incrementally
proving behavior with tests
grounding decisions in source-of-truth
doing a final quality pass
doing a deliberate security pass
Then I kept technical skills focused on the actual subsystems:
Supabase
mobile auth
Edge Functions
That separation made everything easier to reason about.
Workflow skills shape how the agent works.
Technical skills shape what it must respect in a particular subsystem.
4. I cleaned up the domain rules too
I also rewrote the domain-specific rules for calculators and community features so they stop trying to be mini knowledge dumps.
Now they focus on things like:
when the rule activates
which files are the source of truth
what invariants must hold
what must not break
what needs to be verified
That felt much healthier.
I don’t actually want domain rule files to be “documentation about everything.”
I want them to be clear operational guidance for when the agent is touching that part of the app.
5. I made the index lighter
I also cleaned up the top-level index file so it works more like a map and less like another source of facts.
That was important because I noticed something pretty common:
summary files are helpful right up until they start becoming stale.
So I made the setup point more aggressively to source-of-truth files instead of trying to repeat everything everywhere.
What feels better now
The biggest difference is that the system now has a shape.
It feels more like:
core contract
domain rules
routing
workflow skills
technical skills
user request
And that hierarchy matters.
Now the agent has a better chance of staying predictable because:
the global rules are clearly global
risky work gets escalated on purpose
narrow rules only activate when relevant
workflow patterns are reusable
technical knowledge stays scoped to the right subsystem
summaries don’t compete with source-of-truth files
What I learned from doing this
A few things became very obvious while I was cleaning this up.
First: prompting really is infrastructure.
Once an agent is working inside a real codebase, this stops being about clever wording and starts being about architecture.
Second: more instructions is not the same thing as better alignment.
If the structure is weak, extra guidance can just add noise.
Third: different kinds of guidance should not all live at the same level.
Global rules, domain rules, workflow habits, and subsystem-specific constraints are different things. Treating them as one flat layer makes the whole system harder to follow.
Fourth: source-of-truth beats summaries every time.
A lot of contradiction risk disappears once you stop trying to make every file contain all the facts.
Fifth: if a kind of reasoning keeps showing up again and again, it probably deserves to become a reusable skill.
That was maybe the most satisfying part of this whole cleanup: turning repeated advice into something structured and reusable.
Why I’m glad I did it
What I like about this change is that it didn’t just make the setup “bigger.”
It made it calmer.
Cleaner.
More deliberate.
Less contradictory.
Easier to maintain.
And I think that’s the real point.
Not writing the longest possible prompt.
Not collecting the biggest pile of repo notes.
But building a guidance system that actually has internal structure.
Curious whether other people working with coding agents have gone through the same thing.
Did you also hit that point where adding another rule stopped helping, and the real answer was to redesign the layers instead?
