# How we went from no-code agents to no-prompt agents

> Source: <https://dev.to/hanan_amar/how-we-went-from-no-code-agents-to-no-prompt-agents-1o40>
> Published: 2026-06-24 15:37:06+00:00

When we started [Reach](https://reach.kindway.ai), the plan was simple. We had a bunch of small businesses we were already in touch with - real SMBs, the kind that live on WhatsApp and don't have a "tech team." We'd give each of them an AI agent that talks to their customers, hand them a clean starter template for the instructions, and let them tweak it from there.

That was the whole bet: *give people a good starting prompt and a template, and they'll play along.*

We were so wrong it's almost funny now.

Here's the thing about prompt engineering that you only learn by watching non-technical people try to do it: writing the instructions is not the hard part. The hard part is *thinking about the task in the abstract*.

We'd hand a business owner an agent that mostly worked, and say "just adjust the instructions when it gets something wrong." Sounds easy. It is not. Sitting down and imagining all the ways a conversation could go, then writing rules for a machine to follow - that's a skill. It's basically a job. And it's a completely different job from running a flower shop or a real estate office.

So they got stuck. They'd open the instructions editor, stare at it, and close it. The agent stayed mediocre because the iteration loop we designed required them to be part-time prompt engineers. A few of them just quietly left.

That stung, but it taught us the actual problem.

We started doing the iterations *for* them, manually. And once we did that a few dozen times, a pattern jumped out.

The feedback never led to an abstract change. It was never something that made us "rethink the agent's persona" or "restructure the system prompt." It was tiny, concrete, and tied to a real conversation:

These were one-line corrections. The owner knew *exactly* what was wrong the moment they saw a real conversation. They just had no idea how to turn that into a prompt edit, and frankly, they shouldn't have to.

That's when it clicked: the customer doesn't need a prompt editor. The customer needs to point at a real conversation and say "this - fix this."

So we flipped the whole thing. Instead of asking people to imagine use cases (hard) and write instructions (also hard), we built the loop around something they're already good at: **reacting to a conversation that actually happened.**

The flow looks like this:

The key design decision was upstream of all the engineering: **the agent's job is not to be a human.** Its job is to answer the repetitive, known stuff instantly and hand off everything else to an actual person. Once we stopped trying to make the agent do a human's job, the feedback got simpler too - because we were only ever correcting the boring, repeatable parts.

The strange ending to this story: a month or so into running that pipeline, we looked at our own product and realized the system prompt editor - the thing we'd built the entire platform around - was dead weight. Nobody needed it. Every meaningful improvement was now coming through conversation feedback, not through someone editing raw instructions.

So we removed it from the UI.

It's a weird feeling to watch the core of your product become obsolete in a single month, by your own hand. But that's kind of the whole experience of building in this era - the ground keeps moving, and sometimes the best thing you can do is delete the feature you were most proud of, because the model and the workflow around it made it unnecessary.

If you're building agent tooling for non-technical users, my honest advice: stop trying to teach them to prompt. Build the loop around the artifact they already understand - a real conversation - and let the system do the translation.

*We're building this at Kindway. The agent platform is Reach - AI agents for SMBs on WhatsApp, Instagram, and beyond. Happy to talk shop in the comments.*
