user@elrise.io:~$ 
2026-07-2216 min readitmarketaicareerarchitecture

Knowledge Vacuum: what a year outside employment showed me about software hiring

Last year I found myself outside employment. I spent months searching, building side projects in parallel — bundles, benchmarks, open source. At some point I caught myself thinking that I wanted to go back to a paid job less and less. Not out of spite for the industry, not a “look at them” gesture, but simply because through my own experience and through conversations with those who are also searching, I saw the same picture. This article is an attempt to capture it. This is my take. It is grounded in my year of job hunting and in the stories people tell and their experiences. The condensation of my understanding of what is happening to the profession.

How I ended up here

I am a fullstack developer. I have written PHP/Symfony, optimised high-load services in payment and CRM projects, and hired people. At some point last year the project I was working on ended, and I was on the market. Not “fired” — the contract simply closed, and from there I had to find a new place. I was sure I’d find one in a couple of months: I had experience, an in-demand stack, references, a reputation in a few communities.

I didn’t find one. In a couple of months I didn’t find one. Then more. Interviews happened, rejections too. At first I thought it was a normal process — that’s the market, that’s competition, that happens. Then I started noticing patterns I didn’t like. And in parallel, instead of “just waiting”, I sat down and coded my own projects — the very bundles that are now in open source. Not out of desperation, but because that was the only thing I could control at that moment.

A few months later I noticed that I sat down at my own projects with more pleasure than at preparing for the next interview. Not because interviews are bad — but because in my own projects I see a result that works, that can be measured, that can be shown. And interviews turned into a ritual where you’re judged by metrics that have less and less to do with what you actually can do.

And at some point I formulated the diagnosis for myself. Not “AI is taking jobs” and not “seniors are in demand”, but something else. What I see is a vacuum in knowledge assessment: the volume of information a developer has to absorb keeps growing, while the ability to tell real knowledge apart from plausible-sounding output has not. This vacuum is not reducible to AI, hiring, or the downturn. We have all become less certain about what we genuinely know and what only looks like knowing — companies and developers alike. I saw this while trying to get hired and while hiring people myself. The data I found came from different samples, scales, and time windows. It does not establish one shared cause, but it shows a similar shape.

Model: knowledge as an object in multidimensional space

To explain what I saw, I need a model. A developer’s knowledge isn’t a line on a CV or the number of frameworks learned. It’s an object with several parameters: volume, quality, coherence, recency, applicability, depth. Together they form a multidimensional space where each developer has their own “blob” — the visual density of which is just a way to draw the picture, not a seventh separate axis. Some coordinates you can grow in a week, others only over years.

Employers used to look for a point in this space that fit the task: the right volume, the right quality, and — often overlooked — coherence. Coherence is when knowledge isn’t sliced into isolated pieces from different tutorials, but stitched into a working model in the developer’s head. A developer might not know a specific library’s API, but they have a model of how it’s built and where the sharp edges are.

It is coherence that makes a developer a developer, not a Stack Overflow operator with a good memory. It grows slowly — through your own mistakes, through night-time debugging, through projects taken to production and then maintained for three years. It’s an expensive thing — both for the person themselves and for the company that hires them.

What I saw in my experience, supported by other signals

When I started looking for data to verify my feelings, I found a lot that confirmed the picture. The signals came from different samples, different scales, and different time windows — they don’t establish one single cause. They just look the same shape.

First. In interviews, the question “how do you use AI in your work?” came up more and more often. Not “tell me about a complex bug you debugged for three nights”, not “explain why this architecture doesn’t work under load”, but specifically “how do you use AI”. It’s not a bad question in itself, but it shows the priority: companies care about what I do with the tool, not what I can do without it. 84% of developers use or plan to use AI tools at work (Stack Overflow 2025), and 51% of professionals — every day. This is no longer “a feature for the advanced”, it’s the norm. And 66% of developers say AI gives them “almost right, but not quite” answers, while 45% spend more time debugging AI code than they expected. So mass adoption is already there, and mass problems too.

Second. I started watching how people are hired, and saw that my interviewers often didn’t understand what they were looking for. They tested a skill that no longer matters (learning an API), and didn’t test a skill that does (building a model of the problem). It isn’t their fault — their metrics are broken. They measure what they used to know how to measure, not what’s needed now. This immediately tells you how they see their own hiring funnel: the company is consciously choosing the tool over the beginning specialist, and the question of who will be left to grow into the next role quietly disappears from the discussion.

