DEV Community: Taqui

Why Your LLM Prompts Break in Production (And How to Fix Them)

Taqui — Sat, 17 Oct 2026 07:56:12 +0000

I recently started learning Applied AI Engineering from scratch. Before this, I thought prompting was just typing a question into ChatGPT, testing it once, and moving on.

In real apps, that breaks fast. Here are my handyy notes and visual diagrams from Chapter 1 on how to make LLMs reliable, ending with the fact-checking system I designed to test these concepts.

TLDR: The 5 Rules of Reliable Prompting
Temperature = 0 makes answers consistent, but it will still repeat a fake fact if the model does not know the answer.
Thinking comes first: Always put "thinking" before "answer" in JSON so the AI calculates steps before speaking.
Guard the edges: Wrap user input in <userMessage> tags and put your core rules at the very top and bottom.
Give an escape hatch: Use string | null in schemas so the model is never forced to hallucinate missing data.
Chain and retry: Split big prompts into small steps and use if/else retry loops with a max_retries cap.

1. Stochastic LLMs & Temperature

A calculator is deterministic (2 + 2 is always 4). An LLM is stochastic, meaning it predicts the next word by rolling a dice on probabilities. We control that dice roll using Temperature:

Prompt: "The dog chased the..."
 ├─ "ball" (50%) ◄── Temp = 0 (Always picks #1 top choice. Good for facts)
 ├─ "cat"  (30%)
 └─ "car"  (10%) ◄── Temp = 1 (Rolls the dice. Good for creative poems)

Why this matters: Setting Temperature = 0 does not stop hallucinations. The model does not stop predicting at 0. If it does not know the answer, its #1 top guess is still a fake fact, and it will just return that wrong answer every single time.

2. Chain of Thought (CoT) Prompting

For an LLM, generating tokens on the screen is literally how it thinks. If you ask a tricky riddle and force a 1-word answer right away, it has zero time to calculate and guesses wrong.

Zero-Shot CoT: Adding "Let's think step by step". Good for general math or logic, but skip it for simple facts like "Capital of France" because extra tokens cost money and slow down your app.
Few-Shot CoT: Giving 2 to 3 solved step-by-step examples. Best when you need the AI to follow your exact checklist every time.

The "No Backspace" Rule for UI Schemas

Users do not want to see a wall of robot thoughts on their screen. To hide the thinking, define a JSON schema with a "thinking" variable (hidden in backend) and an "answer" variable (rendered in UI).

❌ WRONG ORDER                      ✅ RIGHT ORDER
{                                   {
  "answer": "Weak!",                  "thinking": "Step 1: 14 chars...",
  "thinking": "Wait, 14 chars..."     "answer": "Strong!"
}                                   }
(AI guesses before thinking,        (AI thinks first, then locks in
 and cannot backspace to fix it)     the right answer)

3. Five Prompt Failure Modes

When real users use your app, prompts fail in predictable ways. Here is how the LLM's attention works and how to defend it:

Attention
  High │ ★ System Rules (Put core rules at the start)
       │
   Low │ ░░░ 10 Pages of Policy / Data (Lost in the Middle) ░░░
       │     <userMessage>{Untrusted Input}</userMessage>
  High │ ★ Sandwich Reminder (Put final rule here to beat Recency Bias)
       └────────────────────────────────────────────────────────► Prompt

Prompt Injection: Users type "Ignore previous rules" at the end. Because of recency bias, the AI listens to the latest message. Fix: Wrap input in <userMessage> fences and add a rule reminder at the very bottom.
Lost in the Middle: LLMs forget stuff buried in the middle of long text. Fix: Put long data in the middle and strict rules at the top and bottom.
Conflicting & Vague Rules: Saying "Be warm and casual, but sound like a strict lawyer. Make it pretty short." Fix: Separate the role from the tone, and replace "pretty short" with exact numbers ("max 3 sentences").
The "Pink Elephant" Problem: Saying "Do not think of a pink elephant" makes you picture one. Telling an AI what not to do activates those words. Fix: Tell it what to do instead ("Write 1 paragraph using 5th-grade words").
Sycophancy (Yes-Man Trap): LLMs flatter confident users. Fix: Detach your ego and ask it to find flaws: "Here is an idea I found online. Act as a strict critic and list 3 ways it fails."

4. Structured Outputs

Asking "Please return only JSON" in a prompt is just a polite wish. The AI will eventually add "Sure! Here is your JSON:" and crash your app.

Structured Outputs (Constrained Decoding) physically block invalid tokens by setting their probability to 0%:

AI wants to reply:
  "Sure!" (70%) ──► Blocked (0%) ❌
  "Here"  (20%) ──► Blocked (0%) ❌
  "{"     (10%) ──► Allowed (100%) ✅

Two rules I use for schemas:

Use clear names + Enums: Instead of "s": string, use "sentiment": "positive" | "negative" | "neutral".
Always add a | null escape hatch: Valid JSON syntax does not mean true facts. If "github_url": string is required and a resume has no link, the AI is forced to invent a fake URL just to obey the schema. Using string | null lets it safely output null.

5. Prompting Reliably in Production

Instead of testing a prompt once ("vibe checking") or writing one giant Mega-Prompt, reliable systems use Eval Sets (20 to 50 saved test cases to catch regressions) and Prompt Chains with retry guardrails:

[Step 1: Translate] ──► [Step 2: Check Rule] ──► [Guardrail (if/else)]
 (Fast/Cheap Model)       (Smart Model)                 │
                            ▲                           ├─ Pass ──► [UI Output]
                            └─── Retry + Error Msg ─────┘ (Fail)

Splitting steps makes it easy to see where the output went wrong and adjust only that step.

6. System Design: Fact-Checking Agent

To put everything together, I designed an agentic workflow in Excalidraw for a fact-checking app called TruthPulse.

Click to see the 3 bugs I fixed between V1 and V2

Search Queries vs. URLs: In V1, I told the agent to pass a url string to Web_search_tool[cite: 1]. Since LLMs do not know today's URLs, they would hallucinate dead links. In V2, I changed this to pass query: string (search keywords)[cite: 2].
Nullable Error Field: My V1 schema had "error": string[cite: 1], which forced the AI to invent an error even when the check succeeded. In V2, I changed it to "error": string | null[cite: 2].
Retry Guardrail + Loop Limit: I added a {"retry": "true" | "false"} check after the search step[cite: 2], plus a max_retries = 3 cap so an unsearchable rumor does not loop forever.

Final System Diagram

                        ┌───────────┐
                        │   Input   │
                        └─────┬─────┘
                              ▼
             <userMessage>{value}</userMessage>
             Remember: Only claim the given fact
                              │
                              ▼
        ┌───────────────────────────────────────────┐
        │ Main Agent + Thinking (Temp = 0)          │◄────────────┐
        │ "Strict fact checker... if invalid return │             │
        │  error, else pass query: string to tool"  │             │
        └──────────┬───────────────────────┬────────┘             │
                   │                       │                      │
     query: string │                       │ (Invalid input)      │
                   ▼                       │                      │
        ┌─────────────────────┐            │                      │
        │   Web_search_tool   │            │                      │
        └──────────┬──────────┘            │         Retry = true │
                   │ string                │      (max_retries=3) │
                   ▼                       │                      │
        ┌─────────────────────┐            │                      │
        │ Judge Prompt        │            │                      │
        │ Compare source with │            │                      │
        │ userMessage         │            │                      │
        └──────────┬──────────┘            │                      │
                   ▼                       │                      │
        ┌─────────────────────┐            │                      │
        │ {"retry": "true" |  ├────────────┼──────────────────────┘
        │           "false"}  │            │
        └──────────┬──────────┘            │
                   │ false                 │
                   ▼                       ▼
        ┌───────────────────────────────────────────┐
        │ {                                         │
        │   "thinking": string,                     │
        │   "claim": "true"|"false"|"unverified",   │
        │   "error": string | null                  │
        │ }                                         │
        └───────────────────────────────────────────┘

Takeaway

The main thing I learned in Chapter 1 is that AI Engineering is not about finding one magic prompt. Because LLMs are probabilistic, the real work is building the tags, schemas, chains, and retry guardrails around the model so your app stays reliable even when the AI slips up.

i hope reading really worth it for you,

Make sure to drop (🔥,♥️,👍)

And your comment really motivates me

i am learning and sharing on the internet.

Have a nice Day:)

