DEV Community: Odunayo Dada

How I Built DevTeam AI: A Multi-Agent Software Engineering Team Powered by QwenCloud

Odunayo Dada — Wed, 08 Jul 2026 20:45:49 +0000

How I Built DevTeam AI: A Multi-Agent Software Engineering Team Powered by QwenCloud

Turning a single product idea into a complete software delivery plan using specialized AI agents, human approval workflows, and QwenCloud.

Introduction

Large Language Models have become incredibly good at generating code, documentation, and product ideas. But there's one problem I kept running into.

Software isn't built by one person.

A successful product typically involves product managers, solution architects, backend engineers, frontend engineers, QA engineers, technical leads, and reviewers—all collaborating, challenging assumptions, and refining ideas before a single line of production code is written.

Most AI applications flatten all of these roles into a single prompt.

I wanted to explore something different.

For the QwenCloud Global AI Hackathon (Agent Society Track), I built DevTeam AI—a multi-agent software engineering platform where specialized AI agents collaborate like a real product team, complete with approvals, design reviews, negotiations, revisions, and code generation.

Rather than asking one AI assistant to do everything, DevTeam AI orchestrates an entire software delivery workflow powered by QwenCloud.

The Problem

One of the most expensive parts of software development isn't coding.

It's planning.

Anyone who has worked on production software knows the journey usually looks like this:

Product requirements
Architecture discussions
API design
Database modeling
Frontend planning
QA strategy
Security review
Technical review
Scope negotiations
Implementation planning

These activities often involve multiple stakeholders with conflicting priorities.

A product manager wants more features.

A backend engineer wants simplicity.

QA wants better testability.

The architect wants scalability.

The CTO worries about long-term maintainability.

Most AI tools merge all these viewpoints into one response.

I wanted to see whether AI agents could behave more like a real engineering organization.

The Idea Behind DevTeam AI

Instead of one intelligent assistant...

I built an AI software company.

Each agent has:

A clearly defined responsibility
Dedicated prompts
Inputs from previous agents
Approval dependencies
Review responsibilities
Conflict resolution capabilities

Rather than producing one giant response, the system produces a complete software delivery package.

Meet the AI Engineering Team

DevTeam AI currently orchestrates 11 specialized AI agents across multiple workflow stages.

1. Orchestrator Agent

Coordinates the entire workflow.

Responsible for:

sequencing stages
dependency validation
workflow state
execution monitoring

2. Product Manager Agent

Transforms a rough product idea into:

Product Requirements Document (PRD)
User stories
Acceptance criteria
MVP scope

3. Solution Architect Agent

Designs the technical foundation.

Outputs include:

System architecture
Component responsibilities
Mermaid architecture diagrams
Technology recommendations

4. Backend Engineer Agent

Designs:

REST APIs
Authentication
Database schema
Business logic
Service structure

5. Frontend Engineer Agent

Plans:

User flows
UI architecture
State management
Component hierarchy
Mobile/Web implementation

6. QA Engineer Agent

Produces:

Test strategy
Test cases
Edge cases
Risk analysis
Acceptance validation

7. CTO Reviewer Agent

One of my favorite agents.

Instead of generating new work...

It challenges existing work.

It looks for:

inconsistent assumptions
scalability issues
security risks
missing requirements
architectural weaknesses

Real engineering teams become stronger because of review—not because everyone agrees.

8. Negotiator Agent

When agents disagree...

Someone has to make a decision.

The Negotiator Agent produces:

decision records
trade-offs
compromise recommendations
rationale

This became one of the most interesting parts of the project because it mimics real technical discussions.

9. Revision Coordinator

After human feedback, this agent:

summarizes requested changes
coordinates revisions
keeps documentation synchronized

10. Code Generator Agent

Once planning has been approved, this agent generates:

starter project
boilerplate
folder structure
implementation scaffold

11. Code Reviewer Agent

Performs a final review of generated code by checking:

maintainability
best practices
potential bugs
consistency

Human Approval Is Not Optional

One decision I made early was that AI should not automatically move to the next stage.

Every stage requires human approval.

The workflow looks like this:

Idea

↓

PRD

↓

Architecture

