ccosky

I work at a fully remote company, and coding with Claude hits the "pair programming" itch I have. Obviously it's not the same thing (and I do chitchat with coworkers on teams to get real human interaction during the day), but one of my favorite parts of my job is having technical conversations with others, debating the pros and cons of a certain approach. Pre-AI, they were occasional conversations I had with younger devs, but now I have them every day.

I found Claude extremely addicting at first (the dopamine hits were real for me!) but over time I guess I've gotten desensitized.

Anytime I do something as a one-off that I know I'll do in the future, at the end of the session I'll ask Claude to write a new skill based on what it did. For instance, I had to run some queries on Azure to check the logs for certain output and for the frequency of output. Did it once in a session and then had it write the skill for it. Now I can just run the skill whenever I need that data and it pulls it for me.

With the trend going towards devs coordinating multiple agents at once, I am very curious to see how cognitive load increases due to the multitasking. We know multitasking reduces productivity and increases the likelihood of mistakes. Cal Newport talked about how important is to engage in "deep work." We're going in the opposite direction.

Your experience matches mine too. Experienced devs are increasing their output while maintaining quality. I'm personally writing better-quality code than before because it's trival to tell AI to refactor or rename something. I care about good code, but I'm also lazy, so I have my Claude skills set up to have AI do it for me. (Of course, I always keep the human in the loop and review the outputs.)

You said that you're restructuring the project to be LLM friendly, which also makes the app better for humans. I 100% agree with this. Code that is unreadable and unmaintainable for humans is much more difficult for AI to understand. I think companies that practiced or prioritized code hygiene will be ahead of the game when it comes to getting good results with agentic AI.

Simon's comment about mental exhaustion resonated with me. Earlier this year I spent ~3 days generating 11k lines of HTML validation and sanitization code using multiple agents (having them cross-check each other's work because it was security-sensitive). By the end of those days I was completely wiped out. One night I slept 10 hours just from the mental fatigue. I was surprised that it was just so exhausting! I barely wrote any code myself; I was essentially doing code reviews and exercising architectural judgment all day. I've been thinking a lot lately about how AI changes the cognitive load of software development, not just the speed of it.

I've also noticed the pattern amplification effect he mentioned. Agents mirror whatever quality level already exists in the codebase. In clean, readable areas they reinforce good structure. In messy areas they reproduce the mess just as faithfully. If anything, AI seems to make codebase hygiene even more important, not less. It'll be interesting to see how codebase hygiene affects companies' ability to implement AI harnessing and other advanced techniques.

Agreed. On a previous team I was on (no CODEOWNERS there either), we had a Python script in the build process that would look at the git history for the changed files and assign the two most likely people to the pull request automatically. I liked that a lot.

Thank you for bringing that up! CODEOWNERS wouldn't work for us, but it might for someone else having similar struggles.

This isn't "THE" biggest pain point, but one I dealt with today: we have new devs who ask the whole team, "Can someone do my code review?" This leads to the bystander effect: nobody volunteers to do the code review, because we all think someone else will do it. (Alternately: the team leads get asked to do every code review, because they're the leads and know the most.)

So today I wrote a Claude skill that does a git diff against master to determine what files were changed, looks at the git history of those files (most recent commits and who committed the most lines of code), filters out the people who don't work here anymore, and suggests 3 devs who could be good matches for their MR. Hopefully that will get some of the load off the team leads and staunch the "can someone do a code review for me?" requests.

So there's my suggestion to you: something that will let new devs know 1) who is the best person to do their code review and maybe even 2) who the SME for a particular area of the system is.

I definitely wonder if the people going all-in on AI harnessing are working on greenfield projects, because it seems overwhelming to try to get that set up on a brownfield codebase where the patterns aren't consistent and the code quality is mixed.

I have a suite of Claude skills all about craftsmanship. Refactoring, renaming, deconstructing god classes, detecting deleted code, etc. I've never written better, more readable, more maintainable code in my life than I have with Claude. All of that is trivial and hardly takes any time at all to accomplish.

Before moving to agentic AI, I thought I'd miss the craftsmanship aspect. Not at all. I get great satisfaction out of having AI write readable, maintainable code with me in the driver's seat.

I tested out Atlassian Rovo last year. I tried to get it to list all of the Confluence articles I had written in 2025 so I could use that information for my performance review. It found three, regardless of how I queried it. I had actually written over sixty. I tried, but never did found a good use case for it. Too unreliable.

I wouldn't be surprised if eventually hiring becomes heavily dependent on personal referrals. That way you know you're at least dealing with a real person and not a bot, a North Korean trying to infiltrate your company, or someone who isn't even authorized to work in your country.

"AI is actually pretty good at writing tests, especially for common scenarios and edge cases. The tricky part is deciding what to do when tests fail. Sometimes the code is wrong. Other times the spec itself has evolved and the test needs updating."

Yes, I agree, it is good at coming up with lots of scenarios. But after switching to AI-generated unit tests, I discovered that AI writes tests that mirror the code, not validate that the implementation is correct.

So I have AI write the unit test with a particular pattern in the method name:

<methodName>_when<Conditions>_<expectedBehavior>

Then I have a Claude skill that validates that the method under test matches the first part of the method name, that the setup matches the conditions in the middle part, and that the assertions match the expected behavior in the last part. It does find problems with the unit tests this way. I also have it research whether the production code is wrong or whether the test is wrong too - no blindly having AI "fix" things.

For more complex methods, though, I still do manual verification by checking what lines get hit for each test.

I have a Claude Code skill for adding, deleting and improving comments. It does a decent job at detecting when comments are out of date with the code and updating them. It's not perfect, but it's something.