DEV Community: Njabulo Majozi

Building Prude

Njabulo Majozi — Wed, 17 Sep 2025 08:30:00 +0000

Hey everyone! 👋

I've been working on something pretty cool that I'm excited to share with you all. It's called Prude - essentially, it's an AI-powered app that helps address one of the biggest problems we all face: being overwhelmed by emails, messages, and decisions.

You know that feeling when you open your inbox and there are 50+ emails, and you don't even know where to start? Or when you're getting pinged on Slack, WhatsApp, and Gmail all at once and you're drowning in notifications? That's exactly what this app tackles.

Here's what it does:

Smart Organisation: It automatically reads through all your messages and determines what requires a reply, a calendar event, or a task.
AI Insights: Instead of just showing you messages, it gives you a daily "digest" that summarises what needs your attention and suggests actions
Decision Support: For bigger decisions, it connects the dots between your conversations, projects, and people to give you a better context
One Dashboard: Instead of jumping between Gmail, Slack, Teams, etc., you see everything that matters in one place

Think of it like having a really smart assistant who reads all your messages and then gives you a brief: "Here are the 3 things that actually need your attention today, here's why they matter, and here's what you should probably do about them."

It's designed for professionals and busy people who are tired of feeling like they're always behind on their communications. I'm really proud of how it's turning out!

Still in the building phase, sign up for updates at https://prude.onglx.ai/

Would love to hear your thoughts!

Building OpenAI API Compatibility with AWS Bedrock

Njabulo Majozi — Tue, 16 Sep 2025 08:30:00 +0000

The Problem

Many developers already rely on the OpenAI Chat Completions API. But what if your platform needs vendor independence and cost optimisation by running inference on AWS Bedrock (or GCP Vertex AI) — while still giving developers a drop-in OpenAI-compatible API?

That was the challenge I faced when building OnglX deploy

Context & Architectural Decisions

I wanted developers to adopt OnglX deploy with zero code changes. That meant:

Support the OpenAI API format as-is.
Run inference on Bedrock, not OpenAI.
Keep things extensible for multi-cloud (AWS + GCP).
Secure it with API keys and serverless IAM best practices.

The architectural bet: a protocol translation layer that accepts OpenAI-style requests and translates them to provider-specific formats — then back again.

The Specific Challenge

Bedrock (and other providers) models don’t speak the same “language.”

Claude requires separate handling of system prompts.
Llama expects a continuation-style prompt.
Titan only supports inputText.

Even token usage reporting and error messages differ.

So: how do you unify all that while still looking and behaving like OpenAI?

Solution Approaches I Considered

Provider-Specific Endpoints
- ✅ Cleaner per model family
- ❌ Breaks drop-in compatibility
Unified Translation Layer (Chosen)
- ✅ Works with OpenAI clients directly
- ✅ Extensible for multi-cloud
- ❌ More translation logic & testing required

Trade-Offs

Compatibility vs Performance → We favoured compatibility. Cold starts and translation overhead are acceptable since inference latency dominates anyway.
Multi-cloud support vs Simplicity → Added complexity, but ensures portability and avoids lock-in.
Serverless vs Dedicated Infra → Serverless chosen for cost efficiency and scaling, at the expense of slightly higher cold start latency.

Implementation Details

Request Translation Example

System messages in OpenAI can appear anywhere, but Claude needs them to be separate:

system_messages = [m for m in messages if m['role'] == 'system']
conversation_messages = [m for m in messages if m['role'] != 'system']

payload = {
    "messages": conversation_messages,
    "system": "\\n".join(m["content"] for m in system_messages)
}

Model-specific handling:

if self.model_id.startswith("anthropic."):
    # Claude format
elif self.model_id.startswith("meta.llama"):
    # Llama continuation format
elif self.model_id.startswith("amazon.titan"):
    # Titan inputText format

Response Translation Example

Unifying token usage:

if self.model_id.startswith("anthropic."):
    usage = {
        "prompt_tokens": response["usage"]["input_tokens"],
        "completion_tokens": response["usage"]["output_tokens"],
        "total_tokens": response["usage"]["input_tokens"] + response["usage"]["output_tokens"]
    }

Error mapping to OpenAI style:

except ClientError as e:
    if e.response["Error"]["Code"] == "ValidationException":
        raise ValueError("Invalid request or model")

Infrastructure Setup

