Principal Engineer

CampusIQ | North Austin, TX | Hybrid | Full-time

AI is how you build here, not what you build.

This is a building job. You will not manage a team.

Read this part first

We're probably not looking for the best engineer we can find.

A year ago we published a claim with no proof behind it. The best people at AI-native development wouldn't be engineers. They'd be former engineering managers — people who spent years learning what "done" looks like, who made peace with the fact that their value was never in typing.

Then we tested it. Same assignment to senior engineers, junior engineers, and managers.

The managers won. One of them hadn't written production code in years. He's now the number one contributor at this company.

That's the job we're hiring for.

If you run a team today and miss building, this is about you. You didn't stop being a builder. You just stopped getting to.

What we do, briefly

We tell universities how their space is actually used, from the Wi-Fi network they already own. No new sensors.

One large public university thought its buildings were 97% occupied. Only 38% were filled. Another avoided $8M in construction because the data disagreed with the plan.

Twenty-one people. Four engineers. You'd be the fifth.

What the work is

We turned feature delivery into a production line. You draft the work once; the line builds it and ships it. (That's the machine at v1. We run v0.8 today, and we'll show you exactly where the seams are.)

You'd build the rest of the line. New products are coming, and the line that has to carry them doesn't exist yet. That's yours.

Here's the day: decide what gets built, scope it so a machine can execute it, catch it when the output is wrong, ship. The typing is the machine's problem.

Roughly eighty percent of the craft happens before any code is generated. That part is human, and it's the constraint on everything else.

What ownership means here

You get an outcome, not a queue.

Nobody hands you the steps. When you don't know how to get there, the answer is go figure it out — and you won't be punished for that being hard.

You'd be paired with someone from the business side. Neither of you manages the other. Both of you ship.

We don't need someone who punches tickets. I give you a ticket, you give me a PR was never much of a skill, and it isn't one now. That job is gone here, and we'd rather say so than let you find out in month two.

The distinction that matters most

We need people who can tell the difference between "I build software that uses AI" and "I use AI to build software."

Those aren't the same skill and only one of them is this job. If your experience is shipping ML features, that's real work — and it's not this job.

Strong senior engineers are welcome to apply. Our honest worry is scope. This job is accountable for outcomes, not tickets, and most careers on the IC track never required that.

How we measure

Here are the numbers, because you'll be measured on them and hiding them would be unfair.

1. Tokens per day. Are you actually in the tool? Roughly $80 a day is the floor. It's the fastest honest signal that exists.
2. Pull requests per day. Not a target to maximize — a threshold. It tells us whether you've crossed into working a new way, or you're doing the old thing slightly faster. A step change is the signal. A percentage improvement means nothing has changed yet.
3. Business outcomes. Where it actually settles.

Then, later, the one that matters most: when you build something other people on the team start using.

For context on the second number: engineers here each sustain 75+ merged pull requests a week, and three different people have crossed 100.

What we can and can't teach

The first months are hard. We won't dress that up.

Everyone who made it through spent about a month living in the tools before it clicked. There's a stretch in the middle where you'll be slower than you were at your last job, and everyone here has been through it.

Nobody who succeeded here asked to be taught. Before we ever tested them, they'd already spent their own nights and weekends building real things with an early version of the process we run today. Nobody assigned that. They did it because they wanted to.

That's what the assignment is actually asking. Not polish, and not a number of hours. Whether you'll go and do this on your own, the way everyone who has worked out here did first.

We can teach you our system. We can't teach the wanting.

How this works

Start here. Have your AI send us a synopsis of what you built in the last thirty days. Business, personal, we don't care. If you haven't built anything, that's an answer too.

If that lands: install Claude Code and Superpowers, build something you'll use daily in a domain you know cold, ship it, then tell us what you learned. No deadline.

We're not grading polish. The thing we care most about isn't whether it runs. It's whether you can tell when the robot is lying to you. That's the whole game.

They don't need to be convinced. They need to be pointed. If that sentence describes you, we should talk.

How to apply

Complete the form on campusiq.com/careers. Select this role from the position list and include a resume.

CampusIQ is an equal opportunity employer.