If you want to learn about building voice AI solutions, consider subscribing to my YouTube channel. It'll mostly be technical content (like my latest video on PBX).

The reason is straightforward: most people can only meaningfully engage with what they can understand. So when you post something they don’t understand, they can’t agree or disagree or ask questions. Platforms amplify this further because algorithms optimize for engagement, not depth. That’s why there is lot more user engagement for generic AI related news (new model drops, funding rounds, CEO drama, “AI will replace X”) or generic posts (“nobody is coming to save you”) but hardly any for content that goes deep into AI development. It also reveal real knowledge gap. You are still not too behind if you are serious about learning AI beyond generic stuff. Most of your competition is still AI wrappers and not developers. The people who can meaningfully discuss training dynamics, evaluation reliability, systems constraints, or failure modes remain a small minority. If you’re serious, the window is still open but not infinite. Focus on building things that force you to confront real constraints (evaluation, failure modes, cost, integration with existing systems) rather than consuming more generic news or tutorials.

You can add Gibberish detection to your system prompt so that callers don't waste your tokens. My agent tolerates one instance of gibberish and gives a chance to correct it. After two chances, it politely ends the call. You can train the agent to do whatever you like. For example, you can escalate the matter to HR for AI abuse. Similar functionality can also be used to stop abuse of interviews carried out by AI. **Gibberish:** the words are clear English, but the utterance makes no sense as a whole, or the answer doesn't fit the question. Example: "My name is what do you want for breakfast but night is not good and my email has passed away." **Not gibberish:** accents, filler, rambling, self-corrections, off-topic but sensible questions, or a single misheard word (→ Unclear audio rule). Armed with this knowledge, ask Claude to help you create a gibberish detection prompt.

AI-generated code often introduces hard-to-detect security vulnerabilities. n8n’s node layer partly absorbs this risk because authentication, credentials and API calls are handled by pre-built nodes rather than by code you have to review. When you build workflows in code on Vercel or Trigger.dev without being an experienced developer, you trade that protection for flexibility and speed. Your production workflows are more likely to contain security flaws you can’t spot and failures you can’t easily fix. Most people realise this too late.

Try → discomfort → “I just can’t / I need it” → full return to the old baseline → temporary willpower attempt → repeat. My coffee progression over the years: Latte/cappuccino with added sugar > Latte/cappuccino > Regular coffee + Milk + Sugar > Regular coffee + Milk > Regular coffee. All of this was just to get milk and sugar out of my coffee. Gradual reduction works better than abrupt change. This is a general principle of sensory and habit change, not just coffee. People who don't understand this principle often relapse and get stuck in the cycle of : Try → discomfort → “I just can’t / I need it” → full return to the old baseline → temporary willpower attempt → repeat. The goal is not to become someone with infinite willpower. It is to reach a state where the desired behaviour no longer requires much willpower at all.

You should not be relying on Vercel or Trigger.dev for voice AI. Trigger.dev doesn’t receive requests directly. So your webhook has to live somewhere else, like a Vercel or Next.js route. Here’s what a single mid-call lookup looks like when you build it that way. > Caller asks “Can I get a slot on Tuesday?” > Retell turns speech into text. The LLM decides it needs the calendar. > Retell sends a request to the webhook on your server (a Vercel or Next.js route you build and host). > Your server asks Trigger.dev to run the “check availability” task, then waits. > Trigger.dev queues the task and runs it on a worker, starting one if needed. > The task calls the calendar or CRM API. > The result goes back to Trigger.dev. > Back to your server. > Back to Retell. > The LLM writes the reply. Retell speaks it: “Yes, 10am Tuesday is free.” > By now the caller has gone to bed. (OK, that’s a joke. But you get my point.) What are you running here? Retell, your own server, Trigger.dev, and the calendar or CRM. Four systems in the chain. You built and maintain two of them. Where does it hurt? Every arrow adds delay while the caller sits in silence. And when it breaks, the cause could be your server, the Trigger.dev queue, the task code or the CRM. You check each one separately. Same thing in n8n: Retell → n8n webhook → calendar/CRM node → Respond to Webhook → Retell One system. Webhook and automation in the same place. Why not just use Vercel on its own? Here’s the thing. Vercel is best for workflows that finish quickly. Once a workflow needs to run long, wait, or retry reliably, you need a tool like Trigger.dev. You won’t need Trigger.dev for every voice agent. But you will for some. Host your webhooks in code, and sooner or later you’re depending on a second platform. And once Vercel hands a job to Trigger.dev mid-call, that handoff adds latency. With n8n, there’s no handoff. Not to mention, if you can’t read and debug code, you shouldn’t be using Vercel or Trigger.dev at all. That’s most people. So in that context, when i say don't rely on Vercel or Trigger.dev for voice AI instead use n8n, it should make sense. Remember: >> Vercel alone doesn’t cover every workflow, so you end up depending on a second platform. >> The handoff adds latency mid-call, and n8n has no handoff. >> If you can’t read and debug code, neither is safe to rely on, and that’s most people.

