All three of those are true. I want to be clear about that up front, because this post is not a "JWT is insecure" post. JWT is a perfectly good, well-specified format, and the cryptography is fine.

The problem is something else entirely, and it usually doesn't surface until you're live: you can't take a JWT back.

What "stateless" actually means

A JWT carries its own claims. Your server signs a payload, hands it to the client, and from then on verification is a local operation — check the signature, check exp, trust the contents. No lookup, no shared store, no round trip.

That's genuinely elegant. It's also the exact property that causes the trouble, because "no lookup" and "I can change my mind about this token" are mutually exclusive. If the server never asks anything about the token, it has no place to record that it changed its mind.

So here's the sentence I wish tutorials led with: a signed JWT is valid until it expires, and nothing you do in between can stop that.

The concrete version

Say you issue a one-hour access token at 09:00. At 09:05 you decide that user is abusive and ban the account — flip is_active to false, feel good about it.

At 09:06 that same token still returns 200 OK on your protected endpoints. So does the one at 09:30. The token doesn't know anything happened, and neither does your verification code, because your verification code doesn't ask.

Three flavours of the same bug, all of which I've seen discussed by teams who were surprised by them:

• Logout doesn't log out. Clearing the token client-side is the whole logout implementation in most JWT tutorials. If a copy of that token exists anywhere else — a saved request, a second device, a proxy log — it still works.

• Bans have a delay. Whatever your access-token lifetime is, that's your worst-case window for an abusive account to keep operating.

• Permission downgrades don't take effect. You demote someone from admin to viewer. Their existing token still says "role": "admin", and if your middleware trusts the claim (which is the entire point of putting it there), they're still an admin until expiry.

That last one is the sharpest, because it's not a security bug in JWT — it's a design consequence. Claims are a snapshot of the moment the token was signed. Anything that can change after signing shouldn't be trusted from the token alone.

Every fix reintroduces the state

This is the part I find genuinely interesting. Each standard workaround is reasonable in isolation, and each one gives back the thing JWT was chosen for.

Short expiry plus refresh tokens. Cut access tokens to 5–15 minutes and issue a long-lived refresh token. Revocation now takes effect within one access-token lifetime. But refresh tokens must be revocable to be worth anything, which means they live in a database and get looked up on refresh. You now have server-side session state — you've just renamed it and added a rotation protocol on top.

A denylist of revoked tokens. Store the jti of every revoked token and check it on each request. This works and it's correct. It's also a store lookup on every single request, which is exactly what sessions do, except your lookup key is bigger and you're carrying signature verification as well.

A token version column. My favourite of the three, and still the same trade:

// user row: { id: 42, token_version: 3 }
// JWT payload: { sub: 42, tv: 3, role: "viewer", exp: ... }

async function verify(token) {
  const claims = jwt.verify(token, PUBLIC_KEY); // signature + exp
  const user = await db.users.findById(claims.sub); // ← the lookup is back
  if (!user || user.token_version !== claims.tv) {
    throw new Error("token revoked");
  }
  return user;
}

Bump token_version and every outstanding token for that user dies immediately. It's clean, it's easy to reason about, and I'd happily ship it. But look at the second line of that function: you are querying the database on every request to validate a token whose selling point was not querying the database on every request.

That's the honest summary. There is no way to make a JWT revocable without adding server-side state, because revocation is server-side state. You can move where it lives and how often you check it, but you can't make it disappear.

What a session actually costs in 2026

The mental model a lot of people carry is that sessions mean a heavy database join on every request. They don't.

A session lookup is a single point read by primary key against a store you've already got — Redis, or a Postgres table with an index on session_id. That's a sub-millisecond class of operation on a warm local Redis, and it's on the order of a millisecond or two against Postgres in the same region. I'm not going to quote you a benchmark I didn't run, but the shape is: it's one indexed key lookup, and it's almost never what's slow about your endpoint.

Compare that to the work you're doing anyway. Your handler probably fetches the user record to render anything useful, and your ORM probably issues three more queries you haven't looked at recently. Against that backdrop, the session read is noise.

"Stateless scales better" is a real argument. It is also, for the overwhelming majority of applications, a premature one. If you're running a handful of app servers behind a load balancer with one Redis, statelessness is buying you very little and costing you revocation.

Note the last row, because it cuts both ways. A shared session store is a dependency and it can go down. That's a real cost of sessions and I don't want to hand-wave it.

Where you put the token matters more than which token it is

Brief and precise, because this part attracts a lot of confident wrong advice.

For a browser app, put the credential in a cookie with all three flags set:

Set-Cookie: sid=<opaque-random-value>;
  HttpOnly;
  Secure;
  SameSite=Lax;
  Path=/;
  Max-Age=1209600

HttpOnly keeps JavaScript from reading it, which means an XSS payload can't simply exfiltrate it. Secure keeps it off plaintext connections. SameSite=Lax blocks it from most cross-site requests, which handles the common CSRF cases — though if you accept state-changing GETs or need SameSite=None for a cross-origin frontend, you still want explicit CSRF tokens.

Putting a JWT in localStorage gives up HttpOnly entirely. Any script that runs on your page — yours, a dependency's, an injected one — can read it and send it anywhere.

The standard reply is "but XSS is the real bug." That's true, and it's also not a defence — defence in depth means assuming one of your controls fails. That said, HttpOnly doesn't make you XSS-proof either: an attacker with script execution can still make authenticated requests as the user. What it stops is them walking away with a portable credential that keeps working after you've cleaned up. Meaningful, not complete.

Worth saying: a JWT can live in an httpOnly cookie. That's a fine setup. You just get the storage benefit without solving revocation.

Where JWT is genuinely the right tool

I don't want this to read as anti-JWT, because there are cases where it's clearly correct — and they all share one shape: the verifier can't or shouldn't call you.

• Service-to-service tokens. Short-lived, narrowly scoped, minted for a specific call. Nobody needs to revoke a token that lives for 90 seconds.

• Third-party API access. A partner validating your token with a published public key, with no path to your session store.

• Federated identity and OIDC ID tokens. This is what the spec was designed for. An identity provider asserts something, a relying party verifies the signature. The whole model depends on offline verification.

• Signed single-use links. Password reset, email verification, signed download URLs. Here short expiry isn't a workaround — it's the entire security property you want.

The middle ground most teams land on

After all that, the setup I'd reach for by default isn't exotic:

Opaque session token in an httpOnly cookie for your own first-party web and mobile clients. Revocation is a delete. Logout works. Role changes apply immediately. One indexed lookup per request.

Short-lived JWTs only at the boundary where another service has to verify without calling you. Minutes, not days, and scoped to what that service actually needs.

That's roughly what a well-configured Laravel Sanctum setup gives you, incidentally — opaque database-backed tokens for your own app, which is why we used it on Puratan Ayurveda rather than reaching for JWT out of habit.

My personal take

I think JWT got popular for a reason that has almost nothing to do with its actual strengths: it felt like the modern choice, and sessions felt like the thing PHP did in 2009.

