DEV Community: codeQualityMonkey

Are You Ready to Become the Rubber Duck?

codeQualityMonkey — Fri, 13 Feb 2026 10:53:18 +0000

Last summer I spent two weeks vibe-coding an app with Lovable. The result looked great in the demo. Under the hood, everything lived in a handful of bloated files, state scattered like confetti across components that probably shouldn't have existed. I closed the tab and went back to writing code the old way.

That was the wrong lesson.

The dismissal

I think most developers went through some version of this. You try the shiny AI tool, it produces something that kind of works, the code makes you wince, and you walk away convinced that AI-assisted development is a toy. I did. I used Cursor for a while after that, but only for the safe stuff — utility functions, test scaffolding, things I could verify at a glance. I didn't trust it with anything that mattered.

Then I started using Claude Code with custom skills — feeding it my architectural patterns, my naming conventions, the way I structure projects. And something shifted. The output stopped feeling like a stranger's code. It felt like mine, written by a junior developer who'd actually read the docs.

The flip

Here's the thing nobody tells you about rubber duck debugging. The duck doesn't need to understand your code. You do. The act of explaining makes complexity visible — you hear yourself say something illogical and catch it before the words finish leaving your mouth.

We've spent the last two years treating AI as our rubber duck. We explain what we want, the model generates something, and we learn from the sparring. Better model, better result.

That relationship is flipping.

The models are getting good enough that they don't need us to explain the problem — they need us to answer the questions they can't figure out alone. Where should this service live? Should we prioritize consistency or flexibility here? Is this abstraction earning its complexity? These aren't questions a non-developer can answer. They require years of watching systems grow, rot, and collapse under their own weight.

The smarter you are, the better the AI performs. You've become the rubber duck.

The vibe-coding lesson

There's a popular narrative that AI doesn't care about code quality. That architecture is a human vanity. That you can just vibe your way to a working product and let the machine figure out the details.

Wrong.

LLMs suffer under bad code quality exactly like humans do. Point an agent at a messy codebase and watch it fix one bug while introducing three new ones. The same tangled dependencies that confuse a junior developer confuse the model. It hallucinates connections between modules that shouldn't know about each other. It duplicates logic because it can't find the existing implementation buried in a 2000-line file.

Clean code isn't about aesthetics anymore — it's about making your AI collaborators effective. Good naming, clear boundaries, small modules. The things we always said mattered but sometimes let slide when we were the only ones reading the code. Now there's a team of tireless agents navigating your codebase around the clock, and every shortcut you took becomes their stumbling block.

From production to direction

We spent years grinding the skills that are now being commoditized. Syntax mastery. Writing components. Debugging line-by-line. The raw speed of cranking out code. These were the things that made you a "fast" developer, and fast developers got promoted.

That ladder is dissolving.

What compounds now is everything we used to call "soft" skills — the tech lead skills. Knowing what good looks like. System thinking. Asking the right questions. Deciding what to build, not just how to build it. The irony is that these skills were always more valuable. We just couldn't prove it because the bottleneck was production speed. Remove the bottleneck, and suddenly the person who can steer a system matters more than the person who can type one out.

If you're a developer who spent ten years building intuition about what makes software resilient, what makes abstractions worth their cost, what makes teams ship without tripping over each other — those years weren't wasted. They were preparation for a role that didn't fully exist until now.

The fear underneath

I hear the same thing from developers everywhere. "We spent years building skills that are no longer relevant." It's not usually said that bluntly. It shows up as skepticism toward the tools, as insistence that "real" developers don't need AI, as a quiet refusal to engage.

I get it. The fear isn't irrational. But it's pointed at the wrong thing.

Your skills aren't obsolete. They're applied differently. The developer who understood why a certain pattern fails at scale still understands that — and now has agents that can implement the alternative in minutes instead of days. The developer who could spot a leaky abstraction from a code review still spots it — and now the fix ships the same afternoon.

What actually holds people back isn't a lack of technical skill. It's the fear of stepping away from what's comfortable. The fear of admitting that the thing you were great at — raw code production — is no longer the differentiator.

The new differentiator

Smarter human, better result. That's the equation now.

Not "faster typist, better result." Not "more Stack Overflow answers memorized, better result." The developer who reads widely, thinks in systems, and can articulate why a decision matters — that developer gets more out of AI than someone who can write a React component from memory.

So the question isn't whether AI will replace developers. It's whether you're ready to be the person the AI turns to when it gets stuck. Whether you're ready to sit on the other side of the desk, answer the hard questions, and steer a system you didn't write every line of.

Are you ready to become the rubber duck?

The Art of Decorating: Making Utility Functions Work for You in TypeScript

codeQualityMonkey — Tue, 11 Mar 2025 10:09:52 +0000

Intro

In the React world, where object-oriented programming isn’t as prominent, and where methods that manipulate object state are less common, finding existing utility functions can sometimes feel like a treasure hunt.

Even when I try to be consistent with naming conventions, I often find myself lost in a sea of calculateTotalAmount, getTotalAmount, and calculateTotal. Multiply this problem by several developers—and frequent team rotations—and you get an exponentially growing mess.

But don’t get me wrong, I love a well-curated set of utility functions. Solving a problem means breaking it down into smaller problems, and those smaller problems often lead to reusable utilities. The goal? A solid arsenal of helper functions that make our codebase clean and efficient.

The Initial Solution: Decorating Objects