You’ve been sold a lie about Claude Code replacing n8n. Many people jump to Claude Code to skip n8n’s steep learning curve. However, the learning curve doesn’t disappear. It actually becomes steeper with increased maintenance overhead for most people. With n8n, most of the learning happens up front, while you build. With Claude Code, the build feels easy at first. The learning is deferred until something breaks in production. And it will. At that point, you’re learning automation fundamentals, git, logs, deploys and TypeScript under pressure and that too on code you didn’t write and can’t debug. Not to mention, AI-generated code often introduces hard-to-detect security vulnerabilities that n8n’s node layer partly absorbs. You end up trading fast builds for security issues and maintenance overhead. Building happens once. Maintenance runs forever as long as the automation lives: API changes, auth expiry, rate limits, schema drift, new edge cases in the data. Each of those means reading unfamiliar code, judging an agent’s proposed fix, redeploying, and verifying. The end state is often: >> The automations get switched off. >> You end up hiring a developer to untangle or rebuild the spaghetti code, often costing more than doing it correctly at the start. >> You retreat to n8n where you can see what’s happening. Understand what you are signing up for.

My career advice for 2027: Audit your career. A native worker often thinks, “This is how things are done here. That’s just the way it is. That's my niche.” An outsider asks, “Why are we doing it this way, or why are we even doing this? What's the point when the market has moved on"? You respond to the labour market that exists, not the one you prefer. If your existing skills are no longer serving you, let them go. It's not a sunk cost. They served their purpose, and your market has moved on. When a skill no longer clears the market at the rate you need (whether because of automation, changed buyer preferences, or simply oversupply), the rational move is usually to stop treating it as the centre of your offering. Continuing to refine it, market it, or organise your career around it simply because you already invested years/decades is how people end up becoming obsolete. Develop new skills for the new market. Growth and innovation require stepping outside the comfort of majority thinking. The outsider mindset allows you to see problems and opportunities more clearly and earlier than your competition. Your existing career may have become your comfort zone, and it could soon become your death zone if you don't adapt fast. Audit your current skill stack against actual demand signals (job postings, contractor rates, internal project success, customer willingness to pay) rather than against what felt valuable 2 or 3 years ago. Don’t play by the same rules as everyone else. Question them. Redefine them. Create your own path. That mindset can open doors, sometimes even to working with world-class clients like MIT, from an office halfway across the world.

People in tech role who are currently being replaced by AI today are going to be the same people who replace others with AI once they build there career in AI. This answers your question "why you are being a part of the system which results in mass layoff for others". There is no right or wrong here. Its just survival at this point. You respond to the labor market that exists, not the one you prefer. If you don't do it, someone else will. Survival of the fittest.

Pick your role now, as it will get far worse in 2027. Most companies of the future will revolve around only two core roles: Agent Developers and Agent Supervisors. Over time, every department will likely operate within this structure. Agent Supervisors - senior subject-matter experts responsible for overseeing the performance, reliability, and strategic alignment of AI agents. Agent Developers - build, maintain, and optimise these agents, translating business logic and domain knowledge into operational code, APIs, and workflows.

Learn to manually perform a task first and do it dozen of times before thinking of automating it. So when anything breaks during automation (and it will), you know exactly what broke and how to fix it. Without manual reps, your automation workflow is unlikely to survive production load.

AI is not a technology. It’s infrastructure. You can’t opt out of infrastructure. It's deeply embedded in everything you use. Using failed adoption stories and memes as a crutch to highlight AI's current shortcomings won't halt or reverse AI adoption or change decision-makers' minds. “Billions” of dollars have already been invested. Your memes, complaint posts, and boycotts stand no chance. Adapt or see yourself becoming obsolete.

Keep all your workflow automation in n8n and forget about Retell Workflows. Retell Workflows lets your agent run a few actions at the start or end of a call without an external tool like n8n. For example, before the call, it can fetch the caller’s lead, booking or account details. After the call, it can update your CRM, create a ticket, post to Slack or send an SMS. It has no other triggers. n8n goes much further. It can be triggered by almost anything: a schedule, a webhook, a form submission, a new CRM record, an incoming email or SMS, or a Retell call. It has hundreds of ready-made nodes with authentication handled for you. It can branch, map and reshape one payload for five systems, with retries and error paths on each branch. It gives you error workflows and replay. And the same workflow can serve voice, chat, forms and email. Retell gives you eight native integrations and a JavaScript sandbox. In short, Retell Workflows is nowhere near a substitute for n8n. So if you still need n8n, why split your logic across Retell and n8n? Splitting it means no single place shows how the system works. One side gets updated, and the other doesn’t. Both may write to your CRM. And when something fails, you have to debug two systems to find out which one did it. Keep all your workflow automation in n8n and forget about Retell Workflows.

