Subscribe now

Spend any time on r/cscareerquestions and you will eventually find someone asking whether they really need a degree to get a software job. The question always has a quiet second half it doesn’t say out loud: because that would be easier.And the answers are always some version of the same thing. If you can go to school, you should.

That advice is correct. It is also useless to about half the people who need to hear it, and nobody ever says which half.

Here is the part people get wrong. They argue about whether the two paths are equally hard, and the polite consensus is that they’re just different roads to the same place. I don’t believe that, but not for the reason you’d expect. I’m not going to tell you my way was more work. A computer science degree with four real internships is a brutal amount of work, and any kid grinding LeetCode at 2am on top of eighteen credits has earned the right to roll his eyes at anyone claiming otherwise. That’s not the argument. The two paths aren’t hard in the same way, and that’s the whole thing.

The clean path is hard like a marathon. It’s grueling, it’ll wreck you, but there are mile markers the entire route, everyone agrees on where the finish line is, and if you keep putting one foot down you will get there. The other path is hard like being dropped in the woods and told there’s a road out here somewhere. No markers, no map, no way to know if the direction you picked is right, and no guarantee the road exists where you’re walking. One is hard in effort. The other is hard in uncertainty. Same locked gate at the end of both, but only one group gets handed directions on the first day.

The gate is the same for everyone

Almost nobody gets into this field with zero experience, which surprises people. There’s a minimum, and it seems to hover around a year. The college path solves this so quietly that most people don’t even notice it’s a requirement. Four summers, three months each, one internship at a time, and you walk across the graduation stage with a year of experience already on the resume. The math does itself. You can show up with two bachelors and a masters from anywhere, and if you skipped the internships you’ll still struggle to land the job you think the diploma entitles you to, because a 22-year-old who has only ever performed in a classroom is a risk nobody wants to underwrite.

So the requirement is real, and it’s identical for everyone. Get a year of experience before anyone will give you the job that gives you experience. The college kid satisfies it without ever having to look at it directly. It’s built into the route, one of the mile markers, passed automatically. For everyone else the same gate exists, except no one tells you where it is, what counts, or whether the decade you’re pouring into it counts for anything at all. That’s the woods. Not less work than the marathon. Just no markers, and no way to know you’re walking toward the road.

The window

There’s a window where trading a degree for a career actually works, and it’s narrower than it looks. It opens in high school and starts closing somewhere around 24. Before it shuts, the clean path is genuinely clean: good grades, decent program, hold a 3.0, get the internships, graduate into a job. Low variance, high success rate, well-lit the entire way.

After it closes, you’re a 27-year-old with a full-time job and maybe a family, and “just go to school” stops being advice and starts being a thing people say to feel helpful. Technically the door is still open. Practically, you’re not quitting your income to chase four summer internships against kids ten years younger. The path that works for the 18-year-old doesn’t transfer. This is who the essay is about. Not the people the standard advice serves. The people it waves at on the way past.

Ten years of building things for no reason

I compiled my first Linux kernel at 14 to turn on hyper-threading for a new Pentium 4. My first taste of Linux was Fedora Core 3, and my first daily driver was Ubuntu 5.10, Breezy Badger. Back then the first thing you did was edit your xorg.conf, because your resolution was stuck at 800x600. You didn’t expect Wi-Fi to work. You were doing well to have sound. Wobbly windows and a spinning desktop cube and real transparency were the cutting edge, and transparency only worked against the desktop, so a see-through terminal over your browser just showed you the wallpaper underneath. Ubuntu was a genuine leap, mostly because the forums wouldn’t eat you alive for asking a question, but you could still fill entire weekends getting the machine to simply work, trying something dumb, breaking it, and starting over. For some reason that was the fun part.

Once Debian stopped fighting back I moved to Arch to get the difficulty back. Then one computer wasn’t enough, so I put a ThinkStation S30 next to my bed and discovered Foreman and Katello, FreeIPA, KVM and Qemu and Libvirt, OpenVSwitch. I had almost nothing to host. It didn’t matter. I built a provisioning platform anyway, the kind where a new VM came up with DNS already set, identity handled by a central server, my SSH keys installed, a user account waiting, and NFS home directories that mounted themselves. For machines that existed to host nothing. I built it because not building it felt worse.

