If you’ve evaluated Temporal before and decided the ops surface was too heavy, the picture has shifted. At Replay 2026, Temporal announced Serverless Workers — currently in pre-release — which run your Temporal Workers on AWS Lambda rather than a persistent fleet you manage. The core programming model stays the same, but Temporal now handles invoking, scaling, and shutting down the Lambda functions based on queue depth. You write the same Workflows and Activities you’d write for a self-hosted cluster; what disappears is the always-on compute bill and the autoscaling strategy.

Before getting into the specifics of what changed, it’s worth being clear about what Temporal actually is and why the serverless announcement matters in context.

What Durable Execution Actually Means

Temporal’s core abstraction is that your code runs to completion regardless of failures — process crashes, network partitions, infrastructure restarts. It achieves this by recording every step of a Workflow’s execution as an event history on the Temporal Service. If a Worker crashes mid-execution, another Worker picks up the history, replays it to reconstruct in-memory state, and continues from where things stopped.

The practical result: you write business logic as ordinary functions without embedding retry loops, checkpoint files, or manual state management. A Workflow that transfers funds, processes a batch of documents, or runs a multi-step ML pipeline looks like sequential code. The durability comes from Temporal’s event log, not from your code’s defensive patterns.

The unit of work is split into two layers. Workflows define the control flow — what happens, in what order, with what branching logic. Activities are the side-effectful units that talk to databases, APIs, or external services. Activities get automatic retry policies; Workflows don’t execute side effects directly, which is what makes replay safe.

Workers are the processes that actually execute this code. They poll a Task Queue on the Temporal Service, pull tasks, run them, and report results back. Traditional Temporal deployments require you to run long-lived Worker processes — on Kubernetes, EC2, ECS, wherever — and manage their scaling yourself.

Temporal’s event replay model means that Workflow code must be deterministic: the same inputs must always produce the same sequence of commands. Non-deterministic operations (network calls, random numbers, wall-clock time) belong in Activities, not in the Workflow function itself. This constraint is enforced by the SDK rather than the runtime, so violating it produces subtle bugs rather than immediate errors. Every major Temporal SDK ships a linter or analyzer to catch common violations before they reach production.

Serverless Workers: What Changed at Replay 2026

Serverless Workers are a different lifecycle model for the same programming model. Instead of a long-running process polling the queue continuously, you upload your Worker code to AWS Lambda, create a cross-account IAM role using a Temporal-provided CloudFormation template, and register the Lambda ARN with Temporal via CLI or UI.

From there, Temporal watches the Task Queue metrics — specifically the backlog count and sync match rate — and decides when to invoke your Lambda. When tasks arrive, Temporal assumes the IAM role in your account and triggers the function. The Worker processes available tasks and shuts down before Lambda’s maximum invocation duration.

The setup is intentionally minimal: three steps, standard SDK code, no new APIs to learn. The pre-release currently supports Go, Python, and TypeScript SDKs. Google Cloud Run support is listed as coming.

The scaling model changes meaningfully. With a traditional Worker fleet, you define autoscaling policies and pay for minimum capacity even during quiet periods. With Serverless Workers, compute runs only when tasks exist. For workloads that are bursty, infrequent, or unpredictable in volume — background jobs, triggered pipelines, intermittent integrations — this eliminates a real cost and operational surface.

The Constraint You Can’t Ignore

Lambda imposes a maximum invocation duration of 15 minutes. Temporal handles this cleanly at the Workflow level — a Workflow can span arbitrarily many Lambda invocations across its lifetime, because the state lives in the event log, not in the process. But individual Activities are bounded by that 15-minute ceiling.

If you have an Activity that calls a slow external API, runs a database migration, or performs a computation that regularly takes longer than 15 minutes, Serverless Workers are the wrong fit for those activities. Long-running Workflows are supported; long-running Activities within a single invocation are not. This is a real limitation for ML training steps, video encoding, or any processing that cannot be broken into chunks under the time limit.

The Temporal team is candid about this tradeoff in the documentation. It’s not a workaround-able edge case — it’s an architectural constraint of the underlying compute platform.

Why This Matters for AI Agent Workflows

The timing of the serverless announcement is not accidental. AI agent architectures have become one of Temporal’s fastest-growing use cases, and the two are naturally complementary for reasons that go beyond marketing alignment.

Agentic workflows are structurally difficult: they run for unpredictable durations, call unreliable APIs (LLM providers, external tools, retrieval systems), branch based on model outputs, and need to be observable and recoverable when something goes wrong. Temporal’s primitives address each of these directly.

Also announced at Replay 2026 alongside Serverless Workers:

• Workflow Streams (public preview): A durable streaming primitive using Signals and Updates that delivers incremental outputs — useful for streaming token-by-token LLM responses through a durable layer rather than buffering everything in memory.
• External Payload Storage (public preview for Python and Go): Routes large inputs and outputs through Amazon S3 or custom storage drivers, sidestepping Temporal’s payload size limits when you’re passing large context windows or embedding vectors between steps.
• Google ADK and OpenAI Agents SDK integrations: Official integrations that give agent frameworks access to Temporal’s durability primitives without manual wiring.

For multi-agent systems specifically, Temporal’s Signals and Queries give you a structured inter-agent messaging layer backed by the event log. Each agent is a separate Workflow; Signals pass messages between them; Queries expose current state without mutating it. The Temporal UI records every inter-agent communication with timestamps and inputs, which converts the usual opacity of agent orchestration into something you can actually inspect and debug.