API Gateway v2 (CORS + auth)
DynamoDB (API key management with TTL)
AWS Lambda (Python 3.12, 512MB, 30s timeout)
Amazon Bedrock (AI Models offering)
IAM (least-privilege Bedrock + DynamoDB access)

Terraform example:

resource "aws_lambda_function" "api" {
  runtime     = "python3.12"
  timeout     = 30
  memory_size = 512
}

Results & Lessons Learned

Cold starts aren’t a big issue since inference latency dominates.
512MB Lambda was the sweet spot — lower failures, higher waste costs.
Model prefix detection was a clean way to handle provider quirks.
Error translation was critical for dev UX: users expect OpenAI-like errors.

Most importantly, developers could point their OpenAI clients to our endpoint without code changes.

When to Apply This Approach

You need drop-in OpenAI API compatibility but want to use another provider (AWS/GCP/self-hosted).
You’re building multi-cloud AI infra and need consistent APIs.
You prioritise developer adoption and compatibility over raw performance.

Call to Action

If you’re building AI infra and want OpenAI compatibility without vendor lock-in, this translation-layer pattern is worth considering.

👉 Explore OnglX Deploy’s OpenAI-compatible API Docs and try deploying your own OpenAI-compatible API on AWS in minutes.

001 - This is OnglX deploy

Njabulo Majozi — Wed, 10 Sep 2025 08:30:00 +0000

Hey everyone! 👋

Super excited to share something I’ve been working on: OnglX Deploy 🚀

It’s basically a tool that helps you take control of AI infrastructure without the crazy costs or headaches of managing it yourself.

Here’s the problem: if you’ve ever tried running your own AI workloads, you know how painful it can be. Either you’re stuck paying high API costs to providers, or you’re lost in the weeds setting up cloud infra, Terraform, permissions, scaling, etc. It’s a nightmare.

That’s exactly what OnglX Deploy fixes.

Here’s what it does:

Your Cloud, Your Rules: Deploy AI APIs directly to your own AWS (and soon GCP) accounts. No vendor lock-in, no data privacy worries.
OpenAI-Compatible: You get the same API interface you already use, but running on your own infra.
Big Savings: Cut costs by 25–65% by skipping middleman markups and paying your cloud provider directly.
Developer-Friendly: One simple CLI command sets everything up—no endless configs, no hidden magic.
Extras Built-In: It even ships with an Open WebUI so you can interact with your models from day one.

Think of it like Vercel for AI, but instead of someone else’s servers, it’s your cloud. One command and you’ve got a fully running inference API on AWS.

I just shipped v0.1.43, our first production-ready release 🎉.

That means you can already:

Spin up an API in AWS with onglx-deploy init → onglx-deploy deploy
Run Bedrock models behind an OpenAI-compatible endpoint
Manage everything with a lightweight Go-based CLI that installs via
- Homebrew
  - brew tap onglx/homebrew-deploy-cli
  - brew install onglx-deploy
- npm
  - npm install -g @onglx/deploy-cli

I wanted the developer experience to feel effortless, but under the hood, it’s built on a strong foundation:

CLI Layer: A Go + Cobra-based CLI, a single static binary with zero dependencies.
Orchestration Layer: OpenTofu runner coordinating deployments, rollbacks, and state.
Infrastructure Layer: Embedded OpenTofu modules for AWS (and soon GCP).
Build System: Monorepo powered by pnpm + Turborepo for speed and consistency.
IaC: Everything defined in OpenTofu, fully embedded inside the CLI — no external module wrangling.
Automated Distribution: Binaries cross-compiled with GoReleaser and shipped across Homebrew and npm.

All that, so the experience for you is just one lightweight command.

Getting to this release wasn’t easy. A few big hurdles I solved along the way:

Distribution from a Private Monorepo: Package managers can’t pull from private repos, so I built public “release mirrors” (onglx/homebrew-deploy-cli, onglx/npm-deploy-cli) that automatically publishes binaries after every tag.
Platform-Specific Installs: Needed a way for Homebrew/npm to auto-detect OS + architecture and fetch the right binary. Custom install scripts solved it.
Complex Release Automation: Manual releases were painful, so I wired up GoReleaser + GitHub Actions to fully automate versioning, builds, and publishing.

The result? A smooth, one-command install across macOS, Linux, and Windows.

Still early days, but here’s the roadmap:

Next: OpenAI-compatible endpoint with GCP (Vertex AI + Cloud Functions)
Soon: streaming responses, custom domains + SSL, and better secrets management
Long-term: Multi-cloud, Azure support, and eventually expanding beyond inference into compute, storage, and databases.

If you’ve ever felt locked into someone else’s AI infra or sick of watching your API bill explode, this is for you.

Would love your feedback—and if you want to try it, docs are live here 👉 https://deploy.onglx.io

KIRO - The AI IDE that works?

Njabulo Majozi — Thu, 24 Jul 2025 07:00:00 +0000

Introduction

If you're a developer like me, you've probably experimented with AI coding tools like Cursor or Windsurf. And let's be honest, while they promise magic, they often deliver 'hallucinations' – losing context, butchering project structure, or completely misunderstanding your tech stack. It's frustrating, time-consuming, and frankly, defeats the purpose of 'assistance.'

That's why when I stumbled upon Kiro, a new AI IDE from AWS, my ears perked up. It's a bold promise? To bring structure to AI coding through a concept called spec-driven development. This isn't just another tool; it might be the breakthrough we've been waiting for.

Why It's On My Radar

Problem Solved: Taming the AI Beast

Kiro directly confronts the AI Hallucination problem. Instead of refining prompts endlessly, Kiro uses your detailed specifications to ensure the AI stays perfectly aligned with your project's vision, architecture, and existing codebase. Think of it as giving the AI a blueprint, not just a vague idea.

Core Concept: Code with the Blueprint

Forget prompting in the dark. Kiro's "Code with Spec" workflow is where the magic happens.

Requirements: You define what needs to be built.
Design: You detail how – architecture, data models, error handling, even testing strategies. This is where you establish the guardrails.
Tasks: Break down the work into actionable steps.

Only after you've approved these detailed specs does the AI generate code for each task, directly referencing your blueprint. This structured approach is a game-changer for consistency and accuracy.

Potential Impact: Beyond Just Code

Reducing AI hallucinations isn't just about faster coding; it's about shifting our focus. Imagine less time debugging AI-generated messes and more time on high-level problem-solving and innovative design. Kiro's approach could lead to:

Higher Code Quality: AI adheres to established designs.
Improved Maintainability: Code is generated with context and structure.
Faster Feature Delivery: Less rework, more production.

Industry Context: AWS's Secret Weapon?

Kiro occupies a unique niche. While Cursor and Windsurf are strong contenders, Kiro's AWS parentage is a significant differentiator. We could see deep integrations with AWS cloud services, potentially making it the go-to IDE for developers heavily invested in the AWS ecosystem. The buzz is real: a waiting list for access confirms its high demand.

Personal Insight & Experience

Setup & First Impressions

As a VS Code fork, setup was a breeze – instantly familiar, and yes, you can export your existing extensions. My initial impressions were largely positive. The "agent hooks" and "agent steering" give a sense of control previously missing. The main adjustment? The time. Going from ideation to final results isn't instant gratification; it requires that upfront spec work. But it's a worthwhile investment.

Pros & Cons

Pros:
- Unmatched Accuracy: The spec-driven approach dramatically reduces hallucinations.
- Detailed Workflow: Guides you through requirements and design, improving overall project planning.
- VS Code Familiarity: Low UI learning curve for existing VS Code users.
- AWS Backing: Potential for powerful cloud integrations.
Cons:
- Time Investment: The initial spec phase takes more time than quick prompting.
- Mindset Shift: Requires developers to embrace a more structured AI-assisted workflow.

Use Cases & Applicability

I see Kiro shining brightest for:

Team Projects: Ensuring consistent AI-generated code across a team, aligning with shared specs.
Complex Features: Tackling intricate features where context and structure are paramount.
Domain Alignment: Keeping the AI updated with current domain knowledge as features evolve.

The big learning curve isn't the UI, but getting developers to think differently about AI-assisted development – less "write me code," more "build this exactly according to my blueprint".

Broader Implications & Future Outlook

Kiro isn't just a tool; it's a statement. It's bringing back core software development best practices (planning, design, documentation) to the forefront of AI-assisted coding. This aligns perfectly with trends towards more robust, reproducible, and maintainable codebases.

I believe Kiro is poised to become a critical component in the development cycle, especially as AI continues to mature. It's the bridge between raw AI power and structured, enterprise-grade software development.

