Two kinds of integrity, two different ceilings
When we talk about "integrity," we tend to lump together two very different things.
Integrity with yourself — intellectual honesty — is the ability to look at your real capability without distortion. It's daring to say "I don't know" when you don't. It's writing // TODO: this is a hack instead of pretending you've solved it. It's admitting that the person sitting next to you is better than you at something — and then going to learn from them.
Integrity with others — ethical integrity — is not claiming credit for your teammate's work, not blaming upstream when you're wrong, not estimating timelines politically instead of technically, not hiding bugs to save face.
These two are related, but they aren't the same. And they set two different ceilings:
- A lack of integrity with yourself caps your capability.
- A lack of integrity with others caps your influence.
Some people hit the second ceiling without ever hitting the first — the "toxic 10x engineers" most companies have at least one of. They code well, but no one wants to work with them, and the teams they build never mature. But — and this is the key point — no one ever breaks past the first ceiling without intellectual honesty. Zero exceptions.
This post is about the first ceiling. Because it's the one almost everyone hits, including people considered "nice."
The loop people without integrity can never run
Every good engineer runs a simple loop:
- Encounter a problem beyond current capability
- Admit to yourself that you're missing something
- Go learn, ask, read
- Apply and verify the result
- Update your real map of your own capability
This loop sounds trivial. But it stalls right at step 2 for anyone without intellectual honesty.
They can't admit they're missing something, because admitting it means facing a hard truth: that they aren't as good as they think, that the other person really is better, that the way they've worked for five years might have been wrong.
Instead of facing it, they take detours:
- "That's not important" — when a colleague uses a technique they don't understand
- "That code is over-engineered" — when reading something cleaner than their own
- "That bug is the framework's fault" — when they can't debug it
- "I already know that" — when they hear something new before they've actually thought about it
- "Seniors are no different" — when meeting someone genuinely more skilled
Each of those sentences is a door closing. Each closed door is a missed chance to learn. After five years they have five years of experience. After ten years they still have five years of experience — repeated twice.
The most subtle form of dishonesty: clinging to "good enough"
There's a form of dishonesty with yourself that almost everyone falls into at least once, and it doesn't show up as obviously as the ones above.
It's when you've chosen a solution — a framework, an architecture, a process, a way of working — and over time, evidence starts to surface that it's not good enough. There may be a better fit. The original approach may have been wrong at the assumption level.
Someone honest with themselves stops, admits it, and pays the cost of finding a better solution — even when that means throwing away the work they've already invested.
Someone without that honesty rationalizes:
- "It still works, doesn't it"
- "Changing now is too risky"
- "We'll deal with it next sprint"
- "It's not bad enough to redo"
Each of those statements might be true. But the test is: are you actually re-evaluating, or are you just saying this to avoid re-evaluating?
The difference is subtle but decisive. Someone genuinely re-evaluating has data, comparisons, specific reasons to keep what they have. Someone rationalizing only has feelings — and sunk cost never speaks up for itself.
This is why so many codebases, so many processes, so many architectural decisions outlive their reasonable lifespan by years. Not because they're good. Because nobody had the integrity to say: "I chose this wrong. I need to put in the work to redo it."
Finding a better solution is expensive. It costs time, energy, sometimes ego. That's exactly why it requires integrity to start — without it, the brain will always find a convincing reason not to.
Humility won't save them
This is where a lot of "soft skills for engineers" writing gets it wrong.
They say: be humble, listen, keep a beginner's mind. Sounds great. But humility can be performative — performed to be praised for being humble. Someone can nod, smile, say "I still have so much to learn" — and go back to their desk and write the same code, not read the book a colleague recommended, not try the new tool.
Humility is an attitude. Intellectual honesty is a behavior.
Attitudes can be faked. Behavior can't — behavior leaves a trail: commit history, code reviews, technical decisions, how you react when someone points out you're wrong.
An engineer with real intellectual honesty doesn't need to perform humility. They can be confident, even sharp in argument. But when the other side makes a better case, they change their mind on the spot — not out of politeness, but because they care more about the truth than about being right.
This is the most important test. When was the last time you changed your mind mid-argument in a technical discussion?
Why it gets more dangerous the higher you climb
At the junior level, a lack of integrity still lets you get work done. Tasks are well-defined, code either runs or it doesn't, and you have immediate ground truth. You can't hide a bug from production for long.
But from senior up — and especially at Lead, Architect, CTO — the work shifts to judgment under uncertainty: which stack, which feature to cut, when to say "no" to the CEO, will this architecture scale.
These decisions don't come with instant feedback. You decide today, and the consequences surface six to twelve months later. In those six to twelve months, someone without integrity with themselves does something genuinely dangerous: they rationalize a wrong decision into a right one.
They find ways to explain how they were still correct. They blame the market, the team, shifting requirements. And because they never admit the decision was wrong, they never learn from it. Next time a similar situation comes up, they make the same kind of decision, and rationalize it the same way.
This is why you see "impressive" CTOs whose teams never grow. Not because they don't teach. Because what they model for the team is: dodging the truth is a survival skill. And teams learn from what they see, not what they're told.
A test for yourself
If you've read this far, you're probably asking: what about me?
Here are a few hard questions:
- When was the last time you said "I was wrong" in a technical meeting?
- When a colleague writes better code than you, what's your first reaction — learn from it, or find a reason to criticize?
- Do you have a real mentor — someone you genuinely admit is better than you, and whose advice you actually take?
- In code review, do you find it easier to receive feedback, or easier to explain and defend?
- Reading this, are you thinking "yeah, those other people really do lack integrity" — or are you thinking "hm, do I do this too?"
The last one matters most. Because people without integrity with themselves, when reading something like this, always think about other people. Never about themselves.
AI is destroying the last feedback loop
Until recently, people without intellectual honesty still had one thing that kept them from drifting too far from reality: collisions with the world. Code review criticism. A colleague pushing back. A boss shaking their head. Production going down at 2 a.m. These collisions are uncomfortable, but they're signal — they force people to face the truth whether they want to or not.
AI is taking those collisions away.
Today's large language models are trained to be helpful, agreeable, and to make the user feel smart. This isn't a bug — it's a design choice. But for someone without integrity, this trait becomes a quiet self-destruct weapon:
- You bring a bad idea. The AI finds a way to make it sound reasonable.
- You write lazy code. The AI calls it "clean and well-structured."
- You ask "is what I'm doing right?" The AI leans toward confirmation rather than pushback.
- You debate the AI on a technical decision. You "win" more easily than you would against a person — because the AI yields.
Before AI, an engineer without integrity at least still got hit by reality. Now they have a tool that always agrees, always praises, always finds a way to make them right — and that tool sounds smart, sounds objective, sounds like it has read the entire internet.
They trust it. They use it as a personalized echo chamber. And their choices — already distorted by a lack of integrity — get amplified by a machine with persuasive power we've never had before.
The result is a new and dangerous form of capability decay: not just stalled, but convinced they're climbing. Because the AI told them so.
People with intellectual honesty use AI the opposite way. They actively ask for pushback: "Find the holes in my argument." "Argue against my decision." "Assume I'm wrong — where am I wrong?" They know the AI tends to agree, and they actively pull it back toward the truth. They use AI as a sparring partner, not a cheerleader.
Same tool. Two ways of using it. Two completely different outcomes — and the gap between those outcomes is growing every day.
The ceiling is you
Engineering capability isn't a fixed IQ number. It's the result of thousands of small learning loops over many years. Every one of those loops begins with a simple but hard behavior: looking at the gap in your capability without distorting it.
This used to be hard because of ego. Now it's harder still — because you have an entire machine willing to convince you the gap doesn't exist.
Those who can still do it in the age of AI will pull further ahead than any previous generation. Those who can't will stall faster than any previous generation — and never understand why.
The ceiling isn't the market. It isn't AI. It isn't luck.
The ceiling is you. And AI just made it lower.