DEV Community: Nayim Imrit

How I Built a Full AI Content Pipeline for an iGaming Platform Using n8n, Gemini, Anthropic and Vertex AI

Nayim Imrit — Sun, 27 Sep 2026 06:58:00 +0000

Overview

Running an online casino platform means keeping thousands of game listings, multilingual descriptions, structured reviews and player-facing copy fresh — work that simply doesn't scale by hand. I built the whole production line in n8n, orchestrated across Google Gemini, Anthropic Claude and Vertex AI RAG, with Scrapfly for scraping and Google Cloud Storage for the corpus, all landing in a Payload CMS running on Next.js. Six of the seven workflows are the editorial operation, run by content managers who never see anything but a form; the seventh is a developer harness that exists so engineers can test layouts and the publishing API without hand-filling lorem ipsum.

The seven workflows and what they do:

Casino 1 — Scrapfly scraper. The data ingestion layer. It scrapes casino websites via Scrapfly, converts HTML to clean Markdown, and pushes the content into Google Cloud Storage ready for RAG indexing.
Cloud Storage. A reusable utility subworkflow. Called by other workflows whenever they need to fetch a stored document from GCS. Accepts casino_domain and casino_slug via webhook.
Casino Subworkflow — Vertex RAG. The RAG engine. Handles corpus lookup, filtering and semantic search against Vertex AI. Also reusable — called by the main casino pipeline.
Casino 2 — Main review pipeline. The most complex workflow. Combines Cloud Storage retrieval, Vertex AI RAG, Gemini for structured outline generation, Gemini for section-by-section writing, and Anthropic Claude for multilingual translation. The full end-to-end review factory.
Games. Manages the game catalog: reconciles the Celesta provider list against NovaSpins, deletes stale games, then enriches new ones with Gemini-written descriptions and reviews, provider/tag/bonus taxonomy mapping, and multilingual support. Publishes as Lexical JSON.
Reviews. Form-triggered player review generator. Loops to produce multiple realistic player reviews per casino, with Google Translate plus Gemini post-editing for non-English targets.
Publishing. Not part of the editorial operation — a nine-lane developer harness, one lane per CMS content type, each following the same Schedule Trigger → AI Agent → Lexical conversion → Publish shape. It exists to get real content into a real layout in seconds and to confirm the publishing API still works after a deploy.

Architecture

The whole pipeline in one picture: content ingested from casino sites and source documents, processed through n8n, passed to Gemini, Claude and Vertex AI for generation, held in Cloud Storage and the Vertex RAG index, then assembled, translated, quality-checked, converted to Lexical JSON and published into the Payload CMS running on Next.js.

Every workflow laid out node by node, with the cross-workflow calls drawn as dashed lines — the review pipeline calls the RAG engine and the Cloud Storage utility rather than reimplementing either, while the nine publishing lanes sit alongside the content types they write. The colour coding separates storage and fetch steps from Vertex AI RAG, Gemini, Claude, translation/QA and publish nodes.

Workflow	Purpose
Casino 1 — Scrapfly scraper	Scrape casino pages and prepare raw content for RAG
Cloud Storage — fetch utility	Retrieve and summarise stored documents from GCS
Casino Subworkflow — Vertex RAG	RAG corpus management and semantic search
Casino 2 — main review pipeline	The end-to-end review factory
Games	Catalog reconciliation and AI-generated game content
Reviews	Player review generation from a form submission
Publishing — developer harness	One lane per CMS content type, for layout testing and API verification

The ingestion layer

Two workflows do the plumbing: one pulls content in, the other hands it back out on request.

Casino 1 — Scrapfly scraper

The full Casino 1 canvas: form trigger and domain validation, the Scrapfly → Markdown chain, and the Cloud Storage upload fan-out.

This is the data ingestion layer. A trigger takes a casino domain or a list of URLs, a Code node normalises it and builds the page list, and Scrapfly then fetches each page rendered server-side — the part that matters, because casino sites are JavaScript-heavy and a plain HTTP fetch returns an empty shell. The HTML is converted to clean Markdown, aggregated into one array, and written to Cloud Storage as a .txt, ready to be vectorised and indexed in Vertex AI Search. Validation happens up front: a missing domain stops the run before anything is scraped.

Cloud Storage — the fetch utility

The smallest canvas in the system: a webhook, three guard clauses, and a loop over the file array.

The other half of the plumbing, and deliberately minimal: a webhook accepts casino_domain and casino_slug, guard clauses check the parameters exist and the bucket resolves through a Google Service Account, and the stored Markdown goes back out through Respond to Webhook. It has no ideas of its own, and that's the point — retrieval lives in one place instead of being duplicated across every workflow that needs a document.

The RAG engine

Three corpus POST/response triples across the top, the RAG query path along the bottom.

This is the most technically interesting piece of the system, and the point at which the pipeline stops being "an LLM writing casino copy" and starts being something you can actually trust. It handles every interaction with Vertex AI's RAG corpus — fetching, filtering, and semantic searching — and the review pipeline leans on it twice: once to ground the outline, then again for every section it writes.

Key steps:

Webhook Trigger — Entry point for subworkflow calls.
Validate Parameters — Checks for the required casino-specific parameters, throwing two different Stop and Error nodes depending on which validation fails (general parameters versus casino-specific ones).
Split Out: Extract Corpuses — Splits the list of Vertex AI corpora into individual items for processing.
Filter: Corpus from Parameter — Filters down to only the corpus matching the casino being processed.
If: Parameters Exist — Final gate before querying.
Vertex AI RAG Query — Performs a semantic similarity search against the indexed casino content.
Extract Summary — Parses and returns the top relevant chunks to the parent workflow.

Reusability is the design. Any workflow needing RAG retrieval simply calls this webhook with a corpus and a query. Neither caller nor callee knows anything about the other's internals, which is what keeps the retrieval logic in one place as the corpus grows.

The corpus carries two kinds of truth. The indexed content isn't only operator facts — bonus terms, game catalogues, payment methods, licence details. It also carries the per-country legal and regulatory rules the copy has to comply with. That second kind is what makes the engine genuinely valuable in a regulated market: a review generated for one country can't carry claims that are unlawful in another, and retrieval enforces that without an editor looking the rules up from scratch on every draft. It is the difference between grounding that stops a model inventing bonus terms, and grounding that keeps the output legal.

