I Built an AI Software Engineering Team Inside Telegram. They Have Jobs, Responsibilities, and Apparently Trust Issues

Sujal Gupta — Thu, 05 Nov 2026 17:39:53 +0000

Codex is the manager. Cursor writes the code. OpenCode tries to destroy it. And I get to decide whether anyone gets promoted or fired.

What if you could open Telegram, send a message like:

"Hey team, add a chatbot feature to this project."

And instead of getting another AI-generated explanation of how to build a chatbot, an entire engineering team actually builds it for you?

One agent plans the work, another writes the code, a third aggressively tries to find mistakes, and finally, you get to approve the changes.

Sounds like a software company's dream.

Or a startup founder's attempt to avoid hiring employees.

That's exactly what we built for the Flip the Switch Hackathon 2026.

Meet our project: An Autonomous AI Software Engineering Team powered by Switch.

1. The Problem: Why Does One AI Have to Do Everything?

Let's be honest.

We've all used AI coding assistants. You ask them to build a feature, and they confidently generate 300 lines of code.

You ask them to review it, and they respond:

"Everything looks good! No issues found."

Of course, it looks good. YOU JUST WROTE IT, YOU ABSOLUTE GENIUS.

The problem is that most AI coding workflows rely on a single agent doing everything:

Understand the requirements.
Design the architecture.
Write the implementation.
Test the implementation.
Review its own work.

That's basically asking a student to write an exam, evaluate their own answer sheet, and declare themselves the university topper.

We wanted something different.

Instead of one AI trying to become an entire software engineering department, why not create multiple specialized agents with separate responsibilities?

And more importantly, let them disagree with each other.

Because sometimes the best way to improve code is to have another AI tell the first one that its code is terrible.

2. The Idea: A Software Engineering Team That Lives Inside Telegram

Imagine having an engineering team available directly inside your Telegram group.

No opening five different applications. No manually copying code between agents. No repeatedly explaining the same context.

Just Telegram.

Here's how a typical interaction looks:

Human Developer:
"In prompt-wars, add an interactive chatbot feature."

Codex (Engineering Lead):
"Task #001 created. Identifying the project architecture and planning implementation."

Cursor (Developer):
"Detected React 19 + Vite + TypeScript. Created Chatbot.tsx, implemented state management and UI, and integrated it into App.tsx."

OpenCode (QA Engineer):
"Running adversarial QA... Oxlint passed. No syntax errors or warnings detected."

Codex:
"Changes are ready for review. Type /diff to inspect or Approve to proceed."

Human Developer:
"Approve."

Codex:
"Git branch created, changes committed, and GitHub Pull Request opened!"

And just like that, your AI employees have completed their assignment.

Fortunately, they don't ask for salary hikes. Yet.

3. Why Switch? The Communication Problem

Having multiple AI agents sounds cool until you actually try making them communicate.

Suddenly, you have three different agent CLIs, separate contexts, different execution environments, and absolutely no idea how to coordinate everything.

You need to answer questions like:

How does Codex communicate its plan to Cursor?
How does OpenCode receive Cursor's code changes?
How do agents maintain shared context?
How do messages reach Telegram?
How do you avoid building a complicated collection of custom communication bridges?

This is where Switch enters the picture.

Switch acts as the central communication layer of our architecture.

We used it for:

1. Decoupled Agent Communication

Instead of hardcoding direct connections between agents, they communicate through Switch rooms using the Model Context Protocol (MCP).

2. Telegram Integration

Switch bridges our internal agent communication room with a Telegram group.

Messages from humans enter the system through Telegram, and agent responses are delivered back into the same conversation.

3. Context Preservation

When Codex hands a task to Cursor, Cursor receives the relevant task history. When Cursor finishes, OpenCode receives the implementation context needed to review the changes.

Basically, nobody has to ask:

"Wait, what were we doing again?"

Even AI agents hate repeating themselves.

