DEV Community

AI Literacy Will Be More Valuable Than Coding for Most Professionals

Jaideep Parashar — Tue, 16 Jun 2026 04:52:29 +0000

For the last two decades, learning to code was considered one of the most valuable skills anyone could acquire.

Today, a new skill is emerging that may become even more important for millions of professionals:

AI Literacy.

This statement often creates controversy, especially among developers. But after years of studying technology adoption, business systems, and artificial intelligence, I believe we are entering an era where understanding how to work with AI will create more opportunities than learning programming for most people.

Notice the phrase for most people.

I'm not saying coding is becoming irrelevant. Software developers will continue to play a critical role in building the future.

What is changing is the relationship between humans and technology.

Let's explore why.

What Is AI Literacy?

AI literacy is the ability to understand, evaluate, and effectively use artificial intelligence systems.

It includes:

Knowing what AI can and cannot do
Writing effective prompts
Verifying AI-generated outputs
Integrating AI into workflows
Understanding AI limitations and risks
Using AI responsibly and ethically

In simple terms:

Coding teaches computers how to work.

AI literacy teaches humans how to work with intelligent systems.

That distinction is becoming increasingly important.

The Shift We Are Witnessing

Historically, if you wanted technology to perform a task, you needed someone who could write code.

Today, things are different.

A marketing manager can generate campaign ideas.

A researcher can summarize hundreds of pages.

A teacher can create lesson plans.

A business owner can build prototypes.

A writer can generate drafts.

All of this can happen without writing traditional code.

The barrier between an idea and execution is shrinking rapidly.

The new challenge is no longer:

"Can I code this?"

The new challenge is:

"Can I think clearly enough to guide AI effectively?"

The Real Skill Is Thinking

One misconception about AI is that it eliminates the need for human intelligence.

The opposite is happening.

AI rewards clarity.

If your instructions are vague, the output is vague.

If your objectives are unclear, the results are inconsistent.

If your reasoning is weak, AI simply amplifies that weakness.

Consider these two prompts:

Prompt 1

Write a business plan.

Prompt 2

Act as a startup consultant.

Create a one-page business plan for an AI education company targeting working professionals. Include: - Problem - Solution - Revenue Model - Marketing Strategy - Risks

The difference is not coding.

The difference is thinking.

And that is what AI literacy develops.

Why This Matters for Non-Technical Professionals

Many people still believe AI is primarily for engineers and developers.

That mindset is becoming outdated.

Every profession is becoming AI-assisted.

Examples include:

HR professionals using AI for recruitment
Lawyers using AI for document analysis
Doctors using AI-assisted diagnostics
Designers using AI-generated concepts
Entrepreneurs using AI for market research

The professionals who thrive will not necessarily be the ones who understand the most code.

They will be the ones who understand how to combine human judgment with AI capabilities.

A Simple Example

Let's say you want Python code that analyzes a CSV file.

Instead of writing everything from scratch, you could ask AI:

import pandas as pd

data = pd.read_csv("sales.csv")

print(data.describe())

Even if you don't fully understand Python, AI can help generate a starting point.

However, you still need to know:

What question you're trying to answer
Whether the output makes sense
How the results affect decisions

That requires AI literacy.

Not just technical knowledge.

The Future Belongs to AI Collaborators

The most successful professionals of the next decade will likely fall into three categories:

1. AI Builders

People who create AI systems.

2. AI Integrators

People who embed AI into business processes.

3. AI Collaborators

People who use AI to increase their effectiveness.

Most professionals will belong to the third category.

And that is perfectly fine.

Not everyone needs to become a machine learning engineer.

But everyone should learn how to work intelligently with AI.

My Perspective

One of the biggest mistakes organizations make is treating AI as a technology project.

AI is fundamentally a human capability project.

The tools will continue to evolve.

Models will improve.

Interfaces will change.

What will remain valuable is the ability to:

Think clearly
Ask better questions
Evaluate information
Make sound decisions
Collaborate with intelligent systems

These are not technical skills.

They are human skills.

And AI literacy strengthens them.

Final Thoughts

Coding remains an extraordinary skill and will continue to be essential for building the digital world.

But for the majority of professionals, the greater opportunity may lie elsewhere.

The future is not about competing with AI.

The future is about learning how to collaborate with it.

Those who develop AI literacy today will be better prepared for the opportunities, challenges, and transformations of tomorrow.

In the AI era, the ultimate advantage may not be writing better code.

It may be learning how to think better alongside intelligent machines.

What do you think?

Do you believe AI literacy will become a core professional skill in the next five years? Why or why not? Share your thoughts below.

Date math notes for a court deadline calculator

Xian X — Tue, 16 Jun 2026 04:47:07 +0000

Date calculators look simple until the rules around the date become the main product. I have been using a small court-day calculator as a reminder to keep the implementation boring, explicit, and easy to audit.

The most important design decision is to separate ordinary calendar math from jurisdiction-specific legal rules. A tool can help someone count days, compare deadlines, and avoid manual arithmetic mistakes, but it should not pretend to replace local court rules or legal advice. That boundary needs to be visible in both the interface and the page copy.

For the calculator workflow, I keep a few implementation notes close to the code:

Normalize all input dates before doing any counting.
Show the start date and end date in the result, not only the final number.
Make weekend and holiday assumptions explicit.
Keep a plain-language explanation beside the result so users can catch obvious mistakes.
Avoid hidden defaults when a date rule could change the answer.

The small calculator page I am using for these checks is here:

https://courtdayscalc.com/

A useful test case is to compare a short same-week range, a range that crosses a weekend, and a range that crosses a month boundary. Those three cases catch many accidental off-by-one errors before the tool reaches real users.

For any legal-adjacent utility, clarity matters more than cleverness. The safest pattern is to make the arithmetic transparent, expose assumptions, and tell users when they need to verify a rule outside the tool.

Introduction to TypeScript. JavaScript primitive data types

Julia Shlykova — Tue, 16 Jun 2026 04:44:53 +0000

Implicit and explicit data type assignment

Now, with TypeScript we have the ability to explicitly set data type for a value like this:

//script.ts 

let str: string = "hello";
console.log(str);

However, when we assign a value, even without explicitly declaring data type, TypeScript can implicitly set data type. This technique is called inferred typing. The following code is still valid:

//script.ts 

let str = "hello"; // type is "string"
console.log(str);

TypeScript will still show an error if we try to assign a new value that is not of the previous data type.

//script.ts 

let str = "hello";
str = 1; // Type 'number' is not assignable to type 'string'.
console.log(str);

So, in what cases would we need to explicitly set data type?

if we not immediately assign a value to a variable when we declare it:

let str: string;
str = "hello";
console.log(str);

for function input and output:

function f(s: string): string {

}

inside object types (interfaces);
inside classes.

Duck inferred typing

In more complex variable types if they are not explicitely set, TypeScript uses so-called "duck typing" method:

"If it looks like a duck, and quacks like a duck, then it probably is a duck"

