Forem: Oleg Glybchenko

Sticky identities

Oleg Glybchenko — Wed, 22 Apr 2026 12:31:59 +0000

When I started career in software in 2015, every job application I filled out had the same dropdown.

I picked frontend. Not because I didn't write backend code — I did, throughout my whole career. But the dropdown needed an answer, and frontend was where my mass-applied recruiter keywords lived. You know how it is. Required field. Pick one. Move on.

Except you don't move on. That answer followed me for a decade. The jobs I saw. The filters I passed. The ones I didn't. A dropdown became a label. A label became an identity. And identities, it turns out, are harder to kill than a production bug on a Friday deploy.

Last week I sat down with our R&D chief to talk about the future of software development. Not in the abstract LinkedIn way — in the "what does this actually mean for our team" way. I threw out two directions.

The first is horizontal. The walls between backend, frontend, product, design — they're gone. I watched a PM at our company trace a 35-second production slowdown to a cold buffer pool, calculate that 33,000 rows were being scanned when only 3,300 were needed, and open a PR with the fix. Six months ago he was the guy engineers joked about for "refusing to open PRs." Nobody's laughing now.

The second is vertical. Systems thinking. Architecture. The kind of knowledge that doesn't fit in a prompt and doesn't show up in a diff. The kind of knowledge that prevents the 3am pager from going off in the first place.

He said something that reframed both.

"ICs will always be measured on one thing — how fast they deliver quality. AI doesn't change the metric. It changes the multiplier."

Go wide → you parallelize. Ship 3 things instead of 1.
Go deep → you prevent fires. One architectural call saves 3 months of rework.

Breadth or depth. Both are multipliers. Neither is optional.

I agreed. Then I told him the real problem.

Most developers will pick neither.

A Dead Economist Walks Into a Standup

Stay with me here.

John Maynard Keynes was a British economist who published The General Theory of Employment, Interest and Money in 1936 — right in the middle of the Great Depression. Why should you care? Because before Keynes, every serious economist believed the same thing: markets self-correct. Prices fall, wages adjust, supply meets demand, everything finds equilibrium. Just wait it out. This was the "it works on my machine" of economics — theoretically sound, practically useless.

Keynes looked at millions of people in unemployment lines and said: no. Things get stuck. And they stay stuck.

His big idea was sticky prices. Wages and prices don't adjust to new realities even when they should. Contracts get in the way. Coordination problems get in the way. The simple human refusal to accept less than yesterday gets in the way. The economy doesn't self-correct. It freezes. By the time it unfreezes, the damage is done.

If you're a developer, you've already heard this voice. It sounds like: "I like writing code manually, that's what I was hired for." Or: "I'm not a prompt engineer, I'm a real engineer." Or my personal favorite: "AI can't do what I do" — said by someone mass-applying to the same role they've held for 6 years while the job description quietly changed underneath them.

That's a sticky wage. That's a price that won't adjust.

This was controversial enough to split economics into two schools still arguing about it 90 years later. Keynes told an entire profession "your core assumption is wrong" and proved it with math. Which, if you think about it, is the most senior-engineer move in the history of intellectual work.

Why am I telling you about a dead economist?

Because developer identities are sticky prices.

"I'm a frontend developer" is not a description of what you do. It's a wage that refuses to adjust. I wrote backend code my entire career, but the label said frontend. The market moved — AI dissolved the skill barriers, companies restructured around output — but the label stayed. Comfortable. Familiar. Attached to years of mass-applied recruiter keywords and mass-internalized self-worth.

And it's not just economics. Psychologist Glynis Breakwell developed Identity Process Theory in 1986, which describes exactly why this happens at the individual level. People construct identity around four principles: self-esteem, continuity, distinctiveness, and self-efficacy. Threaten any of them — say, the market telling you your specialization is no longer special — and people don't adapt. They defend. They double down. Erik Erikson, who coined the term "identity crisis", would call what's happening now a mass identity renegotiation. Most people avoid those until the pain of staying exceeds the pain of changing.

Kahneman and Tversky put a number on it: losses feel twice as painful as equivalent gains. To stop calling yourself "a React developer," the alternative has to feel twice as valuable. It doesn't. It feels like opening a codebase you've never seen at 4pm on a Thursday.

So you stay. Not because staying is the right move. Because the cost of moving feels higher than the cost of standing still.

The Market Already Moved. You Didn't.

The numbers are in. Stanford tracked payroll data: employment for developers aged 22–25 dropped 20% from its 2022 peak. Developers over 26? Stable. The two cohorts diverged the moment ChatGPT launched. Like a git branch nobody merged back.

Source: Stanford Digital Economy Lab, "Canaries in the Coal Mine?" (2025)

Harvard went wider — 62 million workers, 285,000 firms. At AI-adopting companies, junior employment fell 9–10% in six quarters. Not layoffs. Companies just stopped posting junior roles. The bottom rungs aren't being kicked out. They're being removed before anyone gets on.