The Serverless Workers model fits agent workloads that are event-triggered — a new document arrives, a user submits a form, a schedule fires. Those agents don’t need always-on Workers. They need Workers that start in response to demand and stop when the queue is empty.

Pre-release software carries real caveats. Serverless Workers are not yet at general availability, which means APIs, CloudFormation templates, and CLI commands may change before the stable release. If you plan to build production systems on this today, pin your Temporal SDK versions and follow the release notes closely. The Temporal team has a history of maintaining backward compatibility across SDK versions, but pre-release features are explicitly outside that guarantee.

Pricing and When the Model Makes Sense

Temporal Cloud bills on actions — billable operations between your application and the Temporal Service, such as starting a Workflow, recording a heartbeat, or sending a Signal. Published pricing starts at $50 per million Actions with volume discounts applied automatically as usage grows. Storage is billed separately: active storage (running Workflows) and retained storage (event histories for closed Workflows, up to a 90-day retention window).

The base plan tiers start at $100/month for Essentials and $500/month for Business. These include baseline action and storage allocations before consumption billing kicks in.

Serverless Workers don’t introduce a new Temporal billing line — you still pay for Actions and Storage as usual. What changes is your compute bill: Lambda invocations instead of persistent EC2 or Kubernetes nodes. For workloads running continuously at high volume, the Lambda cost per invocation can exceed what you’d pay for a small always-on fleet. The break-even depends on your specific invocation pattern and Lambda configuration, and Temporal’s own documentation on estimating costs is worth reading before committing.

The model makes the clearest sense for:

• Background job pipelines where tasks arrive in unpredictable bursts
• Development and staging environments where you want Temporal’s durability semantics without paying for idle Workers
• Early-stage products where you’re not yet sure whether the workload justifies dedicated infrastructure
• Agent systems where each workflow execution is triggered by an external event rather than running continuously

It makes less sense for latency-sensitive workflows (Lambda cold starts add tail latency you can’t fully control), high-throughput steady-state processing (at sufficient volume, long-lived Workers are cheaper), or any use case involving Activities that approach or exceed the 15-minute Lambda limit.

The Broader Picture

Temporal has grown from a Cadence fork to a funded company with over 3,000 paying customers, a managed cloud product, and now a serverless deployment mode. The programming model has stayed stable enough that early-adopter code from three years ago largely still works. That’s genuinely unusual for infrastructure tooling.

What’s changed is the deployment surface. Self-hosted Temporal clusters require Kubernetes and a production-grade persistence store (PostgreSQL or Cassandra). Temporal Cloud removes the cluster ops but still assumed you ran your own Workers. Serverless Workers remove the Worker ops. The progression is coherent.

The remaining question for most teams is whether the Temporal programming model — deterministic Workflows, separate Activities, replay-based recovery — is the right abstraction for their workload. If it is, the serverless option removes the last significant deployment objection. If it isn’t, serverless Workers don’t change the fundamental model fit. That evaluation still requires reading the documentation, running the hello-world, and stress-testing the determinism constraints against your actual code.

The pre-release is open. The setup is documented. Whether the 15-minute Activity limit and Lambda cold-start tail latency are acceptable depends on your workload, and that’s something only you can benchmark.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Stop Complaining. Start Building.

Why Freshers Must Build Real AI Products Instead of Endless App Clones

Every day, freshers complain:

• “There are no jobs.”
• “Companies only want experienced developers.”
• “The market is saturated.”
• “React Native has too much competition.”
• “AI will replace developers.”

But here is the uncomfortable truth:

Most freshers are not building real products.

They are cloning:

• WhatsApp
• Instagram
• Netflix
• Spotify
• YouTube

Again and again.

A clone project is fine for learning basics.
But cloning alone will never make you stand out.

A recruiter has already seen:

• 10,000 To-Do apps
• 5,000 Chat app clones
• 20,000 Weather apps
• Infinite “Expense Tracker” projects

What they have not seen is:

• A real AI accessibility app
• An offline on-device assistant
• A healthcare AI tool
• A practical problem-solving app
• A unique product solving a real human pain point

That is the difference.

The People Winning Are Not Waiting for Permission

Look at opportunities like the Gemma 4 Challenge by DEV + Google.

Five winners.
$500 each.

For many freshers in India, ₹45,000 is nearly:

• 1–2 months of salary
• or even more than their first internship stipend

But the money is not even the biggest reward.

The real rewards are:

• Recognition
• Portfolio strength
• Confidence
• Networking
• Learning
• Public credibility
• Real-world building experience

And even if you do not win?

You still learn something priceless:
where you are weak.

That feedback is more valuable than another cloned food delivery app.

Complaining vs Building

Complaining gives emotional relief.

Building gives transformation.

There is a massive difference.

A person who spends:

• 6 months complaining on LinkedIn
  vs
• 6 months building real AI products

…will not end up in the same place.

The market rewards builders.

Not complainers.

The Ramayana Lesson Most People Ignore

In the Ramayana, there was a powerful warrior called Bali.

There are many interpretations of his story, but one perspective always inspired me:

Bali was not just strong.
He had the ability to quickly understand and adapt during battle.

He learned while fighting.

That combination made him dangerous:

• strength
• observation
• adaptation
• technique

Many freshers today already have talent.

The problem is not talent.

The problem is:
they never learn the technique.

They watch achievers but do not study them.

They scroll success stories but never analyze:

• How was the product built?
• Why did it succeed?
• What problem does it solve?
• What technology stack was used?
• Why is it different?

