
(Japanese translation follows / 日本語は以下に続きます)
Agentic programming is now the standard way software gets built. That's true across most of the industry, and it's certainly true here. Most of the code we ship today is written in collaboration with AI agents, and our engineers spend more time directing, reviewing, and integrating than they do typing out functions by hand.
As I write this, our last sprint is coming to a close, and almost 80% of our assigned points across two large projects were consumed by planning or specification tasks. Of the code that was submitted to our repos, I struggle to see anything that wasn't generated by Claude Code. Basically, a pattern in our sprint planning is that we now expect writing the code to be the part that happens while you go make a coffee.
That shift has changed what we look for in engineering candidates. What surprises me isn't how much it changed. It's how little.
When we evaluate a candidate today, this is what we're looking for:
- The ability to break an impossibly complex task into small, doable ones. This has always been the core skill of engineering, and agents have raised the stakes on it. Give an agent a vague, sprawling brief and you get vague, sprawling output back. Give it a well-decomposed problem and you get something useful.
- Foundational CS knowledge. Data structures, complexity, how a computer actually works. Agents will hand you plausible nonsense with total confidence; fundamentals are how you catch it.
- UX design experience. Someone has to decide what's worth building before anyone, or anything, builds it.
- Data modeling experience. Get the model right and half the system designs itself. Get it wrong and no amount of generated code will save you.
- A grasp of how complex systems hang together, and the ability to keep that picture in your head. Agents are great at the file in front of them. Someone still has to hold the whole system.
- Real knowledge of the languages we use. I'll be blunt about this one: if you don't understand what the agent wrote well enough to see what's wrong with it and fix it, this isn't going to work out. That one is a dealbreaker.
- Strong communication and writing. More of the job than ever happens in prose: specs, reviews, prompts, decisions written down for other people (and other agents) to act on.
- Knowing how to work effectively with an AI harness — the agents, tooling, and feedback loops wrapped around the model — and how to collaborate with other people who are doing the same thing.
That list is almost identical to the one I was using five years ago, back when I was scouting senior engineers and AI was laughably bad at writing code. Decomposition, fundamentals, systems thinking, communication. None of it is new.
The only genuinely new entry is the last one: our engineers need to know how to work with AI as a tool, and like any tool, we expect candidates to be really good at it. I don't think that's a radical demand. If I'd been hiring for a C++ position five years ago and the candidate didn't know how to compile a binary, we'd have arrived at the same impasse.
The biggest real shift is one of level. As a small company, we now have to be up front about hiring senior. There used to be room for people who built a career on hunkering down and staring at code — heads-down folk who were handed well-defined work. A lot of that work can now be done effectively with agents, which means our engineers have to lean harder into the skills adjacent to the code: talking to stakeholders, talking to customers, picking up threads we might once have palmed off to a product manager. The work that was traditionally the cross for seniors to bear is now just the job.
So no, we probably won't be hiring juniors any time soon. But honestly, small companies chasing rapid growth rarely had that luxury anyway; agents didn't really change that. The more interesting question is what all of this does to the meaning of "junior" in our industry, because those goalposts are moving fast, and obviously seniors don't just appear out of thin air. That one deserves a post of its own, and it's one I want to write.
In the meantime: if the list above sounds like you, get in touch. We should talk.
エージェンティックプログラミングは、いまやソフトウェア開発の標準的な手法になりました。業界の大半がそうですし、私たちの会社も例外ではありません。現在リリースしているコードの多くはAIエージェントとの協働で書かれており、エンジニアは関数を手で打ち込むことよりも、エージェントへの指示出し、レビュー、統合に多くの時間を使っています。
これを書いている時点でちょうど直近のスプリントが終わろうとしていますが、2つの大規模プロジェクトに割り当てたポイントの約80%は、計画や仕様策定のタスクに費やされました。リポジトリに提出されたコードを見ても、Claude Code が生成していないものはほとんど見当たりません。つまり、最近のスプリント計画では「コードを書く部分は、コーヒーを淹れに行っている間に終わるもの」というのが前提になりつつあるのです。
この変化は、エンジニア候補者に求めるものを変えました。ただ、私が驚いているのは、どれだけ変わったかではありません。どれだけ変わらなかったか、です。
現在、候補者を評価するときに見ているのは次の点です。
- 途方もなく複雑なタスクを、小さく実行可能なタスクに分解する力。 これは昔からエンジニアリングの中核となるスキルですが、エージェントの登場でその重要性はむしろ増しました。曖昧で漠然とした指示をエージェントに渡せば、曖昧で漠然とした出力が返ってきます。きちんと分解された問題を渡せば、有用な成果が返ってきます。
- コンピュータサイエンスの基礎知識。 データ構造、計算量、コンピュータが実際にどう動くのか。エージェントは、もっともらしい誤りを自信たっぷりに提示してくることがあります。それを見抜く土台になるのが基礎知識です。
- UXデザインの経験。 何を作る価値があるのかは、人(あるいはエージェント)が作り始める前に、誰かが判断しなければなりません。
- データモデリングの経験。 モデルが正しければ、システムの半分は自然に設計が決まります。逆にモデルを間違えれば、どれだけコードを生成しても取り返しがつきません。
- 複雑なシステム全体がどうつながっているかを把握し、その全体像を頭の中に保ち続けられること。 エージェントは目の前のファイルを扱うのは得意ですが、システム全体を把握しておくのは、依然として人間の仕事です。
- 私たちが使用する言語についての確かな知識。 ここは率直に言わせてください。エージェントが書いたコードを読んで、どこに問題があるかを見つけ、自分の手で修正できる程度の理解がなければ、一緒に働くのは難しいと考えています。この点は譲れない条件です。
- 高いコミュニケーション能力と文章力。 仕様書、レビュー、プロンプト、意思決定の記録など、仕事のうち文章で行われる部分はこれまでになく増えています。しかもその文章は、他の人(そして他のエージェント)が読んで行動するためのものです。
- AIハーネス(モデルを取り巻くエージェント、ツール、フィードバックループの総称)を効果的に使いこなせること。 そして、同じ働き方をしている他のメンバーと協働できることです。
このリストは、5年前、私がシニアエンジニアを探していた頃に使っていたものとほぼ同じです。当時のAIは、コードを書かせるとまだまだ使いものになりませんでした。分解力、基礎知識、システム思考、コミュニケーション。どれひとつとして新しいものではありません。
本当に新しい項目は、最後のひとつだけです。エンジニアにはAIをツールとして使いこなすことが求められますし、他のツールと同様に、候補者にはそれが十分に上手であることを期待します。これは無理な要求ではないと思っています。もし5年前にC++のポジションの採用をしていて、候補者がバイナリのコンパイル方法を知らなかったとしたら、結局は同じ結論に至っていたはずです。
最も大きな実質的変化は、求めるレベルです。小さな会社である私たちは、シニアレベルでの採用を前提とすることを、以前より明確に打ち出す必要があります。かつては、明確に定義されたタスクを渡されて、ひたすらコードに向き合うことをキャリアにしてきた人にも活躍の場がありました。しかし、そうした仕事の多くは、いまではエージェントで効果的にこなせます。だからこそエンジニアは、コードの周辺にあるスキル、つまりステークホルダーや顧客との対話、かつてならプロダクトマネージャーに任せていたような仕事に、より力を入れる必要があります。従来は「シニアが担うもの」とされてきた仕事が、いまや仕事そのものになっているのです。
ですから、当面ジュニアを採用する予定はありません。ただ正直なところ、急成長を目指す小さな会社には、もともとジュニアを採用する余裕はほとんどありませんでした。エージェントがその状況を大きく変えたわけではないのです。より興味深いのは、こうした変化が業界における「ジュニア」の意味をどう変えていくのかという問いです。その基準はいま急速に動いていますし、言うまでもなく、シニアはどこからともなく現れるわけではありません。これは1本の記事として書く価値のあるテーマなので、いずれ改めて書きたいと思っています。
それまでの間、上のリストが自分に当てはまると感じた方は、ぜひご連絡ください。お話しできるのを楽しみにしています。

AUTHOR
Nick del Pozo
Head of Engineering


