Kenta Kodashima
← All posts
September 13, 20266 min read

How I use AI at work

AI

With the rise of AI coding tools, a lot of engineers started coding using AI. How they embrace AI in their workflow can be different depending on the team and individual. In this article, I'm going to introduce how I use AI at work.

Approaches to software development using AI

Before I talk about how I use AI at work, I will briefly introduce two different approaches to software development using AI.

Vibe coding

The first approach is called vibe coding. In vibe coding, you leverage AI to handle the heavy lifting of code generation through a conversation so you can focus on the higher-level goals. Typically with vibe coding, we skip a lot of the processes that traditional software engineering values (e.g. planning the implementation and architecture, reviewing diffs, etc.) and start implementing the feature with a prompt. For example, you might just say "Add a search bar to the user list table." to start the implementation.

While vibe coding contributes to increasing productivity, it also comes with some caveats. The most concerning problems include:

  • generating code that just works in the happy path
    • introducing bugs and security risks
  • confidently providing wrong responses, which is what we call "hallucination"
  • downplaying upfront planning
    • installing unexpected libraries
    • adopting architecture that is inconsistent with your team's convention

AI-assisted development

The other approach is called AI-assisted development. In AI-assisted development, you integrate AI into the traditional software development lifecycle to improve the workflow and productivity. In contrast to vibe coding, you plan the work first. The plan includes an outline of the feature you need to build, constraints and acceptance criteria.

The main difference between vibe coding and AI-assisted development is that you specify your intent and constraints instead of letting AI guess them. By doing so, you are more likely to get output that aligns with your requirements.

For example, if I were to add a search bar to the user list table, I could write a prompt like the following. I typically ask AI to investigate and explain the plan first so I can review before I let it change any code.

What needs to be done to add a search bar to the `UserListTable` component?

Tasks:
* Explore the codebase to create a plan
* Check if there are any existing design system components that we can use

Requirements:
* Search should be case insensitive
* It should query the user's name and email
* Reuse an existing design system component if there is one

Which approach should you take?

There is no one right option, but in my opinion, vibe coding is good for fast prototyping to quickly confirm the requirements with the stakeholders or writing one-off scripts and temporary code, while AI-assisted development is generally preferred for actual changes that will be part of the production codebase.

One thing my team is trying out is to generate a prototype with vibe coding, and then switch to the AI-assisted approach to turn the prototype into production-ready code.

My day-to-day workflow

Now I will talk about how I use AI at work. Note that my work may include non-traditional tasks for engineers as I work in a small team of engineers.

General workflow

  1. Understand the requirements
    • Talk to stakeholders if anything is unclear
  2. Let AI look into the codebase to understand what needs to be done
  3. Review the AI-generated plan
    • I usually let it write the plan out to a Notion page so it's easier for me to review
  4. Let AI generate code according to the plan
  5. Manually test some user workflows to ensure the feature works as expected
  6. If anything seems off, tell the AI to address the issues
    • Repeat 5-6 until I'm satisfied
  7. AI code review
    • We have automated AI reviewers that leave comments on the PR (triggered by commits)
    • I let AI address all the comments before I open the PR for human review
  8. Review code by myself before I open the PR for human review
    • After addressing AI comments (or while I have AI address the comments), I at least have a look at the PR I am opening. Otherwise, it would be like delegating review to other engineers, which just feels lazy to me.
  9. Merge and deploy after human review

Other things I use AI for

  • Ticket creation (for bugs and features)
  • Existing codebase analysis
    • I ask AI questions about the codebase before I ask people
    • Its answers are usually good enough
  • Git operations
    • Create PRs
    • Commit changes with a message

Things we are still figuring out

Even though AI tools are helping us be more efficient, they are not perfect. I listed out some concerns with AI that we are still figuring out.

How much permission we should give to AI

By default, AI coding tools such as Claude ask for your permission to do anything. A lot of them have now introduced an "auto mode" which allows AI to think and make decisions on its own. While it's useful to reduce AI fatigue and build things faster, it can execute dangerous actions behind your back. For example, when I was trying it out, I saw that it created a one-off script to read data from the DB or local files.

One thing we tried on our team is to create a dockerized sandbox where we can use auto mode relatively safely. In the sandbox, AI does its job using tokens prepared specifically for the sandbox, and it only has access to the files mounted into the container. While it's a safer approach, it comes with some inconvenience. For example, if I want to take a screenshot and let AI have a look at it, I have to move the screenshot into the project directory so it gets mounted.

How thoroughly we should review AI-generated code

Since AI can write code a lot faster than humans, the amount of code that we have to review can be overwhelming. We can always split one PR into smaller pieces so it's easier to review, but then we end up taking care of many small PRs at once. In a small team, engineering resources are limited. So, people can end up with 10 PR reviews in a day.

On my team, we are still figuring out the right balance of code review, the size of the PRs and the review best practices.

Conclusion

Until last year, I had never thought that AI would be so deeply incorporated into our daily workflow. The quality of AI outputs is improving rapidly, and we are delegating more work to AI. Even though I don't believe that AI will take all the jobs from engineers, the main part of our job is changing from implementation to making architectural decisions and directing AI. Being able to work with AI tools to improve productivity is now a required skill for most jobs rather than a nice-to-have.

Reference