You know the headline numbers. 245,000 laid off in 2025. 95,000 so far in 2026. Salesforce cut support by half, replaced them with AI agents. Snap said 40% of new code is AI-generated. But the same Q1 2026 that saw 52,000 layoffs also had 67,000 active job postings — highest in three years. Same quarter. Same industry. Companies destroying one type of role and creating another, fast enough for both curves to coexist.

The jobs disappearing are defined by labels. The jobs appearing are defined by output.

And yet — go on any job board right now. I went on Anthropic's. The company building Claude — the AI that's supposedly dissolving the boundaries between specializations. Here's what their careers page looks like:

Anthropic's careers page, April 2026. The dropdown is gone. The labels aren't.

The company building the AI that dissolves specialization boundaries is hiring with the same boundaries. Stickiness isn't a bug in the hiring pipeline. It's the pipeline.

The Twist: You Already Know This And It Doesn't Matter

Here's where it gets uncomfortable.

If you've read this far you probably agree. AI changed things. Labels are outdated. Adapt or die. You've seen the LinkedIn posts. You've nodded along. You might have even reshared one with a thoughtful comment like "this resonates."

And then you went back to work. As a frontend developer. Doing frontend things. In a frontend team. With a frontend title.

This is Breakwell's theory in action. You intellectually accept the threat. But your identity defense mechanisms kick in anyway — you minimize the threat, you tell yourself your niche is different, you reframe the layoffs as something that happens to other people. The continuity principle wins. The identity survives. The adaptation doesn't happen.

METR — a nonprofit research group — proved this gap is measurable. They ran a randomized controlled trial in 2025. 16 experienced open-source developers. Randomly assigned tasks with or without AI.

The developers using AI took 19% longer.

Before starting, they predicted a 24% speedup. After finishing — after experiencing the slowdown — they still believed AI had sped them up by 20%.

A 39-point gap between perception and reality. Not a skill problem. A belief system so sticky that lived experience couldn't dislodge it. If that's not downward nominal rigidity applied to self-perception, I don't know what is.

Keynes's whole point. Sticky prices don't persist because people are stupid. They persist because the psychological cost of adjusting is higher than the economic cost of being wrong — right up until the moment it isn't. And by that moment, you're in the LinkedIn "open to work" queue. Which is an unemployment line with better lighting.

Three Things That Break the Freeze

Keynes argued economies don't self-correct. They need intervention — something external that forces movement.

Developer identities work the same way. Three things do it:

Your company stops hiring your label. Already happening. Postings labeled "entry-level software engineer" grew 47%, but actual hiring dropped 73%. The dropdown still has the option. The jobs behind it don't.

Someone crosses the boundary you wouldn't. I watched a PM open PRs, trace production issues, and challenge engineering assumptions that two senior engineers missed. He didn't learn to code — he already knew the domain. AI just removed the last barrier between his knowledge and the codebase. When someone crosses the wall you're standing behind, it stops feeling protective. It starts feeling like a cage.

You realize the label was never a description. It was a limitation. I called myself a frontend developer for years — while writing backend code the whole time. The label didn't reflect what I did. It reflected what I was willing to claim. The gates were already open. The only thing still closed was the dropdown in my head.

The Dropdown

Somewhere right now, a developer is filling out a job application. There's a dropdown. "Select your specialization." They're picking the same thing they picked last time. Not because it's wrong. Because it's familiar. Because the cost of changing feels higher than the cost of staying.

Keynes called this sticky prices. Kahneman called it loss aversion. Breakwell called it identity threat defense. I'm calling it sticky identities.

The biggest risk right now isn't picking the wrong direction — breadth or depth, horizontal or vertical. The biggest risk is not picking at all. Inertia is the default. And the data says the default is getting people left behind.

I picked frontend from a dropdown 11 years ago. It took me most of those years to realize I wasn't choosing a specialty. I was choosing a ceiling.

The dropdown is still there. I stopped picking from it.

I kept getting blamed for outages that weren't mine. So I built a tool to fight back

Oleg Glybchenko — Mon, 23 Mar 2026 01:31:53 +0000

The villain origin story

December 2024. 11 PM. I'm on the couch. Phone buzzes.

"Hey, the AI feature is broken."

I check our dashboards. Everything's green. Our servers are fine. Our database is fine. Our CDN is fine.

OpenAI is down.

Not us. OpenAI. Their status page? Still showing "All Systems Operational." It took them over an hour to even acknowledge it. By then I'd already gotten 14 messages from users who thought we broke something.

Two weeks later — same thing. OpenAI down again. 4+ hours. Same dance. Same blame.

I started to notice a pattern.

The pattern

Every monitoring tool I've ever used — Pingdom, UptimeRobot, Datadog — they all answer the same question: is MY site up?

That's... not the question anymore.

Your site is up. Your checkout is up. Your auth is up. But Stripe's API is returning 500s, so your checkout silently fails. Twilio is lagging, so your 2FA codes arrive 30 minutes late. OpenAI is down, so every AI feature you've built returns a loading spinner forever.

