When Not to Use AI: A Sarcastic Poem Worth Reading

Knowing when not to use AI is turning into a harder skill than knowing how to prompt one. That is the thought I could not shake after reading "Please Use AI" by Shawn Smucker, a prose poem on his Substack The Courage to Live It. It is free to read and takes about two minutes.

I build AI tools for a living. I ship them on this site. And I think the poem is right.

---

🪞 The sarcasm is the whole argument

Smucker writes the piece as a set of cheerful instructions. Use AI for your meal plan. Use it to plan the trip with people you love. Use it for the wedding speech, the creative work, the personal writing. The hero image is a meme that says to be sure to use AI when making your next, I don't know, meal plan, for example.

Every instruction is a trap. The point lands in the negative space: if a machine can do this for you, ask yourself why you wanted to do it in the first place. His phrasing about what you give up is the part I keep returning to.

"the longing for something that could always be a bit better / or the way that anything / worth doing feels a bit clumsy and painful" — Shawn Smucker, Please Use AI

That is not an anti-technology position. It is a claim about which tasks carry their value in the doing rather than in the output. The poem ends on him holding his sleeping daughter, which is about as far from a generated artifact as you can get.

---

🛠️ The test I actually apply: output or reps?

Most "should I use AI for this" debates go badly because both sides argue about capability. Can it write the function? Usually. Can it write the speech? Technically. Wrong question.

The question I use is one line:

Key takeaway: If the artifact is the point, delegate it. If the practice that produces the artifact is the point, do it yourself, even badly.

A migration script is an artifact. Nobody grows as an engineer by hand-typing the 400th ALTER TABLE. Your first real debugging session on a race condition is not an artifact. The confusion, the wrong hypotheses, the three hours of instrumentation, that is the deliverable, and the fixed bug is a side effect.

Same for writing. A release note is an artifact. The email where you tell a client you missed a deadline is reps.

---

📊 A delegation table I would hand a junior dev

Here is how I actually split it on a working day. No scores, no framework, just the split that has held up for me.

Task	Hand to a model?	Why
Boilerplate CRUD, config files, regex	Yes	Pure artifact, zero learning left in it
Test fixtures and seed data	Yes	Volume work, easy to verify
Translating error messages, docs lookup	Yes	Faster than search, low downside if wrong
First draft of a README	Yes, then rewrite	Beats a blank page
Debugging unfamiliar code	No	This is how you learn the codebase
Designing the data model	No	The tradeoffs are the job
Your first three projects, ever	No	You are buying skill, not output
A message to a person who matters	No	The clumsiness is the signal
Your CV's "about me" paragraph	No	Interviewers can tell, and they ask follow-ups

Grammar cleanup on your own words is the honest middle ground. Write the thing, then run it through a checker like our AI grammar checker so the sentences are yours and the commas are correct. That order matters. Reverse it and you get a generated paragraph you are now defending in an interview.

---

💸 The skill debt nobody puts on the invoice

Technical debt shows up in the codebase. Skill debt shows up in you, and it is quieter.

The pattern I keep seeing in juniors who lean on models from day one:

1. They can produce working code fast, which looks great for about four months.
2. They cannot explain why the code works, so code review turns into a stalemate.
3. When the model is wrong, they have no independent signal that it is wrong.
4. They stop being able to estimate, because estimation is pattern-matching on pain you personally felt.

Point 3 is the expensive one. A model that is confidently wrong costs you nothing if you can smell it, and costs you a week if you cannot. That smell is built entirely from the clumsy, painful reps Smucker is describing.

I am not arguing you should type everything by hand. I am arguing that the reps are a purchase, and if you skip the purchase you do not own the thing.

---

🇱🇰 Why the stakes are different from here

If you are building from Sri Lanka, you are competing in a global market on skill, not on proximity. Nobody in Berlin or Singapore is hiring you because you are nearby. They hire you because your judgement is good.

Three things follow:

• Judgement is the export. Code generation is now commodity everywhere, at roughly the same price everywhere. What is not commodity is knowing which of four plausible designs will survive contact with real users. That is not something you can prompt for.
• Free tiers are for volume, not for thinking. The free tiers are genuinely useful when you are learning on a small budget. Use them for the boilerplate so you have more hours for the hard part, not to skip the hard part.
• A generated portfolio is a liability. Local hiring here still runs heavily on referral plus a real conversation. Anything you cannot defend out loud in that conversation is worse than not having it.

If cost is the reason you are deciding what to automate, be exact about it. Our AI token counter and the cost calculators under induwara.lk/tools will tell you what a workload actually costs before you build around it.

---

💡 What this means for you

A poem about meal planning is not usually where you go for engineering advice, and yet the sorting rule in it is cleaner than most of what I read about AI adoption this year.

• Sort your tasks by whether the output or the practice is the point.
• Delegate the output work without guilt. That is what these tools are good at.
• Keep the practice work, especially early in your career, especially when it is uncomfortable.
• Write first, then clean up with a tool. Never the reverse for anything with your name on it.
• When something feels clumsy and painful, check whether that is the signal rather than the problem.

Go read the original. It is short, it is free, and it will take less time than the next prompt you were about to write.