Here’s the thing I need to be honest about, because it’s the whole point. None of this was strategy. I wasn’t grinding toward a career. At 17 I got into photography and did it professionally for years, partly because I was afraid that turning computers into a job would ruin the one thing I did purely because I liked it. I used the open-source photo tools, GIMP and Darktable and DigiKam, and it was brutal, and I did it on a System76 laptop until I finally bought a Mac and switched to Adobe and never looked back. macOS was Unix enough to feel like home once I actually needed to get work done instead of admiring the machine.

So that’s ten years of accumulating exactly the skills that would one day make me valuable, with no target, no mentor, no internship counter ticking upward, and no signal whatsoever that any of it was leading somewhere. The college kid spends four years aiming at a thing they can see. I spent ten aiming at nothing, because aiming wasn’t the point, and I had no way to know whether a single hour of it counted. It turns out you run out of interesting things to do without the scale and the stakes a real job provides. But you don’t learn that until much later, and plenty of people who walked into the same woods never walked back out, because nobody ever read what they’d built. That isn’t the sad part of the story. It’s just the variance. The marathon, everyone who trains finishes. The woods don’t work like that.

The green resume

At 27 I decided to point the skills at a better life. I was in Tampa Bay with no connections into tech, so I enrolled in an associate’s that fed into a bachelor’s, mostly to build a network I didn’t have. The program ran an extracurricular where local tech leaders came to talk at us, and the talks led nowhere except a mixer at the very end.

One of them walked in looking like he’d come as a favor and regretted it. I wasn’t even thinking software at the time. I was thinking data center buildouts, Linux infrastructure, the operations side. But the coordinator introduced me as a programmer, and when the guy asked what I wanted to do, I said I wanted to build developer tools. Which was true. I just hadn’t believed there was a path to it from where I was standing.

He gave me an interview. My first one. They took me to lunch and then spent the rest of the day passing me between developers and managers, and at one point set up a conference call and left me alone in a room talking into a speakerphone. I hadn’t built the muscle for breaking down problems on a whiteboard yet, so when they handed me the simple ones, I bombed. My resume didn’t help on paper. It had a green left rail, no relevant work experience, and instead of a job history it led with projects, the tech I’d taught myself, the things I’d gotten working. For the rest of the day I was “the green resume.” It was a Microsoft shop, so when I talked about Foreman or FreeIPA, it mostly didn’t land. Nobody in the building had a reason to know what it took to make those things work.

Except one of them did. A release engineer, thick French accent, and I caught maybe every third word he said. But he read the resume the way it was meant to be read. Near the end he asked, completely seriously, whether I’d be okay working in a Microsoft shop, and the question was funny because he’d already figured out exactly who I was: someone who grew up on Linux and avoided Windows on principle. I told him I needed a job. Everybody liked me. The whiteboard still got me a clean no at the end of the day, and they told me to work on my algorithms and come back in six months.

Two months later they called and offered me a job anyway. A role they were creating, the pilot for an apprenticeship program. The thing that got me through the gate wasn’t the interview, which I failed, and it wasn’t the degree, which I’d barely started. It was that one man in one room could look at ten years of building things for no reason and see what they were.

That’s the part the clean path never has to think about. The 18-year-old’s experience is legible by design. Four internships read as four internships to anyone holding the resume. Mine needed a translator, and for most of a decade there wasn’t one in the room. The hard part was never the work. I’d have done the work regardless, because it was the fun part. The hard part was carrying a decade of it around in a language almost nobody could read, and needing to get lucky enough to stand in front of the one person who could.

Subscribe now

I ship faster than any team I’ve been on. I have less code in my head than I’ve had in years. The app is fine.

This is not another “I don’t read the code” post. Peter Steinberger wrote the canonical version of that argument in Shipping at Inference Speed, and the methodology has become well-trodden ground in the year since. He’s right about the velocity. The argument I want to make is different. It’s about what the velocity means for the companies you’ve worked at, and why most of them can’t replicate it even with the same agents and the same engineers.

This post is about what I actually do all day, what makes it work, and why most companies you’ve worked at have been optimizing against the wrong constraint for a decade.

What I actually do