↓

Backend

↓

Frontend

↓

QA

↓

CTO Review

↓

Negotiation

↓

Revision

↓

Code Generation

↓

Code Review

If something isn't right...

The workflow stops.

The user can:

approve
regenerate
request revisions

Only after approval does the next stage begin.

This small decision makes DevTeam AI feel much closer to a real engineering workflow than a traditional prompt chain.

Why I Chose QwenCloud

When building multi-agent systems, the language model quickly becomes the least interesting part.

The orchestration layer becomes the real challenge.

I wanted a model that allowed me to focus on building agent collaboration rather than spending days adapting SDKs.

QwenCloud was a natural fit.

OpenAI-Compatible API

Integration was surprisingly straightforward.

Because the API is OpenAI-compatible, I didn't need to redesign my backend.

Instead, I focused on:

workflow orchestration
agent prompting
approval gates
state management
conflict resolution

Excellent Structured Outputs

Every agent generates structured artifacts.

Examples include:

Markdown
JSON
Mermaid diagrams
API specifications
PRDs

Consistent formatting was extremely important because later agents depend on previous outputs.

Strong Reasoning

Many stages require analysis rather than generation.

Examples include:

reviewing architecture
identifying contradictions
comparing implementation plans
detecting missing requirements

These reasoning-heavy tasks are where QwenCloud performed particularly well.

Perfect for Multi-Agent Workflows

A multi-agent system might invoke the model dozens of times for one project.

Each call has different objectives.

Some agents create.

Others critique.

Others summarize.

Others negotiate.

QwenCloud handled these role-specific prompts reliably throughout development.

System Architecture

The architecture intentionally keeps the infrastructure simple while making the workflow sophisticated.

                 User
                   │
          Next.js Frontend
                   │
        Server-Sent Events
                   │
             FastAPI Backend
                   │
        Workflow Orchestrator
                   │
     ┌────────────────────────┐
     │ Product Manager        │
     │ Architect              │
     │ Backend                │
     │ Frontend               │
     │ QA                     │
     │ CTO                    │
     │ Negotiator             │
     │ Revision               │
     │ Code Generator         │
     │ Code Reviewer          │
     └────────────────────────┘
                   │
             QwenCloud API
                   │
               SQLite

Technology Stack

Frontend

Next.js
TypeScript
Tailwind CSS

Backend

FastAPI
Python
SQLite
HTTPX

AI

QwenCloud
OpenAI-compatible Chat API

Real-Time Updates

Server-Sent Events (SSE)

Export

ZIP generation
Markdown artifacts

Why I Used Server-Sent Events Instead of WebSockets

Many AI demos use WebSockets.

For DevTeam AI, Server-Sent Events were a better fit.

The application mainly streams:

agent progress
stage updates
logs
completion events

Communication is almost entirely server → client.

SSE provided:

simpler implementation
automatic reconnection
lower overhead
easier deployment behind Nginx

Sometimes the simpler solution is the better engineering choice.

One Feature I'm Particularly Proud Of

One feature I added late in development dramatically improved the user experience.

As more workflow stages were added, the interface became overwhelming.

I redesigned the workspace so that:

only the active workflow expands automatically
completed stages collapse
future stages remain collapsed
users can manually expand any stage when needed

This small UX improvement makes navigating long AI workflows significantly easier.

It reinforces the idea that good AI products are about more than model quality—they're also about thoughtful interaction design.

Challenges I Faced

Prompt Isolation

Early versions produced nearly identical responses.

The Product Manager sounded like the Architect.

The Backend Agent sounded like the QA Agent.

The solution wasn't a better model.

It was better prompt engineering.

Each agent was redesigned to produce unique artifacts with clear responsibilities.

State Management

Unlike a chatbot, DevTeam AI maintains project state across many stages.

The application tracks:

approvals
revisions
dependencies
generated artifacts
conflicts
baseline comparisons

Managing this workflow became one of the most interesting engineering problems in the project.

Designing Productive Disagreements

Perhaps the biggest lesson was this:

Adding more AI agents doesn't automatically improve quality.

Agents need meaningful reasons to interact.

That's why the CTO Reviewer and Negotiator exist.

