Productive struggle vs AI slop
Productive struggle vs AI slop is quite the topic these days. On one hand we have to do the hard, boring, frustrating work. Do it long enough to learn the whole lot, reshape skills, gain confidence. Opposition of escaping to quick fixes with or without AI.
When used in conjuction with AI, we should still keep the struggle but without the pointless friction. That way more energy and cognitive power goes into craft and progress, long-term growth… instead of refactoring some legacy code and working over things that should not be that hard in the first place.
What is productive struggle?
Productive struggle is the time and space where a task feels, at least a bit, overwhealming. We manage uncertainty, fight mistakes, adjust ideas. When one does not success, one must try and try again. Research calls it “desirable difficulties”, while slowing down short-term performance improve long-term retention and understanding. Such base work works wonders for building metacognition. We become more aware of what know and don`t know.
This is the reason why ram prices are so high.
What is AI slop ?
In common urban dictionairy AI slop we can read that is is just the simple, fast, not well thought through usage of generative LLMs to create ‘stuff’. Is it code, multimedia or text it is ‘same old, same old’. Withg hallucinations and all that jazz. Be aware ! You camm summrize it as prompt a solution, run test and just commit for someone else to patch it up for edge cases. We need to remember that it is a tool.
Sadly most of us are excpected to perform a lot faster that it help in reality.
AI vs productive struggle
Easy usage of AI, fast answers, quick solution are encouraging “answer consumption”. LLMs should remove tiresome tasks and boilerplate work. Quick fixes can erode our tolerance for friction that real learning requires. We should us it for prompting reflection, rather than instantly removing every obstacle. Our brain just doesnt learn cause it doesnt care, the job is done. “It works”. We forget to free out cognitive space for other things.
Structured struggle with AI agents
We could use tools like Tabnine, Copilot, Claude or other Cursor to create a bit of friction deliberately. Learn about alternatives, design patterns, read explanation of the design, test edge cases. It would require us to reason before accepting outputs. We of course are always doing extensive code review aren`t we 🙂 One could create and agent for a “Review” mode to learn and review from the changes.
I would recommend to remember and try to code “manually” without too much over-reliance on such tools. Just to not get out of practice.
AI should save us time for high-value struggle like design work, deep thought, ADR decisions and others. Studies on productive struggle show that persisting with nontrivial tasks builds self-efficacy. Over time we learn a great deal about the whole broad scope and build upon that instead delegating the hard parts to tools.
Can You even embrace 1–2 → 5+ story points
Any manager would go bonkers for such statement. Productive struggle vs AI slop begins where we stumble upon a hidden complexity. Extra small estimation like 1–2 moves to 5 or more story points. Instead of thinking “failure” and “bad performance” or other “laziness”, there after frustrating the developer with constant questions on what and how… teams can treat it as a signal that they are uncovering real complexity, improving domain understanding and investing in future velocity.
Be vocal and normalize prolonged tasks. Agree, when work expands, complexity, architecture issues, unclear requirements, design debt story legitimately grows. One could split stories, add spikes or increasing estimates mid-sprint. It will be much more then just “get it done”.
Summary
Productive struggle vs AI slop is simple as always. Do the hard work. Got spare time ? Learn and figure out stuff even better, maybe optimize, learn a bit more. Prepare difference scenarios and grow.
- For2–3 sprints when a story grows unexpectedly find a bit of time and discuss this either on daily or retro.
- Try to mark tasks that are a bit of uncertain are and acknowledge that they could grow.
- Use AI as as assistant, not a solver.
If You use a nail gun its ok, it helps a lot but just remember that You should still be able to use a regular hammer to punch on some nails.
When a simple story quietly becomes “too big,” the default assumption should be that this is an opportunity to grow team capability, not just a risk to be managed or performance drop to whine about.
Further reading
