Xiangan He

I’m very bullish on AI-assisted security work in 2026.  Models are now good enough to spot real vulnerabilities and even propose reasonable patches. Especially when you give them the right context about your system.  That doesn’t replace a human security engineer, to be clear. But it massively upgrades their throughput and coverage.  Instead of manually combing through every suspicious pattern, you can point the model at a repo and say, “show me the sharp edges first.” People are already getting serious bug bounties and client work off this combo of domain expertise and model leverage.  You still need to know which findings matter, how to exploit them, and how to fix them. That’s the human part.  But the grunt work of scanning, summarizing, and generating draft remediations? That’s getting increasingly automated.  That’s the exact lane my static analysis tool sits in.  It turns historically noisy security work into something high-signal and repeatable.  1 - Run a scan 2 - Get a curated list of likely issues 3 - Click a button to open a PR that tries to fix them It’s not magic, but it’s a huge jump from “grep and vibes.” As models keep getting smarter and context windows keep expanding, this niche only gets more overpowered.

Comfort is sneaky.  It lets you tolerate a job you don’t like or a subpar product because nothing is that bad.  You tell yourself you’ll fix it next quarter or “once things calm down.” But somehow, years go by.  “Not that bad” quietly consumes entire decades of your life if you let it.  The scary thing is you rarely ever get a single dramatic moment that forces you to move.  You just drift, and drifting doesn’t trigger any alarms.  I’d rather push into situations where I might crash the bike than keep walking the same safe loop forever.  At least when you crash, you learn your limits and pick a better route next time.  Higher stakes create more capacity.  You discover what you can actually carry instead of what you assumed you could handle.  Discomfort is a terrible long-term home.  But it’s an amazing short-term teacher.  I’ll take a few real falls over a lifetime of almost trying.

I recently inherited work from a dev team who left several hardcoded keys used in production in the codebase. Security has nothing to do with paranoia and everything to do with professionalism.  Most teams treat it like an enterprise-only concern until the day something goes wrong.  Simple decisions early, like how you handle secrets, how you isolate services, and how you log, eliminate entire classes of bugs later.  I found out they weren’t even authenticating calls to their core API when I ran a scan of their codebase using [slopless.work](slopless.work). I’ve watched many “harmless shortcuts” turn into actual incidents much faster than people expected.  And by the time it’s urgent, it’s usually also expensive to fix.

A decent product with momentum will beat a technically perfect product that nobody uses.  Sounds obvious, but it’s a tough pill to swallow.  I’ve put months into codebases that were clean, elegant, and genuinely fun to work on.  The problem was that nobody really needed what they did. That or they never got in front of the right people.  On the other hand, I’ve watched simple tools with blunt value props and strong distribution absolutely take off.  They ship fast. They talk to users.  They iterate on outcomes instead of obsessing over abstractions.  As an engineer, that’s humbling because it means your cleverness isn’t the main event.  The market doesn’t give you extra points for beautiful architecture if nobody experiences it.  But it’s also freeing.  You have permission not to be the smartest engineer in the room to build a banger product.  You just have to solve a real problem clearly, get it in front of the right people, and keep listening to them.  The craft still matters, but it’s in service of users over your ego.  Once you internalize that, you start making different tradeoffs about what to ship and when.  Good enough + used > perfect + invisible

A lot of talented builders don’t lack skill… They lack access. Good opportunities exist, but they’re scattered, noisy, and usually found too late. So I’ve been building a tool that aggregates real contracts and job opportunities using tighter filters than the usual platforms. A way to surface legitimate opportunities without sifting through endless junk. Still proprietary, still evolving, and currently limited to a small partner tier. The idea is simple: Different builders need different kinds of opportunities at different stages. Early-career? One set of filters. More experienced? A different signal entirely. Still early, but I’m excited about where this is going.

