I've noticed that you can either move very fast with AI, or very slow. Moving fast, you place a lot of trust in the agent and let it proceed and create something very quickly that works at a surface level and that you don't understand at all. Moving slow you take the time to ask questions and understand every part of the application and learn more about how to code it yourself and make changes as necessary.

One thing I've noticed is, that coding manually is exponentially more stressful than the slow AI approach. I'm not going any faster than I normally would, but the burnout doesn't show up on the fifth day of the week. The hyper-focus is kind of fun but utterly exhausting.

With the fast approach I can create impressive demos and POCs that are nowhere near ready for production. But sometimes that's exactly what I need.

> One thing I've noticed is, that coding manually is exponentially more stressful than the slow AI approach.

I find the exact opposite. Typically the AI will make too many mistakes (even with latest advanced models), they usually aren't major/program breaking mistakes, but they still require fixing if I want to keep the code quality good enough, and make future changes possible without a falling house of cards. In order to describe the correct approach I have to write more English to describe the problem than the amount of code I could write myself. I could maybe see it working by writing rough pseudo code and having the AI translate, but then I loose out on any code analysis or tab completion as I write. It's also just innately frustrating to have to babysit and correct somethings work all the time. This all may be in part caused by the nature of my current work for the last couple years, which has mostly been on library code rather than application code.

I suspect I'd have a very different experience if I was working on CRUD related tasks like making new API endpoints, interfacing with a DB, or writing FE components. Not to make light of those tasks, I enjoy that work, though it is much more repetitive.

I agree with the parts about using AI to ask questions and gain better understanding though. I do that constantly for APIs and languages that I don't have a clear mental model of. It's like an interactive search.

Also agree on POCs, sometimes there are small tools, demos, or prototype features that I don't need to care deeply about.

AI has been a big boost for my data science productivity.

I can have an agent put together a shitty prototype of something just to get a general idea of what I'm looking at, and save probably half a day of work and avoid physically typing potentially hundreds of lines of code. And I can rubber duck with it, and very quickly search through software packages and literature, produce summary reports, dig through my own company source code and wiki and Slack messages to figure out how some specific detail works, etc. These things are important but take my time and energy away from focusing on the hard parts of what I'm supposed to be doing.

My new favorite thing with AI is that my pile of random helper functions is now a thoughtfully-designed library with an extensive test suite for every single thing. I'm not auditing every line of code but I'm reading the plans carefully and I do take a glance at what the agent wrote before I start using it. Most of the time it's not perfect or it's ugly in some way I wouldn't have done, but it's good enough to do research with, and it's way better than what I could have put together by hand, and in much less time. I trust my own research results more because I can put together these kinds of helper libraries much faster, and if I have to make changes I have a big test suite to catch me when I make a mistake.

The only hard part is managing the context switching where instead of putting my work on pause to go write a helper routine, I now have to account for periodically interrupting my work in order to keep an eye on what the agent is doing. For now my approach has been to just ignore it for a while and then take a break to cycle through AI work sessions/chats.

I just spent multiple evenings talking through a small data model. With the massive number of misses the model had, I can’t imagine how bad it would have been if I had let it yolo the first design of its choice, to build on.

The requirements didn’t really change, opus just couldn’t see all the real world potential issues with its various suggestions.

But it was helpful for me to talk it out. So I guess it fell in the (very) slow category of productive use.

This, I'm working on a game engine as a hobby project. I can do one "big" feature over a weekend, most of it including designing and manual testing that it's working as expected, but then it takes me 2 weekends to break up the changes into smaller commits using jj, which also gives me the chance to review and understand the code myself. So it's a weird mix of fast and slow, but I think I've grown to prefer reviewing over writing so it works for a hobby project.

I love that you can mix these approaches. It lets me very quickly get a working prototype and then I can focus on optimizing the areas I care about / are having issues.

I think almost anything you can build autonomously with a fully independent AI agent, you can build far better with the slow AI approach. It is a good trade off between the super fast agentic approach and the full manual approach, and leaves you with a codebase you can still reason about and find ways to improve.

Also, once you build something with slow AI, it becomes more practical to actually rewrite it by hand quickly and refactor it in a way that makes more sense for humans. It’s “humanwashing” the code.