For the past few months, we've been talking about IKE, IKE, IKE at Klysera. But what exactly is the IKE? What does it mean? Why should you care about it? Is it even something worth paying attention to?

These are all good questions, and I'll get to answering them soon, but first, let's talk about the world you're hiring into right now. Because if you don't understand that, the IKE won't mean anything to you.

If you've been to any founder dinner, any engineering hiring thread on X, any Slack community for CTOs in the last six months, you’ve likely seen the commentary on Marc Benioff, who went on record saying Salesforce hired zero engineers in FY2026, and he said this was because of “coding agents”. 

Then, Dario Amodei (the man building the AI) called what's coming a "white-collar bloodbath." Sam Altman, in the same week but a different interview, advised companies to "augment, not replace." 

‍

We have these two CEOs, leading frontier companies in the same industry, working on the same technology, dishing out opposite predictions. But which should we even listen to?

Then there's Andrej Karpathy (former Tesla AI lead, OpenAI co-founder) who coined the phrase we all love to hate, "vibe coding" in early 2025. It went viral, and I noticed some developers on LinkedIn were updating their titles to Vibe Code Cleanup Specialist (I personally think it was partly a joke, partly a cry for help). By February 2026, Karpathy himself had declared the term passé and proposed a new one: agentic engineering. All of this happened in the span of just twelve months.

And in the middle of all of this, founders are still trying to hire engineers, and most of them are still confused because one party is saying get rid of your employees and another is saying, “just augment”.

And some others are arguing about whether the role of an engineer is dying out (AI is coming for your job). Nobody, and I mean nobody, is asking “what engineers are actually supposed to be in 2026 to survive the onslaught of security breaches, and tech acceleration the tech world is experiencing today.” 

That's the question we asked at Klysera after sitting with founders from across the globe. And we found the answer to that question.

‍

‍

Is AI Really The Culprit, or Is It Just A Convenient Excuse?

All the chaos you're seeing right now (the layoffs, the vibe coding panic, the "one engineer with AI can now do ten people's work" headlines, every single one of those reactions is borne from a place of panic from those who cannot see the future.

For context, in March, Atlassian (the Australian tech giant) announced it was shedding 10% of it’s global workforce, and just last week, an engineer who was affected in the layoff went viral for posting a video where he detailed the types of systems he had built and how they were maintained and fine-tuned over time.

But the focus here is on why these layoffs at companies like Atlassian seem to be happening. In a blog post on the company’s website, the co-founder said the future approach was not “AI replaces people”.

“But it would be disingenuous to pretend AI doesn’t change the mix of skills we need or the number of roles required in certain areas. It does,” he wrote.

The rise of AI presents its own set of problems, but AI itself is not the problem. It’s simply a diagnostic problem, and this is the thing nobody wants to say out loud.

AI didn't create bad engineers; it simply exposed them. The problem was always ownership. One study I keep coming back to was done by METR, where they ran a randomised controlled trial with experienced open-source developers with real engineers, working in real codebases on real tasks. And they found that the engineers using AI tools were measurably slower on complex tasks than those who weren't. And 95% of them actually thought they were being productive.

That's not a study about AI failing. That's a study about engineers who didn't own their systems deeply enough to know when a tool was helping them or hurting them. An engineer with true end-to-end ownership would catch that. A ticket-completion type of engineer wouldn't because they were never connected to the outcome in the first place.

The engineering world was already chock full of people doing ticket-completion work, implementation without ownership, output without judgment, shipping code that did not have any direct product impact, and many more. 

With the rise of AI, most of these tasks could be completed by a junior engineer in fewer hours than it previously took. It just did it faster and cheaper, and suddenly everyone could see it. What then would be the role of a senior engineer, other than the experience they had to offer? 

Companies started to ask this question, and the product thinking started to evolve to become what it is today. Product ownership + a direct impact on product impact in terms of users/revenue is now a required quality of engineers in 2026. The problem shifted from merely building products to an ownership problem? If AI could make this process faster, what they needed was someone who could own the product development process end-to-end.