The job, as it shapes itself when you’re solo with three to six agents and a roughly one-and-a-half-million-line codebase, is to be the decision engine. The agents are very good at writing code, very good at proposing architectures, and structurally incapable of deciding which architecture is right given the things they don’t know. The product. The user. The runway. The strategic frame. The seventeen decisions already locked upstream. That part is mine. They surface tradeoffs, I pick.

I work with one chat-based agent for design, architecture, and product decisions, and treat the coding agents as a workforce. The chat agent is a colleague I think with. I configured that agent before I ever asked it a question, with explicit instructions to push back, surface assumptions I don’t notice, flag when it’s filling gaps with reasoning biased in my favor, and refuse the compliment sandwich. I designed the colleague before I hired it. The deciding muscle works better with a counterparty that’s been told, in writing, to disagree with me when I’m wrong.

I read code when I have a question, not as a default review activity. I ask for audits. Run a stub-and-mock-data audit on the new module. What do the benchmarks look like under load. Is the data flow consistent with the canonical entity, or did you re-derive it locally. The answers tell me where to look. I look there. I close the loop. I move on.

I tried, for a while, having agents narrate every change in detail before I approved it. I got bored. I’d be holding a bunch of information in my head that was going to be useful only if I had to take over and hand-write the code, which I increasingly do not. The information had no other home. It wasn’t building a model of the system. It was a flashcard deck for a quiz I was never going to take. Reading agent-written code from this morning doesn’t teach you the codebase. It teaches you what the agent did this morning, and that’s a much shallower thing than people realize.

Why this looks reckless to people who haven’t done it

The objection I hear most often is security, and I want to handle it carefully because there are three different things people mean by it, and only one of them is real.

The first is: agents write insecure code. Static analysis, secret scanning, dependency audits, pre-commit hooks, automated testing, and audit passes by a separate model scale with throughput in a way human review doesn’t. Line-by-line human review is a weak, non-scaling control, and most teams overestimate how much safety it actually provides. A skilled reviewer catches things automation misses, especially around business logic and authorization boundaries. The honest claim isn’t that humans add nothing. It’s that the cost of being the gate has gone up faster than the marginal safety humans provide, and the gates that scale are the gates that matter.

The second is: subtle authorization and business-logic bugs will slip through if you’re not reading line by line. Humans miss those bugs too. They’ve always missed them. Subtle bugs are caught in production, in pen tests, in postmortems, in the moments when a real user does something nobody designed for. The discovery channels are the same whether the code was written by a human or an agent. My working assumption is that throughput goes up, absolute bug count probably goes up, and the meaningful question becomes defect rate per shipped unit plus recoverability, not whether any bug slipped through. That’s a gate problem, not an agent problem.

The third is: the agents themselves are a new attack surface. Supply chain risk, prompt injection in AI features, training-data-encoded bad defaults. This one has real teeth. It also has nothing to do with whether you read the agent’s code. It has to do with what the agent is. That’s a different post.

The version of the security objection that goes “you’re not reading every line so you’ll miss something subtle” is mostly engineers describing the workflow they’re used to, dressed up as an argument. The throughput is real. The quality is real. You can disagree with the bet I’m making. You can’t disagree with the codebase, which is fine.

Agents reviewing agents

Here’s what people actually mean when they panic about agents reviewing agents. They imagine one model writing code and the same model approving it, which is a vibes review and useless. That isn’t what the work looks like.

The implementer is one model, usually Codex. The reviewer is a different model. Different family, different training, different failure modes. Each commit goes through atomic review. The implementer requests a review, the reviewer returns a decision with severity-classified findings, and any P0 or P1 issues have to be resolved before the loop moves forward. P2s and P3s can be deferred, but if they are, an issue gets filed against the project. Re-review carries the original review context with it, so the reviewer can see whether the fix actually addressed the finding or just changed the surface. The loop iterates up to three times before it hits a circuit breaker and escalates to me. Two iterations is common. The circuit breaker fires rarely.

After the implementation loop, a separate test-writing loop runs with a different prompt. The reviewer’s job in the test loop is to find gaps in behavioral testing, not line coverage. Missing assertions, trivial assertions, integration paths that aren’t actually exercised. That distinction matters more than anything else in the pipeline, because if I can’t trust the tests, I can’t trust the rest of the gate either. Linters clean, warnings fixed, full test suite passes, build green. Then the commit lands.