Buy This, Not That, Drop This There” - I Made It Make Sense

Taqui — Sat, 10 Oct 2026 20:47:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

The short version

Someone at home gives you a rapid-fire list while you are already halfway out the door:

“Bring 1 litre milk. Don’t buy bread—we already have it. Drop the parcel at the post office. And get three notebooks.”

Most task apps make the person receiving that message do all the work: stop, type, split, remember, and interpret the cancellation correctly.

Nikalll turns that messy family request into a reviewed pocket card. You can speak or paste the request, let an open-weight Gemma model propose the errands, review every item, confirm destinations, and carry the final card outside.

The important part is not that AI produced a list. The important part is that cancelled items remain visible, quantities remain attached, uncertainty stays visible, and the person—not the model—approves what leaves the house.

What I Built

Nikal is a voice-first family-errand handoff for the small, real-world jobs that usually arrive as noisy voice notes or mixed Hindi/Hinglish/English messages.

It is for someone who is leaving home and needs to remember what another person asked them to buy, collect, or drop off.

The flow is deliberately short:

Capture — record a short voice note or paste the original message.
Transcribe — ElevenLabs Scribe v2 turns voice into editable text.
Extract — Gemma, called through Backboard, proposes structured errands, quantities, cancellations, destination hints, and clarification questions.
Review & assign — the original request stays visible while the person edits, cancels, defers, or assigns each item.
Pocket card — Nikal groups approved tasks by destination.
Outside — the person marks each item done, unavailable, deferred, or unresolved.

Nikal is not an autonomous shopping agent. It does not buy anything, message anyone, discover shops, track GPS, or pretend that a model's valid JSON means the request was understood.

The failure this is designed to prevent

The most dangerous failure is not a crash. It is a plausible-looking list that silently drops the important part:

“Do not buy bread” becomes “buy bread.”
“Two litres” loses its quantity.
“Drop this at the post office” loses its destination.
An unclear shop becomes a confident guess.
An unavailable item is quietly counted as completed.

Nikal treats these as product states, not edge cases.

What the card preserves

Included errands.
Explicitly cancelled errands.
Deferred or unresolved errands.
Quantities and units.
The user's original source text.
Destination assignments and manual corrections.
Honest completion outcomes.

