I read everything I can get my hands on, sometimes even things I don't understand at all. Occasionally you have to stretch yourself and look at things that don't make sense. Part of working with LLMs is understanding how the programs works, this is different than writing the code. The explanations coming from the LLM have to make sense to you, or you will get garbage or not understand what your applications is actually doing. You have to be able to look at the code and say I understand what this is doing even if you can't write it. A good example of this is if there is a product manager running a team. They have to understand what the code does even if they don't write it.
Agents still seem pretty bad at architecture. I still need to stay very much in control of how something is done, even if I have an LLM write some code here and there.
For stand-alone bits of code where I don’t really care about the implementation, I will let an agent go wild. But for production code in the legacy code base, not a chance I’m doing that.
Just because coding agents can multiply our productivity doesn't mean that we should reduce ourselves to shoddy engineering, on the contrary.
In fact, I see this as an opportunity to build anew and better. When you're no longer constrained by legacy baggage and constraints, you can collapse layers and introduce new ones that better fit what you're creating.
I'm doing that in the project I'm working on at work. Being able to redefine how serialization/deserialization fundamentally works and interacts with domain objects is giving us unbelievable expressiveness, not by the amount of code written (in fact, it's heavily factorized across layers that were historically separate), but by exploring new designs paradigms.
you still need to engineer/architect your system so that agents are able to efficiently build modify and test the system.
an agent that can quickly figure out which responsibility goes where means the next time there's a bug or feature request, that agent then can actually work in an efficient way and get the task done.
do you want your agents working for 15 minutes or more, constantly regurgitating slop, or do you want your agents working for 5-6 minutes or less?
just remember, agents are only supercharged when they're driven by someone who knows what they're doing.
i'm in sf, and i'm always blown away by people whose systems are either dog shit god awful, or whose systems are god tier insanely good.
it really isn't a flex to spend a ton on tokens or ai compute time, if you're putting out less actual work. ppl who flex like that with mid or worse results are morons.
my systems are somewhere in the middle i'd say, and i strive to be in the latter group.
I read everything I can get my hands on, sometimes even things I don't understand at all. Occasionally you have to stretch yourself and look at things that don't make sense. Part of working with LLMs is understanding how the programs works, this is different than writing the code. The explanations coming from the LLM have to make sense to you, or you will get garbage or not understand what your applications is actually doing. You have to be able to look at the code and say I understand what this is doing even if you can't write it. A good example of this is if there is a product manager running a team. They have to understand what the code does even if they don't write it.
Agents still seem pretty bad at architecture. I still need to stay very much in control of how something is done, even if I have an LLM write some code here and there.
For stand-alone bits of code where I don’t really care about the implementation, I will let an agent go wild. But for production code in the legacy code base, not a chance I’m doing that.
Just because coding agents can multiply our productivity doesn't mean that we should reduce ourselves to shoddy engineering, on the contrary.
In fact, I see this as an opportunity to build anew and better. When you're no longer constrained by legacy baggage and constraints, you can collapse layers and introduce new ones that better fit what you're creating.
I'm doing that in the project I'm working on at work. Being able to redefine how serialization/deserialization fundamentally works and interacts with domain objects is giving us unbelievable expressiveness, not by the amount of code written (in fact, it's heavily factorized across layers that were historically separate), but by exploring new designs paradigms.
Don't just read these books. Write some new ones.
The only architecture advice you need is write short code and create few files. Now you know why LLMs mostly create mountains of trash.
you still need to engineer/architect your system so that agents are able to efficiently build modify and test the system.
an agent that can quickly figure out which responsibility goes where means the next time there's a bug or feature request, that agent then can actually work in an efficient way and get the task done.
do you want your agents working for 15 minutes or more, constantly regurgitating slop, or do you want your agents working for 5-6 minutes or less?
just remember, agents are only supercharged when they're driven by someone who knows what they're doing.
i'm in sf, and i'm always blown away by people whose systems are either dog shit god awful, or whose systems are god tier insanely good.
it really isn't a flex to spend a ton on tokens or ai compute time, if you're putting out less actual work. ppl who flex like that with mid or worse results are morons.
my systems are somewhere in the middle i'd say, and i strive to be in the latter group.