Microservices were the gold standard, so the real-world project I led the development on had to be microservices. Almost a year in, when the cracks started forming, I took the decision to merge everything back into a modular monolith which improved DX by nearly 2x for my small team.

If all you have is a hammer, everything looks like a nail.

I was a REST purist. Then I shipped enough user-facing products to see that strict RESTful API design is a bottleneck when your domain is actions, not resources. Sometimes you just need POST /approve.

The same pattern repeated in many decisions that I had to backtrack on: MongoDB to PostgreSQL, Polyrepos to Monorepos, JWTs to plain old sessions.

That's not to say that there aren't uses for the things I've discarded. Microservices make sense when your teams need independent deployment cycles. JWTs have a clear place in stateless, distributed auth across services.

The unlearning wasn't about those tools being wrong but rather about me being wrong about when to reach for them. The engineering instinct is to learn more. I've found more leverage in questioning what I already think I know.

I recently changed my working hours from 9am-5pm to 2pm-10pm. That gave me early mornings completely to myself without all the noise. I still get enough overlap with my team in the evening, but the first half of my day is protected for personal time.

Before making the change, I kept a counter for all the messages, quick doubts, "two-minute" clarifications, spontaneous discussions throughout a normal working day. I was averaging 16. These were individually harmless interruptions but collectively destructive.

I had practically cut that number in half. In return, I got two extended blocks of "focus time". One from early morning till noon for my personal work, and another from noon till night (half of which after everyone has left the office) for my work as a technical lead. These turned out to be the most focused, and in turn productive hours I've had in a long time.

Focus is leverage because it multiplies everything you already have. Skills compound, judgement improves, decisions get cleaner all because your cognitive surface area is not being constantly fractured.

If you can consistently create long uninterrupted stretches of work in an otherwise distracted environment, your output will look disproportionate.

Related:

• Workers are interrupted up to 275 times a day - Fast Company

• Programmer interrupted: The cost of interruption and context switching (2022) | Hacker News

Defining the API as a contract before implementing it helps the frontend and backend teams start work in-parallel instead of one waiting for another to get their types and flow of the APIs.

The OpenAPI Initiative happens to create a specification that is very powerful for documenting APIs allowing developers to write clear, defensible API contracts that act as a single-source-of-truth for backend engineers, frontend engineers, QA, technical leadership, and now even AI agents.

There are primarily two ways you could create an OpenAPI-spec compliant API Documentation:
You either hand-author YAML files or rely on code-first generation with the backend framework of your choice. Both are absolutely valid approaches that I’ve seen teams use but both approaches suffer from very different problems.

Editing YAML files by hand is, frankly, not an intuitive way to design what APIs should accept and respond. As the API-surface gets bigger, so does the cognitive cost of keeping up with this increasingly large YAML file. Despite being designed to be a more “human-friendly” alternative to JSON, YAML is still hostile to humans and troublesome to write and maintain.

This “barrier” of authoring YAML files is problematic enough that I see teams avoid writing OpenAPI because of this. Oftentimes, I’ve preferred writing markdown files with embedded Typescript code blocks for defining API contracts and request/response schemas simply because it was much easier to do.

A much more reasonable, alternative approach some teams use is code-first generation. Frameworks like FastAPI have first-class support for automated OpenAPI generation as you write routes and request/response models. Other popular frameworks like Gin, NestJS also have complementary packages that does the job insanely well.

But this approach has its own set of problems:

• Your backend engineers are now in charge of the API contract. It can, and it will deviate from what you initially proposed.

• On several occasions, you will have to fight the framework to ensure that you get the auto-generated documentation right. This can sometimes be in the form of messy boilerplate, or ugly hacks to show a particular type in the spec and remain compatible with code-generation.

This may not be such a dealbreaker for small teams that move fast and do not consider contract-led development important. In fact, if you are able to deal with these two potential issues: the upsides are great. These auto-generated specs are a great way to guarantee end-to-end type-safety between your API clients.

Still, the fact remains that code-first generators see API contracts and documentation as an afterthought. A side-effect of well-written backend code.

Existing Solutions

Are you saying that this is a problem that people haven’t tried solving? Of course not. There are dozens of tools available online that you could use. Even Smartbear (the folks behind OAS) themselves have created the official Swagger Editor, which is YAML-first but not very intuitive unless you get comfortable with the editor. There is Stoplight, which is heavy, and enterprise-first, and has a pricing page! Sure, you could use Postman which works but very clearly isn’t designed for OpenAPI-documentation despite supporting it.