But statelessness isn't free. You pay for it in revocation, and revocation is not an edge case — it's logout, bans, role changes, and every incident response where step one is "cut off that session." Those are core product features, not exotic requirements.

So my rule is simple. If the thing verifying the token can call your server, use a session. If it can't, use a JWT, keep it short-lived, and be honest that anyone holding a copy is authenticated until it expires. Pick based on who's doing the verifying — not on which one sounds more scalable.

The short version

• A signed JWT is valid until exp. Logout, bans, and role changes don't affect an already-issued token.

• Every revocation fix — refresh tokens, denylists, token-version columns — adds back server-side state.

• A session lookup is one indexed key read in Redis or Postgres. It's rarely your bottleneck.

• Use HttpOnly + Secure + SameSite cookies. localStorage exposes the token to any XSS on your page.

• JWT is the right call for service-to-service calls, third-party verification, OIDC, and signed one-off links.

• Sensible default: opaque session cookie for your own app, short-lived JWT only where another service must verify offline.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

It looks impressive. It looks like the architecture diagrams in the conference talks. And it is, for a team that size, mostly a liability.

Here's the thing nobody says out loud when that diagram gets drawn: every box on it is a deployment. It's also a backup policy, a restore procedure you have hopefully tested, a monitoring dashboard, a set of alert thresholds, a credential to rotate, an upgrade path, a failure mode at 3am, and — the expensive one — a thing that can silently disagree with the other five boxes.

I want to make the case that Postgres already does a credible version of most of that. Not a better version. A credible one, which for a small system is the correct trade.

Caching: an UNLOGGED TABLE is genuinely fast

Most applications that say "we need caching" mean: there are a few thousand rows that get read constantly and change rarely, and recomputing them is annoying.

Postgres has a purpose-built thing for exactly this. An unlogged table skips the write-ahead log entirely. That makes writes dramatically cheaper, at the cost of the table being truncated if the server crashes — which for a cache is not a bug, it's the definition.

CREATE UNLOGGED TABLE cache_entries (
    key         text PRIMARY KEY,
    value       jsonb NOT NULL,
    expires_at  timestamptz NOT NULL
);

CREATE INDEX ON cache_entries (expires_at);

-- write / overwrite
INSERT INTO cache_entries (key, value, expires_at)
VALUES ('dashboard:org:42', '{"revenue": 91200}'::jsonb, now() + interval '5 minutes')
ON CONFLICT (key) DO UPDATE
    SET value = EXCLUDED.value,
        expires_at = EXCLUDED.expires_at;

-- read
SELECT value
FROM cache_entries
WHERE key = 'dashboard:org:42'
  AND expires_at > now();

That's a primary-key lookup on a table that's almost certainly fully in memory. It is fast in a way that will surprise you if you've only ever thought of Postgres as "the slow durable thing".

Being fair to Redis: it wins decisively on raw operations per second, on the data structures Postgres doesn't have (sorted sets, HyperLogLog), on pub/sub, and on atomic counters under heavy contention. Those are real advantages. They are just not what most teams mean when they say the word "caching".

Full-text search: tsvector plus a GIN index

This is the one people underestimate most. Postgres full-text search is not a toy. You get stemming, stop words, ranking, prefix matching and multi-column weighting, all in the query planner you already understand.

ALTER TABLE articles
ADD COLUMN search_vector tsvector
GENERATED ALWAYS AS (
    setweight(to_tsvector('english', coalesce(title, '')), 'A') ||
    setweight(to_tsvector('english', coalesce(body,  '')), 'B')
) STORED;

CREATE INDEX articles_search_idx ON articles USING GIN (search_vector);

The generated column keeps itself in sync on every insert and update — no trigger to write, no drift, no reindex job. Then the query:

SELECT id,
       title,
       ts_rank(search_vector, query) AS rank
FROM articles, websearch_to_tsquery('english', 'postgres queue locking') AS query
WHERE search_vector @@ query
ORDER BY rank DESC
LIMIT 20;

websearch_to_tsquery is the one to reach for, because it parses the syntax users actually type — quoted phrases, or, a leading minus to exclude. And ts_rank gives you real relevance ordering, weighted by the setweight calls above so a title match beats a body match.

My honest read on the ceiling: this holds up well into the millions of rows on ordinary hardware. I'm deliberately saying "well into the millions" rather than quoting a number, because the real limit depends on your document sizes, your update rate and how many filters you stack on top. Test it against your own data rather than trusting anyone's headline figure, mine included.

Elasticsearch earns its keep when relevance tuning becomes an ongoing product activity — synonyms, custom analyzers, per-language stemming, faceted navigation across large result sets, typo tolerance you actively tune. If someone on your team is going to spend real time on search quality, you want the tool built for that. If search is a box in the header that needs to find the right thing, Postgres is fine.

Queues: FOR UPDATE SKIP LOCKED is a real pattern

SKIP LOCKED arrived in Postgres 9.5 and it quietly solved the "you can't build a queue on a database" objection. It lets a worker claim rows while stepping over rows another worker has already locked, with no contention and no lost jobs.

CREATE TABLE jobs (
    id           bigserial PRIMARY KEY,
    payload      jsonb NOT NULL,
    status       text NOT NULL DEFAULT 'pending',
    run_after    timestamptz NOT NULL DEFAULT now(),
    attempts     int NOT NULL DEFAULT 0,
    locked_at    timestamptz
);

CREATE INDEX jobs_claim_idx ON jobs (run_after)
WHERE status = 'pending';

And the claim query — this is the whole trick:

UPDATE jobs
SET status = 'running',
    locked_at = now(),
    attempts = attempts + 1
WHERE id IN (
    SELECT id
    FROM jobs
    WHERE status = 'pending'
      AND run_after <= now()
    ORDER BY run_after
    FOR UPDATE SKIP LOCKED
    LIMIT 10
)
RETURNING id, payload;

Run twenty workers against that and each one gets a disjoint batch. No double processing, no polling storm, no separate broker. And because it's the same transaction as your business data, you get something an external broker cannot give you for free: enqueue a job and write the row it depends on atomically. Either both happen or neither does.

That property is worth more than most teams realise. A huge share of "the job ran before the record was committed" bugs simply cannot occur in this design.

JSON documents and analytics, briefly

Two more that follow the same shape.

jsonb covers most "we need Mongo" cases. You get schemaless columns, containment operators, path queries and GIN indexing on the whole document:

CREATE INDEX events_props_idx ON events USING GIN (properties jsonb_path_ops);

SELECT * FROM events WHERE properties @> '{"plan": "pro", "source": "referral"}';

The thing you keep, that a separate document store takes away, is joining that document to your relational data in one query.

Time series and analytics are further than people expect too. Window functions handle running totals and rankings. generate_series fills gaps so your chart doesn't skip empty days. Materialized views precompute the expensive rollups on a schedule. That combination carries a dashboard a very long way before a specialist columnar store starts paying for itself.

The real cost isn't the license