Conclusion

Kiro promises what many AI IDEs haven't delivered: reliable, context-aware code generation through a genius spec-driven approach. It's a trial that's showing immense promise for how we build software with AI. As Kiro puts it, it "helps you do your best work by bringing structure to AI coding with spec-driven development". I'm watching this space closely.

Have you used Kiro? What are your thoughts or experiences? Feel free to connect with me

Data Visibility: A Mongoose Middleware Case Study

Njabulo Majozi — Tue, 15 Jul 2025 07:18:23 +0000

Situation: Unapproved orders displayed

As part of a recent feature development, the objective was to empower procurement officers to initiate orders on behalf of various departments. A critical requirement was to prevent these orders from appearing on departmental dashboards until formally approved by the respective department manager.

Tasks: Architectural decision

Option 1: Decentralised Filtering: Modify every single query that retrieves orders across the application. This approach presented a significant risk of identifying and changing potentially dozens or hundreds of queries that would be time-consuming; the likelihood of missing a critical query or introducing subtle bugs was significant, and leading to future changes to data visibility logic requiring similar widespread modifications.
Option 2: Centralised Interception (Chosen): Leverage Mongoose middleware to intercept all data retrieval operations. This promised a more robust and maintainable solution by centralising the logic for filtering unapproved orders at the data layer.

Actions: Filter out unapproved orders

To facilitate the filtering, I needed a mechanism to mark orders that were pending approval explicitly. We added a new field, activeAction, to our orderSchema

The core of our solution lies in a pre-find middleware hook. This hook executes automatically before any find operation (including findOne, findById, etc.) on the Order model.

Results:

Clean and Accurate Dashboards: Only display approved and relevant order data and eliminating confusion.
Centralised Logic: The core filtering logic resides in a single, well-defined location within the orderSchema, making it easy to understand, debug, and modify.
Reduced Development Risk: We completely avoided the arduous and error-prone task of modifying numerous find queries throughout the application.
Scalable Pattern: This approach provides a reusable pattern for managing data visibility based on internal states, applicable to various entities beyond orders.

How do you use MongoDB middlewares? Share in the comments!

Resolving Unexpected Git Hook Changes

Njabulo Majozi — Tue, 08 Jul 2025 13:02:38 +0000

Situation: Unwanted file modifications

Recently, after merging a branch, my Pull Request unexpectedly showed numerous file changes that had minor auto-modifications (e.g., “Hello” to 'Hello') due to an active Git hook. These changes weren't part of my task, leading to a noisy and unclear PR.

Task: Isolate & Maintain Focus

Needed to:

Revert unrelated changes
Keep the PR diff focused on the current task I was working on

Actions: Step-by-step approach

Results: Clean PR

Restored the affected files to their original state
My PR was clean and contained only the relevant task changes

What are your go-to Git commands for managing tricky situations? Share in the comments!

NextAuth.js over Clerk

Njabulo Majozi — Wed, 24 Apr 2024 09:30:00 +0000

The prior article examined how Clerk may simplify user authentication for Next.js applications. Clerk provides a handy managed service option, but it's wise to weigh your options before making a choice. Today, we'll examine and contrast Clerk and NextAuth.js, two more well-liked authentication libraries for Next.js, to help you decide which is ideal for your project.

Why Next Auth instead of Clerk?

Control and Flexibility
- Self-Hosted vs. Managed Service: NextAuth enables you to fully self-host the authentication flow, giving you more control over user data and security procedures. Conversely, Clerk is a managed service, meaning that its servers hold your user data.
- Customization: NextAuth provides more flexibility, such as customizing the authentication procedure using callbacks, which are flexible enough to adjust to your unique requirements. The clerk's experience is more preconfigured, but you can still get some flexibility using webhooks
Community and Support:
- Larger Community: NextAuth benefits from a larger and more active developer community. You'll find more resources, tutorials, and support online if you encounter issues. Clerk, a relatively newer service, might have a smaller support pool.
- Integration Flexibility: NextAuth integrates seamlessly with various social providers and other authentication services. You can leverage existing libraries and solutions within your development stack.
Cost:
- Open-Source vs. Freemium: NextAuth is an open-source library with no direct cost for its basic functionalities. Clerk offers a free tier with limitations and paid plans for additional features and user management capabilities.

Setting Up Next Auth in Next.js