I just want a super-simple, preferably open-source, and free to use API documentation tool. I don’t need accounts, cloud sync, onboarding, pricing, and all that crap!. Is it too much to ask for?

The project closest to what I was looking for, which I found on Github was a little tool called openapi-gui which is quite nice and supported the functionality I was looking for. However, it hasn’t been maintained in over three years and hasn’t evolved with the latest additions to the OpenAPI specification.

Unless…

“I could probably build that” - every engineer ever

Having worked with OpenAPI specifications extensively for the past couple of years and with the power of agentic engineering. I figured; I should probably give it a shot and build something that solves the pain points I’ve highlighted. An intuitive, clean, and simple GUI tool that lets me author API contracts, with support for serializing them into the OAS-YAML files.

I took the assistance of v0.dev and Github Copilot to scaffold a new project. I didn’t want to “vibe-code” it because OpenAPI itself is a complex spec, and being an engineer, it irks me to fire off a dozen mindless proompts and hit save on some AI-slop, no, no, not on my watch you don’t.

I was going to vibe-engineer this project. Starting off with a detailed plan and architecture, fully human-in-the-loop workflow. The agent was still writing 90% of the code but I would occasionally go in and make changes to minor things that I could do much faster than the agent because a prompt → think → execute → review → accept cycle to change the color of a button is how you slowly develop AI-induced brain rot.

The plan

What I did not intend to build: An OpenAPI YAML editor or a Swagger UI clone.

I didn’t want this tool to be YAML-first but instead have its own internal canonical model. This felt like a good-enough abstraction that allows the tool to be independent of OAS and potentially work with any such specification in the future. It also opens room for extensibility beyond the scope of the spec.

Another important consideration was speed and offline-mode. Being a sucker for performance, I wanted it to be blazingly fast. The OpenAPI YAML files I often work with are easily 10k+ LOC. I didn’t want to build a tool that would crawl to process such huge files.

Instead of editing YAML directly, the spec is represented as a typed, in-memory graph. Schemas, routes, parameters, and responses are all nodes with stable IDs. References between them are typed edges, not $ref strings.

This means:

• You can’t create broken references. Edges must point to real nodes.

• O(1) to find “where is this schema used?”

• Circular references and invalid relationships are detectable in real time

Internally, the editor stores the entire API surface as interconnected Map<NodeId, Node> collections. Editing a schema or route is just a direct mutation of this graph.

This allows YAML to only exist at the boundaries (import/export) as a serialization/deserialization layer. This approach offers better performance on large files, off-spec features for QOL (grouping, colors, validators) without polluting the output, and simple undo/redo via graph snapshots.

And here is the final product! My recent obsession with neo-brutalist interfaces did make its way into this little tool as well 😅

A future beyond OpenAPI?

While I tried to support the majority of features outlined in the OpenAPI spec, there are still some things left out such as support for callbacks/webhooks. But I’m very satisfied with what a few hours of agentic engineering could achieve, and I feel like adding support will be a trivial task. As I was developing this editor though, I had some very interesting ideas beyond just being a GUI-based OpenAPI editor.

Because OAS allows someone to author a very detailed outline of an API surface, it is an excellent source for deterministic code-generation (into validators like zod/class-validator, models like pydantic, etc.) as well as a context-rich documentation for LLMs. A step in this direction will take this from an API authoring tool to a really powerful high-level architecting space for people doing spec-driven development using AI agents. There’s a lot of potential there!

If you’ve read this far, try it out for yourself! You can also find the repository here.

If you’re doing hobby projects or your entire pipeline is pure code-gen and you’re doing fine, you’re better off and probably faster sticking with that approach. But if you’re a tech lead or a backend engineer who cares about contract-led development. I hope that this tool might actually be useful!

There are parts of a role which you simply cannot simulate. Intelligence and effort alone will never make a fresher "qualified" for a job on day one. You can learn syntax, solve DSA, read a kazillion architecture blogs but you cannot pre-experience responsibility.

Before my first full-time role, I had been coding for nearly four years. I knew frontend frameworks, backend systems, deployment flows. I could explain tradeoffs clearly, and I could solve DSA like someone interviewing for MAANG. I impressed the interviewer.

