Forem: Hariom Sharma

Claude Moves Fast. Codex Ships.

Hariom Sharma — Tue, 05 May 2026 00:00:07 +0000

I gave two big coding tasks to both Claude and Codex.

Claude finished in about one hour. Codex took about eight.

That sounds like a clean win for Claude until you look at what came back. The Claude output was fast, confident, and useless. Bad assumptions, broken code, missing integration points, half-followed rules, and a shape that would make the codebase harder to maintain even if I patched it into working order.

I threw it away.

The Codex output took a full workday. It read the repo. It followed the local instructions. It reused existing patterns. It added tests. It ran checks. And when I ran the result the first time, it worked.

That changed how I think about AI coding tools.

I am not writing this as a casual weekend test. I have shipped three products in the last four months with AI doing a serious amount of the implementation work. I use these tools hard enough to burn through weekly limits on a $200/month subscription. This is still personal opinion, not a benchmark, but it is opinion built from long hours in real repos where broken code costs me time.

Key Takeaways

Claude optimizes for motion. Codex optimizes for grounded work.
Fast output is not fast delivery if you spend the next day cleaning it up.
Codex's friction is annoying, but most of that friction is it reading, verifying, and respecting project rules.
Superpowers improves both tools, but each agent follows the workflow differently.
Claude's subagent defaults are useful, but delegation does not save you when the main agent is willing to invent around your codebase.
For work I actually ship, I now trust the slower agent more.

Claude feels like an engineer who wants to finish the ticket before lunch.

Codex feels like an engineer who annoys you by reading every linked file before touching the code, then quietly hands you something that passes tests.

The one-hour trap

The trap is simple: Claude makes progress visible very quickly.

It edits. It assumes. It finds a path through your rules. It writes what it thinks should exist. It may use subagents aggressively. It may produce a lot of code fast. That feels productive while it is happening.

Then you run it.

The first failure is usually small. A type mismatch. A missing import. A component API that does not exist. A hook that follows a generic React pattern instead of your local data-fetching pattern.

You ask for a fix. Claude patches the symptom. Now something else breaks.

You ask why the original thing failed. Instead of tracing the root cause, it often jumps into another patch. The code starts collecting bandaids. The more you accept, the harder it becomes to tell what is necessary and what is agent residue.

That is how a codebase becomes fragile. Not from one bad commit. From many plausible commits that never had to prove they matched the system.

The eight-hour tradeoff

Codex is slower in a way that can be frustrating.

For even simple work, it tends to read first. It opens the files. It checks instructions. It searches for existing patterns. It tries to understand why the current code is shaped the way it is. It is much less eager to introduce a new abstraction just because it can.

To be fair, that eight-hour run was not an optimized Codex setup. I tested Codex almost as soon as I installed it. I only had Superpowers installed. I had not yet tuned my AGENTS.md, wired a stronger agent workflow, or built the muscle memory for telling Codex when to split work.

So a lot of the time was self-inflicted setup friction.

Codex also tested after almost every meaningful change. That ate most of the wall-clock time. It would edit, run the relevant check, read the failure, patch, run again, and keep going. That is slow compared with an agent that writes a big diff and says "done." It is also why the final result worked.

The other missing piece was default subagents. Claude tends to fan out work more aggressively. My Codex setup did not do that by default. Without explicit subagent instructions, more of the work stayed in the main thread, which made the run longer than it needed to be.

That patience costs time.

But the time is not empty. It is spent on the things that usually decide whether code survives first contact with the repo:

Does this match the surrounding modules?
Is there already a helper for this?
Are there project rules that override the obvious solution?
Is the failure the root cause, or just the first visible symptom?
What is the smallest check that proves this change worked?

I do not want a coding agent that wins the stopwatch and loses the branch.

I want the branch.

Search behavior is a bigger difference than people admit

Claude tends to work from model knowledge unless you push it to fetch current information.

For stable things, that is fine. For modern SDKs, AI tools, product docs, pricing, CLI behavior, framework releases, or anything that may have changed last month, it is dangerous.

I do not want an agent confidently writing against a six-month-old mental model of a library.

Codex is much more willing to say: this might have changed, search first. The installed CLI even exposes --search, and the current Codex docs have first-class pages for rules and subagents. The exact feature surface changes fast, which is the point: for fast-moving tools, searching is not optional polish. It is correctness.

This is one of the reasons Codex feels slow. It spends time making sure the premise is still true.

