I think we've all seen the pitch lately. It's
really seductive. An AI that can build these
incredibly complex business automations for you.
Oh, yeah. You just describe what you want and,
you know, magic is supposed to happen. It's like
a magic wand, right? The idea of turning hours
of coding into just a few seconds of typing.
But here's the immediate reality check we found
from the testing. It is a supremely powerful
tool. It's incredibly fast. But the first version
it gives you, it breaks a lot. Welcome back to
the Deep Dive. Today, we're taking a really close
look at the real -world performance of text -to
-automation. We're focusing on NN's new AI Workflow
Builder, and it's all based on four pretty rigorous
stress tests from our source material. Right.
So just to set the table here, the AI Workflow
Builder is a feature where you use plain English
to describe what you want. Okay. And in response,
the AI generates the entire node structure for
you. And that's basically the pre -wired blueprint
of your automation. Okay, so let's get right
into it. Our mission here is to figure out if
this tool really replaces needing to know how
to build automations yourself. Yeah. Or if it's
more of a, what we're calling a powerful skeleton
generator. Exactly. We need to know what... you
listening still have to bring to the table. Absolutely.
And these four demos, they really show you exactly
where that human touch is still completely essential.
So the promise is pretty thrilling. You're taking
what could be hours of careful manual workflow
building and turning it into just. Few minutes
of prompting. That's a huge acceleration. And
the reality, I mean, it does confirm that the
AI massively speeds up the process. It creates
these logical sequential structures so fast.
But every single time it needs a human to come
in and fix the configuration details. And especially
the little quirks from third party APIs. It needs
guidance to get from the idea to something that
actually works. You know, I still wrestle with
prompt drift myself. And that's. That's a vulnerable
admission for someone who writes these things
every day. Getting that initial text just right
is really hard, even when you know exactly what
you want. It's totally understandable. Prompt
drift in automation is uniquely tricky because
it's not just the AI changing the words. Right.
It's when it subtly changes the core logic of
how the thing runs or some tiny parameter that
just makes the whole thing fail. So that translation
from human language to a working workflow is
really the hardest part. If the AI builds these
skeletons so quickly, what's the biggest, most
common failure that trips people up? The main
culprits are almost always hidden settings in
third -party APIs and variable mapping errors
that the AI itself actually creates. Okay, so
configuration details and empty variables. They're
the architects of failure. Got it. Let's get
into a practical example then. Demo one. This
was about building a daily newsletter workflow.
A really common task. The prompt seems straightforward.
Research tech trends using a tool called Tavli.
Find an AI tool with perplexity, add a quote,
and then just email the results. And visually...
What the AI came back with was flawless. It built
a perfect five -node structure. You know, scheduled
the two research nodes, a code generator, and
the email node. And it did this in, like, five
seconds. About five seconds, yeah. Everything
looked connected. It looked ready to go. But
when it actually ran, there were no errors, right?
The workflow said it completed successfully.
Exactly. It completed successfully. But the email
that arrived was, well, it was almost empty.
No tech trends, no AI tool, nothing. Just the
boilerplate text. It failed silently. And that's
a classic silent failure. So what was the culprit
when they dug in? It was a critical but totally
hidden setting inside the Tavoli node. By default,
Tavoli just sends back a summary to be efficient.
Okay. But to get the actual raw data to pass
to the next node in the chain, you have to manually
check a box called include response. So it's
basically a hidden checkbox that's off by default.
Exactly. The AI understands the generic NAN node
perfectly. It knows the node exists. But it has
no idea about that specific obscure setting for
that one third -party service. So the variable
it was supposed to pass on was never even created.
It was never created. So the next node just got
empty air. So the AI missed a required hidden
checkbox. For you listening, what's the one thing
we always have to check manually? in these ai
built flows always always examine the optional
settings and node parameters for any third -party
services especially the ones that handle external
data okay let's switch gears to demo two because
this one shows a completely different side of
the ai yeah a really positive one this was a
sales brief generator the first try failed it
was a variable name mismatch the ai created and
it also chose the wrong model And here's where
it gets really cool. So instead of spending,
you know, 20 minutes manually hunting for that
tiny error, which is just agonizing. I live in
there. It's the worst. Right. The person building
this used the AI itself as a troubleshooting
partner. They just copied the raw error message,
all that confusing code, and pasted it right
back into the AI builder. That is a fascinating
move. Using the AI as its own diagnostic tool.
What happened? The result was stunning. The AI
successfully diagnosed and instantly fixed the
variable name mismatch, an error that it had
created. It saw the error context and just provided
the corrected workflow. Wait a minute. So the
AI is actually better at fixing its own mistakes
than we are at finding them. I mean, does that
genuinely save time or is it just a loop? No,
it genuinely saves a ton of time because it knows
the internal language of the nodes better than
a human can track every single data point. When
you give it the context of an error. It's excellent
at finding its own mistakes. It just gets rid
of that horrible manual bug hunting. Okay, so
that's where the real power lies. It's in that
iterative improvement, using its own error messages
as feedback. Now let's look at the biggest cost,
the ambiguity trap, demo three. Ah, yes. The
prompt here was so vague. It was just, build
a multi -agent setup that can look into a subject,
confirm what's accurate, and pull the results
together. That prompt is. It's dangerously ambiguous.
You're giving the AI zero constraints, no trigger,
no data source, no format, nothing. And if you
don't constrain it, the AI will always, always
aim for the most complex solution it can think
of. So what did it spit out when it got that
vague request? It basically hallucinated. It
created this ridiculously over -engineered, confusing,
and totally broken workflow. Oh, wow. It had
an orchestrator agent, multiple sub -agents all
running in parallel, manual triggers, complex
branching logic. It was just spaghetti, the kind
of thing that instantly fails when it tries to
merge data. So vague input leads directly to
these over -engineered, broken workflows. And
that costs time, but there's a real financial
cost here too, isn't there? Yes. This is so important.
The AN8s and cloud plans have mostly usage credits
for the AI. Right. And generating a massive,
broken, complex workflow like that. It just burns
through your credits instantly. Sloppy, ambiguous
prompts literally cost you money. That really
drives home the need for detailed prompts from
the start instead of just wasting credits on
iteration. So what is the easiest way to stop
the AI from... over -complicating a build. Just
force it to build linear, sequential workflows.
That simple constraint prevents almost all of
the complex data -merging errors that happen
when parallel branches try to combine their results.
Okay, so let's contrast all that failure with
the one that worked. Demo 4. This was another
daily newsletter, but this time the prompt was
basically a full project brief. The success was
100 % due to specificity. The prompt laid everything
out. The schedule was 6 a .m. The data source
was Tavli. It even specified the exact configuration
setting. The include response one. Include response,
yeah. explicitly mentioning that to fix the error
from demo one. And it even specified the AI model
to use Anthropics Cloud 4 .5 Sonnet because it's
better at handling complex instructions. So you
basically addressed every single failure point
from the other tests all in one perfect prompt.
Almost. The first bill it gave us still had one
tiny issue. Even with all that detail, it tried
to run the four research searches in parallel.
which still risk messing up the data merging.
So how did you fix that structural problem? A
single line in the chat. Just a command that
said, force this into a fully linear structure.
And that was it. The final result was a perfectly
formatted HTML newsletter that worked on the
very first try. Whoa. I mean, just imagine creating
a production -ready multi -step workflow in seconds.
Just by providing that level of detail, that
really is the acceleration promise. It is. It
really shows that the future of this isn't learning
less. It's about learning how to be an incredibly
precise project manager for an AI. Which brings
us to the three core principles from these tests.
First, be as detailed as possible. Think of it
like you're briefing a junior developer. Right.
Specify everything, the tools, the exact settings,
the output you need. Second, don't expect it
to be perfect on the first try. Plan on using
the AI to help you debug the errors it's inevitably
going to make. And third, prefer linear workflows.
Just avoid the complex branching. They're easier
to build, easier to test, and way, way easier
to debug. So the critical takeaway about prompting
these AI automation builders? Specificity is
everything. The more detailed your instructions,
especially on configuration, the better your
results will be and the faster you'll get a working
automation. That brings up a huge question for
anyone looking at these tools. Is it even worth
it anymore to learn a platform like NENA manually
if the AI can just build the skeleton for you?
The answer is definitively yes, absolutely. Your
manual knowledge of how processes work is still
critical. If you can't even articulate the steps
of what you're trying to do, you can't write
a good prompt. And you still need to understand
data transformation, don't you? You have to know
why a variable is empty or how to reformat data.
That's a fundamental troubleshooting skill. Precisely.
The AI is an architecture generator. You provide
the logic. You provide the muscle and the nervous
system that makes it all work. Right now, these
tools really struggle with third -party API details
and complex variable mapping, which just proves
you need that expert human eye. So to sum up
the big idea here. The AI workflow builder isn't
a replacement for learning the fundamentals of
automation, but it is an incredible accelerator
that makes expert builders maybe 10 times faster.
That's it. But anyone who tries to skip the learning
part is just going to get stuck in a constant
and expensive debugging cycle. Learn the platform
first, then use the AI to go faster. So we'd
encourage you to try this. Go automate a simple
linear process by hand first. Then ask the AI
to generate the skeleton for the same thing and
just compare them. See what's different and see
what tiny configuration details the AI missed.
And here's a final thought to leave you with.
If the AI can reliably diagnose its own variable
and configuration errors, maybe even better than
a human can spot them. How long is it until AI
just masters the documentation for every third
-party API out there? I mean, how long until...
specific manual configuration becomes truly obsolete
because the AI just knows that hidden checkbox
needs to be ticked every single time. That's
something to think about. Until next time. Something
serious.