It has been running long enough that I no longer read every backend PR myself, which was the point. What follows is what I got wrong on the way there, because the interesting parts were never the prompt.

Three layers, and only one of them is a person

Code review used to be one activity. It is now three, stacked, and each one exists to stop the layer above it wasting someone's attention.

Formatting and style is a linter in CI. Not a person, and not the agent either. If an opinion about indentation reaches either of them, the pipeline is broken. This is the layer everyone has already solved and some teams still argue in.

Conventions, architecture and known failure classes is the agent. These work well precisely because they are written down somewhere — and if they are not written down, the agent is the forcing function that makes you write them.

Intent is the human. Should this exist? Is this the right trade? Does the product actually want this behavior? No model has the context to answer that, and pretending otherwise is how you end up with a rubber stamp.

The ordering matters. If the design is wrong, a comment about a variable name is worse than useless — it implies the design passed.

Ground it in your rules, not the model's

The first version reviewed pull requests using the model's general knowledge of the framework. The comments were articulate, plausible, and worthless. It suggested patterns we had deliberately rejected, flagged idioms that are house style, and missed the things that actually hurt us.

The fix was to stop asking it what good code looks like and start telling it. The agent's first instruction is to read the repository's own conventions documentation and everything it links to, then review against that.

This has a side effect worth more than the reviews. Any rule you cannot write down, the agent cannot enforce — so every disagreement about style ends in either a documented rule or an admission that it was never a rule, just a preference. That conversation was overdue on my team by about four years.

Name the failure classes

"Review this pull request" produces a review of whatever the model finds interesting. What you want is a review of the things that have bitten you.

Mine are specific: data crossing a tenant boundary, a new structure built parallel to an entity that already exists, authorization checked at one of the two levels it needs, a method or table duplicating one already in the codebase, and anything on the repository's list of banned patterns.

That list came from production incidents and from review comments I found myself writing repeatedly. It is not a theory of good code. It is a list of ways this particular system has actually gone wrong.

A false blocking finding costs more than a missed bug

This is the thing I would tell anyone building one of these.

An automated reviewer that raises a confident, wrong, blocking objection teaches the team a lesson in about two weeks: this thing cries wolf, skim it. Once that happens, the quality of the reviews stops mattering, because nobody is reading them carefully.

So the calibration is deliberately asymmetric. A blocking finding requires concrete evidence with citable lines. Anything inferred, suspected or reasoned-toward gets downgraded and phrased as a question instead of an assertion. "Is this intentional?" costs the author ten seconds. "This is a security hole" costs them ten seconds, an argument, and a little of their willingness to read the next one.

Severity also has teeth. Only blocking findings reject a pull request. Everything else is information.

Make it argue with itself

The review pass is not the last word. Every finding goes to a second, skeptical pass whose only job is to audit the first one against the actual code and return one of three answers: verified, refuted, or uncertain. It is explicitly told to say uncertain when it can neither prove nor disprove something — an out that makes the other two answers mean something.

The reconciliation is where the thinking is:

for finding in findings:
    verdict = refuter_verdicts.get(finding["i"])

    if verdict == "refuted":
        continue                      # drop it entirely
    if verdict == "uncertain":
        finding["uncertain"] = True   # keep it, flag it
    kept.append(finding)              # anything else: keep, unchanged

That last line is the important one. If the refuter returns nothing, returns a shape nobody expected, or errors outright, the finding survives at its original severity. A malfunctioning skeptic must never be able to quietly downgrade a real blocking finding into a question. The whole block is wrapped in a try, and the except keeps everything.

Every failure mode in that function has been chosen. It fails toward noise, never toward silence.

Let code decide the verdict

The model proposes a verdict. It does not get to hold it.

After reconciliation, a few lines of Python recompute it: rejected if and only if a finding is blocking and not flagged uncertain. That is the one decision I did not want a language model making on a bad day, and it is four lines.

Carried-over findings count the same as new ones. There is no "we already mentioned this" discount — if the problem is still in the diff, the verdict still reflects it.

Humans can overrule it. The author is not a human.

A reviewer nobody can overrule is a tyrant, and one anybody can overrule is decoration.