Review of Retell Memory. Should you be using it? Retell AI recently introduced a new feature called ‘Memory’. It lets your voice agent remember a caller between conversations, so returning callers can be identified and previous context can be retrieved. It all sounds good in theory, but it is not something you should be using or relying upon. I will put it in the same category as pointless features like Retell Workflow. Here is what happens when you use and rely on Retell Memory: #1 When memory lives inside Retell, it is siloed. There is no built-in sync to your CRM, so your SMS tools, email and staff never see it unless you build the export yourself. Scenario: A caller tells the voice agent she has a dog, and that the technician should use the side gate. The technician arrives, checks the job in your field-service app, sees no note, and walks straight into the back garden through the front. Gets brutally attacked by the dog and ends up in hospital. Your client ends up paying the bill. It's an extreme example, but you get the point: what happens when you don't share context across your tech stack. #2 Retell Memory only knows what happened on Retell calls. If a technician closes the job or the invoice gets paid in your CRM, memory will not know. It can confidently carry forward a stale open item. Scenario: Sarah’s furnace was repaired on Monday, and the job was closed in the CRM. On Wednesday, she calls about a new thermostat. The agent opens with “Are you still waiting on that furnace repair?” #3 Identity rests on the phone number alone. On a shared household line or a reassigned number, the agent gets the wrong person and the wrong history. Scenario: Harry booked an AC service from the home landline. Diana calls from the same number to cancel a different job. The agent greets her as Harry and asks about his AC appointment. #4 One prompt covers the whole workspace. This is the most deadly downside. You cannot tailor what a sales agent remembers versus a support agent without splitting into separate workspaces. Scenario: Your sales agent needs to remember budget, timeline, and the competitor quote the lead mentioned. Your support agent needs model numbers, warranty dates and the last fault reported. Both write to the same 2,000-character memory under one prompt. Tune the prompt for sales, and the support agent forgets the fault history. Tune it for support, and the sales agent forgets the budget. Write a prompt that covers both, and each update squeezes both sets of details into 2,000 characters, so you lose half of each. You are better off keeping memory inside your CRM and treating the CRM as the single source of truth. What happens if you run both Retell Memory and your CRM? You get two sources of truth that can drift apart over time, and the agent cannot tell which one to trust. It is worse than relying on your Retell Memory alone or CRM alone. When we have to use a CRM anyway and can't really skip it, what's the point of using Retell Memory? The CRM can do everything Retell Memory does, and it does it better. You have full control over the context and can share it across your tech stack. The biggest architectural downside is maintaining a second customer record. If staff update the CRM while Retell maintains a separate brief, you need rules for which record takes precedence and how corrections reach both. What if you don't use a CRM? If you don't use a system of records (CRM or CRM like tool) you likely don't have a use case that requires retaining caller ID and previous context. I have yet to encounter a business that uses no system of record at all. Even if they aren't using a conventional CRM, they're likely using tools similar to a CRM, like field service tools (Service Titan, Jobber) or good old Google Sheets or Excel. So the real fix is still a CRM or CRM like feature. Retell could save itself a lot of work or rework by testing new features with developers who run voice agents in production before shipping them to everyone.

All these people with no coding background learning Claude code, but who is hiring them? If the skill doesn't translate to $ its just a hobby. Monetising AI is a totally different game. Companies pay for outcomes they can "trust" in production, not speed of generation or 'glue work'.

A bad workman always blames his tools. It’s not the AI, it’s the person using it.

Pro Tip: You can purchase unused API credits from businesses at a 50–60% discount and slash your API call costs in half. Many businesses purchase API credits in bulk or receive promotional credits from AI providers such as OpenAI and Anthropic. Some never use their full allocation. Instead of letting those credits go to waste, they can monetise unused API capacity through third-party marketplaces. Platforms such as Surplus Intelligence, Attium and LLM Mart advertise discounted access to AI models through these arrangements. In some cases, switching may be as simple as changing your API endpoint and API key. The catch is that discounted API access doesn't necessarily mean identical reliability, latency or data protection. So verify the provider's terms, test the service and compare your actual costs before switching. If you're running AI agents at scale, this is an opportunity worth exploring. Even a modest reduction in API costs can add up quickly.