[tech] Building with AI editors
In the previous post Announcing US Visa Bulletin Hub I shared the personal project I had been working on for some time. Besides solving for my own smaller problems I typically like to continue exploring new techniques or tools. In this post I’ll discuss a bit more on how the project was built. Areas will include tools and how I see programming evolving.
AI editors
The primary AI editor I used for development was Kiro from Amazon. Kiro, like Cursor, is an AI-native integrated editor. It too is built on the Visual Studio code platform.
AI-native editors bring a chat-like experience front and center rather than an editor experience with an enhanced auto-complete. The first versions of Github Copilot brought ground-breaking autocomplete to regular IDEs. However, that was so 2022. Newer AI-editors do a lot more complex tasks.
The primary method of AI-editing is called vibe coding where you can iterate over changes. This can be asking about the codebase or making changes.
Kiro also brings a different experience called Spec driven development. Interaction begins with a chat experience, but the output from this stage is a triad of docs as part of a specification. The component docs in a specification are-
- Requirements - user stores and acceptance criteria in a structured form of WHEN -> THEN
- Design - technical architecture and implementation concerns.
- Task list - implementation plan for a step by step approach for solving the broader problem.
With specifications, you are forced to think through what you want to build and how. Further these serve as context for the LLM generator as changes are incrementally made. Technically the specifications are simply text based markdown files. Diagrams generated are also based on textual mermaid tool. In the latest version of cursor, it does generate a plan as well before going through a change which is similar to a spec. However a spec is committed and hence also helps as a future reference point.
Workflow changes
The new AI based tools are definitely able to accelerate productivity for small projects. With very little direct effort I was able to produce a medium sized project.
These tools still require solid technical understanding but do not require deep technical work anymore. My day job as an architect requires me to make a lot of high-level decisions and drive architecture and hence such tools fit how I work.
These tools are becoming more advanced in many ways. There were a few times when the proposed design of a spec from kiro was better than what I had expected. There were newer versions of some AWS services and the tool was able to offer a better solution.
At the same time, these tools have a strong inclination of generating tons of verbose code. Even in my project I have some duplication which as a human author I would try and refactor into a common library. But my tools are making me lazy.
Coding no longer requires deep thinking. Instead you fire off a few commands and hope for the best. In theory, I can review the output from each task and then trigger the next one. However after the initial euphoria waned off; I just started triggering all the tasks in a spec and then went away to other chores. There were a few instances where I had to scrape off a complete feature since the output was not what I expected. Few steps forward and some backward. Understanding how to give well scoped tasks will continue to be what a good engineer does. I’m not yet confident in multiple agents autonomously making changes to a codebase.
Looking into the future
The bar for junior software engineers to enter the industry is going to be higher. With AI tools like these; there is clearly going to be a shift of work from humans to agents.
Code reviews become critical with such tools. However at the same time it will not be easy to humanly review large code dumps. Hence it is likely that code review agents become more prevalent which are able to validate code style and other lesser concerns. For the bigger picture well written and tested specs should be enough.
Programming itself has become easier. And hence we will generate more code and not less. However the true cost is typically around maintenance and migrations. Hence understanding these complex custom solutions to humans and making large scale changes will be a big area. Tools like Codewiki might be interesting to follow.