Every one of these tools is free to download. That's not where the money goes.

The cost is operational surface. Concretely, per additional datastore:

That last row is the killer. With one store, your data is either right or wrong. With two, it can be right in one and stale in the other. With six, the number of pairs that can disagree grows quadratically — six stores means fifteen pairs. Every one of those pairs is a class of bug that only shows up in production, usually as "the search results show a product we deleted."

You don't debug those quickly. You debug them by reasoning about two systems at once, at night.

When each tool genuinely earns its place

I don't want to be the person telling you Postgres does everything. It doesn't. Here's my honest read on when to actually split, with a concrete signal for each.

Redis earns it when you have very high-throughput ephemeral state — rate limiting, session counters, leaderboards, presence, pub/sub fan-out to many subscribers. You'll know because your cache writes have become a meaningful share of your Postgres write load, or because you're doing tens of thousands of counter increments a second and seeing lock contention on a single hot row. That's the signal. Not "we should probably cache things."

Elasticsearch earns it when search relevance is the product. Marketplaces, job boards, documentation portals, anything where a bad ranking loses a sale. You'll know because someone is filing tickets about result quality specifically, you want synonyms and typo tolerance and faceted counts across millions of documents, or you're supporting several languages with different analyzers. When search becomes a thing you tune weekly rather than a feature you shipped, move.

Kafka earns it when you need a durable, replayable event log consumed by several independent services at their own pace. You'll know because you want to add a new consumer and have it read the last thirty days of history from the beginning — that single requirement is the honest test.

And that Kafka one deserves emphasis, because it's the most commonly mis-picked tool of the three. Kafka is a log, not a queue. Many teams reach for it wanting "background jobs with retries" and end up hand-building consumer groups, offset management and dead-letter handling — reimplementing a job queue on top of something that was never a job queue. If what you want is "run this task later, retry on failure", SKIP LOCKED or a proper broker is the closer fit.

Starting on Postgres does not trap you

This is the argument I find most convincing, and it's the one that gets skipped.

The fear is that starting simple means a painful rewrite later. In practice it's the opposite. Moving one workload out of Postgres is a bounded project with a clear definition of done. Move search to Elasticsearch: you already know your query shapes, your document structure and your relevance requirements, because you've been running them in production. You dual-write, you compare results, you cut over, you delete the old code. Two weeks, maybe four, and it ends.

Running six systems from day one is not a project. It's an ongoing tax, paid every sprint, by everyone, forever — and paid at your least experienced moment, when you have the least idea which of those systems you'll actually need.

You're also making the extraction easier by waiting. The team that migrates search after two years of running it in Postgres knows exactly what good relevance looks like for their data. The team that chose Elasticsearch on day one is guessing at analyzer configuration for a product that doesn't exist yet.

My personal take

I think the six-box diagram is mostly a status object. It signals seriousness. It looks like what real engineering is supposed to look like, and there's a quiet fear that a diagram with two boxes means you're not building anything real.

But the actual engineering skill on display in a two-box architecture is usually higher. Knowing that SKIP LOCKED exists, that unlogged tables are a real cache, that a generated tsvector column keeps itself in sync — that's more specific knowledge than knowing Redis is fast.

We're a small studio. The one product we've shipped end to end, an Ayurvedic e-commerce platform on Angular and Laravel, runs on a single relational database, and every time I've been tempted to add a second store the honest answer was that I wanted the diagram, not the capability.

So my rule is simple. Add the specialist store when Postgres has actually stopped being good enough at the thing, with a metric you can point to. Not when you imagine it might. The imagined version of that moment arrives about two years before the real one, and everything you build in between is paid for twice.

The short version

• Six datastores means six deployments, six backup policies, six runbooks — and fifteen pairs that can disagree.
• UNLOGGED TABLE is a genuinely fast cache; most apps' cache is a few thousand rows.
• tsvector + a GIN index gives real ranking and stemming, and holds up well into the millions of rows.
• SELECT ... FOR UPDATE SKIP LOCKED is a correct, battle-tested queue — and it's transactional with your business data.
• jsonb with GIN covers most "we need Mongo"; window functions and materialized views cover most early analytics.
• Redis wins on throughput and pub/sub. Elasticsearch wins when relevance is the product. Kafka wins when you need a replayable log — which is not a job queue.
• Extracting one workload later is a bounded project. Running six from day one is an unbounded tax.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

Instead you find eight lines of perfectly ordinary code. It's clean. It's readable. You'd approve it in a review without a second thought.

That's the thing about N+1 queries. They don't look like bugs. They look like good code.

What an N+1 actually is

Say you have a /posts endpoint that returns the 50 most recent posts, each with its author's name.

public function index()
{
    $posts = Post::latest()->take(50)->get();

    return PostResource::collection($posts);
}

And the resource:

public function toArray($request)
{
    return [
        'id'     => $this->id,
        'title'  => $this->title,
        'author' => $this->author->name,   // ← here
    ];
}

That single line is the whole problem.

Post::latest()->take(50)->get() is one query. It fetches 50 posts. Fine.

Then the resource runs once per post. Each time it hits $this->author, Eloquent notices the relation hasn't been loaded and quietly goes and fetches it. That's 50 more queries, one at a time, each one a round trip to the database.

select * from posts order by created_at desc limit 50
select * from users where id = 7 limit 1
select * from users where id = 3 limit 1
select * from users where id = 7 limit 1   -- yes, again
select * from users where id = 12 limit 1
... 46 more

1 + 50 = 51 queries for a page that needs two. And notice it re-fetches user 7 twice, because each lazy load is independent — Eloquent has no idea it already has that row in memory.

That's the N+1: one query to get the list, then N queries to get something related for each item.

Why it survives every code review

Here's what makes this bug different from most bugs: there is nothing wrong with the code.

$post->author->name is exactly how you're supposed to use an ORM. That's the whole selling point — relations feel like object properties. The abstraction is doing its job beautifully, right up until the moment it isn't.

There's no error. No warning. No lint rule fires. The tests pass, because your test fixture has three posts.

And that's the second half of it: N is small in development and large in production. You seed five records locally, the endpoint returns in 40ms, and you ship. Six months later there are 5,000 records, someone bumps the page size to 100, and the same code is making 100 sequential round trips per request. At 2ms per round trip that's 200ms of pure latency doing nothing but waiting.

The bug didn't appear. It was always there. Your data just grew into it.

Multiply by concurrent users and you get the classic symptom: the app is fine at 10 users and falls over at 200, and your database CPU graph looks like a wall.

The fix: tell the ORM what you need up front

Eager loading. You say in advance which relations you're going to touch, and the ORM fetches them all in one extra query using a WHERE IN.

$posts = Post::with('author')
    ->latest()
    ->take(50)
    ->get();

Two queries. Total.

select * from posts order by created_at desc limit 50
select * from users where id in (7, 3, 12, 41, 5, ...)

Same output, same resource code, 51 queries down to 2. You can load several relations at once:

Post::with(['author', 'comments', 'tags'])->get();