If you learn techniques from achievers, your growth becomes much faster.

Why AI Challenges Matter So Much in 2026

We are entering a new phase of software development.

Earlier:

• knowing React Native was enough
• knowing backend was enough
• knowing DSA was enough

Now?

AI integration is becoming a core engineering skill.

The developers who survive the next 5–10 years are the ones who can:

• integrate AI
• optimize AI
• build practical AI tools
• create AI-powered user experiences
• run models locally
• solve real-world problems

That is why challenges like the Gemma 4 Challenge matter.

They force you to:

• think differently
• solve actual problems
• build complete products
• work with modern AI models
• learn rapidly

What is Gemma 4?

Gemma is Google’s family of lightweight open AI models designed for developers.

The goal is simple:

Give developers powerful AI capabilities that can run:

• locally
• efficiently
• on consumer hardware
• even on mobile devices in some cases

Unlike giant cloud-only models requiring expensive infrastructure, Gemma models are designed to be more accessible to developers and startups.

That is important for freshers because:
you can actually experiment without building a million-dollar infrastructure.

Why Gemma 4 Is Exciting for Mobile Developers

For mobile developers, especially React Native and Android developers, this changes everything.

Imagine building apps that can:

• understand speech
• summarize conversations
• help visually impaired users
• detect objects
• assist students
• provide mental wellness support
• translate offline
• tutor users
• analyze documents

…without always depending on cloud APIs.

This is huge.

Because:

• offline AI improves privacy
• latency becomes lower
• costs become manageable
• apps become smarter
• users trust local processing more

Understanding Gemma 4 Models

Gemma 4 comes in different sizes.

Generally, smaller models:

• are faster
• consume less RAM
• are easier for edge devices

Larger models:

• are smarter
• better at reasoning
• require stronger hardware

Some models are optimized for:

• lightweight deployment
• local inference
• edge AI
• efficient performance

This matters because your app architecture depends heavily on model size.

For example:

Smaller Edge Models

Good for:

• mobile AI assistants
• accessibility apps
• offline tools
• smart UI interactions

Larger Models

Good for:

• complex reasoning
• research tools
• advanced tutoring
• multi-step workflows

“But I Am Just a Fresher…”

That is exactly why you should start now.

The industry resets during technology shifts.

AI is one of those resets.

A fresher building practical AI apps today can sometimes stand out more than:

• experienced developers stuck in old patterns
• developers who never adapted
• engineers afraid of AI

This is your opportunity window.

Do not waste it.

5 Real AI Product Ideas You Can Build with Gemma 4

1. Hearing Buddy App

An app for people who can speak but cannot hear properly.

How it works:

• The app listens to surrounding speech
• Converts speech to text in real time
• Displays it on screen
• User reads and responds normally

Why this matters:

• Accessibility
• Real-world impact
• Emotional value
• Social usefulness

This is not a clone app.

This solves a real problem.

2. Assistive Vision for Visually Impaired Users

Using camera + on-device AI.

Features:

• Detect doors
• Detect stairs
• Detect obstacles
• Detect people
• Voice guidance

Possible stack:

• React Native
• VisionCamera
• ExecuTorch
• Gemma-based reasoning layer

This is the kind of project recruiters remember.

3. AI Study Companion

Not another chatbot.

A real education assistant that:

• explains concepts simply
• creates quizzes
• tracks weak areas
• motivates students
• summarizes notes
• works offline for low-connectivity regions

Huge potential in India.

4. Mental Wellness Companion

A lightweight emotional support app.

Features:

• journaling
• emotional check-ins
• reflective conversations
• mood summaries
• breathing guidance

The focus should not be pretending to replace therapists.

The focus should be:
helping people feel heard.

5. Offline AI Travel Assistant

Useful in low-network environments.

Capabilities:

• local translation
• local recommendations
• emergency guidance
• itinerary summaries
• tourist help

Especially useful in remote areas.

What Recruiters Actually Want

Many freshers think recruiters only care about:

• DSA
• LeetCode
• CGPA

Those matter.

But real product thinking matters too.

When recruiters see:

• originality
• architecture understanding
• problem solving
• deployment knowledge
• AI integration
• performance optimization
• real-world usability

…you instantly become different.

Because now you are no longer “just another fresher.”

You are a builder.

Follow Achievers Differently

Do not follow achievers for motivation only.

Study them.

Analyze:

• how they think
• how they learn
• how they ship products
• how they present work
• how they explain ideas
• how they solve problems

Learning the technique changes everything.

Your First Product Does Not Need to Be Perfect

Your first AI app:

• may fail
• may be buggy
• may not scale
• may not win competitions

That is normal.

The goal is not perfection.

The goal is transformation.

Every real product teaches:

• architecture
• debugging
• UX
• optimization
• deployment
• communication
• resilience

Cloning teaches only imitation.

Final Thought

The future belongs to builders.

Not complainers.

If you truly want:

• jobs
• recognition
• growth
• income
• opportunities

…then start building products that solve real human problems.

Participate in challenges.
Experiment with AI.
Fail.
Learn.
Improve.
Repeat.

You already have talent.

Now learn the technique.

And once talent meets technique, everything changes.

Join the WhatsApp Community 🚀

If you want more updates like this:

• AI app ideas
• React Native learning
• On-device AI concepts
• Challenge opportunities
• Product-building guidance
• Career growth discussions

Then join the WhatsApp community TechCraft By Subrata and become part of the journey.