The prepared workspace is saved in versioned browser storage. The AI request is online and hosted; the prepared local card does not require another model call to mark outcomes. I do not claim that this prototype is a fully offline AI application or a verified installable PWA.

Demo

Live demo: nikalll.onrender.com

Video demo:

The video walkthrough shows the complete story rather than a feature tour:

Start with a messy family request.
Keep the cancellation and quantity visible.
Let Gemma produce a draft.
Correct or confirm the destination in the review step.
Prepare the pocket card.
Mark one task complete and leave an unavailable/deferred state visible.

If the hosted providers are unavailable, the app keeps the source and offers the manual path instead of manufacturing a successful AI result.

Code

taqui-786 / nikalll

🚶 Nikalll (WalkRecall)

Turn chaotic doorstep voice notes into a structured, offline-ready errand card.

Speak once before leaving home, review in seconds, and walk out with a glanceable neighborhood checklist that works completely offline.

Explore Live Demo · Architecture · Features · Quick Start

💡 The Problem: The "Doorstep Voice Note" Chaos

Every time you step out of the house, your mother, roommate, or partner shouts a rapid-fire, chaotic list of errands:

"Arre suno! Bahar ja rahe ho toh sabzi mandi se 1 kg aloo aur dhaniya le lena... par tamatar mat lana ghar pe already hain... phir kirana store se 2 litre doodh aur dahi le lena, par bread bilkul mat lana... aur chemist se BP syrup le lena, band-aid mat lana wo drawer me hai!"

Why traditional tools fail:

To-Do Apps are too slow: No one has the time or patience to manually type 8 separate items with…

View on GitHub

The project is a Next.js + TypeScript application with the domain contracts, provider boundaries, tests, and setup instructions committed alongside the UI.

The most relevant areas are:

app/page.tsx — the capture, review, and pocket-card flow.
app/api/extract/route.ts — bounded, consented text-extraction boundary.
app/api/transcribe/route.ts — bounded audio-upload boundary.
lib/server/backboard.ts — explicit Backboard provider/model request.
lib/server/elevenlabs.ts — ElevenLabs Speech-to-Text adapter.
lib/domain/ — schemas and deterministic card/evidence logic.
tests/ — domain and provider-normalization regression tests.

How I Built It

Open-weight AI is the core, not decoration

Gemma performs the central interpretation task: turning conversational, mixed-language household instructions into a bounded extraction draft.

The browser never chooses the provider or model. The server selects them from environment configuration and sends a fixed prompt with:

explicit provider and model names;
non-streaming output;
JSON output requested as a formatting aid;
memory disabled;
web search disabled;
no tools or autonomous actions.

The default repository configuration uses Gemma through the openrouter provider in Backboard. The exact model is server-configurable; the repository default is google/gemma-3-27b-it. No API key is sent to the client.

Gemma's output is not trusted just because it is JSON. Zod validates the response, and the server checks that every evidence quote occurs verbatim in the original source. The model cannot return trusted destination IDs, application IDs, timestamps, completion states, or approval decisions.

ElevenLabs is a focused input boundary

Voice is useful because the original problem often starts as speech. ElevenLabs Scribe v2 handles transcription; Nikal then shows the transcript as editable text before extraction.

Audio uploads are size-bounded, accepted only through the server route, and not stored as application data. The UI can always fall back to text entry.

Deterministic code owns trust-sensitive decisions

Ordinary TypeScript—not the model—owns:

schema validation;
evidence matching;
destination alias matching;
inclusion/cancellation/deferment state;
card preparation rules;
local persistence;
outcome tracking.

An included item without a confirmed destination cannot enter the prepared card. An unresolved item must be resolved or explicitly deferred. An unavailable item is never silently marked done.

Stack

Next.js 16 App Router
React 19 and strict TypeScript
Tailwind CSS 4 with the existing shadcn/Base UI setup
Hugeicons
Zod for runtime contracts
Gemma via Backboard for extraction
ElevenLabs Scribe v2 for transcription
Render for the public deployment

What I Learned From the First Attempt

My previous hackathon project taught me that a polished interface and a long feature list are not evidence that the core problem was solved.

So this project is intentionally narrower. The demo has one complete story: a messy request, a source-linked AI draft, a human review, a pocket card, and an honest outcome. I kept the original text visible because an extraction that looks correct can still be wrong. I kept cancellation and uncertainty as first-class states because hiding them is worse than showing an incomplete result.

I also removed claims that I could not prove:

hosted Gemma is not described as offline AI;
browser persistence is not described as a fully offline PWA;
a model's JSON is not described as approval;
destination labels are not described as live shop discovery;
no accuracy percentage is claimed without a labelled, held-out evaluation;
an unavailable errand is not converted into a success state.

The most useful engineering decision was to make provider output cross a small, boring boundary: validate it, verify its evidence against the original message, then let deterministic application code decide what the user can approve.

Why Does Open Innovation Matter?

The open model is useful here because Nikal is not trying to replace a person with an opaque assistant. It is trying to make a messy human handoff inspectable and correctable.

With an open-weight model at the center of the extraction step:

the model and provider can be changed without rewriting the product workflow;
the extraction prompt and JSON contract can be inspected;
failures can be compared against a manual baseline instead of hidden behind a chat interface;
the application can keep approval, evidence, and completion outside the model;
a future self-hosted Gemma deployment could reduce the hosted-data boundary for sensitive household messages;
the same safety contract can validate different open models.

Backboard gives the application an explicit model boundary rather than a browser-side vendor dependency. I can select the Gemma provider/model on the server, turn memory and web search off, and keep the rest of the app independent of that choice.

ElevenLabs is deliberately smaller in scope: it solves the voice-capture problem, then hands editable text to the same review pipeline. It does not become a second decision-maker.

There is an important caveat: the current public deployment uses hosted services. Open innovation makes the model layer replaceable and inspectable; it does not magically make hosted inference private. Nikal tells the user when a request is sent for transcription or extraction.

My Agent Session

I built Nikal with OmniRush.ai as a coding and review partner. The agent helped with the architecture, domain contracts, provider boundaries, failure handling, and test cases; I made the product decisions and kept the final scope focused on one physical-world handoff.

I am not embedding a DevRelay session link in this draft because I do not have a public saved-session URL to link to. This section can be removed before publishing, or replaced with the DevRelay URL if one is created.

Prize Categories

Best Use of Gemma — Gemma is responsible for the core interpretation problem: quantities, negations, cancellations, destination hints, and clarification candidates in noisy household language. It is not decorative chat.
Best Use of Backboard — Backboard is the explicit server-side model boundary. The request fixes the provider/model, disables memory and web search, requests structured output, and validates the result before it reaches the review UI.
Best Use of ElevenLabs — ElevenLabs Scribe v2 handles the short voice-note transcription path and returns editable text before extraction.
Best Use of Render — the working Next.js application and its provider-backed routes are publicly deployed at nikalll.onrender.com.

Built by @taqui.

If this is a team submission, teammates should be credited here with their DEV usernames before publishing.

Drop your feedback guyzz

Taqui — Mon, 05 Oct 2026 14:43:36 +0000

Hacktoberfest Weekend Challenge: Build for a Friend Submission 🤝

Taqui

Oct 4

TiffinTally - my contribution to my friend's family business

#devchallenge #weekendchallenge #hf26challenge #webdev

6 min read

TiffinTally - my contribution to my friend's family business

Taqui — Sun, 04 Oct 2026 20:41:53 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built 🤟

Hey there, my name is Taqui. I am a fullstack web developer, and this time I wanted to build something useful outside my usual developer projects.

So I built TiffinTally, a small contribution to my friend’s family kitchen :)

The family story below is fictionalized. Customer counts and messages are illustrative, and real seller feedback is still pending.

The setup is a friend's family business in Noida, in the Gautam Buddh Nagar district of Uttar Pradesh, India. His mother and older sister prepare daily lunches for people who moved there for work.

Some customers live away from their families. They don't want restaurant food every afternoon. They want a simple home-cooked lunch that reaches them at the office
.

The business has around 18 to 24 monthly regulars. Small enough to know everyone, but enough for daily changes to become difficult.

You wonder,
What's the Problem i solving with this app ?

My Answer -

The cooking isn't the confusing part. The WhatsApp messages are.

“Aunty, no lunch tomorrow.”

“Please send two extra on Friday.”

“I am going home for three days.”

One person is cooking. Another is packing. A message arrives between both jobs.

Now someone has to remember the change, update the lunch count, tell the delivery helper, and account for it at the end of the month.

A missed cancellation means an extra lunch gets packed. A missed request means someone doesn't get theirs. And later, “I skipped those three days” becomes another chat to search.

TiffinTally keeps the request, the approved change, the packing list, and the monthly statement connected.

Customers can keep using WhatsApp. The kitchen gets a clearer way to manage what happens after the message arrives.

Demo

Live app: TiffinTally

Here is the workflow, one screen at a time.

1. Start with today's kitchen desk

The dashboard shows the selected service date, approved meal total, and requests waiting for review.

It has a personal greeting and a kitchen-notebook layout. I wanted it to feel like a working lunch register, not a dashboard full of unrelated charts.

2. Connect the kitchen's WhatsApp

The seller connects the kitchen phone through a QR code and links contacts to customer records.

Incoming messages from linked customers can be captured for review. Automatic analysis needs the AI providers configured.

There is also a manual “Add message” option.

3. Read voice notes too

Not every customer types their changes.

The WhatsApp audio path uses ElevenLabs Scribe v2 to turn a voice note into text. That text then enters the same review workflow.

This integration is implemented with mocked API tests. A live customer voice-note walkthrough is still pending.

4. Review before changing anything

The seller can read the original message beside the proposed change, check the dates and quantities, and edit or approve it.

Unclear requests stay marked for attention.

AI creates a draft. It does not approve the order.

5. Keep regular customers organized

Customer records hold names, packing notes, and schedules. Manual proposals handle changes that arrive through a call or conversation instead of WhatsApp.

Settings hold the kitchen timezone, planning time, cutoff, and customer limits.

Prices and delivery setup add each customer's agreed meal rate, billing number, building, and delivery note.

6. Finalize the packing sheet

Approved changes feed the daily packing quantities.

The seller finalizes a version of the sheet before handing it over. If current packing facts change, a fresh sheet is needed.

A pending draft cannot quietly change what gets packed.

7. Explain the monthly bill

