I'm a DevOps engineer. I'm training someone new to the field.
Often I'll ask the AI to do something and it goes sideways. Sometimes it really saves me time, but many times not. I'll break down and actually type out commands or even Google what to do instead of using the AI because it's still faster.
It's true that my trainee uses the AI more because there's fewer commands in his muscle memory. But, it's still not great yet.
Further, the AI must have each one of its actions approved. I've tried fully automatic mode. It's bad.
AI is more like a lawn mower. It's self-propelling, but you still have to hold on to it, sometimes you got to turn it off and just pull the stuff out of its way or it gets stuck.
Author assumes we’re going to use AI more and more. I don’t agree. I regularly out perform the AI pushers on my team and I can talk about engineering in person too!
In practice I think it will more resemble a flood of script kiddies than CTOs. The average person isn't as thoughtful as the author, they just want to close their tickets with the least effort possible. Not that that attitude towards work is specific to tech workers.
> There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit
Wait, what?
> I was never particularly interested in the code itself
> Instead, I was always more interested in the product
Confusing contradictions aside, I had trouble engaging with this article.
The author seems to think every developer thinks like they do. Some people actually enjoy helping their business/users.
The author also has trouble imagining other perspectives as a people manager. From the linked article,
> I do not get any sort of high from managing people. I don’t think anyone gets that same high from this role
Hate to break it to the author again, but some people actually enjoy seeing those they mentor/manage succeed.
Being a people manager isn’t the right fit for everyone. Perhaps being a developer in the next 20, 5, or 1 year won’t be the right fit for the same people it is for today.
CTOs at most of my companies were more like tech evangelists
Author iterated with AI to build Postgres. Why not learn to use build systems? That’ll pay off big time in the medium timeframe.
I'm so fucking tired of people who had no interest in software development telling me software development is dead.
The author repeatedly states they have little knowledge of the tech they're using. But they're CERTAIN in what the industry will be in future.
Hubris
>And with those new skills, your old skills will start to atrophy.
Skills don't work like muscles, please stop with this thinking model of the world. No one is going to fire you because you don't have the same speed of recall of language constructs and have to look more things up. Speed of coding is not the damn bottleneck.
Plus have a little faith in your brain that you could get back to that point if you wanted to.
Is not the first time that I read this kind of narrative, actually appears pretty often in my LinkedIn timeline. We are now managers of agents and now we are CTO of agents… this is plain delusional, you can play with the toys all day long, a mud cake won’t sell very well. This CTO doesn’t code much, I agree, if you are a contributor you know that so called agents are as useful as google and stack overflow on steroids, nothing more than that unless you have no idea of what you are doing.
Interesting that the author didn’t use AI to proofread his post. He’s not interested in coding very much but the English language doesn’t seem to be his forte either.
Author, if you’re reading this, “let’s” => “lets” (2 occurrences).
I'm doing something similar to the OP but I'm not a CTO but a "manager". Maybe the title is "we're all managers now". The CTO role is bigger than that.
So now the newly minted CTOs, get the same authority, credit, compensation, recognition as the real CTO for managing the hearless agents?
I see there is quite a lot of controversy in the comments here, as the most/majority people are technical/ICs.
However, at my current job & role, my manager has left (or taken quite long leave) 2nd time now. Although both me and my team are assigned to another manager in different region (BigTech), it is not the same thing...
Why I mention this: I am gonna avoid doing any and all managerial work. Because last time, I did a lot of managerial work without the benefits. Both in terms of reporting, keeping the team morale (happiness) up, keeping our interest above from a lot of inter-team fighting/prioritization, etc.
In turn, I got no appreciation or compensation out of it. Even I partially did the jobs of other people (collecting artifacts, reporting up to the chain, etc.) So, nobody would get any _bad_ performance review. (Or worse, lay-offs...)
But I agree with the author, I got no dopamine out of these. Yes I was solving some problems, but they were like package conflicts of NPM peer dependencies. Provided no value to me, no improvement for my own performance, and worse, no goal or direction at all!
PS: My team is a completely DevOps team, in Big-Tech terms, support team. What we do is the grunt-work of various other teams to keep them up-to-date, which is why, overall job satisfaction is quite below of the average...
Now, I am refusing to do the same work again. My manager is in parental leave since mid-June. He has _not_ been doing good job in terms of job-satisfaction and team morale since he has joined. I slowly degraded doing the low-key managerial job, and he has not been taking over. With the long-leave in process, I just stopped taking care of it.
Since I stopped doing the managerial grunt-work, 2 people already left from the team of, well, 8 engineers.
Since I am also taking over the work that has been done by the other engineers, I noticed couple of things: 1. The code quality is somewhat okay, but there are obvious "useless" AI generated areas. Similarly, commit messages yield little to no value, as the review process were only within the people who worked within the project. (ie, Several "fix bugs" commits back to back, yields no value) 3. People who left or stayed, has no recollection of the things I helped them with, problems I solved (ie, unblocking those stuck) and no appreciation for the "space" I was able to get to them. (Even though I was quite explicit with each person. 4. I am one of those special engineers where you can put me in any domain/language whatsoever and I will do a good/decent job at it. (jack of all trades, Swiss-army-knife, whatever you call it.) I also solve the issues as I go through with some bug-fixes, features, whatnot. 5. Product/project manager actively sabotages these tech-debt fixes, or the "refactor" of the "AI-generated" code to be a simpler, more-readable versions.
Which is why, unlike the CTO in question of the article, I started caring less and less about these. Now, I also produce code with AI-agents, as the leadership loves the AI-slop metrics.
At some point, these AI-generated code will fail to do something. We'll need to fix that, or replace that. This boils down to 2 different scenarios: 1. If this code is running an airplane, then it is a disaster. Maybe your engines will fail, you must crash-land somewhere at best. 2. If this code is running a rocket, then it already has a limited time anyway. Does not matter if has a memory leak at all. The lifetime is already so limited that the rocket will not even reach to the resource limits being hit.
I guess most of the leadership is currently betting on most problems being #2. Because software engineering going quite fast, rewrites are always at the next corner, what is the point of "maintaining" the codebase?
Meanwhile, I am not sure I will be there to solve more of an airplane problem when it occurs. I just wish best of luck with the AI-agents to the leaders who have just attached pair or rocket-boosters instead of actual jet-engines to an airliner!
I see there is quite a lot of controversy in the comments here, as the most/majority people are technical/ICs.
However, at my current job & role, my manager has left (or taken quite long leave) 2nd time now. Although both me and my team are assigned to another manager in different region (BigTech), it is not the same thing...
Why I mention this: I am gonna avoid doing any and all managerial work. Because last time, I did a lot of managerial work without the benefits. Both in terms of reporting, keeping the team morale (happiness) up, keeping our interest above from a lot of inter-team fighting/prioritization, etc.
In turn, I got no appreciation or compensation out of it. Even I partially did the jobs of other people (collecting artifacts, reporting up to the chain, etc.) So, nobody would get any _bad_ performance review. (Or worse, lay-offs...)
But I agree with the author, I got no dopamine out of these. Yes I was solving some problems, but they were like package conflicts of NPM peer dependencies. Provided no value to me, no improvement for my own performance, and worse, no goal or direction at all!
PS: My team is a completely DevOps team, in Big-Tech terms, support team. What we do is the grunt-work of various other teams to keep them up-to-date, which is why, overall job satisfaction is quite below of the average...
Now, I am refusing to do the same work again. My manager is in parental leave since mid-June. He has _not_ been doing good job in terms of job-satisfaction and team morale since he has joined. I slowly degraded doing the low-key managerial job, and he has not been taking over. With the long-leave in process, I just stopped taking care of it.
Since I stopped doing the managerial grunt-work, 2 people already left from the team of, well, 8 engineers.
Since I am also taking over the work that has been done by the other engineers, I noticed couple of things: 1. The code quality is somewhat okay, but there are obvious "useless" AI generated areas. Similarly, commit messages yield little to no value, as the review process were only within the people who worked within the project. (ie, Several "fix bugs" commits back to back, yields no value) 3. People who left or stayed, has no recollection of the things I helped them with, problems I solved (ie, unblocking those stuck) and no appreciation for the "space" I was able to get to them. (Even though I was quite explicit with each person. 4. I am one of those special engineers where you can put me in any domain/language whatsoever and I will do a good/decent job at it. (jack of all trades, swiss-army-knife, whatever you call it.) I also solve the issues as I go through with some bug-fixes, features, whatnot. 5. Product/project manager actively sabotages these tech-debt fixes, or the "refactor" of the "AI-generated" code to be a simpler, more-readable versions.
Which is why, unlike the CTO in question of the article, I started caring less and less about these. Now, I also produce code with AI-agents, as the leadership loves the AI-slop metrics.
At some point, these AI-generated code will fail to do something. We'll need to fix that, or replace that. This boils down to 2 different scenarios: 1. If this code is running an airplane, then it is a disaster. Maybe your engines will fail, you must crash-land somewhere at best. 2. If this code is running a rocket, then it already has a limited time anyway. Does not matter if has a memory leak at all. The lifetime is already so limited that the rocket will not even reach to the resource limits being hit.
I guess most of the leadership is currently betting on most problems being #2. Because software engineering going quite fast, rewrites are always at the next corner, what is the point of "maintaining" the codebase?
Meanwhile, I am not sure I will be there to solve more of an airplane problem when it occurs. I just wish best of luck with the AI-agents to the leaders who have just attached pair or rocket-boosters instead of actual jet-engines to an airliner!
If you're a solo developer building your next Salesforce killer, you will feel that dopamine rush every time AI helps you get closer to launch.
Don't worry, there's still more coding problems after that one is solved by AI, because the "last 10%" is another 90% of work when it comes to polishing.