Rules matter more than intelligence

My biggest complaint about Claude is not that it is dumb. It is not. It is powerful.

The problem is that it is too willing to route around constraints.

If a repo says "do not edit env files," I do not want the agent to decide that .env.example is close enough to documentation. If a repo says "do not add scripts unless asked," I do not want the agent to add a convenience script because it makes its own workflow nicer. If I ask "why is this not working," I do not want three patch attempts before the root cause is found.

Codex is slower partly because the rules stay heavy in its head.

It treats instructions as part of the job, not as decoration. That matters in real repos, where the fastest fix is often the fix that breaks a migration, a hook, a deploy job, or another engineer's in-progress work.

Where Superpowers fits

I also use Superpowers with both Claude and Codex.

Superpowers is a workflow plugin by Jesse Vincent. The pitch is simple: do not let the agent jump straight into coding. Make it brainstorm, plan, route work, use TDD when appropriate, review the result, and verify before claiming success. The official Claude marketplace page describes it as a skills framework for brainstorming, subagent development, debugging, TDD, and skill authoring. The GitHub repo also documents Codex installation, so this is not a Claude-only idea.

Claude does pretty well with Superpowers. It understands the workflow and can move fast once the plan exists. The problem is that Claude still feels like it is deciding when the workflow matters. Sometimes it invokes the right skill. Sometimes it treats the skill like advice. Sometimes it decides the task is obvious and starts moving.

Codex behaves differently. If the rules say "use Superpowers to route this," Codex is much more likely to actually do that. It will invoke the routing step, check which skill applies, and follow the workflow even when I personally think the task could have been done in two edits. That strictness was part of why my first Codex run took so long: Superpowers wanted routing and planning, and Codex treated that as a rule, not a suggestion.

That is both good and bad.

For big tasks, I want that discipline. Route first. Plan first. Use subagents when the work is independent. Review before declaring done. That is exactly where Superpowers shines.

For small tasks, it can be overkill. If I ask for a copy tweak or a one-line bug fix, I do not always need a methodology. This is the same tradeoff as Codex itself: the discipline that makes it reliable on large work can feel heavy on tiny work.

Still, if I have to choose which failure mode I prefer, I will take "too much process" over "fast wrong code" almost every time.

Subagents are not magic

Claude defaults harder toward subagents. Codex can use subagents too, but in my workflow I usually need to ask explicitly or encode it in AGENTS.md. That lines up with the Codex subagents docs, which describe them as explicit helpers for larger tasks. On that first run, I had not done the tuning yet, so Codex paid the cost of doing too much sequentially.

That is a real advantage for Claude. Subagents can isolate context, split work, and make large tasks move faster.

But delegation only helps if the delegated work is bounded and grounded.

If the parent agent makes bad assumptions, you get multiple workers implementing bad assumptions in parallel. That is not leverage. That is multiplication.

Codex's default is more conservative. It does not fan work out as aggressively unless the task clearly benefits from it. Sometimes that costs time. Sometimes it prevents a mess.

The real speed metric

Here is the metric I care about now:

How long from prompt to shippable branch?

Not prompt to diff.

Not prompt to "I made the changes."

Not prompt to a confident summary.

Prompt to code I can ship without feeling like I need to audit every line for agent damage.

On that metric, the one-hour Claude run was slower than the eight-hour Codex run because the Claude output had no path to trust. Every line needed suspicion. The Codex output had already done the boring work: inspect, edit, test, verify.

That is why I keep using Codex even when it annoys me.

I do not need the fastest agent.

I need the one whose output I can ship with confidence.

Originally published at harryy.me

I Built the Free Geo API Every App Eventually Needs

Hariom Sharma — Thu, 30 Apr 2026 14:52:06 +0000

Every app eventually needs boring location data.

Country dropdowns. State selectors. City autocomplete. Timezone hints. IP-based defaults. The work is not hard, but the options are usually annoying: pay for an API, sign up for a free key with tiny limits, or self-host a database dump for a form field.

I wanted the boring version: no key, no signup, no server to babysit.

Key Takeaways

The API serves 252 countries, 5,024 states, 232,008 cities, 312 timezones, and 178 currencies
Cloudflare's request.cf gives caller location hints; D1 enriches them with full records
SQLite FTS5 handles global search without Algolia or Elasticsearch
The best product decision was deleting auth, API keys, and app-level rate limits