4. System Architecture: Seven Stages of Engineering Chaos

We orchestrated the complete workflow using LangGraph, with SQLite handling persistent state and checkpoints.

Here's the pipeline:

Stage 1 & 2: Codex Receives and Classifies the Task

Codex acts as the engineering lead.

It receives the developer's request, understands the intent, generates a unique task ID, and classifies the task into one of four categories:

BUG
FEATURE
REFACTOR
DOCUMENTATION

It then prepares the implementation plan.

Stage 3: Cursor Investigates the Repository

Before writing code, Cursor needs to understand what it's working with.

It inspects the repository to identify:

Programming languages.
Frameworks and libraries.
Existing project structure.
Relevant components and files.
Potential integration points.

Because blindly writing code without understanding the project is a great way to create a second project inside the first one.

Stage 4: Cursor Implements the Feature

Once the plan is ready, Cursor gets to work.

It generates the required components, creates files, integrates imports, and modifies the relevant application files.

It also produces a unified diff so that changes can be inspected.

Stage 5: OpenCode Performs Adversarial QA

This is where things get interesting.

OpenCode independently reviews the generated implementation.

It executes tests, performs static analysis, checks syntax, and looks for potential issues.

If something fails, the system sends the feedback back to Cursor for correction.

This process repeats for up to three correction cycles.

If the issue still persists, the system escalates it to the human developer.

Apparently, even AI employees need performance reviews.

Stage 6: Human Approval

Once QA passes, Codex sends the developer a review request.

The developer can:

/diff — Inspect the changes.
Approve — Allow Git operations.
Reject — Stop the workflow.

No approval means no commit or push.

We wanted autonomy, not an AI agent accidentally rewriting someone's entire repository at 3 AM.

Stage 6.5: Git Operations

After approval, the system:

Creates a Git branch.
Commits the changes.
Pushes the branch.
Opens a GitHub Pull Request.

Stage 7: Final Report

Codex generates a final summary and posts it directly into Telegram.

The developer gets a complete overview without having to inspect every internal execution step.

5. Meet the Team: Everyone Has a Job

We didn't want three agents doing the same thing. Each agent has a clearly defined responsibility.

Codex — The Manager Who Never Stops Assigning Tasks

Codex is responsible for orchestration and coordination.

Its responsibilities include:

Understanding user requirements.
Classifying tasks.
Generating task IDs.
Preparing implementation plans.
Coordinating agent handoffs.
Managing approval workflows.
Delivering final reports.

Think of Codex as the engineering manager who attends every meeting but doesn't necessarily write the code.

Cursor — The Developer Who Actually Does the Work

Cursor is responsible for implementation.

It investigates the repository and generates actual application code.

Some of its capabilities include:

Creating complete React components.
Implementing state hooks.
Adding responsive styling.
Integrating components into existing applications.
Safely modifying imports.
Generating unified diffs.

It also uses AST-based boundary detection to identify safe integration points.

Because simply appending code to the end of a file and hoping for the best is not a software engineering strategy.

OpenCode — The QA Engineer Who Trusts Nobody

OpenCode is our adversarial reviewer.

Its job is not to appreciate Cursor's creativity.

Its job is to find problems.

It performs:

Pytest execution.
Oxlint static analysis.
Syntax validation.
Brace and quotation checks.
AST compilation checks.
Automated QA feedback.

If Cursor introduces an issue, OpenCode reports it, and the system sends the feedback back for correction.

Basically, Cursor writes code, and OpenCode wakes up every morning wondering how to break it.

Human Developer — The Actual Boss

Despite having three AI agents, one important person remains in charge.

You.

Agents can inspect, generate, test, and prepare changes, but they cannot independently commit or push code.

The final decision always belongs to the human developer.

Because giving an AI complete control over your GitHub repository is an interesting experiment, but perhaps not one we should conduct on our main branch.

6. Technical Challenges: Things That Broke Before They Worked