The Decorator Pattern initially seemed like a great way to attach utility functions directly to JavaScript objects. In the app I was developing, domain objects were key players, and since they were usually served from the backend, decorating them in transformResponse when using RTK-query seemed like a natural choice.

To avoid issues with serialization, you can use defineProperties and set the property enumerable to false:

const calculateSum = (obj: SomeObject) => {
  // ... do something ...
  return sum;
};

const createDecorator = (obj: SomeObject) => {
  const instance = { ...obj };

  Object.defineProperties(instance, {
    [calculateSum.name]: {
      value: () => calculateSum(instance),
      enumerable: false, // This makes the property non-enumerable
    },
  });

  return instance as InsuranceObjectDecorated;
};

const decoratedObj = createDecorator(someObject);

The Drawbacks

While this approach gives us quick access to utilities, it comes with some major drawbacks:

Redundancy – You need to decorate the object on every endpoint that fetches it.
Type Confusion – A decorated version introduces a new type, creating inconsistencies within the repo.
Autocomplete Woes – TypeScript’s structural typing means that the decorated version is valid as the non-decorated version, but you lose autocomplete benefits.
Cascading Updates – Updating types results in a ripple effect of changes throughout the codebase.

A Better Approach: Functional Decoration

I love having utility functions at my fingertips, but the drawbacks above were deal-breakers. So I took a step back and rethought the approach.

Key Principles:

No adding methods to objects.
No sneaky prototype hacks.
No changing method return or parameter types.
Works with both primitives and objects.

Instead of modifying objects, we wrap them in a utility layer only when needed:

function decorate(object: TypeA): DecoratedTypeA;
function decorate(object: TypeB): DecoratedTypeB;
function decorate(object: unknown) {
  if (isTypeA(object)) {
    return {
      calculate: () => calculate(object),
      sumUp: () => sumUp(object),
      format: (locale: string) => format(object, locale),
    };
  }

  if (isTypeB(object)) {
    return {
      subtract: () => subtract(object),
      close: () => close(object),
      findUser: (userId: string) => findUser(object),
    };
  }

  throw new Error("Cannot decorate object");
}

Function overloading

Notice the stacked function signatures at the beginning. This is TypeScript’s function overloading feature. Compare it to:

function decorate(object: TypeA | TypeB): DecoratedTypeA | DecoratedTypeB;

With the latter, your IDE won’t know whether it’s dealing with DecoratedTypeA or DecoratedTypeB, killing autocomplete. Function overloading ensures that TypeScript correctly infers the type based on the input.

How to Use It

Now, whenever you want to see what utility functions are available for a type, just wrap your object or primitive in the decorate function to enjoy all your wired-up utils being listed out by your autocomplete:

const result = decorate(yourObjectOrPrimitive).<insert you autocomplete here>

Adding utils

Wiring up new utils to existing types or even adding a new type is a breeze! Just follow the steps below as needed


// Create a new Decorated type if you are adding a completely new type to the decorator
type TheNewTypeDecoratedType = {
    // Add your new utils to the decorated type
    newUtil: () => string
    ...existing util function types...
}

// Create a new typeguard if needed
function isTheNewType(val: unknown): val is TheNewType { ... }

// Add the new function signature with the type and its corresponding decorated type
function decorate(object: TheNewType): TheNewTypeDecoratedType;
function decorate(...): ...;
function decorate(object: unknown) {

  // Add a new conditional if it is a new type being added to the decorator
  if (isTheNewType(object)) {
    return {
      // Wire up your utils!
      newUtil: () => theUtilYouWantToAdd(object),
      ...existing utils...
    };
  }

  ...already added types...

  throw new Error("Cannot decorate object");
}

Enhancing TypeScript with Template Literal Types

One weakness of TypeScript is its structural typing, meaning two types that look the same are considered the same. Consider this:

type ObjectId = string;
type UserId = string;

function getSomething(id: ObjectId, id2: UserId);

TypeScript won’t complain if you pass a UserId where an ObjectId is expected because both are just string under the hood.

This is problematic on two levels. Nobody stops you if you accidentally pass UserId as the first param, and ObjectId as the second, and there is no way for you to write a type guard that can separate the two. I guess you can already see how this messes with my beloved decorator solution above! You want to get all the utils that deal with ObjectId, but instead, you would only get string functions...

but wait, there is hope! Let me introduce you to ...

Template Literal Types

By leveraging Template Literal Types, we can create distinct, string-based types:

type ObjectId = `objectId-${number}`;

Now, we can create type guards for runtime validation:

function isObjectId(value: unknown): value is ObjectId {
  return typeof value === "string" && /^objectId-\d+$/.test(value);
}

Combining with Decorate

With this, we can extend our decorate pattern to work on primitives and their intended type:

decorate(objectId).getObjectWorth();

function decorate(object: ObjectId): DecoratedObjectId;
function decorate(object: unknown) {
  if (isObjectId(object)) {
    return {
      getObjectWorth: () => getObjectWorth(object),
    };
  }

  throw new Error("Cannot decorate object");
}

Conclusion

By rethinking our approach to utility functions, we: ✅ Avoid modifying objects. ✅ Maintain strong TypeScript inference. ✅ Keep our utility functions accessible without messy type changes. ✅ Enhance runtime type safety with Template Literal Types.

The decorate function provides a clean and scalable way to attach utilities to objects without sacrificing readability, maintainability, or TypeScript’s powerful type inference.

So, the next time you’re tempted to inject utility methods directly into objects—stop. Try a functional approach instead, and keep your codebase clean and predictable.