DEV Community: Pranav - (pranavb.xyz)

Why GPT Models Sucked At UI

Pranav - (pranavb.xyz) — Wed, 22 Jul 2026 11:16:36 +0000

I had this default belief for a while:

Claude/Opus for UI.
Codex/GPT for code.

And honestly, I think a lot of devs had some version of that in their head too.

Claude Code usually felt more tasteful.
Codex frontend output had that same repeated smell:

cards everywhere,
generic dashboard polish,
same-ish layouts,
same-ish "AI app" vibe.

So the easy conclusion was:

GPT just sucks at UI.

But after watching Theo's video and checking OpenAI's own Codex model manifest, I don't think that explanation is clean enough anymore.

GPT-5.5 inside Codex had a huge frontend guidance block sitting in the harness.

Not just "make the UI good".

Actual rules around:

card radius
icon choices
hero layouts
color constraints
button behavior
visual assets
what kind of UI patterns to avoid

That stuff should not be global hidden law.

"Use icons" depends on the product.
"Don't make this kind of hero" depends on the page.
"Cards should be this radius" is not something every repo should inherit because a model manifest said so.

So when people say "GPT has bad UI taste", the fairer question is:

what exactly did Codex tell it to do before my prompt even started?

The part people keep mixing up

When we compare Claude Code vs Codex, we are usually not comparing just model intelligence.

We are comparing the full harness around the model:

system prompt
tools
memory
project instructions
repo context
compaction
permissions
product defaults

Same model in a different harness can feel like a different product.

That is why Theo's experiment was interesting to me.

He ran GPT-5.6 Sol through a Claude Code-like setup using CLIProxyAPI, and the output looked much better than the usual Codex UI reputation would make you expect.

Not a perfect benchmark.

Still useful.

Because it separates two things people usually collapse into one:

model capability
harness behavior

Also, GPT is clearly not helpless at React.

ReactBench currently has GPT models scoring extremely well on realistic React tasks.

So the model being bad at React is not the clean explanation.

One caveat before this becomes too dramatic

I checked the current public Codex manifest again before updating this post.

The old GPT-5.5 entry still has that frontend block.

The current GPT-5.6 Sol entry does not seem to have that exact same block in the public manifest.

So I am not claiming the latest ChatGPT/Codex app still behaves exactly like old GPT-5.5 Codex.

That would need separate product-level proof.

What I am saying is simpler:

this was real public Codex config, and it is a very good example of how much the wrapper around a model can change the model's perceived taste.

Also, check your own prompt files

And since this whole thing is basically about prompts steering models, this is a good time to look at your own setup too.

Open your AGENTS.md, CLAUDE.md, custom instructions, and skills.

Not as some productivity ritual.

For the same reason this Codex thing matters:

hidden instructions steer outputs.

A rule you added six months ago because GPT-4 kept doing something annoying might be actively hurting a newer model now.

A giant CLAUDE.md that keeps repeating old architecture notes, dead commands, stale style opinions, and random preferences is not harmless.

It is context.

It is steering.

Claude's own docs say CLAUDE.md gets loaded into context, and that memory works better when instructions are specific, concise, and periodically reviewed.

So yeah, go look at yours.

I would bet a lot of people have rotten agent files they have not read in months.

And then we blame the model.

Resources I checked

Hoisting Isn't Even Real

Pranav - (pranavb.xyz) — Sat, 20 May 2023 08:51:29 +0000

One of the most famous interview topics - HOISTING, isn't even real.

Yes, you heard that right.

The word 'hoist' wasn't even used in the official ECMAScript specifications until the year 2015. It was first mentioned in the ECMAScript 6 specification, which was published in June of that year.

DEFINITION

If you search on Google, this is what you get

JavaScript Hoisting refers to the process whereby the interpreter appears to move the declaration of functions, variables or classes to the top of their scope, before the execution of the code. Hoisting is not a term normatively defined in the ECMAScript specification.

Please refer to it here.

And even there they've correctly mentioned that Hoisting is not a term normatively defined in the ECMAScript specification.

MISINFORMATION

shinobi;
sensei;
var shinobi = 'naruto';    // line 3
var sensei = 'kakashi';    // line 4

So, based on the definition of hoisting, JS should be able to anticipate all variable declarations, as seen in lines 3 and 4, regardless of their position within the scope and move them to the top of the scope before the code execution begins.

Something like this:

// before execution
var shinobi;
var sensei;

shinobi;
sensei;
shinobi = 'naruto';
sensei = 'kakashi';

Which is not what happens.

JavaScript doesn't move things around the way we might expect it to. Because how would it magically be able to look ahead & find only the declarations in the very first pass?

To be able to do that, you would need to perform complex processing on later tokens in the code block until reaching its end. And theoretically extract any declarations if any are encountered and move them to the top. And guess what that magical processing's called - PARSING!

So, Hoisting is just a shorthand, a convenient explanation to describe this magical behavior without getting into the nitty-gritty details.

REASON

All this misunderstanding occurs because JS execution is a 2-pass process i.e. parsing/compilation & execution. But people tend to think of JS execution as one pass process rather than two.

If you think of it as 2 passes. You can easily explain this magical behavior with the help of Lexical Scope.

Unfortunately, I can't cover it now because of the vastness of the topic but you may refer this as the best resource.

Function Scopes and IIFE Pattern