Without review and disagreement, multi-agent systems quickly become multiple copies of the same assistant.

What the Platform Generates

From a single product idea, DevTeam AI can produce:

Product Requirements Document
Architecture documentation
Mermaid diagrams
API specifications
Database schema
Frontend implementation plan
QA strategy
CTO review report
Negotiation decisions
Revision summaries
Starter project
Code review
Exportable ZIP package

Lessons Learned

This project changed how I think about AI systems.

The future isn't simply making one model smarter.

It's enabling multiple specialized agents to collaborate effectively while keeping humans firmly in control.

The most valuable ideas weren't:

adding more prompts
adding more agents

Instead, they were:

clearer responsibilities
approval workflows
review cycles
negotiation
structured artifacts
transparency

The quality of collaboration mattered far more than the number of agents.

What's Next

Although this was built for the hackathon, I see plenty of room for future improvements:

Persistent long-term memory using vector databases
Retrieval-Augmented Generation (RAG) for organizational knowledge
Support for additional programming languages and frameworks
CI/CD planning agents
DevOps and infrastructure review agents
Security and compliance agents
Team collaboration with shared workspaces
Deployment automation

Final Thoughts

Building DevTeam AI for the QwenCloud Global AI Hackathon was more than an opportunity to experiment with multi-agent AI—it was a chance to rethink how software teams can collaborate with intelligent systems.

QwenCloud provided the reasoning engine behind every specialized agent, while FastAPI, Next.js, and a workflow-driven architecture transformed those individual conversations into a coordinated software delivery process.

Rather than replacing software engineers, DevTeam AI demonstrates how AI can augment each stage of product development: from refining ideas and reviewing architectures to negotiating trade-offs and generating implementation scaffolds. The result isn't a single AI assistant—it is an AI engineering team that collaborates, critiques, revises, and works alongside humans.

As AI continues to evolve, I believe the next generation of developer tools won't revolve around isolated prompts. They will revolve around intelligent, specialized agents working together through structured workflows, with humans guiding the decisions that matter most.

DevTeam AI is my exploration of that future—and QwenCloud made it possible to bring that vision to life during this hackathon.

Project: DevTeam AI
Built for: QwenCloud Global AI Hackathon – Agent Society Track
Tech Stack: QwenCloud, FastAPI, Python, Next.js, TypeScript, Tailwind CSS, SQLite, Server-Sent Events

Protect Your Node.js API: Rate Limiting with Fixed Window, Sliding Window, and Token Bucket

Odunayo Dada — Wed, 10 Sep 2025 09:50:49 +0000

Rate limiting is a strategy for limiting the number of requests a client or user can make to a network, application or API within a specified time (per minute, per second).

Why is Rate Limiting Important?

1. Protects Resources from Misuse

Without rate limiting, a single client (or bot) would be able to make thousands of requests within seconds. This can crash your server, increase expense (if you pay per API call or compute time), and reduce performance for every other user. With rate limiting, you block any single client from taking over your system’s resources.

2. Stops Denial-of-Service (DoS) Attacks

Attackers will normally try to flood servers with traffic in an effort to make the service unavailable. Rate limiting counteracts the impact of such an attack by turning off abusive requests before they consume all of your bandwidth, memory, or CPU. While it’s not a complete solution against volumetric Distributed DoS (DDoS), it’s an essential first line of defense.

3. Enforces Fair Use

In multi-user systems or public APIs, you want everyone to have a fair share of access. Rate limiting ensures that one client doesn’t hog the service at the expense of others. For example, in an API that allows 100 requests per minute, every user gets the same opportunity, preventing abuse and maintaining a consistent experience across the board.

In this article, we’ll look at three (3) popular approaches for implementing rate limiting.

Fixed window
Sliding window
Token bucket / Leaky bucket

1. Fixed Window

The Fixed Window strategy counts requests within a strict time window (like seconds, minutes or hour). When the window resets, the count resets too.

For example, if an API request is limited to 5 requests per minute. The API cannot take more than 5 requests in every minutes and this threshold resets every 1 minute.

import { Request, Response, NextFunction } from 'express';

