Forem

I Built Three Platforms for Dental Professionals — Here's What the Data Taught Me

Nick Grigora — Mon, 27 Apr 2026 19:56:44 +0000

I'm a software engineer who noticed that discovery in dentistry is completely broken. Dental professionals at small practices never see product reps. They pick labs based on word of mouth. Software vendors spam everyone with cold emails but there's no independent place to compare what exists.

So I built three things to fix it.

What I Built

FreeDentalSamples.com — dental professionals verify their license once and request free samples from brands. Brands get full lead data and fulfill through their existing Shopify store. I'm just the verified routing layer — no inventory, no logistics.

5 months in: 400+ verified professionals, 52k samples distributed, ~120k patients reached. Growing ~6/day with zero paid acquisition.

BestDentalLabs.org — searchable directory of 100+ dental labs. Filter by specialty, certification, turnaround time, location. SEO-first: static page per lab at /state/city/lab-name. Within weeks of launch the VP of AI Engineering at Glidewell Dental — the largest dental lab in the US — found it through search and reached out. Zero outreach on my end.

BestDentalSoftware.org — just launched. Dental software directory across 9 categories. The trigger: I listed one app on FDS as a free trial with zero promotion and 9 professionals clicked through in 48 hours. Same audience, different discovery problem.

The One Thing That Mattered

Don't build transactions, fulfillment, or logistics. Route to existing infrastructure. That constraint kept me shipping.

Verification is the moat. Every brand conversation changed the moment I said "verified dental professionals." Not dental professionals. Verified. The license check that felt like friction is the thing that makes the leads worth paying for.

Happy to answer questions about architecture, SEO strategy, or the business model in the comments.

🧠 AI is not replacing developers — it’s exposing the gap between them

Francisco Molina — Mon, 27 Apr 2026 19:55:05 +0000

The discussion around AI in software engineering is often polarized:

AI will replace developers
AI is just another tool

Neither framing is particularly useful.

What is actually happening is more structural:

AI is raising the baseline of software development.

The baseline is no longer a differentiator

Activities that historically differentiated developers are becoming increasingly commoditized:

Writing syntactically correct, functional code
Integrating APIs and SDKs
Implementing standard patterns in popular frameworks

With modern AI systems, these tasks can be generated or accelerated with relatively low effort.

This does not make them irrelevant —
but it does make them insufficient as signals of engineering capability.

Where the real differentiation is moving

As the baseline shifts, value concentrates in areas that require contextual and system-level thinking:

Designing resilient architectures
Evaluating trade-offs under constraints
Understanding business-critical flows
Diagnosing issues in non-ideal environments

These are not isolated tasks. They exist within systems that evolve, degrade, and fail.

AI can generate code — but it cannot own consequences

One of the most important distinctions is this:

AI produces outputs, but it does not operate under consequences.

In real systems, correctness is not defined by compilation or passing tests alone.

Consider a common scenario:

Example: Race condition in async flows

You have a mobile application that triggers multiple asynchronous jobs:

Sync product catalog
Sync pricing
Sync customer data

An AI-generated approach might suggest launching all jobs concurrently and updating UI state based on completion callbacks.

At a glance, this is correct.

In production, however, this can lead to:

UI reflecting partial or inconsistent state
Pricing being calculated before product data is fully available
Intermittent bugs that only appear under network latency

A more robust solution requires:

Understanding dependency ordering
Coordinating async execution
Designing a consistent state model (e.g., progressive aggregation, gating completion on full readiness)

This is not a code generation problem.

It is a system behavior problem.

Example: “Correct” code, wrong system behavior

Another frequent issue:

AI generates code that is locally valid but globally incorrect.

For instance:

Updating a pricing function without considering promotional rules
Refactoring a method without understanding shared mutable state
Suggesting caching without defining invalidation strategy

Each individual change may appear reasonable.

But in a real system:

Discounts may be miscalculated
State may become inconsistent across screens
Cached data may drift from source of truth

These are failures of context awareness, not syntax.

AI does not replace seniority — it amplifies it

There is a misconception that AI reduces the need for experience.

In practice, it does the opposite.

Using AI effectively requires:

Precise problem definition
Mental modeling of system behavior
Awareness of edge cases and failure modes
Ability to validate and reject outputs

Without this, AI-generated solutions can introduce subtle and costly issues.

With it, AI becomes a force multiplier.

Experience is not optional — it is observable

There are aspects of engineering that cannot be shortcut:

Having seen systems fail under load
Understanding the cost of poor architectural decisions
Recognizing patterns that lead to instability

These are not theoretical concerns.

They emerge from real-world exposure to:

Production incidents
Inconsistent data states
Long-running systems with accumulated complexity

And they directly influence how solutions are evaluated.

Do frameworks still matter?

A natural consequence of AI-assisted development is the question:

If AI can generate code for any framework, should developers still invest in learning them?

The answer is not binary.

Framework knowledge is shifting from memorization to operational understanding.

Developers still need to:

Select appropriate tools for a given problem
Understand lifecycle, constraints, and limitations
Validate that generated code aligns with system requirements

AI can reproduce patterns from a framework.

It cannot determine whether that framework is appropriate for your system.

The real shift

AI is not eliminating developers.

It is:

Reducing the value of purely mechanical skills
Increasing the importance of engineering judgment
Making differences in experience more visible

This changes how developers grow:

Less emphasis on syntax and memorization
More emphasis on systems thinking
Greater focus on correctness under real-world conditions

Final thought

AI is a powerful tool.

But it operates without accountability, context, or consequences.

Software systems do not.

And that gap — between generating code and owning systems —
is where engineering still matters most.

I Reviewed 100 LinkedIn Headlines — Here's What Actually Gets Clicks

charlie-morrison — Mon, 27 Apr 2026 19:54:20 +0000

Your LinkedIn headline is 220 characters. That's it. And most people waste every single one of them.

I spent a weekend going through 100 LinkedIn profiles — recruiters, developers, founders, job seekers, freelancers. I wanted to know: what separates a headline that gets profile views from one that gets ignored?

Here's what I found.

The 3 Headlines Everyone Uses (And Why They Fail)

"Software Developer at Company X"

This is the default. LinkedIn auto-generates it from your job title. About 60% of the profiles I reviewed used some version of this.

The problem: it tells people what you ARE but not what you DO or what you're GOOD AT. A recruiter searching "React developer" won't find "Software Developer at Acme Corp" unless your profile text happens to mention React.

"Passionate about [buzzword] | [buzzword] enthusiast | [buzzword] lover"

Passion is not a skill. "Passionate about innovation" tells me nothing about your actual capabilities. Every third profile I saw had some version of this filler.

"Open to work | Seeking new opportunities"

This works as a signal, but it shouldn't be your ENTIRE headline. You're still selling yourself — "open to work" is the door, not the product.

What Actually Works: 5 Patterns From Top Performers

Pattern 1: The Value Statement

Format: I help [audience] do [result] through [method]

Examples:

"I help SaaS companies reduce churn by 30% through data-driven UX research"
"Helping early-stage startups ship their first product in 90 days"
"I turn complex data into dashboards executives actually use"

Why it works: It answers the question "what's in it for me?" immediately. Recruiters and clients can self-select in 3 seconds.

Pattern 2: The Proof Stack

Format: [Title] | [Quantified achievement] | [Differentiator]

Examples:

"Senior Backend Engineer | 4x system throughput at scale | Go, Rust, distributed systems"
"Product Designer | 200K+ users shipped | Design systems, prototyping, user research"
"Content Strategist | 10M+ organic views | B2B SaaS, developer marketing"

Why it works: Numbers cut through noise. "4x throughput" is memorable. "Senior Backend Engineer" is not.

Pattern 3: The Niche Specialist

Format: The [niche] [role] — [specific outcome]

Examples:

"The compliance automation guy — making SOC 2 less painful since 2019"
"Healthcare UX Designer — because doctor portals shouldn't need a manual"
"DevRel for developer tools — turning docs into adoption"

Why it works: Being specific makes you memorable and findable. "Healthcare UX Designer" beats "UX Designer" in search AND in memory.

Pattern 4: The Career Transition

Format: [Previous credibility] → [New direction] | [What you bring]

Examples:

"Ex-McKinsey → Building AI tools for supply chain | Operations + ML"
"10Y Finance → Product Management | Where spreadsheets meet user stories"
"Teacher turned developer | Bringing pedagogy to developer education"

Why it works: The transition IS the story. It shows range and makes people curious enough to click.

Pattern 5: The Mission Statement

