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