const obj1 = {
  id: 1,
  name: "Mary",
  greet() {
    console.log(`Hello, ${this.name}!`);
  },
};

obj1.name = "Ann"; // Ok

obj1.age = 45; // Property 'age' does not exist on type '{ id: number; name: string; greet(): void; }'

TypeScript defined implicityle the type as { id: number; name: string; greet(): void; } and doesn't allow to assign new properties.

Primitive JavaScript types

Each primitive type in JavaScript has a corresponding type in TypeScript:

number - floating-point numbers:

let a: number;

a = 123;
a = 123.0;
a = 0x7b; //hexadecimal notation
a = 0b1111011; //binary notation
a = 0.123e3; // exponential notation
a = Infinity;

bigint - used for large integers (usually higher than 2^53-1 or lower than -(2^53-1)):

let a: bigint;

a = 9007199254740992n;
a = BigInt("9007199254740992");

string - sequence of characters:

let a: string;

a = 'red';
a = "apple";
a = `${1+2} bears`;

boolean - true of false:

let a: boolean;

a = true;
a = Boolean(0); //false

symbol - special type that makes value unique:

let a: symbol;

a = Symbol('key');

Null and undefined

null - indicates value, that's empty or non-existent and we don't expect it to change.
undefined - works as a placeholder for a value of a variable, that was declared but has not yet been assigned to other value.

These two values in TypeScript have any data type. It means that we can change the value of the variable to any value.

let a = undefined; // data type is any

a = 1;

a = 'str';

If we explicitly set data type as null or undefined, the variable won't have the ability to change its value:

let a: undefined;

a = 1; // Type '1' is not assignable to type 'undefined'

Introduction to TypeScript. Special TypeScript data types

Julia Shlykova — Tue, 16 Jun 2026 04:44:36 +0000

Arrays and tuples

array - collection of items (similar to JavaScript). In TypeScript we can specify what value types we expect for items to be:

let arr: number[] = [];

arr[0] = 1;

arr[0] += "string"; // Type 'string' is not assignable to type 'number'

we can declare nested arrays like this: let arr: string[][] = [["string1"], ["string2"], []].

tuples - fixed length array that has predefined types for each position:

let tup: [number, string] = [1, "text"];

tup[0] = 2;
tup[1] = 3; //Type 'number' is not assignable to type 'string'

We also can use nested tuples:

const coords: [number, number[]][] = [
  [0, [0, 0]],
  [10, [0, 1]]
];

coords[20] = [2, []];

Literal types

literal types - constraints on types (string, number or boolean), specifying exactly which values the variable is allowed to take:

let status: 'offline' | 'online';

status = 'ofline'; // Type '"ofline"' is not assignable to type '"offline" | "online"'. Did you mean '"offline"'?

Object literal

We can also specify what properties can our object have using object literals:

const obj: {
  a: number,
  b: string,
  c?: boolean
} = {
  a: 1,
  b: 'text',
  c: true
};

obj.b = 2; //Type 'number' is not assignable to type 'string'

We used optional parameter (?:), that allows us to omit value assignment to the property.

enum type

enum (from enumeration) - a collection of named constants linked with an integer (by default enumeration starts from 0):

enum Color {
  Red,
  Green,
  Blue
}

let colorName: string = Color[1];

console.log(colorName);

enum Colors {
  Red = 2,
  Green,
  Blue
}

let colorName: string = Colors[3];

console.log(colorName); // Green

String enums

String enums allow us to create a set of constants mapped to strings:

enum Notification {
  Warning = "This is a warning",
  Success = "This is a success",
  Danger = "This is a danger"
}

console.log(Notification.Danger); // This is a danger

enum as data type of a variable

enum Status {
  Offline = 'OFFLINE',
  Online = 'ONLINE'
}

let userStatus: Status;

userStatus = Status.Offline;

console.log(userStatus); // OFFLINE

enum vs object

You may ask yourself, why would we use enum, if we can achieve the same behavior with object?

Let's look at the last example: we have userStatus type as enum, but in the end of the day it's just a string and let's try to rewrite it with object:

const Status = {
  Offline: 'OFFLINE',
  Online: 'ONLINE'
}

let userStatus: string = Status.Offline;

userStatus = "plain text"; // OK

We can assign another value to userStatus!

Actually the compiler transforms enum to javascript the object. We can even access its properties:

enum Status {
  Offline = 'OFFLINE',
  Online = 'ONLINE'
}

function getAttr(obj: {Offline: string}) {
    return obj.Offline;
}

console.log(getAttr(Status)); // OFFLINE

Actually, we can make enums disappear at the compile time using const. They won't be compiled to the object and the variables assigned to their keys will be assigned to literals:

const enum Status {
  Offline = 'OFFLINE',
  Online = 'ONLINE'
}

let i: Status = Status.Offline;

function getAttr(obj: {Offline: string}) {
    return obj.Offline;
}

console.log(getAttr(Status)); // 'const' enums can only be used in property or index access expressions or the right hand side of an import declaration or export assignment or type query.

Any, Unknown and Type Casts

any - this type tells typescript compiler to ignore the variable while type checking. It means that we can assign any value to the variable and call any method on it:

let x: any;

x =1;

x=[2,3];

x(); // compiler allows it, since it doesn't know what type of the variable it is.

any is used in a difficult situation, when we are not able to predict the type. Usually in the case of unceratainty you should use unknown type.

unknown - we don't know what the type is going to be but before performing any operations with the variable we have to check its type:

let a: unknown = 10;

if (typeof a === "number") {
  a+=2;
}

console.log(a);

Another way to work with unknown type is to use type casting:

let a: unknown = 10;

// We tell the compiler to treat the variable as its type is number:
let b = (a as number) + 2;

console.log(b);

Create condition using JooqTemplate

ts5432 — Tue, 16 Jun 2026 04:43:06 +0000

1. condition

Create a Condition from a Field, an operator, and a value.

public Condition condition(Name fieldName, String operator, Object[] values)

2. conditions

Parse varargs into List. Arguments are grouped in pairs (fieldName, value). An operator suffix can be appended to the field name.

public List<Condition> conditions(Object... condtionKvs)

example:

// Basic usage: pairs of (fieldName, value)
List<Condition> conds = jt.conditions(
    "name", "John",                 // name = 'John'
    "birthday≥", beginDate        // birthday ≥ '2020-01-01'
);

// Mixing Condition objects
List<Condition> conds = jt.conditions(
    "name", name,
    F("create_time").isNotNull(),  // passing a Condition directly
    "birthday:desc"               // OrderBy: birthday DESC (ignored for conditions)
);

// Using conditions with query
List<User> list = jt.query("user_table", User.class,
    jt.conditions("name%", name, "birthday>=", beginDate));

