Agentic coding reaching ever higher heights

In a recent article from Ryan Lopopolo at OpenAI he describes using Codex for everything in a development project, not a single line of code, plans or even documentation touched by a human, is fascinating.

What I find striking is how well their findings for maintaining context and high quality output align with how a high functioning team would work.

I have not yet worked with multiple sub agents, but for the projects I've done with "single instance" Claude Code and Codex I quickly realised that just prompting isn't enough.

Instead I have landed on a methodology where I think of my LLM counterpart as a fullstack developer that I am collaborating with. I behave and interact more or less as I would with a real person.

1. In conversation with the LLM I discuss the opportunity, talk through ideas, known best practices and patterns, risks, edge cases, design options, project phasing, tech stack...
2. When we both agree there are no big questions or unknowns left for a first iteration, I ask the LLM to save it all as a structured specification in one or more Markdown files depending on complexity. I much prefer to manage this myself rather than using "plan mode".
3. As the LLM starts iterating on implementation I review and validate. and do any configurations (like running queries in Supabase or setups in CloudFlare that the LLM can't do or that I want to understand better).
4. If we run into something that doesn't work, or we realise we need to re-think we go back to the specification documents. We talk through what do do, make sure the spec is up to date, and then back in implementation mode.
5. Lather, rinse, repeat.

It takes some time, to maintain all these Markdown files with the LLM (I typically don't write anything, my time is spent in conversation), but I rarely see the LLM get massively confused and get things wrong. A year ago, without this approach, it was sometimes like working with a really competent goldfish... Lots of reverting to previous branches.

As an added bonus, it also becomes a great "memory" to remind the LLM what we did if I ever want to refactor something or add a feature. Massive time saver.

So it seems like time well spent. And again, I wouldn't dream of working with a real team without these kinds of artefacts, agreements and plans so why would I ditch a methodology that has worked well in the past when leveraging AI?

To paraphrase Albert Einstein:

If I had one hour to spend on a challenge I would talk about the problem for 55 minutes, then deliver the solution in the remaining 5.

What I've also started doing as a project starts taking shape and is deployed, and it's no longer possible to do drastic changes (and mistakes will be really costly), is to create "onboarding documentation".

I ask the LLM to review the project, read all the documentation, and output as Markdown one or more documents that "help a developer coming new to the project to quickly get up to speed and be productive". This seems to help the LLM maintain the basic context.

Lots of food for thought in the OpenAI article to enhance this kind of approach even further.