You Didn't Build a System. You Wrote a Script.

Somewhere in the last two years, everything became a system.

A Python script that calls the OpenAI API and writes to a database? System. A Zapier automation that pings Slack when a form gets submitted? Integration. Two prompts chained together? Agent architecture. A dashboard with three widgets? Platform.

If you've been reading tech LinkedIn or tech Twitter recently, you've felt this. The vocabulary has inflated. And if we're being honest, I've done it too. Somewhere in a bio, a repo README, or a hackathon submission last year, I called something a "system" that wasn't. On inspection, a script with delusions of grandeur.

The AI era gave everyone new vocabulary. What it didn't give everyone is the actual thing the vocabulary describes. And the gap between the words we use and the things we've built is turning tech writing into a costume party.

How we got here

Two forces pointing the same direction.

First, LLMs write like corporate blog posts. Large language models are trained on the internet's dominant register, which was already inflated. When someone opens ChatGPT and asks it to "help me write a post about my project," the model reaches for the vocabulary it saw most in its training data: system, integration, pipeline, orchestration, seamless, robust, production-ready. The model doesn't know your project is a 60-line script. It just knows this is how tech writing sounds. So it makes your script sound like AWS.

Second, the AI wave itself created a whole category of things that genuinely are systems. Real agent frameworks. Real model routing infrastructure. Real retrieval pipelines with real error modes. That vocabulary is legitimate when applied to those things. But it's bled sideways into projects that are nothing like them because when a "real" AI agent is one thing and a script with an LLM call is another, calling both agents makes the second one feel current.

The net effect: we're all writing above our own actual complexity level. And most readers can't tell, which is exactly why it works, and exactly why we should stop.

The catalog

Five of the biggest offenders. For each: what it's become, what it actually was, and what a more honest sentence looks like.

1. "System"

Inflated: "I built a system for tracking user behaviour on our platform." Actual: "I wired up PostHog and added event calls in the frontend."

A system has components. Architecture. Tradeoffs between parts. If your "system" is one script or one integration and one place data ends up, it's not a system. It's a hookup. Call it that.

1. "Integration"

Inflated: "I integrated Stripe with our platform for seamless payments." Actual: "I imported the Stripe SDK and wired up a checkout page."

Integration used to mean two systems learning to talk to each other in a durable, maintained way with error handling, retries, monitoring, and someone who owns the seam. Calling an SDK import an "integration" flattens what the word used to carry. The honest version is often just: I used their SDK.

1. "Agent"

Inflated: "I built an agent that summarises meeting notes." Actual: "I wrote a function that sends the transcript to Claude and returns the summary."

The word "agent" now implies autonomy, planning, tool use, and decision-making across multiple steps. A one-shot LLM call in a for-loop isn't an agent. It's a function that happens to call an LLM. There's nothing wrong with that; it's often exactly the right level of complexity for the job. But calling it an agent oversells the thing and underprices what a real agent is.

1. "Pipeline"

Inflated: "I built a data pipeline that ingests customer signals across sources." Actual: "I wrote a script that pulls from three APIs into a Google Sheet on cron."

A pipeline has stages, transformations, error boundaries, retries, backpressure handling, and observability. Sequential API calls into a spreadsheet are not that. It's a fetch job.

1. "Production-ready"

Inflated: "The system is production-ready and enterprise-grade." Actual: "It runs on my machine and hasn't crashed in the last hour."

Production-ready means specific things: error handling, structured logging, observability, tested under load, deployable, secure, and someone on-call when it breaks. Enterprise-grade means those things plus SLAs, compliance, and multi-tenant safety. If your thing has none of that, it isn't either. It's a working prototype which, again, is a fine thing to have.

Why this matters (beyond aesthetics)

Two reasons that go past "it's annoying."

One: the informed reader can tell instantly. Every senior engineer, every experienced DevRel person, every technical founder who reads your inflated post is doing the same mental subtraction, reading through the vocabulary to figure out what you actually built. When they get to the bottom and realise it was a script, the vocabulary has cost you their trust. You lost credibility with the exact readers you most wanted to reach. The words that were supposed to make you sound smart made you sound the opposite.

Two: AI assistants can't extract specific claims from vague writing. In a previous post, I wrote about William Imoh's framing of AEO — how content now has to be citable by AI assistants (ChatGPT, Perplexity, Claude), not just rankable on Google. Inflated writing fails at exactly this. When Perplexity is generating an answer to "how do I connect Stripe to my Next.js app," it needs to pull a specific instruction, a real example, a named library, a working pattern. A blog post that says "we integrated Stripe seamlessly into our production-grade platform" gets skipped. A blog post that says "we added @stripe/stripe-js in the client and set up a /api/checkout handler with the secret key in an env var" gets quoted.

Specificity is the new SEO. Vocabulary inflation is the opposite of specificity. That's the DevRel cost.

How to write like you actually built it

A few working principles I've been trying to hold myself to. Not rules. Habits.

Use the smallest accurate word. Script if it's a script. Function if it's a function. SDK call if that's what it is. Reach for bigger words only when the smaller ones stop being accurate.

Prefer verbs over nouns. "I connected X to Y" lands harder than "I built an integration between X and Y." Verbs describe action. Nouns describe abstractions. Action is what actually happened.

Name the specific pieces. "An LLM call using Claude Sonnet 4.5 with a system prompt and a tool definition" beats "an AI-powered agent workflow" every time, and it's shorter.

Show, don't classify. Instead of describing what category your project belongs to ("a scalable, production-ready AI observability platform"), describe what it does in a single specific sentence a reader could verify. If a reader couldn't verify it, don't claim it.

Cut the two most dangerous adjectives: robust and seamless. Both mean nothing. Both signal that you're describing rather than building. If your work is robust, the description of what it handles will make it obvious. You don't need the word.

Re-read your draft as a skeptical senior engineer. For every claim, ask: if I said this at a whiteboard, could I defend it? If not, cut it or downgrade it. Most inflated writing dies the moment it's read out loud.

The meta point

DevRel is, at its core, an act of translation, taking something real and complex and rendering it so the reader actually gets it. Every word that inflates instead of clarifies is a step against the job.

In an era where anyone can generate confident-sounding tech writing in three seconds, precision is the differentiator. Not vocabulary. Not tone. Not tables. Precision.

The best technical writers I read now are moving in the opposite direction from the AI-inflated norm. Shorter words. More specific verbs. Fewer adjectives. A quiet confidence that comes from actually knowing what they built.

So, that project on your GitHub? Read the README. If the first paragraph reads as it came out of a corporate deck, it probably did. Rewrite it as if you were telling a senior engineer at a bar what you actually built. That version is the one people will trust. That version is the one AI assistants will cite. And that version is, funnily enough, the one that will make you sound smarter, because it will make you sound like someone who actually built the thing.

This is the third piece in a series on honest technical writing. The first covered what DevRel actually is; the second, the Comparison Test for honest "X vs Y" content. Common thread: specificity beats performance, every time. 🥑