// Configuration
const WINDOW_SIZE_IN_MS = 60_000; // 1 minute
const MAX_REQUESTS = 5; // per IP per window

// Store: { ip -> { count, windowStart } }
type Entry = { count: number; windowStart: number };
const store = new Map<string, Entry>();

export function fixedWindowLimiter(req: Request, res: Response, next: NextFunction) {
  const ip = req.ip || req.connection.remoteAddress || 'unknown';
  const now = Date.now();

  let entry = store.get(ip);

  if (!entry) {
    // First request for this IP
    store.set(ip, { count: 1, windowStart: now });
    return next();
  }

  // If current window expired → reset counter
  if (now - entry.windowStart >= WINDOW_SIZE_IN_MS) {
    entry = { count: 1, windowStart: now };
    store.set(ip, entry);
    return next();
  }

  // Still inside the window
  entry.count++;

  if (entry.count > MAX_REQUESTS) {
    const retryAfter = Math.ceil((entry.windowStart + WINDOW_SIZE_IN_MS - now) / 1000);

    res.setHeader('Retry-After', retryAfter.toString());
    return res.status(429).json({
      success: false,
      message: `Too many requests. Try again in ${retryAfter}s`
    });
  }

  return next();
}

2. Sliding window

Unlike fixed window rate limiting (which resets counters at regular intervals), the sliding window method continuously evaluates requests based on a moving time window.

For example, an API with a limit of 100 requests per minute:

If a user sends 90 requests in the last 50 seconds, they can only send 10 more in the next 10 seconds.

Every second, the window slides forward, dropping old requests and including new ones.

import { Request, Response, NextFunction } from 'express';
import Redis from 'ioredis';

const redis = new Redis();
const WINDOW_SIZE = 60; // seconds
const MAX_REQUESTS = 100;

export async function slidingWindowLimiter(req: Request, res: Response, next: NextFunction) {
  const key = `sliding:${req.ip}`;
  const now = Date.now();

  const windowStart = now - WINDOW_SIZE * 1000;

  // Remove old requests outside window
  await redis.zremrangebyscore(key, 0, windowStart);

  // Count requests in window
  const count = await redis.zcard(key);

  if (count >= MAX_REQUESTS) {
    res.setHeader('Retry-After', String(WINDOW_SIZE));
    return res.status(429).json({ message: 'Too many requests' });
  }

  // Add current request timestamp
  await redis.zadd(key, now, now.toString());
  await redis.expire(key, WINDOW_SIZE);

  next();
}

3. Token bucket / Leaky bucket

Allows bursts up to a capacity; then refills gradually. It enforces a strict, constant rate of processing, smoothing out traffic.

Here is how it works:

Requests are added to a queue (the bucket).
The bucket leaks at a fixed rate (requests are processed one at a time at. regular intervals).
If the bucket overflows (too many requests), excess requests are dropped.

import { Request, Response, NextFunction } from 'express';
import { RateLimiterRedis } from 'rate-limiter-flexible';
import Redis from 'ioredis';

const redis = new Redis();

const limiter = new RateLimiterRedis({
  storeClient: redis,
  keyPrefix: 'bucket',
  points: 150, // bucket capacity
  duration: 60, // refill window (60s → 150 tokens per minute)
  execEvenly: true // smooth out evenly
});

export async function tokenBucketLimiter(req: Request, res: Response, next: NextFunction) {
  try {
    await limiter.consume(req.ip, 1);
    next();
  } catch (rejRes) {
    const retrySecs = Math.ceil(rejRes.msBeforeNext / 1000) || 1;
    res.set('Retry-After', String(retrySecs));
    res.status(429).json({ message: 'Too many requests, retry later' });
  }
}

Rate limiting is one of the simplest yet most effective tools for protecting your APIs. Whether you choose fixed window, sliding window or token bucket, the right strategy depends on your app’s traffic patterns and scaling needs.

Fixed Window :easy to implement, good for small projects.
Sliding Window: fairer distribution, great for APIs with steady load.
Token Bucket / Leaky Bucket: best for production, balances bursts and consistency.

Conclusion