I’ve been thinking a lot about this idea called the “region-beta paradox.” I think it explains a scary amount of founder behavior.  The gist is simple: If something is mildly bad, you’re less likely to change it than if it’s truly terrible, because the discomfort never gets intense enough to kick you into action.  You tolerate the job that’s “fine.” You tolerate the product that’s “kinda working.”  You tolerate the life that’s “not that bad.” And people spend years in that holding pattern.  Long term, that can be worse than getting absolutely wiped out in 1 big, obvious failure.  A catastrophic loss might hurt more in the moment, but it forces you back to first principles.  What do I actually want?  What game am I actually playing?  What fundamentally needs to change in my life?  I’ve lived both sides of this.  If I’d cruised into Harvard, slid into a big-tech track, and ended up comfy as an I5 at Google, I’d probably be sitting on stock and optimizing for stability right now.  Don’t get me wrong.  I don’t think that’s a bad life by any means.  But I know myself well enough to know I’d be playing a proxy game, not the real one I care about.  Instead, my path has been messy.  - First-gen immigrant - Didn’t speak English until 11 - Got bullied in school - Lost my mom to cancer at 15 - Worked 80-hour weeks through a tier-2 school so my parents never had to pay a dime - Paid off my parents’ debt And now I’m supporting their retirement with the income from the dev shop.  None of that was comfortable.  But it pushed me into the lane I actually wanted to be in.

Speed is the only moat that compounds.  Especially for small teams.  Speed to serve customers when something breaks or they ask for a feature. Speed to adapt to new tools and platforms. It’s how you win trust while big orgs are still routing the ticket.  And we’re already seeing public markets price this in.  People are more willing to bet on the fast movers than on legacy logos that can’t keep up.  Figma’s a great example.  They didn’t sit on their lead and wait for their competitors to catch up.  They shipped Figma Make and a Claude code plug, leaning into the new meta instead of defending the old one.  Google’s another.  Google only started feeling dangerous again once Sergey and the founder energy stepped back into the room. The more an org is run on out-of-date playbooks and exec muscle memory, the more ripe it is for AI-native teams to eat their lunch.  This has been true for every major tech cycle.  But AI is going to compress the timeline so the gaps show up faster and hit way harder.

When a 9th grader says, “I don’t know” to a Newton’s Law problem, instead of going in circles asking the same questions, Magister explains the concept (F=ma), and then asks the student to apply it with real context.  You learn by doing something real, not by being questioned to death.  The goal is to make kids confident by using AI to teach them, not to make them dependent on AI to give them the answers.

The #1 complaint we heard from parents regarding Magister was:  The AI keeps asking questions but never actually explains anything.  It never told kids how to solve the problem correctly.  It just kept prompting in circles until everyone gave up.  One of the students submitted an answer and got nothing back.  No correct, no incorrect, just silence and the next question.  When her mom told me that she said, “mommy, this is confusing,” I felt that in my soul.  Because kids aren’t going to take the time to mess around with a tool that’s confusing. They’re just going to close off from the subject entirely.  So we rebuilt the feedback layer from scratch around 1 rule.  Teach the concept first, then ask the student to apply it.  Check out the demo below:

One underrated skill in 2026: Talking to AI clearly.  A lot of habits that were useful for coders 5 years ago actually hold you back now.  Things like hoarding context in your head and doing everything solo doesn’t fly.  The more you articulate you’re about constraints, edge cases, and desired outcomes, the better your “AI squad” performs. It’s like pair-programming and rubber-ducking on steroids.  Learn to ask better questions, and suddenly you feel 3-5x more cracked without new languages on your resume.

Most of the “launched” apps I see would fall over the moment real traffic hits.  A demo only has to work once on the creator’s machine. A real product has to behave under load, failure, and attack.  Production means logging, error handling, deploy + rollback, and someone who owns fixes.  If you can’t answer the question,  “What happens when this breaks?”  You don’t have a working product. Your users shouldn’t be the ones discovering where the bodies are buried.

You need a bit of intentional delusion to build anything non-trivial.  You have to believe “this might work” long enough to exhaust most of the obvious branches.  If you bail too early, you’ll never collect enough data to know if it was a bad idea or just an under-cooked one.  But you also can’t grind blindly for 3 years towards a dead end.  The art is knowing when to double down and when to pivot.  And that’s a question I’m still actively wrestling with daily.

My mom told me she had a malignant tumor when I was 5 or 6.  It’s a weird age to learn the word “malignant,” but once you hear it, you never really un-hear it.  Facing mortality that early completely rewired how I think about time.  Nothing feels guaranteed. “Someday” stopped sounding like a real plan to me.  So in college I worked 80-hour weeks so my parents never had to pay a dime for my schooling.  Every extra shift or freelance gig was me trying to buy them a little more safety.  Eventually, I paid off their debt, which felt better than any title or promotion ever could.  Now the devshop doesn’t just fund my experiments, it helps support their retirement.  Screw “hustle culture,” that’s just baseline responsibility.  When you’ve watched the clock run out on someone you love, taking big swings stops feeling optional.  All of this is the backdrop for why I take building so seriously. I’m trying to make the time I have count.

