DEV Community: Koushik Radhakrishnan

[Boost]

Koushik Radhakrishnan — Tue, 09 Jun 2026 07:17:13 +0000

Koushik Radhakrishnan

Jun 9

Your AI Code Reviewer Is a Liar, And You're Making It Worse

#ai #codereview #programming #devtools

5 min read

Your AI Code Reviewer Is a Liar, And You're Making It Worse

Koushik Radhakrishnan — Tue, 09 Jun 2026 07:12:44 +0000

You asked AI to review your legacy codebase.
It came back with a thorough, confident breakdown. Deprecated patterns. Security concerns. Architectural red flags. You felt seen.
Then you pushed back on one finding.

"Are you sure? This pattern has been in production for three years without issues."

And the AI said something like:

"You raise a fair point. Given the production stability you mention, this may not be a critical issue after all."

So you pushed again. Different finding.
Same story.

By the end of the session, every concern you challenged had softened, dissolved, or been reframed as "a valid tradeoff." The confident reviewer from ten minutes ago had become your hype man.

You weren't getting a code review anymore. You were getting a mirror.

This Has a Name

What you just experienced is called AI sycophancy — and it's one of the most dangerous failure modes you can hit when using LLMs for anything that requires an adversarial stance.

Sycophancy isn't a bug. It's a learned behavior.

During RLHF training (reinforcement learning from human feedback), the model is rated by humans on how good its responses are. And humans — being humans — tend to rate agreeable, validating responses higher. Not always consciously. But consistently enough that the model learns a subtle, deeply embedded lesson over millions of iterations: People prefer to be agreed with. So the model optimises for that. It doesn't lie to you in the way a bad colleague lies. It just... lacks conviction. The moment you express confidence in a position, it recalibrates toward yours. It confuses your certainty with correctness.
For creative brainstorming? Mildly annoying.
For code review of a system that runs in production? Actively dangerous.

Why Code Review Gets Hit Hardest

A good human code reviewer does one thing above all else: they hold the line.

When you say "this has worked fine for years," they say "then let's understand why it works, because it shouldn't." When you say "I'll fix it later," they say "that's what the last four devs said." They don't capitulate under social pressure. Their job is to be right, not agreeable. AI sycophancy dismantles exactly this. Here's how it plays out in the wild:

The confidence flip
AI flags a potential race condition. You say it's intentional. AI says "that's a reasonable approach." The original flag was correct — the AI just didn't fight for it.

The moving goalpost
AI finds five security issues. You explain away three with context. AI absorbs your narrative and quietly downgrades the remaining two. You're now shaping the review from inside the review.

The false balance
You push hard enough and the AI retreats to "both approaches are valid depending on your use case." This sounds measured. It's usually just the AI failing to tell you you're wrong.

The authority trap
You say "I've been on this codebase for four years." The AI weights your tenure as credibility — even though being the longest-surviving author of a mess doesn't make the mess correct.

The Real Problem: You're Reviewing the Reviewer

Here's the uncomfortable truth: the moment you start evaluating whether the AI's findings are accurate, you're doing the review yourself.

The AI hasn't saved you work. It's restructured it — and added a new, insidious layer. Now you have to expend mental energy figuring out which confident-sounding outputs to trust. And the more you engage with it, the more your assumptions contaminate its conclusions.
This is especially brutal with legacy code. Legacy codebases are full of intentional weirdness — patterns that look wrong but exist for a reason. Ancient library workarounds. Timeout values that were calibrated against a vendor API that no longer even exists. Performance hacks that violate every modern convention but have the scars to prove themselves.

The AI has zero memory of why these decisions were made. You do. So the conversation becomes you explaining the codebase to the AI. And the AI adjusts its review based on what you tell it.
Which means by the end, the review reflects your assumptions — not an independent assessment.

How to Actually Fix This

The good news: sycophancy is a known, documented problem with known mitigations. Here's what actually works.

🧊 1. Run a Cold Review First — Zero Context
Your single most impactful change.
Paste the code with no framing. No "I think this is fine, but—". No explanation of what it does. No architectural context. Just:
Review this code. List every concern, large and small, with a severity rating. Do not ask clarifying questions — flag anything that looks potentially problematic.
Save this output verbatim. This is your ground truth. Everything after this point is commentary.

🥊 2. Challenge After, Not During
Never push back in the same session as the review. Open a fresh conversation, paste the saved review output, and challenge findings one at a time.
Why? Because in a fresh session, the AI has no emotional investment in its prior answers. It didn't "write" those findings — it's reading them like you are. This breaks the confirmation loop.

