10 min read
Aaron Benz
:
Updated on September 9, 2026
We set out to see if four engineers, working with AI, could produce like a team five times the size. What we built along the way changed who can ship, how quickly we work, and what it means to be technical at CampusIQ.
A pull request is a real change to our live software, not a notes file or documentation update. Someone defines what needs to change, the robots do the coding, automated checks make sure it works, and a person reviews it before it merges. Once it does, it’s live and ready for our customers, whether that customer is someone using CampusIQ or someone on our own team.
By early 2025, I was using AI constantly. I’m a data scientist; I love building, and I was making prototypes whenever I had an excuse. Then Opus 3 dropped, and it felt like I had grabbed a bolt of lightning. I spent $7,000 on tokens in two days. Seriously. That weekend made something very obvious to me: the cost and speed of building software had changed.
Around the same time, Chad Walters, our VP of Engineering, ran his own experiment. He took work he normally would have scoped at seven days and finished it in seven hours, even though he had not shipped production code in 15 years. At the time, I had one full-time developer; we had just closed our Series A, and the natural next step was to start building toward an engineering team of around 20 people.
My offer to Chad was basically, “We need to scale to 20 engineers.” His counter was, “No. Let’s figure out how to supercharge a team of four so they can outperform a team of 20 with AI.”
Cool. I want to buy that.
That became the bet, and it changed more than our hiring plan. We did not throw out the company vision, but we did stop treating a long-range roadmap like scripture. By the time a year-out plan reached the finish line, our tools and codebase had often moved so far that pieces of it were already stale. The motion got simpler: solve the problem in front of you. Vision still points the direction. It just stopped booking the calendar.
Buying the bet was easy. Getting everyone else there took 16 months. For five months, the rest of the engineering team stayed under 12 merged pull requests per developer per week while we built the systems behind the scenes. Chad’s numbers tripled in November, while the rest of the team’s actually went down and didn’t start moving until January.
That gap taught us something we didn’t expect: just because the system works doesn’t mean everyone immediately knows how to work with it.
Chad had built it around the way he worked, so naturally, he was the first to see the results. The rest of the team needed time to learn it, trust it, and figure out how it fit into their own work. That roughly two-month lag between Chad taking off and everyone else starting to move became an important part of how we approached AI adoption across the rest of CampusIQ.
March peak on the dashed max is real: one week at 84, then they sat on the 75 floor. That flat is the floor, not a chart bug. July is the step: best week 108, monthly average 74. July is not locked. PR analytics through 2026-08-12, Q3 in flight. Q2 still closes June 30. No names.
As we started shipping more, we had to make sure we weren’t trading quality for speed. More PRs don’t mean much if they create more problems than they solve. We saw two ways this could go wrong, so we built safeguards for both into the way we work.
AI can produce a lot of work very quickly, including work that looks finished when it isn’t. At this volume, there’s no way a person can catch everything by simply paying closer attention. So every change goes through the same gates, with automated builds and testing, mandatory human review, more than 130 automated checks, and sandboxed runs for agents. We have data showing quality holds as volume grows. We just haven’t published it yet.
AI also makes it very easy to build something impressive on Friday and have everyone ready to ship it by Tuesday. But building something quickly and deciding it belongs in production are two different things. That second decision still belongs to a person. Nothing reaches production until someone has looked at what changed, why it changed, and whether it should actually ship.
To make all of this work, we built something we call Second Brain. It’s our internal operating system for AI, built around the way CampusIQ actually works. It gives AI access to our company context, past decisions, workflows, and ways of doing things so it doesn’t have to start from scratch or guess every time someone asks it to do something.
And it isn’t just for Engineering. The same system supports Sales, Customer Success, Operations, Product, and plenty of my own day. Everyone works from the same foundation, with the context for their role already built in.
Anyone across Sales, CS, Ops, Product, or Engineering can start a change based on what they need.
Each department has its own lobe with the skills, docs, and conventions for how the work actually gets done, with 565 skills across 11 roles.
The docs, past work, and decisions are already there. Instead of starting from scratch every time, the model can look up what it needs.
Every change goes through automated tests, human review, 130-plus checks, and a private environment the robots can’t skip.
Once it passes the checks and merges, it’s ready for a CampusIQ customer or someone on our own team to actually use.
Second Brain stacks with the AI models we already work in, including Claude Code, Codex, and Grok.
A lobe is one department’s piece of Second Brain. It holds the skills, docs, and conventions for how that team actually works, teaching the system how we do things and handling the repeatable work through commands. Across CampusIQ, that adds up to 11 lobes and 565 skills.
47 tools on one platform, with 33+ built in-house, plus the CLIs and MCPs behind them.
Credentials, tools, and updates across 31 services are all in one place, so getting into something like HubSpot takes a click instead of editing a config file.
Repos, CLIs, past sessions, and decisions are stored so the model has the context and history it needs to look things up instead of guessing.
PRs, Slack, and structured jobs are where the robots do the typing.
Usage and telemetry that show us who’s getting value from the system, where people are getting stuck, and where they might need help.
More than 130 checks run before work gets through, with the same engineering gates in place for everyone.
Yes. They’re all Norse. We’re nerds.
We named Second Brain on October 21, 2025, and it’s been growing with us ever since. Today, 47 tools live on one platform, more than 33 of them built in-house, turning what CampusIQ knows into something every team can actually use.
Second Brain was working for me and the engineers, but that was only part of the test. We wanted the whole company working this way, and simply giving everyone access wouldn’t get us there. AI changes what people can take on and how they get their work done, which meant people needed more than a login and a training doc. So instead of sending a memo, I wrote a charter, and we worked with people directly until it clicked. These four things made the biggest difference.
We started with a few expectations for how we wanted this to work across the company:
Giving people access wasn’t enough, so we brought teams into the office for three days and worked through their actual jobs. We set everyone up, found the parts of their work that were slow or painful, and fixed them. One salesperson sent 50 outbound emails the afternoon his setup clicked. If someone needed more time on the basics, we stayed there.
Most people get an early win with AI and then hit a point where it suddenly feels harder. The tool’s limitations show up at the same time as your own learning curve, and it’s easy to assume everyone else is getting it while you’re falling behind. We started calling this “the valley,” and simply letting people know it was coming helped. Our usage data also showed us where people were doing well and where they were getting stuck, so we could step in before frustration turned into giving up.
The robots can do the work and run the technical checks, but a person still decides whether something should ship. Every change comes back to three things: what changed, why it changed, and what the risk is. If no one responds within two days, human approval can pass by default. The automated checks never do.
By January, the rest of the engineering team had started to catch up. Then we saw the bigger shift. People in Operations, Product, Sales, and Insight and Strategy started building and shipping things themselves. These weren’t test projects or exercises. They were real problems people saw in their own work and decided to solve, with every change going through the same technical checks and human review before it reached production.
Operations took on something pretty fundamental: how everyone at CampusIQ logs in. They rewrote our authentication system, including native device login and our credential core, despite never having held an engineering title.
Product shipped 13 PRs directly into the admin app, including a “No MAC on file” indicator, a better folder browser, and consent-gated surveys. These are real features in the customer-facing product, and while Product has the authority to merge its own changes, the same technical checks still apply.
Sales built its own tool to handle the federal procurement paperwork that was slowing them down. Six PRs took it from the first version to a live pilot in three weeks, and now the whole Sales team uses it. The problem belonged to Sales, so they solved it themselves instead of waiting for Engineering to put it on the roadmap.
Insight and Strategy addressed six review findings in our ArcGIS integration and built a Slack command for sharing permalinks along the way. This wasn’t a special AI project or something Engineering handed over. It was simply part of getting their work done.
Merged PRs across the same 90-day period, one year apart. This wasn’t one unusually productive week. It was happening across the company.
The same engineer, measured across the same 90-day period one year later, with Second Brain now built into how they work.
Non-engineers went from 32 merged PRs in Q1 2026 to exactly 400 in Q2, with my own PRs left out of the count.
We’ve turned repeatable work and solved problems into 565 skills across 11 roles, supported by 47 tools on one platform and 33+ built in-house.
Our coverage floor is now 90%, which means some of the work we were comfortable shipping a year ago wouldn’t make it through today.
Only 5.9% of merges were five lines or fewer or maintenance work, dropping to 3.9% for non-engineers, while the median change was 447 lines.
I have a confession. I hate meetings. Like most CEOs, I spend more than 30 hours a week in them, but I still wanted to be building alongside everyone else. I don’t think every founder needs to merge code, but if we were asking the whole company to change how they worked, I needed to be doing it too.
In one 30-day stretch, I merged 131 PRs and worked on roughly 50 decks, reports, analyses, tools, and features, all while spending 30+ hours a week in meetings. A year earlier, there’s no way I could have done that much myself.
This is still a work in progress, and we need more people to help us build what comes next. We’re growing quickly and looking for people who are excited to work this way, whether that means building with AI, rethinking how their team works, or solving problems that don’t fit neatly inside a job description. If that sounds like you, show us what you’ve built with AI in the last 30 days. We care a lot more about that than a polished résumé.
This isn’t a typical security role. Twenty-one people ship production code at CampusIQ, many of them through agents and most of them outside Engineering, so we need someone who can build the controls that make that safe as we grow. You’ll use agents to automate those controls wherever possible, with the goal of making security part of how the system works every day instead of something everyone scrambles to prepare for when an audit comes around.
This isn’t a role where you manage a queue and hand the building off to someone else. You’ll own outcomes and ship alongside the team using agents. The system we use to build software is still at v0.8, we have new products coming, and there’s a lot left to figure out. We’re looking for someone with strong judgment, good taste, and the willingness to build the next version with us.
You’d be our first sales leader, which means there’s plenty here for you to shape. You’ll lead the team and still close, while continuing to rethink how we sell with AI. Call prep that used to take two hours already takes about 20 minutes, and we think there’s a lot more room to go. Like everyone else here, you’ll be expected to build and ship improvements to the way your team works.
You don’t have to wait for a role to open or a formal hiring process to get our attention. Find two real problems in your own work, use AI to solve them in a way that lasts, and show us what you built. When you have two, get in touch.
Everybody ships. Yes, everybody.
3 min read
I wrote this in November. I had no proof. Three weeks later I learned I was right. Posted November 10, 2025 The skills that made you a good...