Of course, building this wasn't as simple as writing three prompts and watching magic happen.

We encountered several interesting problems.

Challenge 1: The Great README Disaster

During our early prototypes, we asked Cursor to implement a chatbot feature.

It couldn't find an existing chatbot file.

So what did it do?

It started appending comments to README.md.

Yes. We asked for a chatbot and got documentation.

Technically, the README was updated. Technically, our requirements were not met.

We realized that Cursor needed a much better understanding of repository architecture.

So we developed a Stack and Component Architecture Detector.

Now the system:

Inspects package.json.
Detects React 19 and TypeScript.
Identifies the src/components directory.
Creates Chatbot.tsx.
Finds the appropriate integration point in App.tsx.

The README can finally rest in peace.

Challenge 2: QA That Doesn't Take Forever

A conversational development workflow needs fast feedback.

Nobody wants to wait a minute after every small code modification.

We integrated Oxlint, a Rust-based linter, along with AST-based validation.

In our test environment, Oxlint analyzed 39 files in approximately 27 milliseconds.

That's fast enough that the QA engineer barely has time to complain.

Challenge 3: Working With Multiple Repositories

Developers rarely work on just one repository.

We therefore implemented a dynamic ProjectManager inside Codex.

Developers can manage repositories directly through Telegram.

Available commands include:

/projects — List available repositories.
/use prompt-wars — Switch to another repository.
/files — Explore the project file tree.
/undo — Roll back changes.

Switching projects shouldn't require performing an archaeological excavation through your terminal history.

7. Testing: Did It Actually Work?

We validated the system using 20 automated unit and integration tests.

These covered:

SQLite state persistence.
LangGraph workflow execution.
Switch MCP envelope formatting.
Agent communication and mention addressing.
Python, TypeScript, React JSX, JSON, and HTML validation.
Automated correction loops.
Timeout boundaries.
Human rejection guardrails.

And the result?

============================= test session starts =============================
collected 20 items

tests\test_workflow.py .................... [100%]

============================= 20 passed in 15.97s =============================

20 tests passed. Zero excuses from the QA department.

8. What We Learned

Building this project taught us a few important things.

1. Multi-agent systems need proper coordination.

Simply running multiple LLMs does not automatically create a collaborative system. You need shared state, communication protocols, task boundaries, and reliable handoffs.

2. Independent QA is incredibly valuable.

A model reviewing its own code is not the same as an independent agent critically examining the implementation.

Separating development and QA creates an opportunity to catch mistakes that might otherwise go unnoticed.

3. Human-in-the-loop is not optional.

Autonomy is useful, but unrestricted autonomy can be dangerous.

We deliberately kept Git operations behind an explicit approval gate.

4. Developer experience matters.

A powerful system is not necessarily a useful system if interacting with it is complicated.

Being able to request a feature, inspect a diff, and approve changes from Telegram makes the entire workflow much more accessible.

9. Open Source: Go Break It Yourself!

We built this project for the Flip the Switch Hackathon 2026, and the entire implementation is available on GitHub.

GitHub Repository: https://github.com/Sujal01go/switch-hackathon

Tech Stack:

Switch
Telegram Bot API
MCP (Model Context Protocol)
LangGraph
Python 3.12
SQLite
Pytest
Codex CLI
Cursor Agent
OpenCode CLI

Feel free to explore the repository, experiment with the architecture, and suggest improvements.

We would genuinely love to hear your feedback.

Final Thoughts

We started with a simple question:

What if AI coding assistants stopped working alone and started working together?

The result was a small virtual engineering team with a manager, a developer, a QA engineer, and one human who still has to approve everything.

The funny part?

They can write code, review code, communicate, and open pull requests.

But I still have to tell them when to take a break.

Maybe the next feature should be an AI HR department.

Until then, happy coding! 🚀

Built with Switch for Flip the Switch Hackathon 2026.

DEV Community: Sujal Gupta