Scaling Engineering Contributions

Coding agents have made it possible for anyone to contribute to a codebase. As engineers use these tools to multiply their velocity, traditionally non-technical roles are eager to ship to production for the first time.

“Opening the gates” to non-technical contributors might sound like a nightmare to most engineers due to concerns around code quality, opportunity cost, and risks associated with making production changes. But with the right systems and guardrails in place, I’ve found not only is it possible, In some cases it might even make more sense.

Anyone can make code changes, but should they?

At the meta-level, I think we’re slowly seeing a re-distribution of responsibilities as traditional roles begin to evolve. And a lot of this is driven by the fact that in many cases, it often makes more sense to slice the work differently.

See Boris’ take about the Claude Code team:

Boris Cherny

@bcherny

·Follow

As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: comes up with brand new ideas; churns out Show more

11:45 PM · Jun 28, 2026

20.0K

Reply

Copy link

Read 888 replies

My own opinion is that “writing code” is just one activity necessary for shipping a change to production, and we shouldn’t limit it to specialist engineers.

For example, engineers often get blocked when making changes outside their domain of expertise.

A deeply backend engineer working on an LLM system might need to make a small frontend change so that a user can configure a prompt via the UI. In the “before-times” this would have meant you need to pair them with a frontend engineer to align on the schema, make the frontend changes, then test and address any integration issues after all of the changes have been merged.

Nowadays it is fairly easy for the engineer to just go ahead and make all of the changes. Less back-and-forth and people involved means faster shipping, which is great.

Similarly, a completely non-technical role like a designer will be much faster at creating and implementing visual UX polish, as opposed to pairing with an engineer and working through a multi-person feedback loop of iterations.

Does code quality still matter?

Agents can write, review, and fix any problems you might encounter while making changes to a codebase, so what’s the point in caring about what the code looks like?

The short answer, speed.

“Good codebases are easy to change. A bad codebase is hard to change (or hard to change without causing bugs).”

We care about quality because it impacts the velocity at-which we can safely make changes to a codebase as it matures. And this effect is amplified when using coding agents.

I highly recommend listening to this talk from Matt Pocock about Why Software Fundamentals Matter More Than Ever where he argues that:

“Bad code is the most expensive it’s ever been”

I believe ignoring code quality might work for prototypes and new codebases. But as soon as it grows into something more mature, you’ll quickly find diminishing returns on velocity that compound over time.

So how can we mandate quality?

Establish Patterns

Coding agents are similar to humans in the sense that they will copy the patterns around them (or sometimes even worse, introduce a bad new pattern) when in unfamiliar territory. So we should make sure the patterns are expertly crafted and enforced, because they will be copied everywhere.

You’ll want to leverage domain experts (think cloud platform engineer, UI engineer, etc.) to define the patterns and primitive abstractions used throughout the codebase, and then you’ll be able to scale that expertise by allowing non-experts to contribute on top of them.

“In my opinion, agents need mostly the same things humans need to work efficiently: boundaries, constraints, and fast feedback loops. That includes a project structure that is easy to navigate … as well as a fast and reliable test suite. That’s why agents are so good at new codebases, but not very effective on codebases that have grown organically over years.”

A quote from of my favorite engineering blog writers Dominik (@tkdodo) (definitely check out his blog if you’re into frontend/UI engineering), and I think he nails it.

Automated Guardrails & Verification

Before we can safely allow everyone to begin contributing, it’s best to have experts define the foundational patterns and add restrictions to govern the incoming changes.

There are many different kinds of guardrails that can be added, but I’d categorize them into two buckets: deterministic and non-deterministic.

Deterministic

These usually involve some form of static-text analysis and run via script during development, pre-commit/push, or in CI.