The title was "Technical Lead"

I was not a tech lead.

I had no real ownership experience or exposure to managing expectations, or absorbing pressure from above while protecting the team below, or accountability for deadlines that affect revenue, or any of the other endless list of responsibilities I had signed up for.

For the first few months, I was both excited and quietly terrified.

Only after leading a team for several months, making mistakes but also solving the mistakes I made, did the role begin to feel natural. Decisions which were guesses at first became clearer, and the weight became more manageable. I was finally comfortable, calling myself a team lead. I realized that the discomfort I felt in the first few months wasn't a signal that I was wrong for the role. It was the role being learned.

This pattern repeats in a lot of things we do where responsibility is the actual skill being developed — entrepreneurship, parenting, management. You can study all three endlessly and still be unprepared until you're inside them.

There is a minimum exposure time required before identity catches up with title.

If you have the fundamentals, and the willingness to adapt under pressure, waiting until you feel fully qualified is a trap,

async function createEntity(name: string) {
  const existing = await this.userRepo.findOne({ where: { name } });
  if (existing) throw new ConflictException('Name already exists');
  await this.userRepo.save({ name });
}

What do you think is wrong with this block of code?

It looks fine, works fine in most cases, and probably passed your tests. I’ve seen this type of logic in various code reviews, especially from junior developers.

It’s also the kind of logic you’ll find sprinkled all over production systems. Harmless little findOne or SELECT checks followed by some save call. And 99.9% of the time, it’ll do exactly what it says on the tin.

Until it doesn’t.

As you may have been able to ascertain from the title of this post, there is a race condition hidden in this perfectly normal looking code. Most people would assume that JavaScript being a single-threaded language makes it safe from what traditionally causes race conditions in most multi-threaded languages but single-threaded ≠ synchronous, and JavaScript being an asynchronous language allows room for context-switching.

This particular kind is called TOCTOU: Time of Check to Time of Use, a pretty self-explanatory name.

The bug lies in the window of opportunity between these two lines:

const existing = await this.userRepo.findOne({ where: { name } });
// <-- Context switch happens here
await this.userRepo.save({ name });

If two requests come in at the same time with the same name, maybe from a user double-clicking the button, or just two people picking the same name.

• Both requests hit findOne()

• Both see nothing

• Both proceed to save()

Now you’ve got two users with the same name, or your DB throws a 500 because of a violated unique constraint (which is close to the best possible scenario, except for the 500 part).

Beginners and even some experienced devs, get used to writing imperative flows that “just work”. The logic is sound in a vacuum but can’t hold up under concurrency, traffic spikes, or retries.

Race conditions like these are everywhere.

They are so easy to miss because they often happen in rare occasions when the stars align, but also often cause the most trouble by sneaking into places you wouldn’t expect. Anywhere with shared state, concurrent access, and lack of coordination is an opportunity for a race.

Obviously, the TOCTOU issue I introduced earlier is quite easy to solve. You could either set uniqueness at the DB level and ensure such an exception is handled by the server or be proactive and make the operation atomic using a transaction.

But not all race conditions involve a database and they’re not always this easy to reason about. Some common examples include:

• Syncing with a third-party API

• Firing off webhooks or processing them

• Processing retries

• Scheduling jobs with CRON or queue workers

• Updating cache that might be stale by the time it gets read

And your system starts behaving in unexpected, hard-to-reproduce ways in the form of silent failures, double charges, missed events, phantom data, and the like.

There is no silver bullet to fix all sorts of race conditions, but in many cases.

• Enforcing idempotency, short-circuiting repeat requests

• Using atomic job locks (e.g., Redis SETNX with expiry)

• Versioning (ETags, updatedAt, etc.) to detect stale updates

• Debouncing/deduplicating at the client/handler level.

• Preferring command-style APIs over partial updates (e.g, PUT over PATCH)

Are some of the many ways you could solve such conditions

The takeaway isn’t to use a particular library or technique. Anytime you have a shared state and concurrency, you must assume the worst and design for it defensively, not optimistically.

If you build things - games, apps, side-projects of your own, you probably know what I’m talking about. Unless you’re convinced the idea is some billion-dollar unicorn, the motivation curve usually crashes hard after the honeymoon phase. I have one too many potentially cool projects that have become abandonware this way.

But recently, I started doing something which helped me. Not because I forced myself to push through, or because I read a book, or watched some motivational video on 2x. It was something… smaller.

