I built halilerencelik.com with OpenAI's Codex. Everything added since — the blog you are reading and its Turkish version — was built with Claude Code. Same person, same site, two tools. These are the differences that actually showed up in the work, not the ones on a feature page.

Disclosure. This post was written with Claude Code, which makes it a comparison partly authored by one of the things being compared. So it stays on ground that can be checked: what I built, what broke, and what I decided. The judgement is mine.

What I built with each

Codex produced the site itself: a hand-written static site, no framework, no build step, six case studies, the home page and the about page. Not scaffolding I then rewrote — the thing that is live.

Claude Code produced everything after: the blog and its posts, the Turkish counterpart of every page, the search and structured-data work, and a good deal of correction to my own earlier assumptions.

That matters for reading the rest of this. Neither tool got a toy project. Both got the same real site, at different stages of it.

Where ChatGPT is still better for me

Analysis and content. When I need to think through a problem in prose — structure an argument, work out what a section is really saying, push on an idea before it costs anything — ChatGPT is where I go, and switching away from it for that would be a downgrade.

I want to be precise about the claim: this is a preference formed on my own work, not a benchmark. But it has held long enough that I stopped treating it as a mood.

What made me switch for building

One concrete friction, and it was about design tooling rather than code.

I work in Sketch as well as Figma. Sketch ships an MCP server inside the Mac app, so an assistant can read the layer tree and pull assets directly. In my setup that connection kept dropping — not once, repeatedly, in the middle of work. And I could not find a Sketch extension inside Codex itself to fall back on.

That sounds small written down. It is not, because a design tool that disconnects halfway through a task is worse than one that was never connected: you keep starting over, and you stop trusting what the assistant thinks it can see.

What replaced it was not a single feature. It was that the assistant could reach the whole chain — the design file, the repository, the commit, the deployment — and stay there. I have written about that setup separately.

A tool that disconnects halfway through is worse than one that was never connected. You do not just lose the work; you lose your ability to trust what it sees.

What actually changed in the work

The loop closed. With Codex I was moving output into place myself and checking it afterwards. Now a change becomes a commit with a message that explains it, the commit becomes a preview deployment, and I open the preview on a phone before anything reaches production.

The gain is not speed. It is that every step leaves a trace I can inspect. When something renders wrong I can see it rather than take anybody's word for it — including the assistant's.

Does the tool decide the outcome?

No, and I would distrust this post if it implied otherwise. The site Codex built is a good site. The parts built since are good because I knew what I was asking for, not because the assistant changed.

The test I apply has not moved: if this comes back wrong, will I be able to tell? A tool earns more of the work when it makes that easier to answer — by showing me the file, the diff, the rendered page. It earns less when it makes the answer harder, whatever it can generate.

What I would tell someone choosing

  • Do not choose on capability lists. Both will produce a working page from a description. That stopped being the differentiator.
  • Choose on what happens when it is wrong. How quickly you find out, and how much of the trail you can inspect.
  • Check the connection to the tools you actually live in — your design app, your repository, your host. A capable assistant that cannot reach them is a smart assistant in another room.
  • Do not assume one tool for everything. I build in one and think in the other, and I have stopped trying to collapse that.

Read next

Halil Eren Çelik

Halil Eren Çelik

Lead Product Designer · Design Manager · Photographer

Fifteen years turning complex requirements into products people can actually use — lately with AI as a collaborator rather than a competitor. Photographs as a hobby.