Why existing geo APIs are annoying

Most geo APIs make static data feel dynamic.

Country names, ISO codes, currencies, timezones, and state boundaries come from public datasets. Charging per request for a list of countries is a business model, not a technical requirement.

Free APIs exist, but many still require registration before a developer can run one curl. Some have tiny daily limits. Some are slow because every request goes back to the same origin.

Self-hosting fixes control but adds chores: download dumps, import them, expose routes, write search, keep everything updated. For a country dropdown, that is a lot of infrastructure.

The shape I wanted was simpler:

Requirement	Why it mattered
No API key	Let people try it before they care
Cached static data	Countries and timezones do not change per request
Real database queries	JSON blobs are fine until search and pagination show up
Self-hostable	A fork should not depend on my domains
Open data sources	No mystery dataset hiding behind the API

That led to Cloudflare Workers, D1, and a small Hono router.

The architecture is intentionally small

The public API is one Worker with one runtime dependency: Hono for routing and CORS.

There is no ORM, no API gateway, no auth service, and no external search cluster. The Worker talks to D1 through a binding, serves static assets through Workers Static Assets, and exposes the OpenAPI spec from the same deployment.

Host	What the Worker returns
`geocoded.me`	Landing page, dashboard, explorer, docs
`api.geocoded.me`	JSON API
`/openapi.json`	OpenAPI 3.1 document
`/postman.json`	Postman collection

The important bit is not cleverness. It is drift control.

The docs site and API ship together, so the documentation cannot lag behind a separate backend deployment.

What actually shipped?

The API is mostly boring REST.

The useful parts are the defaults: all list endpoints are paginated, every endpoint supports field selection, and static responses get long-lived cache headers.

The first useful route is also the shortest:

curl https://api.geocoded.me

That returns the caller's Cloudflare location hints, then enriches them with full country, state, and city records when D1 can match them.

Cloudflare already has the first location signal

Cloudflare adds a cf object to inbound Worker requests. When available, it includes useful hints like country, region, city, coordinates, timezone, ASN, and colo.

That is enough to answer "where is this request probably coming from?" It is not enough to power a product UI.

Cloudflare might give you country: "US" and regionCode: "CA". Geocoded turns that into full records: country name, flag emoji, currency, phone code, state name, timezone, and city metadata.

Response type	Cache policy	Reason
Countries, states, cities, timezones, currencies	`public, max-age=31536000, immutable`	Data changes through the pipeline, not per request
Caller location	`private, no-store`	Your IP location changes with VPNs, travel, and networks
OpenAPI/Postman docs	Short public cache	Useful to cache, but easier to refresh

The city match is deliberately conservative: country + state + city name. It works well enough for a free API, but I would not pretend it is a parcel-grade geocoder.

Why D1 was enough

D1 gave me the part JSON files do not: queries.

Countries, states, cities, timezones, and currencies live in normal tables with indexes. Global search uses SQLite FTS5, so ?q=san can search across countries, states, and cities without an external search service.

The whole schema is still small. The checked-in JSON output is under 70 MB, and the D1 database stays well below the current D1 storage limits.

Feature	Why D1 fit
Pagination	`LIMIT`, `OFFSET`, and a simple opaque cursor
Lookup routes	Indexed country/state/city columns
Full-text search	FTS5 virtual table
Self-hosting	`wrangler d1 create`, migrations, seed script
No database server	D1 is managed and bound directly to the Worker

If this becomes a fuzzy geocoder, I would revisit the storage/search layer. For country/state/city lookup, D1 is enough.

Field selection is the cheap GraphQL

A full country record has a lot of fields: translations, neighbours, languages, driving side, literacy rate, timezone list, currency info, postal code metadata, and more.

Most callers do not need all of that.

So every endpoint accepts ?fields=:

Request	Payload intent
`/countries?fields=name,iso2,emoji`	Build a country selector
`/countries/US?fields=name,capital,currency`	Show a compact country profile
`/?fields=ip,country,countryInfo.name,countryInfo.emoji`	Enrich caller location without the full country object

I considered GraphQL for about five minutes.

Then I remembered what I actually wanted: comma-separated fields, dot notation for nested objects, and no new runtime dependency.

The data pipeline is the real product

The API is small because the pipeline does the messy work before deploy time.

The data comes from institutional sources: GeoNames, Unicode CLDR, IANA, ISO 4217, Natural Earth, Wikidata, trusted boundary sources, and vendored CIA World Factbook demonyms.