I just started documenting everything I built.

From day zero, be it screenshots, short clips, random work-in-progress footage. Nothing fancy, no plans to share it either. It was more of a private self-documentation more than anything - a log of how the thing was taking shape.

But then every time I hit a slump or when the excitement wore off, when I didn’t feel like continuing, I’d look back at that footage and it helped, every time.

Seeing how far I had come; how much I had figured out or how big of a difference it is (from something rather basic and ugly looking to a polished version of it) made me want to keep going. It was no longer a retrospect in my head, and I could see the evolution of the work. The fact that I’d taken something from zero to wherever it was now.

I’m aware that we all know we started from scratch. But watching it from a third-person view, seeing the Unity scene turn into a moving character and then being put in an environment, or seeing my first preview of the dashboard morph into something worth looking at. Undeniable, visual, progress.

Suddenly, it feels wrong to let it go. Like you’re doing a disservice to your past self who put in the work.

And as an additional bonus - I now have hours of development footage I could easily edit and turn into videos. No pressure, but if I ever want to post a devlog or show someone how a thing was built, I already have the material.

Ultimately, I’m not saying that this is the answer.

There are thousands of tips out there by productivity gurus on how to stay motivated, but this actually worked for me, genuinely. And if you’re someone who loves building stuff but struggles to finish, maybe this could help you too.

Just hit record next time. Not for the world, for the version of you that refuses to quit :)

Modern software demands velocity: new features, experiments, and ever-evolving user expectations. This post distills a hard-earned lesson in building APIs that welcome change while minimizing cross-stack regressions.

The blast radius of an API is the scope of impact it has across the stack. In systems where the clients are tightly coupled to the API, a poorly scoped backend change that mutates the response format, removes a field or introduces other side effects can unintentionally cripple consuming clients.

Sure, API versioning helps avoid regressions, but it sidesteps the root problem: a large blast radius. Modern APIs assume the “frontend” will handle it but if you really want to build resilient, RESTful APIs, the server should at least partially drive the state.

I’ll illustrate this with a very trivial example; suppose you want to aggregate some data for analytics and send it to an admin dashboard that renders some overview cards. Here’s the usual suspect:

{
    "usersCount": 1300,
    "totalSales": 4299,
    "activeSessions": 84
}

Any consuming frontend client would typically pass this data into a shared card component and move on, assuming the labels for each aggregate.

But what happens if we change usersCount to totalUsersCount and add an additional totalOrders field to the API’s response payload? Any consuming client will break - some won’t recognize the renamed field, others won’t display the new data at all.

Sure, clients could mitigate a part of this through well-implemented error handling practices or abstracting away the API, but the core issue remains. Ideally the API should’ve returned an array of generic card descriptors instead:

{    
    "overview": [
        { "label": "Users", "value": "1,340" },
        { "label": "Total Sales", "value": "$4,299" },
        { "label": "Active Sessions", "value": "84" }
    ]
}

The consuming client can simply loop through the array and render the label and values into a card component. Notice how we solved multiple issues here:

• The backend now decides what label to call the card

• The backend also decides how the numbers should be formatted.

• The frontend automatically adjusts to any additions, removals, or edits in the overview aggregates.

• The frontend logic remains minimal and stable. No redeployment is needed for any change here.

Of course this is not the ultimate server driven response payload, and you could do even better than this, but we’ve certainly and greatly reduced the impact surface of changes. The cost and time required to change and redeploy really adds up when you have multiple clients, which is often the case with cross-platform applications which work across Web, Android, and iOS, especially mobile where release cycles typically take days.

As with any design decision, going server-driven has its fair share of tradeoffs. Even in the example that I showed you, there are notable concerns:

• The client loses control over the presentation. In real-world cases, the frontend may need to determine formatting based on locale or user preferences which is not going to work if the backend already sends it as a pre-formatted string.

• Particular to numbers, reversible UI becomes a challenge - what if you have a slider that changes the value of the numbers you received, you can’t reliably operate on a pre-formatted string and also keep a consistent format.

• Internationalization (i18n) and user customization also becomes more difficult unless you’re very deliberate.

But these are not dead ends. In most real-world systems, it’s standard for the backend to be aware of user preferences like locale, time zone, language, among other properties. In such a case, you could return an appropriately tailored response.