The review pipeline

The core review pipeline: validation, Gemini/RAG generation, then aggregation and publish.

The centrepiece of the system and its most complex workflow. Everything the previous sections built — the scraped corpus, the stored documents, the RAG engine — converges here into a finished, publish-ready casino review, combining RAG retrieval, structured outline generation, section-by-section writing and multilingual translation.

Trigger

An n8n Form Trigger titled "Casino to Generate Overview" collects the casino domain, slug and target language from an operator. No developer involvement.

Stage 1 — Input validation

Code: Extract Website Domain — Normalises the submitted URL.
Code: Validate URLs — Custom JS validates URL format.
If: Website Domain Exists — Routes valid versus invalid inputs; invalid ones hit Stop and Error: Missing Website.

Stage 2 — Content retrieval

Cloud Storage Subworkflow call — Fetches the existing scraped Markdown content from GCS using the fetch utility.
Vertex RAG Subworkflow call — Queries the relevant Vertex AI corpus, retrieving semantically relevant content chunks for the casino being reviewed, together with the regulatory rules that apply to the target market. Both reach the model in the same retrieval step, which is what keeps a review compliant for its country without an editor looking the rules up separately.

Stage 3 — Gemini outline generation

Gemini API: Generate Outline — Given the retrieved content, Gemini produces a structured outline for the casino review (sections like Welcome Bonus, Game Selection, Payments, and so on).

Stage 4 — Section-by-section writing

Gemini RAG Query per Section — For each section in the outline, Gemini is called again with a targeted RAG query to fetch the most relevant source material.
Gemini: Write Section Content — Each section is written using both the outline and the retrieved context, which is what keeps it factually grounded.

Stage 5 — Translation with Anthropic Claude

If: Language != 'en' — If the target language is not English, the content is routed to the translation branch.
Anthropic Claude: Translate Sections — Claude handles nuanced multilingual translation of each section, preserving tone and iGaming terminology.
Merge translated and non-translated — Both branches converge before final publishing.

Stage 6 — Publishing

The final structured review is assembled and sent to the NovaSpins backend API.

This workflow is the clearest example of multi-model AI orchestration in the system: Gemini handles research and writing, Claude handles translation, and Vertex AI RAG provides the factual grounding.

Games catalog

Reconciliation feeds the enrichment webhook, which fans out into Gemini search, review and description branches.

This workflow keeps the NovaSpins game library in sync with the upstream provider (Celesta) — and unlike everything else in the system, it deletes as well as creates.

Reconciliation. A scheduled run pulls the full Celesta list and the current live list, then hands both to Gemini to diff. What comes back isn't text but a decision: which games to add, which to remove. The workflow acts on the removals with a DELETE call. Treating catalog maintenance as a reconciliation problem rather than a content problem is the interesting part — the model is being used as a comparator, not a writer, and its output drives state changes on the platform.

Enrichment. Each new game fans out through Gemini for the game's details (RTP, volatility, features, provider), a full written review, and a shorter SEO description. Non-English targets go through Google Translate and then Gemini again as a post-editor. Finally the workflow resolves taxonomy relationships — provider, tags, casinos, bonuses — fetching the existing entries and creating any that are missing, so a newly published game arrives already linked into the catalog instead of as an orphan record.

Player reviews

The review pipeline's validation front-end, with a multi-result player-review loop in place of the review stages.

A form-triggered generator for player-perspective reviews — the first-person kind you'd see on a comparison site. It validates the domain, then loops a Gemini call to produce several reviews per casino rather than one, and for non-English targets passes each through Google Translate with Gemini post-editing. The reviews are aggregated into a single payload and emitted as JSON, ready to publish.

The developer harness

Nine publishing lanes on one canvas, each wrapping the same Schedule Trigger → AI Agent → Lexical → Publish shape.

This one is not part of the editorial operation. Where the other six workflows each own a single pipeline, this packs nine independent lanes into one canvas — one per content type the CMS accepts, 54 nodes in total — all sharing the same four-stage shape: Schedule Trigger → AI Agent → Markdown-to-Lexical → Publish. Engineers run it by hand to get real content into a real layout within seconds, and to confirm the publishing API still behaves after a deploy; nothing it produces is meant to be read by a player.

Lane	Trigger	Model	Endpoint
Casino article	`Schedule Trigger Post Test Casino n8n`	Claude Sonnet 4.6	`POST /api/casinos/`
Casino update	`Schedule Trigger n8n casino update`	Gemini 3 Flash	`PATCH /api/casinos/{id}`
Casino review	`Schedule Trigger n8n review Update`	Gemini 3 Flash	`PATCH /api/casinos/{id}`
Bonus	`Schedule Trigger Post Bonus`	Gemini 3 Flash	`POST /api/bonuses`
Game	`Schedule Trigger Games n8n`	Gemini 3 Flash	`POST /api/games/`
Guide	`Schedule Trigger Guides n8n`	Gemini 3 Flash	`POST /api/guides/`
News	`Schedule Trigger News n8n`	Gemini 3 Flash	`POST /api/news/`
Guest review	`Schedule Trigger Review Casino`	(none — static payload)	`POST /api/reviews/`
User review	`Schedule Trigger Review Casino jr letto`	(none — static payload)	`POST /api/reviews/`

Six lanes run on models/gemini-3-flash-preview. The exception is the casino-article lane, wired to claude-sonnet-4-6 — the same split between Gemini for volume and Claude for the high-value piece that runs through the rest of the system.

Where the content lands: the CMS

Everything above is the production side. The workflows write into a Payload CMS — a Next.js application hosted on AWS — that holds both the content and the taxonomy it hangs off.

The Payload admin. Collections map onto what the workflows post to, and the System Data block supplies the UUIDs they reference.

The Casinos collection — records created by the workflows, not typed by hand.

The same records rendering on the public site: the homepage casino cards block.

The comparison row — welcome offer, payment methods, withdrawal speed, RTP range and providers, all separate fields rather than free text.

News and guides, through the same pipeline.

Stack