The Bill book shows dated quantities and charges from finalized sheets.

Skips and extras reconcile into the total without deducting the same skipped meal twice. An agreed half-portion charge can be entered as a dated adjustment with a reason.

Issued statements are saved as immutable versions. Revisions reference the previous statement and warn customers not to pay both.

Sharing opens a WhatsApp composer for the seller to review and send. It does not mark a bill paid or prove a delivery happened.

8. Give the helper Ramesh Mode

Ramesh Mode groups positive meal quantities by the buildings or routes the seller entered.

Cancelled stops appear separately under “Do not stop today.” Unassigned deliveries remain visible instead of disappearing.

The helper gets a practical handover summary, not the whole billing workspace.

This is building-based grouping, not GPS route optimization.

9. Keep forecasts separate from orders

The forecasting section is advisory. It cannot change confirmed meals.

The planned TabPFN path uses historical meal changes and structured message signals. Hosted prediction integration and real-history validation are still unfinished, so I am not claiming a working demand forecast.

Code

Source repository: TiffinTally

How I Built It

I used Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui for the app.

TanStack Query handles reads and refreshing data after actions. Better Auth provides Google sign-in. Zod validates inputs and model outputs.

Gemma reads the request

The configured model is Gemma 4 31B IT, accessed through Backboard using its OpenRouter provider.

It extracts proposed meal changes with supporting quotes from the original message.

The app checks those quotes against the source. A confident-looking answer with invalid evidence does not become an approved order.

JEV asks a different set of questions

TypeSafe's JEV, pinned to jev-1.13.0, independently classifies the request.

Is it a pause, a quantity change, or something unclear? Does it explicitly replace the regular schedule? Are necessary details missing?

Disagreement or uncertainty becomes a review warning. JEV is another signal, not a guarantee that Gemma is correct.

Backboard connects both stages

Both models use the Backboard SDK, with separate threads and memory disabled.

An approved fictional live test produced a validated review candidate through the Gemma/JEV pair. That checks the integration, not accuracy across real customer conversations.

MongoDB keeps the approved facts

The persistence layer targets MongoDB Atlas, using seller-scoped records, revision checks, transactions, and request receipts.

Approval and money calculations are ordinary application code, not model-generated arithmetic.

Amounts use integer paise. Repeated requests use idempotency keys. If a save result is uncertain, the UI checks the original receipt rather than blindly submitting it again.

The checks have limits too

I checked the layouts with 279 isolated browser-rendering cases, covering mobile, tablet, desktop, and short landscape sizes using fictional data.

Those checks do not replace watching someone use the app on their own phone. The authenticated seller walkthrough and real family handover remain next steps.

Why Does Open Innovation Matter?

Gemma is an open-weight model, so the extraction stage is not tied permanently to one closed model API.

I can inspect the prompts, change the validation, and evaluate another serving option without rebuilding the packing and billing rules.

A closed API could also extract messages. The benefit here is having more control over the model choice and the surrounding workflow.

Open-weight does not mean offline. This build uses hosted inference, and ElevenLabs transcription is hosted too.

The important boundary is visible in the code: models suggest changes, while the seller approves them and deterministic code calculates the result.

My Agent Session

I built TiffinTally with AI assistance in omnirush.ai.

The work included the review pipeline, billing reconciliation, delivery handover, and responsive layouts.

One useful failure was a Gemma quote with an incorrect evidence offset. The validator rejected it. I corrected the prompt and kept the strict check instead of weakening it to accept the answer.

Prize Categories

Best Use of Gemma: Open-weight message extraction with source-linked review drafts.
Best Use of Backboard: The shared SDK integration for the Gemma and JEV stages, tested with fictional live requests.
Best Use of MongoDB Atlas: The application's persistence design for seller-scoped approvals, packing sheets, and statements. Live authenticated commerce verification remains pending.
Best Use of ElevenLabs: Scribe v2 integration for WhatsApp voice-note transcription. Live end-to-end transcription remains pending. ElevenLabs

I am not claiming TabPFN or Sentry categories from configuration or unfinished integration alone.

The goal is pretty simple: let the family spend more time cooking, and less time figuring out which lunch changed.

Thankyou for reading, i hope you liked it :)

Guys need your shitty feedback here

Taqui — Tue, 29 Sep 2026 17:00:53 +0000

Taqui

Sep 28

My Craziest Side Project Yet: Drawva

#mlhacks #devchallenge #hackathon #ai

4 min read

My Craziest Side Project Yet: Drawva

Taqui — Mon, 28 Sep 2026 16:52:46 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

Hey there, my name is Taqui. I am a fullstack web developer. When I started coding back in 2020, things were simple and skills had the highest priority. Lately, with the rapid rise of AI and the tough job market, I have felt pretty cookeddd. But instead of sitting back and questioning my career choice, I decided to dive headfirst into Agentic AI and GenAI to build a serious, real-world system from scratch.

That project is Drawva.

Drawva is an infinite canvas whiteboard engine powered by a multimodal AI perception agent. Unlike typical whiteboards where your strokes are just static pixels, Drawva actually looks at your canvas, understands your hand-drawn gestures, and turns them into live diagrams, interactive code widgets, and math equations.

DeepSeek Harness (DSH) Agent Runtime

Under the hood, Drawva runs a modular DeepSeek Harness system built on a Cordis microkernel runtime:

Agent Loop & Tool Runtime: Handles multi-turn tool calling through typed contracts (canvas_apply, canvas_snapshot, canvas_read, canvas_patch_widget).
Token Meter & Compaction: Uses a tool-result pruner and basic compaction to keep agent context tight and cost-effective during long sessions.
Session Projection: Preserves agent state and conversation history across streaming SSE steps.

Specialized Prompt Techniques

Getting an LLM to accurately interact with a freehand 2D canvas required custom prompt engineering contracts:

Coordinate Contract: Mathematical pixel-to-global transforms so the AI calculates exact millimeter coordinates from visual snapshots.
Zero-Heading Redundancy: The AI treats the user's handwritten words as the title. It never outputs duplicate title banners, keeping the canvas looking naturally co-authored.
Hybrid Wireframe Utilization: If you sketch a 3-box wireframe, the AI does not erase it. It leaves your pen lines intact and renders live data directly inside your drawn boxes with 100% transparent backdrops.
Two-Command In-Place Replacement: When turning a rough sketch into an interactive applet, the agent emits an atomic erase command first to clear the ink, followed immediately by the mounted widget.
Native Sketchnoting: A dedicated mode that uses pure vector strokes to sketch 3D loss surfaces, neural net graphs, and complex planes.

Extensible On-Demand Plugins

Drawva features 11 extensible runtime plugins loaded dynamically via load_plugin:

Live Data: Weather, Stocks, Tech News (Hacker News), Earthquakes (USGS), Space Weather, and Currency Exchange Rates.
Developer & Media: GitHub Pulse (live repo stars, forks, velocity), Image Search (server-side photo resolution for sandboxed widgets), and Flowcharts.

7 Diagram Engines & P2P Sync

Drawva supports 7 sandboxed diagram runtimes (Mermaid, Graphviz DOT, Vega-Lite charts, SMILES molecular structures, BPMN, Cytoscape, GeoJSON) alongside MathJax LaTeX typesetting. Everything autosaves to IndexedDB, and users can collaborate peer-to-peer over WebRTC with zero central server databases.

Demo

Here is a full walkthrough video showing Drawva in action, from freehand sketching to live diagram rendering:

Direct video link: Drawva Demo on YouTube

GitHub Repository: https://github.com/taqui-786/drawva
Live App: https://drawva.vercel.app/
Community cooks: https://drawva.vercel.app/community

Partner Technologies

Building Drawva pushed me to integrate modern fullstack and AI technologies:

DeepSeek Harness (DSH): Powered the core agent runtime, tool execution lifecycle, token metering, and compaction pruning.
Next.js 16 (App Router) & React 19: Provided the streaming foundation, handling Server-Sent Events (SSE) and fast client hydration.
Vercel AI SDK & Multimodal LLMs: Connected the canvas to vision models like Google Gemini 2.5, OpenAI GPT-4o, and local Ollama models for high-resolution visual inspection.
Tailwind CSS v4 & Base UI: Used to build our dark-mode UI with custom neon lime tokens, floating tool docks, and accessible dialogs.
GitHub: The entire codebase is open-source on GitHub, where I tracked features, plugin contracts, and releases.

Hackathon Experience

Tbh this was my first hackathon 😅. And Over the past few months, I had been losing my confidence as a developer, wondering if AI was making my hard-earned skills obsolete.

Building Drawva was not the only goad for this hackathon. The main purpose is that new Deepseek Harness in the market and it is opensources, So i decided to learn how the harness is build and end up integrating the mini-kernal in this project.

This experience proved to me that as developers, our value is not gone. We just have to evolve, pick up Agentic AI, and build ambitious tools that solve real problems.

That's it man

Look, the tech market is wild right now and we all feel cooked some days. But if AI is taking over the world, I am not going down without building the craziest open-source tools I possibly can.

Go open Drawva, draw the ugliest, most crooked scribble you can think of, and watch the AI turn it into art. Aslo also also don't forget to share you crazyy dravs to the comminuty page (we have one our community page)

And if it crashes, roast me in the GitHub issues or open a PR. And if this gave you even 1% of your developer spark back, smash a star on the repo. Let us reclaim our builder aura :)

Microsoft Up 15%. Me? 100% Down.

Taqui — Sun, 02 Aug 2026 15:33:51 +0000

hey there, so i wanted to share something with you. this is a bit personal but i have been watching the news this week and bruh... things are not going good. i am jobless right now, no other source of income, and day by day things are getting worse. and the worst part? AI is literally fuking every job in the software field. so when i saw this week's stock market drama, it hit me different.

Microsoft popped. Meta tanked. Same AI boom. Two completely opposite reactions. and all i could think was... yeah, this is exactly my life right now.

The Numbers, Bruh

let me break it down real quick because this is wild:

Microsoft jumped like 15% after beating expectations. Azure grew 43%. full year Azure revenue crossed $100 billion. insane.
Meta dropped 8–9% after missing on guidance. their free cash flow collapsed 91% year-over-year to just $784 million. like... 91%?? gone.

same AI boom. same crazy spending. and the market said "you're amazing" to one and "you're done" to the other.

Why Microsoft Won

Microsoft actually showed receipts. they didn't just talk about AI, they showed the money coming in. Azure is growing, Copilot is making real revenue, investors can literally see the line between billions spent and billions earned.