That's four queries — one for posts, one each for authors, comments and tags — regardless of whether you're returning 50 posts or 5,000.

Every mature ORM has this. Different spelling, same idea:

If you want it enforced rather than remembered, Laravel lets you fail loudly the moment anything lazy-loads:

// AppServiceProvider::boot()
Model::preventLazyLoading(! app()->isProduction());

In dev and test that throws a LazyLoadingViolationException the instant you touch an unloaded relation. In production it stays off, so you get a slow page rather than a 500. I turn this on in every new project now — it turns an invisible performance bug into a loud test failure.

The nested trap

This is the one that got me the most times. You fix an N+1, feel good about it, and immediately create another one a level down.

$posts = Post::with('comments')->get();   // fixed the comments N+1

foreach ($posts as $post) {
    foreach ($post->comments as $comment) {
        echo $comment->user->name;        // ← new N+1, one per comment
    }
}

comments is eager loaded. comments.user is not. So now instead of one query per post, you get one query per comment — which is usually a much bigger number than the one you started with. Congratulations, you made it worse.

The fix is dot notation:

Post::with('comments.user')->get();

Three queries: posts, comments for those posts, users for those comments. Rails: includes(comments: :user).

The rule I use: every relation you touch anywhere in the render path needs to appear in the with(). Not just the ones in the controller — the ones in your resource classes, your Blade partials, your accessors. Especially accessors, because a computed attribute quietly touching a relation is the sneakiest version of this bug there is.

Over-fetching: the trap on the other side

Eager loading is not free, and "just add with() to everything" is its own bug.

with('comments') on 50 posts that each have 400 comments pulls 20,000 rows into PHP memory to render a page that shows a comment count. You traded 51 fast queries for 2 queries and an out-of-memory error. That's not a win.

Three things I reach for instead:

If you only need a number, use a count. No rows loaded at all.

Post::withCount('comments')->get();
// then: $post->comments_count

If you only need a few columns, ask for a few columns. Include the foreign key, or the relation silently breaks — Eloquent needs user_id on comments to match them back to posts.

Post::with([
    'author:id,name',
    'comments:id,post_id,body',
])->get();

If you only need a slice, constrain the relation.

Post::with(['comments' => fn ($q) => $q->latest()->limit(3)])->get();

And the honest fourth option: sometimes the right answer isn't eager loading at all, it's a join with an explicit select, or a dedicated read query that returns exactly the shape the endpoint needs. ORMs are excellent until you're fighting them, and a hand-written query for one hot endpoint is not a failure of engineering.

How to actually catch these

You will not spot N+1s by reading code. I've tried. The code looks fine — that's the entire premise of this post. You catch them by counting.

Log queries in dev. Cheap and immediate:

DB::listen(fn ($q) => logger()->debug($q->sql, ['time' => $q->time]));

Fifty near-identical lines in your log is the signature. Once you've seen it, you recognise it instantly.

Use the tools. Laravel Debugbar puts a live query count in the corner of every page. Rails has Bullet, which pops a warning telling you exactly which includes you forgot. Prisma logs queries with log: ['query']. Django Debug Toolbar does the same job. All of them make the invisible visible.

Assert query counts in tests. This is the one that actually stops regressions, because it fails in CI rather than in production:

public function test_posts_index_stays_within_query_budget(): void
{
    Post::factory()->count(50)->create();

    $queries = 0;
    DB::listen(function () use (&$queries) { $queries++; });

    $this->getJson('/api/posts')->assertOk();

    $this->assertLessThan(6, $queries);
}

Seed 50 records, not 3. A test with three fixtures passes happily at 4 queries whether the code is O(1) or O(N). The whole point is to make N big enough that a regression is obvious.

Then set a budget and hold the line: no endpoint may exceed N queries. Pick a number — 10 is a reasonable starting point for most read endpoints — and put it in CI. Budgets work because they're boring and automatic, and nobody has to remember anything.

The honest caveat

Not every query inside a loop is a bug.

If you're loading five configured payment providers, or the seven days of a week, or three tenant settings — N is bounded, small, and never going to grow. Five extra queries against an indexed primary key is a couple of milliseconds. Rewriting that into a clever eager-load makes the code harder to read and buys you nothing you can measure.

The failure mode I actually see more often in review isn't the missed N+1 — it's someone eager-loading six relations "to be safe" on an endpoint that uses two of them, then wondering why the response got slower.

Optimise the endpoints you can measure. Find the slow one, count its queries, fix that. Then go back to writing features.

My personal take

What I find interesting about N+1 is that it's not really a database problem. It's an abstraction problem.

ORMs sell you the idea that $post->author is just a property. It isn't — it's a network round trip wearing a property's clothes. Ninety-five percent of the time that illusion is exactly what you want, and it makes the code genuinely nicer to write and read. The other five percent, it hands you a 51-query endpoint that no reviewer will ever flag.

So I don't think the lesson is "be careful with ORMs." The lesson is that you can't reason about this by reading — you have to measure it. Query count is the single cheapest performance metric in a web app. It's one number, it's trivially available, and it correlates with slowness better than almost anything else you can check that fast.

We had a version of this on the Puratan Ayurveda build — a product listing that felt sluggish and turned out to be doing per-product lookups for related data. It wasn't clever to fix. It was one with() call. That's usually how this goes: the diagnosis is the hard part, the fix is one line.

Put a query counter in front of your face in dev, put a budget in CI, and this whole class of bug mostly stops happening to you.

The short version

• An N+1 is 1 query for the list plus N more for each item's relation. 50 posts + authors = 51 queries where 2 would do.
• It passes review because the code is idiomatic and correct — it only hurts once N grows in production.
• Fix it with eager loading: with('author') in Laravel, includes in Rails, include in Prisma, relations in TypeORM.
• Watch the nested case: with('comments') then touching $comment->user just moves the N+1 down a level. Use with('comments.user').
• Don't over-correct. Use withCount() for numbers, with('author:id,name') for specific columns, constrained closures for slices.
• Catch it by counting: DB::listen in dev, Debugbar or Bullet locally, query-count assertions in tests with 50 seeded records, and a hard budget in CI.
• Turn on Model::preventLazyLoading() outside production so lazy loads fail loudly instead of silently.
• If N is genuinely small and bounded, leave it alone. Optimise what you can measure.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

I remember staring at it thinking: what is in there? I didn't write 1.2GB of anything.

That question is worth answering, because the answer is almost always the same three things, and all three are fixable in about twenty minutes. This post is that walkthrough — the naive Dockerfile, why it's so big, and the version I'd actually ship.

First, let's find out what's actually in there

Here's the Dockerfile almost everyone writes first. It works. It's also the problem.

FROM node:20

WORKDIR /app
COPY . .
RUN npm install
RUN npm run build

CMD ["node", "dist/main.js"]

Nothing here is wrong, exactly. It builds, it runs, it ships. But four things are quietly inflating it:

• node:20 is a full Debian image. Around 1.1GB before you add a single line of your own code. It ships a complete Linux userland — apt, Python, build toolchains, man pages. You are shipping a general-purpose operating system to run one JavaScript process.
• npm install installs devDependencies. TypeScript, ESLint, Jest, your entire test suite, webpack or Vite, all of it. None of it runs in production. All of it ships.
• COPY . . copies everything. Including .git — which on a busy repo can be hundreds of megabytes of history — plus your local node_modules, .env files, screenshots, logs, coverage reports.
• The build tooling stays in the final image. You needed TypeScript to produce dist/. You do not need TypeScript to run dist/. But it's still in there.

That last bullet is the one worth sitting with. Your application code is often the smallest thing in your application image.

Fix one: stop copying junk in

This is the cheapest win and most people skip it. Create a .dockerignore next to your Dockerfile:

node_modules
.git
.env*
dist
coverage
*.log
.vscode
README.md

Two reasons this matters more than it looks.

The obvious one: less stuff copied, smaller image.

The non-obvious one: COPY . . invalidates your build cache every time any file changes. Edit the README, and Docker re-runs your entire npm install. Ignoring the noisy files means your cache survives longer, and your builds get dramatically faster — which you'll feel on every CI run, not just once.

Also, .env in a Docker image is a real security problem. Anyone who can pull that image can read your secrets with docker history. .dockerignore is the simplest guard against doing that by accident.

Fix two: multi-stage builds

This is the big one. The idea is simple: build in one image, run in a different, much smaller one, and copy only the finished output across.

# ---- build stage ----
FROM node:20-alpine AS builder
WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

# ---- runtime stage ----
FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force

COPY --from=builder /app/dist ./dist

USER node
CMD ["node", "dist/main.js"]

Everything in the builder stage — TypeScript, the full dependency tree, source files, build caches — is thrown away. Only dist/ crosses the boundary.

A few details in there that actually matter:

• npm ci, not npm install. It installs exactly what's in your lockfile, and it's faster. npm install can silently update your lockfile mid-build, which means your CI image and your teammate's image aren't the same thing.
• --omit=dev in the runtime stage. This is where most of the savings live. On a typical TypeScript API, devDependencies are frequently larger than production dependencies.
• USER node. Containers run as root by default. There's no reason your Node process needs to be root, and it costs you one line not to be.
• ENV NODE_ENV=production — some libraries check this at runtime and skip development-only work.

Fix three: pick a smaller base image

Rough sizes for the base image alone, before your code:

Alpine is my default, but I want to be honest about the trade-off, because "just use Alpine" advice usually skips it.

Alpine uses musl libc instead of glibc. Most things don't care. Some things care a lot — native modules that ship prebuilt glibc binaries have to compile from source instead, which makes builds slower and occasionally breaks outright. sharp, canvas, some database drivers, and anything wrapping a C library are the usual suspects. If you hit that wall, node:20-slim is the sensible retreat: still a fraction of the full image, still glibc.

And distroless is worth knowing about even if you don't use it. It has no shell, no package manager, nothing but the runtime. Great security posture, genuinely unpleasant to debug — you can't docker exec into a shell, because there isn't one.

What the numbers actually look like

Ballpark figures for a typical TypeScript Express or Nest API — your mileage will vary with your dependency tree, but the shape holds:

Which brings me to a claim I want to push back on. You'll see posts promising sub-50MB Node images. Be sceptical. The Node runtime itself is roughly 120MB on Alpine — you cannot get under that and still run Node. If someone's showing you 40MB, they've either switched to a compiled runtime like Bun or Go, or they're quoting the compressed registry size rather than the on-disk size. Both are fine things to do. Neither is the same claim.

180MB is a realistic, honest target for a Node service. Chasing lower usually means fighting your runtime rather than fixing your image.

The layer-order trick that speeds up every build

One more thing, and it's about time rather than size, but it's the change I appreciate most day to day.

Docker caches each instruction as a layer. When one layer changes, every layer after it rebuilds. So this ordering is quietly expensive:

COPY . .
RUN npm ci        # ← re-runs on EVERY code change

And this one isn't:

COPY package*.json ./
RUN npm ci        # ← only re-runs when dependencies change
COPY . .

Same instructions, different order. In the second version, editing a controller doesn't reinstall your dependencies — Docker reuses the cached layer and skips straight to copying your source. On a large dependency tree, that's the difference between a two-minute CI build and a fifteen-second one.

The rule of thumb: put the things that change least at the top of your Dockerfile, and the things that change most at the bottom. Your dependencies change weekly. Your source changes hourly. Order accordingly.

My personal take

Image size is one of those problems that feels cosmetic until it isn't.

A 1.2GB image is slower to push, slower to pull, slower to cold-start on every autoscaling event, more expensive to store across every tag you keep, and — the part people underrate — it has a much bigger attack surface. Every package in that Debian base is something a scanner can flag and something you're nominally responsible for patching. Shipping a compiler and a package manager into production isn't just wasteful; it's a bigger blast radius if something does get in.

None of the fixes above are clever. Multi-stage builds, a smaller base, a .dockerignore, and sensible layer ordering. It's maybe twenty minutes of work and it's the highest-leverage twenty minutes in most Dockerfiles I've read.

If you take one thing from this: go run docker images right now and look at the number. If it starts with a 1, you already know what to do.

The short version

• Full node:20 is ~1.1GB before your code. node:20-alpine is ~135MB. That's most of your problem.
• Multi-stage builds let you compile with the full toolchain and ship only the output.
• npm ci --omit=dev in the runtime stage — devDependencies are often bigger than prod ones.
• A .dockerignore keeps .git, node_modules and .env out, and keeps your build cache alive.
• Copy package*.json and install before copying source, so code changes don't reinstall dependencies.
• ~180MB is an honest target for a Node service. Sub-50MB claims are usually a different runtime or a compressed size.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

A single developer could build frontend applications, backend services, APIs, databases, authentication systems, and deployment pipelines.

That skillset remains incredibly valuable today.

However, the rapid adoption of AI tools is changing what developers spend their time doing.

Developers are no longer responsible only for writing code.

Increasingly, they are responsible for orchestrating workflows between AI models, business systems, APIs, databases, and automation platforms.

This shift is creating a new type of engineer.

The AI Workflow Engineer.

Why Full-Stack Development Is Changing

Traditional full-stack development focused on building software applications.

A typical workflow looked something like this:

• Frontend

• Backend

• Database

• APIs

• Deployment

Developers wrote most of the code manually and controlled every layer of the application stack.

Today, AI tools can generate UI components, API endpoints, database schemas, documentation, and even test cases.

As a result, the bottleneck is no longer writing code.

The bottleneck is connecting systems together and designing workflows that produce reliable outcomes.

Developers are spending less time coding every feature from scratch and more time coordinating how different systems interact.

What Is An AI Workflow Engineer?

An AI Workflow Engineer focuses on designing how AI systems interact with the rest of the technology ecosystem.

Instead of simply building features, they build processes.

A modern AI workflow may include:

• Large Language Models

