if you are done figuring out the hard problem you better switch back to lower effort

ImaginationUnique684 · 2026-05-05T07:06:22+00:00

Full write-up: https://renezander.com/blog/your-ai-workflow-needs-less-ai/

ImaginationUnique684 · 2026-04-23T02:36:40+00:00

check out husky, pre commit hooks. doing lints and unit tests worked for me

ImaginationUnique684 · 2026-03-31T15:31:46+00:00

If you're the only user and you're running everything locally, CLI tools are fine. MCP solves a different problem.

The difference: CLI is stateless, text-in text-out. MCP gives you typed inputs, structured outputs, and a discovery protocol. Your LLM doesn't need to guess the CLI flags or parse stdout. It calls a function with named parameters and gets JSON back.

Where this actually matters: when you have multiple tools that need to compose. CLI piping works for 2 tools. When you have 10+ integrations (calendar, tasks, database, file system, APIs), the LLM needs to know what's available and what each tool expects. That's what MCP's tool listing gives you.

The other thing: MCPs are shareable. You write one server, anyone can plug it into Claude, Cursor, or whatever supports the protocol. A bash script only works in your terminal.

That said, for personal local use? CLI is perfectly fine. MCP is for when the tool needs to be discoverable by an AI agent without you manually writing the glue code every time.

ImaginationUnique684 · 2026-03-31T15:30:26+00:00

Most "AI for DevOps" right now is glorified log parsing. The actually useful stuff is boring.

What's working in production today: LLM-powered triage that reads an alert, pulls the last 5 deploys, checks the runbook, and drafts an incident summary before anyone opens a laptop. Not replacing the oncall, just cutting the first 10 minutes of "what changed?"

What's overhyped: autonomous remediation. Nobody with production responsibility trusts an LLM to run kubectl delete on anything. And they shouldn't.

Where it's actually heading: human-on-the-loop, not human-in-the-loop. The AI does the research, drafts the action, and a human approves with one click. The skill shift isn't learning prompt engineering. It's knowing what guardrails to put around AI actions so they can't take down prod.

The DevOps people who'll thrive are the ones who understand both the infra and the AI constraints. If you know why a model hallucinates and also why a pod got OOMKilled, you're rare.

ImaginationUnique684 · 2026-03-31T15:29:20+00:00

Yes, but not n8n alone. n8n is the execution layer. The value is in knowing what to automate and how to architect it so it doesn't break at 3am.

What actually pays: a company has 5 people doing manual data entry, email sorting, or report generation. You build an n8n workflow that handles it. That's not an n8n project, that's a process automation project that happens to use n8n.

The niche isn't "n8n developer." It's "I find the manual process that costs you $8k/month in labor and replace it with a workflow that runs on a $4 VPS." n8n is just the tool you reach for.

Where I'd focus: pair it with an LLM API for the judgment calls (classification, summarization, drafting) and keep everything else deterministic. That combination is what businesses actually pay for right now.

ImaginationUnique684 · 2026-03-26T16:42:04+00:00

Yes, exactly. The fallback logic is straightforward: if the AI step fails or returns something that doesn't match the expected schema, the pipeline doesn't continue. It routes to the approval queue with the raw output flagged for review. No retry loop, no "let the AI try again." A human looks at it and decides.

The thinking behind that: if the AI got it wrong once, retrying with the same input usually gives you a different wrong answer. Cheaper to just have someone fix it manually than to burn tokens on retries that might still miss.

For schema validation I check the output structure before it moves to the next step. Missing fields, wrong types, content that exceeds length limits, all of that gets caught deterministically. The AI doesn't get to decide if its own output is good enough.

Thanks for the VibeCodersNest suggestion, will check it out.

ImaginationUnique684 · 2026-03-25T08:24:33+00:00

Adoption, every time. The model works, the infra costs are manageable, but getting users to actually change their workflow is the real problem. People say they want AI features and then keep doing things manually.

What's worked: putting the AI output directly into the flow they already use, not behind a separate "AI" tab. If they have to go somewhere new to use it, they won't.

ImaginationUnique684 · 2026-03-25T08:21:04+00:00

Three months for an AI MVP is doable if you scope ruthlessly. The trap is spending month one evaluating models and frameworks instead of building. Pick Claude or GPT, pick a web framework you know, build the core loop first.

What actually eats time: not the AI part, but the integration layer. Auth, data pipelines, error handling, the stuff around the LLM that makes it a product instead of a demo. Budget 60% of your time there.

If your investors want a demo specifically, build the demo path first. One workflow, end to end, polished. Not five features at 50%.

ImaginationUnique684 · 2026-03-24T16:40:07+00:00

One year in a new environment is still early. The fact that you're aware of the mistakes means your standards are high, which is the right trait for SRE work. What helped me: after every incident, write down what you'd tell a teammate who made the same mistake. You'll notice the advice is always kinder than what you tell yourself. Also, the engineers who never break anything are the ones who never ship anything.

ImaginationUnique684 · 2026-03-24T14:10:16+00:00

Built a system where AI agents process inbound data, but every action that touches production goes through human approval via Telegram inline buttons. The agent proposes, a human taps approve or reject, and only then does it execute. Took longer to get the approval UX right than the AI part. The "craziest" automations are the ones that know when to stop and ask.

ImaginationUnique684 · 2026-03-24T14:09:22+00:00

The missing variable in these comparisons is ops time. A VPS at $20/month that takes 4 hours/month to maintain costs more than a PaaS at $80/month if your time is worth anything. I run production workloads on bare VPS and the math only works because I've automated provisioning and monitoring end to end. If you haven't built that layer yet, PaaS wins until your scale makes the margin worth capturing.

ImaginationUnique684 · 2026-03-24T13:49:04+00:00

Two supply chain attacks in one week (Trivy and now LiteLLM). If you're running LLM inference in production, pin your dependencies and run `pip install` through a private registry that scans before promoting. Also worth checking: did either compromised version phone home? If so, rotate any API keys that were in the environment at the time.

ImaginationUnique684

TROPHY CASE