Skip to content
kevinferron.com

Software development philosophies · An argument from my own pages · My opinion

Who to hire now

The engineer I would want on a team has changed, because of language models, agents wired as graphs, and vaults of notes that agents read and write. This is my opinion, and every point on it comes from a Lab page where I already made it.

The claim

My opinion

A company should focus on the core of its business. I keep coming back to that, and this page looks at it through hiring. The engineer worth having keeps the team on that core by judging what to build, and above all what not to build. I see that as build versus buy, extended.

One of several pieces on the theme, this one.

Three things changed the job: language models that write code, agents wired as graphs with budgets, receipts and gates, and second brains, the vaults of notes that agents read and write. They make building cheap. So choosing what to build is the hard part.

This page is my opinion. It has no hiring statistics and no story from any hiring round. Every point below is one I already made on another page of the site, in my words from that page, with a link to it. The one outside source is Dan Luu.

What mattered before

The profile I’m comparing against treats writing the code as the scarce work. You hire people who produce a lot of correct code. To grow the team, you add more of them.

“The mistake is measuring work in one number, so that doubling the workers halves the time.”
From More people, more agents, same plan

Judge what to build, and above all what not to build

The spine of the piece

The cost of writing code used to do the deciding: a build was expensive, so only the clear cases got built. Now an agent will build almost anything you ask for in an afternoon, so the scarce skill is judgement about what to build. And above all, what not to build.

I think of it as build versus buy, carried down to every feature, every script and every agent. Does this need to exist? Is there already something that does it? Who keeps it running once it ships? I wrote the small-business version of those rules for software spend.

“Because most businesses don't need a build.”
From The Software Checkup
“Build when your process has settled.”
From The Software Checkup

What else it takes

Six more traits follow, and I tie each one to the page that argues it. They serve the spine above. They’re how a small team builds its core well, checks it, and keeps everything else out. For each, I name the old habit, then give my words from the page.

1. Say what done looks like before anything is built

Before, whoever wrote the code decided when it was done. Now the first skill is writing the checks. The loop builds until code says they pass.

“Say what done looks like, as checks that can be run.”
From One loop, three models
“Write down what done looks like as checks, then build until code says they pass, with a person before anything ships.”
From What people mean by a harness

2. Read generated work as if someone else wrote it

Before, you reviewed a colleague’s change. Now most of the diff may have no colleague behind it. Reading it is the job.

“Read the whole diff as if someone else wrote it.”
From One loop, three models
“one place checks the pieces together before they merge”
From More people, more agents, same plan
“nothing ships through my loop without a receipt for this exact content”
From Traces, checkpoints and receipts

3. Write things down for the next reader, person or agent

Before, what a team knew could live in people’s heads. Now an agent starts every session knowing only what’s written down. So writing it down is part of the work.

“What belongs in the vault is what the next reader will need and cannot reconstruct”
From Writing back
“The vault-on answers differ because of these, not because the model is cleverer.”
From Read before you act

4. Decide what code decides, what a person decides, and when to stop

Before, process lived in a wiki and in habit. Now someone has to design the graph. It sets where the gates are, who approves what, and what a run may spend.

“code for anything a script can decide, a person for anything that cannot be undone, and a model for neither”
From Designing an agent graph
“if the same gate has failed three times for the same reason, stop and report what was tried”
From Designing an agent graph
“a model asked whether its own work is finished tends to say yes”
From Designing an agent graph
“a note that says “never repeat a login” asks; it does not stop anything”
From Permissions and privacy
“scoring a call is half of a gate, and the other half is a decision about the calls it holds back”
From Gating an agent’s action

5. Cut the plan before adding workers

Before, a bigger backlog meant a bigger team. Now the person you want can split the work into pieces that don’t need to talk to each other. That decides how much any number of agents or people can do.

“The lever is the plan, not the headcount.”
From More people, more agents, same plan
“I run my own work this way: specialist agents, wired as a graph”
From More people, more agents, same plan

6. Test the claims on your own work

Before, a vendor’s page or a conference talk could settle a tool choice. Now the tools change faster than the talks. So the habit to hire for is measuring on your own tasks.

“Whether a given piece earns its place is a question for your own tasks and your own measurements, not for a slogan.”
From What people mean by a harness
“I would not take a routing rule from a vendor’s page”
From Routing a request to a model

Is software solved?

The outside source

Software is solved, some people say. A capable model one-shots it, so the work is over. Dan Luu, in an essay I put in my finds, pushes against that from a different side [Dan Luu (essay)].

Dan Luu, after his friend Michael Malis, argues that people still carry a cost model from before coding agents, so the projects that are cheap now never occur to them, and that careful testing and benchmarking can make the results good enough to use [Dan Luu (essay)]. He’d say we can be more ambitious, not that we should, and he hedges what his own examples show: many are works-for-me tools, and making one a product would take much more work [Dan Luu (essay)].

On software being solved, he’s direct. When people say a new model means everything just works, he writes “I haven't found this to be true at all” [Dan Luu (essay)]. He says each more capable model lets him take on more ambitious work where models still struggle, and that he’s skeptical of the so-called saaspocalypse [Dan Luu (essay)]. He also says he isn’t making a claim about the future [Dan Luu (essay)].

I put the essay in my finds with one line: AI tools cut the cost of building software, so people should attempt projects they once ruled out; heavy testing can make the results good enough to trust. Thanks to Nader Dabit for sharing it.

There’s a tension with this page, and I won’t pretend there isn’t. Luu says attempt what you once ruled out; I say build only what is core. How I hold both: cheap building makes the question of what’s core matter more, not less, and an ambitious build that isn’t core is still something your team has to keep running. That’s my reading, not Luu’s.

What it does to the team

If those are the traits, the team that needs them is small. The platform-team page is where I argued its shape. I marked it as my recommendation.

“Both people can hold the whole product in their heads.”
From The next platform team
“The pod is my recommendation, not an industry standard.”
From The next platform team

What this means for a hiring loop

My opinion

Where I could be wrong

The evidence against

“This is my opinion, and I have not run an experiment to prove it.”
From More people, more agents, same plan

That goes for this page too. My platform-team page also collects evidence that AI doesn’t clearly make developers faster. This page doesn’t answer it.

“AI does not clearly make developers faster.”
From The next platform team

My harness page also reports a team that runs with few blocking gates, while my pages argue for gates in code and a person before anything that can’t be undone. That page doesn’t settle the difference. Neither does this one.

Related on this site

Sources

  • Dan Luu (essay) · Dan Luu, "We should be more ambitious with the software we build", danluu.com, 2026 (a personal essay, his opinion and his own examples; read 2026-11-02)

Sources as read on 2026-11-02.