Rate limiting is more than just a performance trick — it’s a safeguard against abuse, downtime, and unfair usage. We’ve explored three powerful strategies: Fixed Window, Sliding Window, and Token/Leaky Bucket.

But this is just the beginning. In my YouTube video, I’ll show you how to set up real rate limiting in a Node.js app, step by step, with live coding examples and best practices to keep your APIs secure and efficient.

👉 Watch the full video here

Offline-First Mobile App Architecture: Syncing, Caching, and Conflict Resolution

Odunayo Dada — Wed, 16 Jul 2025 14:46:39 +0000

In many parts of the world, network connectivity is unreliable. Even in major cities, mobile users frequently lose signal while commuting, entering buildings, or during power outages.

If your app stops working the moment internet access is lost, you’re building for ideal conditions , not the real world.

Offline-First Design
An offline-first application is designed to work seamlessly with or without the internet. It uses local storage as the primary data source and synchronizes changes with a remote server once connectivity is available.

This approach ensures your users can:

Continue working uninterrupted
Avoid data loss
Trust your app to be available at all times

Real-World Use Case: Field Data Collection in Rural Areas
I will share my approach to building a field data collection app for areas with poor internet. I had to ensure that:

User input was never lost
Data could be submitted at any time — whether online or not
The app could sync data automatically once network resumed.

Here’s how I implemented this using Room, WorkManager, and NetworkCallback in Android.

Persisting Data Locally with Room
Whenever a user captures data (e.g., survey responses or inspection records), it is saved in a local SQLite database using Room.

@Entity(tableName = "field_data")
data class FieldDataEntity(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val formName: String,
    val content: String,
    val isSynced: Boolean = false,
    val timestamp: Long = System.currentTimeMillis()
)

@Dao
interface FieldDataDao {
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(fieldData: FieldDataEntity)

    @Query("SELECT * FROM field_data WHERE isSynced = 0")
    suspend fun getUnsyncedData(): List<FieldDataEntity>

    @Query("UPDATE field_data SET isSynced = 1 WHERE id = :id")
    suspend fun markAsSynced(id: String)
}

Syncing with the Server Using WorkManager:

Once the device regains network access, a background worker is triggered to sync all unsynced data in the room database.

class DataSyncWorker(
    context: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(context, workerParams) {

    private val dao = AppDatabase.getInstance(context).fieldDataDao()
    private val api = ApiService.create() 

    override suspend fun doWork(): Result {
        val unsynced = dao.getUnsyncedData()
        for (item in unsynced) {
            try {
                val response = api.uploadFieldData(item)
                if (response.isSuccessful) {
                    dao.markAsSynced(item.id)
                    sendInAppNotification("Data synced: ${item.formName}")
                }
            } catch (e: Exception) {
                // Retry later
            }
        }
        return Result.success()
    }

    private fun sendInAppNotification(message: String) {
        // Optionally notify user
    }
}

Detecting Network Availability

Used Connectivity Manager to detect when the device regains internet access and enqueue the sync worker.

fun registerNetworkCallback(context: Context) {
    val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val request = NetworkRequest.Builder().addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET).build()

    connectivityManager.registerNetworkCallback(request, object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network) {
            enqueueSyncWorker(context)
        }
    })
}

fun enqueueSyncWorker(context: Context) {
    val request = OneTimeWorkRequestBuilder<DataSyncWorker>()
        .setConstraints(Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build())
        .build()

    WorkManager.getInstance(context).enqueue(request)
}

Conflict Resolution Strategy
In my case, conflicts were minimal because users didn’t edit the same record from multiple devices. However, in more collaborative apps, you can handle conflicts by:

Last-write-wins: simplest, but risky
Merge strategies: combine changes from client + server
User-assisted: notify user to choose the correct version
User Feedback: In-App and Push Notifications

Once sync completes, we notify the user via:

In-app snackbar/toast (if app is foregrounded)
Push notification using a local notification

Key Lessons:
Prioritize local-first design when working in regions with poor internet
Always queue unsynced data instead of blocking the user
Use WorkManager + Room + NetworkCallback for resilient, testable sync logic.
Don’t forget about conflict resolution — design for edge cases

Have you built offline-first apps before? I’d love to hear how you approached syncing and caching in the comments.