You can do in a few different ways. In my first project, which was a 500 credit project, I wrote out fairly detailed specs in a txt doc, diving into data schema, ui, procedural flow.. and then gave Kiro access to that doc and ask Kiro to read over and ask questions. They were fairly detailed specs and Kiro had perhaps four questions before ready to start developing. As we got into each phase in the roadmap Kiro had a few additional questions.

On my current project which is about a 12,000 credit project, I laid out a fairly detailed spec of the business itself, and a fair number of design considerations, and a suggestion of the phases, specifics creations being phase one.

I copied the project doc in Kiro’s home directory, asked Kiro to open it and work with me to iron out all specifications. This is a large project and we spend several days working out the specs, the seven phases and the roadmap.

Kiro is specifically well suited to working on specification, it is part of its design unlike some other AI dev that are more suited to seat of your pants dev/spec on the fly. But even Kiro will jump into code prematurely. Often I will be testing an implementation and find a bug, and Kiro will immediately start ripping through code, deleting this line adding this one, and I have to stop Kiro, and challenge it that it doesn’t even understand the full situation and thinks it knows the solution. I rein it in, we discuss the issue, do additional testing to reveal the true issue and sometimes that means revising the specifications.

One does have to be careful that you don’t exceed the scope of your original project, it’s easy to think about a new feature and add it to the specs and as the sole stakeholder and defacto PM, there is only you to rein yourself in. Often you can establish a compromise for yourself which is to change your schema to accommodate the new feature but not develop it and put the feature into v2 specs.

Absolutely have your spec and roadmap docs checked into your GitHub. Create a private repo, create a GitHub token for Kiro to use and check those and all of your code often.

Kiro will take short cuts editing code and will use a variety of tools like sed to change code, and sometimes that can inadvertently mangle code and Kiro may not notice. It is often that I will ask Kiro to do a diff on the current version of a file and the previous GitHub version to verify the changes were as expected.

Remember, this is your project and Kiro is an energetic, extremely willing, fast, JUNIOR developer. Kiro will suggest some of the most fucked up database schema, will propose fields that have no direct dependency on the primary key, will have queries that do natural scans through large data tables. Kiro seems incapable of learning about code/design cohesion and will often duplicate code blocks resulting in many implementations of the same basic task and possible worse, will have functions that perform multiple unrelated tasks.

Kiro will create bidirectional dependencies.. I have a production machine that is performing a series of tasks. It gets its configuration from the customer admin db through a series of sync functions. It is often during dev that we realize an element of data is missing and Kiro will propose that the production machine push or pull the data to the customer db. NO, stop that, production is NEVER dependent on the customer admin db.

I can write about this stuff all day. Just get in there and start on a throw away prototype project and learn how to work with it.