Overview
Basic Set up
- File Structures
Hooks Based Approach
Kiro IDE offers hook which triggers the predefined natural language based workflow. A hook can load the instructions into the chat interface and the agent will take the instructions and perform the task by following the instructions.
For example, you can define a hook which adds js docs whenever a file with .ts extension saved. The instruction could be:
You are a JavaScript expert. Can you review the saved ts file to see if there's any js docs missing or out-of-date? If so, please add or update the js docs.As mentioned above, this hook will be triggered whenver a .ts file saved and the Kiro IDE will scan the saved file and append or edit JS doc if necessary.
A pitfall of this approach is Kiro IDE's editing might also run the hooks as long as the trigger condition met. This pitfall could potentially create a chain reaction. As the defined hook modifies the files which sets off anohter hook to update the same file and on and on.
This kind of drawback explicitly forces us to re-think about the hook action and effects when defining a hook to ensure the set of hooks can end without further comsuming more computing powers.
The hooks based approach could leverage this kind of chain reactions to bake the normal human coding excercise into a action chain.
When we as the human developer to solve a certain issue with typing code, we usually divide the problem into a set of smaller probem and address each subproblem individually. then we can roll up to the bigger problem and solve the problem at the end. That is the typical divide-and-conquer methology. When we appraoch the undividable problem, we usually map the our thoughts into certain flow to address the issue. Let's take a simple example, finding a element in an array. The first approach we can think of could be iterating through the array until find the element, if we cannot find any matching element, the program should return a predefiend value or throw exception. The thoughts above can actually be the instructions we can feed to the coding agent so that the coding agent can solve the problem based on the detailed instructions. What could be the next step after the inital code written? We probalby want to do some testing here to ensure the code can return the desired results. What's next after tests? Optimization, adding comments, improving readability, etc. This kind of coding "pattern" can be modeled into hooks to shift our human developers from coding to writing.
- Feature Hook - scan the file comment with "feat: " to implement the feature
- Test Hook - scan the file comment with "test: " to implement the test cases
- Review Hook - scan the file comment with "review: " to improve the code
- ...etc
As the hooks mentioned right above, a human developer can first write the feature hook. In the element finding problem, we can write our desired approach to solve the problem. We can also add certain details like the name of the methods, how many methods we should have, etc, etc. When the human developer saved the file, the Kiro agent kicks in and start to perform the feature implmenetation. The next step, the human developer can start to come up with certain test cases or the instructions to build out the test cases and then save the file. The Kiro agent kicks in and start to write the unit tests. The next step, the human developer can start to review the code, add review comments to improve the taste of the code or address issues. Then the Kiro agent kicks in another round to evolve the code and present a better result.
If we zoom out from the details about how those reaction chain works, we can find the human-in-the-loop approach is still critical as the human developer is the main driver of the problem solving and quality assurance. However, the coding agent pairs in to liberate the human developers from typing and lower level implementation details.
So what does the human developer need to know under this development approach?
- Problem solving - the human developer still need to ensure we are solving the correct problem with correct appraoch
- Critical test cases - the coding agent could come up with comprehensive, deliberate test cases to make the test coverage to 100%. However, human developers can connect the coding with real business edge cases and those connections could be more valuable when guiding the coding agent to write the correct tests and correct solutions.
- Code taste - at the end of the day, human still need to read the code, understand the business logic in order to verify if the code can fulfill the purpose. Human developers still need to understand the basic principles and patterns when guiding the coding agents. Those principles and patterns could make other peer human developers and coding agents to understand the solution effectively (mental model).
Natural Language Based Programing
If we look closer into the hook based approach, we can find there are plenty of back-and-forth. Can we guide the coding agent to come up with the plan in one solid shot? Probably we could, and I named this approach as Natural Language Based Programming.
When people interview with big tech companies, DSA has always be the frontline of the first a couple rounds of the interview loop. When the interviewee is examined with the DSA questions, most of the time, the interviewer is looking for if the interviewee can elaborate and implment the correct solution.
With the AI coding era, the implementation part has been completely snached by the coding agent. however, we can still focus on the elaborate part to:
- Clear our thoughts to find the elegant solution
- Provide coding agents details and guidance to implement the correct solution
- Provide other human developers context about our code with clear natural language instead of code.
Still, we can take the same old example - finding element in an array. We can start to create a task execution plan for the coding task. In that plan, we can elaborate the approach we want the problem to be solved or we can provide the clear description of the problem to let the coding agent go nuts with the solution.
We can provide test cases and stress the perspectives the test should focus on so that the coding agent can evole the solution on itself in order to achive the final results. We can also provide the constraints of the solution too. For example, most real life projects could have complicated dependency graphs and we can offer the coding agent some tips about what classes or packages they could use when solving the particular problem. The more details we can provide, the better results the coding agent can achive. However, we also need to ensure we are not providing redudant information to overload the agents or contributes to the LLM hallucination.
When we finalise the task execution plan, we can give it to Kiro IDE and we can leverage the Kiro IDE spec feature to divide the task execution plan into smaller actionable tasks so that it can execute automously.
We can also evolve our task execution plan too. We can add new requirements, give the agent new ideas or constraints and ask the agent to align the implementation with the taks execution plan.
At the end, when we raise Pull Request for code reviews, the task execution plan should be part of the code commit as it can share the thoughts with the broader team, give the reviewer clear context about what to review and help the team to improve the task execution plan in the future.