Layer	Technology
Orchestration	n8n (self-hosted)
AI Writing & Reasoning	Google Gemini (via Vertex AI API)
AI Translation QA	Google Gemini
AI Translation (multilingual)	Anthropic Claude
Semantic Search / RAG	Vertex AI Search & Conversation (RAG)
Document Storage	Google Cloud Storage
Web Scraping	Scrapfly
Auth	Google Service Account (OAuth2)
CMS	Payload CMS (headless)
Frontend	Next.js
Hosting	AWS
Content Format	Lexical JSON (Payload rich text)
Platform API	NovaSpins REST API

Conclusion

This system replaced what would otherwise be weeks of manual content work per month. It handles game catalog management, casino review writing, player review generation and multilingual localisation — all triggered from simple forms or schedules, with no developer intervention required for routine runs. It also ended up serving two very different audiences from one codebase: content managers, who only ever see a form, and engineers, who kept a harness workflow for testing layouts and the API.

Two decisions did most of the work. The first was modularity over monoliths — giving every workflow a single responsibility, and factoring the RAG engine and the Cloud Storage fetch into reusable subworkflows the review pipeline calls rather than copies. That is what makes the system cheap to extend: a new content type means a new lane, not a rebuilt pipeline. The second was RAG for factual grounding — never letting a model invent casino details when retrieval can supply them. Because the corpus holds both operator facts and the per-country regulatory rules, a non-lawyer operator can generate market-appropriate copy without a compliance review on every draft.

The key insight is that n8n is not just a task runner — it's a workflow orchestration layer that lets you compose AI APIs, storage services and platform APIs into coherent, maintainable pipelines. Combined with the right models and a RAG backbone for factual grounding, it becomes a serious content production engine.

If you're building content automation for a platform with a large and dynamic catalog, this modular approach — scrape → store → retrieve → generate → translate → publish — is a pattern worth stealing.

How I Built a Fully Automated Brand Abuse Detection & DMCA Pipeline in n8n

Nayim Imrit — Sun, 13 Sep 2026 06:16:41 +0000

No lawyers on retainer. No manual monitoring. Just a scheduler, two search APIs, and some very strongly worded emails — sent automatically.

The problem

A client runs multiple brands online. One day they noticed a clone of their app on the Play Store — same name, similar icon, fake reviews. They'd had it for weeks without knowing.

That's when I realized: brand abuse is quiet. Clones, impersonator websites, and fake apps don't announce themselves. By the time you find them, the damage is done — lost revenue, confused users, diluted SEO.

The traditional fix? Hire an IP firm to monitor manually, or pay for expensive brand protection SaaS. Neither option made sense for an agency managing multiple mid-size brands.

So I built my own — in n8n, over a few weekends.

What the system does

Three workflows, chained together, running silently on a schedule:

Workflow A — Scans Google/Bing search results and app stores for unauthorized use of brand names
Workflow C — Enriches each detection with registrar and hosting data via RDAP
Workflow B — Generates and sends legally-structured DMCA takedown notices to the right targets, automatically

From detection to takedown notice: zero human intervention.

Why two search APIs instead of one

This is the architectural decision I get asked about most, so let me address it upfront.

I use Monitorank for web search (Google and Bing SERPs) and DataForSEO for app store searches (Google Play and Apple App Store). Not because I couldn't find a single API that does both — but because each one is genuinely better at what it does.

Monitorank is built specifically for SERP monitoring. It handles ranking data cleanly, supports geolocation, and gives reliable results for web search across desktop and mobile. It was the natural fit for catching impersonator websites showing up in organic search.

DataForSEO is where I go for app store data. Its Play Store and App Store search APIs are more mature, return richer metadata (developer name, ratings, install counts), and the async task model (task_post → wait → task_get) handles rate limits gracefully without me having to engineer a retry system from scratch.

Using both means the pipeline covers the full surface area of brand abuse — web and mobile — without compromising on data quality in either channel.

How Workflow A works

Workflow A is the detection engine. It runs on a schedule, reads a list of active brands from a Google Sheet (config_brands), and loops through each one.

For each brand, it runs two parallel tracks:

Web search via Monitorank — brand search terms are batched and sent to the Monitorank API. Results come back as ranked URLs, which get filtered and deduped against previously known detections in the sheet.

App store search via DataForSEO — two parallel requests hit the Google Play and Apple App Store endpoints. DataForSEO's async model means I post the task, wait for it to complete, then fetch the results. This is more reliable than hitting the live endpoint and hoping for a fast response.

After both tracks complete, every surviving URL gets a live 404 check. If the infringing page is already gone, there's nothing to do — it gets dropped before it ever reaches enrichment. Only live detections make it forward.

New findings get appended to the detections sheet, and a Gmail alert fires summarizing what was found.

How Workflow C works (RDAP enrichment)

Before you can send a DMCA notice anywhere useful, you need to know who to send it to. That's Workflow C's job.

For each new detection, it runs three lookups in sequence:

RDAP domain lookup (rdap.org/domain/{domain}) — returns the registrar, registration date, and crucially, the registrar's abuse contact email
DNS A record lookup (dns.google/resolve) — resolves the domain to an IP address
RDAP IP lookup (rdap.org/ip/{ip}) — identifies who is hosting that IP and their abuse contact

The results get written back to the detections sheet, filling in registrar_abuse_email and hosting_abuse_email.

One gotcha here: RDAP APIs are public infrastructure and rate-limited. I added a wait node between detections to pace the loop — without it, you'll start getting throttled and silently losing data.

How Workflow B works (DMCA sending)

Workflow B is where it gets interesting. It takes the enriched detections and builds the actual takedown notices.

Smart routing by source — the target of a DMCA notice depends on where the abuse was found:

Source	Emails sent to
Google SERP	Google DMCA agent + registrar + hosting
Bing SERP	Microsoft DMCA agent + registrar + hosting
Google Play	Google DMCA agent + registrar
Apple App Store	Apple copyright agent (with CC) + registrar

Domain grouping — if the same rogue domain has five infringing URLs, they all get bundled into one complaint rather than five separate emails. This is both more professional and less likely to get marked as spam.

Two sending modes — brands can configure whether notices go out directly in their name (direct) or signed by an agency acting on their behalf (on_behalf_of). The email template adjusts accordingly, pulling complainant or agent details from the config sheet.

