What I've observed is that by prompting for longer I get to keep my brain focused on the architectural ideas (networking, protocols, data structures, etc) rather than worrying about the most performant/elegant implementations.

I always enjoyed writing code and I am very good at writing very performant and elegant code, but it would sometimes come at the detriment of focusing on the code and not the design.

because my manager will ping me and say "anon you aren't prompting enough" like they never heard of Goodhart's law before.

Companies are tracking token usage across the board. You are in trouble for too less or too many. Unfortunately the token usage is the only measurable thing for most folks so everyone is playing the game, otherwise how else would Anthropic and OpenAI make the money

In my experience?

It used to be that one person had one to three codebases they knew intensely at my company. If you needed a bug in codebase X fixed, person Y was the one to do it and if they aren't available, person Z can do it, just not as quickly.

Now every person on my team has to handle tickets for every single codebase. There are about two dozen different large codebases involved here.

It's a ludicrous antipattern because person Y still needs to review the PR that person A generated for codebase X, and it will take them about as much time to wrangle the 2000 line PR (oh boy do LLMs love their mocks for unit tests) as it would have been for them to do the 50 line code change.

On top of that, it has "allowed" us to add feature after feature onto codebases not designed for them without refactoring. Is it good that this Flask API went from a purpose built service that interacted with the data analytics for product A stored in database X, and now our sales guys can sell product B, C, and D stored in database X? Uh, I'm sure it's great for them. Oh, and now it all can be stored in database X, Y, or Z depending on what the customer wants or what sales promised them. Great. Now I'm looking at a Flask app.py that's 12,000 lines of repeated code.

It has allowed poor designs to still produce working code. For a while. We seem to be getting a lot of bugs lately that look really bad to customers because it's for really simple shit. And I can't help but notice that happening to all the various products and sites I use too...

Writing code directly takes longer to warm up. Usually, I'd keep tens of thousands of lines in my head. In the past, I spent a lot of time designing error propagation and execution contexts. (Talented people might figure it out right away, but unfortunately I don't have that kind of talent.) So I'd have to think about things like Result<T> and how far to propagate errors—and worry about whether my approach would conflict with the existing codebase.

But these days, AI just generates code following the existing patterns of the codebase. In the past, staring at a blank screen meant going through a checklist of things to design—starting from policies and writing everything down step by step. Now, I just ask AI and it gives me a template—which is great. Then if the AI makes a mistake, I fix it manually.

Of course, I still hand-code sometimes—but only in the areas I enjoy. Most of the time, I use AI coding. Both are fun, and they complement each other in interesting ways. Doing both together is actually enjoyable.