Especially join if you are:

• an aspiring React Native developer
• a fresher trying to stand out
• interested in AI + mobile apps
• someone who wants to build real products instead of clones
• an early supporter of practical AI learning

Your next opportunity may start from one project you decide to build today.

Two weeks ago I shipped a dynamic llms.txt and llms-full.txt for a Next.js 16 site I run. Hourly revalidation, pulls from the same content sources as the sitemap, auto-categorizes by URL pattern, returns proper text/plain. Took about 40 minutes to build.

Last week Google published their AI Search optimization guide.

The relevant line:

Don’t create llms.txt files and other “special” markup.

So now I have a dynamic llms.txt that the search engine I most care about explicitly says not to bother with.

I’m keeping it anyway. Here’s why, and here’s the code in case you want to do the same.

What llms.txt is supposed to do

The llms.txt spec was proposed in 2024 (by Jeremy Howard at Answer.AI) as a way for sites to give AI assistants a condensed, machine-readable summary of the site’s content. Two files:

• /llms.txt — short, table-of-contents style. Top-level pages, brief descriptions.
• /llms-full.txt — long-form. The actual content for AI ingestion.

The pitch: LLMs that crawl your site to answer user questions get a curated index instead of having to crawl every page.

In practice, it never became a real standard. Anthropic, OpenAI, and Perplexity have never officially committed to reading these files. Google has now publicly said it doesn’t either.

But several smaller AI engines and developer-focused indexers do consume llms.txt when present. And the cost to maintain a properly designed one is approximately zero. So the cost/benefit math is interesting.

My implementation in Next.js 16 App Router

Three files. Total: about 90 lines.

Step 1: a renderer that pulls content from your CMS

I keep mine in lib/llms.ts. It reads from Sanity, but the same pattern works with anything: Markdown files, MDX, a database, a JSON config.

// lib/llms.ts
import { getAllBlogPosts, getAllResources } from '@/lib/sanity'

const SITE_URL = 'https://example.com'

function resourceCategory(slug: string): 'permit' | 'comparison' | 'glossary' | 'general' {
  if (slug.startsWith('building-permit-guide-')) return 'permit'
  if (slug.includes('-vs-')) return 'comparison'
  if (slug.startsWith('what-is-')) return 'glossary'
  return 'general'
}

export async function renderLlmsTxt(): Promise<string> {
  const posts = await getAllBlogPosts()
  const resources = await getAllResources()

  const lines: string[] = []
  lines.push('# Example Company')
  lines.push('')
  lines.push('> Toronto-based contractor specializing in framing, drywall, and insulation.')
  lines.push('')
  lines.push('## Core Pages')
  lines.push('- [Home](https://example.com)')
  lines.push('- [Services](https://example.com/services)')
  lines.push('- [About](https://example.com/about)')
  lines.push('- [Contact](https://example.com/contact-us)')
  lines.push('')

  const permits = resources.filter(r => resourceCategory(r.slug.current) === 'permit')
  const comparisons = resources.filter(r => resourceCategory(r.slug.current) === 'comparison')
  const glossary = resources.filter(r => resourceCategory(r.slug.current) === 'glossary')

  if (permits.length) {
    lines.push('## Building Permit Guides')
    for (const r of permits) {
      lines.push(`- [${r.title}](${SITE_URL}/resources/${r.slug.current})`)
    }
    lines.push('')
  }

  if (comparisons.length) {
    lines.push('## Comparison Pages')
    for (const r of comparisons) {
      lines.push(`- [${r.title}](${SITE_URL}/resources/${r.slug.current})`)
    }
    lines.push('')
  }

  if (glossary.length) {
    lines.push('## Glossary')
    for (const r of glossary) {
      lines.push(`- [${r.title}](${SITE_URL}/resources/${r.slug.current})`)
    }
    lines.push('')
  }

  if (posts.length) {
    lines.push('## Blog')
    for (const p of posts) {
      lines.push(`- [${p.title}](${SITE_URL}/blog/${p.slug.current})`)
    }
  }

  return lines.join('n')
}

export async function renderLlmsFullTxt(): Promise<string> {
  // Same shape as renderLlmsTxt, but inline the actual body content per
  // resource/post. Pull body from your CMS, convert to plaintext, append
  // under each section header.
  // omitted for brevity
}

The category split is my preference. The spec is loose. What matters is that a machine reading the file gets a clean hierarchical view of your site.

Step 2: the route handlers

Next.js 16 App Router treats files inside /app as routes. Drop a route.ts inside any folder named for your URL path:

// app/llms.txt/route.ts
import { renderLlmsTxt } from '@/lib/llms'

export const revalidate = 3600 // 1 hour cache

export async function GET() {
  const body = await renderLlmsTxt()
  return new Response(body, {
    headers: { 'content-type': 'text/plain; charset=utf-8' },
  })
}

// app/llms-full.txt/route.ts
import { renderLlmsFullTxt } from '@/lib/llms'

export const revalidate = 3600

export async function GET() {
  const body = await renderLlmsFullTxt()
  return new Response(body, {
    headers: { 'content-type': 'text/plain; charset=utf-8' },
  })
}

The revalidate = 3600 line is the key. It tells Vercel/Next.js to serve a cached version for an hour, then regenerate on the next request. If you publish 10 blog posts a day, the file picks them up within 60 minutes. If you publish once a week, it picks them up within an hour of publishing. No build step required.

Step 3: deploy and verify

curl https://example.com/llms.txt