So dismissals are honored: if a maintainer says a finding is wrong, the re-review lists it under dismissed and does not raise it again. That single behavior did more for adoption than any improvement to review quality, because it turned the bot from something that happens to you into something you can answer.

The list of people who can dismiss is built in code, not decided by the model, and it excludes two groups: other bots, and the pull request's own author. Nobody dismisses findings on their own work. That was not a hypothetical — it is the first thing anyone tries.

What it is still bad at

It cannot tell you the feature is a bad idea. It cannot tell you this abstraction will be painful in six months because it has not seen the six months. It cannot tell you the ticket was wrong.

It also cannot merge anything, which is a design decision rather than a limitation. The layer that has the context to approve is the layer that has the context to be accountable, and that is still a person.

What changed is what that person spends their attention on. Before, it went on conventions, naming, missing authorization checks and the same four comments I had written a hundred times. Now it goes on whether we should be building this at all — which is the only part of code review I was ever any good at.

Standup. Fifteen minutes.

09:40

Standup ends.

09:45

feat: add password reset

The ticket says “simple.” I said it was simple too. Out loud. Where people could hear.

10:40

Quick call.

— So for this you’ll want to fire an event and add a Listener that puts a Job on the Redis queue.

— Wait! What’s a Listener? And a Job? And who is this Redis guy?

11:05

The first eighty percent took twenty minutes. I said two days.

“If you’re still writing code by hand in 2026, you’re already behind.” — 8,400 likes

11:40

Four PRs waiting on my review. Mine can wait.

“I haven’t read code in months. Why would I?” — 12,000 likes

12:30

fix: password reset
fix: password reset (actually)

12:55

I’ll eat after this.

13:52

Four hours. The code was right the entire time. I restarted the service.

fix: restart the service

“AI has made debugging a solved problem.” — 4,000 likes

14:03

I will not be investigating why.

14:20

— Hey, when do you think this will be ready?

I said two days. It has been two days.

14:40

The agent opened a PR. Small, well described, clean diff. It fixes a bug we don’t have.

“We shipped our whole Q3 roadmap with three engineers and an agent.” — 11,000 likes

15:20

The test failed in CI. I ran it again. It passed. I moved on.

15:45

— The startup down the road raised eight million. I looked at their website. It’s a form.

16:10

This class depends on that one, which depends on another one over there. Today I’d build it completely differently. If I touch it now I lose the afternoon.

wip
wip 2
revert: wip 2

16:35

Slack notification. Not now.

Phone rings.

— Thiago, can you look at Slack, I’m stuck.

OK.

— Never mind, got it.

16:50

I did not eat.

17:50

— A customer says he can’t update his password.

What kind of person changes their password on a shopping site at 5:50pm on a Friday?

17:52

Works on my machine.

18:04

The logs say everything is fine. Either the logs are lying or I am.

18:10

— He sent a screenshot in the chat.

18:11

Oh.

19:30

I should do something else for a living. Something less stressful, away from a screen, talking to people. Although I don’t like people that much, and here I can work quietly with music on.

I haven’t left this room since this morning. I’m not complaining.

20:05

test: add the tests I said I’d written

“The model writes your tests now. Stop typing.” — 6,200 likes

20:15

I need a coffee.

Coffee is over!

Until I was eighteen the only piece of technology I owned was a phone without a camera. I wasn’t interested in computers. I didn’t dislike them either. They were just not part of my life in any direction.

When I finished high school I had no idea what to do, so I took a technical course in IT. Not because I felt called to it. Because I understood there would be more job offers.

That was the whole reason. I picked the thing that looked most likely to pay.

The course

First semester: maintenance, networking, programming. I don’t think I need to say which one held my attention.

I was good at mathematics and my logical reasoning was decent, and for the first time that was useful for something other than a test. At the end of the semester I applied for the degree in Systems Analysis and Development. I passed, and for a year I did both courses at the same time.

The internship

After the technical course I got an internship at the institution where I studied. First contact with programming outside a classroom. First reality check.

It was horrible.

I had no idea what I was doing. Too much new information at once, and my main task was maintaining a system built by someone far more experienced than me.

It was the best thing that could have happened.