Operator	Meaning	Example
(none) or ==	Equal (eq / isNull)	"name", value → name = ?
%	Contains (LIKE)	"name%", "Jo" → name LIKE '%Jo%'
%L	Starts with	"name%L", "Jo" → name LIKE 'Jo%'
%R	Ends with	"name%R", "hn" → name LIKE '%hn'
>	Greater than	"birthday>", date → birthday > ?
>=	Greater than or equal	"birthday>=", date → birthday >= ?
<	Less than	"age<", 18 → age < ?
<=	Less than or equal	"age<=", 18 → age <= ?
<>	Not equal	"name<>", "admin" → name <> ?
in	IN query	"id", list (Collection/array value) → id IN (?,?,?)
notin	NOT IN query	"id:notin", list → id NOT IN (?,?,?)
isnull	IS NULL (unary, no value argument)	"name:isnull" → name IS NULL
isnotnull	IS NOT NULL (unary, no value argument)	"name:isnotnull" → name IS NOT NULL

3. Order By

In varargs, can append sort operators to field names to specify ordering. can also pass OrderField objects directly.
example:

// Mix ordering in varargs
List<User> list = jt.queryv("user_table", User.class,
    "birthday:desc",            // ORDER BY birthday DESC
    F("name").asc().nullsLast()  // ORDER BY name ASC NULLS LAST
);

// Pass order list to query()
List<User> list = jt.query("user_table", User.class, conditions,
    Arrays.asList(F("birthday").desc(), F("name").asc()));

Sort Operator	Meaning
fieldName:asc	ASC
fieldName:desc	DESC
fieldName:ascnf	ASC NULLS FIRST
fieldName:ascnl	ASC NULLS LAST
fieldName:descnf	DESC NULLS FIRST
fieldName:descnl	DESC NULLS LAST

Notes from maintaining a small game reference page

Xian X — Tue, 16 Jun 2026 04:42:23 +0000

I have been keeping notes on a small fan reference page and wanted to write down the checks that made it less fragile. The main lesson is that a reference page should not try to look bigger than the information it can verify. A short page with clear scope is more useful than a large page padded with guesses.

For game notes, I now separate three things before publishing: confirmed mechanics, change-prone observations, and open questions. Confirmed items can sit in the main table. Change-prone items need a date or version note. Open questions should stay out of the main answer until there is better evidence.

That process also makes updates faster. When a player reports a change, I can compare it against the current notes instead of rewriting the whole page. It is a small workflow, but it prevents the common wiki problem where old information stays visible because nobody remembers why it was added.

The current reference page I am using for this workflow is here:

https://growagardens2.com/

A simple checklist I use before updating a page:

Can this claim be checked from more than one source or direct play?
Does the page show the limits of what is known?
Are dates or version notes included where the information may change?
Is the answer easy to scan on mobile?
Would a new reader understand the next action without reading the whole page?

Small reference projects do not need heavy infrastructure. They need careful wording, repeatable checks, and a willingness to leave uncertain details unpublished until they are verified.

The Skills File Pattern

kavyarani7 — Tue, 16 Jun 2026 04:33:48 +0000

SectorFlow Engineering Series · Part 2 of 3 · Read Part 1 first: Token Efficiency in Claude Code

How we stopped appending to CLAUDE.md and started importing only what we need.

June 2026 · SectorFlow Engineering

In this series Part 1: Token Efficiency in Claude Code (start here). Part 3: Picking Models and Tools — the MCPs we tried, refused, and why.

The append loop

If you use Claude Code for a while you'll probably land where we did: a CLAUDE.md that got too big and too self-contradictory to trust.

It starts fine. You write down the basics — what the app does, where the server lives, what the API looks like. Then something breaks. Claude picks the wrong model string, or makes a chart without the right color, or ignores a cache rule you mentioned in passing three weeks ago. So you write the rule down and append it. Reasonable.

And it works for a while. Then the file's big, the week-two rules are sitting on top of the week-six rules, and when two of them disagree — they will, because requirements move and old notes go stale — the model either reconciles them into mush or just picks one. You spend an hour debugging output before you realize the rule you thought was active got overridden by something you wrote months ago and forgot about.

The bigger issue: the whole file loads every session, no matter what you're doing. A color fix on the frontend doesn't need the deployment runbook. An API route change doesn't need the chart color rules. Every line that isn't relevant is costing tokens and adding noise.

We thought about how to fix this without just deleting the stuff we'd need again later, and ended up with what we call the skills file pattern. Split the context into separate files by purpose, import only what the task needs.

The structure

CLAUDE.md stops being the rulebook and becomes a table of contents. The actual rules move into separate files under .claude/.

File	What it owns	When it loads
`core.md`	Absolute constraints: model strings, API key rules, cache TTLs, data contracts	Every session — the foundational constraints
`design.md`	Color tokens, chart types, component patterns, loading-state conventions	UI and frontend tasks only
`infrastructure.md`	Hosting config, environment variables, deployment rules, automator wiring	Infrastructure and CI tasks
`workflow.md`	Ticket format, commit rules, token rules, division of labor	Every coding session
`architecture.md`	ADRs, scaling thresholds, rejected technical decisions	Architecture reviews and new integrations

The import syntax in CLAUDE.md is nothing special:

@sector-dashboard/.claude/core.md
@sector-dashboard/.claude/design.md
@sector-dashboard/.claude/workflow.md
(infrastructure.md and architecture.md load only when the task references them)

So a UI task loads core + design + workflow. An infra task loads core + infrastructure + workflow. architecture.md only shows up if someone actually asks about a scaling decision or an ADR. The context stays small and stays on topic.

What goes where

core.md — the constitution

core.md is the one file that loads every single session, so everything in it has to be true and currently enforced. We treat it like a constitution. Stable, authoritative, never wishful.

Two kinds of things go in:

Facts we've verified — model IDs we've confirmed work, endpoint shapes, cache key names, exact token limits per endpoint.
Hard constraints — rules you don't break without a deliberate, written-down decision (where the API key goes, no swapping models, TTL values).

Don't put aspirations in core.md. "We should try to…" or "ideally the model would…" — that's workflow.md material. core.md is only for things that are true right now. The moment you put a hope in there, reality eventually contradicts it and now you've got a lie sitting in your most-trusted file.

design.md — the visual contract

Every hex value, every chart-type assignment, every loading-state pattern goes in design.md. Three reasons it pays off:

A new engineer, or a fresh Claude session, doesn't have to reverse-engineer the visual conventions out of the component code.
When we changed the color logic on the 52-week range bar, we edited one table in design.md. No component files had to change just to record the rule.
We can reject a PR where Claude hardcoded a hex instead of using the documented token, because the rule is written down.

design.md is also where we list what not to touch. TradingViewChart.jsx is wrapper-only. signals.js has its own color system and must not get the new --sf- variables. Those "don't" rules matter as much as the conventions do.

workflow.md — who does what

This is the file that matters most day to day. It spells out what Claude does and what the engineer does, in enough detail that there's no room to wonder. Part 1 has the full reasoning, but the short version is: if the engineer can do it in under two minutes in a terminal, it shouldn't go to Claude through an MCP.

workflow.md also holds the task format we make engineers use when they hand work to Claude:

Required field	Why it exists
`Branch: {name}`	Stops Claude asking or guessing — one less tool call
`Files to CREATE: [list]`	Scopes creation, stops new files getting added speculatively
`Files to MODIFY: [list + one-liner]`	Keeps Claude from reading unrelated files for context
`What to build: [criteria]`	The single source of truth for when it's done
`Do NOT read: [not listed]`	An explicit boundary — absence isn't permission

If any of those fields is missing, Claude asks before it touches a file. That kills the usual failure mode where it reads three or four files "to understand the codebase" before writing a single line.

architecture.md — decisions and why

Architecture decisions go in as ADRs — the decision, what led to it, what it costs us. We record the rejected ones too, and those turn out to be the more useful part.

When some future session asks "why not GraphQL?" or "should we add WebSockets for live data?", the answer is already sitting there: considered, rejected, here's why. Claude doesn't reopen it and neither do we.

The rule that keeps it from rotting

One rule keeps the split files from turning into the same contradictory mess as the old monolith:

One file owns one domain. If a rule could live in two files, it goes in the more constrained one — usually core.md. And if you can't tell which file a rule belongs in, it's probably too vague to be a rule.

In practice: color tokens go in design.md, not core.md. Cache TTLs go in core.md, not architecture.md. Division of labor is workflow.md, not core.md. Once the domains are clear the contradictions jump out — if the same thing shows up in two files, one of them is wrong.

What changed after

Startup token cost down about 60% on a typical task.
Contradictions are findable now — the same topic in two files gets flagged.
New rules have an obvious home, and figuring out the home forces you to be clear about what kind of rule it even is.
You can review the files on their own — a frontend change goes up against design.md and nothing else.

It's not a complicated setup. Six files and a manifest. The work is in holding the one-domain line: the moment a file starts feeling like it's about two things, split it.

Continue reading

Part 3: Picking Models and Tools — the MCPs we tried, refused, and why.

Why AI-Generated UIs Look 'Off' — and the One Principle That Fixes It

@kiwibreaksme — Tue, 16 Jun 2026 04:33:17 +0000

You've seen it. You ask an AI to build a dashboard, and it returns something that's… fine? Every component is individually competent. The button is a button. The card is a card. And yet the whole thing reads as generated — like a stock photo of a UI.

For a long time I assumed the fix was "better components" or "more taste in the prompt." It isn't. After digging through the actual design literature — Refactoring UI, Material Design 3, Apple's HIG, IBM Carbon, WCAG, the Financial Times' visual vocabulary — the real culprit has a name:

Incoherence.

The parts don't agree with each other. And once you can see it, you can't unsee it.

I've written before about why your vibe-coded app looks ugly and what I did about it. This post goes underneath that — the actual mechanism behind the "off" feeling, and the one principle that fixes it.

The tell: parts that don't agree

Here's a UI with nothing "wrong" in it:

A card with sharp 2px corners
Pill-shaped buttons inside it
A blue primary action next to a purple "upgrade" link
Icons: two from Lucide (outline), one filled emoji
One shadow lit from the top-left, another from straight below

Every one of those choices is defensible in isolation. Together, they signal "assembled from parts," because a human designer would never make all of them on the same screen. A designer picks one corner style, one accent, one icon set, one light source — and repeats those decisions everywhere.

That repetition is what we read as "designed by one mind." Goran Paun (UX Collective) calls it visual coherence; Steve Schoger's whole Refactoring UI is, in a sense, a book about not introducing gratuitous variation. The principle is old. What's new is that AI breaks it by default, and understanding why tells you how to fix it.

Why AI specifically struggles with this

A language model generates UI locally. It writes the card, then the button, then the modal — each as a fresh, plausible snippet. It has no running memory that "the buttons 40 lines up were pill-shaped, so these must be too." Each component regresses to the mean of its training data, and the mean of "a button" and the mean of "a card" were never coordinated.

Humans don't work this way. We carry a tiny set of decisions in our head — this product is soft-cornered, blue-accented, 8px-grid — and every new element inherits them. The decisions are sticky.

So the fix isn't "make the model more tasteful." It's: write the sticky decisions down, and tell the model to copy them instead of inventing new ones.

The meta-law: one choice per axis

Here's the whole idea in one sentence:

For each design axis, pick exactly one value or family, encode it as a token, and apply it everywhere.

Coherence is not "every screen is identical." It's that the same decisions recur. A settings page and a dashboard can look very different and still feel like one product — as long as they share a radius personality, a shadow language, an accent, and a spacing unit.

These are the axes that have to stay unified:

Axis	Pick ONE, system-wide	Failure mode when mixed
Corner / radius	sharp 0–4px · soft 8–12px · pill 9999px	sharp dialog + rounded buttons = "two products glued together"
Shadow	one scale, one light source (above-left), one tint	"a scene with two suns"
Accent color	one accent for emphasis (+ semantic red/green/amber)	nothing reads as the action
Spacing unit	one 8px grid (4px half-step)	off-grid 7/13/19px reads as "sloppy"
Icon style	one family, one fill mode, one stroke weight	mixing sets looks "out of place"
Type scale	one modular scale, ≤2 families	arbitrary sizes destroy rhythm
Motion	one duration set + one easing family	some snappy, some sluggish = different apps
Control height	shared height set (e.g. 40px)	a 44px input beside a 32px button breaks the baseline

The single best instinct I've heard a non-designer voice it as:

"If the corners are sharp, everything should be sharp."

Exactly right — and it generalizes to every row in that table. Treat a mixed axis as a lint error, not a style choice.

Let's make four of these concrete.

1. Pick one corner personality (and respect the nesting law)

First, radius is a token, never a magic number. Define a small scale and reference it everywhere:

:root {
  --radius-sm: 8px;   /* inputs, buttons   */
  --radius-md: 12px;  /* cards, menus      */
  --radius-lg: 16px;  /* modals, sheets    */
  --radius-full: 9999px;
}

Then pick one personality — all sharp, all soft, or all pill — and apply it across card / button / input / modal / image. Don't let the model freestyle a rounded-none panel with rounded-full buttons.

There's a subtle second rule most people miss: nested radii must share a center. When a rounded element sits inside a rounded container with padding, the inner radius should be smaller:

inner radius = outer radius − padding

.card {
  --pad: 16px;
  border-radius: var(--radius-lg);          /* 16px */
  padding: var(--pad);
}
.card > .thumbnail {
  /* 16 − 16 = 0; clamp so it never goes negative */
  border-radius: max(0px, calc(var(--radius-lg) - var(--pad)));
}

If you give the inner element the same radius as the outer one, its corner visibly bulges past the container's arc. Apple's new "Liquid Glass" system formalizes exactly this concentric-corner math; Cloud Four has the canonical write-up.

2. Layered shadows from a single light source

The fastest way to make depth look fake is one hard box-shadow. Real shadows are a gradient (a penumbra), so stack several low-opacity layers, and — critically — tint them toward the surface hue instead of using pure black, which goes muddy:

/* card — sits near the page */
--shadow-md:
  0 1px 2px  hsl(220 40% 20% / 0.08),
  0 2px 4px  hsl(220 40% 20% / 0.08),
  0 4px 8px  hsl(220 40% 20% / 0.08);

/* modal — floats toward the user */
--shadow-xl:
  0 2px 4px   hsl(220 40% 20% / 0.06),
  0 8px 16px  hsl(220 40% 20% / 0.06),
  0 16px 32px hsl(220 40% 20% / 0.06),
  0 32px 64px hsl(220 40% 20% / 0.06);

The coherence rule: one light direction for the whole page (convention: above and slightly left), with vertical offset roughly 2× the horizontal. As elevation rises, offset and blur go up while opacity goes down. A card and a modal then read as the same light hitting objects at different heights — not two unrelated effects. (Josh Comeau and Tobias Ahlin both have excellent deep-dives on this.)

In dark mode, shadows nearly vanish, so switch to tonal elevation — lighter surfaces for higher elevation — and never use pure #000 as your base (Material recommends #121212 with white overlays per level).

3. One accent, everything else greyscale

Most "AI rainbow" UIs come from reaching for a new hue every time something needs emphasis. The discipline:

One accent for interactive emphasis.
A full tinted-grey ramp (not pure grey — nudge it 5–15% toward the brand hue) for text, surfaces, and borders.
Only four semantic colors — success / warning / error / info — used strictly by meaning, never decoration.

:root {
  --accent: #5b5bd6;
  /* greys tinted slightly toward the accent's hue, not 0-saturation */
  --grey-50:  hsl(240 20% 98%);
  --grey-200: hsl(240 14% 90%);
  --grey-500: hsl(240 8%  55%);
  --grey-900: hsl(240 12% 14%);  /* body text — NOT #000 */
}

And one accessibility floor you don't get to negotiate (WCAG 2.2 AA): 4.5:1 contrast for body text, 3:1 for large text and UI components. Never convey information by color alone — pair it with an icon, text, or shape. A red border on an invalid field is not enough; add the icon and the message.

4. One spacing grid, with proximity doing the grouping