This is more rigorous than what most engineering teams are actually doing. The PR review process at most companies is quietly devolving into engineers running the same single-model assistant on each other’s diffs. Same model on both sides of the review. Same blind spots. Same things missed for the same reasons. Two engineers with Claude reviewing each other’s Claude-assisted PRs is not two layers of review. It’s one layer with a procedural ritual on top.

Cross-model review is harder to set up than that, which is why most companies don’t do it. They’re standardized on a single vendor. License costs, compliance review, security review, vendor management. Getting a second model family approved at a typical enterprise is a quarter-long project at minimum. So the engineers who should be running cross-model review can’t, the engineers who route around it on their own get told they’re being reckless, and the engineers running single-model review call it discipline. Single-model review catches things. Cross-model catches different things, and in practice that matters more than most teams want to admit. The thing that would actually catch the most bugs is the thing the org won’t let them have.

There’s one more layer worth mentioning because it sets up what comes next. The agents don’t only review code. They review plans. An implementer working on a ticket has to write an implementation plan and request a plan review beforewriting any code, and that plan review goes to a different agent. Plan review, implementation review, test review, deferred-issue tracking, three-loop circuit breaker with escalation to me. That’s the gate. It catches a lot. It does not catch everything, and the methodology that fills the rest of the gap is the next section.

Audit-driven development

The methodology I run is audit-driven. It’s not a refinement of test-driven or spec-driven development. It’s a different shape, built for a workflow where implementation isn’t the bottleneck. The shape: before any cross-cutting implementation, an agent maps the existing surface, identifies non-obvious findings, surfaces decisions in numbered form, and waits for me to lock them. Only then does any code get written.

It works because the bandwidth math changed. A solo human engineer doing thorough discovery before every cross-cutting change is exhausting and rarely justified. Agents don’t have audit fatigue. A thirty-minute trace-through-everything pass costs them roughly nothing. I read a structured findings document instead of doing the discovery myself. The asymmetry is the point.

Four examples from a single recent session, each picked because it shows a different kind of finding the implementation gate alone would not have caught.

The PrepPage navigation bug. An agent was scoped to find the right inspector target for a small UI retrofit. The audit came back with: the navigation goes to the wrong route entirely. The draft is reviewed at one route, but the existing code navigates to a different route, which has zero draft awareness. Users are stranded today. That’s a production bug, live, visible to real users. A spec-first or test-first approach does not surface it. The spec said “navigate to identity,” the test said “verifies navigation occurred.” Both pass. Users get stranded. Only an audit asking what does the user actually see when they land finds it.

The orthogonal-dimension discovery. Another agent was scoped to retrofit a single button. The audit came back with: this affordance can’t work cleanly because the bridge is missing an orthogonal dimension. “Where to land” is actually two concepts: which slot’s inspector to open, and which region of the page to scroll to. The existing query parameter covers the first. We need a second one for the second. That’s an architectural improvement discovered as a byproduct of trying to use what existed. A spec-first approach locks the architecture before discovery. The audit produces the architectural insight while doing the implementation work.

The reconciliation task. One whole task this week shipped as audit and correction with zero functional code change. The parent task and five subtasks all referenced a workbench component that had been retired by a different commit weeks earlier. A documentation page was stale on the same point. Master-list editing now lives somewhere else entirely, and the references hadn’t been updated. The kind of decay that compounds invisibly until someone tries to use the affordance and discovers it points at retired code. Audit-first found and fixed it before that confusion hit any consumer.

The cross-track stash. An agent picking up a ticket noticed nineteen failing tests at HEAD before they started any work. Without verifying those were pre-existing, work-in-progress from parallel agents on other tickets, they would have claimed damage they didn’t cause when their own changes landed. They stashed, verified the failures were not theirs, unstashed, and only then claimed clean shipment of their own work. That’s audit discipline applied to the agent’s own work product, not just the codebase. Same shape: don’t assume; verify; structure the finding.