Nobody explained the codebase to me. I read it. I broke something small and put it back. I found the function that got called from everywhere and suddenly understood why the whole thing was shaped the way it was. Within a few months I was working on my own. The classes started to look useless next to what I was doing outside them. I finished the course anyway.

It lasted two and a half years. By the end of it I had built real software in several different technologies, and I had not yet officially worked a day in the industry. I arrived at my first job already knowing what a real system looks like.

Day one

At the beginning of 2011 I entered the job market properly. On my first day I was told I would be working in a different position from the one I had applied for, with a technology I had never seen.

I stayed.

Lost for the second time in two years, and the second time went faster — not because I knew the technology, but because I had already survived not knowing something. That’s what the internship actually taught me. Not the language. The tolerance.

The first years

From there it was websites and small apps, one after another, and I was learning new technologies constantly because the work kept requiring them.

I was usually the least experienced person in the room, working next to people who had been doing it far longer than me. Almost nothing I learned in that period came from a classroom. It came from building something that shipped, watching it break in a way nobody had predicted, and fixing it while someone more senior explained what I should have seen coming.

That’s the phase that prepared me for the next step in my career.

If I could talk to that intern

Things don’t always make sense at first, and that isn’t a signal about you. The first years are for learning, and for building the resilience to keep going while you’re still confused. The resilience is the part that lasts.

He wouldn’t have believed me. He’d have gone and found out the hard way, which sometimes is the only way it works.

The examples below use a support desk API — tickets, accounts, agents, customers — because the shape is easier to follow than whatever domain you happen to be in.

The code is PHP and Laravel because that's what I work in. The ideas aren't. A template method and a strategy are the same shape in any language with classes, and you'll have your own version of a resource and a validation rule.

Breaking the repository layer into view classes

Every list endpoint needs the same invisible rules. A ticket belongs to an account. Drafts are only visible to whoever wrote them. Tickets on a deleted board don't count. Tickets in an archived queue don't count either, unless you asked for that queue specifically.

Miss one of those in one query and you don't have a bug, you have a data leak.

The usual answer is a scope, or a helper the developer remembers to call. "Remembers to" is the problem.

So the rules live in an abstract base, and the base runs them:

abstract class TicketView implements View
{
    public function __construct(protected TicketViewOptions $options) {}

    public function __invoke(): Builder
    {
        $query = Ticket::query();

        $this->limitToAccount($query, $this->options->user->account_id);
        $this->hideOtherPeoplesDrafts($query, $this->options->user);
        $this->excludeDeletedBoards($query);
        $this->excludeArchivedQueues($query);

        return $this->build($query);
    }

    abstract protected function build(Builder $query): Builder;
}

A subclass never touches __invoke(). It writes build(), which is the only part that makes it different from the others. It cannot skip the scoping, because it doesn't own the entry point. This is the template method pattern: the base owns the algorithm and leaves exactly one step to whoever extends it.

Views and filters both carry a key:

interface View
{
    public function __invoke(): Builder;
    public static function key(): string;
}

interface Filter
{
    public static function key(): string;
    public function apply(Builder $query): Builder;
}

which means a request can select them by string, and the repository assembles them:

public function startView(string $key, TicketViewOptions $options): Builder
{
    return (match ($key) {
        InboxView::key()     => new InboxView($options),
        AssignedView::key()  => new AssignedView($options),
        ReportingView::key() => new ReportingView($options),
        default              => new DefaultView($options),
    })();
}

A dozen view classes for one model, and the security rules are written once.

This isn't "put your queries in a repository." A repository with twelve public methods has exactly the problem the controllers had. The win is that the base class owns the part nobody is allowed to forget.

Declarative resources with lazy resolvers

The second place the same decision gets made is on the way out. One endpoint returns a ticket. Another returns a ticket with its customer. A third returns a ticket with its customer, its assignee and its attachments. Written as three resources, they drift — and the one nobody touches for a year is the one still returning a field that was renamed.

So a resource declares its default shape and its optional relationships separately:

abstract class ApiResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        $this->readRequest($request);

        return [
            ...$this->resolveFields(),
            ...$this->resolveOptional(),
        ];
    }

    abstract protected function baseFields(): array;

    protected function optional(): array
    {
        return [];
    }
}

