Agentic Coding Demo: Building Production-ready Progressive Disclosure feature in 30 minutes with codex-cli (GPT-5).
Thoughts on using AI for serious product development
Good software engineers know that when you write code you often approach it in steps: make it work, make it pretty, make it fast. Kent Beck, the creator of Extreme Programming, made that explicit; good developers have long worked this way.
In this post, I’ll show how I implemented a real-world feature for a new project I’ve been working on, and why I think the act of coding has now reached a very reliable abstraction: natural language. I’ve been working with AI tools to improve my development speed since the AI wave started, and the last few weeks have changed how I build.
I started with GitHub Copilot, which was already a game changer for editing (auto-complete) and local changes. My speed multiplied. Then I coded by asking questions on ChatGPT.com while editing with GitHub Copilot in VS Code. When GitHub Copilot announced Chat inside VS Code with code context, I tried it a bit but wasn’t impressed, so I didn’t use it much. Later, Google announced Stitch for building UI. I used it to scaffold something, then had to take it from there as a human “editor” (with Copilot’s help, still working in-editor).
Coding IDEs started popping up and I didn’t try them. I’ve been an early OpenAI user, I like and trust them, and I wasn’t ready to invest time learning new tools. I figured I’d let them evolve before jumping in. Also, I’ve customized VS Code enough that switching feels painful. I don’t like that VS Code has nano-lag compared to editors outside a web view, but I still use it because it’s so customizable, has a large plugin ecosystem (it’s become a standard), and just works most of the time.
When OpenAI announced codex-cli I was curious, without realizing how powerful it would become. One day I decided to try it. As a bootstrapper, I’m usually short on time to even read the full instructions. I worried about it messing up my repo, so I started a new project and decided to use only codex-cli to feel safe and get familiar. I built my first app prototype entirely with it, and it worked! But after a certain point the code became spaghetti 🍝 full of monkey patches—unmaintainable. I realized that unlike my usual process, where a prototype evolves into production through iteration, this prototype could not be salvaged. I’d have to start over.
Before rewriting the project to give it the structure it deserved (not just “vibe code it” but actually monitor every change—especially at the structure level), I did some customer validation. A few potential users were excited. So I disposed of the throwaway prototype and decided to build it well.
What I did next was serious planning with ChatGPT.com’s help: understanding the theory, different approaches, potential trade-offs, and researching tools. When I was ready to build, I went back to codex-cli. Because the project was new, I made sure everything was saved in the remote repository (just in case), passed the flags so it could do what it needed (even go outside the shell, which was causing slowdowns), and let it tell me when it was ready. It would sometimes fail and sometimes get it right. It was very useful, but it still needed supervision and guidance—like an intern.
I would step back, undo, course-correct, and continue. I made sure the project used the right tools in the right way, with the right separation and structure. It took time, but it was worth it. I was already building much faster, and I got really excited about codex-cli. I started reporting issues and talking with the team behind it.
Around the same time, other CLIs started popping up—most notably Google’s Gemini and Claude. I tried Google Gemini. It takes one bad “shot” to reduce trust; when you’re sitting and waiting for minutes, if the agent does the wrong thing and messes up the codebase, it’s annoying even once. On some hard problems I had, codex performed better than Gemini (that was my impression), so I stuck with codex. I didn’t really try Claude since codex was already very good, though I read in the Pragmatic Engineer newsletter that many developers liked Claude Code.
Then something magical happened a few weeks ago. OpenAI announced ChatGPT 5. Buried in the announcement was a note that ChatGPT 5 was optimized for code writing, so I tried it. I updated codex-cli and found that many of the issues I’d reported were fixed and the default model was now GPT-5.
To my surprise, GPT-5 was optimized for exactly this kind of work: reasoning about technical goals, proposing good approaches, calling tools, and making things happen. It’s a default-reasoning model, meaning it does a “thinking” step behind the scenes before responding—which reminds me of how my first serious programming professor taught us to “think before you code.” It feels like working with a smarter person. Instead of an intern, it’s like having a senior developer who’s actually much smarter than you, ready to ship. You just say what you want in plain language and they’ll get it done. Once I started coding with codex-cli and GPT-5, I realized product development had changed. We can now build features in minutes rather than hours, hours rather than weeks, and weeks rather than months. The old assumption that developer speed only varied by 2–4x has been inverted. I was mind-blown: when I thought I’d get a complex feature done by day’s end, it was done in 30–60 minutes (this was already true with codex-cli and GPT-4).
I don’t know how others are using AI coding tools, but it’s worth sharing how I’m building. The insight I’ve had is that I rarely need to look at the code. Sometimes I do—and it’s important—but most often it just works, and I can verify it with as much depth and rigor as I need.
I think the act of coding has reached a very reliable abstraction: natural language. Some of us developers are wondering whether our hard‑earned skills will become obsolete. Tech executives claim most developers will become unnecessary. Apps like lovable.dev position themselves as replacements for developers. I find it somewhat sad that there is a startup with superstar engineers and Math Olympiads, that is openly on a mission to get rid of developers like themselves.
I don’t think that’s what will happen. Code is useless without its users, and complex projects serve diverse audiences, including internal stakeholders. We’ll still need people who can talk to the AI and specify, in sophisticated technical language, exactly what they want—often the product of thoughtful trade-offs with no single “right answer” in a complex problem space. Say someone asks an AI to “build a pong game.” It will likely produce a working version, and you can iterate. But if an expert talks to an AI step by step, as they would with a coworker, they’ll likely produce a better product—and, crucially, one they can trust, because they can inspect the critical parts and understand how it works. That’s how you offer quality and reliability guarantees to users. We may need fewer developers, but we’ll still need people who understand how systems work behind the scenes. For complex apps (the ten we use 80% of the time), we’ll still need those experts to both build and iterate—in natural language.
For demonstration—because they say “you don’t know what you don’t know”—I’m sharing how I built a feature this way for my new project, Shape It. I did have to step in and use VS Code Copilot Chat once when parentheses weren’t matching (Copilot is good at this because it has access to the IDE’s errors). The interesting part is that I built the entire feature using natural language only. I’m not sure this should be called vibe coding, which is often associated with people who don’t know how to code (and that’s great—but limited). In this new kind of agentic coding, you do need to “speak” code in natural language to get it right and reliable.
Make it work, make it pretty, make it fast still applies. The difference now is that you can think before you code in natural language, and a capable agent will do the heavy lifting. You supervise, you specify, you verify—and you ship.
I’m sharing here’s my entire conversation with codex-cli, for your inspiration:
progressive-disclosure.txt
It took half an hour to make it work (tech speak), around two hours of “design talk” to make it pretty, and it’s already fast enough.