Pranav - (pranavb.xyz) — Tue, 09 May 2023 19:20:19 +0000

WHY

Consider you've written code like the below at some point. We've declared a var and hope that it still has the same value. Well, right now it looks good.

var ninja = 'Naruto';

// ...

console.log(ninja); // Naruto

But say after a few months a jr. dev comes along and unknowing try to make a change like this.

var ninja = 'Naruto';

// ...

var ninja = 'Sasuke';
console.log(ninja); // Sasuke

console.log(ninja); // Sasuke -- oops!

So, you can easily see the issue here.
We have a naming collision problem.

You may think, we should just use const there. But the problem is not if the variable can be reassigned (because the developer if not aware could just modify your const to var anyways) but we have a naming collision problem.

So, the problem is: We have a problem where 2 different people wanna use the same semantic name for their purposes.

PSEUDO FIX

Since the problem could be thought of as mainly arising due to the declaration of the variable in the same scope. So, the natural fix coming to mind would be, to make use of different scopes, and one simple way to do so could be by wrapping a function around it.

var ninja = 'Naruto';

function anotherNinja() {
    var ninja = 'Sasuke';
    console.log(ninja); // Sasuke
}
anotherNinja();
console.log(ninja); // Naruto

So, now those vars don't seem to collide anymore and the code seems to work well. But now the problem is, we have a named function in the same scope.

So it seems, we didn't solve the name collision problem, we just shifted it to a different variable name.

REAL FIX - IIFE

var ninja = 'Naruto';
(function anotherNinja() {
    var ninja = 'Sasuke';
    console.log(ninja); // Sasuke
})();
console.log(ninja); // Naruto

So, this code pattern you see is called an IIFE pattern i.e. Immediately Invoking Function Expression, which does exactly what it sounds like.

Using IIFE, we're creating a new scope and immediately invoking it.

Another use case: when you want to turn statements into expressions

Consider below example:

var ninja;
try {
    ninja = fetchNinja();
}
catch (err) {
    console.log(err);
}

If you wanna do something like this, since try-catch is a statement it doesn't work in an expression position.
You can do something like this:

var ninja = (try {
    ninja = fetchNinja();
}

catch (err) {
    console.log(err);
})();

Summary

Try to follow "The principle of least privilege" whenever possible.

The principle of least privilege is the idea that any user, program, or process should have only the bare minimum privileges necessary to perform its function.

Leverage the power of function scopes and IIFE patterns to enjoy the benefits of the principle like:

Avoid naming collisions
Restrict code access
Ability to freely refactor code

API Gateway Responses and Handling Authorizer Responses

Pranav - (pranavb.xyz) — Thu, 04 May 2023 01:44:39 +0000

Intro

I have added a token-based Lambda Authorizer for all my backend services deployed on API Gateway. I wanted the user to be signed out if the authorizer responds with a 401 (Unauthorized) or 403 (Access Denied) error.

This is how my code looked like for the authorizer lambda:

const jwt = require('jsonwebtoken');

exports.handler = function (event, context, callback) {
  const token = event.authorizationToken?.split(' ')[1];

  if (!token) {
    callback('Unauthorized'); // Return a 401 Unauthorized response
  }

  const data = jwt.verify(token, process.env.SECRET, (err, data) => {
    if (err) {
            // Return a 403 Access Denied response
      callback(null, generatePolicy('user', 'Deny', event.methodArn, {"messageString":"Invalid token"}));
    }
    return data;
  });

  callback(null, generatePolicy('user', 'Allow', event.methodArn, data));
};

// Help function to generate an IAM policy
const generatePolicy = function (principalId, effect, resource, data) {
  const authResponse = {};

  authResponse.principalId = principalId;
  if (effect && resource) {
    const policyDocument = {};
    policyDocument.Version = '2012-10-17';
    policyDocument.Statement = [];
    const statementOne = {};
    statementOne.Action = 'execute-api:Invoke';
    statementOne.Effect = effect;
    statementOne.Resource = resource;
    policyDocument.Statement[0] = statementOne;
    authResponse.policyDocument = policyDocument;
  }

  // Optional output with custom properties of the String, Number or Boolean type.
  authResponse.context = {
    ...data,
  };
  return authResponse;
};

After this, I used to get error logs on my client apps, but I could not access the response object to check the response's status code.

I needed to determine if an error was caused by my authorizer (resulting in a 401 or 403 status code) or by my API endpoint lambdas. The issue was that the response was being caught as a fetch error in the catch block instead of returning a response with the expected status code and message that I could handle properly.

Additionally, I guess it was even giving me a CORS error, which I wasn't able to understand why.

Solution

After quite a bit of searching, I found out that to receive proper handleable responses, I would need to configure the API Gateway Responses section in the API Gateway.

Here, you can see all of the responses the API Gateway is capable of handling.

Add the CORS headers in the response header to receive proper handleable responses and configure the response templates as you need.

In my case, this is how I configured my Access Denied:

#Note: Here, the messageString comes from the context data that we are sending from our Authorizer function that we defined previously.

.
.
.
if (err) {
    // Return a 403 Access Denied response
  callback(null, generatePolicy('user', 'Deny', event.methodArn, {"messageString":"Invalid token"}));
}
.
.
.
  authResponse.context = {
    ...data,
  };
}

For more info:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#api-gateway-gatewayResponse-definition