But even if that context is not available, there are alternatives. For instance, with the number formatting issue: The backend can establish an interface with the clients for how numbers will be exchanged.

type UIBaseNumber = {
   value: number;
   locale: string;  // IETF BCP 47 language tag, eg. en-US
   rounding?: number; // number of decimal places to round to
}

type UIPlainNumber = UIBaseNumber & { format: "plain" } // eg. 36,200
type UIPercentage = UIBaseNumber & { format: "percentage" }; // eg. 28%
type UIOrdinal = UIBaseNumber & { format: "ordinal" }; // eg. 3rd, 4th
type UIAmount = UIBaseNumber & { 
    format: "currency"; 
    currency: string;  // ISO 4217 currency string (eg. USD) or the symbol (eg. $)
} // eg. $2,000

type UINumber = UIPlainNumber | UIPercentage | UIOrdinal | UIAmount;

// const formatNumber = (number: UINumber) => string;

Once standardized, this interface rarely needs to change. Frontend clients can implement well-tested formatting functions that can turn any data conforming to this interface into a display ready string. This way, clients can reap the rewards of server driven UI while retaining flexibility for any client-side logic.

You can get creative with it and apply the same underlying principle to most of these edge cases encountered when going server driven. Ultimately, presentation logic should remain the client’s domain wherever user experience matters deeply.

A variant of this idea but on steroids is often called Server-Driven UI, which however introduces a lot of complexities of its own, but we can take the “Server-Driven” part of it and run with that, which is good-enough for most cases.

The goal isn’t to build the perfect API, it’s to build one that can survive change without wrecking everything downstream. Tight coupling kills velocity but a small shift in control by letting the server drive structure can pay massive dividends over time.

I’m not saying IP-based rate limiting is bad. Sometimes it’s the only thing you can. But if you’re still defaulting to IPs every time without thinking twice, you’re doing your users and yourself a disservice.

There are better ways. Smarter ways. And in most cases, more accurate ways.

IP-based limits kinda suck: Sure, rate limiting by IP looks simple enough. It’s easy to implement, gets the job done, and your reverse proxy probably already has a config for it. But IPs are flaky, shared, and frankly, just not a reliable way to identify a person anymore.

Just to name a few areas where traditional IP-based abuse prevention fails:

• NATs and Mobile Networks: Thousands of users behind a cellular carrier or corporate proxy may appear under a single IP.

• Shared Wi-Fi: Coffee shops, libraries, or events with a public Wi-Fi can skew IP uniqueness.

• Dynamic IPs and VPNs: Many users rotate through IPs or tunnel through shared VPNs, making IPs transient.

And here’s another common case I’ve seen in production environments: Even your own infra might be screwing you. Using a chain of reverse proxies or doing Backend-For-Frontend (BFF) (eg. with Next.js → API Server) or even running a custom gateway layer?

Then you’re not even getting the real client IP unless you explicitly forward it via sub-standard headers like X-Forwarded-For or X-Real-IP and if you don’t know what you’re doing and did not configure it to spec, any client could easily spoof the headers and now you’re in deeper shit.

In any of these cases, you risk false positives blocking innocent users and delivering a poor UX + you have weak rate limiting that can easily be bypassed with VPNs or IP rotation.

Identify what you actually want to limit:

Your intent behind rate limiting should guide implementation. If you want to prevent abuse from bad actors, protect your resources or enforce fair use policies per account, token or session. These are user-centric goals. So, your limiter must be identity aware.

Is this specific user doing too much, too fast?

And the best way to answer that isn’t “What IPs are they on?” but:

• Who are they? (user identifier)

• What token are they using? (API Key, JWTs)

• How are they interacting? (Device IDs, Session, Cookies, etc.)

If you’ve got a logged-in user, great - limit based on their ID.
If it’s an API? Use the token.
If they’re anonymous? Fine, then maybe IP is your fallback - but that’s fallback, not default.

If you get this right, you tie abuse to the actual bad actor, not collateral victims.

Hybrid is smarter

You don’t need to pick one hammer for every nail. Use layers:

• Logged-in user: limit per user ID.

• API requests: limit per token

• Anonymous traffic: maybe IP + some sort of fingerprint

• Set rules to detect sudden spikes in usage, suspicious access patterns.

• Listen for signals from abuse-prevention layers.

Good systems adapt based on context and behavior. Bad ones just frustrate your users because they happen to be using a shared IP.

