Atomic Development Principles and Enforcement System (AI Optimized Steering)

[broken herald]

I've included my favorite 6 steering documents I created, as a system for optimizing my steering for all execution in Kiro.

(after a significant amount of iteration)

Summary;

Key Problem Statement: The LLMs powering AI IDEs excels at Context Retrieval (long-term memory: the entire codebase/spec drive) and Code Generation (transforming text/spec to code).

It fails at Working Memory and Coordinated State Transition (short-term memory: tracking the necessary steps, side effects, and dependencies of a complex, multi-component task).

Strategic Justification: The highly serial, atomic, and test-validated workflow is a "human validated externalization of the AI's short term memory." By enforcing "one item, one test, one compile," we are forcing the AI to successfully complete and commit a single, unambiguous state transition before being handed the next state transition.

In my opinion most humans are bad at state transition too so I'm leveraging some agile, some waterfall etc etc to compensate for what AI is good at.

Other supporting ideas here driving additional iteration;

Specification (Spec Drive): The Spec Drive must detail functionality down to the atomic, single-purpose unit (e.g., "Add the API path /users/{id}/details," not "Build the User Profile module").

Task Granularity: Each task given to the AI must correspond to one atomic unit (one component, one API path, one database migration step).

Vertical Slice Prioritization: Always prioritize validated communication (Front-End \rightarrow Back-End \rightarrow Database) before expanding a layer (e.g., a simple, end-to-end hello-world route must be complete before adding another route).

Test-First, Commit-Atomic: The AI must first generate the test for the atomic unit. Then, it generates the code. Success is defined by:
Test Pass (Functional validation)
Successful Compile (Structural validation)
One Atomic Commit (Historical memory lock)

No silver bullet, but trying.

[twin crane]

do you feel that these steering instructions make noticeable difference in your projects?

[broken herald]

@twin crane Yes, specifically the atomic approach, where I'm enforcing functions must have appropriate tests, and must lead to a successful build in serial steps. So some test driven development at play here too. The enforcement system has been helping to step it from carrying on to extra steps and instead focusing on nailing the one it's on.

So it may say "Task 3 is now Task 3.1->3.4" which helps me audit and resteer if necessary

[full veldt]

works well - I put these in an existing project and then did the following "review the following steering documents. make any changes so they are appropriate for the project code methodology - DO NOT make them larger or more complex - YOU CAN reduce their complexity and items as long as they are still effective.

validation-systems.md

serial-development-protocol.md

no-assumptions-enforcement.md

conflict-resolution-procedures.md

comprehensive-enforcement-system.md

atomic-development-principles.md"

This worked well - some changes to match the project (docker commands etc..) and it removed aspects not needed for this particular project but left around 70% totally unchanged. Worth checking the diffs before accepting the changes (but all made sense for my context).

[broken herald]

@full veldt badass. Very glad it was plugin and play for you. That was my goal.

I recently consolidated these down to just 3 items too in my own system about a day ago to increase the potency of the steering prompts as tokens.

You can just ask Kiro to complete that for you and reduce the verbosity and consolidate to the most critical takeaways!

[agile hare]

@broken herald hey, I couldn' see the security best practices file, unless I've mis-read, would you mind uploading it please?

[broken herald]

@agile hare

[iron stone]

Thanks for the share! Optimisation tip: Ask Kiro to read the docs (You might need to ask it to read them using cURL), and then consolidate and optimise the steering docs for you.

[broken herald]

We had the same idea! I need to update this post as I reduced them all down to 2

[slate hamlet]

@broken herald can you share them please? like to check them out 🙂

[broken herald]

Originals are attached to the first post @slate hamlet you can also have Kiro simplify them down for you if you just want to have one doc.

[finite sigil]

@broken herald , thanks for taking a crack at this. I'm going to give it a try on a project. This topic is especially important as LLMs evolve.

I came across this article and found the approach is similar. The study linked is a good read and may help refine the structure even more.

https://news.mit.edu/2025/mit-researchers-propose-new-model-for-legible-modular-software-1106

[quaint ermine]

do these steering docs take up a lot of context and or token count to get invoked all the time?

[maiden crown]

Steering, mcp and anything that's added is more context.

If you send a 3 tokens prompt but have 5 steering each having 3 tokens in lenght/size then you are sending 3 (prompt) + 15 (5 steering at 3 tokens) so in fact you are sending a 18 tokens prompt

same goes with MCP, without a prompt can be 10 tokens, with MCP the same prompt can be 50 tokens for example it all depend on how you manage your MCP

(that's why it's important to only have the one you are currently using activated or use MCP-managers)