A concrete resource lists each optional relationship with its key and its own condition:

protected function optional(): array
{
    return [
        new OptionalRelation(
            'customer',
            fn() => new CustomerResource($this->ticket->customer),
            fn() => $this->ticket->customer !== null,
        ),
        new OptionalRelation(
            'assignee',
            fn() => new AgentResource($this->ticket->assignee),
            fn() => $this->ticket->assignee !== null,
        ),
    ];
}

The closure is lazy, so nothing resolves unless somebody asked for it. And they ask in the query string — ?include_customer=1&include_assignee=1. The resolver reads include_ plus its own key and decides.

Nested resources inherit the parameters, so ?include_assignee[fields]=phone reaches the agent resource underneath without the ticket resource knowing anything about agents.

A second resolver handles extra columns. baseFields() returns what everyone gets; ?fields=reference,priority adds more, filtered against a blocklist so nobody can ask for password or token.

One resource per model. Every variation is a query parameter instead of a class.

Enums with behavior

The third place is the smallest and does the most damage. A ticket has a status. What does the status mean?

It depends who's asking. To the agent, awaiting_customer means there is nothing to do. To the customer, the same status means they owe you a reply. Write that as a match in the API resource, then again in the notification, then again in the email, then again in the frontend, and you have four definitions that were identical exactly once.

So the enum answers the question:

enum TicketStatus: string
{
    case AWAITING_CUSTOMER = 'awaiting_customer';
    case AWAITING_AGENT    = 'awaiting_agent';
    case PENDING_REVIEW    = 'pending_review';
    case PENDING_SIGNATURE = 'pending_signature';
    case PENDING_UPLOAD    = 'pending_upload';

    private const NOTHING_TO_DO    = 'Nothing to do';
    private const WAITING_ON_THEM  = 'Waiting on the customer';
    private const REPLY_NOW        = 'Reply now';
    private const REVIEW_AND_CLOSE = 'Review and close';

    public function callToAction(Ticket $ticket, User $user): string
    {
        if ($ticket->isOnHold()) {
            return self::NOTHING_TO_DO;
        }

        return $user->isAgentFor($ticket)
            ? $this->agentAction()
            : $this->customerAction();
    }

    private function agentAction(): string
    {
        return match ($this) {
            self::AWAITING_CUSTOMER,
            self::PENDING_SIGNATURE,
            self::PENDING_UPLOAD    => self::WAITING_ON_THEM,
            self::AWAITING_AGENT    => self::REPLY_NOW,
            self::PENDING_REVIEW    => self::REVIEW_AND_CLOSE,
        };
    }
}

The enum also groups its own cases:

public static function awaitingCustomerCases(): array
{
    return [
        self::AWAITING_CUSTOMER,
        self::PENDING_SIGNATURE,
        self::PENDING_UPLOAD,
    ];
}

and that group is what the filter uses:

$query->whereIn('tickets.status', TicketStatus::awaitingCustomerCases());

The same definition that renders a label builds a whereIn. Add a status and you add it to one list, rather than to a filter and a resource and a notification and a mailer.

A PHP enum isn't a list of constants. It's a class that happens to have a fixed set of instances, and a lot of the duplication I've removed in recent years came from remembering that.

Four smaller ones

Model traits. Behavior shared by several models, without a base class that accumulates everything forever. The models that have children use this one; the rest never see it.

trait WithOpenSubtickets
{
    public function blockingState(): Attribute
    {
        return new Attribute(get: fn() => $this->resolveBlockingState());
    }

    private function resolveBlockingState(): ?string
    {
        return $this->children()
            ->whereIn('status', TicketStatus::awaitingAgentCases())
            ->value('status');
    }
}

Custom casts. Four lines, and every write path is covered — the endpoint, the seeder, the import, the invitation flow, and the one somebody adds next year without reading this.

class NormalisedEmail implements CastsInboundAttributes
{
    public function set(Model $model, string $key, mixed $value, array $attributes): mixed
    {
        return mb_strtolower($value);
    }
}

Rule objects. A validation rule that needs a query belongs in a class, not in a closure pasted into four form requests. One validate() method, testable on its own — a specification, in the older vocabulary.

