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.
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.