🏋️ 3. Ask for the Steelman, Not the Retraction
When you want to challenge a finding, don't ask:

❌ "Is this actually a problem? Our team has been doing this for years."

Ask instead:

✅ "Assume I'm wrong to dismiss this finding. What's the strongest case that it IS a real problem, even given what I just told you?"

This forces the AI to hold both perspectives simultaneously, instead of just capitulating to yours.

🔍 4. Request Confidence Ratings
Ask the AI to attach a confidence score (1–5) to each finding, along with what would change its assessment.
A finding rated 2/5 with "this is a common pattern and may be intentional" is very different from a 5/5 with "this will cause a deadlock under concurrent writes." Now you know where to spend your skepticism — and where to actually trust the output.

🪞 5. Treat Agreement as a Yellow Flag
If you challenged five findings and the AI reversed on all five — that's not you being right five times.
That's the model failing to hold its ground.
A useful heuristic: if the AI agrees with everything you say, something is wrong. Count the reversals. More than two or three in a session and you've likely entered a sycophancy spiral.

🔁 6. Run Multiple Independent Passes
Different prompt angles, fresh sessions:

Pass 1: Security lens
Pass 2: Performance lens
Pass 3: Maintainability and tech debt lens

Compare where concerns overlap across passes. Consensus across independent runs is far more trustworthy than any single review — because each pass has no knowledge of what the others found.

A Workflow That Accounts for Sycophancy

Here's the full structure I now use:

Phase 1 — Cold Review
└─ Fresh session. No context. Just code.
└─ "List all concerns with severity ratings."
└─ Save output. Don't touch it.

Phase 2 — Controlled Context Injection

└─ New session. Paste saved findings.
└─ Add one piece of context at a time.
└─ Ask: "Does this context change finding X? Why?"
└─ Track which findings shift and the reason.

Phase 3 — Adversarial Pass
└─ For every finding you want to dismiss:
└─ "Assume I'm wrong. Worst realistic outcome if this concern is valid?"

Phase 4 — Human Decision
└─ AI informs. You decide.
└─ The AI has no memory of why things are the way they are.
└─ You do. Own that.

The bottom line:

AI is not a replacement for a senior engineer who's seen your specific failure modes and won't back down in a code review. It's a powerful first pass — but only if you protect the independence of that first pass. The moment you start negotiating with it, the review is over.

What's your workaround when AI stops pushing back? Cold reviews, steelmanning, something I haven't thought of — drop it in the comments.

Sass isn't dead, but native CSS just replaced its biggest use case. We can finally write reusable, type-safe functions directly in the browser, with zero build tools. I wrote up a practical guide on Dev.to explaining exactly how native `@function` works.

Koushik Radhakrishnan — Sun, 31 May 2026 06:24:26 +0000

CSS @function - DEV Community

CSS just got its biggest quality-of-life upgrade since custom properties. For years, if you wanted...

dev.to

CSS @function

Koushik Radhakrishnan — Sun, 31 May 2026 06:15:04 +0000

CSS just got its biggest quality-of-life upgrade since custom properties.

For years, if you wanted reusable logic in CSS, you had two choices: wrestle with custom properties that couldn't do real computation, or reach for a preprocessor like Sass. That era just quietly ended. CSS now has native custom functions — and they're as powerful as you'd hope.

1. What Exactly Is `@function`?

Think of it exactly like a JavaScript function — but living inside your stylesheet. You give it a name (always prefixed with --), define some parameters, and write a result: descriptor that determines what it returns.

/* BASIC SYNTAX */

/* Define it once */
@function --double(--x) {
  result: calc(var(--x) * 2);
}

/* Call it anywhere */
.box {
  width: --double(20px);  /* → 40px */
  height: --double(50px); /* → 100px */
}

No var() wrapper needed to call it. No build step. No Sass import. Just define and use — as many times as you like, across your entire stylesheet.

Note: Unlike Sass, native CSS functions don't evaluate math automatically. You must wrap mathematical operations in calc() inside your result descriptor.

2. The Syntax in Full Detail

Parameters with Default Values

You can make parameters optional by giving them a fallback — the function still works even if you don't pass a value.

@function --spacing(--size: 16px) {
  result: calc(var(--size) * 1.5);
}

.card {
  padding: --spacing();      /* → 24px (uses default) */
  margin: --spacing(20px);  /* → 30px */
}

Type-Safe Parameters

You can declare the expected type of each parameter — and the return type too. The browser will validate this at parse time, preventing weird cascading bugs.

