DEV Community: Yuva Kunaal

I built an AI agent skill that turns article concepts into weird, hand-drawn illustrations

Yuva Kunaal — Fri, 17 Jul 2026 10:03:03 +0000

Every technical article eventually hits the same wall: you've written something you're proud of, and now you need images. So you reach for the usual suspects — a stock photo of someone pointing at a whiteboard, a generic gradient banner, maybe a flowchart that looks like every other flowchart on the internet. Nobody remembers any of it.

I wanted the opposite of that. I wanted illustrations that actually say something — that take a judgment or a process buried in a paragraph and turn it into one small, strange, memorable picture.

So I built Kunaal's Illustrations — an AI agent skill that does exactly this.

What it actually is

It's not a prompt. It's not a PPT template. It's a skill you drop into your AI agent that teaches it a very specific way of thinking about illustrations.

Instead of "add a picture here," the agent learns to ask: what's the one cognitive action in this paragraph worth drawing? Then it draws that — in a consistent hand-drawn style, with a recurring cast of characters who are genuinely part of the scene rather than decoration standing in the corner.

Here's the boy saying hi. He shows up a lot.

The core idea: draw the concept, not decoration

This is the whole philosophy in one line: the character has to do the work.

If you could remove the character from the picture and the picture would still make sense, then the character was just decoration — and that's a fail. Every illustration has to hang on a single idea, and a person (or occasionally a very unbothered cat) has to physically act it out.

A few examples that came out of it:

"Too many tasks, zero focus." A boy hopping between floating paper islands, exhausted, never actually landing on any of them.

"Messy thought becomes structure." A girl at her desk with a tangled cloud of thoughts above her head, and clean structured lines forming on the page under her pen.

"Preparation, meet reality." A boy throwing his papers in the air because his grades didn't match the effort.

None of these needed a caption to land. That's the point.

The visual DNA

The style is deliberately restrained so everything looks like it came from the same hand:

Pure white background — no paper texture, no shadows, no gradients.
Black hand-drawn line art with thin, slightly wobbly lines.
Lots of white space — the subject only fills about 40–60% of the frame.
Sparse red / orange / blue handwritten labels, and only when a label genuinely helps.
One image = one idea. No cramming a whole chapter into a single picture.

The two default characters are a boy (short black hair, light blue t-shirt, grey pants) and a girl (shoulder-length black hair, yellow t-shirt, dark grey pants). They're not mascots — they're the workers doing the absurd job the concept requires.

Who it's for (and who it isn't)

It's a great fit if you:

write English articles, blogs, or Notion docs and want in-text illustrations
create methodology, knowledge, or AI-workflow content
like turning abstract judgments into concrete, slightly weird metaphors
want a reusable visual language that stays consistent across everything you publish

It's not for you if you want polished brand key visuals, corporate flat illustrations, dense architecture diagrams, cutesy emoji-style mascots, or strictly editable vector source files. That's a different tool.

How it works under the hood

The skill runs a small, opinionated workflow rather than firing off a single image:

Digest the text — read the article and find the cognitive anchors: the core judgments, the turning points, the before/after moments.
Plan first, draw later — output a shot list of 4–8 images. For each one it writes the paragraph it follows, the theme, the core meaning, the structure type, what the character is doing, and suggested labels.
Generate one image at a time — never stitched together, each carrying exactly one idea.
QA against a checklist — is the background clean white? Is there enough white space? Is the character actually doing something? Does it accidentally look like a PowerPoint slide? If it fails, regenerate.
Save and report — final PNGs land in a Generated/ folder, with a note on which images are solid and which are optional.

You can also stop it at step 2 if you just want the illustration plan and want to draw things yourself.

Trying it out

The fastest path (the way I use it):

Open Antigravity and select the Gemini 3.1 Pro (High) model.
Paste the repo's .git URL into the chat and tell the agent to clone/install it.
Start prompting.

Or install it manually into your agent's skills directory:

git clone https://github.com/Yuvakunaal/kunaal-illustrations.git
cd kunaal-illustrations
cp -R ./kunaals-illustrations ~/.gemini/config/skills/

Then the prompts are refreshingly simple. Whole-article mode:

Use $kunaals-illustrations to generate 4 bizarre in-text illustrations for the article below.
Requirements: wide composition, pure white background, black hand-drawn line art,
sparse red/orange/blue English handwritten annotations.

<paste your article>

Planning-only mode:

Use $kunaals-illustrations, do not generate images yet.
Analyze where this article is worth illustrating and output a shot list of about 5 images.

<paste your article>

Single concept:

Use $kunaals-illustrations to generate an in-text illustration for
"Trust is not shouted out, but built piece by piece with evidence."
Make it bizarre but clean, and the boy must carry the core action.

A couple of things I've learned using it: keep the label text short (the fewer words in the image, the more stable the output), and let each picture stay about one idea. AI image models will still occasionally hallucinate a typo or drift on style — when that happens, cutting the number of labels and regenerating usually fixes it.

A note on licensing

The repo is dual-licensed: the skill code, prompt templates, and docs are MIT, and the example images, character IPs, and style references are CC BY 4.0. If you use or adapt the characters or style, please credit "Kunaal's Illustrations" by Kunaal and link back to the repo.

Take it for a spin

If you write anything technical and you're tired of forgettable stock imagery, I'd love for you to try this on your next post.

Repo: https://github.com/Yuvakunaal/kunaal-illustrations
Portfolio: https://kunaal-portfolio.vercel.app/

If you build something weird with it, drop it in the comments — I want to see what your agent draws. And a star on the repo genuinely helps.

When Batching Your AI Agents Makes Them Read Each Other's Mail

Yuva Kunaal — Thu, 16 Jul 2026 16:29:22 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

n8n is an open-source workflow automation platform — think Zapier, but self-hostable, node-based, and built for developers. One of its most-used features is the AI Agent node, which wraps an LLM in a tool-calling loop: the model can call other nodes in your workflow as "tools," see the results, and decide what to do next, across multiple items and multiple rounds.

To keep costs down and stay under rate limits, the Agent node supports Batch Processing — running several input items through the tool-calling loop concurrently instead of one at a time. That feature is where this bug lives.

Bug Fix or Performance Improvement

The bug: when Batch Processing is enabled with a batch size of 2 or more, and two items in the same batch both need to call a tool in the same round, one item's conversation history silently leaks into the other's from round 2 onward — or gets dropped outright. Concretely: item 0 calls get_weather for Berlin, item 1 calls get_stock_price for ACME. By round 3, item 1's rebuilt conversation context contains item 0's Berlin weather call instead of its own stock price call. The LLM processing item 1 is now reasoning from a completely different item's history.

This isn't a cosmetic bug — it's silent data/context corruption in the exact feature (tool-calling memory) that determines whether an AI agent gives a correct answer. And it fails silently: no exception, no error in the UI, just a wrong answer built from someone else's data.

Root cause, traced through the actual engine round-trip:

executeBatch.ts merges all items' outgoing requests for a round into one shared object. When it does, it keeps only the first item's metadata (which includes previousRequests — that item's own tool-call history) and silently discards every other item's.
buildSteps.ts, when rebuilding an item's conversation for the next round, splices whatever previousRequests survived that merge into every item's steps, completely unconditionally — no filtering by which item the history actually belongs to.

Put together: whichever item happens to go first in the batch "wins" the shared history slot, and every other item inherits it instead of its own.

Code

My Improvements

I confirmed the bug with a deterministic (non-flaky) regression test before touching any source: mock two batch items each returning distinct tool-call data, run them through executeBatch, and assert on the merged result. It failed exactly as the root-cause analysis predicted — item 1's data was gone, item 0's leaked everywhere.

The fix has three small, surgical pieces:

Tag, don't guess. Added an optional itemIndex field to ToolCallData (the type representing one tool-call step), and tag every step with it the moment it's created in buildSteps.ts.
Merge, don't discard. In executeBatch.ts's batch merge, instead of keeping only the first item's previousRequests, concatenate every contributing item's array.
Filter, don't splice blindly. In buildSteps.ts, when rebuilding an item's steps for the next round, filter the merged previousRequests down to just that item's own tagged entries before splicing them in.

// buildSteps.ts — filter on the way back in
if (response.metadata?.previousRequests) {
  steps.push(
    ...response.metadata.previousRequests.filter((step) => step.itemIndex === itemIndex),
  );
}

// executeBatch.ts — merge instead of discarding
} else {
  request.actions.push.apply(request.actions, batchResult.actions);
  const otherPreviousRequests = batchResult.metadata?.previousRequests;
  if (otherPreviousRequests?.length) {
    request.metadata = {
      ...request.metadata,
      previousRequests: [...(request.metadata?.previousRequests ?? []), ...otherPreviousRequests],
    };
  }
}

One deliberate scoping call: this same root cause also means each item's iterationCount (used for the "max iterations" circuit breaker) is shared across the batch rather than tracked per item. Fixing that properly would mean restructuring the whole shared-metadata shape — a bigger, riskier change. I documented it as a known follow-up instead of folding it into this PR, to keep the diff small, reviewable, and focused on the one bug with an unambiguous, demonstrable before/after.

Verified: 2 new regression tests, both confirmed failing against the unfixed code and passing after the fix, plus all 338 existing tests in the Agent/agent-execution suite still green — no regressions.

Best Use of Sentry

I wanted evidence that wasn't just "trust me, I read the code" — so I wrote a small demo harness that runs the real project code (the actual executeBatch/buildSteps functions, not a toy reproduction) through the exact two-item batch scenario, instrumented with Sentry.

Before the fix: running the scenario produced two real Sentry warning events — "item 1's conversation history contains item 0's tool-call data" and "item 1's own tool-call history was dropped during batch merge" — plus a trace span tagged cross_item_leak_detected: true.

After the fix: same scenario, same instrumentation — zero warning events, and the trace span flips to cross_item_leak_detected: false, with both items' data intact.

