Hi there,
I’m Martin, CTO at Flank.
Below you can read a rather personal reflection on how agents have actually changed my team.
Coding became a team sport
I am a social scientist. My PhD was in computational social science, where I built agent-based models way before anyone heard of AI agents. I used them to research how thousands of simulated workers following a few simple rules turn small differences in what people know and can afford into large differences in where they end up. In my free time, I still work on personality and passion at work. It is a varied background, and until recently none of it looked like preparation for anything specific.
I now serve as CTO of Flank. I took over the engineering team at the start of the year, and the first big job was a strategy for how we would use AI coding agents. I expected the challenges to be technical. Most of them were social and organisational.
The first thing the agents did
The first thing the agents did was flatten us. The gap between what a junior and a senior engineer on the team can ship in a week has never been smaller. That matches what the studies of support desks and consultancies found: the people who gained most from AI were the ones who had the least to start with. I believe it. I also think it is half of the picture, because the studies of learners find the opposite once the tool is taken away. Students with a chatbot did better on their homework and worse on the exam. Engineers given an assistant for a library they had never used finished a bit faster and understood noticeably less, especially when something broke.
The second consequence surprised me more. Coding became a team sport, far more than it was when everyone typed their own code. You need the fast movers, the people who are not afraid to experiment and not afraid to tear it all out and write it again. Someone has to think about reliability, and about what the shipped system does at three in the morning. And you need the slow ones, the deliberate ones, the people who feel they own the product and read it as if they will be the one fixing it. One person with agents can build a product now. It still takes all of these people to grow it, maintain it and make it work for an enterprise customer.
The slowest engineer
The slow ones are the ones I keep coming back to. There is an engineer who is slower than everyone else this quarter, because he reads every line the agent writes and asks it why before he accepts anything. His pull requests are the smallest we have, and they are the ones I never have to reopen. He is also the one I would trust with the most sensitive parts of our system.
Which brings me to the thing I did not expect to use. The speed at which we ship new features looks like an engineering problem, and from inside the sprint it feels like one. In practice it is a problem of working environment and process. People need clear direction and they need slack. Permission to move quickly has to come with protected time to review the parts that are mission critical. It also has to come with permission to say, out loud, that the agent wrote this and I do not understand it well yet. That is important information about the state of the system, and a team where people hide it is a team that will find out the hard way. And someone has to have spent enough time with the code to understand it, so that when there is a bug or an incident at an awkward hour, a person can fix it rather than ask the agent to guess.
None of that is technical. It is organisational research, the kind I read and taught and never expected to apply, and I now use it every week. Whether an engineer keeps learning while the agent works is not mostly a matter of character. Reading two thousand generated lines costs an hour, and who gets that hour is something I decide when I set the sprint. It matters more than it sounds, because people grow into whatever I hand them as their main work. Give an engineer a year of accepting what the agent produces and that is the engineer you will have at the end of it: fast, productive, and stuck the moment something breaks. Give another a year of reading, questioning and fixing, and you get someone who understands the system and can be trusted with it.
The next few years
I think this is what the next few years look like well beyond engineering. AI will change industries, and I suspect a lot of the change arrives as connections nobody planned, between disciplines, between industries, between technologies that had little to do with each other. A social scientist running an engineering team is one. Lawyers becoming the engineers of their own playbooks is another, and the legal teams handing routine work to agents will meet the same exam ours did, with their juniors. The interesting ground is between the fields. It is where I have ended up, and I find it a good place to stand.
