3 ms·

I’ll try to explain how to do it correctly. I’m not selling anything. Seeing this as the top comment makes me a bit sad. 1. Learn about ports and adapters as

I’ll try to explain how to do it correctly. I’m not selling anything. Seeing this as the top comment makes me a bit sad. 1. Learn about ports and adapters as an architecture pattern. Domain driven design and locality of reasoning are your new best friends. 2. Realize that AI can generate unlimited fake data almost immediately. So anything you can isolate can get a fake adapter and a real one. You can build and test any such system in near real time, mounted in some fake data system of your own design. 3. Give your opaque backend code UI, so you can build it the same way. This can just be a nice log UI that effectively becomes a backend component harness, but you can get fancy now because UI is cheap. Think about the UX here as providing value by making the code maintainable in the field. 4. Stop thinking like an IC. Don’t be a micromanager about things that don’t matter. Pretend you have 100 mediocre developers working in parallel and design for that explicitly. I actually like go now. It was designed for the managers. 5. Don’t get lazy. You still have to AI pair program the important bits and make architectural calls. This is actually hard, as you have to prioritize what to review in depth and what to glance over. This is why the backend UI helps. It keeps you in the loop. 6. The rough model I’m describing scaled decently pre-Astra. Post-Astra is a whole new world because communication and judgement improved. It leaves behind good docs and comments, and explains things clearly. This was the one gap we had with Claude, and it’s fixed now. The code -after several days of testing- is better as well. On mobile, so I didn’t get super in depth.

officialchicken 24d ago
I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small team of highly coordinated things will always outproduce a pile of generic ones acting will little or no methodology. Please deeply re-evaluate at a philosophical level what quality over quantity really means for delivering outcomes.
- iforgotmypasswo 24d ago
  Not to be tautological, but isn’t the product the product? Which code? The high level code? The transpiled intermediate code? The assembly it runs on eventually? The microcode optimizations on the processor? I’ve written assembly professionally. That code matters occasionally. But mostly I don’t worry about it. I don’t worry much about the transpiled JavaScript tsc output either. Or the intermediate code generated for LLVM. Or the bytecode most managed languages make for their interpreters. Like I said, you still have to do the hard parts, but most of software development is boilerplate or yet another implementation around the hard parts. AI is a tool you have. Using it effectively does not mean it is your only tool. Also, profit is not the ultimate metric. Value provided is the metric. Optimizing for money, to paraphrase a great book, is like trying to get better at tennis by studying the score board.
  - officialchicken 22d ago
    No company is measured by "value provided" on any market, it's a feel-good metric. And you\re playing word-games now despite even saying you're not trying. Like I stated earlier, it's entirely a sophomoric take. And now I understand why.
    - iforgotmypasswo 20d ago
      I’ll try to explain value provided a bit. I think it’s a useful concept to share. A company or organization, generally speaking, has a purpose. It either produces something for or provides a service to end customers which they perceive as valuable. Over time, a company figures out what that purpose is and what it is not. If you are trying to manage a company and you are fixated on dollars, you’re usually not adding anything useful. You’ll likely make decisions completely misaligned with the purpose of the company. If you run a business by jumping from department to department trying to figure out how to maximize profit, you’re just an administrator looking to squeeze efficiency out of existing processes. You want some employees who do this, but it’s certainly not going to keep your company alive and relevant for the long term in an evolving market. Instead, you want to be jumping between departments trying to figure out if the core value proposition of the company is being realized. Are you maximizing value provided to your customers? Is your value proposition still relevant? Chasing value is targeted and intelligent. You’re correct that it’s much harder to create metrics for this, but the metrics you find are substantially more useful than profit margins. These metrics tell you if you’re succeeding. If you’re providing value and profit is an issue, then you either charge more or you never had a viable business model in the first place. Early stage companies chase cashflow by necessity. But once you’re no longer early stage and you have a margin of safety and some success, you can start to think differently. Chasing dollars at this point might put you out of business. Chasing value provided to your end customers leads to substantially more opportunities for continued success.
