I never thought that I would be back to coding, but here I am, pushing a PR on a Friday afternoon with code I did not write myself. We have all seen the way software is written, and especially science-related software, change through 2026. One consequence of this is that managers, like myself, managed (no pun intended) to come back to coding. And I believe that besides having an impact on the job market, AI will affect the definition of what is to be a tech manager from now on.
The before: good managers did not code
I have been managing data science and engineering teams for the past 10 years, but my career started around 14 years ago. I say “around” because depending on who you ask, a 3-year-long PhD in Physics “counts” as work experience once you leave academia. I experienced firsthand the boom of data science (once the sexiest job of the 21st century), which inflated my job title quite fast in the 2010-2015 period. I became a Data Science line manager in 2016 basically because there was nobody else in the room to do so, much earlier than I would promote someone today, and basically “matured along the way”.
Being a tech manager in a Fortune 500-style corporation means that you stop pushing code and start pushing people. The guidance I got in those first years was to “sit in the passenger seat” and let the team do the coding, which I half-jokingly called “the actual work”. My job was, as a fellow manager told me, to be “the man with the shovel”: going head-first removing the blockers my team would face. Sometimes you should also use your shovel to defend your team against threats, and attack them, like when I had to explain to the DevSec team why we needed access to Python.
Something funny happens when you stop coding but keep living off it. I started developing a sort of “systems view” of the code my reports were building. I got better at understanding how services were connected, how people would use them. It is like understanding how an elephant works just by touching it. As in the old parabole, you do risk taking one part for the whole, but it is possible to develop a good overview if you just keep asking.
I briefly came back to coding during the pandemic. Coding a system to automatically bet on horse races was my lockdown/evening project. It never worked, but the joy of actually writing something myself was a good relief from the endless remote meetings I got as a manager.
After the pandemic, layoffs started and the first widely publicized push for managers to code came from Elon Musk when, after his Twitter takeover, he stated that managers should have 20 reports and code 20% of their time. At the time, as a line manager at Delivery Hero, a German ~25,000-strong food delivery app, I feared for my professional life. Absolutely no way I could write something as good as my Senior ICs, perhaps not even my Junior ICs. While hiring in most big tech has always over-indexed on LeetCode/Codility even for line managers, in scale-ups outside of Silicon Valley that was not the norm. As an example, we ran a position for Science Manager for almost a year because almost no experienced manager would agree to take a hands-on test.
I think peak managerial (gotta love this word) was when I joined Amazon as a line manager in 2024. In a company obsessed with the written word, line-manager work is to produce/review documents. The mountain of 1-pager product proposals, 6-pager promotion packages, 12-pager architecture reviews, plus all the other weekly/monthly/quarterly reports, is insurmountable. In a given week, I would: start two 1-pagers, edit one promo package, write 2 pages of a product launch, come up with insights for a weekly business report, and think about the next monthly report. In this environment, there is no time for coding. “You will get the hang of it with time,” a more experienced leader told me, but that time did not come as I was part of the layoffs in late 2025.
There was a brief period in late 2025 and early 2026 in which I could apply for internal positions at Amazon to keep my job. As I wanted to stay in Berlin for personal reasons, there were no management positions to apply for, so I decided to face my fears and start coding again. Tech interviews at Amazon follow a specific script, and at least as recently as late 2025 they still demanded a live coding round. The first binary tree I had to invert ended up more like a chewed slime. I started spending all my time on coding platforms and relearned how to rotate palindromes, perform the A*-search, the Dijkstra, the Snorlax, MaxSliceSum, and Reverse Polish Notation. Only millennial managers will immediately identify the Pokémon in the list. I got better at live-coding, but after the 5th time it was clear that I had no future as a senior scientist at Amazon. Don’t get me wrong, I don’t think they are wrong in selecting like this, as I certainly do not know of a better way to do so. What I do know is that this methodology would not select people like me, whom perhaps they actually do not need anyway.
Now, coding because of AI
I joined Grover in June 2026 as a science line manager of a 4-person team, and I guess because we are a smaller company, our adoption of AI is just incredible. In these first three months, I have seen my current team deliver more than what I have seen similar teams do in a year. I want to say it is my impact as a manager, but it is just a clever tool, AI, being used by clever people.
For ML models, in particular, development always felt more artisanal in comparison to regular software. There are countless ways of doing population filters, feature selection, hyperparameter search, and model validation. So many caveats to observe and take care of. As a data scientist, you would learn a few paths on how to build a model and go for it. AI assistants expose us to different techniques, test countless variations of the same strategy, and keep track of everything already tested and discarded. In my past experience, a mature team with reliable tools would take 3 months to go from inception to production of a simple classification model. With AI, my team built a churn classification model in one month, while covering much more ground in the science part than before. We used Claude to map all possible sources of features, going through the repo that keeps the data-lake tables updated instead of relying on a human-curated data catalog, and surfacing a few data bugs in the process. We tested several cross-validation schemes before deciding on the most robust one, constructed several definitions of churn, and, finally, let an auto-researcher pick the best feature selection + algorithm configuration. In the end, Claude Cowork even built us the slides for a technical presentation to the team and another for stakeholders. Now, when asked about model details, I can just point the company to the model’s repository and tell them to ask their AI how it works.
Given that AI was doing so much, I decided to try it myself. It started simple. “Clone this repo for me”… done. Great, no more having to learn how the F# ssh keys worked. Now, “compare these two services. How do they interact, what are their main differences and similarities”, and suddenly I found out that one was running SQLAlchemy 1.x and the other 2.x. “How hard is it to upgrade”, it turns out it is hard. Besides making onboarding much easier, and less painful for my team, I had a more detailed systems view than I could before, at the exact level that I needed.
I used to dread writing project status reports, which is something that one simply has to do as a manager, so I decided to automate it. I set up two microservices. The first is a simple scheduler in my Claude Cowork that runs through my email, calendar, Slack, GitHub and Jira, gathers all that has happened to a specific project in the last week, and writes a 255-char report to my team Slack channel. The second is an n8n workflow that watches my team Slack, watches for either a thumbs-up or a revision, and posts the agreed version to Jira. I went from one afternoon of writing text to 5 minutes of revisions.
Currently, I take on side-quests that my team would surface but nobody had time to do. I can now query, investigate issues, propose code changes, and create monitoring workflows. I’m still shy about taking on a really impactful project, but the feeling of actually writing something again has changed the way I work.
What has failed catastrophically is code review of artifacts produced by AI development for science. To fully utilize context, AI must generate a paper trail of decisions, instructions, content, or any piece of knowledge that it finds relevant while developing your project. While for a regular software engineering project you can focus on the code that was produced, for science what you want is the analysis being created, the reasons why a tree-based ML algorithm was chosen instead of a logistic regression. What was once a collection of Jupyter notebooks with analysis became a large collection of .md files in a PR. We have not fully decided on how to handle this complexity yet, but something that I have naturally gravitated toward is creating a very good summary doc with what I expect the reviewer to read and evaluate, treating all the supporting docs generated by Claude as machine logs. And that’s how I spend most of my time preparing PRs: finding what the useful information is at that particular stage.
In the process, I did notice that AI behaves like an overly excited intern with a lot of technical knowledge but little pragmatism. As I already had several real-life interns like this, the experience to handle this behavior came naturally. Opus 5 started raising too many side-quests? Ignore them like the ideas of a PM (joking, you guys are great). Fable is too expensive? Use it only for planning and decision making, like I would ask of a Staff Engineer. Sonnet is for the tasks that you leave for that late Thursday afternoon when you are already tired but it is too early to clock out, so you pick the things that you don’t need to think too much about. And Haiku I would just fire.
The future: the death of line management has been greatly exaggerated
And I guess if other managers are experiencing the same, this explains the tendency of senior folks to keep their employability. If I can now do the work of a manager and a junior (my self-evaluated coding level), why hire juniors in the first place? Managers can now become more active in coding, and that ought to add some “hands-on” head count to the pool. If you assume that the typical span of control was between 5 and 8 ICs reporting to a manager, with 36.5 million ICs worldwide, we now have a few million new devs entering the workforce, and a few won’t start as juniors like me. And I’m not alone, some estimates put the number of Engineer Manager back into coding at 35%.
Hence I can see a near future in which line managers will be evaluated more like we do for Staff Engineers now, where the focus on system design is much stronger. Or perhaps “team leader” will just be one more archetype of Staff Engineer, merging both roles into one. The future line manager will have a bird’s-eye view of the systems they own and code parts of them sometimes, while still keeping up with their regular managerial (there it is again, the beautiful word) tasks.
I still think that managerial (last time) tasks are needed. The most important one is human alignment: corporations, orgs within these corporations, teams within these orgs, and people within teams, will always have their own “particular” goals. Management is the art of aligning those goals to get stuff done (but Charity wrote better than me about this). It will be a while before AI can take this over because the actors I mentioned do not document their goals, either because they don’t want to (when was the last time you actually wrote down “I would like Project XYZ to fail to prove my point”? I guess never.), or simply because they don’t know them (who never worked for a company that had no idea what they were going to do next quarter?).
The second most important one is human empathy. While AI can pose as unlicensed therapists and career coaches, humans have millions of years of evolutionary tricks to actually understand each other. Is your report looking tired? Getting angry with simple tasks? Complaining more than usual about the vending machine snack selection? Perhaps burnout is coming. I believe managers deliver value by delivering this exact understanding, followed by the right empathic response.
Or perhaps I’m just happy coding again and am overstating my impact. But on a personal level, I can only be happy with the AI coding revolution and the possibilities it brought to me. No binary tree can invert me now.
Leave a Reply