I Build Solo

How I Collaborated with Claude on Building a Feature

What I Worked On

This week, I was able to fix two tricky issues for a habit tracking app I’m working on. For example, I worked on improving the notifications settings page (see screenshot) by fixing issues related to edge cases. I collaborated with Claude on this task and this is how I structured my workflow from the beginning to completion and how I used Claude to get help with each step.

Notification settings page

Step 1: Write a Thorough Ticket Description (Planning)

Day of Week: Tuesday-Wednesday
Location: On a commuting train ride
Time taken: Several 5-10 minute sessions on my phone (via the GitHub app)

  • [Me] Created a new GitHub Issue and write a draft description in a few sentences
  • [Me] I asked Claude in the comment section via GitHub Action to refine the ticket description. I asked it to identify any ambiguities I should clarify if any.
  • [Claude] Wrote an improved, more detailed ticket description with ambiguities about the requirements if any
  • [Me] I answered the questions about ambiguities
  • [Me & Claude] Repeat
  • Result: A refined ticket description that’s ready for Claude to execute on

Step 2: Create a PR with Draft Implementation (Engineering)

Day of Week: Tuesday-Wednesday
Location: On a commuting train ride Time taken: A few minutes

  • [Me] I asked Claude to implement a solution that fulfills the requirements
  • [Me] I press the create a PR button that Claude’s response included (It seemed somehow Claude can’t do it on its own yet via GitHub Action.)

Step 3: Test and Refine the Implementation (Engineering)

Day of Week: Saturday
Location: Home workstation
Time taken: Several hours of focus work

  • I opened Xcode, switched my branch to the one with Claude’s changes. Also, I have Claude Code open on terminal for the same project on the side.

  • I made various refinements to make the project build if it doesn’t yet. E.g., adding new files to the project directory (It seems Claude can create files but can’t update the Xcode project file to make them appear in Xcode.)

  • I thoroughly reviewed the PR and all the changes. During the process, I took the following actions:

    a) If I didn’t understand anything, I asked in Claude Code about the rationale or how the code works.

    b) In the two tasks I worked on, there were a few times when I needed to clarify why the suggested changes were needed. It turned out Claude had added some duplicate logic because it didn’t fully utilize other parts of the codebase

    c) If I didn’t understand something and asked, that often led me to discovering Claude’s poor code or implementation styles, which I could improve to ensure high quality for the final output.

    d) I also noticed that Claude often used singletons directly in private methods, for instance. For such suggestions, I did some refactoring afterwards to add dependency injection to maintain view models testable. My feeling is that if Claude needs to do a major refactoring before doing something (e.g., making view models testable and adding new protocols first before it write unit tests), it often makes mistakes or its implementation becomes too complex or hard to follow. So, such “testability hygiene” is pretty important based on my experience so far.

    e) For new service or manager classes added (e.g., Claude suggested adding BadgeManager to centralize the business logic for determining the correct badge number to use across the app), I also asked Claude to write unit tests. Sometimes, it’s almost impossible to predict what the exact behavior will be in all situations. It wrote a suite of unit tests for both normal and edge cases. Afterwards, I reviewed the test cases and executed them on Xcode. Sometimes, the first shot code didn’t build or pass, but fixing them wasn’t too difficult.

Step 4: Merge the PR

  • When needed, I asked Claude to evaluate the overall changes on the branch again. When I tried that on one of the two tasks, it identified a few points as red flags related to scalability, etc., but I knew that it was going to be fine because the app is still in the MVP state and I didn’t want the code to become too complex too early (because that would slow me down and delay the app launch)
  • Eventually everything looked good, and I merged the PR via GitHub.

Reflection

What Seemed to Work Well This Week

The best part about this week’s workflow was being able to tackle the planning and early implementation parts of a feature development on weekdays during my commuting. This was great because I can get most of the PM and draft implementation work done via Claude and when I can do some focus work on weekends, I can jump right into reviewing PRs and improving, without having to do the planning myself and write draft implementation beforehand, which is often time consuming.

To maximally leverage this workflow, I should spend a few hours every Sunday to plan which tasks I’m going to tackle the following week. I should create new GitHub issues for those tasks with draft descriptions so that on Monday, I can start refining those tickets.

What I Think Could Be Done Better Moving Forward

In my opinion, Claude is very helpful now but is still not a perfect coding partner. Its implementation often needs to be thoroughly reviewed afterwards and doesn’t always use the ideal approach (e.g., adds duplicate logic). One reason might be because Claude doesn’t know the same amount of context I have for the project being worked on. For instance, I know that this app is still being prepared only for an MVP so I know what prioritization should be used when it comes to tradeoffs between scalability vs. speed, for instance, but Claude doesn’t and it sometimes suggests implementations too complex for the current stage in my opinion.

Maybe this is something that can be improved on via claude.md. For instance, I can start documenting when such instances happen and try to prevent them from happening again by giving appropriate directions in the file.