rando103747202 24d ago
Comments like this give me terrible fomo. My personal experience is much closer to the comment you responded to but I’m always worried that it’s actually just me holding it wrong. A more in depth follow up would be nice if you have time when you’re not on mobile. In particular I’d be curious to hear more about how your intense pair programming sessions go and how you maintain or develop a good mental model of the codebase. Obviously the backend UI is a big part of it but I’m sure there is more. Any chance any of the projects you are using this on are open source? In any case, I’m going to give your backend UI a shot at work next week and Astra plus your workflow a shot on a personal project.
- oblio 23d ago
  I would argue: stop worrying about it. We're what, several decades into this modern software engineering thing and even stuff like DRY, let alone SOLID or whatever, still isn't an universal thing. Do whatever works for you, talk to other people, see what they do day to day, watch other people whose products you've used or whose architecture/code you've read and liked do, and don't fret too much.
brabel 24d ago
Great comment. I don’t do everything you say but still get very high quality code out of Opus 5 with Claude. Fable 5 can be even better but I haven’t proven it enough to be confident yet. It may get off the rail if you’re a bit ambiguous about what you want , but that is only rarely a problem lately. We invested early in good AI instructions while still keeping the context small . We also have lots of skills the AI is instructed to use under different tasks (eg it must always span a subagent go review code, test creation skill, planning procedure etc). When all is done I just can’t believe any human could have done a better job.
JeremyNT 24d ago
I honestly feel like you're making this sound more complicated than it needs to be. I get what I would describe as very good results from GPT 5.6 on my projects. There are some methodologies that can improve things for me versus just YOLO'ing but even these are of marginal benefit: * Have good requirements. Experience with a codebase and stakeholders helps a lot here. * Correctly subdivide the task into chunks that won't blow context. You can write a big task and have an agent plan subtask delegation for you, but it's good to have some intuition of your own. * Perform an automated code review. This is a no-brainer but it catches stuff. * Make sure you understand the "big picture" stuff and stop caring about the little details. The agents will write unit tests, so you shouldn't have to care about reading every LOC, you can ask the agent to describe the architecture and flow instead.
- sandos 24d ago
  This is still weird to me, the agents are super-good and clever most of the time, but I do feel I always need to direct them to a small area to focus: much like a human!! If you just ask them to implement things, they never (for me anyway, were not allowed the most expensive model! Terra is it for now) suggest they should stop adding code ontop of code and refacor, I always have to poke them to do that. Having done that once, and added some tests, they suddenly become aware that, yeah, maybe we should test stuff. The LLMs seem to have no innate ability to understand whats a good direction a higher level. I mean, if you ask them about it, they will actually kinda figure that out, too. But always need that nudge... So if you as a developer do not have the innate drive to ensure quality, the results will be terrible in my experience. If you DO spend the tokens on quality though, it can also be kinda awesome. But its not magic.. I notice clear "slowdowns" the bigger the scope gets. They are not actually able to, in any way, subdivide implementations more efficiently than humans.
jgwil2 24d ago
1. I'm not sure what you're advocating here that wasn't already a best practice in software engineering. 2. This is a real benefit. 3. Not sure I follow, can you expand on this? 4. You don't have to be a perfectionist but you should still understand what it's doing. 5. Yes, this is hard and related to item 4. In any case, you're not really contradicting OC since their comment was specifically referring to "the people who say they no longer read any code," and that's not what you're advocating at all (see point 5).

officialchicken 24d ago

I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small team of highly coordinated things will always outproduce a pile of generic ones acting will little or no methodology. Please deeply re-evaluate at a philosophical level what quality over quantity really means for delivering outcomes.

iforgotmypasswo 24d ago
Not to be tautological, but isn’t the product the product? Which code? The high level code? The transpiled intermediate code? The assembly it runs on eventually? The microcode optimizations on the processor? I’ve written assembly professionally. That code matters occasionally. But mostly I don’t worry about it. I don’t worry much about the transpiled JavaScript tsc output either. Or the intermediate code generated for LLVM. Or the bytecode most managed languages make for their interpreters. Like I said, you still have to do the hard parts, but most of software development is boilerplate or yet another implementation around the hard parts. AI is a tool you have. Using it effectively does not mean it is your only tool. Also, profit is not the ultimate metric. Value provided is the metric. Optimizing for money, to paraphrase a great book, is like trying to get better at tennis by studying the score board.
- officialchicken 22d ago
  No company is measured by "value provided" on any market, it's a feel-good metric. And you\re playing word-games now despite even saying you're not trying. Like I stated earlier, it's entirely a sophomoric take. And now I understand why.
  - iforgotmypasswo 20d ago
    I’ll try to explain value provided a bit. I think it’s a useful concept to share. A company or organization, generally speaking, has a purpose. It either produces something for or provides a service to end customers which they perceive as valuable. Over time, a company figures out what that purpose is and what it is not. If you are trying to manage a company and you are fixated on dollars, you’re usually not adding anything useful. You’ll likely make decisions completely misaligned with the purpose of the company. If you run a business by jumping from department to department trying to figure out how to maximize profit, you’re just an administrator looking to squeeze efficiency out of existing processes. You want some employees who do this, but it’s certainly not going to keep your company alive and relevant for the long term in an evolving market. Instead, you want to be jumping between departments trying to figure out if the core value proposition of the company is being realized. Are you maximizing value provided to your customers? Is your value proposition still relevant? Chasing value is targeted and intelligent. You’re correct that it’s much harder to create metrics for this, but the metrics you find are substantially more useful than profit margins. These metrics tell you if you’re succeeding. If you’re providing value and profit is an issue, then you either charge more or you never had a viable business model in the first place. Early stage companies chase cashflow by necessity. But once you’re no longer early stage and you have a margin of safety and some success, you can start to think differently. Chasing dollars at this point might put you out of business. Chasing value provided to your end customers leads to substantially more opportunities for continued success.