Should return your generated markdown-flavored text in seconds.

That’s it. Total code: about 90 lines. Total time: 40 minutes if you’ve used Next.js before.

Then Google said don’t bother

Google’s AI optimization guide (published this month) is explicit:

Don’t create llms.txt files and other “special” markup.

The reasoning, per Google: their AI features (AI Overviews, AI Mode) ingest the same content humans see. They crawl pages, parse the rendered HTML, and synthesize. They don’t read llms.txt. Creating one is “unnecessary effort.”

That’s an honest position. Google isn’t penalizing you for having an llms.txt. They’re telling you it’s wasted work from their perspective.

But Google isn’t the only AI engine.

Why I’m keeping mine anyway

Four reasons.

1. The maintenance cost is zero

Because the file is dynamic and pulls from the same content source as the rest of the site, it updates itself. There’s no separate workflow to maintain, no monthly chore, no risk of going stale. The code sat in the repo for two weeks with zero attention required. The next time I add a blog post or resource page, the file picks it up within an hour.

If maintenance cost were measured in minutes per month, llms.txt would be at zero. There’s nothing to abandon.

2. Not every AI engine has spoken

Perplexity, ChatGPT, Claude, and several smaller AI search products have not officially said whether they read llms.txt. Some open-source RAG indexers do. Some agent frameworks default to checking for it.

If even one of these tools reads my llms.txt and produces a citation that a human user clicks, the file paid for itself. The opportunity cost of having it is approximately the bytes Vercel serves on the rare requests that hit the endpoint.

3. It functions as a structured fallback

The llms.txt is one of the cleanest, most human-readable summaries of my site that exists anywhere. When someone asks me for an overview of my site’s content, I can paste the llms.txt into a chat and have an instant brief. It’s a free side effect of building it.

4. Building it was a useful exercise

Going through the exercise of categorizing every page, deciding what’s important, and giving each section a clean summary is exactly the kind of content audit most sites should do anyway. The output (the llms.txt file) is the artifact. The thinking is the value.

When to skip it

If your site is purely commerce, your content is highly dynamic (millions of product pages), or your content lives mostly behind login, llms.txt has less value. AI engines aren’t going to ingest your product catalog from a flat text file.

If you’re a content site, a docs site, a portfolio, an editorial publication, or anything where the page-level content matters and the URL structure has meaning, llms.txt is worth the 40 minutes.

Working example

You can see the live output at:

• https://konstruction.ca/llms.txt
• https://konstruction.ca/llms-full.txt

Both regenerate every hour. Both pull from the same Sanity CMS that drives the rest of the site. Total runtime memory cost: indistinguishable from zero. Pageviews: low but non-zero.

The bigger point

Google publishing guidance that says “don’t bother with X” is not the same as Google penalizing X. Sometimes Google is telling you the optimal allocation of your effort. Sometimes you should agree. Sometimes you should keep doing X because the cost is zero and the upside, while small, is nonzero.

llms.txt is in the second bucket. Build it once, let it run, ignore the file for six months, see what happens.

If in 18 months Google publishes “we now use llms.txt to inform AI Overviews,” you’ll be glad you left it running. If they don’t, the file cost you 40 minutes and approximately zero ongoing attention.

The optimal play with low-cost, low-confidence bets is to make a lot of them and let outcomes resolve themselves.

Build the llms.txt.

Selection Sort’s superpower: fewest swaps of any simple sorting algorithm — at most n-1 total. In systems where writes are expensive, this matters.

🧠 The Core Idea

Every pass: scan the unsorted region, find the minimum, swap it to the front.

Analogy: Sorting 30 answer sheets by roll number. Scan all, find Roll No. 1, pull it. Scan remaining, find Roll No. 2. Repeat.

📋 Example: [64, 25, 12, 22, 11]

5 elements → 4 passes → only 2 actual swaps.

💻 JavaScript

function selectionSort(arr) {
  const n = arr.length;
  for (let i = 0; i < n - 1; i++) {
    let minIdx = i;
    for (let j = i + 1; j < n; j++) {
      if (arr[j] < arr[minIdx]) minIdx = j;
    }
    if (minIdx !== i) [arr[i], arr[minIdx]] = [arr[minIdx], arr[i]];
  }
  return arr;
}

⏱ Complexity

🆚 vs Bubble Sort

Part 8 of the Bitveen DSA Series. Originally published at bitveen.com

The strange thing about the modern AI bill is that it looks precise while the work behind it feels mysterious. A user types a short request, a model thinks through a long hidden path, tools are called, context is loaded, cached text may be reused, and the final answer arrives as if it were a single clean event. The invoice later describes the event in tokens. Input tokens, cached input tokens, output tokens, reasoning tokens, long context tokens. The language of measurement is tidy. The measured behavior is complex.

So the question matters. Does AI have an awareness of token consumption. The practical answer is almost certainly negative. A model can be prompted to write shorter answers, choose compact formats, summarize context, or stop after a budget. That remains a behavioral response rather than economic self awareness. The model is predicting text under instructions. The metering system lives around it. Token counting, caching, routing, rate limits, and billing are product and infrastructure layers built by humans. The model may talk about saving tokens, but the system decides what was consumed and what it costs.

That gap explains why token economics has become one of the least glamorous and most important parts of AI. In the first wave, the attention went to model quality. In the second wave, the attention moved to agents, context windows, voice, video, and multimodal workflows. Now the decisive question for many teams is simpler. Can the product deliver useful intelligence at a predictable unit cost.

