Why Knowing the Name of Things Makes You a Better Engineer (Especially with AI)

AISoftware EngineeringCareerArchitectureFrontend

There's a class of engineer I've worked with who always seems to get better output from AI than everyone else. Same tools, same models, same codebase. Their prompts just land better. The AI does more of what they actually wanted.

For a while I thought it was prompt engineering. Some magic formula for how to structure instructions. It's not that. It's simpler: they know the names of things.

Software engineering vocabulary is now one of the most valuable skills you can build. And the good news is you don't have to be an expert to benefit from it. You just have to collect terms.

The Gap That Collapsed

Before AI coding tools, knowing about something wasn't worth that much. If you'd read a blog post about the strangler fig pattern but never applied it, that knowledge was mostly decorative. You still had to figure out the actual migration plan, write the actual code, handle the actual edge cases.

The gap between knowing-about and knowing-how was large, and only knowing-how paid off.

That gap has collapsed.

Today, if you know a pattern exists and can roughly name it, you can get full working code in seconds. The name is the lever. The agent knows the implementation.

You don't need to know how to implement a virtual list. You need to know it exists, that it applies when "rendering 10,000 rows feels slow," and what to call it when you talk to Claude or Codex. The model has read every implementation on the internet. It just needs you to point it in the right direction.

This changes what's actually worth learning. Deep expertise is still valuable (I'd argue more valuable now, not less). But a whole new category has opened up: wide, shallow, named awareness. Collecting terms you don't fully understand yet, so you can unlock them when you need them.

Engineer A vs Engineer B

Let me make this concrete. Two engineers are building a UI. Same brief, same tools.

Engineer A tells their agent: "Make a sidebar that can hide, a bar at the top, some card things, and popups in the corner."

Engineer B tells their agent: "I want a collapsible sidebar with a persistent top nav, CSS-driven card flip transitions on hover, and a toast notification stack in the bottom right using a portal so it renders outside the main layout."

The difference in output quality isn't small. Engineer B is going to get something close to what they want on the first pass. Engineer A is going to spend three rounds of corrections trying to explain what they actually meant.

And here's the thing: Engineer B doesn't necessarily know how portals work at a deep level. They've seen the term. They have a rough idea it's "the pattern where you render something outside the normal DOM tree." That's enough. The model fills in the rest.

The gap between these two engineers isn't implementation skill. It's awareness.

Architecture Patterns

The same principle applies when you zoom out from UI to system design.

If you know terms like strangler fig, CQRS, saga pattern, event sourcing, or BFF (Backend For Frontend), you can give your agent precise architectural direction. You don't need to have implemented any of them. You need to know roughly when they apply and what they're called.

"Migrate this legacy module using the strangler fig pattern" is a specific, actionable instruction. The agent will generate a proxy that intercepts requests, a migration path that keeps the old system running while the new one is built out, the incremental cutover. Correct by default.

"Migrate this legacy module carefully" is an invitation to guess.

I encountered this firsthand when we needed to decouple a read-heavy reporting module from the core transaction service at work. Knowing that CQRS existed (and roughly what it was for) let me describe the approach in one sentence. The agent scaffolded the entire read model. Without that term I'd have spent twenty minutes describing "a separate path for reads that doesn't touch the write side" and probably gotten something less precise.

Saga pattern is another one worth having in your vocabulary even if you've never built a distributed transaction in your life. "Use the saga pattern with compensating transactions" vs. "make sure if one step fails we undo the earlier steps" will get you very different starting points.

Refactoring Names Are Especially Useful

Martin Fowler's Refactoring catalogs dozens of named techniques. Most engineers who've read it remember the concepts vaguely. In the AI era, even a vague memory pays off.

Some of the most useful ones I reach for regularly:

  • Extract Method: Pull this block of logic into its own function
  • Guard Clauses: Flip the conditionals so the happy path is unindented
  • Introduce Parameter Object: These eight arguments should be a single config object
  • Replace Conditional with Polymorphism: The switch statement that routes behavior by type