rando103747202 24d ago

Comments like this give me terrible fomo. My personal experience is much closer to the comment you responded to but I’m always worried that it’s actually just me holding it wrong. A more in depth follow up would be nice if you have time when you’re not on mobile. In particular I’d be curious to hear more about how your intense pair programming sessions go and how you maintain or develop a good mental model of the codebase. Obviously the backend UI is a big part of it but I’m sure there is more. Any chance any of the projects you are using this on are open source? In any case, I’m going to give your backend UI a shot at work next week and Astra plus your workflow a shot on a personal project.

oblio 23d ago
I would argue: stop worrying about it. We're what, several decades into this modern software engineering thing and even stuff like DRY, let alone SOLID or whatever, still isn't an universal thing. Do whatever works for you, talk to other people, see what they do day to day, watch other people whose products you've used or whose architecture/code you've read and liked do, and don't fret too much.

brabel 24d ago

Great comment. I don’t do everything you say but still get very high quality code out of Opus 5 with Claude. Fable 5 can be even better but I haven’t proven it enough to be confident yet. It may get off the rail if you’re a bit ambiguous about what you want , but that is only rarely a problem lately. We invested early in good AI instructions while still keeping the context small . We also have lots of skills the AI is instructed to use under different tasks (eg it must always span a subagent go review code, test creation skill, planning procedure etc). When all is done I just can’t believe any human could have done a better job.

JeremyNT 24d ago

I honestly feel like you're making this sound more complicated than it needs to be. I get what I would describe as very good results from GPT 5.6 on my projects. There are some methodologies that can improve things for me versus just YOLO'ing but even these are of marginal benefit: * Have good requirements. Experience with a codebase and stakeholders helps a lot here. * Correctly subdivide the task into chunks that won't blow context. You can write a big task and have an agent plan subtask delegation for you, but it's good to have some intuition of your own. * Perform an automated code review. This is a no-brainer but it catches stuff. * Make sure you understand the "big picture" stuff and stop caring about the little details. The agents will write unit tests, so you shouldn't have to care about reading every LOC, you can ask the agent to describe the architecture and flow instead.

sandos 24d ago
This is still weird to me, the agents are super-good and clever most of the time, but I do feel I always need to direct them to a small area to focus: much like a human!! If you just ask them to implement things, they never (for me anyway, were not allowed the most expensive model! Terra is it for now) suggest they should stop adding code ontop of code and refacor, I always have to poke them to do that. Having done that once, and added some tests, they suddenly become aware that, yeah, maybe we should test stuff. The LLMs seem to have no innate ability to understand whats a good direction a higher level. I mean, if you ask them about it, they will actually kinda figure that out, too. But always need that nudge... So if you as a developer do not have the innate drive to ensure quality, the results will be terrible in my experience. If you DO spend the tokens on quality though, it can also be kinda awesome. But its not magic.. I notice clear "slowdowns" the bigger the scope gets. They are not actually able to, in any way, subdivide implementations more efficiently than humans.

jgwil2 24d ago

1. I'm not sure what you're advocating here that wasn't already a best practice in software engineering. 2. This is a real benefit. 3. Not sure I follow, can you expand on this? 4. You don't have to be a perfectionist but you should still understand what it's doing. 5. Yes, this is hard and related to item 4. In any case, you're not really contradicting OC since their comment was specifically referring to "the people who say they no longer read any code," and that's not what you're advocating at all (see point 5).