Then I ran Seer (Sentry's AI root-cause tool) on the "before" issue. What came back was remarkable — Seer's root cause analysis independently identified the exact mechanism (the unconditional splice in buildSteps, no per-item partitioning), citing the real files in my repo (executeBatch.ts, buildSteps.ts lines 316–395, prepareItemContext.ts, runAgent.ts) as evidence — meaning it actually read the connected repo, not just the event text.

I let it go further: "Yes, make a plan" produced a 4-step plan that matches my actual fix step for step — tag ToolCallData with itemIndex, filter in buildSteps, merge in executeBatch — down to the same line numbers. Then "Yes, write a code fix" produced a diff nearly identical to what I'd already shipped.

That's four independent analyses — mine, Seer's root cause, Seer's plan, and (see below) Gemini's — all converging on the same diagnosis and the same fix. The one genuine difference is worth calling out honestly rather than glossing over: Seer's generated filter also let untagged (itemIndex === undefined) entries pass through to every item as a backward-compat safety net, where mine is strict. In this codebase that difference never manifests (every step is unconditionally tagged going forward), but it's a real, spottable design choice, not a rubber stamp.

And the most useful gap Seer's autofix exposed: its generated diff shipped with zero tests. n8n's own contribution guidelines require tests on every PR (unlabeled PRs without them auto-close after 14 days) — so even a diff this close to correct wouldn't be a mergeable submission on its own. That's the concrete difference between an AI-generated patch and a human-verified fix: mine ships with regression tests confirmed failing before, passing after.

I also let Seer draft its own PR from the plan — it created PR #2 on my fork, a nice piece of evidence that Sentry can go all the way from a captured error to an autonomous, code-aware pull request. My actual submission (PR #34360) is the tested, human-verified version.

Best Use of Google AI

I ran a three-message debugging session with Gemini, feeding it the real (unfixed) code and the symptom, without telling it my own conclusions first, to see if it would independently arrive at the same root cause.

Prompt 1 asked it to diagnose the bug from the executeBatch.ts merge logic and buildSteps.ts splice, given the symptom (item 1 inheriting item 0's history by round 3). Gemini correctly identified the reference-hijacking merge and the unconditional splice as the mechanism. It also flagged a "secondary bug" — that request.actions.push.apply(...) mutates item 0's original actions array by reference. Worth being honest about this one: it's technically true (same array object), but I don't think it's actually a separate bug here — nothing else reads that reference afterward, and merging all items' actions into one array is the intended behavior anyway. Good reminder that AI analysis needs to be checked against real usage, not just taken at face value.

Prompt 2 asked what the smallest fix would be, and specifically what breaks if you patch only buildSteps.ts without also fixing the merge in executeBatch.ts. Gemini got this right and explained it well: if you only filter in buildSteps, item 1's data isn't there to filter — it was already discarded two rounds earlier. Filtering a dataset that no longer exists doesn't help; you'd trade cross-contamination for outright data loss (and, plausibly, an agent that repeats tool calls because it's forgotten it already made them). This matches exactly what I found empirically in the Sentry demo.

Prompt 3 shared my actual shipped diff and asked Gemini to sanity-check it, including the deliberate iterationCount scoping decision. It confirmed the fix closes the conversation-history gap, and caught something I hadn't stated as sharply: because the merge spreads request.metadata (item 0's) and only explicitly overwrites previousRequests, any other per-item metadata field beyond previousRequests — not just iterationCount — still silently reflects only the first item's value. That's a more precise, general framing of the same follow-up I'd already scoped out, and it made its way into my PR description as a result.

Across all three prompts, Gemini converged on the same diagnosis as my own analysis and Sentry's Seer — but the value wasn't in blind agreement, it was in the two places I could point at and say "that's not quite right" (the array-mutation non-bug) or "that's sharper than what I'd written" (the general metadata-field caveat). That back-and-forth is what actually made the PR description better.

I Open-Sourced an AI Skill for Generating Minimalist Hand-Drawn Illustrations

Yuva Kunaal — Tue, 23 Jun 2026 07:00:22 +0000

I Open-Sourced an AI Skill for Generating Minimalist Hand-Drawn Illustrations

Most AI-generated illustrations today look highly polished, glossy, and over-rendered.

While that's impressive, I wanted something different.

I wanted illustrations that feel simple, human, playful, and intentionally imperfect — the kind of sketches you'd find in a notebook or on a whiteboard.

So I built and open-sourced Kunaal's Illustrations.

The Goal

The objective was straightforward:

Minimalist black line art
Lots of whitespace
Wobbly hand-drawn aesthetics
Consistent character style
Easy generation through AI prompts

Instead of creating photorealistic artwork, the focus is on communication and storytelling.

What Can It Generate?

Cozy Lifestyle Scenes

Examples:

Boy reading a book with a coffee
Girl working on a laptop
Friends chatting at a dining table
Someone studying late at night

Technical Concepts

It can also visualize abstract ideas such as:

Complex server architectures
API workflows
System design concepts
Developer productivity themes

Documentation & Presentations

The illustrations work particularly well in:

Notion pages
Blog posts
Technical documentation
Slide decks
Educational content

Built-in Character Style

The skill includes a consistent visual identity through:

Reference Boy
Reference Girl

These characters provide style consistency while still allowing generation of completely new scenes and concepts.

Example Prompt

Generate an illustration: A boy and a girl sitting opposite each other at a dining table saying hi and hello.

Why Open Source?

I wanted:

Anyone to use it
Anyone to improve it
A reusable illustration style for creators and developers

Open-source tools become far more useful when the community can adapt and extend them.

GitHub Repository:

@Yuvakunal/kunaal-illustrations

Contributions, feedback, and suggestions are welcome.

If you find it useful, consider giving the repository a ⭐.

Happy building!

"Wrong Answer" is the worst feedback you can give a SQL learner — so I built something better

Yuva Kunaal — Mon, 18 May 2026 04:16:54 +0000

You submit a query. It's wrong.

The platform says: Incorrect result.

That's it.

No diff. No hint. No explanation of which rows are wrong or why. Just a red banner telling you to try again.

I've used enough SQL learning tools to know this is the standard. And I think it's the single biggest reason people get stuck and give up — not because SQL is hard, but because the feedback loop is broken.

So when I built SQLumina, I made the debug experience the core feature. Here's exactly how it works under the hood.

The problem with "wrong answer"

When a SQL query returns incorrect results, there are maybe 15 different reasons why:

Wrong JOIN type (INNER when you needed LEFT)
Joining on the wrong columns (PK to PK instead of FK to PK)
Missing GROUP BY column
WHERE clause firing before aggregation
HAVING threshold off by one
LIKE missing a wildcard
NULL comparison written as col = NULL instead of IS NULL

Each of these produces a different shape of wrong output. A generic "incorrect" banner treats them all the same. That's useless.

What a learner actually needs is: which rows are wrong, and why.

Step 1 — Building the row-level diff

Every challenge in SQLumina has a reference solution stored server-side. When a user submits, the backend runs both queries concurrently against the live PostgreSQL database:

user_result, ref_result = await asyncio.gather(
    run_query(user_sql, schema),
    run_query(reference_sql, schema)
)

Then it computes three sets:

correct = user_rows & reference_rows
missing = reference_rows - user_rows
extra   = user_rows - reference_rows

These map directly to the three columns in the debug panel: Correct, Missing, Extra.

The diff table shows full row values — all columns, no truncation. If a row is missing because your JOIN dropped it, you can see exactly which row it was.

Step 2 — Accuracy scoring with Jaccard similarity

Once you have the three sets, you need a single accuracy number.

I use Jaccard similarity:
accuracy = |correct| / (|correct| + |missing| + |extra|)

The reason this matters: a simple "percentage correct" would reward over-fetching. If the expected result is 10 rows and you return 10,000, you'd technically have 100% of the correct rows — you'd just also have 9,990 extra ones.

Jaccard penalises both under-fetching and over-fetching. Getting 15 rows when 10 were expected is scored lower than getting exactly 10 right. This matches how production SQL correctness actually works.

Step 3 — Parsing the query AST

Showing the diff is useful. Explaining why the diff exists is what makes it genuinely educational.

This is where it gets interesting.

I built a 30+ rule heuristic engine that parses the user's actual SQL to extract:

Table names and aliases
JOIN conditions (specifically the ON clause columns)
SELECT columns and whether they're wrapped in aggregates
WHERE predicates and their operators
GROUP BY columns
HAVING conditions

Then it matches those parsed elements against the diff to produce specific diagnosis cards.

Example rule — wrong JOIN key detection:

def check_join_key(parsed, diff):
    for join in parsed.joins:
        left_col  = join.condition.left.column
        right_col = join.condition.right.column
        left_ref  = get_table_pk(join.condition.left.table)
        right_ref = get_table_pk(join.condition.right.table)

        if left_col == left_ref and right_col == right_ref:
            return DiagnosisCard(
                severity="high",
                message=f"You're joining {join.condition.left.table}.{left_col} "
                        f"to {join.condition.right.table}.{right_col}. "
                        f"Both are primary keys. You probably want the foreign key instead.",
                fix=generate_corrected_join(join)
            )

The card surfaces in the UI with a severity badge, confidence percentage, the specific columns involved, a corrected SQL fragment, and a plain-language explanation of the underlying concept.

Step 4 — The zero-rows suite

A separate set of 7 rules fires specifically when the user's query returns zero rows against a non-empty expected result. These are the most frustrating bugs to debug because the diff table is just... empty.

The rules detect:

Pattern	Issue
`col = NULL`	Should be `IS NULL`
`LIKE 'foo'`	Missing wildcard — should be `LIKE '%foo%'`
`BETWEEN hi AND lo`	Bounds are reversed
`NOT IN (...)` with NULL in list	NULL silently excludes every row
`date_col > CURRENT_DATE + INTERVAL '30 days'`	Future filter — should subtract
WHERE clause over-filtered	Too many AND conditions, no rows survive
No WHERE when one is required	Missing filter entirely

Each zero-row rule names the exact predicate from the user's query and suggests the corrected version. No generic messaging.

Step 5 — The pgBouncer bug that took me days

This one isn't about the debugger directly. It's about the infrastructure that makes sandboxed query execution reliable — and it's the bug that cost me the most time.

SQLumina runs on Neon's serverless PostgreSQL with asyncpg. Each user query runs inside a schema — ecommerce, social_media, or banking — and sandbox queries run in an isolated sandbox_{user_id} schema.

To route queries to the right schema, I was setting the search path before executing:

await conn.execute(f"SET search_path TO {schema}")
await conn.execute(user_sql)

In development: worked perfectly.

In production under any real load: randomly failing with relation "products" does not exist.

Not consistently. Not reproducibly. Just sometimes, on concurrent requests.

The root cause: Neon uses pgBouncer in transaction mode.

In transaction mode, pgBouncer doesn't guarantee that two consecutive statements from the same application connection hit the same backend PostgreSQL connection. The SET search_path runs on connection A. The actual query lands on connection B — which has a fresh search path pointing at public, where your tables don't exist.

The fix:

async with conn.transaction():
    await conn.execute(f"SET LOCAL search_path TO {schema}")
    await conn.execute(f"SET LOCAL statement_timeout = '5000'")
    result = await conn.fetch(user_sql)

SET LOCAL scopes the change to the current transaction. Since the transaction is atomic, both statements are guaranteed to execute on the same backend connection. pgBouncer can't split them.

Two lines. Took days to find. Now it never fails.

If you're building on Neon and hitting "relation does not exist" errors randomly under load — this is your fix.

Step 6 — Sandboxing safely

A few things that keep user queries from doing damage:

Comment stripping — SQL comments (-- and /* */) are stripped before parsing so users can't hide keywords inside comments to bypass validation.

Destructive operation blocking — DROP DATABASE, TRUNCATE outside sandbox scope, and GRANT are blocked at the parser level before execution.

Auto-LIMIT — LIMIT 1000 is appended when absent so a SELECT * on a large table doesn't flood the frontend.

Timeout — SET LOCAL statement_timeout = '5000' kills queries at the DB level after 5 seconds. A Python asyncio.wait_for at 6 seconds is a belt-and-suspenders fallback — PostgreSQL cancels cleanly before Python times out, which prevents dirty pool connections.

Read-only enforcement — The main ecommerce, social_media, and banking schemas are strictly read-only from the Playground. Only the user's own sandbox schema allows DML.

Per-user isolation — Every user gets their own sandbox_{user_id} schema. Other users' tables are completely invisible. Schema names are case-folded and sanitised before interpolation so two Clerk IDs that differ only in case can never collide.

What I learned

Building this taught me more SQL than taking any course did.

You can't write a rule that detects "you're joining on two primary keys" without understanding deeply why that's wrong and what the correct foreign key relationship should look like. You can't write the zero-rows suite without knowing every way a query can silently exclude all its data.

The debug engine is now 30+ rules. It's also the thing I'm most proud of in the entire codebase.

If you're building anything where users write queries against real data — especially in a learning context — invest in the feedback layer before anything else. The SQL execution part is easy. Telling someone specifically what they got wrong is the hard problem.

SQLumina is about to launch...

CommitAI — Local AI-Powered Git Assistant Using Gemma 4

Yuva Kunaal — Fri, 08 May 2026 20:56:09 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

As developers, we repeatedly write commit messages, maintain changelogs, and switch context during development. I wanted to build a lightweight developer tool that could automate this workflow completely offline without relying on cloud APIs or external AI services.

So I built CommitAI — a local AI-powered Git assistant using Gemma 4 + Ollama.

The workflow is simple:

Read staged Git diff
Send it to a local Gemma 4 model
Generate a clean Conventional Commit message
Update changelog automatically
Execute the Git commit

I also added Git hook integration so the workflow becomes:

git add .
git commit

and the AI handles the rest.

The project is built entirely in Python and runs locally on my MacBook Air M2 (8GB RAM).

Features

AI-generated Conventional Commit messages
Automatic changelog generation
Git hook integration
Fully local/offline workflow
Rich CLI interface using the Rich library
No external APIs
Privacy-friendly local inference
Uses staged Git diffs as context

Demo

Demo Video

Code

CommitAI Repo

How I Used Gemma 4

I used the gemma4:e2b model through Ollama for all AI-powered functionality inside CommitAI.

I specifically chose the E2B model because:

it runs efficiently on local hardware
lightweight enough for my MacBook Air M2 with 8GB RAM
low-latency responses for CLI workflows
strong enough reasoning for summarizing Git diffs
ideal for privacy-focused offline tooling

Gemma 4 powers:

commit message generation
changelog summarization
Git workflow automation

Architecture

Git Diff
   ↓
CommitAI
   ↓
Ollama API
   ↓
Gemma 4 (E2B)
   ↓
AI-generated commit/changelog
   ↓
Git commit execution

Tech Stack

Python
Ollama
Gemma 4 (gemma4:e2b)
Rich
Git Hooks

Future Improvements

PR description generation
Multi-model support
Better diff summarization
VSCode extension
Team changelog modes
Interactive commit editing

One of my biggest goals with this project was proving that useful AI developer tooling can run fully locally without depending on cloud APIs.

Thanks for reading 🚀

I built a free AI Flowchart Studio — just launched today! 🚀

Yuva Kunaal — Fri, 08 May 2026 18:27:40 +0000

Hey DEV community! 👋

Just launched AI Flowchart Studio today — a tool that converts
plain English into professional flowcharts using a Multi-Agent
Gemini AI pipeline.

The Problem

Existing tools like Lucidchart are too heavy for quick diagrams.
I wanted something where you just DESCRIBE and it builds.

How the AI Works (4-Stage Pipeline)

This is the part I'm most proud of:

Orchestrator Agent — Validates if the prompt can logically become a flowchart
Logic Parser Agent — Breaks text into a structured JSON graph (nodes + edges)
Generator Agent — Converts the graph into Mermaid.js syntax
Syntax Validator — Final check to guarantee perfect visual output

This pipeline ensures "Garbage In" never becomes "Garbage Out" 🎯

Tech Stack

Frontend: Vanilla JS, Mermaid.js, html2canvas, CSS3
Glassmorphism — deployed on Vercel

Backend: FastAPI (Python), Google GenAI SDK,
Server-Sent Events for real-time streaming — deployed on Render

Key Features

🤖 Multi-Agent AI generation
✏️ Manual builder (click & type, no coding)
🔄 Undo/Redo engine with memory buffer
📤 Export PNG (3x super-scaled), SVG, or Mermaid code
💾 5 concurrent saved projects
📱 Mobile-responsive with bottom-sheet menus
🔍 Hardware-accelerated canvas zoom (+/- 300%)
🔑 BYOK — your API key never leaves your browser

Privacy First (BYOK)

Your Gemini API key is stored only in your browser's
LocalStorage. Our backend acts purely as a secure proxy —
zero data retention.

🔗 Try it: AI Flowchart Studio

🚀 Also live on Product Hunt today — support appreciated!
Product Hunt Launch

Would love feedback from devs:

What would make you use this daily?
Any architecture improvements you'd suggest?
Would you pay for a hosted version (no API key needed)?

Thanks for reading! 🙏