Your infrastructure is healthy. Your users are furious. And the status pages of those providers? They'll update eventually. Maybe. If they feel like it.

→ You find out from customer complaints
→ You find out from someone on Twitter
→ You find out from Downdetector — which, by the way, went down during the November 2025 Cloudflare outage. The site that tracks outages couldn't track the outage.

I'm not making this up.

It's getting worse

This isn't a pessimism play. It's math.

Every major cloud provider is pouring money into GPU clusters and AI infrastructure. Forrester — not some blogger, an actual analyst firm willing to stake their reputation on it — predicted at least two major multi-day hyperscaler outages in 2026. The reason? Legacy systems getting neglected while everyone races to ship the next model. TechTarget covered it too — cloud outages are expected to be the new normal.

And we're already seeing it. In the first three months of 2026 alone:

Anthropic (March 17-18) — Claude went down hard. API 500 errors everywhere. Chat, coding tools, mobile — all dead. IBTimes reported on the global disruption. Developers on Twitter called it "a snow day". StatusGator tracked 9+ hours of downtime on March 18 alone. Earlier in February, StatusGator detected an Anthropic outage 1 hour and 47 minutes before Anthropic acknowledged it on their own status page. Almost two hours of "All Systems Operational" while nothing was operational.

GitHub (February) — Six separate incidents in one month. The worst one took out GitHub Actions and Codespaces for nearly six hours. Then on March 18, webhook deliveries went from ~5 second latency to 160 seconds. That's a 32x spike. On the same day Cloudflare was also having issues. Fun times.

Cloudflare (March 18) — Pages API, Pages Builds, and Workers Builds all hit with 500s and build failures. If you were deploying that day, you weren't deploying that day. This came after the November 2025 mega-outage that took out X, Spotify, ChatGPT, Canva, Discord, and dozens more — and a second outage in December.

Stripe — 13 incidents in the last 90 days. Three major outages. The payment processor. Thirteen incidents in three months.

AI coding agents are shipping 1,300 PRs a week at Stripe now. That's incredible. It's also 1,300 chances per week for something subtle to break. The faster everyone ships, the more things break. The more things break, the more you need to know about it before your users do.

I'm not anti-AI — I literally built CanaryOps using Claude Code. But the tool that helps me build faster is also the tool that goes down at 11 PM on a Tuesday. The irony isn't lost on me.

The "I'll just build it" moment

Every developer has this moment. The sensible voice in your head says "there's probably a tool for this." You google it. There isn't. Well, there is — but it costs $300/month and requires a sales call and a 47-slide onboarding deck.

So you do what developers do.

You open your terminal at 11 PM on a Tuesday and whisper "how hard can it be."

(Narrator: it was not that hard.)

What I built

CanaryOps — monitors the APIs you depend on. Not your site. Your dependencies.

The idea is dead simple: ping Stripe, OpenAI, Twilio, Cloudflare, SendGrid, and about 10 other common APIs at regular intervals. When something starts returning errors or degrading — email alert. Before the status page updates. Before the user complains. Before you find out from a meme on Twitter.

Stack:

Next.js (App Router) + TypeScript
Supabase for auth and database
Resend for email alerts
Vercel cron for the check engine
Lemon Squeezy for billing (because Stripe wanted me to incorporate a company just to accept payments, which is a whole different rant)

How it works:

Sign up, pick the APIs you use from a preset list (or add any custom URL)
CanaryOps pings them at regular intervals
Something's off → you get an email
You now have a 5-minute head start over your users

That's it. No Kubernetes. No Grafana dashboards that require a PhD to read. No 47-slide onboarding deck.

Why email and not Slack/Discord/SMS

Because email is the cockroach of the internet. SMTP has been running since 1982. It survived the dot-com bust, the move to mobile, the move to cloud, and every Cloudflare outage that takes out half the web. Your inbox still works when everything else is on fire.

Yes, I use Resend to send the alerts. Yes, Resend could also go down. Yes, I'm aware of the irony of monitoring dependencies while depending on dependencies.

It's dependencies all the way down.

At some point you pick a layer you trust and stand on it. I'm standing on email. It's been working for 43 years. I like those odds.

The part where I ask for your help

CanaryOps is live. Free tier gives you 10 monitors with 5-minute checks and email alerts. No credit card, no trial that expires, no "contact sales."

Pro is $9/month for 50 monitors and 1-minute checks. That's less than the mass-produced sandwich you bought for lunch.

I'm a solo dev. No funding, no team, no marketing department (as you can probably tell from this post). I built this because I needed it, and I'm betting other developers need it too.

What I actually want from you:

Try it → canaryops.dev
Tell me what's broken
Tell me what APIs to add to the preset list
Tell me if the value prop makes sense or if I'm yelling into the void

The thesis

The question isn't whether your dependencies will go down. They will. More often than last year, and the year before that.

The question is whether you'll know before your Slack lights up with user complaints.

Status pages are self-reported. They update when providers decide to admit something's wrong. That's not monitoring — that's PR.

You deserve to know before the status page does.

canaryops.dev