These specific qualities that an engineer is required to have in 2026 are what we have coined into “the IKE profile (Ideal Klysera Engineer Profile”

‍

‍

How The IKE Was Born. We Didn't Invent This. We Kept Seeing It.

It all started with conversations. The same conversation, over and over, with founders from different industries, geographies, and stages of growth. 

And it usually went something like this: 

“We hired someone great on paper, and something is off. It’s not that the code is bad or defective, and it’s not missed deadlines. It’s harder to name; my engineer waits to be told what to do next, and they escalate decisions they should be able to make on their own. They are technically competent but outcome-absent”.

But there’s another side to this conversation with a very small group of founders.

They'd say things like: “Oh, my engineer thinks like a co-founder. They always came back with something better than what I asked for, so I genuinely don't have to worry when something lands on their plate.”

You’d be surprised to hear this, but the difference between these engineers wasn't a seniority thing. Some of those engineers had been there three years in. Some were ten. Neither was it experience. It was something else entirely.

So we decided to go find it.

We went to frontier companies building the next generation of the apps we all love and use today. We thought to ourselves, how do they find these engineers who create these stellar products? What qualities do they possess, and how can we replicate that? 

No one source that tells you more about what we need than their job descriptions. We read 200 of them across thirty-six companies (Anthropic, Stripe, Linear, Vercel, Shopify, Ramp), and we compared them against a baseline of what those same calibre of companies were asking for in 2019–2021.

What we found was not subtle.

Five things that used to define a qualified engineer as far back as 2019 have been almost entirely removed from how the best companies hire. 

• Degree requirements have gone from 84% of JDs to 2.5%.
• Years of experience minimums have dropped from 74% to effectively zero on the visible page. 
• "Team player" and collaboration-as-a-primary-criteria language have quietly retired. 
• Aspirational, culture-fit framing collapsed from 60% of JDs to 16.5%. 
• And generic technical stack requirements listed as the headline ask have been replaced almost entirely by outcome and ownership language.

In their place, these companies now prioritize qualities like:

• End-to-end ownership. 
• AI fluency as a baseline expectation, rather than a differentiator, shows up in 60.5% of modern JDs.
• Imperative, direct language about what you will drive, own, and be accountable for.
• Perhaps most tellingly is the complete disappearance of language that describes what the day-to-day work looks like. 
• Zero of 200 JDs tells you what the job actually is like because the engineer will be expected to wear many hats. They only tell you what they expect you to produce.

The industry changed its entire theory of what an engineer is for.

We had seen the pattern enough times (in founder conversations, in placements, in post-mortems) and now we had the data to match it. So we made a deliberate decision to name it, define it and build a framework rigorous enough to vet for it consistently, not just recognise it when we were lucky enough to stumble across it.

That framework is IKE.

‍

‍

The Five Things That Actually Matter In 2026

So what does the IKE actually look like in practice?

We built it as a direct correction and response to what we kept seeing the market get wrong. Each one of these competencies exists because of a specific failure we saw repeat itself, in JDs, in placements, in founder post-mortems.

‍

1. End-to-End Ownership

Marc Benioff said Salesforce doesn't need to hire engineers anymore because coding agents can do the work. And he's right, but only about a specific kind of work.

See, AI can sort through your tickets, perhaps even resolve pr’s for you, and it’ll do them fast, cheaply, and it will keep getting better at them. But what it cannot do is look at a product, see the gap between what exists and what should exist, and close it without being asked. That layer of context is still very much missing with AI, and that requires someone who is connected to the outcome, not just the task.

End-to-end ownership is what we require our engineers to have when they come in. That layer of knowledge, and the ability to wear multiple hats, is simply non-negotiable in an IKE. The IKE doesn't wait for a brief. They write the brief.

‍

2. Engineering Fundamentals

This one gets misread a lot, so let me be precise about what I mean.

I'm not talking about whether they can code. I'm asking whether they can think under pressure, make architectural decisions that hold at scale, and recognise when the fast path now becomes the expensive path later.

This is an absolute non-negotiable of an IKE because early architectural decisions compound and wrong ones can easily become the technical debt that costs you your Series B velocity. An IKE engineer understands what the AI generated, why it made those choices, and whether those choices will survive contact with real users.

‍

3. Product Thinking & Craft

The feature factory is the most expensive thing a startup can build. And most startups build one without realising it.

I like to think of it this way: 

Engineers who build to the ticket produce features but the engineers who think in user outcomes produce products. The difference sounds small but the compounding effect over eighteen months is enormous.

In 2026, with AI generating implementations faster than most teams can even review them, the bottleneck isn't output anymore. It never really was. It's now about making judgments about what's worth building in the first place. The IKE asks why before they write a single line.

‍

4. AI-Native Fluency

Not "do they use Copilot." Everyone uses Copilot these days.

The question is whether they reason with AI as a structural layer of how they work like directing agents with precision, evaluating output with scepticism, making architectural decisions that account for what AI handles well and where it quietly fails.

Remember the data I mentioned earlier where senior engineers with 10+ years reporting 81% productivity gains from AI tools? They're not gaining because they use the tools. Senior engineers get approximately 5x the productivity gains from AI compared to junior engineers because effectively reviewing and correcting AI-generated code requires deep understanding of system design, security patterns, and performance tradeoffs.

They're gaining because they understand the system well enough to know what to do with the output. 

‍

5. Learning Velocity

I'll keep this one short because the proof is sitting right in front of us.

Andrej Karpathy coined "vibe coding" in early 2025. Collins named it Word of the Year by December. And by February 2026, Karpathy himself had declared the term passé and proposed a new one.

Twelve months. One complete cycle.

The half-life of any specific technical skill in 2026 is measured in months, not years. Which means the IKE cannot be defined by what they know right now. They have to be defined by how fast they close the gap between what they know and what comes next.

All of these five competencies (every one of them harder to fake than a degree), every one of them invisible to a standard hiring process.

Which brings us to the obvious question, how the hell does Klysera actually find this person, if it’s so difficult to measure?

‍

‍

How We Vet For What Can't Be Faked

So the obvious question here is “If these five competencies are so important, how do you actually test for them?”

Because, to be fair, none of them are self-reported. You cannot simply ask someone, "Do you have end-to-end ownership?" and trust the answer. 

Everyone says yes. In fact, everyone believes they do.

Ownership shows up in build history, in the actual arc of what someone built, what broke, what they fixed, what they learned, and what they did differently the next time. 

Essentially, ownership leaves a trial of evidence that is hard to ignore.

AI-native fluency shows up in how someone reasons through a problem in real time. Anyone can write "proficient in Claude, Copilot, Cursor." What we're watching for is how they think when the AI output is wrong and they have to catch it.

Learning velocity shows up in the trajectory of someone's work over time. We do not focus on the current stack because the stack will change in very short burst in a short time. What is important is whether the person has consistently closed the gap between where they were and where the market moved.

And look, the average startup hiring process isn't finding any of this. 

The process likely involves:

• Resume screening
• A leetcode round
• Or a vibe-based panel. 

I'm not saying this to be harsh. I'm saying it because it's true and most founders know it. That process surfaces people who are good at hiring processes. Those are not the same people as the ones who will own your product outcomes.

At Klysera, our vetting is built around evidence, not assertion. Every competency has a corresponding signal we look for and none of those signals are things a candidate can rehearse the night before.

And then there's the guarantee. Our outcome-based billing tied to impact benchmarks. We don't get paid if the engineer doesn't perform against the benchmarks we set together with you at the start. This is a structural incentive that we absolutely stand by no matter the cost. It means we are accountable to get the definition right, the vetting right, and the placement right, every single time.

Because if we don't, we don't win either.

‍

‍

The Bet You're Really Making

I want to leave you with something that I don't think gets said enough in hiring conversations.

Every engineer you place at the seed-to-Series A stage is not an operational decision. It's a strategic bet that you cannot afford to lose. Products that users love are getting tougher to build because of the sheer amount of competition you have. The engineers in the room at the beginning define what you build, how it gets built, and whether it survives the moment it meets real users. 

Get that right, and everything compounds in your favour, but if you get it wrong, you’ll spend the next eighteen months managing around it.

The market is still arguing about whether engineers matter in the age of AI. We built Klysera because we already know the answer. 

The right engineers are the ones who own the outcomes, think in products, and build with the fluency that 2026 actually demands.

The “IKE” is our definition of right.

And we stand behind every single placement with the only guarantee that actually means something aka you don't pay if the benchmark isn't met.

If you've read this far, you already know what kind of engineer your product needs. The only question left is whether you want to find them the hard way or the right way.

If this sounds like you, let’s talk. Book a call with us today and we’ll have an honest conversation about what you're building and whether we can help you build it better.