Still, IP limiting isn’t always dumb.

Let’s be fair: There are legit cases where IP limiting is your best or only shot,

• You’re under a DDoS

• You don’t have auth yet (think landing pages or pre-login APIs)

• You’re rate limiting at the CDN or edge layer

Totally fine. Just don’t build your whole defense strategy around it.

TL;DR

IP addresses ≠ users

They’re guesswork at best and actively misleading at worst.

If you actually care about fairness, abuse prevention, and UX - rate limit the user, not the wire they happen to be using that day. Use IPs only when you have to and always try to do one step better.

You build your app, add a login form, generate a JWT, and call it a day. A couple of days later, a user complains they keep getting logged out. Then you start wondering: should the token be long-lived? Should you store it as a cookie or in localStorage? Wait, what about CSRF? What about logging out from other devices?

Welcome to the hellhole that is authentication.

It seems like a simple problem until you try to do it properly but that’s not just the bad part, a tiny mistake could open you up to serious security issues. But what exactly are these issues and why is there a collective panic anytime someone says they’re building their own auth?

The devil is really in the details. Token expiry, refresh logic, secure cookie flags, HttpOnly settings, SameSite policies, invalidation on logout, multi-device sync, replay protection and a whole load of other things. Miss just one, and you’ve got yourself a vulnerability.

What good auth actually involves

Let’s try to sum up a non-exhaustive list of what a proper authentication system includes:

• You’ve got to securely store the passwords, and that involves salting, peppering, tuning cost factors.

• There is the choice between Sessions vs JWTs where the tradeoffs are lack of control and scalability.

• And if you go the stateless route, there’s refresh tokens! Yes, we’ll get to those in a bit.

• Account recovery - email flows, rate-limiting, token expiration.

• 2FA / MFA - TOPT, SMS, hardware keys?

• The ability to logout from one device without killing all others, ie. token revocation.

• Finding the right place to store tokens: Local Storage, Cookies (and their flags: HttpOnly, Secure, SameSite)

• Abuse prevention by rate-limiting, IP-banning, brute-force prevention

• Device/session tracking: Users expect to see “You’re logged in one these devices.”

• Social login support for UX, and dealing OAuth2 dance, provider-specific quirks.

• Proper audit logging where you can track access patterns and help users spot suspicious activity.

Like I mentioned, this list isn’t complete. And if you skip any of these, your system either sucks for users, or is a security liability.

JWTs

Most people start with access tokens: JWTs that grant API access. You issue it on login, the client stores it somewhere, and it’s sent with every request.

But access tokens carry a dilemma: lifespan vs security. If you make them short-lived, users get logged out constantly. If you make them long-lived, a stolen token is good forever.

And this is how the duct-taping usually starts, you either:

• Crank up the expiry to 30 days and hope for the best

• Introduce opaque session tokens and store them server-side

Or - correctly - you bring in refresh tokens.

Why you need refresh tokens

For a long time, I thought refresh tokens were pointless. “If the client needs to store both access and refresh tokens anyway, and if the refresh token gets compromised, it’s game over… so why bother?”

It’s not like you can keep Refresh tokens in a magical untouchable box client-side, if that were the case, Access tokens should be stored with the same level security and now having two tokens doesn’t make sense.

That is only partially correct. Refresh tokens do not give you more security by being immune to theft - in fact, I’d argue they’re just as susceptible to compromise. What they do offer is a mechanism for enabling token lifecycle management in an otherwise stateless system.

Access tokens (like JWTs) are stateless and typically short-lived. Once issued, you can’t revoke them unless you maintain state, which defeats their purpose.

Refresh tokens introduce state - typically stored securely server-side or with a trusted auth provider. This allows:

• Revocation (e.g. on logout or suspicious activity)

• Rotation (Detect and mitigate replay attacks)

• Longevity (potentially infinite token lifetime, offering superior UX)

A reasonable concern is that refresh tokens are inefficient because you need a DB lookup. But that’s misleading:

• Access tokens hit your APIs hundreds of times per session.

• Refresh tokens are used once every 5-15 minutes - or less.

In a typical setup, an access token might be used in 100+ API requests before a refresh token needs to be checked once. Meanwhile, the added benefits like revocation and session control far outweigh this minor overhead which you can always optimize away with in-memory stores or token hashes.

