The gist of it
Many people said it, and I did too, but without really feeling it. You. still. need. to. think. for. yourself.
The longer form
I take it as a benefit from the current generation of AI tooling, how working with so-called agentic AI makes you (eventually) take a step back and ask yourself: do I need to go fast or slow?
An example of being fast would be:
I want to explore this idea, cook me a quick proof of concept and take so and so shortcuts.
This is basically delegating most of the minute questions and implementation details to somebody (or something in this case) else. The working artifact gets produces in mere minutes. The feedback loop is dramatically shortened and prompters can do their job (i.e. iterate) faster. This is great, we are going to a higher level and ignoring details we don't need to pay attention to (at this point).
On the other hand, being slow in this world means, you know, using an engineering mindset: think first, clarify, think some more, repeat, then maybe start writing something down. I am more and more convinced that slowness would be the antithesis of the slop-engineer approach. You know the one, where the prompter anthropomorphises their coding assistant and merely poke them to "try harder" while riding the dopamine rush. When both parties are absolutely right, there is no more place for nuance and critique.
I appreciate how slow I've been to put these thoughts in words, and I find it derisively funny that I've been over correcting so hard in the last six months. Oscillating between externalising my thinking (laziness to understand and debug complex state) and "I must own the solution space end-to-end to prove my craftsmanship".
Unsurprisingly, when I take the time to think, I don't like any of either extremes. We still need to apply our skills at every step: requirements, acceptance criteria, architecture, integration tests, … All the usual suspects you deem necessary for your problem (I said you).
I have recently read The Uselessness of "Fast" and "Slow" in Programming. It is more approachable than the classic What Every Programmer Should Know About Memory and adds some craftsmanship pep talk I vigorously nod to. I read it as a wake-up call to the engineering mindset: we have a challenging environment, own it, master it, be proud of yourself. Stick to the middleground, know your tools, don't give in to the slop.