Taia Dimitrova has been an experienced QA Engineer in software testing and quality assurance since 2016.
Adept at:
– Designing and implementing test plans
– Ensuring product and project quality
– Proven expertise in automation testing, test strategy development, and defect tracking
Committed to delivering high-quality software and enhancing user experience. Passionate about continuous improvement and dedicated to exceeding expectations. Eager to contribute to a dynamic team and drive innovation in the QA process.
In this QA Spotlight edition, I feature a refreshing and very modern perspective on what it means to be a QA engineer today.
This post tells the story of how a QA engineer turned a personal frustration — constantly missing good theatre tickets — into a fully functional Telegram bot that monitors theatre websites and sends notifications automatically. The twist? The bot wasn’t built in the traditional “write everything by hand” way.
Instead, ChatGPT was used for brainstorming and architecture, while Copilot was utilized for implementation. The QA engineer orchestrated everything, defining the flow, validating logic, handling edge cases, resolving deployment issues, and shaping the overall quality of the solution.
Below, I am sharing her full blog post:
How I built a Telegram theatre bot without really “building” it
I will be honest from the start: this bot did not begin with me opening an editor and writing code.
It actually started with a question I threw at ChatGPT: “Is this even doable?” From there, I mapped the architecture, clarified the moving pieces, and only then switched to Copilot to bring it all to life.
So no, I did not handcraft a Telegram bot line by line. I did not architect every module from scratch or sit up at 3 AM debugging API calls. Instead, I did something that feels perfectly normal in 2025. I combined ChatGPT for brainstorming and design with Copilot for implementation, vibed through the coding session, and iterated until everything worked.
And somehow, that flow turned into a fully functional automation bot that checks theatre calendars in Iași and sends me Telegram notifications whenever new events appear.
This is the story of a QA engineer building a bot without actually building the bot, at least not in the traditional “let me manually suffer through this codebase” way. And honestly, I do not have time to analyze every line of code right now, priorities exist, but the experience still taught me more than expected.
The real spark: missing out one too many times
Here is the true origin story of this bot.
One day I thought, “Let me check what plays are in Iași this week.” I opened the websites and all the good seats were already gone.
Front rows: gone. Side seats: gone. Everything I would have actually wanted: long gone.
It was not the first time this happened. If I manage to buy tickets in good spots, it is once every several months.
And my QA brain quietly whispered its favorite line: “Why are you doing this manually? You could automate this.”
And that is how the idea was born, from a mix of mild frustration and the desire to never miss a great theatre night again.
Enter copilot: my co-developer, co-architect, co-chaotic bestie
Before Copilot even entered the picture, I had already done the detective work. I opened the theatre websites, inspected the network calls, found the hidden endpoints, grabbed the request parameters, and looked at the shape of the JSON responses. Then I came back to ChatGPT with a simple question:
“Is this doable, and what would the architecture look like?”
Once I had a rough plan, I moved to Copilot and that is where the real vibe coding session began.
I did not write code from scratch. I explained the flow: “Here is the endpoint. Here is the request. Here is what the response looks like. Here is how I want the events to be processed and formatted. Here is the overall logic.”
Copilot took all of that and started generating the project: modules, helpers, scrapers, message builders. Sometimes beautifully, sometimes chaotically. And while the files were being created, my brain kept running in parallel:
- “These functions should really live in a utils file.”
- “This piece of logic needs to be centralized.”
- “This file does not belong here at all.”
So I nudged Copilot again and again: move this, refactor that, apply best practices, reorganize the whole project structure. And Copilot did, well, mostly. It would fix one thing and accidentally break another. I would try to fix its fix and accidentally break something else. Classic teamwork.
But that was the charm of it. It was not delegation. It was collaboration, messy, iterative, and surprisingly fun collaboration.
I brought the understanding, the analysis, the endpoints, the logic, and the QA instinct. Copilot brought the speed, the scaffolding, and the endless dev energy. And somehow, between the two of us, a clean, maintainable, fully functional theatre notifier bot emerged from what started as a casual idea and a vibe coding session.
My biggest lesson: You still need to think like an engineer
Even though Copilot wrote all the code, the thinking still had to come from me.
I did not architect the whole system by hand, but I did have to steer Copilot constantly: checking the structure it generated, asking it to refactor files, reorganize modules, and apply best practices for a proper Python project. None of that happened automatically. It took several iterations, a lot of “move this here” and “this should be in its own module,” until the project finally looked clean.
The scraping logic was not even my idea. Copilot and ChatGPT proposed it after I showed them the website structure. What was my contribution was the flow: how I wanted the message to look, when the bot should send it, how often it should check the sites, and what should happen if no new events were found. The keyword trigger was also my idea. The weekly cleanup of old events was also mine. Copilot handled the scaffolding, the functions, and the heavy lifting. I handled the direction, the logic, and the quality.
And that is the real takeaway:
AI can generate the code, but it cannot define the purpose, the flow, or the experience.
It does not magically decide what “good” looks like. That part still requires engineering thinking, judgment, and intention. You can automate the typing, but you cannot automate the understanding.
And then came the moment: “Wait, this bot needs to live somewhere.”
Once the bot finally worked on my laptop, I had a small but important realization:
I am not going to keep a terminal open forever just so the theatres can notify me about their events.
The bot needed independence. A life of its own. A place in the cloud where it could run happily twice a day without asking me for permission.
So I packaged everything up and deployed it, which somehow made the whole project feel real. It was not just a fun little script anymore, it became a tiny cloud creature checking theatre calendars on my behalf. A digital assistant with one very specific job:
to tell me when good plays appear.
And honestly, watching it run automatically for the first time without me felt a little magical. A two-hour vibe-coding idea had evolved into something autonomous, reliable, and surprisingly useful.
There is something uniquely satisfying about creating a bot you do not have to babysit.
It just lives, works, and does what is needed, which is more than I can say about some humans.
What went wrong (because something always does)
No project is complete without a little chaos, and this one delivered nicely.
1. The great Heroku pricing plot twist
Halfway through deployment, I confidently opened Heroku, ready to click the classic Free Tier button. Only to discover that the free tier had apparently been declared extinct.
A zero dollar side project suddenly wanted five dollars a month from me.
So I closed the tab, politely refused, and migrated everything to Render.com, learning an entirely new hosting platform in the process.
Vibe coding meets vibe DevOps.
2. The environment variable treasure hunt
Somewhere along the way I created a small identity crisis for my bot token.
Was it BOT_TOKEN, BOT_API_KEY, TOKEN? Nobody knew. Not even me.
Different files were reading different names, like each module had its own opinion. The bot worked locally but crashed in the cloud because one file insisted on using an environment variable that did not exist anywhere else.
10 out of 10 would not recommend.
3. The duplicate message incident
At one point my bot developed enthusiasm. Every command triggered twice, resulting in a polite but relentless flood of “checking for new events” messages.
It turned out that both main() and manual_check() were sending responses independently. My bot was not broken, it was just chatty. Too chatty.
4. The known events file that only existed on my laptop
Locally, everything was perfect. In the cloud: ‘FileNotFoundError: known_events.json’
Render had no idea this file was supposed to exist. The bot tried to load it, failed, panicked, and refused to continue. Creating the directory fixed it, but it was one of those classic “works on my machine” moments that makes you sigh deeply.
5. The endless file shuffle
What started as a cute little script slowly evolved into a full package. Files moved from root to core. Services got their own folder. Helpers were relocated. Imports broke. Fixing imports broke other imports.
At some point I realized I had spent more time reorganizing files than using them.
But that is the beauty of building with AI. You do not just write the project. You grow it, reshape it, and occasionally chase it around like a toddler with scissors.
Final thoughts
This project reminded me of something important:
AI may write the code, but it does not define the structure, the logic, or the quality. That part is still deeply human.
Copilot did not replace engineering thinking, it accelerated it. It let me stay focused on decisions, flows, risks, behaviors, and outcomes instead of keystrokes. And that is exactly where engineers bring the most value.
The result was a lightweight tool that solves a personal frustration, runs reliably in the cloud, and took a fraction of the time it would have required even five years ago.
And that is the beauty of this new era. When an idea appears, you do not have to let it fade. You can build it quickly, creatively, and thoughtfully.
Sometimes you automate tests. Sometimes you automate your life.
Both are valid.
And yes, if a real Python developer opens this repo, I am sure they will spot a few creative decisions.
Maybe more than a few. Happy to hear any.
Follow Her Work
If you enjoyed this perspective and want to read more content like this, make sure to follow Taia’s work.
👉 Connect with her on LinkedIn
This is a great example of how QA engineers can think beyond test cases, embrace modern tools like AI, and still apply strong engineering judgment to create meaningful solutions.