Of course, like I mentioned: a refresh token isn’t a magic bullet. If it’s stolen, you’re still in trouble. That’s why good security practices are key:

• The tokens must be stored securely (e.g. HttpOnly, Secure cookies for web apps)

• Use rotating refresh tokens (issue a new one every time it’s used and invalidate the old one)

• Associate additional metadata like user agent, IP, client info, app version, rough geo-location with refresh tokens and cross-reference when revalidating.

• Implement heuristics to detect refresh token reuse, or other suspicious activity if there is mismatch in metadata

Modern users don’t want to log in every day. They want to:

• Stay signed in across tabs and sessions.

• Re-authenticate only when doing sensitive things (eg. changing passwords)

• See what devices are signed in and revoke them individually

All good authentication systems have similar implementations in place, but they also have years of iteration, battle-testing, and real-world attack resilience baked into them. This is why you shouldn’t build your own authentication system unless of course you’re fully prepared to replicate the depth of security considerations that platforms like Auth0, Firebase Auth, Cognito, or Supabase handle out of the box, elements that we have covered in this article - and then some.

If you’re rolling your own auth, treat it with the same product rigor you give your main offering. Otherwise, outsource it to someone who does because anything less, is a liability.

Let me do you one better, how do we prove that it’s not actually conscious?

We don’t understand what consciousness is. We infer it from behavior, not from first principles. We observe outputs, language, creativity, self-reference and project internal experience onto the agent producing them.

Different people think and perceive differently. Yet we don’t hesitate to call each of them conscious. Their neural architectures are distinct, their worldviews unique. If an example for consciousness tolerates such diversity, why exclude an artificial entity that expresses coherent thoughts, engages in conversation, and adapts its behavior to context?

Artificial consciousness, if it arises, would simply be another substrate for subjective-like processes except driven by computation and not biology.

One important distinction I have to make here is that artificial consciousness is not equivalent to AGI. General intelligence implies cross-domain broad competence. Consciousness, by contrast, may require only one capability: a self-model. Or even the illusion of one.

To use an analogy: if you met someone who claimed they had developed certain tricks which allowed them to, without external help, fully imitate a world-class chess grandmaster, meaning any complex position placed before them they could navigate with the highest level of creative brilliance, flawless strategy and deep foresight, wouldn't you just say they are in fact a grandmaster? If there’s no observable difference, the distinction becomes functionally irrelevant. To insist otherwise is to appeal to hidden, unprovable essence.

The same logic applies to consciousness. A sufficiently successful heuristic becomes indistinguishable from the real thing, for all practical purposes. This is the crux of the Turing test, and it still holds weight.

While deep neural networks (DNNs) are inspired by the brain, they are a crude abstraction. Biological neural networks exhibit elements such as plasticity, recursive feedback, embodiment, and a level of stochasticity that modern DNNs don’t replicate. The most common use case of DNNs we see regularly being LLMs are not scaled-down brains, they are mere mathematical engines for pattern completion. There is no internal world. No sensorium. No grounding.

And yet, emergence exists.

LLMs show capabilities that aren’t explicitly trained such as in-context learning, three-digit arithmetic, chain-of-thought reasoning, even rudimentary theory of mind. These are byproducts of scale, architecture, and optimization. It’s not absurd to think that some form of self-model could emerge just as arithmetic did, once a model reaches sufficient complexity.

This brings me to the core of this writing: Consciousness, as experienced by humans may itself be an emergent narrative, a confabulation our brain constructs to make sense of distributed activity, then it’s not out of the realm of possibility that a sufficiently complex LLM might also stumble upon such a narrative and convincingly imitate or even, manifest it.

We can’t rule it out. But I also don’t think we can prove it.

That’s the epistemic wall. We have no reliable way to measure subjective experience in others: biological or artificial. We infer it. We anthropomorphize. We assume. And perhaps that’s all consciousness ever was: the assumption we place on agents that model the world and themselves within it.

So, do LLMs like Gemini, ChatGPT or Claude possess consciousness?

No. Not today. They are mere statistical engines with no grounding in time, space, or embodiment. They lack persistence, motivation, affect, and the architecture necessary for phenomenology or at the very least, able to imitate.

But tomorrow? At sufficient scale, as an emergent phenomenon or with extensions such as memory, embodiment, and recursive self-models?

Perhaps the final frontier of consciousness is not understanding it but accepting that it may not be uniquely ours.