Auto-send gate — each brand has an auto_send flag. If it's off, the detection gets marked skipped and nothing is sent. This lets cautious clients review detections before any emails go out.

Every sent notice gets logged to a complaints sheet with a follow_up_date set 10 days out.

Lessons learned

Filter aggressively before sending. Early versions of the pipeline sent notices to hosting providers like Google Cloud and Akamai for domains they just happened to host. Those abuse desks ignore automated notices instantly. I added a filter to skip known CDN and hyperscaler abuse emails — they're useless targets.

Dedup at multiple stages. I deduplicate at the detection level (to avoid re-reporting known infringers), at the domain level (to group URLs into one complaint), and again after sending (to update individual detection IDs back to complaint_sent). Skipping any of these layers causes duplicate emails, which undermines your credibility.

RDAP returns inconsistent formats. Some registrars follow the spec cleanly, others return abuse contacts buried in nested entities, and some return nothing at all. The parsing code needs to handle all three gracefully — don't assume the field you want is where the spec says it should be.

Build in the auto_send flag from day one. I almost shipped without it. It seems like overhead until the first false positive, at which point it becomes the most important feature in the system.

The tech stack

n8n (self-hosted) — orchestration
Monitorank API — web SERP monitoring
DataForSEO API — app store search
rdap.org + dns.google — domain/IP enrichment
Gmail — outbound DMCA notices
Google Sheets — config, detections, complaints log

No database, no custom backend. The whole thing runs on n8n and a spreadsheet.

What's next

The system handles detection and first-contact takedown well. What it doesn't do yet:

Follow-up tracking — the follow_up_date column is there, but I haven't built the follow-up workflow yet
Response parsing — when a registrar replies, someone still has to read it
Counter-notice handling — if a takedown gets disputed, that's currently a manual process

These are Workflow D and beyond. For now, the pipeline catches real abusers, sends legally-sound notices automatically, and has saved my client hundreds of hours of manual monitoring.

If you're managing brand protection for multiple clients and doing this by hand, it's worth automating. The hardest part is the first detection — everything after that is plumbing.

Built with n8n. Questions? Drop them in the comments.

Using MonkeyCode 30M Free Tokens and Asked It to Build Tic-Tac-Toe — Here's What Happened

Nayim Imrit — Sun, 30 Aug 2026 12:33:53 +0000

I tested MonkeyCode with its daily free token quota and DeepSeek-V4-Flash by giving it a complete front-end development task, then asked it to publish the result to GitHub.

What happens when you give an AI coding agent a fairly detailed software specification and let it actually build the project instead of just generating snippets?

I decided to find out.

For this experiment, I used MonkeyCode with DeepSeek-V4-Flash and its roughly 30M-free-token daily quota available in my account.

My goal was deliberately simple:

Build a complete Tic-Tac-Toe web application from scratch, make it functional, preview it, and then push the finished project to GitHub.

The interesting part wasn't the game itself.

It was watching how much work the agent could perform autonomously — from creating files and implementing the UI to testing the application and eventually publishing the project to my GitHub repository.

The experiment

I wanted to test MonkeyCode with something slightly more demanding than:

"Create a Tic-Tac-Toe game."

Instead, I gave it an actual development specification.

The requirements included:

Vanilla HTML
CSS
Modern JavaScript
No frameworks
No npm dependencies
Responsive design
Dark/light mode
Player vs Player
Player vs AI
Easy AI
Unbeatable Minimax AI
Undo functionality
Win detection
Draw detection
Persistent scoreboard
localStorage
Animations
Complete README documentation

And I explicitly asked it to create:

index.html
styles.css
script.js
README.md

The application also needed to work directly in a browser without a build process.

That made it a nice little benchmark for an AI coding agent.

The prompt

This is the exact prompt I used.

Act as a front-end web developer. Create a lightweight, single-page Tic-Tac-Toe web application using ONLY vanilla HTML, CSS, and modern JavaScript, and update the project's README.md file.

### Technical Guidelines & Rules
1. Tech Stack Constraints:
   - Use standard HTML5, CSS3, and modern Vanilla ES6+ JavaScript.
   - NO external frameworks (React, Next.js, Vue, Tailwind, etc.).
   - Keep it zero-dependency: output files must run directly in a standard web browser without build tools or npm dependencies.

2. File Structure:
   - index.html — Clean, semantic structure.
   - styles.css — Responsive design using Flexbox/Grid, CSS custom variables (for themes), smooth transitions, and a clean modern aesthetic (dark theme default).
   - script.js — Modular, cleanly formatted JavaScript handling game state, UI rendering, event listeners, and AI logic.
   - README.md — Complete documentation.

3. Core Gameplay & Features:
   - Game Modes:
     - Player vs. Player (Local 2-player)
     - Player vs. AI (Include a toggle for Easy AI vs. Unbeatable Minimax AI).
   - Game Mechanics:
     - Interactive 3x3 grid with hover indicators and clear click feedback.
     - Turn indicator display showing active player (X or O).
     - Move History / Undo last move functionality.
     - Automatic win detection with a visual highlight/line on winning cells.
     - Draw detection.
     - Scoreboard (X Wins, O Wins, Ties) persisted in browser localStorage.
     - Reset Board button & Clear Scoreboard button.
   - UI Polish:
     - Light/Dark mode toggle switch.
     - Smooth animations for marking X and O.

4. Documentation Requirement:
   - Create or completely update README.md in the project root containing:
     - Overview
     - Features
     - File Structure
     - How to Run
     - AI Logic Explained
     - Brief explanation of the Minimax decision algorithm.

Generate all files (index.html, styles.css, script.js, and README.md) with fully functional, clean, and well-commented code.

I intentionally made the prompt detailed.

I wanted to see whether the agent could follow a specification rather than simply produce something that looked like a Tic-Tac-Toe game.

What MonkeyCode did

After submitting the task, MonkeyCode started working through the requirements.

The workflow was interesting because it wasn't just one giant response containing four code blocks.

The agent went through individual tasks and file operations.

It started by planning the implementation and then created the project files.

Here it is in action:

Notice how the interface exposes individual steps as they execute: planning first, then each file in sequence, then running a preview. That stepped visibility is one of the things that makes an agent feel meaningfully different from a chatbot.