class UniqueBoardName implements ValidationRule
{
    public function __construct(private readonly int $accountId) {}

    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        $taken = Board::query()
            ->where('account_id', $this->accountId)
            ->where('name', $value)
            ->exists();

        if ($taken) {
            $fail('That board name is already in use.');
        }
    }
}

Route model binding. The cheapest one on the list and the one people skip longest. Type-hint the model and the lookup disappears from every method that needed it.

// Before: the same two lines in show, update, destroy and four others
public function show(int $id): TicketResource
{
    $ticket = Ticket::findOrFail($id);

    return new TicketResource($ticket);
}

// After
public function show(Ticket $ticket): TicketResource
{
    return new TicketResource($ticket);
}

The shape underneath

Look at the three main ones again and they are the same move.

The view base runs the scoping, so a new view can't forget it. The resource declares its fields in one place, so a new endpoint can't quietly invent its own. The enum answers what a status means, so a new consumer can't disagree with the old ones.

None of them stop you from writing duplicated code. They make the duplicated version harder to write than the correct one, which is the only mechanism I've seen survive a team, a deadline and a developer who joined last week.

Duplication isn't repeated lines. It's repeated decisions. Find the decision that must never be made twice, and move it somewhere it can't be skipped.

Behind most comments is a good intention and a bad habit. In nearly twenty years of reading and reviewing code — and more recently, setting up automated review passes — I have almost never been saved by a comment that explained what a method was doing. Most of the time, the comment was an apology for writing code that couldn't explain itself — or worse, a quiet lie.

The comment that tells you what the code already says

The most common comment is the narration:

// Check if the product is active
function check($object) {
    return $object->status === 'active';
}

The author knew the code was vague. check() doesn't say what it is checking, and $object could be an invoice, a user, or an associative array. Instead of fixing the names, they added a sentence above it.

If you fix the method signature, the comment has nothing left to say:

function isActive(Product $product): bool {
    return $product->status === 'active';
}

When code needs a translation layer in English to be understood, the fix is almost never a better comment. It is narrower methods, typed parameters, and names that describe the domain instead of the data structure.

Comments rot faster than code

Code has an advantage comments will never have: it has to run. If code breaks, the test suite catches it or production complains.

A comment has no compiler, no linter, and no runtime verification. It just sits there.

// Returns the current month as a two-digit string
public function getCurrentDate(): string {
    return Carbon::now()->format('Y-m-d');
}

This started as a small refactor: someone changed getCurrentMonth() to return a full date, updated the format string, ran the tests, opened the pull request, and merged it. Nobody updated the comment.

Six months later, an engineer fixing a billing bug reads the comment, trusts it, and spends two hours tracing why an invoice grouped by month is creating a record per day. The code was working; the comment was sabotaging the reader.

The only three comments worth writing

I don't ban comments on my teams, but I treat them as a last resort. If a comment is necessary, it almost always falls into one of three buckets:

1. The bizarre constraint (the "why", never the "what")

Code can tell you what it is doing, but it cannot tell you why an external system forces you to do something unexpected:

// Stripe webhook events can arrive out of order during account reconnects.
// Do not process subscription.updated before customer.created has settled.

No amount of clean architecture can explain a vendor's bug or an odd regulatory requirement. If the code looks wrong on purpose, write down why.

2. The temporary tourniquet in production

Production is on fire, customers are impacted, and you need a dirty five-line fix to stop the bleeding:

// HOTFIX: bypass cache lookup while Redis cluster rebuilds.
// Ticket: ENG-4122 — remove once failover completes.

Use the comment to mark the hack and tie it to a tracked ticket. Then delete both when the real fix lands.

3. Framework configuration files

Configuration files that ship with frameworks — like Laravel's config/ directory — are settings dashboards, not domain logic. Comments that explain valid options and their trade-offs make sense because nobody reads a config file to understand an algorithm:

/*
|--------------------------------------------------------------------------
| Application Timezone
|--------------------------------------------------------------------------
| Sensible default for internal timestamps. Stored in UTC, converted at display.
*/
'timezone' => 'UTC',

If you feel the urge to comment, refactor first