XORS is intentionally small and senior.  We could scale a ton, but we choose not to, because the work we do sits next to people’s careers, reputations, and fundraising rounds.  We’re product-focused engineers first, and “agency” second.  Mainly because there’s a massive difference between: “We shipped an app” and “We shipped something that lets people live more than they otherwise could.”  Doing it right is the only way to build something that actually lasts past the demo.  If you care deeply about what you’re building, you’ll want a team that cares just as much.

I think of building products like playing an RTS game.  You place bases.  (Skills you build, products you ship, and relationships you invest in) You allocate units to different fronts depending on what matters that week. (Your time, energy, and nowadays AI agents)  Sometimes you push for expansion (new ideas or new markets), and sometimes you turtle up and reinforce what’s working.  Losing one battle doesn’t mean losing the game, but it usually means your build order was off.  Maybe you over-teched too early. Maybe you tried picking a fight without enough resources behind you.  The nice thing about this frame is that failure turns into information instead of a verdict on your identity.  Most people don’t realize they’re allowed to treat their career and projects this way.  They assume there’s a script they’re supposed to follow instead of a map they’re free to explore.  Once you see life as an RTS instead of a linear campaign, a lot of “impossible” moves become viable.  You can reroute, rebuild, or even start a new run without throwing away everything you’ve learned.  For me, that mindset makes taking real swings a lot less scary. It’s also a lot more fun this way.

People talk about luck like it’s random. I don’t think it is. Luck is mostly a function of surface area. If you ship once a year, post occasionally, and take calls when they fall into your lap… your surface area is small. If you… - Build in public - Shipping content daily - Ship small experiments - Take discovery calls - Reach out cold - Improve your craft daily - Write about what you’re learning … your surface area expands. Opportunities collide with you because you’re moving. Some of my biggest breaks came from: Posting consistently, hopping on calls even when I was tired, saying yes to uncomfortable projects, and getting better every week. It’s not glamorous, but consistency compounds faster than talent alone. Increase your surface area of luck and let probability do the rest.

Been getting a lot of questions in client calls lately about running agents securely. Here’s how I think about it (3 layers): 1 - Prompt-based security Your system prompt is not a security boundary. If a capability is dangerous, remove it via policy, not instructions. Prompt injection (direct or indirect) will bypass “never do X” guardrails. Treat every external input (web pages, PDFs, code comments) as untrusted. 2 - VM / sandbox-based security Containerize agent execution. But remember: containers share the host kernel. If you actually care about isolation, you’re looking at: - microVMs - gVisor - or fully virtualized environments (Each has tradeoffs.) Agents write throwaway scripts constantly. App-level controls aren’t enough. You need OS-level enforcement beneath the application layer. 3 - Egress / ingress controls Block-by-default for outbound traffic. Use domain allowlists to prevent data exfiltration. But even that isn’t sufficient. A compromised agent can encode data in DNS queries or tunnel via ICMP. You need DNS inspection + anomaly detection layered on top. TL;DR: Prompt guardrails get bypassed. Sandboxes get escaped. Allowlists get tunneled around. No single layer holds. Stack all three.

We don’t consider XORS to be the hero in the story.  It’s the founder or team trying to ship a real product under real constraints.  They want to reach the next round without wasting time or money along the way.  So our role is pretty simple.  We want to be the senior studio you call when it really matters.  When you need: - Tight feedback loops - Product-grade engineering - Taste about what you shouldn’t ship yet We want to be the first company you think of.  When it’s high stakes, you need a partner that gets it done right the first time.

Most people never get to experience the software they could have if someone had really cared.  That’s basically why XORS exists.  We help people experience life through software they wouldn’t otherwise have.  For founders building a legacy or teams sprinting to the next round, we’re the small, senior studio that gets it done right.  You focus on things only you can do, and we make sure the product people touch is something worth remembering.  Our focus is quality, speed, and judgement when you don’t have time to get it wrong.

@oluwabyers DM me and lmk how I can help!

@xBalbinus I know you may have thousands of ideas of project you are planning to work on. So you care to work in partnership with someone who has a great idea for day to day problem solving app?

My first ever product was a website monitoring tool that never really shipped.  I had a landing page, a semi-working app, and a head full of excuses about why it wasn’t ready.  But the truth was, I was scared to put it in front of real people and find out it was mid.  So it died as a prototype.  Just like thousands of other indie projects.  Nowadays, I’d rather ship something slightly ugly and learn fast than polish something nobody will ever see.