The workflow looked roughly like this:

Task
 ↓
Planning
 ↓
Create index.html
 ↓
Create styles.css
 ↓
Create script.js
 ↓
Create/update README.md
 ↓
Run / preview application
 ↓
Inspect result
 ↓
Publish to GitHub

You're not simply asking:

"Give me the code."

You're effectively delegating a development task.

The generated application

The result was a complete zero-dependency Tic-Tac-Toe application.

The repository contains:

tik-tak-toe_monkeyCode/
│
├── index.html
├── styles.css
├── script.js
├── README.md
└── LICENSE

The generated README documented the Minimax implementation and the different game modes.

The GitHub repository is publicly available here:

https://github.com/Nayim-Imrit/tik-tak-toe_monkeyCode

(Note: the repo slug uses "tik-tak-toe" — that's intentional, not a typo.)

And yes, the game actually worked

This was the most important part of the test.

The generated application wasn't just visually complete.

I could actually run it in the browser.

The preview worked, and the core functionality was there:

2-player mode
AI mode
Easy AI
Minimax AI
Score tracking
Undo
Reset
Dark/light theme
Persistent scores
Responsive interface

For a task that started with one natural-language instruction, that was a pretty good result.

The token consumption surprised me

This is where the experiment became more interesting.

The platform gave me approximately 30 million free tokens per day.

And I decided to actually use them.

You can see the live quota counter in the GIF above — at the point I captured it, the interface showed:

Daily quota: ~30M

By the time the full task completed — application created, previewed, and pushed to GitHub — the quota had dropped to approximately 27M, meaning the entire workflow consumed roughly 3 million tokens.

That sounds enormous for a Tic-Tac-Toe game.

And honestly, it is.

But there's an important distinction.

The token usage isn't simply:

My prompt → 3M tokens → Tic-Tac-Toe

An agent performing software-development work can repeatedly interact with its environment:

Read
 ↓
Think
 ↓
Edit
 ↓
Inspect
 ↓
Run
 ↓
Check
 ↓
Fix
 ↓
Repeat

Every one of those interactions can contribute to the total context and token consumption.

That's fundamentally different from asking a normal chatbot to generate four files once.

3 million tokens for a small project is still a lot. A more efficient agent should minimize unnecessary file re-reads, avoid redundant context and reduce iterations. This is something I'll be tracking closely in future experiments — token efficiency matters as much as output quality.

The GitHub test

After the application was working, I gave MonkeyCode another task:

Push the project to my GitHub repository.

The target repository was:

Nayim-Imrit/tik-tak-toe_monkeyCode

The agent handled the repository workflow and the finished project ended up on GitHub.

This was an important part of my test.

Generating code is one thing.

Getting an agent to work with an actual development environment and source-control workflow is another.

Why this feels different from ChatGPT generating code

This experiment made me think about the difference between an AI assistant and an AI coding agent.

A traditional coding assistant might do something like:

Developer
   ↓
Ask for code
   ↓
AI generates code
   ↓
Developer copies code
   ↓
Developer creates files
   ↓
Developer runs application
   ↓
Developer fixes errors
   ↓
Developer commits

An agent can potentially move more of that workflow into the AI environment:

Developer
   ↓
Specification
   ↓
AI Agent
   ├── Creates files
   ├── Edits files
   ├── Runs commands
   ├── Checks results
   ├── Iterates
   └── Publishes changes

That's the real thing I wanted to test.

Not:

"Can AI write JavaScript?"

We already know it can.

The more interesting question is:

How much of the development workflow can an AI agent actually execute for you?

DeepSeek-V4-Flash is an interesting model for this

The timing of this experiment was also interesting because DeepSeek-V4-Flash had recently been released.

DeepSeek describes V4-Flash as the faster, more cost-efficient member of the V4 family, built with a strong focus on agentic tasks — meaning it's designed for exactly this kind of multi-step, tool-using workflow rather than single-turn generation. In practice, that showed up in the planning phase: rather than immediately generating code, it broke the task down into discrete file operations first.

That's why I wanted to run an actual task instead of just reading the benchmark numbers.

My test wasn't a benchmark

I want to make this distinction very clear.

This wasn't a scientific comparison between:

DeepSeek
Claude
GPT
Gemini
GLM

I wasn't measuring:

tokens per second
latency
benchmark scores
coding accuracy across 100 repositories
cost per accepted pull request

It was a practical experiment:

Give an AI coding agent a realistic specification and see what happens.

And for that particular task, the result was surprisingly good.

What I liked

The agent understood a detailed specification

The prompt contained a lot of requirements.

It wasn't just:

"Make Tic-Tac-Toe."

It specified architecture, technology restrictions, features, documentation and AI behavior.

The generated repository followed those requirements reasonably well.

Zero-dependency development worked well

I deliberately prohibited:

React
Next.js
Vue
Tailwind
npm
build tools

The result remained:

HTML
CSS
JavaScript

That made the application extremely portable.

You can simply open:

index.html

in a browser.

The Minimax implementation was documented

This was a nice detail.

The README didn't simply say:

"The AI uses Minimax."

It explained the basic idea:

Current board
     ↓
Possible moves
     ↓
Opponent responses
     ↓
Future states
     ↓
Score positions
     ↓
Choose best move

For Tic-Tac-Toe, the game tree is small enough that exhaustive search is perfectly practical.

Token consumption is a real concern

Nearly 3 million tokens for a relatively small application is a lot.

Even though the daily quota is huge, developers should not automatically assume:

More tokens = better result.

Agent efficiency matters.

A better agent should ideally minimize unnecessary context, repeated file reads and redundant iterations.

This is something I've become increasingly interested in: token-efficient AI development workflows.

If an agent repeatedly reads the same files, re-evaluates the same architecture and regenerates context unnecessarily, the cost can grow very quickly.

For production use, this isn't just a curiosity — it's a real cost and performance factor.

The local agent idea is even more interesting

The part that really caught my attention is what happens when you move beyond a browser-based coding environment.

The broader idea is to run an AI development agent locally on your own machine, connect it to tools, repositories and services, and give it controlled permissions.

Conceptually:

                 ┌───────────────┐
                 │   AI Model    │
                 │ DeepSeek/GPT  │
                 │ Claude/GLM... │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
      Filesystem       GitHub          MCP
          │              │              │
          ▼              ▼              ▼
       Laptop         Repositories     Tools

Instead of:

"AI, tell me what command I should run."

You can move toward:

"AI, implement this feature, run the tests, inspect the result and create the commit."

Obviously, this comes with an important warning:

Don't give an autonomous agent unrestricted access to your machine.

Permissions matter.

Credentials matter.

Repository access matters.

Tool integrations can potentially give an agent the ability to do much more than edit a source file.

The principle should always be least privilege.

What about connecting other AI subscriptions?

This is another direction that I find interesting.

Instead of thinking:

"Which AI coding tool should I use?"

we can start thinking:

"Which model should handle which task?"

For example:

Simple coding task
        ↓
DeepSeek V4-Flash

Complex reasoning
        ↓
GPT / Claude

Large refactoring
        ↓
Another specialized model

Local/private task
        ↓
Local open-weight model

This creates the possibility of treating AI models almost like interchangeable compute providers.

The agent becomes the orchestration layer.

The model becomes the engine.

That separation is potentially much more interesting than simply choosing one AI subscription and using it for everything.

So, is MonkeyCode worth trying?

Based on this experiment:

Yes — if you're interested in AI agents rather than just AI chat.

The Tic-Tac-Toe project isn't impressive because Tic-Tac-Toe is difficult.

It's interesting because I gave the system a specification and it was able to turn that specification into:

Requirements
     ↓
Implementation
     ↓
Files
     ↓
Working application
     ↓
Documentation
     ↓
Git repository

with very little manual intervention from me.

That's the direction AI-assisted development is moving toward.

But there's still a long way to go

I wouldn't use this one experiment to conclude that AI coding agents can replace developers.

They can't.

At least, that's not what this test demonstrates.

The developer is still responsible for:

Defining the requirements
Reviewing the generated code
Validating behavior
Checking security
Reviewing dependencies
Managing credentials
Controlling permissions
Testing edge cases
Reviewing Git changes
Deciding whether the solution is actually production-ready

The agent can execute.

The developer still needs to judge.

And that distinction is important.

Final thoughts

My first MonkeyCode experiment was intentionally small.

A Tic-Tac-Toe game.

Four main files.

Vanilla JavaScript.

No backend.

No database.

No external APIs.

Yet the agent was able to take the specification, implement the application, provide a working preview and eventually get the project into GitHub.

The most interesting number wasn't actually the 30M token quota.

It was the fact that an AI agent consumed roughly 3 million tokens of that budget while doing real development work — planning, creating, iterating, previewing, committing.

That raises a much more interesting question for my next experiment:

What happens when I give the same agent a real full-stack application?

Something with:

Next.js
PostgreSQL
Authentication
APIs
Database migrations
Tests
Docker
GitHub
CI/CD

And then measure:

How many tokens does it take?

How many iterations does it need?

How much code does it generate?

How much of the work actually needs human intervention?

That's a much more interesting benchmark.

The project

GitHub: https://github.com/Nayim-Imrit/tik-tak-toe_monkeyCode

The repository contains the generated HTML, CSS, JavaScript and README documentation.

What should I test next?

I'm thinking of taking this experiment much further.

Instead of Tic-Tac-Toe, give an AI coding agent a real full-stack application and track the entire process.
If you'd like to see that experiment, let me know what kind of application I should throw at it. 🚀

How I Cut LLM Token Usage with OKF, CLAUDE.md, and Skills

Nayim Imrit — Sun, 16 Aug 2026 06:35:00 +0000

Every time you ask an AI coding assistant a question, it often starts from scratch.

"Where is authentication implemented?"

"Who calls UserService?"

"How does this API flow work?"

Instead of remembering your architecture, the model crawls dozens of files again. That means more tokens, higher cost, slower responses, and more opportunities for hallucinations.

After experimenting with AI-assisted development, I found that the biggest optimization isn't choosing a different model --- it's changing what you send to the model.

This article covers a layered workflow for making AI agents dramatically more efficient using OKF, persistent project memory, on-demand skills, and token compression.

Why token optimization matters

LLMs don't read code the way humans do. Everything becomes tokens processed through transformer layers.

Every unnecessary file, log, or repeated explanation increases:

💰 Cost (for paid APIs)
⏱️ Latency
🧠 Context window usage
❌ Risk of losing important information

The goal isn't to provide less context. It's to provide better structured context.

Layer 1: Replace raw code with structured knowledge

The biggest improvement comes from avoiding repeated file reads entirely.

Instead of feeding an LLM your repository every session, generate a knowledge bundle once and let the agent query that instead. This is the core idea behind OKF (Optimised Knowledge Format). It extracts your project's architecture --- classes, functions, APIs, relationships, and modules --- into structured Markdown that both humans and AI agents can navigate efficiently.

Traditional workflow:

Question
│
▼
Read 40 files
│
▼
Understand architecture
│
▼
Answer

OKF workflow:

Question
│
▼
Read knowledge bundle
│
▼
Jump directly to implementation
│
▼
Answer

The difference is simple:

Without OKF	With OKF
Re-reads source files	Queries structured concepts
Large token usage	Small, focused context
Slower reasoning	Faster navigation
Architecture rediscovered every session	Architecture indexed once

Meet OKF Generator

The easiest way to generate these knowledge bundles is with OKF Generator, an open-source CLI that scans a repository and produces an OKF bundle using static analysis --- no LLM required. It supports incremental updates, agent integrations, and even a zero-LLM workflow where you can generate and query bundles entirely offline.

GitHub: https://github.com/UmairBaig8/okf-generator

Getting started:

pip install okf-generator

# Generate your first bundle
okf generate

# Update it after new changes
okf update

# Install integrations for AI agents
okf install all

Once generated, point your agent to the bundle instead of your entire repository. The bundle is plain Markdown, version-controllable, and designed to live alongside your source code.

Not Just Claude: OKF Works With Any Agent

OKF goes beyond token optimization. When onboarding developers to a large codebase, you can give any LLM the generated okf_bundle and ask it to explain the project, identify key components and their relationships, and generate a Mermaid diagram.

This provides a quick, high-level overview of the codebase and can significantly reduce onboarding time.

For this example, using a local LLM(gpt-oss20b), I asked it to analyze C:\Code\uigen\okf_bundle and generate a Mermaid diagram with an explanation of the project's key components and how they interact.

All the components, explanations, and web flow were generated in less than 2 minutes.

Layer 2: Give your project a memory (CLAUDE.md)

Most developers repeatedly explain the same things:

How to run the project
Coding conventions
Folder structure
Architectural decisions

That information belongs in CLAUDE.md, a persistent Markdown file automatically loaded at the beginning of every session. It eliminates repeated briefings and keeps foundational project knowledge available without bloating every prompt.

A good CLAUDE.md contains:

# Project Rules

- Use pnpm instead of npm

This project has an OKF knowledge bundle at ./okf_bundle/.
- Use `okf lookup <Name>` for full concept context.
- Use `okf lookup --type <Type>` to filter by type.
- Read `SUMMARY.md` for the full knowledge map.

Instead of repeating these instructions across conversations, they're loaded automatically.

File locations:

# Project-level
./CLAUDE.md
./.claude/CLAUDE.md
# User-level
~/.claude/CLAUDE.md

Layer 3: Load knowledge only when needed (Skills)

Not everything deserves permanent context.

Deployment guides, review checklists, compliance docs, and long API references are better stored as Skills. Skills are reusable SKILL.md files that stay out of the main context until the task requires them, keeping the default prompt lean while still making detailed workflows instantly available.

Good examples include:

/deploy
/release
/review
/database-migration

Your default context stays small, but expertise is always one command away.

File locations:

.claude/skills/<name>/SKILL.md
# or
~/.claude/skills/<name>/SKILL.md

Layer 4: Automate consistency with Hooks

Hooks aren't about saving tokens directly. They're about preventing expensive mistakes.

Examples:

Auto-format after every edit
Block dangerous shell commands
Notify you when an agent finishes
Run linting automatically

Since hooks fire at predefined lifecycle events, they remove repetitive instructions from your prompts entirely.

File locations:

.claude/settings.json
# or
~/.claude/settings.json

Keep your knowledge bundle up to date

A stale architecture is almost as bad as no architecture.

You can regenerate your OKF bundle automatically using GitHub Actions whenever someone pushes to main or opens a pull request. The workflow keeps your AI context synchronized with your codebase and can even generate impact summaries for reviews.

name: OKF Bundle

on:
  push:
    branches: [main]

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install okf-generator
      - run: okf generate . okf_bundle

Now your AI always understands the latest architecture.

Reduce output tokens too

Optimizing input is only half the story.

Two complementary tools solve different problems:

Tool	Optimizes
OKF	What the model reads
caveman	What the model writes
rtk	Terminal and tool output

If your context is filled with git diff, build logs, or test output, rtk trims that before it ever reaches the model. If your assistant tends to produce verbose explanations, caveman keeps responses concise. Together they reduce both sides of the token equation.

The complete token-efficient workflow

Each layer removes a different source of waste:

Layer	What it eliminates
OKF	Re-reading source files
CLAUDE.md	Repeating project briefings
Skills	Loading reference docs unnecessarily
Hooks	Repeating operational instructions
caveman / rtk	Verbose output and noisy logs

Final thoughts

The future of AI development isn't about endlessly increasing context windows. It's about making context intentional.

A well-structured repository gives AI assistants the same advantage it gives human developers: they spend less time searching and more time solving problems.

If you're already using Claude Code, Cursor, Copilot, or another AI coding assistant, try generating an OKF bundle for your next project. You'll probably notice the difference long before you notice the token savings.

Resources

If you've been experimenting with token optimization or AI developer workflows, I'd love to hear what's working for you in the comments.

Testing 3 Local LLMs on a CPU-Only Laptop — Here's What Actually Happened

Nayim Imrit — Wed, 05 Aug 2026 08:29:51 +0000

As developers, we keep hearing that powerful LLMs require expensive GPUs. I wanted to find out how far local AI could actually go on a modest machine — no cloud, no cost, no GPU.

So I ran a practical experiment using LM Studio on a 40 GB RAM laptop without a dedicated GPU, pitting three open-weight models against each other on a real coding task.

Test Environment

Hardware

Standard laptop
40 GB RAM
No dedicated GPU (CPU inference only)

Software

LM Studio (context length: 8192 tokens)
VS Code
100% local inference — no API calls, no internet required

Models tested

Qwen 3 14B
GPT-OSS 20B
Gemma 4 26B A4B QAT

The Experiment

Each model received the exact same prompt: generate a complete Snake Game using only HTML, CSS, and JavaScript — no frameworks, no external libraries.

I evaluated each result on:

⏱ Generation time
🪙 Token usage
🎨 Quality of the generated UI
🔧 Whether manual corrections were needed
🧑‍💻 Overall developer experience

Results

🟡 Qwen 3 14B

Generation took approximately 9 minutes and produced 3 separate files (HTML, CSS, JS).

After testing, the snake moved too fast. I had to send a follow-up prompt, which triggered another full 9-minute generation cycle — and only around five lines of code actually changed.

Pros

Functional game on the second attempt
Game instructions included
Low token usage (~651)

Cons

Slow generation
Required a second iteration to fix gameplay speed
Basic UI

🟢 GPT-OSS 20B

This was the biggest surprise of the experiment.

Generation completed in approximately 3 minutes, producing a single self-contained HTML file with all HTML, CSS, and JS included. Token usage clocked in at ~51 — significantly lower than the other models (worth noting: token counting may differ across models, so treat this as directional rather than a strict apples-to-apples comparison).

Unlike Qwen, the game worked correctly on the first attempt.

Pros

Fastest generation by far
Lowest token usage
No code changes required
Score displayed during gameplay
Instructions included

Cons

UI is functional but not the most polished

🔵 Gemma 4 26B A4B QAT

Gemma required some extra setup before running correctly — specifically, adding capability entries in LM Studio's model configuration. If you're not comfortable editing model configs, budget a few extra minutes here.

Generation took approximately 8 minutes and produced 3 files (HTML, CSS, JS).

The output was noticeably more polished visually than the other two models.

Pros

Best-looking interface of the three
Well-structured project output
Instructions included

Cons

Highest token usage (~2170)
Slower than GPT-OSS
Requires extra LM Studio configuration

Comparison Table

Model	Time	Files	Tokens	UI Quality	Needed Changes
GPT-OSS 20B	~3 min	1	~51	Good	❌ No
Gemma 4 26B	~8 min	3	~2170	⭐ Best	❌ No
Qwen 3 14B	~9 min	3	~651	Basic	✅ Yes

Key Observations

A few patterns stood out:

GPT-OSS prioritised efficiency — working code, fast, no fuss.
Gemma prioritised presentation — the cleanest interface, though it needs configuration upfront.
Qwen produced functional code but needed a second pass to be usable.
All three models completed a real coding task without touching the cloud.

Conclusion

For my workflow, GPT-OSS was the clear winner.

Gemma produced the most polished result, but GPT-OSS delivered the best overall developer experience:

✅ Fastest generation time

✅ Lowest token consumption

✅ Working solution on the first attempt

✅ Zero additional configuration

✅ Single-file output — easy to review and ship

On CPU-only hardware, these differences compound quickly. Waiting 3 minutes instead of 9 — and skipping multiple iterations — makes a real difference to your flow.

More broadly, this experiment shows how capable modern open-weight models have become. Even on a mid-range laptop with no GPU, you can generate complete applications locally, maintain full privacy, and avoid cloud inference costs entirely.

If you've tested local models on constrained hardware, I'd love to hear what you found — drop a comment below. 👇

Tested with LM Studio on a 40 GB RAM, CPU-only laptop. Models: GPT-OSS 20B, Qwen 3 14B, Gemma 4 26B A4B QAT.

Building a PHP Wedding Planner with Omniroute: My First Experience

Nayim Imrit — Sun, 26 Jul 2026 10:16:36 +0000

I tested an AI coding agent with a real university project spec — here's exactly what happened, token by token.

Artificial Intelligence is rapidly changing how we build software. Instead of spending hours scaffolding projects or writing repetitive boilerplate code, AI coding agents are now capable of planning, generating, and even refining applications with minimal input.

Recently, I had the opportunity to test Omniroute while helping a friend with her final-year university project. She already had a detailed project specification and needed a working PHP template to kick-start her development. Since I had never worked with Twig templating before, I decided this would be the perfect opportunity to see how far an AI-assisted development workflow could go.

This article shares my experience — from setting up Omniroute to generating a complete project and evaluating the results.

🛠️ Setting Up Omniroute

I already had an old Claude API key with approximately $0.20 of credit remaining, so I decided to use it for this experiment.

To install and configure Omniroute, I followed this setup tutorial:

After following the installation steps, my directory structure looked like this:

⚙️ Improving the AI's Coding Standards

One feature I particularly liked was Omniroute's ability to customise the AI's behaviour through the .agent configuration file.

I configured Claude with modern development guidance so that it would generate code following current best practices instead of relying on outdated programming patterns.

I used the following guide as inspiration:

🔗 How to Stop Your AI Coding Agent from Writing Outdated Code with Modern Web Guidance

Tip: Although this step is optional, I would highly recommend it. Small improvements to the agent's instructions can significantly improve the quality and consistency of the generated code.

📋 Preparing the Project

My friend had already written all of the project requirements, including both the functional and non-functional specifications.

I created a new project folder called wedmauritius inside my XAMPP htdocs directory and copied her requirements into a file named:

newProjectRequirement.txt

Once everything was ready, I simply asked Claude whether it could access and understand the requirements document.

Instead of immediately generating code, Omniroute analysed the project and asked whether I wanted it to create a development plan before executing the implementation.

I found this particularly impressive because it approached the project much like an experienced software developer would — understanding the requirements first before writing any code.

🚀 Generating the Application

After confirming the execution plan, Omniroute began building the project automatically.

The development process required very little manual intervention. It generated the project structure, organised the files appropriately, and implemented the requested functionality based on the specification document.

The final project directory looked like this:

📊 Omniroute Dashboard

When Omniroute starts, it automatically launches its web dashboard. From here you can:

Monitor development sessions
Configure quotas
Review usage statistics
Manage other application settings

⚠️ Security note: The default login password is CHANGEME. If you're installing Omniroute for the first time, remember to change this before using it regularly.

✅ The Results

Overall, I was pleasantly surprised by the quality of the generated application.

Metric	Value
Total tokens consumed	~250,800
Additional API cost	~$0.50
Manual interventions needed	1 (CSS fix)
Output quality	Production-ready starting point

Rather than producing a rough prototype, Omniroute generated a solid starting point that my friend could immediately continue developing. For anyone beginning a university project or building an internal prototype, this can save many hours of initial setup work.

🔢 Token Usage

One of the more interesting parts of this experiment was the token consumption.

Although my Claude account had virtually no remaining credit, Omniroute continued the development using available free-tier endpoints to complete the project.

An additional $0.50 worth of tokens was consumed during the process — remarkably cost-effective for what was generated.

🧪 Testing the Generated Website

Once the project had been generated, I tested the application manually. Overall, everything worked remarkably well.

The only issue I noticed was a small CSS problem — the navigation bar was not remaining sticky while scrolling.

Rather than fixing it manually, I simply opened another Omniroute session and asked Claude to correct the issue. It did so without any fuss, which demonstrates one of the biggest advantages of AI-assisted development: rapid iteration.

💭 Final Thoughts

This was my first real project using Omniroute, and I came away genuinely impressed.

What stood out most wasn't just its ability to generate code — it was the workflow. Omniroute analysed the requirements, proposed a development plan, and then executed that plan with very little guidance. That makes it feel less like an autocomplete tool and more like collaborating with a junior developer who can rapidly scaffold an application.

Of course, AI-generated applications still require testing, code review, and refinement. Minor issues — such as the CSS bug I encountered — are to be expected. However, those are small trade-offs considering the amount of time saved during the initial development phase.

If you're looking for a way to bootstrap small PHP applications, university projects, proof-of-concepts, or internal tools, Omniroute is worth exploring.

I don't see it replacing software developers anytime soon — but it certainly makes them significantly more productive.

Have you tried Omniroute or a similar AI coding agent? I'd love to hear about your experience in the comments below.