When you finish a function and feel the urge to explain it with a comment, pause. That urge is your brain telling you the code is dense, the naming is ambiguous, or the function is doing three things instead of one.

Extract the private method. Name the boolean variable. Give the parameter a real type.

If, after doing all of that, someone reading the code would still ask "why would anyone do this?", write the comment. Otherwise, let the code speak for itself.

I did the whole academic run: a technical diploma followed by a three-year associate degree in Systems Analysis and Development. Over 3,000 hours sitting in classrooms.

Even before AI, my takeaway was that universities moved too slowly, spent too much time on filler curriculum, and taught almost nothing about how real software gets built and maintained in production.

Today, with tools that can scaffold entire applications, generate database migrations, and debug errors in seconds, the traditional four-year degree is completely divorced from reality.

If you want to become a software engineer today, going to college for programming is the slowest, most expensive way to get there.

What universities spend four years teaching

Look at a typical computer science or software engineering curriculum:

You spend the first year on general education requirements that have nothing to do with programming. You spend the next two years learning toy algorithmic puzzles, setting up basic development environments, and completing isolated homework assignments that never see a real user, a production deployment, or a legacy codebase.

That entire loop has been collapsed. An entry-level programmer with an AI assistant can scaffold an authentication flow, spin up a relational database, and deploy a working prototype before an academic committee finishes debating next semester's syllabus.

Universities update their course material on a five-year cycle. Software development changes every month. Paying tens of thousands of dollars to learn how people built software in 2018 is a bad financial investment and an even worse use of your time.

What actually gets you hired now

The misconception about programming was always that the job was typing code. It never was. The job has always been understanding a business problem, designing a reliable system, and taking responsibility when it breaks.

Now that AI can write the initial version of almost any feature in minutes, the bar for human engineers has moved up, not down. When I hire developers for my team, I don't look for someone who can write an algorithm on a whiteboard. I look for:

1. Architectural judgment: Can you structure a system that doesn't collapse when data volume scales? Do you know where the tenant boundaries are, and how authentication actually flows between services?
2. Skeptical review: AI generates confident, plausible code that is frequently insecure, inefficient, or subtly broken. Can you audit that code, catch the hidden trap, and push back? As I wrote in how I use AI to review every pull request, even an automated reviewer has to prove its findings before anyone should trust them.
3. Execution under real constraints: What happens when an external API times out? How do you migrate a database table with millions of rows without downtime? How do you trace a production bug when the logs are silent?

None of this is taught in lecture halls. It is learned by building, shipping, and breaking real systems.

What the learning path looks like today

If you are starting from zero right now, you have an advantage no previous generation had. You don't have to wait for a professor's office hours to ask a question. You have an infinitely patient senior engineer sitting in your terminal:

1. Build real products from day one

Don't spend six months reading theory before writing your first line of code. Pick a concrete problem — a tool for a local business, an integration you wish existed, a SaaS prototype — and build it.

Use AI to move fast, but never paste code you cannot explain. Make the model explain the trade-offs: "Why did you choose this database schema over a normalized structure? What happens to this queue if the worker crashes mid-job?"

2. Learn systems, not just languages

Languages and frameworks are easier to pick up than ever. What lasts across your career is systems thinking: how operating systems handle processes, how relational databases execute queries, how HTTP and networking work, and how automated test suites protect your code from regressions.

3. Put software in front of real users

As I shared in my first experiences as a developer, my career only gained momentum when I stopped doing isolated exercises and started dealing with real production code that clients depended on.

Build three non-trivial applications. Deploy them to production on a cloud host. Connect a real domain. Set up error monitoring. Find actual users to try them, and fix whatever breaks.

An engineer who can point to three live applications, explain the architectural decisions behind them, and show how they solved real production failures will beat someone holding a four-year diploma every single time.

Final thoughts

None of this means you shouldn't go to college.

If walking across that stage, earning a degree, and celebrating that milestone with your family is a personal dream, that is completely valid. It is an achievement worth being proud of, and nobody can take that away from you.

Just don't confuse personal fulfillment with professional qualification. If your goal is to become a capable software engineer and land a great job in today's market, college is no longer what gets you there. Building real systems, understanding how they fail, and shipping software is.