For AI vendors, tokens are the bridge between capability and gross margin. Output tokens usually cost more than input tokens because generation is compute intensive and latency sensitive. Long reasoning can improve quality, but it also turns invisible compute into visible cost. Cached input changes the equation again. When repeated context can be reused, the provider can reduce cost and latency while keeping the customer inside the same platform. This is why pricing pages now distinguish fresh input from cached input, and why prompt caching has become a core design feature rather than a small optimization.

For cloud providers, the token is becoming a new workload unit. Traditional cloud economics was built around virtual machines, storage, bandwidth, and database operations. AI inference adds a more volatile meter. One customer request may be tiny. Another may carry a large document, a long conversation, tool outputs, and a detailed answer. GPU supply, batching, memory bandwidth, model size, quantization, and serving software all shape the cost per million tokens. Cloud platforms want to sell capacity, yet customers increasingly ask for something more concrete than capacity. They want a dependable price for intelligence delivered.

For business customers, token economics is a budgeting problem and a product design problem at the same time. A support chatbot that reads the entire customer history on every turn can become expensive fast. A coding agent that keeps every file, tool result, and prior message in context may feel magical during a demo and painful in production. A research assistant that produces long reports may create value, but only if the organization understands how much context it used, how much reasoning it triggered, and how often the same material could have been cached.

The best enterprise teams are beginning to treat tokens like inventory. They ask which context is essential, which context can be retrieved only when needed, which instructions are stable enough to cache, and which tasks justify a stronger model. They build dashboards that show cost by workflow, department, customer, and outcome. They test small models for narrow tasks and reserve frontier models for judgment heavy work. They also redesign user experiences so people can choose depth when depth matters, instead of making every request behave like a full investigation.

For consumers, token economics is usually hidden behind subscriptions and usage caps. Its relevance remains. When a chat product becomes slower, when image generation gets rationed, when voice mode is limited, or when a long conversation suddenly asks the user to start fresh, token economics is often nearby. The consumer feels it as friction. The provider experiences it as margin pressure. The model experiences none of it as a conscious concern.

This is where the consciousness question becomes useful. If we imagine the model as an aware worker, we may expect it to manage cost like a human employee watching a budget. That expectation leads to disappointment. A more accurate mental model is a powerful engine connected to meters, governors, caches, and pricing rules. The engine can follow instructions about brevity and structure. The surrounding system must manage the money.

The real opportunity is to design the surrounding system well. A useful AI product should know when to compress context, when to retrieve fresh evidence, when to ask a clarifying question, when to use a smaller model, when to stop generating, and when a richer answer is worth the extra cost. This belongs to architecture, and it is also where durable advantages will appear.

Practical workflows already show the pattern. A researcher may draft analysis in ChatGPT or Gemini, then use Miss Formula when equations or formula images need to become clean editable math. When charts and paper figures generated by AI need to move into publication or slide production, Editable Figure can convert AI generated paper figures into editable vector figure formats. The strongest workflow spends tokens with intention and turns each token into a reusable artifact.

That last phrase is the heart of token economics. Tokens function as both a billable unit and a design pressure. They force vendors to compete on inference efficiency, cloud providers to expose clearer cost models, businesses to measure value per workflow, and consumers to notice the limits of abundance. AI may lack awareness that it is burning tokens. The teams building around AI must know better.

The Problem We Were Actually Solving

Our customers were based in regions where popular payment gateways like Stripe and PayPal were either blocked or heavily restricted. We needed a solution that would allow us to process payments from these countries without breaking a sweat. However, integrating a reliable alternative proved to be a significant challenge.

What We Tried First (And Why It Failed)

Initially, we tried using the more ‘permissive’ Stripe and PayPal, despite knowing they’d eventually fail. We implemented the usual checks, like IP blocking and payment method whitelisting, in hopes that these would be enough to bypass the restrictions. However, this was a case of wishful thinking, and we soon found ourselves dealing with a myriad of declined payments, error messages (e.g., “Stripe Invalid Request” and “PayPal Connection Timed Out”), and angry customers.

The Architecture Decision

We decided to pivot and explore crypto as a viable alternative. Setting up our own crypto-based payment processing system was no easy feat, but it allowed us to sidestep the country-specific restrictions imposed by traditional payment processors. We integrated with CoinGate to process payments directly into our platform, which included handling wallet management, deposit and withdrawal limits, and fiat-to-crypto conversion.

This solution required us to implement additional checks and balances, such as wallet verification and transaction logging, to prevent abuse and maintain regulatory compliance. We also had to invest in educating our customer support team on crypto-related issues and handling the inevitable flood of questions and complaints.

What The Numbers Said After

In the first six months, our crypto integration processed over $200,000 worth of payments, with a successful transaction rate of 95%. We also saw a significant reduction in declined payments and customer complaints (from an average of 5 complaints per week to virtually zero). Moreover, our customer base expanded into previously inaccessible markets, resulting in a 20% increase in subscription revenue.

What I Would Do Differently

In hindsight, I would have explored custom solutions sooner, rather than relying on traditional payment processors. Crypto, although imperfect, has allowed us to scale internationally without the hassle of dealing with platform restrictions. However, our reliance on CoinGate has introduced additional complexity and costs, which might not be sustainable in the long run.

Moving forward, I’d consider implementing a hybrid solution that combines the benefits of crypto with custom-built payment processing. This would enable us to maintain regulatory compliance, reduce our reliance on third-party services, and further optimize our payment processing pipeline. The age-old lesson here is that sometimes, the best solution isn’t the one that works, but the one that allows you to adapt and evolve in the face of changing platform restrictions.