• Vector Databases

• APIs

• Business Systems

• Automation Tools

• Memory Systems

• MCP Servers

The engineer's responsibility is ensuring all of these components work together efficiently.

This requires a different mindset.

The goal is no longer writing every line of code.

The goal is creating intelligent systems that can perform tasks autonomously and reliably.

The New Skills Developers Need

As AI becomes integrated into software development, the most valuable skills are evolving.

Developers still need strong programming fundamentals.

But they also need to understand:

• Context Engineering

• AI Agents

• MCP

• Workflow Design

• System Architecture

• Automation Platforms

• Prompt Design

• Data Pipelines

The developers who combine software engineering knowledge with AI workflow design will have a significant advantage over those who focus only on code generation.

Coding remains important.

But understanding how systems communicate is becoming even more valuable.

What Happens Next?

The future of software engineering is unlikely to be a choice between developers and AI.

Instead, it will be about developers who know how to leverage AI effectively.

Companies are already looking for engineers who can integrate AI into existing workflows, automate repetitive tasks, and build intelligent systems that connect with real-world business processes.

The developers who adapt to this shift will be positioned to build the next generation of software products.

The title on the job description may still say "Software Engineer."

But the responsibilities are increasingly starting to look like those of an AI Workflow Engineer.

The Short Version

• Full-stack development remains valuable, but the role is evolving.

• AI tools are reducing the amount of manual coding required.

• Developers are increasingly responsible for orchestrating workflows between AI and business systems.

• AI Workflow Engineering combines software engineering, automation, architecture, and AI.

• Skills like MCP, Context Engineering, AI Agents, and workflow design are becoming increasingly important.

• The future belongs to developers who can connect systems, not just write code.

Written by the TechKis team — an AI-first engineering studio. Building AI products, web platforms, mobile apps, and custom software. Need help bringing your idea to life? Let's build it together. techkis.tech

Short for Model Context Protocol, MCP is rapidly becoming one of the most important standards in modern AI development.

At first glance, it may look like just another protocol. But many engineers believe MCP could fundamentally change how AI systems interact with software, databases, APIs, and business tools.

To understand its significance, imagine a world where every device required a completely different cable. Connecting a monitor, keyboard, charger, and external drive would require separate standards and custom adapters.

That problem was largely solved by USB-C.

MCP is attempting to solve a very similar problem for AI applications.

Why AI Integrations Became So Complicated

One of the biggest challenges in AI development today is connectivity.

Large language models are incredibly powerful, but they know nothing about your company's databases, GitHub repositories, ticketing systems, documentation platforms, or internal APIs.

To make AI useful, developers need a way to connect these systems together. Historically, this meant building custom integrations for every service an AI application needed to access.

A GitHub connector.

A Slack connector.

A Jira connector.

A CRM connector.

A database connector.

Individually, these integrations seem manageable. But as organizations adopt more AI-powered tools, the number of integrations grows rapidly.

The result is increased technical complexity, duplicated engineering effort, and systems that become difficult to maintain and scale.

What Exactly Is MCP?

Model Context Protocol (MCP) introduces a standardized way for AI systems to communicate with external tools and services.

Instead of building custom integrations for every application, developers can expose capabilities through MCP-compatible servers. The AI system only needs to understand a single protocol: MCP.

Once connected, it can discover available resources, access information, execute actions, and interact with multiple systems through a common interface.

This dramatically reduces integration complexity while making AI applications easier to build, maintain, and scale.

More importantly, MCP creates interoperability. Developers can build integrations once and reuse them across multiple AI applications instead of reinventing the same connections repeatedly.

This is the same reason USB-C became so successful in hardware.

When everyone follows the same standard, everything becomes easier to connect.

And that's exactly what MCP aims to achieve for AI applications.

Why MCP Matters For AI Agents

The rise of AI agents is making protocols like MCP more important than ever.

Traditional chatbots are primarily designed to answer questions. AI agents, however, are built to take action.

They can create tickets, update documents, review code, trigger workflows, execute tasks, and coordinate multiple tools simultaneously.

To perform these actions effectively, agents need reliable access to external systems. Without a standardized protocol, every new integration adds complexity, increases maintenance effort, and slows down development.

This is where MCP comes in.

MCP provides a common language between AI systems and the software ecosystem around them. It allows agents to discover capabilities, access resources, and interact with multiple tools through a consistent interface.

Instead of spending time building hundreds of custom integrations, developers can focus on creating smarter and more capable AI applications.

As AI agents become more autonomous, MCP is likely to become a foundational layer of the modern AI stack.

What Happens Next?

We're still in the early stages of MCP adoption.

Not every platform supports it yet, and not every organization has embraced it. However, the momentum behind MCP continues to grow as more companies look for reliable ways to connect AI systems with their existing software ecosystems.

The industry is rapidly moving toward AI-native applications, while AI agents are becoming more autonomous and capable of performing real-world tasks. To unlock their full potential, these systems need secure, standardized access to tools, services, databases, and business workflows.

This is where MCP becomes important.

The future of AI will not be determined only by how intelligent models become. It will also depend on how effectively those models can communicate, collaborate, and take action across the digital world.

Just as USB-C became a universal standard for hardware connectivity, MCP has the potential to become the universal standard for AI connectivity.

And that's exactly why so many developers are paying attention to it today.

The Short Version

• MCP stands for Model Context Protocol.

• It provides a standardized way for AI systems to connect with external tools and services.

• MCP reduces the complexity of building and maintaining custom integrations.

• It enables AI applications to discover, access, and interact with external systems more efficiently.

• The rise of AI agents is one of the biggest drivers behind MCP adoption.

• Many developers view MCP as the USB-C standard for AI applications.

Written by the TechKis team — an AI-first engineering studio. Building AI products, web platforms, mobile apps, and custom software. Need help bringing your idea to life? Let's build it together. techkis.tech

But once the app grows, the same question keeps coming back: should I use Context API or Redux Toolkit?

I've seen developers argue about this a lot. Some say Context is enough. Some say Redux is the proper way. Honestly, I don't think one answer fits every project. It depends on the size of the app, the type of state, and how often that state changes.

Context API is great when the state is simple

React Context is built into React — that's already a big advantage. No extra package, no additional setup, no separate store configuration. For simple shared data, Context works nicely: logged-in user info, the selected theme, language preference, basic app settings, small global values.

In these cases Context feels clean and lightweight. You create a provider, wrap your app, and use the value wherever you need it. Simple. And for many apps, that's enough.

But Context can become messy when the app grows

The problem starts when Context is used for everything — authentication state, cart state, filters, API data, form state, notification state, dashboard data. Suddenly you have multiple providers. State updates become harder to track. Components re-render more than expected. Debugging becomes annoying. And the app slowly becomes difficult to reason about.

That's where Context starts showing its limits. Not because Context is bad, but because it was never meant to become a full state management system for complex apps.

Redux Toolkit feels better for serious app state