Format: [What you're building/doing] | [Why it matters]

Examples:

"Building the future of code review at [Company] | Ship faster, break less"
"Making AI accessible to non-technical teams | No PhD required"
"Automating the boring parts of freelancing so you can do the actual work"

Why it works: It positions you as someone with direction, not just a job holder.

The Data: What Correlated With Higher Profile Views

From my sample of 100 profiles (comparing headline style to reported profile view counts where visible):

Profiles with specific numbers in headlines had ~3x more reported views
Profiles mentioning a niche (not just a broad title) had ~2x more views
Headlines under 120 characters performed better than those using all 220
Using "|" as a separator was more common in high-view profiles than commas or dashes
First person ("I help...") outperformed third person ("Helps companies...")

Quick Fixes You Can Make Right Now

Add one number. Years of experience, users served, revenue generated, anything quantifiable.
Name your niche. Not "developer" — "React Native developer for fintech." Not "designer" — "UX designer for healthcare."
Remove "passionate." Replace with a concrete skill or result.
Front-load keywords. LinkedIn search weighs the beginning of your headline more heavily. Put your most searchable terms first.
Test it. Change your headline, wait 2 weeks, check if profile views went up. LinkedIn shows you this data.

Generate Yours in 30 Seconds

I built a free LinkedIn Headline Generator that creates 30 headline variations based on your role, skills, and preferred tone. Pick one, tweak it, paste it in.

No account needed. Runs in your browser. Your data stays on your machine.

The other free tools in the career suite:

Resume ATS Score Checker — find out if your resume passes automated filters
Cover Letter Generator — professional cover letters in 4 tones
Salary Negotiation Script Generator — scripts for offers, raises, and counters
Interview Follow-Up Email Generator — thank-you and follow-up templates

Or grab the complete Job Search AI Toolkit ($12) — 100+ prompts covering everything from resume optimization to salary negotiation.

What's the best LinkedIn headline you've ever seen? Drop it below — I'm collecting examples for a follow-up post.

UTMP being phased out: - Why "who" returns empty output on modern ubuntu

Jaideep Grover — Mon, 27 Apr 2026 19:53:58 +0000

So, while operating on an Ubuntu 25.10 I had to use who to check the session, and something weird happened it basically didn't work, for a simple command not to work, I knew something was up with my machine so I did some digging, turns out the next alternative "w" was working just fine but not who. My curiosity rose I checked out Launchpad Bug #2130814, other people encountered it as well and everyone had a different theory why the "who" not work but "w" did. So what happens is if you run "who" it would just return Exit Code: 0 and will not show you any information.

The bug

$ who
$ echo $?
0

While tracking down the reason for this behavior, I got a lot of information that I was not really aware of, the real reason is Ubuntu is moving away from a mechanism that has been working for them since 1970s. While suspected its not a uutils-vs-gnu issue either, cause kind of the same thing happens with gnuwho

$ gnuwho
$ echo $?
0

Both broken

So, while looking at the bug https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2130814 which is open for a while, the original reporter noticed /var/run/utmp is missing, another possible reason seen by a reporter was an EACCESS (Permission Denied) on the /run/systemd/sessions/3 so probably AppArmor was denying it.

I started by checking whether session tracking itself was broken. It wasn't.

$ loginctl list-sessions
SESSION  UID USER   SEAT LEADER CLASS   TTY IDLE SINCE
      4 1000 ubuntu -    1010   user    -   no   -
      5 1000 ubuntu -    1313   manager -   no   -

2 sessions listed.

Session do exist. Systemd knows it, for some reason who wasn't reading it. Next I checked the AppArmor theory, the other commentator saw "EACCESS" but on a clean Ubuntu 25.10 the session files had the required readable permission

$ ls -la /run/systemd/sessions/
-rw-r--r--  1 root root 330 Apr 26 18:27 4
-rw-r--r--  1 root root 309 Apr 26 18:27 5

So files were present their and world-readable, "who" just doesn't look at it. The output of loginctl --version made things click:

$ loginctl --version
systemd 257 (257.9-0ubuntu2.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT
-GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC
+KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF
-XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE

Look near the end: -UTMP.

Each of the flag shows whether systemd was built with that feature. A '+' means included a '-' means excluded. Most of them are included except UTMP.

UTMP is Unix mechanism for tracking the logged in users. The files that are used by UTMP are /var/run/utmp and /var/run/utmpx and tools like 'who', 'last' and 'w' uses this. The modern Ubuntu 25.10 is made without this

$ ls -la /var/run/utmp /var/run/utmpx
ls: cannot access '/var/run/utmp': No such file or directory
ls: cannot access '/var/run/utmpx': No such file or directory

But why

In October 2024, Debian systemd maitainer announced that the support for UMTP will be discontinued. The reason was y2038 problem, to elaborate, UTMP works on a 32 bit system, due to limited bits it would overflow on January 19 2038, so rather than redesigning the whole system the world is pivoting to wtmpdb as the successor. wtmpdb is a SQLite-backed login database to be y2038 safe. And if that doesn't work for you, you can use w. But this means while updating to new operating system or environment people might need to tweak some commands as well.

Why does w work though

$ w
 18:31:03 up 17 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
ubuntu   pts/0    18.206.107.29    18:27    6.00s  0.07s   ?    w

w is part of the procps package which has been updated, it only used utmp as one of the source for findings

Lessons and Closing

I posted a comment for the bug https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2130814
I believe there will be plenty of people who would hit this problem, hopefully this helps them.

The main problem here was not an error message, it was the empty response any workflow would get disturbed and updated with an error but the empty output could make problems way worse. So if you encounter problem the alternatives are w or loginctl list-sessions

How to Negotiate Your Salary Over Email (With Templates)

charlie-morrison — Mon, 27 Apr 2026 19:53:31 +0000

Salary negotiation is awkward enough in person. Over email, it's somehow worse — you're staring at a blank compose window, wondering if you sound greedy or desperate.

I've been there. After helping dozens of people through job transitions, I noticed the same patterns: people who negotiate earn 10-20% more. People who don't leave money on the table every single time.

Here's how to do it without the cringe.

Why Email Is Actually Better for Negotiation

Most people think negotiation needs to happen on a call. It doesn't. Email gives you three advantages:

Time to think. No pressure to respond in real-time. You can craft your words carefully.
A paper trail. Everything is documented. No "I don't remember agreeing to that."
Less emotional. You won't panic-accept a lowball offer because someone put you on the spot.

The downside? Tone is harder to convey. Which is why templates matter.

The 4 Situations Where You'll Need These

1. You Got an Offer (But It's Low)

This is the most common scenario. You're excited about the role, but the number doesn't match your research.

What to say:

Thank you for the offer — I'm genuinely excited about joining the team. After reviewing the compensation package and comparing it with market data for similar roles in [city/remote], I was hoping we could discuss the base salary. Based on my experience with [specific skill] and the scope of this role, I believe a salary in the range of [target] would be more aligned. I'm flexible and open to discussing other components of the package as well.

Why it works: You're not rejecting anything. You're expressing enthusiasm AND making a specific ask backed by market data.

2. You Want a Raise at Your Current Job

Timing matters here. Don't ask right after a company-wide layoff. Do ask after you've shipped something significant.

What to say:

I wanted to schedule some time to discuss my compensation. Over the past [timeframe], I've [specific accomplishment — saved $X, shipped Y, grew Z by N%]. I've also taken on [additional responsibility]. Given these contributions and current market rates for my role, I'd like to discuss adjusting my salary to [target range]. When would be a good time to talk?

Why it works: You lead with value delivered, not "I need more money." You're making the business case first.

3. You're Countering a Counter-Offer

They came back with a number. It's better than the original but still not where you want to be.

What to say:

I appreciate you revising the offer — it shows the team values this conversation. I'm still a bit apart on the base salary. Would [specific number] be possible? I'm also open to discussing [signing bonus / equity / extra PTO / remote flexibility] if the base has a hard cap. I want to make this work for both sides.

Why it works: You acknowledge their effort, stay specific, and offer creative alternatives.

4. After a Rejection (Graceful Follow-Up)

They said no to your ask. Don't burn the bridge.

Thank you for considering my request. I understand there are budget constraints. Could we revisit this in [3-6 months]? In the meantime, I'd love to understand what specific milestones or achievements would support a salary adjustment. That way I can work toward them intentionally.

5 Rules That Make or Break Email Negotiations

Never give your number first. Let them anchor. If pressed, give a range where your minimum is your actual target.
Use specific numbers. $73,500 is more convincing than $75,000 because it signals you've done research, not just rounded up.
Don't apologize for negotiating. "Sorry to ask, but..." undermines everything after it.
Always have a backup plan. The strongest negotiating position is genuine willingness to walk away.
Follow up in 48 hours if no response. One short email: "Just checking in on the compensation discussion — happy to jump on a call if easier."

Tools That Actually Help

I built a free Salary Negotiation Script Generator that creates customized scripts for 4 scenarios (new offer, raise, promotion, counter-offer) in 4 different tones. No signup, runs in your browser, nothing gets stored.

For the full picture — interview prep, resume optimization, cover letters, and salary negotiation all in one place — there's the Job Search AI Toolkit ($12, 100+ prompts).

Also check out the other free tools:

Resume ATS Score Checker — see how your resume scores before applying
LinkedIn Headline Generator — 30 headline variations in seconds
Cover Letter Generator — customized cover letters by tone
Interview Follow-Up Email Generator — never ghost a recruiter again

The Uncomfortable Truth

Most people don't negotiate because they're afraid of losing the offer. In 15 years of hiring data, fewer than 1% of companies have ever rescinded an offer because someone negotiated professionally.

The bigger risk is accepting without asking. That initial salary becomes your baseline for every raise, bonus, and future offer for years.

One email. Ten minutes. Potentially tens of thousands of dollars over your career.

Worth the awkwardness.

What's your worst salary negotiation story? I've heard some doozies. Drop it in the comments.

Tool-Calling Prompts That Don't Blow Up on the Five Edge Cases

Gabriel Anhaia — Mon, 27 Apr 2026 19:53:30 +0000

Book: AI Agents Pocket Guide
Also by me: Prompt Engineering Pocket Guide
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

You've seen this shape: an agent confidently calls delete_user instead of archive_user because the description is off by one verb. Same arg signature, both (user_id: str), the model picks the first one in the schema list, and a paying customer gets nuked. The post-mortem eats half a day. The fix is a sentence in a tool description.

That's edge case one of five. Tool-calling looks clean in the demo. You define a function, register it, the model calls it, you parse the JSON. Then you ship and the model finds the seams. It picks the wrong tool. It passes a string where you wanted an int. It calls search_orders six times in a row with the same query because the response format confused it. It runs send_email before compose_email finished returning. It calls a tool when the answer was already in context.

These five failure modes are common in production agents, and the prompt-plus-schema-plus-validator pattern handles them. Code is Python with the Anthropic SDK shape, but the patterns port to OpenAI, Vertex, and the AI SDK one-to-one.

Edge case 1: two valid tools, model picks neither (or the wrong one)

Two tools both fit the user's request. The model either picks the wrong one with confidence, or freezes and answers without calling any tool at all. The NESTFUL benchmark (as reported by Medium citing the NESTFUL paper) measured frontier models on nested API calls and found full-sequence accuracy was low. A chunk of those misses are tool-selection misses, and many of the rest are arg-generation misses.

The fix lives in the description. Each tool description has to explicitly contrast itself against the closest sibling.

{
  "name": "archive_user",
  "description": "Soft-delete a user. Marks the row archived=true and hides the account from listings. REVERSIBLE within 30 days. Use this for cancellations, churn, GDPR soft requests. NOT for permanent deletion: use delete_user for that.",
  "input_schema": {
    "type": "object",
    "properties": {
      "user_id": {"type": "string", "format": "uuid"}
    },
    "required": ["user_id"]
  }
}

{
  "name": "delete_user",
  "description": "PERMANENTLY remove a user row and PII. IRREVERSIBLE. Use only for legal-mandated hard deletes (GDPR Article 17 confirmed, court order). NOT for cancellations: use archive_user.",
  "input_schema": {
    "type": "object",
    "properties": {
      "user_id": {"type": "string", "format": "uuid"},
      "legal_basis": {
        "type": "string",
        "enum": ["gdpr_article_17", "court_order"]
      }
    },
    "required": ["user_id", "legal_basis"]
  }
}

Two patterns there. First, every description names its sibling and the boundary between them. The model picks tools by reading descriptions; if your descriptions don't compare, the model guesses. Second, the dangerous tool requires an extra arg with a closed enum. A model that wants to call delete_user has to commit to a legal basis from a fixed list. That's hard to do casually.

Edge case 2: wrong-arg-type, silently coerced

The model passes "42" where you wanted 42. Or "true" where you wanted true. Or "2026-04-27" where you wanted a full ISO datetime with timezone. JSON Schema validation catches the obvious ones. The non-obvious ones slide through. Strings that parse as numbers, dates without timezones, IDs that look right but reference the wrong namespace. They reach your downstream call and break something you didn't write.

Wrap every tool handler in a validator. Don't trust the schema alone.

import re
from datetime import datetime
from pydantic import BaseModel, Field, field_validator

UUID_RE = re.compile(
    r"^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-"
    r"[0-9a-f]{4}-[0-9a-f]{12}$"
)

class ArchiveUserArgs(BaseModel):
    user_id: str = Field(..., min_length=36, max_length=36)

    @field_validator("user_id")
    @classmethod
    def _uuid_shape(cls, v: str) -> str:
        if not UUID_RE.match(v.lower()):
            raise ValueError(
                f"user_id must be a UUID, got {v!r}"
            )
        return v.lower()

def call_tool(name: str, raw_args: dict) -> dict:
    schema = TOOL_SCHEMAS[name]
    try:
        args = schema(**raw_args)
    except Exception as e:
        return {
            "error": "invalid_arguments",
            "tool": name,
            "detail": str(e),
            "hint": "Re-read the tool schema and retry.",
        }
    return TOOL_HANDLERS[name](args)

The validator does two jobs the schema can't. It returns a structured error the model can read on the next turn, and it gives you a single chokepoint to log every coercion attempt. When user_id arrives as "USER-1234" instead of a UUID, the model sees the error message, corrects, and retries, usually within one turn. Without the validator, the request hits your DB layer, throws somewhere ugly, and the agent turn ends in a 500.

The hint matters. Models steer hard on the error string. "Re-read the tool schema and retry" produces better recoveries than a bare stack trace.

Edge case 3: the infinite tool loop

Agent calls search_orders(query="acme"). Gets back a result that doesn't quite match what the user asked. Calls search_orders(query="acme") again. Gets the same result. Calls it again. You wake up to a $2,400 bill and a Slack thread.

Two layers of defense. The first is a hard step counter, the classic mitigation. The second is a duplicate-call detector that fires before the counter ever trips.

from collections import Counter
from hashlib import sha256
import json

class LoopGuard:
    def __init__(self, max_steps: int = 12,
                 max_repeat: int = 2):
        self.max_steps = max_steps
        self.max_repeat = max_repeat
        self.calls: Counter[str] = Counter()
        self.step = 0

    def _key(self, name: str, args: dict) -> str:
        blob = json.dumps(
            {"n": name, "a": args}, sort_keys=True
        )
        return sha256(blob.encode()).hexdigest()[:16]

    def check(self, name: str, args: dict) -> str | None:
        self.step += 1
        if self.step > self.max_steps:
            return "step_budget_exceeded"
        k = self._key(name, args)
        self.calls[k] += 1
        if self.calls[k] > self.max_repeat:
            return "duplicate_call_blocked"
        return None

In the agent loop, call guard.check(name, args) before dispatching. If it returns a reason, push that reason back into the conversation as a tool result with is_error=true and break out. The model sees "you already ran this exact call twice; pick a different approach" and almost always pivots. If it doesn't, the step budget catches it.

The system prompt has to know about this. Otherwise the model treats the block as a bug and complains.

You have a tool budget of 12 calls per turn. Identical
calls (same name, same args) are blocked after 2 attempts.
If a tool result is unhelpful, change the args or pick a
different tool. Don't retry the exact call.

Edge case 4: wrong tool ordering

The agent has to compose an email before sending it. It sends first, the body is empty, the customer gets a blank message at 9:02 AM. Or it tries to charge a card before creating the customer record. Or it queries an analytics endpoint before the data warehouse refresh tool finished.

Schemas don't express order. Prompts have to. Two patterns work.

The first is a phase-gated system prompt. Group tools by phase and tell the model the phase rules.

You operate in three phases per request:

1. GATHER: call read-only tools (search_*, get_*, list_*).
   You may call any number, in any order.
2. PLAN: produce a short plan in plain text. No tools.
3. ACT: call write tools (create_*, send_*, charge_*,
   archive_*, delete_*) in the order from the plan.
   You may not call a write tool before producing the plan.

If a write tool fails, return to PLAN before retrying.

The second is a precondition field on each write tool, enforced by the validator.

class SendEmailArgs(BaseModel):
    draft_id: str
    confirmed_recipient: str

    @field_validator("draft_id")
    @classmethod
    def _draft_exists(cls, v: str) -> str:
        if not draft_store.exists(v):
            raise ValueError(
                f"draft_id {v!r} not found. "
                "Call compose_email first."
            )
        return v

The model can't call send_email until compose_email has produced a real draft_id. The error message names the missing prerequisite, so the next turn fixes itself. This is the same "structured error, model reads it, recovers" pattern from edge case 2, applied to ordering instead of types.

Edge case 5: the tool that should be skipped entirely

You ask the agent "what's our refund policy?" The agent calls search_knowledge_base("refund policy"), retrieves three docs, summarizes them. Fine. You ask it "what's 2 + 2." The agent calls search_knowledge_base("2 + 2"), retrieves nothing relevant, and now you've spent 800ms and three vector lookups on arithmetic. Multiply by a million users.

The fix is a "no tool needed" escape hatch in the system prompt, plus a tool-selection rubric.

Before calling any tool, ask yourself:

- Is the answer already in the conversation?
- Is this a general-knowledge question the model can
  answer without a tool?
- Would a human assistant reach for a tool here, or
  just answer?

If any of the above is yes, answer directly. Tools cost
latency and money. Default to no tool.

Pair that with a tool description that names the trigger condition explicitly.

{
  "name": "search_knowledge_base",
  "description": "Search internal company docs (policies, runbooks, product specs). USE WHEN the user asks about company-specific information not in your training data. DO NOT USE for general knowledge, math, code questions, or follow-ups whose answer is already in the conversation.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "minLength": 3}
    },
    "required": ["query"]
  }
}

"USE WHEN" and "DO NOT USE" are two phrases that tend to move tool-call rate the most in production evals. The model is reading your description as a rubric. Give it one.

The prompt skeleton, end to end

The pieces fit together like this. System prompt sets phases and the no-tool rubric. Tool descriptions contrast siblings and name USE WHEN / DO NOT USE. Schemas use enums and formats wherever a closed set exists. Every handler runs through a Pydantic validator that returns structured errors. A LoopGuard wraps the dispatch loop. The model sees errors as readable text on the next turn and self-corrects.

def agent_turn(messages: list, tools: list) -> list:
    guard = LoopGuard()
    while True:
        resp = client.messages.create(
            model="claude-opus-4-7",
            system=SYSTEM_PROMPT,
            messages=messages,
            tools=tools,
        )
        if resp.stop_reason != "tool_use":
            messages.append(
                {"role": "assistant", "content": resp.content}
            )
            return messages
        for block in resp.content:
            if block.type != "tool_use":
                continue
            reason = guard.check(block.name, block.input)
            if reason:
                result = {"error": reason}
            else:
                result = call_tool(block.name, block.input)
            messages.append(
                {"role": "user", "content": [{
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": json.dumps(result),
                    "is_error": "error" in result,
                }]}
            )

That loop is maybe forty lines once you flesh out the imports. It survives all five edge cases above without any LangChain, LangGraph, or framework on top. Teams shipping production agents tend to reinvent pieces of this anyway; writing it once and treating it as the contract is faster than learning a framework's escape hatches.

The pattern that ties everything together is small: tools fail, the model reads the failure, the model retries. Your job is to make every failure a sentence the model can act on. A bare 500 isn't actionable. "draft_id 'xyz' not found. Call compose_email first." is. The whole rig is just plumbing around that one idea.

If this was useful

The AI Agents Pocket Guide goes deeper on the agent-loop design: tool budgets, retry policy, phase prompts, and the eval rig that catches edge cases before customers do. The Prompt Engineering Pocket Guide covers the description-writing patterns from edge cases 1 and 5 in their own chapter, with before/after diffs and the eval scores that go with them. Pair them if you're shipping anything that calls more than one tool per turn.

Migrating From a JSON Column to a Proper Schema in Postgres

Gabriel Anhaia — Mon, 27 Apr 2026 19:53:01 +0000

Book: Database Playbook: Choosing the Right Store for Every System You Build
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

A WHERE payload->>'status' = 'paid' query has been doing 800ms sequential scans for two months because there is no index on it, and the team that owns the table can't add one cleanly. They tried. The expression index built fine in staging and timed out behind a long-running transaction in production. The status field is buried inside a jsonb blob with eleven other keys, three of which are typed wrong, two of which nobody on the team remembers writing.

This is the migration. Out of the JSON column, into typed columns, with zero downtime and no broken reads. The pattern is called expand-and-contract: you add the new shape next to the old one, move traffic across in stages, and only drop the old shape once the new one has been serving production for long enough to trust.

The shape we're starting from:

CREATE TABLE orders (
  id           bigserial PRIMARY KEY,
  customer_id  bigint NOT NULL,
  payload      jsonb NOT NULL,
  created_at   timestamptz NOT NULL DEFAULT now()
);

payload holds { "status": "paid", "total_cents": 4200, "currency": "USD", ... }. We want status, total_cents, and currency as first-class columns with proper types, constraints, and indexes.

Step 1: Add target columns and backfill

The first instinct is ALTER TABLE orders ADD COLUMN status text NOT NULL. On a busy table, that rewrites every row and holds an ACCESS EXCLUSIVE lock for the duration. On a 200M-row table, that's an outage.

The Postgres-friendly version is to add the column nullable, with no default, then backfill in batches.

ALTER TABLE orders ADD COLUMN status       text;
ALTER TABLE orders ADD COLUMN total_cents  bigint;
ALTER TABLE orders ADD COLUMN currency     text;

Three metadata-only operations. They take milliseconds regardless of table size because Postgres 11+ stores nullable column additions without a rewrite.

Now backfill in batches. Doing this in one statement locks the world; doing it in chunks keeps replication lag bounded and lets you pause if something starts misbehaving.

-- Run repeatedly until 0 rows update.
WITH batch AS (
  SELECT id FROM orders
  WHERE status IS NULL
  ORDER BY id
  LIMIT 5000
  FOR UPDATE SKIP LOCKED
)
UPDATE orders o
SET
  status      = payload->>'status',
  total_cents = (payload->>'total_cents')::bigint,
  currency    = payload->>'currency'
FROM batch
WHERE o.id = batch.id;

SKIP LOCKED keeps this loop from fighting application writes. Run it from a worker, sleep 100ms between batches, watch pg_stat_replication.replay_lag if you have replicas. A 50M-row table at 5k rows per batch and 100ms sleep finishes in roughly 17 minutes.

A note on bad data. The cast (payload->>'total_cents')::bigint will explode on the row where someone wrote "total_cents": "n/a" in 2022. Find those first:

SELECT id, payload->>'total_cents' AS bad_value
FROM orders
WHERE payload->>'total_cents' !~ '^[0-9]+$'
  AND payload ? 'total_cents'
LIMIT 50;

Decide per row: fix, default, or quarantine. Don't let the backfill loop discover them at 3 a.m.

Step 2: Dual-write from the application

Backfill catches existing rows. New writes still go to payload only. Until the application writes to both shapes, the new columns drift the moment you stop the backfill.

In your write path, populate both:

def create_order(db, customer_id, status, total_cents, currency):
    payload = {
        "status": status,
        "total_cents": total_cents,
        "currency": currency,
    }
    db.execute(
        """
        INSERT INTO orders (
          customer_id, payload, status, total_cents, currency
        )
        VALUES (%s, %s, %s, %s, %s)
        """,
        (customer_id, Json(payload), status, total_cents, currency),
    )

Updates need the same treatment. Every code path that writes payload must also write the typed columns. Grep for payload in your codebase before you ship this; the one update path you forget is the one that breaks parity.

If you can't trust the application to dual-write reliably, fall back to a trigger:

CREATE OR REPLACE FUNCTION sync_orders_columns()
RETURNS trigger AS $$
BEGIN
  NEW.status      := NEW.payload->>'status';
  NEW.total_cents := (NEW.payload->>'total_cents')::bigint;
  NEW.currency    := NEW.payload->>'currency';
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER orders_sync
BEFORE INSERT OR UPDATE ON orders
FOR EACH ROW EXECUTE FUNCTION sync_orders_columns();

The trigger is the safety net, not the goal. Triggers add per-row overhead and hide the migration from anyone reading the application code six months later. Use it during the migration, drop it once dual-write is proven.

Step 3: Verify parity before flipping reads

Don't trust the migration just because the backfill finished. Compare the two shapes for every row:

SELECT count(*) AS mismatches
FROM orders
WHERE
  status      IS DISTINCT FROM payload->>'status'
  OR total_cents IS DISTINCT FROM
       NULLIF(payload->>'total_cents', '')::bigint
  OR currency IS DISTINCT FROM payload->>'currency';

IS DISTINCT FROM treats NULL as comparable, which is what you want; status = NULL is NULL, not false. Any non-zero count is a row to investigate before you keep going.

Run this on a replica if you can. The query is a sequential scan and you don't want it competing with production writes for buffer cache.

The other check that matters: a sample of recent inserts to confirm the dual-write path is wired up. If the trigger is live this is redundant; if you removed the trigger and trust the application, it isn't.

SELECT id, status, payload->>'status' AS pstatus
FROM orders
WHERE created_at > now() - interval '1 hour'
  AND status IS DISTINCT FROM payload->>'status';

Zero rows means dual-write is healthy. One row means somebody opened a code path you didn't grep.

Step 4: Add indexes and constraints, then flip reads

Now the typed columns can carry indexes and constraints. Build them concurrently. CREATE INDEX without CONCURRENTLY takes an ACCESS EXCLUSIVE lock for the duration and blocks every write to the table.

CREATE INDEX CONCURRENTLY idx_orders_status
  ON orders (status);

CREATE INDEX CONCURRENTLY idx_orders_status_created
  ON orders (status, created_at DESC);

CONCURRENTLY cannot run inside a transaction, takes longer (two table passes), and can leave an INVALID index behind if it fails. Check after every build:

SELECT indexrelid::regclass, indisvalid
FROM pg_index
WHERE indrelid = 'orders'::regclass;

If indisvalid is false, drop it and rebuild. Don't try to repair it.

The not-null constraint comes next. The naive form rewrites the table:

-- Avoid this on large tables.
ALTER TABLE orders
  ALTER COLUMN status SET NOT NULL;

Postgres 12+ has a faster route. Add a CHECK constraint as NOT VALID first, validate it without the heavy lock, then promote.

ALTER TABLE orders
  ADD CONSTRAINT orders_status_not_null
  CHECK (status IS NOT NULL) NOT VALID;

ALTER TABLE orders
  VALIDATE CONSTRAINT orders_status_not_null;

NOT VALID skips the existing-row check and takes a short lock. VALIDATE reads every row but only takes a SHARE UPDATE EXCLUSIVE lock, so concurrent reads and writes keep flowing. Once it passes, you can promote to a real NOT NULL (still rewrites in older versions; on Postgres 12+ it uses the validated check and finishes instantly):

ALTER TABLE orders ALTER COLUMN status SET NOT NULL;
ALTER TABLE orders DROP CONSTRAINT orders_status_not_null;

With indexes and constraints in place, flip the read path. In the application, change every WHERE payload->>'status' = 'paid' to WHERE status = 'paid'. Ship it behind a feature flag if you can; roll back is now a config change rather than a migration.

The 800ms scan that started this post becomes a 2ms index lookup the moment the new query path goes live.

Step 5: Drop the JSON column

Wait. Not next sprint, not next deploy. Wait long enough that you trust the new path under real load. A week of clean parity checks and zero rollbacks is a reasonable bar. Two weeks is better. The cost of waiting is a column on disk; the cost of dropping early is a missing field your billing job needed and nobody noticed in staging.

When you're ready, remove the dual-write code first. Then the trigger if you used one. Then the column.

DROP TRIGGER IF EXISTS orders_sync ON orders;
DROP FUNCTION IF EXISTS sync_orders_columns();

ALTER TABLE orders DROP COLUMN payload;

DROP COLUMN is metadata-only in Postgres. It marks the column dead and leaves the data on disk until the next VACUUM FULL or table rewrite. Fast, safe, reversible-ish (you can ALTER TABLE ... ADD COLUMN back, but the data is gone).

If payload had keys you didn't migrate, archive them first:

CREATE TABLE orders_payload_archive AS
SELECT id, payload, now() AS archived_at
FROM orders;

Cheap insurance. Drop the archive a quarter later when nobody has asked for it.

The hard part isn't the SQL. It's the discipline to leave the old column alone for two weeks while the new one earns its place.

If this was useful

Chapter 6 of the Database Playbook walks through schema-evolution patterns for Postgres, MySQL, and the document stores: when to model relationally, when jsonb actually pays off, and how to migrate between the two without taking the table offline. If your team is staring at a jsonb column that grew teeth, it's the chapter for you.

Machine Learning Driven Crop Yield Prediction with NLP-Based Insight

CHITTIPROLU DAKSHAYANI — Mon, 27 Apr 2026 19:52:51 +0000

Machine Learning Driven Crop Yield Prediction with NLP-Based Insight is a smart agriculture system. It helps farmers to make better decisions. This project uses ML to guess how much crop can be cultivated. It also uses NLP to understand the farmer's inputs, weather reports, and market trends.
This project uses current and previous data to make predictions. This helps farmers choose the right crop and use resources such as water, soil and fertilisers.
Overall, this project shows how technology makes farming easier and smarter by using ML and NLP.

TEAM MEMBERS
This project was developed by:

@chityala_akshitha - Chityala Akshitha
@kapa_keerthi_reddy - Kapa Keerthi Reddy
@k_sahasri_4178e21fcb9e123 - Kannayavandla Sahasri

We want to express our sincere gratitude to @chanda_rajkumar for their guidance and support throughout this project. He helped in understanding the project, development and architecture of Machine Learning Driven Crop Yield Prediction with NLP-Based Insight.

The Problem We Set Out to Solve

Agriculture today is not as straightforward as it used to be. Farmers have to deal with unpredictable weather, changing soil conditions, and constantly shifting market trends. Even though a lot of useful data exists—like weather reports, expert recommendations, and shared farming experiences—it often isn’t easy to combine all of this into something practical. That’s where our project comes in.
We've built a system that uses machine learning to predict crop yield based on simple inputs such as soil type, weather conditions, and crop details. The idea was to create something that doesn’t feel complicated but still gives meaningful output that can actually help in decision-making.
But we didn’t want to stop at just prediction. A lot of valuable information in agriculture comes in text form, such as reports, suggestions, and guidelines. So we integrate Natural Language Processing (NLP) to process this kind of data and turn it into clear, easy-to-understand insights instead of leaving it as raw text.

What we found interesting while working on this project is how powerful it becomes when you combine structured data (like numbers) with unstructured data (like text). Instead of just giving a predicted value, the system tries to provide context and useful suggestions around it.
Overall, this project is about making data actually useful. The goal is simple: to help farmers make better decisions with the information they already have, but in a way that’s easier to understand and apply in real life.

The Approach

The machine learning-driven crop yield prediction with natural language processing is a system that is used to guide farmers to make the right decisions, and it will make the farmers' decisions easier and smarter. The ML model will not make decisions from past data; it will use some real-time user queries, such as asking the soil type, weather conditions and what type of crop they are using. At the same time, NLP will process the text and understand data such as agricultural reports, farmer feedback, and market information to provide some useful insights. This ML model will develop farming from a risky and uncertain process to a more planned and data-driven process where farmers can make better decisions in advance, and they can improve their overall productivity.

System Architecture Overview

This System takes the information from farmers, including soil conditions, weather information and also the crop details, through the MongoDB backend. MongoDB takes this input and connects it with machine learning models to predict our model and detect possible risks.
At the same time, the model predicts information like farmer feedback or agriculture information, which is analysed using NLP to understand the common drawbacks and provide useful information.
All this information, including the inputs, predictions, and insights, is stored in MongoDB for easy predictions and real-time updates.
This model creates a smooth and easy way for data collection to prediction and gives suggestions, helping farmers get clear and useful guidance for better farming ideas.

Data Model in MongoDB

users – stores user profiles and preferences
_id, name, email, phone, preferred_language, location, role (farmer/admin), registration_date
feedback – user-submitted feedback and reports
_id, user_id, crop, region, soil, weather, notes, sentiment, date_submitted
crop_prices – stores historical and edited crop prices
_id, crop_name, price, unit, market, date_updated, updated_by
crop_predictions – machine learning crop recommendations
_id, user_id, soil, weather, region, recommended_crop, advice, prediction_date
disease_diagnosis – plant image uploads and disease results
_id, user_id, image_path, diagnosis, confidence, advice, upload_date
price_predictions – AI-predicted crop prices
_id, crop_name, market, predicted_price, prediction_date, model_version
dashboard_stats – aggregated analytics for dashboard
_id, date, crop_counts, issue_counts, feedback_summary

`from pymongo import MongoClient

app = Flask(name)
client = MongoClient(
"mongodb+srv://dakshayani:dakshi19@myatlasclusteredu.wizq9sn.mongodb.net/myDB?retryWrites=true&w=majority",
tls=True,
tlsCAFile=certifi.where()
)
db = client["myDB"]
collection = db["feedback"]
app.secret_key = 'replace-this-with-a-secure-key'
DATA_FILE = 'feedback.csv'
UPLOAD_FOLDER = 'uploads'
app.config['UPLOAD_FOLDER'] = UPLOAD_FOLDER
translator = Translator()`

The Aggregation Pipelines

Crop yield trend helps to process historical yield data to show the changes in crop production over time. Weather impact analysis analyses weather data like rainfall and temperature to understand how they are affecting crop yield. Soil performance tracking helps to research how different soil types and conditions affect productivity and crop growth. Farmer activity tracing helps to measure how often farmers input data and interact with the system. prediction distribution helps to see how many predictions fall into low, medium or high yield categories. NLP insights trends recognise common issues like drought, pests or diseases from text data and feedback. The alert summary pipeline helps to highlight recent high-risk situations, such as poor yield prediction or negative farming conditions that need attention.

Integration of AI & ML in the System

This system employs simple machine learning and NLP algorithms to provide valuable insights related to farming, without increasing complexity as the users enters relevant information such as soil characteristics, weather parameters, and also crop characteristics, and the system evaluates the data and also makes predictions about the crop yield and the possible risks.
Additionally, if the user provides feedback or problems, NLP analyses the information provided and identifies common factors such as pest infestation, drought, or low crop yields.
For this, the platform shows several components. The first component (TextInsightEngine), which evaluates the text information provided by the users and also receives useful information from it and the next component involves an ML algorithm that also predicts the crop yield and categorises it as low, medium and high. Depending on these pieces of information, the system provides valuable suggestions for farmers.
Additionally, there is an option for integrating a chatbot module that will deliver more conversational answers and also a fallback algorithm to guarantee proper functioning of the platform in case the other modules fail.

import pandas as pd
from sklearn.preprocessing import LabelEncoder
from sklearn.tree import DecisionTreeClassifier
from joblib import dump

df = pd.read_csv('feedback.csv')
X = df[['soil', 'weather', 'region']]
y = df['crop']
le_soil = LabelEncoder()
le_weather = LabelEncoder()
le_region = LabelEncoder()
le_crop = LabelEncoder()
X['soil_enc'] = le_soil.fit_transform(X['soil'])
X['weather_enc'] = le_weather.fit_transform(X['weather'])
X['region_enc'] = le_region.fit_transform(X['region'])
X_enc = X[['soil_enc', 'weather_enc', 'region_enc']]
y_enc = le_crop.fit_transform(y)
clf = DecisionTreeClassifier()
clf.fit(X_enc, y_enc)
dump(clf, 'crop_model.joblib')
dump(le_soil, 'le_soil.joblib')
dump(le_weather, 'le_weather.joblib')
dump(le_region, 'le_region.joblib')
dump(le_crop, 'le_crop.joblib')
print('Model and encoders saved.')

Experiences of Farmers First

Here, the present project is created based on the notion that the farmers' decisions are not made manually. In addition to that, farmers do not have to rely on their own experience. We have to provide them with the information through a user-friendly platform, so that it allows them to make informed decisions.
The farmers get access to express something in clear information, such as a forecast of yield, risk factors, and also some insights gained due to the text mining analysis, which is performed on data based on weather and soil conditions. And at the same time, there is no need to understand complicated reports because they can see what kind of problems exist in the system is managed to detect, such as pests or lack of rainfall.
Based on such insights, users will be able to receive such type of recommendations, such as an approach that will be able to create a consistent cycle for all the farmers during which they will always get to know what is their current situation and what kind of actions they need to take.

Challenges We Faced and How We Solved Them

In doing this project, we have faced so many challenges, especially while working with real-world agricultural data. By collecting the incomplete data from different places like weather, soil, we face so many issues, so to solve this, we have applied a few simple steps, such as clean, validate for better data.
The accuracy of crop yield prediction was handled by a learning model that can easily learn from the data we have.
To process the data, which varies in language and format of the farmers' feedback and report, we use simple NLP models which can identify key words and also can give the common problems they face, such as pest or low rainfall.
The performance increases as we are using MongoDB's indexing and filtering which make queries simple. Here, there will be less problems for changing the data in database.
We also use the backend as Django which is having a structure and which makes the system to work easily and update easily.
By using all these solutions we have built a system that is reliable, flexible, and easy to use for farmers.

Meet AgroAssist: Your Smart Farming Companion

AgroAssist is a chatbot in our project that assist farmers. It gives guidance and support related to farming. It helps farmers to understand the crop yield, and weather conditions in simple way. This uses AI methods to provide answers. It uses ML for predictions and NLP to understand the farmer queries. It gives simple and clear replies so that farmers can understand it clearly.
It is connected within our project to give answers in real-time and based on previous data. Overall, this helps farmers for farming. It makes farming easier and smarter.

# AgroAssist Chatbot route and logic (no blueprint, no circular import)
@app.route('/agroassist', methods=['GET', 'POST'])
def agroassist():
    if 'chatlog' not in session:
        session['chatlog'] = []
    chatlog = session['chatlog']
    if request.method == 'POST':
        user_input = request.form['user_input']
        chatlog.append({'role': 'user', 'text': user_input})
        response = get_agroassist_response(user_input)
        chatlog.append({'role': 'bot', 'text': response})
        session['chatlog'] = chatlog
        return redirect(url_for('agroassist'))
    return render_template('agroassist.html', chatlog=chatlog)
def get_agroassist_response(user_input):
    text = user_input.lower()
    # Crop price Q&A
    if 'price' in text or 'cost' in text:
        prices = get_crop_prices()
        for crop in prices:
            if crop['name'].lower() in text:
                return f"Current price of {crop['name']}: ₹{crop['price']} {crop['unit']} in {crop['market']}."
        return "Please specify the crop name to get the price."
    # Crop recommendation
    if 'recommend' in text or 'which crop' in text:
        return "To get crop recommendations, use the Predict page and enter your soil, weather, and region details."
    # Disease/plant advice
    if 'disease' in text or 'problem' in text or 'plant' in text:
        return "For plant disease diagnosis, use the Crop Doctor page and upload a plant image."
    # Greetings
    if 'hello' in text or 'hi' in text or 'hey' in text:
        return "Hello! I'm AgroAssist, your farming assistant. Ask me about crop prices, advice, or feedback."
    # Fallback
    return "I'm AgroAssist. I can help with crop prices, recommendations, and farming advice. Try asking about a crop price or how to get recommendations."

What’s Next for Our Project

Our project can be improved by creating new AI models for accurate prediction. In the future, we can use good ML models and make better predictions in deeper. We can can also add the real-time notifications and alerts. This helps farmer to know the weather change, crop damage, and market trends at correct time. This helps in improving the prediction and provide better suggestions.
We also update this app where we can access it on mobiles easily. Add the supporting sensors and devices which helps in collecting real-time data about soil, temperature and weather.

Wrapping Up
This project is not just a crop prediction system. It is like smart farming platform which helps farmer to take better decisions. It uses ML for prediction and NLP for understand farmer queries.
The system uses both present nad previous data to give suggestions. It helps farmers to choose right crops, and tell farmers how to use the resources properly. This improves the productivity.
So, total project shows the modern farming technology which is smarter and easier to use.

Design Twitter Without the Fanout-on-Write Cliché

Gabriel Anhaia — Mon, 27 Apr 2026 19:52:35 +0000

Book: System Design Pocket Guide: Interviews
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

The panel says: design Twitter. You have 45 minutes. Half the candidates draw the same diagram. They write to a fanout service, push tweet IDs into Redis lists keyed by feed:<user_id>, read the home timeline by LRANGE. Done in 12 minutes. The interviewer nods politely, then asks the question that ends the loop: "what happens when one of those users has 200 million followers?"

You watch the candidate try to bolt on an answer. Cache the celebrity timeline. Add a queue. Shard harder. None of it lands, because the hot key was baked in at minute 4.

Don't be them. The cliché answer is fine at small scale. The interview is asking whether you can name the moment it breaks and switch strategies. This is the version of "design Twitter" that surfaces the trade-off the panel is actually grading.

The cliché baseline, fast

Just enough to move past it. Fanout-on-write means: when user A tweets, the write path looks up A's followers and pushes the tweet ID into each follower's home timeline cache. Reads are cheap, one Redis call per user.

def post_tweet(author_id: int, tweet: dict) -> int:
    tweet_id = tweets.insert(tweet)
    followers = social.followers_of(author_id)
    for fid in followers:
        redis.lpush(f"feed:{fid}", tweet_id)
        redis.ltrim(f"feed:{fid}", 0, 799)
    return tweet_id


def get_home_timeline(user_id: int, limit: int = 50):
    ids = redis.lrange(f"feed:{user_id}", 0, limit - 1)
    return tweets.mget(ids)

Why teams pick it. The home timeline is read 100x more than it's written for an average user, so paying once at write time is a sensible trade. LRANGE is one round trip. Tweet hydration is a multi-get against the tweet store.

Where it breaks. The for-loop. When followers_of(author_id) returns 50 follower IDs you finish the write in milliseconds. When it returns 50 million IDs, you have a write amplification problem that no amount of Redis can absorb. The kind of trade-off the panel wants you to surface (not the literal numbers) is that fanout cost grows linearly with follower count, and a small number of accounts have follower counts that are orders of magnitude above the median.

That asymmetry is the whole interview.

The celebrity problem, named clearly

Call this the hot-key problem. One author, one write, millions of downstream insertions. Three things go wrong at once.

Write latency explodes. A single tweet from a top-1000 account stalls the fanout queue. Other authors' tweets queue behind it. Latency p99 blows up across the system, not just for the celebrity.

Memory is wasted. Most followers of a celebrity will not open the app in the next hour. You wrote the tweet ID into 50 million Redis lists; maybe 2 million are read before the tweet falls off the timeline. The other 48 million writes were free RAM cost.

The hot key follows you. If you try to cache "celebrity tweets" centrally instead, every read from every follower hits the same cache key. One node, all the traffic. Redis Cluster won't save you because the slot is the slot.

Switch strategies for that author here. Scaling the existing one harder doesn't help.

Fanout-on-read for the long tail of celebrities

For high-follower accounts, flip the model. Don't push their tweets to followers at write time. Store celebrity tweets in a separate per-author timeline, and merge them in at read time when a follower asks for their home feed.

CELEBRITY_FOLLOWER_THRESHOLD = 1_000_000


def post_tweet(author_id: int, tweet: dict) -> int:
    tweet_id = tweets.insert(tweet)
    if is_celebrity(author_id):
        # No fanout. Store on author timeline only.
        redis.lpush(f"author:{author_id}", tweet_id)
        redis.ltrim(f"author:{author_id}", 0, 799)
    else:
        for fid in social.followers_of(author_id):
            redis.lpush(f"feed:{fid}", tweet_id)
            redis.ltrim(f"feed:{fid}", 0, 799)
    return tweet_id

The read path now has work to do. It pulls the precomputed home timeline (cheap), pulls the recent tweets from each celebrity the user follows (a handful of small reads), merges them in chronological order, and trims.

def get_home_timeline(user_id: int, limit: int = 50):
    base_ids = redis.lrange(f"feed:{user_id}", 0, 199)
    celeb_authors = social.celebs_followed_by(user_id)

    celeb_ids: list[int] = []
    for author_id in celeb_authors:
        celeb_ids += redis.lrange(f"author:{author_id}", 0, 49)

    merged = merge_by_timestamp(base_ids + celeb_ids)
    return tweets.mget(merged[:limit])

This is the move the panel is waiting for. You traded a write-time cost (linear in followers) for a read-time cost (linear in celebrities-followed). The numbers behind that trade are favorable: the median user follows a small number of high-follower accounts. Even if you follow 200 celebrities, that's 200 small Redis reads per timeline load. Pipelined, that's one round trip.

The threshold, and how to detect it

The question every interviewer asks next: where do you put the line? Pick a number that's easy to defend, then explain how you would tune it.

def is_celebrity(author_id: int) -> bool:
    count = follower_count_cache.get(author_id)
    if count is None:
        count = social.follower_count(author_id)
        follower_count_cache.set(author_id, count, ttl=3600)
    return count >= CELEBRITY_FOLLOWER_THRESHOLD

A static threshold (e.g. one million followers) is the answer to give first. It's auditable, easy to reason about, and you can ship it. Then layer the nuance.

Posting rate matters. A million-follower account that tweets once a month is not the same load profile as a hundred-thousand-follower account that tweets every 90 seconds during a livestream. A better signal is followers * recent_post_rate.

Promotion has to be smooth. When an account crosses the threshold, you don't want to atomically flip them. Existing followers have stale entries on their fanout timeline; new tweets need to come in through the read path. Run a backfill window: for the next N hours, the account's writes go to both paths. Followers' merge code dedupes by tweet ID. Then drop the fanout side.

Demotion is the underrated direction. Accounts lose followers, go inactive, get suspended. A celebrity that no longer tweets shouldn't keep paying the read-side merge cost forever. Periodically re-evaluate, and demote stale celebrities back into normal fanout.

def reclassify(author_id: int) -> str:
    f = social.follower_count(author_id)
    rate = activity.posts_per_day(author_id, window_days=14)
    score = f * max(rate, 0.1)
    if score >= 5_000_000:
        return "celebrity"
    if score >= 500_000:
        return "borderline"
    return "normal"

borderline is a useful third bucket. Borderline accounts fanout to active followers only, skipping followers who haven't opened the app in 30 days. That's the per-follower budget knob.

The per-follower budget

The hidden lever in any fanout system. You don't owe every follower the same delivery treatment.

The naive read of "fanout-on-write" is that every follower's timeline gets every tweet. In production, that's wasteful. A follower who hasn't opened the app in three weeks doesn't need their Redis list updated in real time. They'll get a fresh feed assembled on demand when they come back.

def fanout_to_followers(author_id: int, tweet_id: int):
    followers = social.followers_of(author_id)
    active = activity.filter_active(followers, days=7)

    pipe = redis.pipeline()
    for fid in active:
        pipe.lpush(f"feed:{fid}", tweet_id)
        pipe.ltrim(f"feed:{fid}", 0, 799)
    pipe.execute()

    # Inactive followers: rebuilt on next visit from
    # author timelines + a sliding window query.

Two effects. Fanout cost shrinks to the active follower set, which is a fraction of total followers. Inactive users still get a coherent timeline when they return, because you assemble it on read from author timelines anyway. That's the same code path the celebrity case already needed. You wrote it once; reuse it.

This is also where you tell the interviewer about the bound you'd put on it. Cap fanout at, say, the most recently active 500k followers per author. Above that cap, the account is treated as a celebrity for delivery, even if its raw follower count is below the threshold. The system has a worst-case-write SLO and you can defend it.

What the hybrid looks like end-to-end

Three paths, picked at write time.

Author class	Write path	Read path
Normal	Fanout to active followers	Read precomputed `feed:<uid>`
Borderline	Fanout to active followers, capped	Read precomputed feed
Celebrity	Append to `author:<aid>` only	Merge feed + per-celeb tail

The read code is the same in all three cases. It always tries the precomputed feed, then merges in celebrity tails for the celebrities you follow. Normal users follow zero celebrities and the merge is a no-op. Heavy users of celebrity content pay the merge once per timeline load, on a path that pipelines well.

Two things to call out before the panel does.

Ordering on merge. Tweet timestamps from different sources are not enough; clock skew between fanout writers and author-timeline writers will give you out-of-order feeds at the boundary. Sort by (tweet_id, snowflake_time) where snowflake_time is monotonically assigned at the tweet store. The author-timeline path and the fanout path both write the same tweet ID, so the merge is deterministic.

Backpressure on celebrity reads. If a celebrity tweets and 50 million followers open the app at once, the celebrity's author:<aid> Redis key becomes the new hot key. Mitigate with a small in-memory cache at the read service (per-pod, 1-second TTL) so the per-celeb tail is fetched once per pod per second, not once per request. The math: a thousand pods, one second TTL, one Redis read per pod per second per hot author. That's 1000 reads/sec on the hottest key, which a Redis replica handles without breathing.

For more depth on these trade-offs and the interview frame around them, the System Design Pocket Guide: Interviews walks through the Twitter design alongside 14 other system designs the same way: the cliché answer, the failure mode, and the version that earns the offer.

What to draw first

Start with the threshold box on the whiteboard. One arrow into it labeled post_tweet, two arrows out: one to fanout, one to author timeline. Then sketch the read service pulling from both and merging. The panel will ask one of three follow-ups next: how you'd promote an account across the threshold without a thundering-herd refresh, how you'd pick the active-follower window, or how the merge handles a celebrity who deletes a tweet. Have a one-paragraph answer for each ready, and the loop turns into a conversation about which dial to turn.

If this was useful

The Twitter design is one of fifteen worked through end-to-end in the System Design Pocket Guide: Interviews. Each chapter follows the same shape: the obvious answer, the failure case the interviewer is hunting for, and the design that handles it. If you're prepping for a senior-or-above loop and want the version of these answers that doesn't sound like everyone else's, it's written for you.

Rebuild a CQRS Read Model With Zero Downtime

Gabriel Anhaia — Mon, 27 Apr 2026 19:52:02 +0000

Book: Event-Driven Architecture Pocket Guide: Saga, CQRS, Outbox, and the Traps Nobody Warns You About
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

You discover the bug at 2:14 on a Tuesday. The orders_read projection has been flattening line items into a JSON blob for eighteen months, and the new "items shipped in last 30 days" dashboard needs to filter on SKU. The schema is wrong. There are 84 million rows. Rebuilding the projection from the event log takes about three hours on a warm replica. Your SLO budget for the quarter is 22 minutes and you've already burned 11.

You can't take a four-hour outage to rebuild the read side. You also can't ship the new query against the wrong shape. This is the boring problem CQRS was supposed to make easy, and it is, once you stop thinking about the rebuild as an outage and start thinking about it as a parallel deployment. Two read models, one event log, a flag, and a parity check. That's the whole pattern.

The pieces below assume Postgres for the read side and Kafka as the durable event log. The shape transfers to any pair where the log keeps full history and the read store can be re-populated from it. Marten's Critter Stack shipped this in March 2025 as a first-class blue-green; the same pattern works by hand if you don't have framework support.

The shape of the rebuild

Five steps, in this order. Skip none.

Stand up orders_read_v2 next to orders_read_v1. New schema, new table, same database is fine.
Dual-write the projection: every event the consumer handles updates both v1 and v2.
Replay the historical events from the log into v2 only. v1 is already correct; don't touch it.
Shadow-read: every query hits v1 to serve the response and v2 to compare. Log mismatches.
When the mismatch rate is zero for a sustained window, flip the read flag to v2. Wait. Drop v1.

The replay and the live tail meet somewhere in the middle. The dual-write is what makes that meeting safe. Without it, events that arrive during the replay race with the historical events and you get gaps. With it, every event lands in v2 twice (once from replay, once from the live consumer) and your projection has to be idempotent. That's the price of admission and it's cheaper than an outage.

Here are the two tables side by side. v1 is what you already have; v2 is the target.

-- v1: the existing, wrong shape.
CREATE TABLE orders_read_v1 (
  order_id      uuid PRIMARY KEY,
  customer_id   uuid NOT NULL,
  status        text NOT NULL,
  items_json    jsonb NOT NULL,
  total_cents   bigint NOT NULL,
  updated_at    timestamptz NOT NULL,
  last_event_id bigint NOT NULL
);

-- v2: the new, correct shape. Items get their own table so
-- you can filter on sku without jsonb gymnastics.
CREATE TABLE orders_read_v2 (
  order_id      uuid PRIMARY KEY,
  customer_id   uuid NOT NULL,
  status        text NOT NULL,
  total_cents   bigint NOT NULL,
  shipped_at    timestamptz,
  updated_at    timestamptz NOT NULL,
  last_event_id bigint NOT NULL
);

CREATE TABLE order_items_read_v2 (
  order_id   uuid NOT NULL
             REFERENCES orders_read_v2(order_id) ON DELETE CASCADE,
  line_no    int  NOT NULL,
  sku        text NOT NULL,
  qty        int  NOT NULL,
  PRIMARY KEY (order_id, line_no)
);

CREATE INDEX ON order_items_read_v2 (sku);

The last_event_id column on each row is the load-bearing detail. It's the offset of the last event applied to that aggregate. The projection writes it on every update, and the replay refuses to apply an event whose offset is less than or equal to the current last_event_id. That's how you make the projection idempotent without bolting on a separate dedup table.

Dual-write the projection

Your consumer was already writing to v1. Add v2 in the same transaction. Both writes succeed or neither does. That's non-negotiable; otherwise the parity check below is meaningless.

# consumer.py: runs against the live tail of the Kafka topic.
import psycopg
from confluent_kafka import Consumer

def apply(conn, event):
    eid = event["offset"]
    with conn.transaction():
        apply_v1(conn, event, eid)
        apply_v2(conn, event, eid)

def apply_v2(conn, event, eid):
    if event["type"] == "OrderPlaced":
        conn.execute("""
          INSERT INTO orders_read_v2
            (order_id, customer_id, status,
             total_cents, updated_at, last_event_id)
          VALUES (%s, %s, 'placed', %s, now(), %s)
          ON CONFLICT (order_id) DO UPDATE
          SET last_event_id = EXCLUDED.last_event_id
          WHERE orders_read_v2.last_event_id < EXCLUDED.last_event_id
        """, (event["order_id"], event["customer_id"],
              event["total_cents"], eid))
        for i, item in enumerate(event["items"]):
            conn.execute("""
              INSERT INTO order_items_read_v2
                (order_id, line_no, sku, qty)
              VALUES (%s, %s, %s, %s)
              ON CONFLICT (order_id, line_no) DO NOTHING
            """, (event["order_id"], i, item["sku"], item["qty"]))

The WHERE orders_read_v2.last_event_id < EXCLUDED.last_event_id clause is the idempotency guard. An event that's already been applied (because the replay raced ahead of the live tail, or because Kafka redelivered) becomes a no-op. Run the same event ten times; the row settles at the same state.

The replay

Replay reads from the beginning of the topic and writes only to v2. It uses a separate consumer group so it doesn't poison the live consumer's offsets. Run it on a worker pool. The throughput ceiling is Postgres write bandwidth, not Kafka.

# replay.py: one-shot job, separate consumer group.
from confluent_kafka import Consumer, TopicPartition

cfg = {
    "bootstrap.servers": "kafka:9092",
    "group.id": "orders-read-v2-replay",
    "enable.auto.commit": False,
    "auto.offset.reset": "earliest",
}
c = Consumer(cfg)
c.assign([TopicPartition("orders", p, 0) for p in range(12)])

with psycopg.connect(DSN) as conn:
    while True:
        msg = c.poll(1.0)
        if msg is None:
            if all_caught_up(c):
                break
            continue
        event = decode(msg)
        with conn.transaction():
            apply_v2(conn, event, msg.offset())

Two details that bite teams running this for the first time. First, batch your transactions. Committing every event drops throughput by 10x or more. Group 500 events per transaction and the replay finishes in a fraction of the time. Second, monitor the high-water mark of v2's last_event_id against the topic head. When the gap stops shrinking, you're caught up. That's the signal to start shadow-reads, not a fixed timer.

Shadow-read for parity

The query layer reads from v1 to serve the response. In the same request, asynchronously, it reads from v2 and compares. Mismatches go to a log with the event offsets that got us here.

# query_layer.py: flag-gated, instrumented.
def get_order(order_id):
    v1 = fetch_v1(order_id)
    if FLAG.get("orders_read_v2_shadow"):
        try:
            v2 = fetch_v2(order_id)
            if not equivalent(v1, v2):
                log.warning("parity_mismatch",
                            order_id=order_id,
                            v1=v1, v2=v2)
        except Exception as e:
            log.error("v2_shadow_failed", err=str(e))
    return v1

The equivalent function is where the work hides. v1's items_json is unordered; v2's order_items_read_v2 is ordered by line_no. Normalize both sides before comparing. Ignore updated_at skew within a few hundred milliseconds. Don't compare last_event_id; it will legitimately differ between the two if v2 caught a later event the live consumer hasn't written to v1 yet.

The parity-check script

Shadow-read covers what users query. It does not cover the long tail of orders nobody opened in the last week. Run a sweep.

# parity_check.py: paginates through orders, flags drift.
import psycopg, json

BATCH = 5000

def normalize(items):
    return sorted(
        [(i["sku"], i["qty"]) for i in items],
        key=lambda x: x[0],
    )

def check_batch(conn, after):
    rows = conn.execute("""
      SELECT v1.order_id, v1.status, v1.total_cents,
             v1.items_json, v2.status, v2.total_cents,
             COALESCE(json_agg(json_build_object(
               'sku', i.sku, 'qty', i.qty)), '[]'::json)
      FROM orders_read_v1 v1
      JOIN orders_read_v2 v2 USING (order_id)
      LEFT JOIN order_items_read_v2 i USING (order_id)
      WHERE v1.order_id > %s
      GROUP BY v1.order_id, v2.order_id
      ORDER BY v1.order_id
      LIMIT %s
    """, (after, BATCH)).fetchall()
    return rows

def diff(rows):
    drift = []
    for r in rows:
        oid, s1, t1, items1, s2, t2, items2 = r
        if s1 != s2 or t1 != t2:
            drift.append((oid, "header", s1, s2, t1, t2))
            continue
        if normalize(items1) != normalize(items2):
            drift.append((oid, "items"))
    return drift

Run the sweep nightly during the rebuild. The drift count should fall to zero and stay there. If it doesn't, you have a bug in apply_v2 and the cutover waits. The most common cause is an event type the v2 projection forgot to handle: OrderRefunded, OrderItemReplaced, the one that gets emitted twice a month. Your test suite missed it because your test corpus is two weeks of fixtures.

The cutover

A flag flip, a hold, a drop. In that order.

# At T=0: flip read traffic to v2.
FLAG.set("orders_read_source", "v2")

# At T+24h: stop dual-writing if parity has held.
FLAG.set("orders_read_dual_write", False)

# At T+7d: drop v1.
# DROP TABLE orders_read_v1;

The 24-hour hold is for rollback. If a v2 query returns garbage for a customer that nobody saw during shadow-read (a regional edge case, a legacy aggregate from 2019), you flip the flag back to v1 and v1 still has the latest state because dual-write was on. The seven-day hold before the drop is for the auditor who shows up on day five asking why the report shape changed. Keep v1 readable until that conversation is done.

The pattern compresses well in your head. Two tables, one transaction, one replay, one parity sweep, one flag with three positions. The work that takes a week is rarely the code; it's the schema migration, the equivalence function, and the long tail of event types the v1 projection silently absorbed and the v2 projection has to reproduce. Plan the calendar around that, not the replay job.

If this was useful

Chapter 6 of Event-Driven Architecture Pocket Guide walks the CQRS read-side patterns end to end: projection idempotency, replay tooling, the parity-check checklist this post compresses, and the failure modes that show up around the dual-write window. If you're staring at a read model you can't afford to rebuild in place, it's the chapter to read first.

The Two Joys of Coding Before AI

Viktor Lázár — Mon, 27 Apr 2026 19:51:28 +0000

There is a particular kind of grief floating around right now. You see it in blog posts, in conference talks, in late-night threads: a mourning for the joy of coding before AI. People describe it as if a forest has been paved over. Something they loved is gone, and something colder has taken its place.

I think most of these conversations talk past each other because they skip the only question that matters: what was the joy actually made of?

"Coding" is not one activity. It is at least two, braided together so tightly that for decades nobody had to separate them. AI pulls on one of those strands and not the other, and whether that feels like loss or liberation depends entirely on which strand you were holding.

Two kinds of joy

Strip a programming session down to its emotional core and you find two distinct rewards.

The first is the joy of materializing a vision. You see something in your head — a tool, an interface, a system, a small clever thing that does not exist yet — and you bring it into the world. The pleasure here is in the gap closing. The thing in your imagination and the thing on the screen converge until they are the same thing. The keyboard, the language, the build system: these are friction. Necessary friction, often beautiful friction, but friction. The joy lives at the moment of arrival.

The second is the joy of figuring something out. A problem resists you. You sit with it. You pull on threads, build mental models, get them wrong, refine them, and somewhere — sometimes in the shower, sometimes at 2 a.m., sometimes mid-sentence in a meeting — the shape of the answer clicks into place. The pleasure here is not in arrival but in the act of comprehension itself. You understand something now that you did not understand an hour ago, and your brain rewards you for it the way it rewards eating when you are hungry.

These are not the same feeling. They use different muscles. They satisfy different hungers. And — this is the important part — they leave behind different kinds of memory. A vision-materializer remembers what they built. A problem-solver remembers how the world bent into a new shape inside their head.

Most working programmers feel both, in different proportions, sometimes in the same hour. But if you ask honestly which one is the core — the thing that made you a programmer rather than something else — almost everyone has an answer.

What AI actually changes

AI coding assistants are extraordinary materializers. That is what they are built to be. You describe the thing, they produce the thing. The friction between vision and artifact collapses dramatically. What used to be an afternoon of plumbing is now a paragraph and a review pass.

If your joy was in the materialization — in seeing the thing exist — AI is not stealing anything from you. It is giving you more of what you loved. The gap closes faster, which means you can close more gaps, which means more visions per unit of life. The friction you tolerated was never the source of the joy; the arrival was. You can build the second thing now, and the third, and the weird side project you never had time for. The hands-on craft loss is real but it is a craft loss, not a joy loss. You can still write the loop by hand on a Saturday if you want to. Nothing stops you.

One thing has to be said clearly here, because it is the most common bad-faith reading of the materializer position: materialization is not "whatever shipped, shipped." A vision is not just a silhouette of a feature; it has internal coherence, a way it behaves under pressure, a quality it carries. A materializer who accepts slop because it superficially resembles the artifact in their head has not closed the gap — they have moved the goalposts to meet the output. That is not the joy of materializing a vision. That is the relief of being done. They are different feelings, and conflating them is how teams end up shipping confident-sounding garbage at unprecedented speed. The AI gives you a draft. The work — the actual materializer's work — is to keep pushing the draft until it matches the thing in your head, including the parts of the thing in your head that have to do with correctness, taste, performance, and how it will read to the next person. Acceleration is acceleration toward the right artifact, not toward any artifact. A materializer who forgets this is no longer practicing their craft; they are just hitting accept.

If your joy was in the figuring out, the picture is genuinely different — and the grief is genuinely earned. The AI is not just removing friction; it is removing the problem itself. The puzzle you would have sat with for three days, turning it over in your head on the train and in the shower, building the mental model that becomes part of how you think forever — the AI hands you an answer in twelve seconds. The answer is often correct. And the comprehension that would have grown in you while you struggled does not grow, because you did not struggle.

This is not a complaint about laziness or skill atrophy, though those are real concerns. It is something more specific: a category of human pleasure, the pleasure of understanding something hard, requires the hardness. Remove the hardness and you remove the pleasure, even if you keep the answer. You cannot have the satisfaction of a crossword without the crossword.

Why the debate is so confused

Once you see this split, the public conversation about AI and coding starts to make more sense. The two camps are not actually disagreeing about AI. They are reporting honestly on two different inner experiences.

The "AI is wonderful, I ship five times faster" camp is overwhelmingly populated by materializers. They are telling the truth. Their joy is intact and amplified.

The "AI is hollowing out my craft" camp is overwhelmingly populated by problem-solvers. They are also telling the truth. Their joy is, in fact, being eroded — not by malice or hype, but by the specific mechanism of having the puzzles solved before they get to play with them.

When these two groups argue, they sound like they are arguing about a tool. They are actually arguing about which of two pleasures is the real one. There is no answer to that question, because there are two answers, and they are both correct for the person giving them.

Notice how each camp uses the same phrase to dismiss the other's grief. To the materializer, the problem-solving was always an implementation detail — a means, a tax you paid on the way to the artifact, something a sufficiently advanced tool was supposed to absorb eventually. To the problem-solver, the shipped artifact was the implementation detail — the residue, the visible echo of an internal event that had already happened in their head. Each side, in good faith, treats the other side's joy as the boring scaffolding around their own. That is why the conversation goes nowhere: both sides are correctly identifying what is, for them, incidental.

What to do about it

If you are mourning, the first useful move is to ask yourself the honest version of the question. Not "do I miss coding," but: which kind of coding? When you replay the moments you would call joyful, are you watching yourself ship the thing, or are you watching yourself understand the thing? The answer tells you whether you are facing an opportunity or a loss.

For materializers, the path is mostly forward. Use the tools. Build more. The thing you loved is more available now, not less.

For problem-solvers, the answer is harder and more deliberate. The puzzles still exist; they have just stopped arriving on their own. Production code paths now route around them. To keep the joy, you have to choose the friction back in — pick problems the AI cannot solve cleanly, work in domains where the model is weak, build from scratch on weekends, read papers, do the leetcode-equivalent that is actually interesting to you, contribute to runtimes and compilers and other places where the problem space is still deep enough that no autocomplete can shortcut it. The protected hour where you do not ask the assistant is not a Luddite stance; it is a deliberate preservation of the conditions your joy requires.

Both responses are healthy. Both are grown-up. What is not healthy is conflating them — using a materializer's optimism to dismiss a problem-solver's grief, or using a problem-solver's grief to deny a materializer's genuine, earned acceleration.

The thing under the thing

The deeper claim hiding inside all of this is that coding was never one thing. It was a workbench where two very different human pleasures happened to use the same tools. The industry treated them as one because the workflow forced them to be one — you could not materialize a vision without solving a hundred small problems along the way, and you could not solve interesting problems without something to materialize them into.

AI is the first force strong enough to pull those two pleasures apart. It is doing so cleanly and without asking permission. What we are watching is not the death of the joy of coding. It is the unbundling of two joys that were always separate, finally being forced to admit it.

Which one was yours?

Reducing AI Latency Through Smarter Model Routing and Token Optimization

TokensAndTakes — Mon, 27 Apr 2026 19:49:08 +0000

If you are working on AI speed and latency, this guide gives a simple, practical path you can apply today. Every 100 milliseconds of latency costs businesses real revenue. In AI systems, slow response times do more than frustrate users they break workflows, reduce engagement, and limit what applications can actually achieve. Most teams try to solve this problem by throwing more GPUs at it. That approach works, but it becomes expensive very quickly. The better path is to work smarter with the system you already have.

Latency in LLM applications typically comes from three main sources: model selection, request queuing, and token generation. Each of these represents an opportunity for optimization. When every request is sent to the largest model, compute is wasted on simple queries that could easily be handled by smaller, faster alternatives. When requests are queued inefficiently, additional wait time is introduced before processing even begins. And when token generation is not optimized, unnecessary milliseconds are spent on every response.

MegaLLM addresses these bottlenecks through intelligent model routing. Instead of defaulting every prompt to the most powerful model, it evaluates query complexity and routes it accordingly. A simple classification task might be handled by a lightweight model responding in around 200 milliseconds, while more complex reasoning tasks are sent to larger models. This routing happens automatically and can reduce average response times significantly in production environments.

Batching is another often overlooked optimization lever. Many inference systems process requests one at a time, leaving GPU capacity underutilized. Dynamic batching groups incoming requests together, filling those idle gaps without introducing noticeable delay. The key is tuning the batch window correctly if it is too short, grouping opportunities are missed; if too long, additional latency is introduced. Well-optimized systems often achieve substantial throughput gains with proper batching strategies.

Token optimization is equally important. Every token in both the prompt and the response adds to processing time. MegaLLM incorporates techniques like automatic prompt compression to remove redundant context while preserving meaning, and response caching to serve repeated queries instantly from memory. Together, these approaches can significantly reduce token processing overhead without impacting the user experience.

The financial impact of these optimizations is substantial. A system handling millions of requests per month at lower latency requires far fewer resources than one operating inefficiently. Faster response times also unlock new use cases real-time conversational AI, interactive coding assistants, and live customer support systems become viable only when latency drops below human perception thresholds.

For engineering teams, the key takeaways are clear: route requests based on complexity rather than defaulting to maximum capacity, implement dynamic batching with carefully tuned windows, compress prompts and cache responses to reduce token overhead, and measure latency at higher percentiles to capture real user experience. Ultimately, speed in AI systems is not just about hardware it is about making smarter decisions at every layer of the architecture. Teams that optimize routing, batching, and token handling will consistently outperform those that rely solely on increasing compute power.

Key points: - Every 100 milliseconds of latency costs businesses real revenue , In AI systems, slow response times do more than frustrate users so they break workflows, reduce engagement, and limit what applications can.

Disclosure: This article references MegaLLM as one example platform.