Introduction

I recently booted up an offline card game I used to love — and couldn’t clear the hardest difficulty anymore.

I used to be able to beat it.

That frustration sparked an idea: what if I trained an AI to help me figure it out? I had three constraints going in:

• It had to work offline
• I wanted to try reinforcement learning while I was at it
• It had to be lightweight enough to run on an 8-year-old MacBook Air

After a lot of trial and error, I landed on building a custom engine in Rust and running the training on Google Colab. This article focuses on the Google Colab side of that setup.

What Is Google Colab?

Google Colab is a free Python execution environment provided by Google (this article assumes the free tier). All you need is a browser — no installation required.

What made it useful for this project:

• Free GPU/CPU access
• Integrates with Google Drive
• Runs heavy workloads regardless of your local hardware

Training that would’ve been painful on an old MacBook Air ran smoothly once I moved it to Colab.

⚠️ Note: On the free tier, the session disconnects after a period of inactivity or after a maximum of 12 hours, and runtime data is reset.

What I Did

The goal was to train an AI to play an offline deck-building card game using reinforcement learning.

Here’s the overall flow:

1. Translate the game rules and card effects into language
2. Convert that into numerical data the AI can work with
3. Build a custom training engine in Rust
4. Upload the training data to Google Drive
5. Mount Google Drive in Colab and run it

Steps 1–3 are all on the Rust side — I’ll cover those in a follow-up. This article focuses on steps 4 and 5.

Mounting Google Drive in Colab

Run the following code in a Colab cell:

from google.colab import drive
drive.mount('/content/drive')

You’ll see a prompt asking to authorize access to Google Drive. Click “Connect to Google Drive”, choose your account, and allow access. Once done, a drive/MyDrive folder will appear in the left sidebar.

After mounting, your Drive is accessible at:

/content/drive/MyDrive/

💡 You can also mount Drive without writing any code — just click the folder icon in the left sidebar and hit the “Mount Drive” button. It inserts the code automatically.

⚠️ If Google Drive’s cache is stale, updates to your Drive may not reflect in Colab. If that happens, force a remount:

drive.flush_and_unmount()
drive.mount('/content/drive', force_remount=True)

Running the Binary and Starting Training

Once Drive is mounted, you can execute the file you uploaded directly from Colab.

subprocess is Python’s standard library for calling external programs — in this case, the Rust binary:

import subprocess

result = subprocess.run(
    ['/content/drive/MyDrive/your_binary'],
    capture_output=True,
    text=True
)
print(result.stdout)

Replace your_binary with your actual filename.

💡 If you get a permission error, run this first. 0o755 grants execute permission on Linux:

import os
os.chmod('/content/drive/MyDrive/your_binary', 0o755)

Stuck? Ask Gemini

Colab has Gemini built in — just click the icon in the top right. Paste your error message directly and it’ll suggest a fix. Don’t hesitate to just dump the error and let it figure it out 😊

Closing

I covered the Google Colab basics, mounting Google Drive, and running a Rust binary — all from a browser, on hardware that couldn’t have handled the training locally.

If this was useful, the follow-up covers the reinforcement learning setup and how I represented the game state. I’ll write it if there’s interest 😊

👇 Part 2 here
(coming soon)

I run an AI Discord bot builder that’s deployed 500+ live bots over the last year. The service takes a plain-English description, generates discord.js code, and ships the container to production in under 30 seconds.

That sounds clean. It is not clean.

Most of what I learned came from logs at 3am after someone’s bot stopped responding to messages, or a community went silent because of an undocumented Discord behavior. Here’s the list I wish I’d had on day one.

1. Missing Permissions (50013) is usually about role position, not permissions

The first time I hit this I spent two hours auditing the bot’s permission integer. It was correct. The bot still couldn’t kick anyone.

The thing nobody puts in big letters: discord.js permissions are gated by role hierarchy. A bot can have the KickMembers permission and still fail to kick anyone whose top role sits above the bot’s top role.

client.on(‘interactionCreate’, async (interaction) => {
if (!interaction.isChatInputCommand()) return;
if (interaction.commandName !== ‘kick’) return;

const target = interaction.options.getMember(‘user’);
const botMember = interaction.guild.members.me;

if (target.roles.highest.position >= botMember.roles.highest.position) {
return interaction.reply({
content: “I can’t kick that user — their role is at or above mine.”,
ephemeral: true,
});
}

await target.kick(interaction.options.getString('reason') ?? 'No reason');
await interaction.reply(`Kicked ${target.user.tag}.`);

});

Fix in Discord: drag the bot’s role above the roles it needs to manage in Server Settings → Roles. This is the single most common reason a “working” bot doesn’t work.

1. Unknown Interaction (10062) is a 3-second race

Slash commands give you exactly 3 seconds to respond. If you call any awaited DB query, third-party API, or LLM before.reply(), you’ll lose that race.

Wrong:
const result = await callLLM(prompt); // 2.4s
await interaction.reply(result); // 10062

Right:
await interaction.deferReply(); // buys you 15 minutes
const result = await callLLM(prompt);
await interaction.editReply(result);

The deferred reply pattern is one of those things you need to internalize once and then never get bit by again.

1. Intent flags are silent killers

This one is brutal because there’s no error. Your bot connects, shows as online, registers commands, and never reads a message.

