Post

sent this to the team today everything great comes from being able to delay gratification for as long as possible and it feels like we're collectively losing our ability to do that

26 reposts171 likes

I think working on a prototype necessarily is product thinking... So I don't understand this too much. Other than that it's agreeable points.

I find myself doing something similar just on a solo-dev level: Let the models write the code/fix, and then convince myself that i can understand the essence by having it give me a summary. Almost always backfires, but it's so convenient in the moment

The summary is the trap. It tells you what happened, not whether you'd catch a bug three months from now. Real understanding comes from writing it yourself at least once. AI is good for getting unstuck, bad for learning the shape of a problem.

I have started clearing context and having Opus take a fresh look at it, and that's paid dividends in terms of reducing lines of code while retaining functionality less code, more comments

The point about using them "for every minor change" is something I was discussing with a team-mate just today. There's definitely a tendency to let the LLM take over responsibility for "owning" the code. Initially it's great productivity boost, adding features faster than you could but by the end

you're twiddling your thumbs for 5 minutes waiting for it to figure out how to change the font size on a label or something equally trivial that you could do yourself in 30 seconds if you'd written it yourself and understood it well. The temptation is to keep deferring the work needed to gain

i force myself to review every LLM diff line by line, same as a PR from a junior dev. the moment you rubber-stamp changes you stop understanding the codebase. slower upfront but you never end up staring at code you can't navigate without the LLM.

Good message to the team! I am not sure it's about delayed gratification so much as avoiding hard thinking. And understanding that shipping half baked features is going to slow you down in the long run. Same with hacky code. Both are symptoms of lacking the clear end goal picture

Not implying here you lack business vision or anything. Talking about end goal of how your code should be after you make changes. When working seriously, I ship about 3x as fast as I would without AI. When prototyping its 10x. That difference is the clean up of code and product thinking.

2 could not be more true. Having the default behavior be “let me work around the problem instead of trying to fix it” is great for marketing because you can make it seem like LLMs are capable of solving much more complex problems than they are.