[techblueberry]

I’m in this exercise right now, and I’m thinking about, how do I stay in the drivers seat. I think it’s a version of, bionics not robots.

Im trying to go back in time to when AI was more autocomplete than agent and write my code with assistance. Find the file, find where the code goes autocomplete the fix. Rather than one shot multi file changes do one at a time.

The bosses probably don’t want people spending 4 hours figuring out why upgrading a package conflicted with another package in weird ways or changed the API or other obscure things, so like, give troubleshooting 10 minutes, try to grok the code context, then prompt for a fix. Or prompt “show me where I need to look to fix this” and fix it yourself.

The question to really ask is what time scales are we talking about. Sitting down to do a task getting context and prompting code probably takes like what an hour, maybe 2 if you have to review it or fix something? If you add another hour to that, and really understand it, I think you’re not hampering your productivity all that much if at all in the aggregate.

The other thing I’ve always done is let myself get nerdsniped easily. Maybe multiple times a day if someone posts an error in chat I’ll give myself 5-10 minutes to look at logs/graphs/google. Keeps the job interesting but also I think keeps my mind flexible and into the details across a broad swath of tech.

[KolibriFly]

That's probably one of the most sustainable approaches. Queries like show me where to look for the problem often turn out to be more useful than just fix it for me, because they leave the most valuable part of the work to the engineer