What I Actually Automate with n8n + Groq (And What I Do Not)

I have automated a decent chunk of my own workflow with n8n and Groq — the job-application pipeline is the most-documented one, plus a few smaller ones I have not written up. I have also started, then abandoned, more automations than I have shipped. The abandoned ones taught me more about where automation actually pays off than the successful ones did.

The filter I use now#

Before building an automation, I ask one question: does this task fail loudly or quietly when it goes wrong?

• Fails loudly (a broken build, a form that will not submit, a 404) → automate it. Someone notices immediately if the automation itself breaks, so a bad run gets caught fast and the blast radius is small.
• Fails quietly (a slightly-off summary, a mis-categorized item, a tone that is a little wrong) → be much more careful. Nobody notices for a while, which means a silently-broken automation can run for weeks producing subtly bad output before anyone catches it.

This single distinction has done more to shape what I automate than any general "AI good/AI bad" instinct. It is not about how hard the task is — it is about how expensive an undetected failure is.

What I actually automate#

• Structured data extraction from unstructured text, where I can validate the schema mechanically (a Code node checking required fields exist and have the right type) before the output ever reaches a spreadsheet or downstream step. Wrong data with the right shape still gets caught by a human at the review step, because the workflow surfaces it rather than silently accepting it.
• Repetitive, well-defined lookups and cross-referencing — checking a list of URLs, matching rows against a known set of categories. The "correct answer" is checkable against a ground truth, so a Groq call getting it wrong occasionally is a low-cost failure I catch on review.
• First-draft generation that I always personally edit before it goes anywhere public. Draft blog scaffolds are the clearest example — the pipeline that runs at /lab/ai-content-pipeline never publishes anything automatically; it hands me a draft with [TODO: ...] markers everywhere only my own experience belongs.

What I have deliberately kept manual#

• Anything where the "wrong" output looks plausible and specifically flatters the reader. Performance reviews, testimonial-style copy, anything praising my own work — I do not automate these because a model producing a slightly-too-generous, slightly-fabricated version of the truth is a failure mode that is both likely and hard to catch, exactly the "fails quietly" case above.
• Final publish/send actions. Every automation I run stops one step short of the irreversible action — saving a draft, not publishing a post; writing a row, not sending an email. On this site that gate is structural rather than a habit I have to remember: the admin panel that writes posts to disk is disabled outright in production (NODE_ENV === 'production' turns it off), so nothing can publish itself even if I wanted it to. Posts get written locally, reviewed, then committed like any other change.
• One-off tasks that will not repeat. The setup cost of a reliable n8n workflow is real — building the node, testing the edge cases, handling the rate limits. If a task will not run at least a handful of times, the automation costs more than doing it by hand.

The honest version of "AI automates everything"#

It does not, and pretending otherwise is how you end up with an automation nobody trusts after the first bad run poisons confidence in the whole system. The automations that have actually stuck around in my workflow are the boring, checkable ones — not because the flashy ones do not work, but because I have not yet found a way to make their failure mode loud enough to trust unattended.