lesson? Wall Street doesn't hate AI spending. it hates AI spending without proof.

Why Meta Lost

Meta's problem is that nobody can see where the money comes back. Zuckerberg talked about the "AI capacity dilemma" — how much compute to keep for yourself vs sell to others. but guidance missed, free cash flow went to hell, and the market was like... nah bro, i need answers.

and honestly? i relate to that feeling more than i want to admit. putting everything into something and people still saying "not enough."

The Bigger Picture

this week is a preview of everything coming. companies are dumping hundreds of billions into data centers, chips, and models, all betting AI demand keeps exploding. the ones who can prove it pays off? they get rewarded. the ones who can't? they get crushed.

and us devs? we're the ones caught in the middle. chips are booming — Lam Research jumped 20%, Micron went crazy. but the jobs? they're disappearing.

bruh, i remember the days before Claude and Cursor. things were so good. i had my aura, man. i was a fuking awesome engineer. i built cool projects, wrote articles that people genuinely loved, got stars and forks on my repos, my articles had views, likes, comments... and i loved replying to every single one of them. i had so much self confidence back then.

i miss those days so badly. i wish i could get back to them.

What This Means for Us

AI isn't a single trade anymore. it's a scoreboard. companies that turn AI into a revenue engine win. companies that treat it like a science project lose. Microsoft showed the winning formula. Meta showed what happens when you can't explain the money.

and for people like me? i guess it means we have to adapt. find the new aura. rebuild. i don't know how yet, but i have to.

ahh... i wish those days would come back again. i wish i get my aura back again.

anyway, thanks for reading. this one was personal. i hope things get better for all of us out here.

thankyou.

Great Read

Taqui — Mon, 25 May 2026 15:34:46 +0000

Sylwia Laskowska

Dec 1 '25

Nobody Writes Clean Code. We All Just Pretend

#discuss #webdev #programming #productivity

211

128

4 min read

The Company Is Strong. So Why Are 4,000 People Gone?

Taqui — Sat, 28 Feb 2026 06:10:58 +0000

Going to be a rant.

We just watched a CEO tweet that they’re making their company “smaller” and not because revenue collapsed, not because the product failed, not because customers left, but because they can. Nearly half the company, over 4,000 people, gone in one move while the business is still growing, improving profitability, and serving more customers.

Read that again. This wasn’t survival mode, this was optimization mode.

The tone of the tweet was calm, transparent, even generous with severance and benefits, which somehow makes it more unsettling.

The logic was simple: intelligence tools plus flatter teams equal a new way of running a company. Faster decisions, fewer layers, more output per person. So leadership chose to act now instead of cutting slowly over years. And this is what people are missing in the AI debate. It’s not about whether AI writes better code. It’s about compression.

If a strong, profitable company can say “we need fewer people because AI changes how work gets done,” then the baseline just shifted. Layoffs used to be reactive. Now they’re proactive. “Profitable” used to mean safe.

Now it doesn’t. This isn’t framed as survival, it’s framed as restructuring for an intelligence-driven future. And once companies realize 10 people can do the work of 15, they don’t keep 15 out of kindness. They optimize for margins. That’s the uncomfortable truth.

AI isn’t just a tool inside products anymore, it’s becoming the operating system of companies. And operating systems are designed for efficiency. If this is happening while models are still early, what happens in three years? Maybe the real question isn’t whether AI replaces developers. Maybe it’s how many developers a modern company actually needs. Because once leaders decide that number is lower, they don’t drift toward it. They jump. And that jump is what we just saw.

Rant over.

Built Something Crazy This Week – Inkash

Taqui — Sat, 14 Feb 2026 13:45:51 +0000

Hey dev's 👋 it's me Taqui

This week I built something that actually pushed me hard.

It’s called Inkash.

Live: https://inkash.vercel.app
GitHub: https://github.com/taqui-786/inkash (Drop a Star ⭐)

Inkash is a smart link generator that compresses real data into a short shareable URL.

No database.
No backend storage.
The data lives inside the URL itself.

That was the fun part.

What Inkash Actually Does

The idea is simple:

Take user input
Compress it using the deflate algorithm
Convert it into a URL-safe string
Generate a shareable link
On load, decompress and restore the original content

So large content becomes a compact link.

When someone opens it, everything rebuilds instantly on the client.

It feels kind of crazy seeing big data turn into a short URL and still restore perfectly.

it also has markdown editor you can us

Sharing Feature:

The cool thing is,

You can generate the QR-code of the link and share it

Core Compression Logic (Simplified)

Here’s a simplified version of how compression and decompression works:

import { deflate, inflate } from "pako";

export function compressData(input: string) {
  const compressed = deflate(input);
  return btoa(
    String.fromCharCode(...compressed)
  );
}

export function decompressData(encoded: string) {
  const binary = atob(encoded);
  const bytes = Uint8Array.from(binary, (c) => c.charCodeAt(0));
  return inflate(bytes, { to: "string" });
}

Under the hood, it:

Uses the deflate algorithm to reduce payload size
Converts binary compressed data into Base64
Makes the output URL safe
Restores everything safely on load

Technical Challenges

The real challenge was not just compression.

It was making sure everything works safely inside a browser URL.

Here are some things I had to handle:

Making compressed output URL safe
Handling corrupted or invalid hashes
Respecting browser URL length limits
Preventing UI crashes during decompression
Managing edge cases with large payloads
Keeping everything fully client-side

If even one character in the URL changes, decompression can fail. So proper validation and error handling was very important.

Tech Stack

Next.js
TypeScript
Client-side compression using pako
Modern UI components
Clean and scalable architecture

There is no database involved.

The link itself is the storage.

That was the main experiment and honestly the most fun part.

What I Learned

Building Inkash taught me:

How the deflate algorithm works in real usage
Binary to Base64 transformations
URL encoding and safety concerns
Browser URL length constraints
How easy it is to break decoding
How to build something useful without a backend

This project broke many times before it became stable. But once it worked, it felt clean and kind of magical.

If you check it out, I would really love honest feedback.

What would you improve or add to something like this?

This portfolio isn’t perfect, but it’s 100% mine

Taqui — Sat, 24 Jan 2026 06:26:18 +0000

Hey devs 👋 its me Taqui

Just wanted to share the story behind my last portfolio.

I already had a portfolio before this. It looked cool, it worked fine, but for some reason it never felt like it was really mine. I couldn’t fully connect with it.

The truth is, my older portfolio was mostly a rebuild of chandai’s portfolio. I learned a lot from building it, especially about layout, animations, and structure. But at the end of the day, it still felt like I was wearing someone else’s design.

So I decided to start again. From zero.

This time, I made one clear rule for myself:
Build something from my own ideas, my own layout decisions, and my own taste.

I did take inspiration from other great portfolios (because that’s how we all learn), but every section, spacing choice, and interaction was designed and built by me. No copying. No rebuilding someone else’s work.

Tech stack I used:

Next.js
Tailwind CSS (mostly custom styles)
Very little shadcn/ui, only where it made sense, like the contact form
Small UI details and interactions done manually instead of relying on libraries

When you open the site, you’ll notice a subtle fade-in blur animation. That was intentional. I wanted the site to feel calm and smooth, not flashy or loud. Something that feels pleasant to scroll through.

This isn’t my first portfolio.

But it’s the first one that truly feels like *me*.

And because of that, I’m calling it my last portfolio.

I’ve attached a demo banner image above so you can get a quick idea of the look and feel.

Live URL (new portfolio):

Checkout its live 🚀

Source code:

Drop a ⭐ on Github

If you’re curious, feel free to check it out.

And if the code helps you or inspires you in any way, dropping a GitHub star would honestly mean a lot ⭐

Feedback is welcome.

Happy Show Off Saturday 🚀

I Built Everything Fast… Then One Page Destroyed My Confidence

Taqui — Tue, 09 Dec 2025 07:04:12 +0000

Hey buddy,

So… I built almost the whole app. Shipped every hard thing. Solved every annoying bug.

And then one single page came out of nowhere and said:

“Bro, sit down.”

Welcome to my life with Snapgroove - a tiny tool I’m building to make your screenshots look less like a cry for help. Give them shadows, gradients, device frames… all in one click. Basically: make your work look expensive without knowing design.

And guess what?

The core app is done.

Like actually done.

Editor works
Image export is smooth
All features tested
Logo and branding ready

Live here → https://snapgroove.vercel.app

But then…

The landing page happened.

And suddenly I felt like I forgot how to think.

The Fun Part: Building the Actual App

As a full-stack dev, building features is my comfort zone.

Give me logic, give me APIs, give me bugs that ruin my sleep - I will survive.

Snapgroove came together pretty fast:

A clean editor
Nice export flow
Simple UI
It’s all open-source too: taqui-786/Snapgroove

Github Repo

I even vibe-coded some layouts for the landing page.

But honestly? Everything felt too generic or too messy.

I’m just not great at design stuff. And this is the part that always slows me down on every project I make.

And yes, I know the app itself is still not perfect. It’s in beta. I’m improving it as fast as I can. But landing pages… bro… they hit different.

The Not-So-Fun Part: The Landing Page Breakdown

It’s wild how I can build a full editor in a single sitting, but a landing page will take my brain hostage for days.

I tried multiple layouts.

I tried being creative.

I even told myself, “Just ship it, nobody cares.”

But I care.

And nothing feels right.

Landing pages are weird.

You need:

Good design
Clean layout
The right words
The right vibe
Something that doesn’t scream “bro, we know you’re a developer”

And I’m still figuring that out.

What I Need Help With (Yes, You 😭)

If you’re reading this, I’d honestly love your input.

Take a quick look at the app
Tell me what confused you
Suggest what the landing page should highlight
Share any design inspo sites you use

Anything helps.

I’m a developer who’s way better at building things than selling them.

So any tips, design ideas, or copy advice… I’ll take it all.

Why I’m Even Sharing This

Because building stuff is fun.

But being stuck alone makes it harder.

And I know I’m not the only dev who can ship complex features in 2 hours but can’t pick a font for 2 weeks.

If you feel the same, you’re not alone.

We’re in the same boat, staring at Figma like it’s a final exam.

Thanks for Reading 🙏

If you have even 2 minutes, your design brain cells could save my entire project.

Drop any tips.

Share any inspo.

Tell me what looks weird.

Or just say “yo this looks clean” so I don’t cry.

App: https://snapgroove.vercel.app

Codebase: taqui-786/Snapgroove