What ties these four together isn’t the methodology. It’s that in every one of them, the audit surfaced a finding I had to act on, and acting on it required exactly the authority that has been taken out of most senior engineers’ jobs at most companies. The PrepPage decision: accept the production bug, fix it, change the navigation contract. The orthogonal-dimension decision: extend the bridge architecture. The reconciliation decision: retire the references, restructure the task. The cross-track decision: accept that nineteen failing tests are someone else’s problem, ship clean. Every one of those is a decision an engineer at most companies wouldn’t be allowed to make alone. Architecture would weigh in. Product would weigh in. A retro would happen later. The audit would still surface the finding. It just wouldn’t get acted on in the same hour.

That’s the part of the methodology you can’t bolt onto an existing org. Not because the methodology is hard. Because the authority isn’t there, and the reason it isn’t there is structural, not personal. The next section is about why.

The bottleneck shifted

Here’s the part of the argument that’s going to land hard, and I want to be precise because it’s easy to get wrong.

Engineering work used to have a clear bottleneck: implementation. Writing the code was slow, error-prone, and the rate-limiting step on most projects. Most of how engineering organizations are structured today was built around that constraint. You divided the work because no one person could implement enough of it. You specialized roles because deep expertise in any one domain took years. You added review processes because the cost of bugs was high relative to the cost of catching them. You added product managers, designers, architects, tech leads, security reviewers, platform teams, each one of them owning a slice of the decision space, because coordinating implementation work at scale required someone to make the call about what got implemented next, and no single person could hold all those decisions.

Agents broke the constraint. Implementation is no longer the bottleneck. A solo engineer with three to six agents can produce more functioning, tested, audited code per week than most teams I’ve worked on. The thing that’s slow now isn’t writing code. It’s deciding what code should exist, in what shape, with what constraints, fitting which other parts of the system. The decision pipeline is the bottleneck, and the decision pipeline at most companies is fragmented across the roles that were created to coordinate implementation work that’s no longer expensive.

Most engineering organizations are now optimized against the wrong constraint. Their coordination mechanism, the fragmentation of decisions across roles, was the answer to a problem that no longer exists at the same intensity. They can’t dismantle the fragmentation without dismantling the coordination they depend on. That’s not a temporary mismatch. It’s a structural one.

The “I review every line” speech is a response to that structural condition. Not a personal failing. The senior engineer’s day was hollowed out by the same fragmentation that’s now choking on the decision bottleneck. Their attention was redirected toward implementation review because that was what the org needed from them when implementation was hard. Now implementation is cheap, the role hasn’t been redrawn, and the attention is still going there. The attention is doing what it was trained to do. It’s just doing it on the wrong layer.

Why most companies can’t close the gap

Some companies can close the gap. Not many.

AI-first startups with small teams and compressed decision pipelines can. The kind of place where the founder, the lead engineer, and the product person are sometimes the same human or three people on close-quarters Slack daily. The fragmentation never set up there. Those companies can absorb agent throughput because their decision pipeline was already short.

Some engineering-led shops can. Companies where senior engineers have real authority over architecture, where the chain of approval is short, where the culture trusts the people closest to the code to make the calls. These are rare and getting rarer, but they exist.

Most mid-sized to large engineering organizations can’t. Not because they’re stupid or slow or badly run. Because the coordination mechanism that made them functional at their current size is the exact mechanism that’s now slowing them down. Dismantling it would mean retooling the org chart, the planning process, the review cadence, the budgeting cycle, the political settlements between product and engineering and design that took years to negotiate. Most companies will not do that. Some will try halfheartedly, get six months in, declare it didn’t work, and go back to the previous shape. The forces preserving the old structure are real, and most of them aren’t bad-faith.

What companies will do instead, what most are already doing, is bolt agents onto each existing role. Each PM gets an agent to draft tickets faster. Each designer gets an agent to produce mockup variations faster. Each engineer gets an agent to write code faster. Each reviewer gets an agent to review faster. That’s automation per role. It’s not transformation of the work shape. The decision pipeline still has the same number of stops. Each stop is now slightly faster. The aggregate throughput improvement is real and modest. It will not match what a solo operator with the same agents and clear decision authority can do.

The gap widens. Solo operators on product engineering work, building a product, shipping features, iterating on architecture, will continue to outpace mid-sized engineering organizations working on the same kinds of problems, by a margin that compounds.

Two qualifications worth being explicit about, because the claim is strong and the wrong reading of it is unhelpful.

