I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas, but when you already have some of the pieces it ultimately wants to drive all of the thinking and takes over. Then it just feels like you're deferring your experienced judgement. I've seen colleagues lose the ability to reason any more without asking the agent to do it for them, because they inherently don't see the point if the agent is going to end up doing the whole piece (and probably auditing/overruling anything they came up with on their own).
Sometimes it's easier for me to scaffold the architecture (in real, working code) and then let the agent fill in the implementation. And I make the agent document the architecture and have it refer to the documentation when coding. When I review agent code, I focus only on architecture (is it following existing architecture? is it introducing new structures, dependencies, etc.?)
Other times, I let the agent create a black box with a well-defined interface contract. I don't care about the architecture inside the black box.
This is one thing I actually do with a chatbot, instead of an agent. Voice mode even.
I start talking to it while doing menial tasks like cleaning or doing the laundry, and I discuss the architectual decisions and options until I come to some resemblance of a plan.
Good side of this approach is that I can't just "skim over" or "copy paste" things - either I understood them and can repeat them myself, or I can't. It takes more time than /grill-me and similar approaches, but it's the only approach that doesn't make me want to claw my brain out.
> I'm really struggling to see how to make architectural decisions with an agent.
I walk to work and home with ChatGPT Voice and AirPods. I ask it to be Socratic and I just start rambling the top of thing on my mind. After 20 mins of back-and-forth it's usually teased an answer out of me or I've teased an answer out of it.
> I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas
I feel the opposite, like if I go to an agent without first knowing what I want to build, I'll never figure out what I'm doing or why and it'll run away from me.
I pretty much always go back and forth and have the agent write out a plan to a file and review it myself in my text editor. I still sometimes end up with surprises I disagree with, but I don't really find it to be true that the LLM ends up trying to "drive all of the thinking".
When I'm thinking through an architecture, I not only instruct it to refrain from writing any code, I don't even necessarily tell the agent what I'm trying to build.
I have had really good experiences with designing architecture with agents. It is much much better than humans and frankly, if my colleagues had used agents to design their new services, we'd have been in much better place.
Why would you care about architecture? It was an issue when humans were writing code so architecture mattered in the sense that you needed a sweet spot between current requirements and future extensions.
The agent can rewrite half your codebase in one day, so architecture stops mattering for the most part.
Why try to make things that are good? Why care about anything? Why not just turn our minds over to the machines, and let them rock us to sleep like babies?
Possibly because the goal is the end product that serves a purpose and has value, not the process.
If you can make your product, make the customer happy, and make your money to enjoy your life and secure your families future… why care who or what or how (as long as it’s ethical obviously).
Why would you care about architecture? Ability to implement the current feature, ability to implement future features, maintainability, and (at least sometimes) performance.
But why would you care when an AI can just rewrite it? Yes, but can it rewrite it to a good architecture? Or just to a different one?
Does a good architecture make code easier for an AI to maintain? I don't know, but I think it's at least not proven that it doesn't.
It’s important for separation of concerns, which is important for maintenance and future iteration on features and bug fixes. If you don’t have separation of concerns, every change to anything is essentially a from scratch rewrite of the whole thing. That’s also incredibly inefficient in token usage.
An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends.
Do we do things because it's the "right thing" to do in the moment, or because of the final outcome that will eventually result?
The most ideal answer is somewhere in the middle. I am far more interested in the total area under the curve than a single instant in time.
In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.
I've been using codex to design and build a product that is a fairly conventional looking app - think of a gmail like experience - with some delicate synchronization across devices.
I find that I need to invest a whole lot in high level design myself to get Codex to create a suitable architecture and make the right tradeoffs. It's more like I am designing and Codex is reviewing and occasionally we brainstorm. When I tried having it design based on requirements, it went wild with an unsustainable design / architecture.
And I use things like plan mode etc. My experience is unlike what I read in most vibe coding exploits.
I wonder if I am doing something wrong. Is there a good canonical example of a project built with Codex or even Claude Code that shows how the human and AI interact that I could use as a reference
I've been on a similar path, and I used to put time in high level design, as it was basically required in some cases. But not a lot of time, because smaller agents research, perform small tests, whatever to inform the high level design. Working incrementally seems to help, maybe prompting a bit more often, but the same can be accomplished with well defined checkpoints.
Then generalize + standardize that process, get an agent to replace you as high level designer so you can manage a team of high level designers, etc etc
> When you truly understand what you’re trying to accomplish, it’s easier to take a small step...
I think they're describing an approach to decision-making in the context of agents.
Engineers encountering LLMs for the first time think the problems they encounter are entirely novel, but really we are rehashing old lessons which Fred Brooks wrote about half a century ago, but in new jargon.
The essential difficulty of specifying what you actually want remains the same and nothing I've seen from LLMs will change that.
Whatever it is you are doing, consider the very basic reason for doing it. And then, build your solutions from there from what is available. Examine the first principles of whatever it is you're doing.
You are working, and you are building things, to create value.
What are the tools you use to move about your environment and create your product, your value? Your knowledge, your training, your time.
If you examine the first principles of whatever it is you're doing, you should realize: you must keep your toolbox open and ready to swap new tools in and out in order to keep up with the time and manage yourself effectively.
AI is a tool, learn to use it as a tool and stop 'fighting the times' so much. All of your criticisms are valid, and you are correct: but everyone still wants to save time, and so you must keep up.
This is one of those things where one can throw around the term "first principles thinking" with relative ease.
To actually do it is different and usually comes from having to wrestle with a problem.
Sadly people from the academia and the public at large has a hard time understanding what this even means.
They equate it with exam based memorization or delegation to authority. Funnily they even think first principles reasoning is an improved version of doing the same.
But this is a blessing in disguise as it gives those who wrestle with real problems a unique skillset that can be advantageous.
> Sadly people from the academia [...] equate [first principles thinking] with exam based memorization or delegation to authority.
In what departments and at what universities? The term "first principles" comes from academia. I think you'd be hard pressed to find a faculty member in any philosophy department doesn't understand what reasoning from first principles is. I'd be surprised if any working mathematician thinks of "memorization" or delegating to authority rather than axiomatization. What experiences led you to say this?
And it's a skill that you'll use in other contexts. Over too learn and practice it in IT/physics, and you find out that you can use it to psychology, humans around you are dealt with another depth and different outcomes become possible
I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas, but when you already have some of the pieces it ultimately wants to drive all of the thinking and takes over. Then it just feels like you're deferring your experienced judgement. I've seen colleagues lose the ability to reason any more without asking the agent to do it for them, because they inherently don't see the point if the agent is going to end up doing the whole piece (and probably auditing/overruling anything they came up with on their own).
Sometimes it's easier for me to scaffold the architecture (in real, working code) and then let the agent fill in the implementation. And I make the agent document the architecture and have it refer to the documentation when coding. When I review agent code, I focus only on architecture (is it following existing architecture? is it introducing new structures, dependencies, etc.?)
Other times, I let the agent create a black box with a well-defined interface contract. I don't care about the architecture inside the black box.
This is one thing I actually do with a chatbot, instead of an agent. Voice mode even.
I start talking to it while doing menial tasks like cleaning or doing the laundry, and I discuss the architectual decisions and options until I come to some resemblance of a plan.
Good side of this approach is that I can't just "skim over" or "copy paste" things - either I understood them and can repeat them myself, or I can't. It takes more time than /grill-me and similar approaches, but it's the only approach that doesn't make me want to claw my brain out.
+1. I have found that most coding harnesses are too focused on the doing that using a Claude/chatgpt chat gives me a lot better quality.
> I'm really struggling to see how to make architectural decisions with an agent.
I walk to work and home with ChatGPT Voice and AirPods. I ask it to be Socratic and I just start rambling the top of thing on my mind. After 20 mins of back-and-forth it's usually teased an answer out of me or I've teased an answer out of it.
> I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas
I feel the opposite, like if I go to an agent without first knowing what I want to build, I'll never figure out what I'm doing or why and it'll run away from me.
I pretty much always go back and forth and have the agent write out a plan to a file and review it myself in my text editor. I still sometimes end up with surprises I disagree with, but I don't really find it to be true that the LLM ends up trying to "drive all of the thinking".
When I'm thinking through an architecture, I not only instruct it to refrain from writing any code, I don't even necessarily tell the agent what I'm trying to build.
How much scope do you give it? I find it's easier to stay in control when you give it scope down the chunks of work you give it.
I have had really good experiences with designing architecture with agents. It is much much better than humans and frankly, if my colleagues had used agents to design their new services, we'd have been in much better place.
Why would you care about architecture? It was an issue when humans were writing code so architecture mattered in the sense that you needed a sweet spot between current requirements and future extensions.
The agent can rewrite half your codebase in one day, so architecture stops mattering for the most part.
Why try to make things that are good? Why care about anything? Why not just turn our minds over to the machines, and let them rock us to sleep like babies?
Possibly because the goal is the end product that serves a purpose and has value, not the process. If you can make your product, make the customer happy, and make your money to enjoy your life and secure your families future… why care who or what or how (as long as it’s ethical obviously).
An agent can rewrite a small codebase in half a day, I have millions of lines of code - it can't rewrite that in half a day.
Why would you care about architecture? Ability to implement the current feature, ability to implement future features, maintainability, and (at least sometimes) performance.
But why would you care when an AI can just rewrite it? Yes, but can it rewrite it to a good architecture? Or just to a different one?
Does a good architecture make code easier for an AI to maintain? I don't know, but I think it's at least not proven that it doesn't.
It’s important for separation of concerns, which is important for maintenance and future iteration on features and bug fixes. If you don’t have separation of concerns, every change to anything is essentially a from scratch rewrite of the whole thing. That’s also incredibly inefficient in token usage.
I have found autonomous agents to be pathetic at architectural decisions.
Architecture has remained so far to be one of those domains where skillset dwarfs everything by comparison.
Higher order thinking is more important and rare.
An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends.
Do we do things because it's the "right thing" to do in the moment, or because of the final outcome that will eventually result?
The most ideal answer is somewhere in the middle. I am far more interested in the total area under the curve than a single instant in time.
In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.
I've been using codex to design and build a product that is a fairly conventional looking app - think of a gmail like experience - with some delicate synchronization across devices.
I find that I need to invest a whole lot in high level design myself to get Codex to create a suitable architecture and make the right tradeoffs. It's more like I am designing and Codex is reviewing and occasionally we brainstorm. When I tried having it design based on requirements, it went wild with an unsustainable design / architecture.
And I use things like plan mode etc. My experience is unlike what I read in most vibe coding exploits.
I wonder if I am doing something wrong. Is there a good canonical example of a project built with Codex or even Claude Code that shows how the human and AI interact that I could use as a reference
I've been on a similar path, and I used to put time in high level design, as it was basically required in some cases. But not a lot of time, because smaller agents research, perform small tests, whatever to inform the high level design. Working incrementally seems to help, maybe prompting a bit more often, but the same can be accomplished with well defined checkpoints.
Then generalize + standardize that process, get an agent to replace you as high level designer so you can manage a team of high level designers, etc etc
Lots of words, not a lot of meaning. What is this post about?
> When you truly understand what you’re trying to accomplish, it’s easier to take a small step...
I think they're describing an approach to decision-making in the context of agents.
Engineers encountering LLMs for the first time think the problems they encounter are entirely novel, but really we are rehashing old lessons which Fred Brooks wrote about half a century ago, but in new jargon.
The essential difficulty of specifying what you actually want remains the same and nothing I've seen from LLMs will change that.
[delayed]
I think it's saying you need to go back and think harder about the problem instead of putting all your effort points into a solution.
Whatever it is you are doing, consider the very basic reason for doing it. And then, build your solutions from there from what is available. Examine the first principles of whatever it is you're doing.
You are working, and you are building things, to create value.
What are the tools you use to move about your environment and create your product, your value? Your knowledge, your training, your time.
If you examine the first principles of whatever it is you're doing, you should realize: you must keep your toolbox open and ready to swap new tools in and out in order to keep up with the time and manage yourself effectively.
AI is a tool, learn to use it as a tool and stop 'fighting the times' so much. All of your criticisms are valid, and you are correct: but everyone still wants to save time, and so you must keep up.
Common sense is not so common
This is one of those things where one can throw around the term "first principles thinking" with relative ease.
To actually do it is different and usually comes from having to wrestle with a problem.
Sadly people from the academia and the public at large has a hard time understanding what this even means.
They equate it with exam based memorization or delegation to authority. Funnily they even think first principles reasoning is an improved version of doing the same.
But this is a blessing in disguise as it gives those who wrestle with real problems a unique skillset that can be advantageous.
> Sadly people from the academia [...] equate [first principles thinking] with exam based memorization or delegation to authority.
In what departments and at what universities? The term "first principles" comes from academia. I think you'd be hard pressed to find a faculty member in any philosophy department doesn't understand what reasoning from first principles is. I'd be surprised if any working mathematician thinks of "memorization" or delegating to authority rather than axiomatization. What experiences led you to say this?
And it's a skill that you'll use in other contexts. Over too learn and practice it in IT/physics, and you find out that you can use it to psychology, humans around you are dealt with another depth and different outcomes become possible