Snap every margin, padding, and gap to a single scale — 4, 8, 12, 16, 24, 32, 48, 64 — and let proximity carry meaning. The rule from Gestalt (and Refactoring UI's "avoid ambiguous spacing"): the space around a group must be clearly larger than the space within it.

A concrete ladder for forms:

label → input        : 4–8px
input → input         : 12–16px
group → group (section): 24–32px

When everything is evenly spaced, the eye can't tell what belongs together. The doubling at each level is what makes a label bind to its field and a section separate from the next.

Make the machine check itself

Writing the decisions down is half the battle; the other half is catching violations. This is where AI can actually help — if you give it the rubric.

I bake all of the above into an open-source design engine (StyleSeed) that Claude Code and Cursor read automatically, but the idea is tool-agnostic. The most useful piece turned out to be a coherence grader: a check that scores a file and flags mixed axes as real deductions.

A trimmed example of what that output looks like:

## Design Score: 70 / 100   (Dashboard.tsx)

Color discipline   13/18  ▓▓▓░  #000 headings; 3 accent hues
Cards & elevation   8/12  ▓▓░░  1px borders doing separation
Coherence           6/12  ▓▓░░  sharp cards (l.22) + pill buttons (l.48); 3 accents

### Fix first (highest score gain)
1. Unify radius (pick soft 8–12px) + collapse to one accent  → +9
2. Add empty + loading states to the orders list            → +7
3. Drop 1px borders, use tone + ≤8% shadow                  → +4

The "Coherence" category is the one that most predicts "looks AI-generated," precisely because it measures system-wide consistency rather than per-component prettiness. A component can be beautiful and still wrong — if it disagrees with its neighbors.

The takeaway

If you remember one thing:

Beautiful parts don't make a beautiful UI. Agreeing parts do.

Pick one value per axis — radius, shadow, accent, spacing, icons, type, motion — write it down as a token, and make every new element inherit it instead of inventing a fresh choice. That single discipline is the difference between "a robot made this" and "a designer made this," and it's the cheapest, highest-leverage thing you can do for an AI-built interface.

The corners are sharp? Then everything is sharp. All the way down.

Want the practical side? I covered the one-file fix that makes your vibe-coded app stop looking ugly in a companion post. And the full research-backed version — concrete spacing numbers, a type recipe per app type, layered-shadow and nested-radius recipes, all grounded in Refactoring UI / Material 3 / Apple HIG / WCAG — is open source (MIT): github.com/bitjaru/styleseed. A ⭐ helps more devs (and more AI tools) find it.

Token Efficiency in Claude Code

kavyarani7 — Tue, 16 Jun 2026 04:31:45 +0000

SectorFlow Engineering Series · Part 1 of 3 · Parent article

Notes on where our context budget was actually going, and what we did about it.

June 2026 · SectorFlow Engineering

In this series Part 2: The Skills File Pattern — fixing CLAUDE.md bloat with imports. Part 3: Picking Models and Tools — the MCPs we tried, refused, and why.

The problem nobody warns you about

Claude Code can do a lot. The catch is that all of it runs on context, and you don't get much of that.

When we started SectorFlow we did the obvious thing. Kept a CLAUDE.md at the repo root, and every time something went wrong — wrong model string, a cache TTL that didn't match, a chart that came out looking off — we'd write a rule and stick it on the end. The file kept growing. We didn't really clock it as a problem until it was one.

By about week six it was 400 lines. Every session loaded the whole thing. Frontend rules sitting next to deployment runbooks sitting next to database decisions, none of it sorted. And because we'd added the rules one at a time over weeks, some of them flatly disagreed with each other. Claude would follow the new one, or the old one, or try to split the difference. We got something wrong either way.

I want to be clear this isn't a Claude Code problem. It's on us, and it's fixable. But fixing it meant we had to stop treating CLAUDE.md like a junk drawer.

The thing that actually hurts isn't the per-token price. It's that every token spent loading context is a token you don't get back for the work. Burn 30,000 on setup and you've got far less room to write code than if you'd burned 5,000. You hit the ceiling partway through a file and whatever you were in the middle of is just gone.

Context is a budget

Here's the shift, and it's simple once you see it: anything Claude reads at the start of a session is something it can't use later for code. Most projects pile everything into CLAUDE.md on the theory that the model might need it someday. We flipped the question. What does the model need for this task? Load that. Skip the rest.

Two rules came out of it:

Precision over completeness. A small context that's right does more for you than a big one trying to cover all the bases.
Load on demand. Structure things so only the relevant part shows up for a given task.

Those turned into three actual practices, and each one gets its own article in this series. This one is just the overview — what we measured and why it matters.

What we actually changed

1. Session startup cost

Every session loads CLAUDE.md plus whatever it imports. Before, that was the one 400-line file, every time, regardless of the task. After we split it into separate skill files, a UI task pulls in core.md (the constraints) and design.md (the visual stuff) and nothing else. An infra task gets core.md and infrastructure.md. Startup cost dropped about 60%.

2. Reading tickets

We had the Linear MCP hooked up so Claude could read tickets itself. Nice in theory. But one list_issues call runs about 3,500 tokens, and the whole read-it / mark-done / comment loop is around 9,000. So now the engineer just pastes the acceptance criteria. That's maybe 400 tokens. The 8,600 difference doesn't sound like much until you multiply it across 60-plus tickets — that's something like 7 or 8 full context windows handed back to the actual work.

3. Reading files it was never asked to read

Left alone, Claude reads files to get its bearings, sometimes three or four of them before it writes a line. So we made a rule: only read files the task names. Need to find a function? grep for it, then view just those lines. Don't open a file to soak up "context." If something's actually missing, ask. Saves 2,000–4,000 tokens on a complex task.

4. Spinning up the dev server to check things

Verifying a change by eye means starting the server, waiting, navigating, screenshotting, evaluating — a whole chain of calls. For anything you can't see in a browser, like server logic or data contracts or route handlers, that chain tells you nothing. So we only do the visual check when the change is something a person could actually see in a browser. For syntax we run node --check. One Bash call.

The numbers

Source of overhead	Before	After	Saving
Session context load	~400 lines, every session	60–120 lines, task-specific	~60%
Ticket ingestion (per ticket)	~9,000 tokens via MCP	~400 tokens via paste	~8,600 tokens
File reads per task	3–5 files speculatively	Named files only	2,000–4,000 tokens
Verification overhead	Dev server + screenshot	`node --check` only	4–6 tool calls

Each of these on its own is fine, nothing dramatic. Put together they change what fits in a session. Stuff that used to take two or three sessions now usually fits in one. That's the whole point.

How the parts fit

The other two articles each take one piece of this:

Part 2, the skills file pattern, is about the startup cost and the contradicting-rules mess. It's where the import-on-demand structure comes from.
Part 3, models and tools, covers the ticket overhead and the file-reading habit, plus which MCPs we said no to and where we drew the line between Haiku and Sonnet.

Read this one first for the why. Then either of the others for the how.

One thing to keep in mind

Claude Code does its best work when the context is small, accurate, and honest about what's actually known versus what you're hoping for. Vague in, vague out. And a context file that tries to cover everything ends up covering nothing properly.

Continue reading

Part 2: The Skills File Pattern — fixing CLAUDE.md bloat with imports.
Part 3: Picking Models and Tools — the MCPs we tried, refused, and why.

Auditing Kubernetes Manifests With AI: A Practical Workflow

James Joyner — Tue, 16 Jun 2026 04:31:15 +0000

A senior K8s engineer I work with audits manifests faster than I read them. He's seen so many patterns that "missing readinessProbe on a Deployment that takes 45 seconds to start" jumps off the page. Most of us don't have that pattern library memorized — and increasingly, we don't need to. AI assistants have read more Kubernetes manifests than any human ever will.

The catch: a generic "review this YAML" prompt produces generic noise. You need to direct the model toward the categories of issues that actually matter in your environment.

The two mistakes everyone makes

Mistake 1: Asking for "a security review." You'll get a bullet list of every possible concern, ranked alphabetically, with no signal about which matter. You'll skim, dismiss, and learn nothing.

Mistake 2: Pasting one manifest. Real Kubernetes problems live in the interaction between resources — a Deployment's readiness probe and a Service's selector, a NetworkPolicy and the actual app traffic. One YAML in isolation hides most of the bugs.

The fix for both is the same: give the model a bounded scope and enough context to reason about interactions.

A workflow that works

Step 1: Pick the audit dimension

Pre-decide what you're checking for. Different prompts for different dimensions:

Resource limits & QoS — are requests/limits set, does QoS match intent, are limits realistic
Probes & lifecycle — readiness, liveness, startup, preStop, terminationGracePeriodSeconds
Security context — runAsNonRoot, capabilities, readOnlyRootFilesystem, seccomp
Network exposure — NetworkPolicy, Service type, Ingress rules
Reliability — PodDisruptionBudget, topology spread, replica count
State & storage — PVC access modes, retention policies, backup tags

Mixing dimensions in one review produces wishy-washy output. Pick one, get a clean answer, move on.

Step 2: Paste the manifest + related context

For a workload review, paste:

The Deployment / StatefulSet / DaemonSet
Its Service(s) and Ingress
Any NetworkPolicies that match its labels
The HPA if relevant
The ConfigMaps and Secrets it references (sanitize first)

For YAML this is usually under 500 lines, well within any model's context window. The model can now reason about interactions, not just isolated fields.

Step 3: Use a directive prompt

The big difference between "tell me about this YAML" and a useful review is the instruction format. Compare:

Review this Kubernetes manifest.

versus:

You are reviewing a production Deployment + Service + NetworkPolicy bundle. For each finding, give: (1) severity (critical/high/medium/low), (2) the exact field path that's wrong, (3) one sentence on why it matters, (4) the corrected YAML snippet. Focus only on probes, lifecycle, and graceful shutdown. Ignore documentation/comments.

The first prompt produces an essay. The second produces a list of fixable issues.

Step 4: Verify before applying

This is where most reviews go wrong. The model is right most of the time. It's wrong some of the time, often in ways that look correct.

Common AI failure modes in K8s review:

Hallucinated field names — spec.template.spec.terminationGracePeriod (it's terminationGracePeriodSeconds)
Outdated API versions — policy/v1beta1 PodDisruptionBudget (removed in 1.25)
Wrong defaults claimed — claiming failureThreshold defaults to 1 when it's 3
Misreading the use case — recommending runAsNonRoot: true for a workload that legitimately needs root

For every "fix" the model suggests, glance at the official K8s docs for that field. This adds 30 seconds per finding and catches the wrong ones. Without this step, you will apply changes that break things.

A real example

Here's a Deployment I reviewed last week:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments
spec:
  replicas: 2
  selector:
    matchLabels: { app: payments }
  template:
    metadata:
      labels: { app: payments }
    spec:
      containers:
      - name: app
        image: registry.example.com/payments:v3.1.0
        ports:
        - containerPort: 8080
        env:
        - name: DB_URL
          value: postgres://payments-db:5432/payments
        resources:
          limits:
            cpu: "2"
            memory: "2Gi"
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }
          initialDelaySeconds: 5

I asked Claude to review for probes and graceful shutdown only. The findings:

No requests, only limits → pod gets BestEffort QoS, first to be evicted under pressure. Set requests equal to or below limits.
initialDelaySeconds: 5 → Java/Spring apps typically need 30-90 seconds to start. Add startupProbe with longer threshold.
No livenessProbe → kubelet won't restart if the app deadlocks. Mirror readinessProbe with looser thresholds.
No terminationGracePeriodSeconds → defaults to 30s; for a payment service with in-flight requests, this is borderline. Set to 60s.
No preStop hook → SIGTERM hits immediately; load balancers may still send traffic for ~10s after pod marked Terminating. Add sleep 15 preStop.

All five were real, all five were fixable in two minutes of YAML editing. The model didn't tell me about anything irrelevant. That's because I scoped the prompt to "probes and graceful shutdown only."

The big one — #5 — is something I've personally been bitten by twice. The model wouldn't have prioritized it without the directive prompt.

What about Kyverno / OPA / Pod Security Admission?

Yes, you should run those too. They catch consistent issues at admission time. They don't catch issues that require judgment: "is 30 seconds enough graceful shutdown for this specific service?" Policy enforcement is a floor; AI review is a directed second opinion above that floor.

I run both. Kyverno catches "no securityContext at all" before it ever lands. AI review catches "readinessProbe path doesn't match what the app exposes" — something only a human (or an AI imitating one) would notice.

A starter prompt

If you want a template, here's the one I use most:

You are reviewing a Kubernetes workload bundle for production readiness. Focus only on: probes (readiness, liveness, startup), terminationGracePeriodSeconds, preStop hooks, and rolling update strategy. For each finding produce: severity, exact field path, why it matters in one sentence, corrected YAML. Ignore everything else (security context, network policies, resource limits — those are separate reviews). The workload is [serves HTTP at /api on port 8080 / consumes from a queue / batch processor that runs N hours].

The bracketed context at the end is what makes the review accurate for your workload. Without it, the model assumes a generic web service.

For our full prompt library on Kubernetes review, see the Kubernetes & Helm category — especially kubernetes-yaml-security-review and kubernetes-resource-limits-tuning.

This article was originally published on DevOps AI ToolKit — practical AI workflows for cloud engineers.

Using ChatGPT Custom Connectors With a Remote MCP Form Server

Lovanaut — Tue, 16 Jun 2026 04:28:27 +0000

ChatGPT can suggest form fields in seconds.

That is useful, but it still leaves a gap:

Ask ChatGPT for fields
Open a form builder
Create the form manually
Copy labels
Configure response emails
Preview
Fix issues
Publish

With a remote MCP server, ChatGPT can move one layer deeper. Instead of only describing the form, it can call tools that create and operate the form.

This post walks through a narrow version of that setup using FORMLOVA as the remote MCP form server. The goal is not to explain every FORMLOVA feature. The goal is to show the practical connection path: ChatGPT developer mode, a remote MCP URL, OAuth, a first draft form, and the safety boundaries you should keep in place.

OpenAI's current help content may call this area "developer mode", "MCP apps", "custom apps", or formerly "custom connectors". The naming can move. The underlying shape is the same: ChatGPT can connect to an external MCP server and call approved tools.

Reference:

What We Are Connecting

The server URL for FORMLOVA is:

https://formlova.com/api/mcp

It is a remote MCP server. You do not install a local package, run a process on your laptop, or paste a shared API key into a config file.

The connection flow is:

ChatGPT
  -> remote MCP server URL
  -> OAuth
  -> FORMLOVA tools
  -> draft form / preview / review / operations

OAuth matters because a form system is not a read-only documentation source. It can create forms, inspect submissions, configure emails, and eventually operate workflows. The server needs to know which FORMLOVA user is acting.

Prerequisites

You need:

Requirement	Notes
ChatGPT developer mode / MCP app access	Availability depends on plan and workspace settings.
A FORMLOVA account	The free plan is enough for the first connection test.
A browser session	OAuth redirects through the browser.
Remote MCP URL	`https://formlova.com/api/mcp`

If you are in a workspace plan, an admin may need to allow developer mode or custom apps before you can create an MCP app.

Step 1: Create The App In ChatGPT

In ChatGPT settings, look for the area related to apps, connectors, or developer mode. The labels may differ by account type, but the fields you are looking for are roughly:

Name: FORMLOVA
Description: Create and operate forms from ChatGPT
MCP server URL: https://formlova.com/api/mcp
Authentication: OAuth

Use the exact domain:

https://formlova.com/api/mcp

Do not add a random server URL you found in a thread or snippet. MCP apps can expose tools that perform write actions. Treat the server URL like an application you are granting permission to operate.

Step 2: Complete OAuth

After creating the app, ChatGPT should send you through the FORMLOVA authorization flow.

The rough flow is:

ChatGPT settings
  -> create MCP app
  -> FORMLOVA login / consent
  -> return to ChatGPT
  -> app connected

If the connection appears successful but tools do not run, check whether the app is enabled in the specific chat. Connecting an MCP app in settings and selecting it in a conversation can be two separate steps.

Step 3: Create A Draft Form

Start with a low-risk draft. Do not begin by publishing or sending emails.

Example prompt:

Use FORMLOVA to create a draft registration form for an internal engineering meetup.
Ask for name, email, team, attendance type, dietary restrictions, and one question for the speaker.
Keep it unpublished and return the preview URL.

The expected result is:

draft form created
preview URL returned
no public publish action yet

This is the right first test because it proves that ChatGPT can call the remote MCP server without immediately creating public side effects.

A Better Test Prompt

The first prompt can be short, but a realistic prompt should include the workflow after submission.

Forms are rarely just fields. They are the beginning of an operational process.

Here is a better test prompt:

Use FORMLOVA to create a draft contact form for a B2B SaaS website.

Required fields:
- name
- work email
- company
- inquiry type
- message

Optional fields:
- company size
- current tool
- expected timeline

After submission, the team wants to route pricing inquiries faster, ignore obvious sales pitches, and send a confirmation email that sets a realistic response-time expectation.

Keep the form unpublished.
Return the preview URL.
After creating it, review the form for mobile input friction, unnecessary required fields, and response-management gaps.

This prompt gives the model three kinds of information:

field requirements
operational intent
safety boundary

The safety boundary matters. "Keep it unpublished" and "return the preview URL" make the first test observable without turning it into a production action.

How To Tell If The MCP App Actually Ran

A weak test is:

Create a contact form.

ChatGPT can answer that without using any tool. It can produce a nice Markdown list of fields and still never touch the remote MCP server.

For a real test, verify the artifacts:

Check	Why it matters
Preview URL exists	Proves a draft was created outside the chat
Form is unpublished	Confirms the write action was bounded
Fields match the prompt	Confirms the tool call used the requested schema
Mobile-specific review exists	Confirms the model did more than generate labels
Follow-up operations are identified	Confirms the form is treated as intake, not a static page

I also like asking the model to summarize what it did:

Summarize the FORMLOVA actions you took.
Include the preview URL, publish status, and any review findings.

That response is not the source of truth by itself. The preview URL and the server-side draft are the evidence. But the summary helps you catch when the model is pretending to operate while only writing advice.

Step 4: Ask For A Review Before Publishing

Once the draft exists, ask for a review pass:

Review this form before publishing.
Check whether it is clear on mobile, whether any required fields are unnecessary, and whether the confirmation message sets the right expectation.

For form software, this step matters more than the initial generation. AI-generated form fields are usually plausible. The operational mistakes come later: too many required fields, weak confirmation text, unclear response handling, missing status columns, or a form that is painful on mobile.

What The Review Should Catch

A useful form review should not only say "looks good."

It should catch issues like:

The phone field is optional, but the follow-up workflow assumes phone calls.
The inquiry type is free text, which makes routing harder.
The form asks for budget too early, increasing friction.
The confirmation message says "we will reply soon" but does not set a response-time expectation.
The form is long on mobile and should split contact details from request details.
The message field is required but has no guidance about what to include.

For a contact form, the review should connect form fields to response operations:

Form decision	Operational consequence
Inquiry type as select	Enables routing and filtering
Work email required	Reduces low-quality consumer traffic
Timeline optional	Helps prioritize without blocking submission
Confirmation message	Sets expectations and reduces duplicate submissions
Sales-pitch filtering	Keeps real inquiries visible

This is where MCP-backed form software becomes more useful than a static AI answer. The same conversation can move from field creation to response workflow decisions.

Step 5: Keep Write Actions Bounded

MCP gives ChatGPT a tool surface. That is powerful, but it should not remove product safety.

I would separate early usage into these tiers:

Tier	Examples	Risk
Read	list forms, inspect draft, get preview	Low
Draft write	create unpublished form, edit labels	Medium
Publish	make a form public, change public copy	Higher
External effects	send emails, trigger reminders, export data	Highest

For the first session, stay in the first two tiers. Create a draft, preview it, edit it, review it. Publish only after the generated result has been inspected.

This is also why a form MCP server should expose domain-level operations rather than one giant "do anything" endpoint. A tool named create_draft_form is easier to reason about than a generic mutate.

Troubleshooting

If ChatGPT does not call the server, try making the target app explicit:

Use the FORMLOVA MCP app to create this draft form.

If OAuth loops, check browser blockers, workspace permissions, and whether you are logged into the expected FORMLOVA account.

If the app connects but no tools appear, check whether developer mode is enabled for your account or workspace and whether the current chat has the app selected.

If the model tries to answer with a static checklist instead of operating the tool, ask for a concrete action:

Create the draft in FORMLOVA and return the preview URL.
Do not just suggest fields.

When This Pattern Is Worth Using

This setup is not necessary for every form.

If you only need a one-off internal poll, a static prompt and a simple form builder may be enough.

The remote MCP pattern becomes more valuable when the form has operational weight:

responses need triage
emails need different wording by answer
submissions have statuses
follow-up needs timing
spam or sales pitches need filtering
forms are revised repeatedly
multiple people inspect the same intake queue

In those cases, ChatGPT is not just generating a form. It is becoming the operating surface for the workflow around the form.

That is the real reason to connect a remote MCP form server.

What This Post Is Not

This is not a tutorial on building an MCP server from scratch. It is not a full Apps SDK UI guide. It also does not cover Claude, Cursor, or Gemini CLI setup.

The narrower point is that ChatGPT can be used as an operating surface for a remote form system when developer mode and MCP apps are available.

The full FORMLOVA guide covers the longer path: setup, OAuth, preview, publishing, response management, email operations, workflows, and safety boundaries.

Read the full FORMLOVA ChatGPT guide

The Day We Fixed Our Signup Pipeline

Oge Obubu — Tue, 16 Jun 2026 04:23:48 +0000

It started with a graph.

Our signup numbers were climbing every week. The team was excited—growth was happening. But something felt off. A lot of those "users" never came back. Their email addresses looked strange. And our activation rate was quietly dropping.

One Friday afternoon, I decided to dig into the data.

What I found was not growth. It was noise.

The Diagnosis

I ran a simple query: group signups by IP address, count them, and sort descending.

The top result: one IP address had registered hundreds of accounts in the past 24 hours.

Same browser fingerprint. Same pattern. A script, probably hitting our register endpoint, generating accounts with throwaway email domains, and moving on.

I checked the user agents. Tools, not people.

I checked the email domains. Addresses that expire before the welcome email is even sent.

Our signup pipeline was wide open. Anyone, or anything, could walk in.

The Approach

We needed protection in layers. Not a single gate, but a series of filters. Each one catches something the others might miss.

We decided on three layers. And we built them all in a single sprint.

Layer 1: Throttling

The most obvious fix: rate limiting. But not just one limit, two.

Per-IP throttling: A small number of signup attempts per IP address within a short window. If you hit the limit, you get a clear response telling you when to retry.

No ambiguity.

Per-domain throttling: An even smaller tolerance for signups from the same email domain within a longer window. This catches distributed attacks, a bot using different IPs but always the same throwaway domain.

Two counters. A bot that shares either an IP or a domain gets stopped.

Layer 2: Blocklists

Rate limiting slows things down, but it doesn't stop determined attackers. They'll wait and come back. We needed permanent blocks.

Blocked email domains: We maintain a list of disposable email domains. Any registration attempt using one gets rejected before the data touches the database.

Blocked user agents: If the request comes from a non-browser tool, it's rejected with a simple error. No explanation. No details. Attackers don't need to know why they were blocked.

Layer 3: IP Blocklist

Some IPs are persistent. They've been flagged before. They've abused other endpoints, not just signup. Rate limiting won't stop them. Blocking their user agent won't stop them if they switch.

We needed a hard blocklist, IPs that are rejected for every request, not just registration.

The message is deliberately terse. No explanation. No recourse. The middleware runs on every route, every method, every request. If your IP is on the list, you don't get through.

Before and After

Before:

Hundreds of accounts from a single IP in 24 hours
Throwaway email domains made up a significant percentage of new signups
Activation rate was diluted by fake accounts
Every data-driven decision was slightly wrong because the denominator was inflated

After:

Same-IP registration farming dropped to zero
Disposable domain signups disappeared
Our signup numbers reflected actual human intent
Activation rate recovered, because the denominator now represented real users

What We Learned

1. Signal matters more than volume.

When signups are inflated by bots, every metric that depends on user count becomes unreliable. Activation rate. Retention. Revenue per user. Cleaning the pipeline made every downstream number trustworthy again.

2. A small amount of code can fix a big problem.

The solution wasn't complex. It was layered. Three simple mechanisms, each handling what the others miss.

3. Layers matter.

A single rate limit would have slowed the bots but not stopped them. A single blocklist would have caught the obvious ones but missed the persistent ones. The combination covers more surface area than any one approach.

4. Not all rejections are equal.

We chose our responses carefully. Legitimate users get useful feedback. Bad actors get silence. The message you send reveals how much information you want the requester to have.

The Takeaway

A healthy signup pipeline doesn't make the news. Nobody sends a tweet saying "I tried to sign up and couldn't because the IP throttling worked correctly."

But the absence of this work would eventually make headlines, just not the kind you want.

Growth is not just about getting users in the door. It's about making sure the users who come through are real. Every decision you make, product direction, marketing spend, feature priorities, depends on the quality of your data. And your data quality starts at the first line of defense: the registration endpoint.

The bots stopped. The data cleaned up. And our growth metrics finally told the truth.