First, this is about product engineering work specifically. Building applications, shipping features, iterating on the system that meets the user. It is not a claim about all engineering work. Regulated industries, security-critical infrastructure, legal-heavy work, anything that requires deep specialist expertise per domain, still benefits from genuine specialists. The asymmetry is real but not universal.

Second, “can’t close the gap” is shorthand for “most can’t, in the current shape, without changes most won’t make.” A company with the appetite for actual structural reorganization can. The number of companies with that appetite is small, and their willingness to act on it is smaller. The asymmetry is durable for the foreseeable future not because change is impossible but because the change required is unpopular with the people whose roles depend on the existing fragmentation.

I realize this sounds elitist. I don’t have a softer version. The honest claim is that solo engineers running multi-agent loops on product engineering work are in a structurally favored position relative to most teams, and the structural advantage is going to widen rather than narrow over the next several years. An engineer can start a tech company solo, build the MVP, ship it, get funded, and then hire. It happens all the time. The number of people who’ve started a tech company by hiring an engineer first and telling them what to build is vanishingly small, and the ones who tried mostly didn’t ship. The asymmetry that’s already true at the founding stage is now showing up at every stage of product engineering work, because the bottleneck is no longer something more headcount can fix.

The model I already paid for

I want to close on the part of this that’s actually personal, because the structural argument depends on it.

I built the model the hard way. Not the model I’m running now. The model that lets me run the model I’m running now.

I’ve reverse engineered codebases written in frameworks you’ve never heard of, frameworks that hit end-of-life eleven years before I touched them, frameworks where Google could not save you because the questions had been asked and answered and the answers had since rotted out of every search index on earth. I’ve inherited products from acquired companies whose latest contractor had blamed the contractor before that, who had blamed the one before that, going back through enough layers of finger-pointing that the original code’s author was untraceable. I’ve found a tarballed Linux filesystem checked into git because that turned out to be how a device’s firmware was built, and figured out how to build it, because if I couldn’t, an entire product line was at risk. The most important tool I had for many years was a diff tool. Not an IDE. Not a debugger. A diff tool, used to compare what was supposed to be there to what was actually there, often with weeks of work between the two.

That’s where the model came from. Not from review. From desperation, repetition, and being trapped alone with code that nobody else on the planet had in their head. After enough hours of that you start to know things you can’t quite explain. You read a file and something feels wrong before you can name what. You ask an audit question and the answer either matches your gut or doesn’t, and when it doesn’t you know to keep pulling the thread. That’s what taste is. That’s where it lives. It’s not a thing you teach in a code review.

For most of my career, that was a moderately valuable skill. The kind of thing that made me useful on legacy projects nobody else wanted to touch and on acquisitions that came with horror stories. It was niche. It paid the bills. It wasn’t the central skill the field rewarded.

What changed isn’t the skill. The skill is the same. What changed is that agents took the implementation work, the central thing the field rewarded for thirty years, and made it cheap. The skill that was niche became the skill that determines who gets the throughput multiplier and who doesn’t. The model I built reading the same code for the twentieth time, in frameworks that defeated Google, became the thing that lets me operate three to six agents at full breadth on a million-and-a-half lines of code without losing the architecture.

The asymmetry runs deeper than the throughput, and this is the uncomfortable part. The companies that can’t close the gap also can’t grow the kind of engineer who closes it. The structure that fragmented decisions also kept engineers out of the conditions where the model gets built: alone with a system nobody else has in their head, no senior engineer above them, no architecture review meeting catching drift, only the diff tool and the codebase and the time. That’s not a place the modern product-engineering pipeline puts people.

Here’s the bet, and it is a bet, and I want to be clear about that.

I’m betting the model I built the hard way still works. That an audit at the right moment is worth more than a thousand reviewed diffs, because the audit is the model deployed, not the model being assembled. That recoverability beats readiness, that I can re-acquire context faster than I could maintain it, and that the gates around the codebase catch the things my attention would have been catching if I’d tried to keep my attention on everything.

The dangerous part of this bet is that codebases don’t always tell you immediately. They tell you six months later, through drift, through brittleness, through a user path nobody audited. The bet isn’t that nothing will break. The bet is that the audit loop finds drift faster than traditional review prevents it.

So far, it has.

Subscribe now