[foxyv]

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.

[gwerbin]

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.

[foxyv]

I agree, the speed at which the agents work is a problem. It creates an interrupt workflow instead of a flow workflow. This works for some people but I notice that I don't do well that way. Typically I'll have an agent working on a task while I use a separate one in Ask mode just kind of satisfying my curiosity while I wait. This keeps me engaged but makes the interrupts less jarring.

[notnullorvoid]

> 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.

[foxyv]

If I'm working on a non-coercive environment (No deadlines, requirements, etc..) hand coding in hyper-focus mode is extremely zen. But working on a deadline it really hurts. My brain can't help but ratchet up the stress.

[dd8601fn]

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.

[gwerbin]

The rubber ducking potential is the first thing that got me interested in AI as a useful tool.

You do have to be very careful of when the AI might be confidently wrong, or leading you down some kind of weird narrow path.

When searching the web to gather info on a topic, all have a tendency to find 2-4 search results and fixate on those as if they represented the entire scope of the topic. No surprise about the fixation because that's kind of how LLMs work (X, Y, and Z are in context -> more tokens about X, Y, and Z). But you have to be aware of it, and I often have to prompt it to do another search and keep turning up more options.

[foxyv]

I've found that my requirements and acceptance criteria are much less clear than I think they are. AI reveals when you are being too vague, almost instantly sometimes.

[dd8601fn]

They always are. When you think you’ve got it all… ya don’t.

Unfortunately this recent experience wasn’t that as much as it producing rapid-fire misses when it did have the constraints. It regularly just violated X to kinda-solve Y. Or made up a solution to both that solves neither. And this wasn’t some wildly complicated scenario.

Sure made me solidify some opinions (we ended up pretty close to where I had started without it), but woo-boy… it was a painful journey.

[foxyv]

Yeah, sometimes you just have to throw out the current solution and start over/rollback. AI will go down some weird rabbit holes to solve a problem with the wrong requirements. Sometimes I feel like I'm just coding in English instead of Python or TypeScript.

[deadbabe]

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.

[vadansky]

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.

[CharlesW]

> …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.

I just tell Claude Claude code, "commit all, grouping logically" after a tranche of work.

[maccard]

Genuine question a why are you using AI for a hobby project like that? It seems like the worst of both worlds.

[solarkraft]

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.