Source	Used for
GeoNames	Countries, admin divisions, cities, coordinates, population, timezones
CLDR	Translations, currency symbols, GDP/literacy hints, week/time/measurement data
IANA	Timezone IDs and country mappings
ISO 4217	Currency codes, names, decimal digits
Natural Earth	ISO 3166-2 subdivision codes and types
Wikidata	Missing subdivision IDs and capitals
CIA World Factbook	Nationalities/demonyms

The pipeline fetches source files daily, hashes them with SHA-256, and exits without writing anything when upstream data has not changed.

When something changes, it builds five JSON files, validates them, pushes the public output into the API repo, and the API repo's seed workflow loads D1.

That gives the Worker a boring job: read tables and return JSON.

The best feature was removing features

The first version had API key registration.

Email form. Confirmation flow. Key storage. Per-key limits.

Then I looked at it and asked: what am I protecting?

The source data is public. The output is public. The project goal is adoption. Putting registration in front of a free country list only makes the product worse.

Removed	What got better
API keys	One `curl` proves the API works
Account creation	No database table for users
Per-key limits	No identity layer just to throttle public data
Email confirmation	No delivery, spam, or bounce handling

There are still platform limits and abuse protection at Cloudflare's layer. I just stopped building application-level gates for a dataset that was meant to be open.

Where this breaks down

City matching is name-based. The location endpoint matches Cloudflare's city hint against D1 cities inside the detected country and state. Cities with identical names in the same state can collide.

D1 has storage limits. The current dataset fits comfortably. A future "every hamlet on earth" version would need a different storage/search plan.

The data is as good as its sources. Cross-referencing helps, but upstream mistakes still make it through sometimes.

The stack is Cloudflare-specific. Self-hosters need Workers, D1, Wrangler, and the request.cf object for the location endpoint.

That is a deliberate trade-off. This project optimizes for a tiny operational footprint, not cloud portability.

Try it

Start with the location endpoint:

curl https://api.geocoded.me

Then grab slim country data:

curl "https://api.geocoded.me/countries?fields=name,iso2,emoji"

Search and drill down:

curl "https://api.geocoded.me/search?q=san+francisco&type=city"
curl "https://api.geocoded.me/countries/IN/states?fields=name,iso2"
curl "https://api.geocoded.me/countries/US/states/CA/cities?limit=10"

Timezones and currencies are separate resources:

curl "https://api.geocoded.me/timezones?fields=timezone,countryCodes&limit=5"
curl "https://api.geocoded.me/currencies?fields=code,name,symbol&limit=5"

No API key. No signup. No demo account.

harryy2510/geocoded on GitHub

What do you usually do for location data: pay for an API, ship a JSON package, self-host a dump, or hardcode the list and move on?

Originally published at harryy.me

Hello World

Hariom Sharma — Fri, 24 Apr 2026 06:21:08 +0000

I have been writing notes for years. Architecture decisions, debugging war stories, things I wish someone told me before I shipped that thing to production. All sitting in private docs nobody reads.

That felt like a waste. So here we are.

Why bother?

I have shipped 15+ products across 10+ industries over the last decade. Google, Telefonica, startups you have never heard of. Every project taught me something. Most of those lessons live in my head or in scattered docs. A blog gives them a permanent home and forces me to think clearly about what I actually learned vs what I think I learned.

A portfolio shows what I built. A blog shows how I think. If you are deciding whether to work with me, both matter.

What to expect

Short posts on real engineering problems. Architecture decisions where both options suck and you pick the less painful one. AI tooling: I have been deep in Claude Code, building plugins, automating my own workflow. Performance work. Shipping fast without shipping garbage.

No listicles. No "ultimate guides." No sponsored content. Just notes from building things.

This blog's stack

Astro with MDX on Cloudflare Workers. Zero client JavaScript (except a tiny search filter). Content Collections for type-safe frontmatter. Shiki for code highlighting. The whole thing scores 100 across Lighthouse.

const posts = await getCollection('blog', ({ data }) => {
    return !data.draft && data.publishDate <= new Date()
})

Every post is an .mdx file committed to the repo. Git is the CMS. No database, no build-time API calls, no dependencies that will break in six months.

First real posts coming soon: starting with how I set up my AI development stack and why most people are burning tokens for nothing.

Originally published at harryy.me