Human Skills — developers beyond Code Review Approval Monkeys

The coding monkey joke about developers has been around for years — copy from Stack Overflow, adapt, ship. Agentic tooling hasn’t killed that role. It’s creating the next version: the code-review-acceptance monkey. Click Accept on the permission requests. Click LGTM (looks good to me) on the pull request. Technically in the loop. Not really thinking.

Simpsons machine hitting the “y” key over and over again.

I spent two days in August at Comsysto’s internal Agentic Engineering Summit — sharing current agentic workflows, comparing notes on what’s actually working, and trying to figure out where our teams might be heading. Ten colleagues, two days, a lot of honest conversation. The session I brought to our Open Space:

what should developers be learning right now, and what should we be looking for when we hire?

These are the threads that came out of it.

Understand and Discover first

The first thing the room landed on: before you can build the right thing, you have to understand where the actual problem is. This sounds obvious. It isn’t.

Requirements don’t arrive on a silver platter. Stakeholders often don’t know what they want and need. Translating a business problem into something a team can actually build requires judgment that isn’t in the ticket. Someone has to do that work, and it doesn’t get cheaper when implementation gets faster. If anything, it gets more exposed.

The developers who were always valuable

The developers we have always valued most in our teams were rarely the fastest at implementation. They were the ones who could tell a feature request from an actual user problem. Who noticed when a requirement was hiding an important architectural decision. Who understood the infrastructure well enough to get new things to production safely — and to make that path more reliable over time. The ones who could look at generated output (or a spec, or an ADR) and say, confidently, “this is not a good idea, and here’s why.”

Adam Tornhill describes this as the expert generalist builder, the role that collapses product thinking, architecture, and technical leadership into one, breaking work into pieces that can be delegated to agents.

Enablers and the DevOps-for-AI question

Tornhill’s second archetype is the enabler: pipelines, machine-friendly constraints, testability, making legacy codebases AI-ready. The session arrived at the same distinction independently. Someone in the room described it as something between platform engineering and governance — the people who set up the conditions in which agents can work safely. Someone called it “DevOps for AI” (or Developer Experience) and suggested it deserved its own session.

Delivery ownership still requires understanding infrastructure

Understanding the path from code to deployable — pipelines, environments, what breaks where — was named as a baseline that doesn’t go away. If you don’t understand how infrastructure works, you can’t own delivery. You can’t evaluate whether what an agent produced is safe to ship. You’re back to clicking Accept.

Every team does this slightly differently. That’s part of what makes it hard to abstract. You have to understand it in context, not in theory.

Concepts still matter

The room kept hitting the same wall: AI is just another tool that can help you apply a concept you already understand. It is much less useful for building understanding in the first place. That hasn’t changed. The baseline of knowing how things actually work — your framework, your SDLC, your team’s infrastructure — is still the entry ticket. So what about learning and upskilling? We still saw value in learning new concepts through books and conferences. One colleague had stumbled across an interesting approach with agent skills that support learning during the development flow. But a large part of how developers build real understanding is by making mistakes and being responsible for the consequences. When agents do more of the doing, some of that friction disappears. Nobody had a clean answer for what comes next.

More questions than answers

That’s the thing about a good Open Space session. You come in with one question and leave with many more.

We did not get far on the interview question, but we did get somewhere. Throughout the session we kept realizing that the skills that matter haven’t changed that much. The tooling is different; some concepts are more abstract, but the essence — problem understanding, system thinking, knowing when to push back — is the same as it always was. For an organization that was already looking for that rather than the fastest coding monkey in the room, the way we interview probably doesn’t need to change much.

The interesting work was always beyond the IDE. The question is whether you’ve been doing it, or whether you’ve been hiding behind your syntax — and whether you and the organization you’re in know the difference.

Further Reading

• Adam Tornhill — Coding Is Dead (…But It Still Smells Funny): his take on the two paths emerging for developers.
• Niklas Gruhn — Don’t be a meat proxy: An evolution of the term coding monkeys in the age of AI.
• Gene Kim and Annie Vella — Narrow developer role: “Annie and I kept coming back to a troubling question: if a developer has spent a decade only being allowed to type code — never designing, never talking to customers, never deploying — where would they get the confidence to suddenly do more? Self-efficacy comes from mastery experiences.”

This blogpost is published by Comsysto Reply GmbH