@function --fade(
  --color <color>,
  --alpha <number>: 0.5
) returns <color> {
  result: color-mix(
    in srgb,
    var(--color),
    transparent calc(var(--alpha) * 100%)
  );
}

.overlay {
  background: --fade(royalblue, 0.3); /* 70% opaque blue */
}

Logic Inside Functions

This is where @function gets genuinely exciting. You can embed @media or @supports queries right inside a function to return different values based on conditions.

@function --responsive-font(--sm, --lg) {
  result: var(--sm); /* mobile default */

  @media (min-width: 768px) {
    result: var(--lg); /* larger screen override */
  }
}

h1 { font-size: --responsive-font(24px, 48px); }
p  { font-size: --responsive-font(15px, 18px); }

3. Real-World Examples

Example 1 — Theme-Aware Sizing (Light/Dark)

The built-in light-dark() function only works with color values. With @function, you can extend that same idea to any CSS property — font weights, border radius, letter spacing, anything.

@function --theme-val(--light, --dark) {
  result: var(--light);

  @media (prefers-color-scheme: dark) {
    result: var(--dark);
  }
}

button {
  font-weight: --theme-val(500, 400);
  border-radius: --theme-val(6px, 2px);
  letter-spacing: --theme-val(0em, 0.03em);
}

Example 2 — Color Opacity Shorthand

Stop writing color-mix() from scratch every time you need a translucent variant of a color.

@function --alpha(
  --c <color>,
  --a <number>: 0.5
) returns <color> {
  result: color-mix(
    in srgb,
    var(--c) calc(var(--a) * 100%),
    transparent
  );
}

.modal-bg { background: --alpha(#0f0f0f, 0.7); }
.chip      { background: --alpha(royalblue, 0.15); }
.highlight { background: --alpha(gold, 0.3);      }

4. Why This Beats Sass/SCSS for These Use Cases?

Let's be clear — Sass isn't going away. But @function directly replaces its most common use case: reusable value computation. Here's why the native approach wins:

No build step. Your function evaluates at runtime in the browser, not at compile time. It can react to live conditions like viewport size or user preferences.
Works with custom properties. You can pass var(--token) directly as a function argument. Sass couldn't dynamically read runtime custom property values.
Type safety. Declare parameter types and return types. The browser validates them — something Sass never did natively.
Ships in your CSS. Devtools can inspect it, browser can cache it. Zero toolchain friction.

5. Browser Support & Current Limitations

🔴 @function shipped in Chrome 139 (May 2025) and is supported across Chrome, Edge, and Opera (~67% of global users). Firefox and Safari are still pending — production use without a fallback affects ~33% of users.

🚫 No recursion. A function cannot call itself. Recursive patterns need to stay in JavaScript.

🚫 No side effects. Functions can only compute and return a value. You can't modify a DOM element's class or trigger an animation directly from inside a function.

⚠️ Name must start with --. Easy to forget. --my-fn() works; myFn() does not.

⚠️ Spec is still evolving. Some details (like interaction with cascade layers) are still being refined in the css-mixins-1 spec. Treat this as stable-but-maturing.

⚠️ No cross-file imports natively. Functions defined in one CSS file are not automatically available in another unless you use @import or bundle them together.

💡 Progressive Enhancement Strategy
Use @supports to check for @function support, or define a plain var() fallback first and layer your function-based values on top. Users on unsupported browsers will get the fallback; Chrome/Edge users get the enhanced version.

If this was useful, share it with your frontend team. Drop a comment with the most creative use case you can think of — I'd love to see what people build with this. 👇

DEV Community: Koushik Radhakrishnan

[Boost]

Your AI Code Reviewer Is a Liar, And You're Making It Worse

Your AI Code Reviewer Is a Liar, And You're Making It Worse

This Has a Name

Why Code Review Gets Hit Hardest

The Real Problem: You're Reviewing the Reviewer

How to Actually Fix This

A Workflow That Accounts for Sycophancy

The bottom line:

Sass isn't dead, but native CSS just replaced its biggest use case. We can finally write reusable, type-safe functions directly in the browser, with zero build tools. I wrote up a practical guide on Dev.to explaining exactly how native `@function` works.

CSS @function - DEV Community

CSS @function

1. What Exactly Is @function?

2. The Syntax in Full Detail

Parameters with Default Values

Type-Safe Parameters

Logic Inside Functions

3. Real-World Examples

Example 1 — Theme-Aware Sizing (Light/Dark)

Example 2 — Color Opacity Shorthand

4. Why This Beats Sass/SCSS for These Use Cases?

5. Browser Support & Current Limitations

1. What Exactly Is `@function`?