Parrot
Project Overview
At some point, every AI-powered no-code experiment hits a wall. You start with a simple idea—“AI will build this for me”—and somewhere along the way, you realize that instead of solving problems, you’re debugging AI’s mistakes. And when AI is the one making the errors and the one fixing them, things can get… weird.
I wanted to break out of that cycle. Instead of asking one AI model to find a solution, what if I made several argue their way to a consensus? Something something “diversity of ideas” something something “two heads are better than one” something something… you get it. That’s how Parrot was born.
The resulting tool is linked from the button above! This one is presented as a demo of how it might work to avoid AI API costs but I can create a membership based tool if people are interested; otherwise feel free to use the instructions on this page and grab the code from github here and deploy your own recursive AI chatbot!
Problem Statement
I’ve written before about the dangers of the no-code feedback loop—that frustrating cycle where the problem seems obvious on paper, but no matter how many ways you phrase it, the AI agent keeps confidently proclaiming, “Fixed!” when nothing has actually changed. It’s like trying to explain a joke to someone who just doesn’t get it, except the joke is your broken app, and the AI insists it’s working fine.
These were two separate solutions that Claude (via Cursor AI) presented in a row, both claiming things were “fixed”
The usual fix? Start a new chat, rephrase the question, and try again. Sometimes that works. But sometimes, even with a fresh conversation, the AI still latches onto a flawed solution and refuses to let go. That’s where Parrot comes in—the idea was to stop these dead-end loops by making different AI agents argue their way to a real fix (or at least some new potential ways to tackle the problem), instead of just reinforcing each other’s mistakes. That premise was simple: If AI can write code, and AI can debug code, can AI also validate its own solutions? Could I automate my own debugging process by making AI explain itself to another AI?
Turns out, this is easier said than done… as usual. However, we've built a tool that has definitely been helpful in plotting a new course out of tricky recursive errors.
Objective
The goal with Parrot was to figure out how to make an AI chatbot that could actually chat with “itself” — not just respond in isolation, but hold an ongoing, dynamic conversation. I wanted a system where AI agents could talk to each other about debugging problems, refine their answers, and validate solutions without me having to mediate every step. But for that to work, I needed to solve three core challenges:
1. Building a functional AI chatbot — figuring out the architecture so that conversations were structured in a way that allowed different models to interact meaningfully.
2. Creating a smooth, conversational flow—ensuring AI didn’t just dump information but engaged in actual back-and-forth reasoning.
3. Putting it all in a clean, usable UI—we take for granted the context windows that tools like ChatGPT and Claude provide, I had to find the right UI/platform to make this easier.
Parrot was my way of making AI debugging feel like an actual discussion—one where different models could challenge, refine, and (ideally) reach the best possible solution. It also was/is a tool that I simply needed to get myself out of some coding corners.
Build Process
Parrot started out like most of my AI projects—with a simple prompt. I asked GPT for guidance on how to build a chatbot, and it recommended some tools. Easy enough. I followed its lead, spinning up scripts and testing different frameworks, assuming that would be the hard part.
But the real challenge wasn’t the tools—it was the architecture. Making a chatbot respond is easy. Making it hold a real conversation, where responses build on each other and context is maintained, is where things got tricky. The AI needed to do more than just react to single inputs; it had to engage in an actual back-and-forth, remember past messages, and adjust its reasoning dynamically.
That’s where the build process got interesting—shifting from “just write responses” to structuring a system where AI could argue, refine, and actually solve problems collaboratively.
Code Before UI
At first, I figured a simple command-line tool would be enough—just type in your code, get a response, done. Functional, straightforward, and it worked. You can see the initial setup in the screenshot below. But pretty quickly, it started feeling clunky. Every time I had a question, I had to relaunch the script, open the terminal, and type everything out again.
First working code in terminal
Then I hit a bigger problem—sometimes I needed to attach more code, or my question expanded into multiple lines, and that just doesn’t flow well in a terminal. Despite having a working version, I realized I needed something closer to the kind of context window we’re used to with AI. That’s when I turned to GPT to figure out how to build a simple UI cell that actually made sense.
I kind of broke my (recently established) ruleset with this project of “plan features, sketch out UI, boilerplate the code & deploy, then refine” — I've written about this a little bit in past posts but following this general structure has served me well as I've been building these various things. I think with this project it just started as a little helper tool for myself and turned into something bigger that I wanted to add some polish to in order to make it more usable for myself and something that other people could copy and implement as well.
Moving to “Full Chatbot”
There are plenty of platforms for hosting a chatbot, but for Parrot, I went with Streamlit—a deceptively simple tool that probably has more capabilities than I’m giving it credit for. At its core, Streamlit let me host a Python script and instantly turn it into a usable UI. Unlike most of my past projects, where I started by designing a frontend, this time I skipped straight to asking GPT for a working script and let Streamlit handle the rest.
Instead of wrestling with web frameworks, I let Streamlit provide the UI dynamically—it handled input boxes, displayed responses, and ran everything in real time. The alternative would have been building a UI from scratch, setting up a separate web app, and dealing with Vercel’s deployment quirks. But why do all that when I could just host the code and be done with it?
Why Streamlit Worked Well for This Project:
• Instant UI Generation – No need to manually build input forms or chat windows; Streamlit creates them from the script.
• Simple Hosting – Avoided complicated frontend deployment; just run the Python script, and the UI works.
• Live Code Execution – Updates and responses are generated in real time, making it feel like an interactive app without extra infrastructure.
• Rapid Prototyping – Made it easy to test and iterate on the chatbot’s logic without rebuilding the UI each time.
Setting up Streamlit for your Chatbot
You can follow these steps to get your own chatbot running. Or, you know, just ask GPT.
Open a terminal and run the streamlit install package to ensure you have everything needed to run a Streamlit app.
pip install streamlit
Create and Deploy Your App on Streamlit Cloud
Go to Streamlit Community Cloud and log in using your GitHub account.
Click “New app” to start deployment.
Select the GitHub repository where your chatbot’s code is stored.
Choose the main branch and set the entry file (typically app.py).
Click “Deploy”, and Streamlit will launch your app.
Configure API Keys Using Streamlit Secrets
In your Streamlit Cloud dashboard, find your app.
Click the three-dot menu (⋮) → “Settings” → “Secrets”.
Add your API keys in the following format:
CLAUDE_API_KEY = "your-anthropic-api-key"OPENAI_API_KEY = "your-openai-api-key"DEEPSEEK_API_KEY = "your-deepseek-api-key"
Click “Save” to apply the changes securely.
Update and Maintain Your App
Any updates you push to the connected GitHub repository will automatically reflect in your Streamlit app.
If you need UI improvements (e.g., better chat flow or file uploads), edit app.py locally and push changes to GitHub.
Restart the app via the Streamlit Cloud dashboard if needed.
Now, instead of using a clunky terminal, you have an interactive AI chatbot with a smooth, web-based UI.
Local Git Repository Usage
At this point, I’ve slowly evolved into an AI-assisted pseudo-developer, picking up bits and pieces about Git and GitHub along the way. I’ve worked in tools like Cursor AI and followed GPT’s instructions for initializing repositories, connecting them to remotes, and syncing code. But something really clicked during this project—I realized that any folder can become a Git repository just by running a simple command in the terminal.
I’d been thinking of Git as something tied to my development environment, like Cursor or VS Code, where repos are just “there” when you start a project. But once GPT walked me through the setup manually, it hit me: all those tools are just running the same Git commands under the hood. If I wanted to, I could skip the fancy dev environments and just use the terminal to create a repo, make changes to a single file, and sync things up—no full project structure required.
It’s one of those obvious-in-retrospect moments, but still a eureka moment for me. Just knowing that I can spin up a repo anywhere, track changes, and sync with GitHub using a few basic commands makes the whole thing feel way more flexible and under my control.
As a sidenote, here’s the Git cheat sheet I use to keep track of commands and workflows.
Do Androids Dream of Electric Sheep? (Or, Forcing the AI to Argue with Itself)
One of the biggest challenges in getting the AI agents to talk to each other was maintaining proper context across the conversation. At first, I had them responding independently (not intentionally, I didn’t realize that chat context wasn’t being preserved between responses), but the back-and-forth quickly started feeling disjointed—responses lacked memory of previous arguments, and sometimes an AI would just rephrase the same point instead of engaging with what the others had said. Keeping track of the entire conversation history in each prompt helped, but it also made the responses bloated, with AI agents spending too much time summarizing instead of actually debating.
After some trial and error, I realized that just feeding them the chat history wasn’t enough—they needed a reason to engage dynamically rather than just stacking responses on top of each other. The breakthrough came when I started explicitly telling the AI agents to challenge each other’s assumptions and look for flaws in previous responses. This immediately made the discussions feel more natural and engaging—they weren’t just explaining their own views but actively disagreeing, correcting, and refining each other’s arguments.
It turns out that making AI truly “talk” to itself isn’t just about feeding it prior messages—it’s about giving it a goal in the conversation beyond just answering the question. As with many things this isn't terribly surprising in retrospect, but it also wasn't part of my initial design or intention. By tweaking their behavior to be a little more combative (in a productive way), the responses started to feel like actual debate rather than a group of independent AI monologues… and the outputs became more useful and usable.
Forming a Consensus
The final structural piece here was getting the AI to drive toward consensus. After some back-and-forth, I now have the prompts explicitly ask, “Have we arrived at a consensus?” If the answer is yes, it outputs a final consensus block—a clear set of recommendations that can be taken and implemented into the code (or, more commonly, a set of recommendations and thoughts that amount to some new unique ideas around “have you tried this…?”). If not, it loops for another round, up to the max discussion limit I’ve set.
In practice, more rounds don’t necessarily mean better answers—a lot of times, they just produce longer ones. But I’ve definitely seen cases where extra iterations helped refine ideas and get the AI to actually agree on a path forward. The system could absolutely be made smarter, maybe by dynamically adjusting how many rounds are needed based on disagreement levels, but for now, it captures the intent I wanted: AI models not just responding independently, but actively debating and resolving their differences to produce a useful outcome.
Was this section just an excuse to use the above GIF? Yes, yes it was.
Results & Lessons Learned
Project Status: Usable Tool
When you check out the tool page for this one, it just displays a (hilarious, to my dad-centric humor) sample conversation that shows how the whole process works in practice. Unlike the other tools I’ve built, this one isn’t immediately usable or interactive—it’s more of a behind-the-scenes tool that I built to help myself build other tools.
It became substantial enough that I felt the technique was worth sharing. I pop this chat bot open whenever I’m feeling stuck on a problem, like a brain trust of AI models that I can bounce ideas off of. It’s less about getting a single right answer and more about sparking new angles to troubleshoot my way out of whatever challenge I’m working through.
Lessons Learned
Lessons Learned
Sometimes, just hosting the code is enough: I could have gone the full custom web app route, but in this case, letting Streamlit do the heavy lifting saved time, effort, and a lot of debugging/deploying pain.
AI models need structure, not just prompts: Just throwing AI agents into a conversation without clear instructions leads to messy, repetitive, and unfocused results. Structuring their roles, setting debate rules, and guiding them toward consensus made all the difference.
The simplest tools can be the most useful: This wasn’t built to be a polished, user-facing app—it was just a tool to help me build other tools. But it ended up being so useful that I realized the technique itself was worth sharing.
Costs
No net new costs this week at all! Streamlit has paid service tiers but they have not been necessary.
The Toolbox
Section coming soon! See the main build details for tools used. The main new tool this week was Streamlit, for hosting the chatbot code.
#efficiencies
The whole genesis of this tool was actually efficiency-focused. I kept running into a recurring problem—getting stuck in an AI feedback loop where progress in my no-code apps stalled, and I wasn’t sure what the next step should be. So, instead of struggling through it every time, I built a mini tool for myself to quickly generate ideas, discussions, and implementation steps to break out of that loop and move forward.
I’ve already been using this to build upcoming projects, and I know I’ll keep refining it over time to make it even more useful and adaptable. It’s not just another app—it’s a problem-solving engine that helps me tackle roadblocks faster.
Next Steps
As for where this mini app goes from here—I don’t have any explicit plans to build on it or turn it into a full product. For me, it was enough to just share the approach I took to solving a problem.
That said, there are plenty of potential improvements that could be made:
The prompting logic could be fine-tuned,
We could incorporate more advanced reasoning models, which I’ve already experimented with…
Another interesting idea would be to store previous resolutions in an aggregated memory, allowing the system to retrain itself and search for the right types of solutions over time.
Actually… as I’m writing this, that last point has some real merit—I’m adding that one to the idea bank for another day. One of my other side projects involved building a RAG (Retrieval-Augmented Generation) database, which helped focus AI responses more effectively. There’s probably something useful in creating a RAG-powered chatbot that logs discussions, learns from back-and-forth feedback, and improves its ability to assist people like me—no-coders hacking their way to working solutions… Stay tuned…