Redux had a reputation for being heavy earlier — too much boilerplate, too many files, too many concepts. But Redux Toolkit changed that a lot. Now it feels much cleaner. You create slices, write reducers more easily, and manage async logic with createAsyncThunk or RTK Query. And most importantly, you get a predictable state flow.

That matters when your app gets bigger — ecommerce carts, dashboards, complex filters, user permissions, API-driven state, multi-step forms, large admin panels. In these cases Redux Toolkit feels more organized.

The biggest advantage of Redux Toolkit is structure

This is why I personally prefer Redux Toolkit for bigger applications. It gives structure. You know where state lives. You know how it changes. You can trace actions, debug with Redux DevTools, and separate logic into slices.

That makes the application easier to maintain, especially when multiple developers are working on the same project. Context can work, but Redux Toolkit gives discipline. And in real projects, discipline matters.

So which one do I prefer?

For small apps, I prefer Context API. It's simple, fast, no extra dependency, and no need to over-engineer.

But for medium or large applications, I prefer Redux Toolkit — especially when the app has multiple screens, API data, user roles, cart logic, filters, or shared state used in many places. Because once state becomes important to the product, I want something predictable, something easier to debug, something that doesn't become messy after six months. For that, Redux Toolkit feels safer.

My personal rule

I usually think about it like this:

• If the state changes rarely and is simple, Context is fine.
• If the state changes often, affects many components, or needs debugging, Redux Toolkit is better.

That simple rule avoids a lot of confusion. Because the real mistake isn't choosing Context or Redux — it's using the wrong tool for the wrong kind of state.

The short version

• Context API is best for simple shared values like theme, auth user, or language.
• Redux Toolkit is better for larger apps with complex and frequently changing state.
• Context is lightweight but can become messy when overused.
• Redux Toolkit gives better structure, debugging, and predictable state flow.
• My preference: Context for small apps, Redux Toolkit for serious production apps.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

That's usually the moment the real question shows up: should I just use a database queue, or is it time to move to RabbitMQ?

I've thought about this a lot while working on backend-heavy applications. And honestly, the answer usually depends less on what's "better" technically and more on what your application actually needs. Both work. They just solve slightly different problems.

Database queues are often the easiest place to start

For many applications, database queues are enough — especially in the beginning. If you're using something like Laravel queues backed by a jobs table, setup is straightforward. No extra infrastructure, no separate message broker, no queue server to manage. Everything stays inside the application environment, which makes development fast. And that simplicity matters.

For things like sending emails, OTP delivery, notifications, invoice generation, and small background jobs, database queues usually do the job perfectly fine. We sometimes overcomplicate things too early.

But as traffic grows, the database starts doing too much

This is where things begin to feel heavier. Your database is already handling user requests, inserts, updates, joins, reporting queries, and search filters. Then queue jobs get added on top, and suddenly the same DB is also responsible for processing background tasks.

That works for a while — until the queue volume increases. Then you start noticing jobs piling up, slower processing, delayed workers, increased DB load, and retries creating even more pressure. At that point the queue system itself becomes part of the performance conversation. And that's usually where RabbitMQ enters the picture.

RabbitMQ feels built for messaging from day one

RabbitMQ approaches the problem differently. Instead of storing jobs inside the database, it acts as a dedicated message broker. Its only job is moving messages between producers and consumers efficiently.

That separation helps a lot. Your app pushes a message, RabbitMQ handles routing, and workers consume it independently. The database stays focused on data; queue processing stays focused on messages.

That separation becomes valuable when your workload gets heavier — high-volume notifications, real-time event processing, order pipelines, multiple worker services, microservice communication, and external integrations happening continuously. This is where RabbitMQ starts feeling stronger.

The trade-off: RabbitMQ gives power, but adds complexity

This part matters. RabbitMQ is powerful, but it isn't free. You're adding more infrastructure, which means server setup, deployment config, monitoring, worker management, connection handling, retry strategy, dead-letter queues, and failure recovery.

Compared to database queues, that's definitely more to manage. So if your application only sends the occasional background email, RabbitMQ may actually be unnecessary overhead. And that's okay — not every project needs distributed messaging infrastructure.

So which one would I choose?

If I'm building a small to medium application, I'd usually start with database queues. Fast setup, easy maintenance, works well, and less infrastructure to think about.

If I'm building a high-volume system with heavy background processing, I'd lean toward RabbitMQ — especially when thousands of jobs are processed regularly, multiple services communicate with each other, queue throughput matters, the database load is already high, and reliable async messaging is becoming core to the platform.

My personal take

I don't see RabbitMQ and database queues as competitors. I see them as stages. Database queues are a great starting point. RabbitMQ becomes valuable when scale and complexity demand it.

A lot of teams jump to advanced infrastructure too early, and sometimes the simpler solution is the better engineering choice. At the same time, once your queue load becomes part of your bottleneck, a dedicated message broker can make a huge difference.

So for me the decision usually comes down to one question: is the queue just supporting the app, or is async processing becoming part of the system itself? That answer usually makes the choice clear.

The short version

• Database queues are simple, fast to implement, and great for many applications.
• RabbitMQ is built specifically for messaging and handles high-volume async processing better.
• Database queues work well for emails, notifications, and smaller background tasks.
• RabbitMQ becomes useful when scale, throughput, and service-to-service communication grow.
• If your current queue isn't causing problems yet, database queues may still be the right choice.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

So when I came across Google Antigravity, I was curious. At first I assumed it was just another editor with AI autocomplete built in. But the more I explored it, the more it felt like Google is thinking about development in a slightly different way. And that's what caught my attention.