Third. I saw that those who landed well landed not through “framework knowledge”, but through the ability to assemble a complex system and explain why it’s assembled exactly that way. This skill — coherence — can’t be bought from ChatGPT. And it’s the hardest to evaluate in an interview, because it shows not in the answer to a specific question, but in how a person reasons when they don’t know the answer.

Market snapshots, side by side

The numbers below are independent snapshots from different sources. They are not a time series and they do not prove a single shared cause. Where a figure describes a different sample or a different year than the others, I note it inline.

Together these snapshots form an uncomfortable pattern, but I use the word “trend” carefully: the sources do not share a sample, a year, or a question, so what they share is a shape, not a curve. This article is about that observation, not a forecast.

Where this leads — two scenarios I find useful, not a forecast

The branches below are scenarios I sketched for myself to think with, not predictions. They describe what could happen if the underlying pressure on entry into the profession keeps compounding, or if it eases. I do not assign probabilities.

What Branch A describes is the expertise deficit that would set in if no one invests in the path that turns a beginner into someone who can hold a coherent model. What Branch B describes is the alternative in which that path is rebuilt and the accumulated effect goes into a renewed knowledge cycle instead of a dry one. The fork is not “AI takes jobs” or “AI does not” — it is about whether the industry keeps the route open by which a junior eventually becomes a senior who carries coherence in their head.

I have been through this both as a hiring manager and as a hiree. On one hand I see the demand for ready-made seniors holding steady while the entry paths under it narrow. On the other I see that the people who would have grown into those seniors are not being hired into the conditions where that growth happens. Those are two different problems wearing the same outfit. They both feed the assessment vacuum I described at the start: the gap between what the market signals say about a candidate and what the candidate can actually do in a real system.

What I decided for myself

This isn’t “top 10 tips”. These are three conclusions I’ve made for myself this year. Maybe it’ll be useful to someone, maybe not.

First. AI is raw material, not a finished dish. I use it every day: for writing code, for validating complex tasks, for architectural checks. But I don’t give it the final decision. If I can’t explain why this code works and under what conditions it’ll break — it doesn’t suit me, I’m consuming it right now, not using it. This isn’t morality, it’s a check: a developer differs from an AI operator precisely by having a model in their head, not only the result.

Second. Deliberately grow the foundation. It’s boring, it doesn’t monetise in the moment, but it’s the only thing that separates someone who can hold a coherent model from someone who can’t. I keep reading code that AI gave me, without AI. Solving tasks that look too small for AI — that’s where the coherence of the model grows. Writing something by hand, at least once a week, just so my hands remember. This is my way of staying sharp. Not “best practice” from a textbook, but what works personally for me.

Third. I chose my own projects over employment, at least for now. This is not morality and not advice. It’s just my choice at the moment. I’ve hired people, I’ve searched for jobs, and I don’t want to pretend these processes work. They are visibly misaligned with what they claim to measure — and that’s visible from both sides. I’d rather spend a year on my bundles, on benchmarks, on open source, than on trying to fit into metrics that have nothing to do with what I actually can do. This is my conclusion, and it might not be yours. But I made it — and after a year of my projects I have a result I can touch, not a CV I can rewrite.

Not an end, but a reboot

I don’t think the profession is dying. I think it’s rebooting — and, like any reboot, it carries the risk of freezing on a black screen. We’re all — developers and companies — at the point where old knowledge-as-object hasn’t stopped working yet, and new knowledge-as-stream has already stopped fitting into the old hiring and assessment models. The assessment vacuum — the gap between the external signals hiring and the market use to judge a person, and the internal model that person has in their head — is what we all feel when we try to hire, get hired, assess, explain to ourselves what’s happening.

There is a way out of this vacuum, and it’s not about “learning prompts”, and not about running to become AI engineers. It’s about re-learning to tell knowledge apart from its visibility — in your own work, in hiring, in evaluating colleagues. Then the conveyor will fix itself.

I’m doing my part. Bundles go to open source, benchmarks run, documentation gets written. Right now this is indeed instead of employment — but not in opposition to the industry. This is my way of surviving the reboot without losing coherence. Everyone has their own.

Disclaimer

This is an analytical column, not an academic study. Personal experience sets the question; public reports provide separate market signals. They do not establish that everything described here has one cause. Where the data cannot separate the effect of AI from the hiring correction and cost pressure, I do not claim that it can. If you work in the industry and see a different picture, open an issue or write in the comments.

Sources:

Discussion

Comments (0)

No comments yet.