TogetherLoop has really come together, and it's more robust than I imagined. Again, I don't know if it's a real business, but I really like using it. One of the last big features to add is tagging. I'm not married to the way any platform does it. My version has to be private, and your post can't leak into other feeds or vice versa unless you've allowed it. I'm particular about the way everything works, so I'm not going to "vibe code" it. This is a log of my interactions with Claude to get to the end.
First off, I had a conversation with the AI about query efficiency. It's gotta perform well, but honestly, SQL is not my strong suit. I had a back and forth about schema design, about five iterations, when we got to a point of agreement. (I'm personifying the machine with "we," but "Claude and I" is too wordy.) We arrived at a place with minimal changes, were essentially a tag is recorded as its own entity, but the tagged person has a post placeholder that points to the original. They get a notification that to approve it, which flips a "IsAccepted" to true. Then we can make sure that the placeholder points to the post in their feed, but a third person only sees the original if they're friends with both people. No dupes. This took about 15 minutes.
Then we talked about the display of the tags, which I want to have fresh profile photos and names. I wasn't thinking about this, but Claude suggested a secondary query to decorate the posts for the feed. Duh, I do this in POP Forums. Signatures and avatars come in a second query, then we decorate the objects. I did this 20 years ago because I sucked at SQL, but it turns out this is a very efficient way to build output, and the performance is excellent. We discussed this for 20 minutes.
Next I asked the machine to propose implementation, and ask questions. After the first round, I told the AI to make the UX out of scope. Engineers already suck at UX, but the machine can be worse. It asked a lot of good questions, mostly about edge cases and other rules. It proposed multiple states for a pending tag, but really it just needs to be yes or no. I shrunk the scope down further, until I was satisfied it was just enough. (Sidebar: This is how I run dev teams, too. The smaller the swing, the larger the success.) This took 10 minutes.
I unleashed it on the proposed implementation (in a branch I could throw away, of course), which took about 14 minutes. It changed 30 files, which is a non-trivial review. My guess is that a lot of organizations with quality problems get into trouble here. Trust-but-verify can be labor intensive, and honestly, I think I should have narrowed scope more.
During my review, I found an instance where it created a class with just one property, something that it does a lot, though I'm not sure why. It seems insistent on wrapping anything sent over the wire as its own type. There were some other questions I had, and Claude had reasonable pro/con arguments for its decisions. I left them as-is. The bigger issue was that the database migration failed. It took several rounds to undo the bad script, which had me concerned, and required extra work to make sure it was OK. This took 40 minutes.
Next I had the AI do the UX for selecting tags, kind of an auto-complete thing as you type in a modal. With tweaks to the look, it took 20 minutes. Next was the cycle to shape the notification and its approve/reject path. While the approval is possible right in the notification, obviously you might want to look at it first. So I had to add the approval mechanism to the post itself. But then it still struggled with the queries and such to appear correctly in the profile feed, and the "my" feed. Along with design preferences, this took at least 60 minutes between Claude's revisions and my evaluation.
At this point, the PR is 900+/41- lines of code, across 38 files. My timing wasn't precise, but it looks like about three hours of work, between me and the robot. Letting it sit, I found that it didn't comma-dileneate the tag list, as I asked. It also didn't sync the approve/reject action buttons between the post itself and the notifications. After 10 minutes of back-and-forth, it had a solution, but it wasn't a good one. It wanted to open up entirely new ways of sending notifications, instead of through the existing message bus and processor. It also put logic in the repository layer instead of the service. These are the kinds of things that disappoint me, when you have a well developed pattern, and it decides to reinvent it. I usually catch this in planning, and it's why I can't just let it loose. This took about 30 minutes total to get right.
So overall, feature idea to implementation in about three and a half hours. How long would it have taken me? Because I'm familiar with the code base, probably five hours. If I wasn't, maybe a little longer. I had to do a lot of redirecting, even though it had a code base with tons of established conventions. Can you imagine what would happen unsupervised? You'd have notifications following a half-dozen paths, for example. And this is with a well revised CLAUDE.md file and a ton of rules.
No comments yet.