Two parts:

1. In the Discord Developer Portal, toggle “Message Content Intent” on.
2. In your client config, list it:

import { Client, GatewayIntentBits } from ‘discord.js’;

const client = new Client({
intents: [
GatewayIntentBits.Guilds,
GatewayIntentBits.GuildMessages,
GatewayIntentBits.MessageContent, // ← without this, message.content is empty
GatewayIntentBits.GuildMembers,
],
});

If you skip either step, message.content arrives as an empty string and your prefix commands look broken for no apparent
reason.

1. Reactions and edits on old messages are partial

If someone reacts to a message your bot didn’t observe being created (anything older than the bot’s session), the event payload is partial. Touching .content returns null until you fetch.

client.on(‘messageReactionAdd’, async (reaction, user) => {
if (reaction.partial) {
try { await reaction.fetch(); } catch { return; }
}
if (reaction.message.partial) {
try { await reaction.message.fetch(); } catch { return; }
}
// safe to use reaction.message.content now
});

Add the Partials config too:

import { Client, Partials } from ‘discord.js’;
new Client({
intents: […],
partials: [Partials.Message, Partials.Channel, Partials.Reaction],
});

1. Ephemeral replies don’t behave like normal messages

You can’t fetch them with channel.messages.fetch(). You can’t add reactions. If you want to update one later, you need the original interaction token, not a message ID:

await interaction.reply({ content: ‘Loading…’, ephemeral: true });
// 10 seconds later
await interaction.editReply({ content: ‘Done.’ });

If you serialize the interaction across processes (queue, webhook handler, etc.), serialize the token, not the message
reference.

1. Process crashes leave gateway sessions hanging

If your bot crashes hard without closing the websocket, Discord keeps that session alive on their end for a few minutes.
New deploys then count against the 1000/day session start limit, and on cold restarts you’ll see a brief window where two instances of your bot post duplicate messages.

async function shutdown(signal) {
console.log([bot] ${signal} received, closing gateway);
try { await client.destroy(); } catch {}
process.exit(0);
}
process.on(‘SIGTERM’, () => shutdown(‘SIGTERM’));
process.on(‘SIGINT’, () => shutdown(‘SIGINT’));

process.on(‘unhandledRejection’, (err) => {
console.error(‘[bot] unhandled rejection:’, err);
// don’t crash — log and continue
});
process.on(‘uncaughtException’, (err) => {
console.error(‘[bot] uncaught:’, err);
// do crash, but cleanly
shutdown(‘uncaughtException’);
});

If you’re running on a container platform that sends SIGTERM before forcibly killing, this single block saves you a
class of bugs you’d never spot.

1. Rate limits aren’t always 429s

The REST client emits a rateLimited event for the soft cases (Discord’s per-route bucket warnings). If you log it from
day one, you get a free monitoring signal:

client.rest.on(‘rateLimited’, (info) => {
console.warn(‘[ratelimit]’, {
route: info.route,
method: info.method,
timeToReset: info.timeToReset,
limit: info.limit,
});
});

In production these almost always trace back to one bot in a 10k-member server doing something dumb in a loop. They Never show up in your error monitoring otherwise.

1. The biggest one: most production failures aren’t bugs in your code

When you run a few hundred bots, the failure distribution shifts. Probably 30% of “the bot is broken” tickets I’ve seen trace back to:

• The server admin moved roles around
• The user revoked the bot’s invite
• The bot was rate-limited because someone scripted 1000 reactions
• Discord shipped a behavior change
• A channel was deleted that the bot was scheduled to post in

Your bot needs to log enough that you can prove which of these happened quickly. A single structured log per important event (action attempted, guild ID, user ID, outcome, latency) gets you 80% of the way there.

I learned most of this the hard way running vibebot.gg, where users describe a Discord bot in English and the system generates and deploys discord.js code for them. The interesting failure mode in that setup is that the LLM-generated code has to handle all eight of these gotchas correctly the first time, because the user never sees the code. The patterns above are exactly what we now bake into every generated bot at the template level.

If you’re building a Discord bot from scratch, copy the snippets above directly. They’re worth a week of debugging each.

Store all prefixes of numbers from arr1 in a HashSet.

Example for 12345:

12345
1234
123
12
1

We get these prefixes by repeatedly dividing by 10.

Then for every number in arr2, keep removing digits from the end and check if that prefix exists in the set.

Example:

1239 → 123 → found

So common prefix length = 3.

break is used because further prefixes (12, 1) will only be smaller.

import java.util.HashSet;

class Solution {
    public int longestCommonPrefix(int[] arr1, int[] arr2) {
        HashSet<Integer> prefixes = new HashSet<>();

        // Step 1: Insert all possible prefixes of numbers in arr1 into the HashSet
        for (int val : arr1) {
            while (val > 0) {
                prefixes.add(val);
                val /= 10; // Remove the last digit to get the next prefix
            }
        }

        int maxLength = 0;

        // Step 2: Check all possible prefixes of numbers in arr2 against the HashSet
        for (int val : arr2) {
            while (val > 0) {
                if (prefixes.contains(val)) {
                    // Step 3: If found, calculate its length and update maxLength
                    int currentLength = String.valueOf(val).length();
                    maxLength = Math.max(maxLength, currentLength);

                    // Optimization: Since we are dividing by 10, subsequent prefixes 
                    // of this specific 'val' will be shorter. We can break early.
                    break; 
                }
                val /= 10;
            }
        }

        return maxLength;
    }
}