Some examples include dead-code detection (we use knip), using a statically typed language (like typescript), module import restrictions (we use eslint-plugin-boundaries and tach, lint rules, and the list goes on.

I love lint rules.

You’ll hear me say this every day.

The ROI for lint rules is huge. They provide a fast feedback loop for agents, surface recommendations for course correction, and are completely deterministic.

For example, the Monaco codebase has a “Clean Component” lint rule I created which enforces that .tsx files contain only:

1. Import statements
2. A single exported React component matching the filename
3. A props type named {ComponentName}Props

Here’s an example of what the result looks like:

import { useState } from 'react';
import { Button } from '@/shared/ui/button';
import { StepBadge } from './step-badge';
import { MAX_VISIBLE_STEPS } from './constants';
import { formatStepCount } from './utils';
import type { SearchPlanStep } from './types';

type SearchPlanPanelProps = {
  steps: SearchPlanStep[];
  onRun: () => void;
};

export function SearchPlanPanel({ steps, onRun }: SearchPlanPanelProps) {
  const [isExpanded, setIsExpanded] = useState(false);
  const visible = steps.slice(0, MAX_VISIBLE_STEPS);

  return (
    <div>
      <p>{formatStepCount(steps)}</p>
      {visible.map((step) => (
        <StepBadge key={step.id} step={step} />
      ))}
      <Button onClick={onRun}>Run</Button>
    </div>
  );
}

// enforcing strict conventions means it doesn't matter
// who the author was. The code style is always the same.

It sounds simple enough, but you’d be surprised how much time this saves during code review.

Any time someone leaves a comment on a code review, I am always looking for a way to automate that opinion via a lint rule. There is absolutely no reason for wasting time calling out code style and conventions on PR’s when the enforcement can be automated (and shifted left in the process).

It has never been easier to create a custom lint rule with the help of agentic coding tools, so you should create many of them where it makes sense!

Non-deterministic

You won’t always be able to enforce an opinion deterministically, specifically when it requires real judgement. And this is where we can leverage agents as judges.

At Monaco we’re utilizing agent-only executable skills to codify engineering opinions into a library of best practices, which are available during implementation.

Here’s a small snippet from the copy-writing skill in our web service:

## Buttons

Labels should be sentence-case (with capitalized proper nouns including domain entities) and use imperative verbs. They should be action-first and specific about what will happen.

Example 1
Good: “Add Contact”
Bad: “OK”

Example 2
Good: “Delete Campaign”
Bad: “Delete”

“OK” and “Delete” are syntactically fine strings, but in order to know they are bad you have to understand what the underlying onClick function does (calls addContact or deleteCampaign) and judge whether the label exhibits the intent well enough.

This can’t be enforced with a lint rule, so we document it as a skill and make it available to agents during implementation and review.

Code Review

I don’t think anyone particularly loves performing code review, but it’s the final line of defense. This is where domain experts should be leveraged to ensure nothing dangerous makes it into production.

“Code review is the bottleneck”

I haven’t been able to go a single week without hearing or reading about this somewhere in the last few months, and it’s true.

Manual code review is expensive and time-consuming, so It’s important to automate as much of the process as possible. The “Automated Guardrails & Verification” I mentioned earlier are all in service of this goal.

In addition to the above, we’re using Devin as our AI reviewer, which loads a codex of skills into context, triggers automatically when opening a pull request, and performs a first-pass before any human reviewer is involved.

The manual review part can be painful, especially when you allow more contributors, but I’ve found it to be the best way to identify opportunities for automation (unwritten lint rules, etc.). And in my opinion, this area is evolving quickly and will probably look very different soon.

What’s on the horizon?

I think the industry is converging on a few common notions:

1. If we want to ship faster it isn't possible to read all of the code
2. We should automate code review / verification as much as possible
3. We will soon shift our energy to higher-level activities like aligning on high-level technical design and what the outcome of a code change should be

We’re just starting to scratch the surface of what can be automated, and there are a lot of interesting ideas floating around.

Uncle Bob Martin

@unclebobmartin

·Follow

Replying to @wookash_podcast

I don’t review code written by agents. I measure things like test coverage, dependency structure, cyclomatic complexity, module sizes, mutation testing, etc. Much can be inferred about the quality of the code from those metrics. The code itself I leave to the AI. Humans are Show more

6:04 PM · Apr 14, 2026

1.3K

Reply

Copy link

Read 63 replies

Yep that’s an uncle bob tweet, and even though I don’t necessarily agree with everything this guy says, I think some of the ideas are interesting.

After you’ve automated away the easy parts of code review, what remains is usually “alignment” or “why are we making this change and is the outcome correct”.

In my mind, the next logical step is to shift away from code review and more towards “plan” review, and I’m excited to move in this direction.

Anyone can contribute

At Monaco cross-specialty PR’s between engineers are common. Designers and PM’s are writing production code where it makes sense to leverage their non-technical skills (while becoming more technical each day).

And I’ve personally found a lot of joy in helping build an automated system that allows anyone to write clean code.

“Make doing the right thing easy”

This is easily my favorite mantra right now. It can apply in so many situations: Design, UX, etc., and it’s a really important mindset to adopt if you work on any kind of developer tooling.