Interesting article. I work in a high performance / distributed computing area at a company that is over 10 years old. Honestly, we don’t need to write much code. I debug problems that arise from our scale a lot, and features need to be well thought out but ultimately end up being a few hundred lines of code. I suspect my experience as a software engineer is quite different than most, and doesn’t fit really well into this multi agent paradigm.
The tools I find the most useful are search tools that can answer questions about the code base. Finding out where things happen in an application I’ve never touched before helps me get much closer to the bug.
For personal projects, I basically do not write code now and use agents for most of the coding, but I still read and test code that is generated.
So I have a few questions really;
1. What types of projects are you working on where spinning up many agents simultaneously is useful?
2. What is the technical skill of being a good software engineer now? I assume it’s similar to what it was before, but rather than having juniors implementing stuff or doing it by hand, it’s having agents do it.
3. Do you feel as engaged and stimulated as you did before agents existed? I wonder if I can enjoy this new paradigm as much as I enjoyed plain old coding.
With not-that-much work, you can get Claude Code and coding agents in general to be extremely powerful search tools. They are really good at like munging through a database, pulling on imports to find more context, and returning information about it. Now, they get worse as the code base gets larger. For my midsize codebase (~100k loc) they are pretty effective, but I could imagine this breaking a bit at 1M loc. But the important thing is that they are extremely cheap, so you can do the work that you would normally be doing while on the side running one (or more) of these agents explicitly to see what it digs up. If it doesnt dig up something useful, no harm no foul; just move on.
To answer the questions:
- mostly building product. I run a startup, you can check it out at tilework.tech. We pivoted recently, but before we were building a visual block editor for ETL processes. Was very easy to spin up many agents to add new ETL features. Integrate with bigquery is ~= integrate with google drive which is ~= integrate with snowflake, etc. etc. So once you built one, you could fan out a bunch of agents and build the rest in like a day.
- I think its a lot more system design and awareness. You need to be able to evaluate when the agent is doing something that is good / bad, which in turn means you need to dramatically expand the scope of your understanding of the system. I think writing code 'by hand' is basically unnecessary now for many use cases (if you are doing embedded systems, you probably still have to do things by hand; same if you are working in unfamiliar programming languages). Instead, you are writing system modifications, which is much more involved.
- Yes! I actually like this more. I get to spend way more time thinking about problems and shaping solutions, instead of thinking about syntax and api calls and so on. If you really like the formal beauty of programming languages, maybe this isn't a great change. But I like _building things_, and for me I get to spend way more time on building things instead of dealing with random bs
Appreciate this answer, and your startup seems cool!!
I think what I enjoy about programming is the obsessive nature of solving a problem. Where I rush through a snack break so I can get back to my computer as soon as possible because I’m so engrossed in what I’m doing.
I’m not sure I’d say I am most obsessed with building (although I do love that), instead I think the fundamental problem solving is what I enjoy the most. Code is a means to an end to solve a problem. I don’t care at all about writing code by hand just for the sake of it, I just hope I can maintain a mental model of the codebase I’m working in without writing too much code. I guess this is demonstrably true because I have a good mental model of the giant 700k commit mono repo I use at work yet I have only written a small fraction of that code.
But I have not been in a position yet where I have worked on 20k plus lines of greenfield code using agents to write most of it, so I just don’t know what that feels like. I have a few small projects brewing so I will see how that goes. I am using Claude code and while it works on a new feature, I read code that is already written to better understand what is currently happening. I assume as the code base is more established I can focus on fanning out work to multiple agents while I make decisions about overall design / read code.
Interesting article. I work in a high performance / distributed computing area at a company that is over 10 years old. Honestly, we don’t need to write much code. I debug problems that arise from our scale a lot, and features need to be well thought out but ultimately end up being a few hundred lines of code. I suspect my experience as a software engineer is quite different than most, and doesn’t fit really well into this multi agent paradigm.
The tools I find the most useful are search tools that can answer questions about the code base. Finding out where things happen in an application I’ve never touched before helps me get much closer to the bug.
For personal projects, I basically do not write code now and use agents for most of the coding, but I still read and test code that is generated.
So I have a few questions really;
1. What types of projects are you working on where spinning up many agents simultaneously is useful?
2. What is the technical skill of being a good software engineer now? I assume it’s similar to what it was before, but rather than having juniors implementing stuff or doing it by hand, it’s having agents do it.
3. Do you feel as engaged and stimulated as you did before agents existed? I wonder if I can enjoy this new paradigm as much as I enjoyed plain old coding.
With not-that-much work, you can get Claude Code and coding agents in general to be extremely powerful search tools. They are really good at like munging through a database, pulling on imports to find more context, and returning information about it. Now, they get worse as the code base gets larger. For my midsize codebase (~100k loc) they are pretty effective, but I could imagine this breaking a bit at 1M loc. But the important thing is that they are extremely cheap, so you can do the work that you would normally be doing while on the side running one (or more) of these agents explicitly to see what it digs up. If it doesnt dig up something useful, no harm no foul; just move on.
To answer the questions:
- mostly building product. I run a startup, you can check it out at tilework.tech. We pivoted recently, but before we were building a visual block editor for ETL processes. Was very easy to spin up many agents to add new ETL features. Integrate with bigquery is ~= integrate with google drive which is ~= integrate with snowflake, etc. etc. So once you built one, you could fan out a bunch of agents and build the rest in like a day.
- I think its a lot more system design and awareness. You need to be able to evaluate when the agent is doing something that is good / bad, which in turn means you need to dramatically expand the scope of your understanding of the system. I think writing code 'by hand' is basically unnecessary now for many use cases (if you are doing embedded systems, you probably still have to do things by hand; same if you are working in unfamiliar programming languages). Instead, you are writing system modifications, which is much more involved.
- Yes! I actually like this more. I get to spend way more time thinking about problems and shaping solutions, instead of thinking about syntax and api calls and so on. If you really like the formal beauty of programming languages, maybe this isn't a great change. But I like _building things_, and for me I get to spend way more time on building things instead of dealing with random bs
Appreciate this answer, and your startup seems cool!!
I think what I enjoy about programming is the obsessive nature of solving a problem. Where I rush through a snack break so I can get back to my computer as soon as possible because I’m so engrossed in what I’m doing.
I’m not sure I’d say I am most obsessed with building (although I do love that), instead I think the fundamental problem solving is what I enjoy the most. Code is a means to an end to solve a problem. I don’t care at all about writing code by hand just for the sake of it, I just hope I can maintain a mental model of the codebase I’m working in without writing too much code. I guess this is demonstrably true because I have a good mental model of the giant 700k commit mono repo I use at work yet I have only written a small fraction of that code.
But I have not been in a position yet where I have worked on 20k plus lines of greenfield code using agents to write most of it, so I just don’t know what that feels like. I have a few small projects brewing so I will see how that goes. I am using Claude code and while it works on a new feature, I read code that is already written to better understand what is currently happening. I assume as the code base is more established I can focus on fanning out work to multiple agents while I make decisions about overall design / read code.