Install NextAuth
```
npm install next-auth
```

Configure NextAuth

Server

NextAuth.js will handle all queries to /api/auth/* (signIn, callback, signOut, etc.) automatically.

import NextAuth from "next-auth";
import GoogleProvider from 'next-auth/providers/google';

export const authOptions = {
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET
    })
  ]
}

export default NextAuth(authOptions)

Client

Provider

import { SessionProvider } from "next-auth/react"

export default function App({
  Component, pageProps: { session, ...pageProps }
}) {
  return (
    <SessionProvider session={session}>
      <Component {...pageProps}/>
    </SessionProvider>
  )
}

Consumer

import { useSession, signIn, signOut } from "next-auth/react"

export default function Component() {
  const { data: session } = useSession()
  if(session) {
    return <>
      Signed in as {session.user.email} <br/>
      <button onClick={() => signOut()}>Sign out</button>
    </>
  }
  return <>
    Not signed in <br/>
    <button onClick={() => signIn()}>Sign in</button>
  </>
}

NextAuth.js is a compelling alternative to Clerk, offering developers greater control, flexibility, and cost-effectiveness. Its open-source nature, extensive community support, and seamless integration capabilities make it an attractive choice for Next.js applications. Whether you're looking for a self-hosted solution or prefer a managed service, NextAuth.js provides a robust and customizable authentication framework to meet your project's needs.

Auth with Clerk

Njabulo Majozi — Wed, 17 Apr 2024 15:00:00 +0000

It can be challenging to set up user authentication for web apps. Creating login flows, safely hashing passwords, controlling sessions, and integrating social logins are all part of the traditional process, guaranteeing optimal security. Luckily, there's a more effective method.

In a recent project, I investigated Clerk, a powerful solution for simplifying user authentication in Next.js applications. Let's explore why Clerk has become my preferred option and how it streamlines development.

Why Clerk Auth?

Forget about the time-consuming back-end configurations. With a wide range of capabilities aimed at improving the security and usability of your application, Clerk gives you the power to:

Embeddable UIs: Say goodbye to custom login forms! Clerk provides pre-built UI components like SignIn, SignUp, UserButton, and UserProfile that seamlessly integrate into your Next.js and other frontend frameworks supported by Clerk.
Authentication: Clerk offers a comprehensive set of authentication options, including:
- Multifactor Authentication (MFA): Add an extra layer of security with MFA to protect user accounts.
- Session Management: Includes maximum lifetime, inactivity timeout, and multi-session apps.
- Social Sign-On: Make logging into well-known social media sites like Google, Microsoft, and others easier.
- Email/SMS One-Time Passcodes (OTPs): Send verification codes via email or SMS to offer easy log-in.
- Magic Links: Simplify the login procedure by using links that, when clicked, provide access.
Flexibility: Integrate Clerk seamlessly with your preferred development stack:
- Frontend SDKs: Integrate Clerk with popular frontend frameworks like Next.js, React, React Native/Expo, and more.
- Backend SDKs: Leverage Clerk's backend SDKs for Node.js, Go, and other languages.
More
- Admin Dashboard: Manage user authentication and access control from a centralized, secure dashboard.
- Integrations: Expand your application's functionality by integrating Clerk with other services, such as Firebase, Supabase, and more.
- Webhooks: Stay informed about user activities through real-time notifications.
- Bot Detection: Clerk helps mitigate brute-force attacks with built-in bot detection mechanisms.
- B2B Suite: Build secure and scalable authentication experiences for your business-to-business applications.

Setting Up Clerk Auth in Next.js

Install Clerk
```
npm install @clerk/nextjs
```

Configure Clerk

By adding the following environments in .env.local

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=<your clerk public key>
CLERK_SECRET_KEY=<your clerk secret key>

ClerkProvider

Provide authentication context to the rest of the application by wrapping around an app, such as root layout.tsx

...
import { ClerkProvider } from '@clerk/nextjs';

...

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}): JSX.Element {
  return (
    <ClerkProvider>
      <html lang="en">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  );
}

Middleware

Clerk's middleware functionality in the Next.js middleware file handles authentication, protects routes, and ensures that only authenticated users can access them.

import { authMiddleware } from "@clerk/nextjs";

export default authMiddleware({});

export const config = {
  matcher: [ 
    "/((?!.+\\.[\\w]+$|_next).*)",
    "/(api|trpc)(.*)"
  ]
};

Configure type of auth strategy through a dashboard

Clerk supports authentication strategies such as password login, social authentication (allowing users to log in using their Google, GitHub, or other social network accounts. This feature enhances the user experience by providing a familiar login process), and more. To those auth strategies, you need to configure it in your Clerk dashboard.

Additionally, Clerk supports various authentication strategies, such as password login and social authentication, which can be configured seamlessly through the Clerk dashboard.

My journey with Clerk Auth has been nothing short of transformative. It's revolutionized how I approach user authentication, offering unparalleled simplicity without compromising security. Clerk isn't just a tool – it's a game-changer for Next.js development.

Facebook Introduces Meta AI in WhatsApp

Njabulo Majozi — Mon, 15 Apr 2024 07:00:00 +0000

Facebook has integrated Meta AI, powered by the Llama model, into WhatsApp, introducing an AI chatbot to enhance user interactions. This integration enables users to engage with AI assistants, offering a new dimension to their messaging experience.

While you can add Meta AI to group chats, it functions independently. It respects your privacy by not accessing your private conversations, and it doesn't analyze the history of the group chat before joining. It's important to note that this feature is currently in a limited rollout.

Currently, Meta AI offers basic functionalities. However, the future is promising. We can expect Meta AI to evolve into a powerful tool that can understand and participate in your conversations. This could include features like generating summaries of conversations, analyzing sentiment, or even helping you draft messages.

NB: There's more reads at My Blog Site

AI powered PostgreSQL Test Data Generation Tool (Cloudflare AI Challenge)

Njabulo Majozi — Sun, 14 Apr 2024 16:07:56 +0000

This is a submission for the Cloudflare AI Challenge.

What I Built

I built a serverless application using Cloudflare Workers and Hono, a lightweight web framework for Cloudflare Workers. The application is designed to generate steps for inserting random data into a PostgreSQL database and then convert those steps into SQL queries. This is achieved by leveraging Cloudflare's AI models to understand and generate natural language instructions, which are then converted into SQL commands.

Demo

My Code

REPO

The core functionality lies in the generate-data endpoint:

Extracting Schema: It retrieves the user-provided schema definition from the request body.
Initializing AI Models: It creates instances of two AI models:
- @hf/thebloke/deepseek-coder-6.7b-base-awq: This model understands natural language instructions and generates the steps in human-readable format.
- @cf/defog/sqlcoder-7b-2: This model takes the steps and schema definition, translating them into corresponding SQL code.
Prompting the Models
- The first model receives a prompt explaining the desired outcome and the provided schema.
- The second model receives the generated steps and the schema definition, combining the information for SQL generation.
Returning Data: The function returns a JSON response containing the generated steps and the corresponding SQL code.

Journey

Building this application involved several steps, from understanding the requirements to implementing the solution.

Understanding Cloudflare Workers: I started by researching how to use Cloudflare Workers and Hono for serverless applications.
Exploring AI Models: I explored Cloudflare's AI models to find one that could generate natural language instructions based on a given schema.
Integration and Orchestration: I implemented the logic to process the generated instructions and convert them into SQL queries.

Multiple Models and/or Triple Task Types

Multiple Models

The application demonstrates multiple AI models from Cloudflare's AI platform. The first model, @hf/thebloke/deepseek-coder-6.7b-base-awq, generates natural language steps for data insertion. The second model, @cf/defog/sqlcoder-7b-2, converts these steps into SQL queries. This showcases the flexibility and power of Cloudflare's AI platform in generating complex content based on simple prompts.
Triple Task Types

The application performs three main tasks:

Data Generation: It generates natural language steps for inserting data into a PostgreSQL database based on a given schema.
SQL Query Generation: It converts the generated steps into SQL queries.
API Endpoint: It exposes an API endpoint (/generate-data) that accepts a schema and returns the generated steps and SQL queries.

Challenges:
- Coordinating communication between the two LLMs.
- Prompts designs.
- Ensuring the generated SQL scripts are functional and adhere to the DDL and data constraints.

What I'm Proud Of

The ability to combine multiple LLMs to achieve a complex task like test data generation for databases.

What's Next

Experiment with different LLM combinations for improved performance.
Integrate user feedback to refine the generated test data scripts.
Local LLMs integration
Use LangChain SQL agent to retrieve database DDLs