(Quick context: Antigravity launched in public preview, free for individuals, and runs on macOS, Windows and Linux. It's built around Gemini 3 Pro but also supports Anthropic's Claude Sonnet 4.5 and OpenAI's GPT-OSS.)

It doesn't feel like just another IDE

Most IDEs still work the same way. You open files, write code, run terminal commands, debug something, fix it, repeat. AI usually sits beside that workflow as an assistant — maybe it completes code, maybe it writes a function, maybe it explains an error.

Antigravity feels like it's trying to move AI deeper into the workflow itself. Not just helping with code, but helping with the entire task. That difference sounds small, but the more you read into it, the bigger it gets.

The most interesting part: agent-first development

This is the part that stood out most to me. Google describes Antigravity as agent-first development, and honestly that explains it pretty well. Instead of AI helping with a line of code, the idea feels closer to AI helping with the job you're trying to complete.

For example: creating a new feature, updating multiple files together, debugging a failing implementation, running checks, and reviewing the generated output. There's even a dedicated "Manager" surface where you can spawn and watch several agents work in parallel, each with direct access to the editor, terminal and browser.

It feels less like autocomplete and more like having another developer inside the project with context. That's a pretty interesting direction.

It still feels familiar, which I like

One thing I noticed immediately: Google doesn't seem to be forcing developers into a completely new way of working. And that matters, because most developers already have workflows they're comfortable with — editor, terminal, Git, browser, docs, local environment. That workflow already works.

Antigravity feels more like an extra layer on top of that rather than asking you to replace everything. Personally, I think that makes adoption much easier. Good developer tools usually fit into your workflow. They don't fight against it.

The real test will be production projects

This is where I think every AI coding tool eventually gets tested. Demos always look clean. Real codebases usually aren't.

Production projects are messy. There's old code, temporary fixes, unclear naming, large folders nobody wants to touch, and half-finished documentation. That's where tools like this either become genuinely useful — or become something you open once and never come back to.

What I'm curious about is how Antigravity handles those real-world environments, because that's where developers actually spend their time.

My take after exploring it

I don't think Antigravity is trying to replace developers. And honestly, I don't think that's what most developers want anyway.

What feels more realistic is this: AI handles more of the repetitive movement around coding, and developers spend more time on decisions — architecture, reviewing, thinking through product and implementation. Less context switching, less jumping between tabs, less repetitive setup work. More actual building. That's the part I find interesting.

The short version

• Google Antigravity feels bigger than a normal AI code editor.
• It's focused on agent-first development, not only autocomplete.
• The goal seems to be helping developers complete tasks, not just write code.
• It still feels close to existing workflows, which makes it easier to approach.
• The real test will be how useful it becomes inside real production codebases.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

And honestly, I understand why. AI tools have improved fast, much faster than most people expected. You type a prompt and it writes code. You paste an error and it explains the issue. You ask for a component and it builds one, sometimes surprisingly well. Enough to make people stop and think: if AI can already do this, what happens next?

My short answer? No, but things are definitely changing

I don't think AI is replacing developers anytime soon. But I do think it's changing how development happens, and that's an important difference.

Because writing code is only one part of software development. Real development includes a lot more than syntax: understanding product requirements, deciding architecture, debugging strange production issues, handling trade-offs, thinking about performance, working with teams, and understanding what users actually need.

Most of that isn't "write code." It's judgment, context, experience, and sometimes even instinct. That part is much harder to automate.

AI is very good at generating code

That part is obvious now. Need a React component? AI can generate one. Need help with a SQL query? Usually fast. Need a boilerplate API structure? Done in seconds. Need test cases? Also possible.

For repetitive work, AI is genuinely useful — sometimes very useful. And if I'm honest, I use it too. A lot of developers do now. Not because we can't code without it, but because it speeds things up.

But generating code isn't the same as building software

This is where the conversation usually gets oversimplified, because code generation looks impressive. But software engineering isn't just output.

Real projects are messy. Codebases are messy. Requirements change halfway through development. Clients change priorities. Legacy code exists. Production bugs happen only on one server at 2 AM. Naming conventions make no sense. Documentation is incomplete. And business logic lives partly in code... and partly inside someone's head.

That's real software development. And AI still struggles there, because context matters more than code.

The role of developers is shifting

If anything, AI is changing where developers spend their time. Less time writing repetitive code. More time reviewing. More time designing systems. More time asking better questions. More time making decisions.

AI can generate options. Developers still decide which option is correct — and often which one is safest, fastest, cleanest, or easiest to maintain six months later.

That decision-making layer is still deeply human.

What I think actually happens next

My guess? AI becomes part of every developer workflow — kind of like Git, or Stack Overflow, or package managers. At first optional, then normal, then expected.

Developers who learn to use AI well will probably move faster, prototype faster, debug faster, and ship faster. Not because AI replaces them, but because it removes some of the repetitive friction around development. And the human part — thinking, deciding, building — becomes even more important.

The short version

• No, I don't think AI will replace developers anytime soon.
• AI is very good at generating code, especially repetitive code.
• But software engineering is much more than writing syntax.
• Context, architecture, debugging, business logic, and decision-making still need developers.
• AI will likely become a daily development tool, not a replacement for engineers.

Written by the TechKis team — an AI-first engineering studio. techkis.tech

That changed fast.

In 2026, AI tools aren't sitting on the side anymore. They're part of the daily workflow. And honestly, even if someone tells you they don't use AI while coding, there's a good chance they already have without thinking much about it. Autocomplete, debugging help, test generation, documentation, code review... AI has quietly become part of software development itself.

It started with autocomplete, but it's no longer just that

For a lot of developers, the entry point was simple. GitHub Copilot finishing a function. ChatGPT helping debug an error. Cursor rewriting some repetitive code. At first it felt like productivity support: useful, but optional.

Now it feels bigger. AI tools have moved well beyond "suggest the next line." They help developers generate components, write API routes, explain unfamiliar code, refactor old files, write unit tests, generate SQL queries, review pull requests, and summarize documentation.

And increasingly, they help complete entire tasks, not just snippets. That's a very different shift.

Developers spend less time typing and more time thinking

This is probably the biggest change I've noticed. Coding used to involve a lot of repetition: writing similar API controllers, repeating validation rules, creating DTOs, building CRUD pages, setting up routes, writing test scaffolding. Useful work, but repetitive.

AI handles a surprising amount of that now. So developers spend more time on the things that actually need a human: architecture decisions, reviewing logic, debugging edge cases, thinking through product requirements, and deciding what should be built in the first place.

Less typing. More decision-making. And honestly, that feels closer to real engineering.

The tools are improving faster than most people expected

A year ago, AI could write code... sometimes, and often with mistakes. Now tools like Cursor, GitHub Copilot, Claude Code, Windsurf, and Google Antigravity feel far more capable.

Not perfect. They still get things wrong and still need review. But they're noticeably more useful than before, especially when they understand your project's context. And that context changes everything, because generating code is easy. Generating code that actually fits your project is the hard part. That's exactly where the newer tools are improving quickly.

But AI hasn't replaced developers, and probably won't anytime soon

This question comes up constantly: "Will AI replace software engineers?" Personally, I don't think that's the right question.

AI is very good at generating. Developers are still needed for deciding. And software is full of decisions: trade-offs, business logic, edge cases, system design, security, performance, understanding users. AI can help with the code, but it still doesn't understand product thinking the way an experienced developer does. At least not yet.

Right now it feels more like this: AI speeds up development, developers still guide it. And that distinction matters.

My personal take

I think AI coding tools are becoming like Git, or Stack Overflow, or package managers. At one point each of those felt optional. Then they became normal, the kind of thing you just expect every developer to use.

AI coding tools are heading the same way. Not because developers are being replaced, but because the workflow is changing. The developers who adapt will probably move faster, ship faster, debug faster, and learn faster, while spending less time stuck on repetitive work.

That doesn't make software development easier. It just removes some of the friction around building software. And honestly, that's a pretty exciting shift to watch.

The short version

• AI coding tools are now part of the daily developer workflow.
• They've moved beyond autocomplete into debugging, testing, refactoring, and full task completion.
• Developers spend less time writing repetitive code and more time thinking through architecture and logic.
• Tools like Copilot, Cursor, Claude Code, and Google Antigravity are evolving very quickly.
• AI isn't replacing developers, but it's definitely changing how software gets built.

Written by the TechKis team — an AI-first engineering studio. techkis.tech