These names turn vague code smells into unambiguous instructions. "Apply guard clauses to this function" gets you exactly what you want. "Make this less nested" might get you a valid refactor that doesn't solve the actual readability problem.

Here's an example. You have a function like this:

function processOrder(order, userId, isAdmin, isBeta, retryCount, timeout, dryRun, notifyEmail) {
  // ...
}

If you say "this function takes eight parameters and it's getting hard to read," the agent might extract some into constants, or group them in an ad hoc way. If you say "apply the Parameter Object pattern to group the configuration arguments," you get:

function processOrder(order, options) {
  const { userId, isAdmin, isBeta, retryCount, timeout, dryRun, notifyEmail } = options;
  // ...
}

Clear, predictable, easy to extend. The name told the agent exactly what you wanted.

UI Patterns and Component Galleries

This works at the component level too. The Component Gallery catalogs 60+ UI components with their names, alternative names, and examples across design systems. Every engineer working with AI tools should bookmark it.

Knowing that a "combobox" is different from a "select" (it's searchable and filterable), or that "breadcrumbs" has a specific accessibility behavior, or that a "skeleton screen" is the right name for those loading placeholders, lets you ask precisely for what you want.

Without that vocabulary, you end up describing the shape of something you're trying to name: "you know, the dropdown where you can also type to filter." The agent will probably get there eventually. But "add a combobox to the search field" is one instruction.

The Skim-Don't-Study Habit

The habit I'd recommend for building this kind of vocabulary breadth isn't reading deeply. It's skimming broadly.

Read the introductions of technical books, not the implementation chapters. Martin Fowler's Refactoring, Gregor Hohpe's Enterprise Integration Patterns, Alex Xu's System Design Interview. Read the first 30 to 50 pages of each. You'll pick up 80% of the vocabulary with maybe 20% of the time investment.

The goal is exposure, not mastery. A word you've seen once is worth more than a word you've never encountered. When you actually need it, you'll know enough to ask the right question.

A few things I do alongside this:

  • When I come across code in a PR that does something clever, I ask what the pattern is called. Sometimes I ask my agent directly. The name goes in a personal note.
  • Before starting a new problem type, I spend 20 minutes reading about the solution space. About to add a real-time feature? Read about WebSockets, Server-Sent Events, long polling, and CRDTs. I won't implement any of them from memory. But I'll know which one fits and why.
  • I treat vocabulary as a collection, not a curriculum. I'm not trying to understand everything I've heard of. I'm building a list of concepts I can point to when the need arises.

Vocabulary Compounds

Here's why this matters as a long-term strategy: vocabulary doesn't expire.

"Strangler fig" will be valid architectural advice in ten years. "Guard clauses" will still be a refactoring technique when React is deprecated. "TCP vs UDP" will matter when whatever replaces HTTP/3 is designed. These names refer to underlying patterns that don't change when frameworks change.

The engineer with 200 named patterns in their head will consistently get better AI output than the one with 20, even if their underlying coding ability is identical. Every named concept you add to your vocabulary expands the precision of every prompt you'll ever write about that domain.

That precision gap shows up everywhere: in prompts, in architecture discussions, in code reviews where you can point to a named concept instead of describing symptoms. It's the difference between "this violates the Single Responsibility Principle, extract the validation logic" and "this function does too much, clean it up a bit."

I'm exploring this idea (and a lot more like it) in my book How to Be a Great Software Engineer in the Age of AI, which covers how the skills that made great engineers great are shifting, not disappearing.

Where to Start

If you want to build your vocabulary quickly, here's what I'd actually do:

  • Bookmark the Component Gallery and spend 30 minutes browsing the component names
  • Skim the pattern list in Martin Fowler's catalog of refactoring techniques, you don't need to read the explanations, just scan the names
  • When you encounter a new term in a PR or tech post, ask your agent to explain it in two sentences and add it to a note
  • Before your next architecture decision, spend 20 minutes reading Fowler's pattern catalog, even just the names and one-line descriptions

You're not studying. You're building an index. The agent has all the implementations. You just need to be able to say what you're looking for.

Recommended Resources