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.

In the only thing that matters, Andreesen emphasizes that product-market fit (PMF) is the most critical factor to startup success. When starting a new project, builders and people who are drawn to great products, are naturally inclined to focus on what the the solution will look like (or do) “the product”, making it easy and natural to lose track or underestimate the other, and equally important part of the PMF puzzle, “the market”.

But, even when we are market-aware, as product managers, whether by training, or because of an external push such as a friend, investor, coach, or stakeholder who asks “how are you going to make money?” followed by “who is going to pay for that and why?”, we are inclined to have an expansive view and look for a good reason to say “as many people as possible”, and if we’re not wary of our innate push towards motivated reasoning, we may be fast and certain to make up and conclude that our target market are large “potential” audiences, akin to starting at the top of the total addressable market (TAM).

My point is—when looking to innovate, rather than thinking of addressable markets, no matter if it’s TAM, SAM, or SOM, we should instead look into the first 2.5% of people who will use your product according to the innovation diffusion theory as the early answer to “who is this product for?”. These people are the “innovators” also known as super fans by Amy Jo Kim and as high-expectaction customers (HXC) by Julie Supan.

While your super fans will probably not help you make money, and they will certainly not be the target audience that will make your business model work, technically speaking, for simplicity, early on, you should think of them as your target audience, specially for design purposes. I will talk about the importance of audiences in design more in depth in another post, but the point I want to make here is that we should always be building for someone, and that someone, before product-market fit, should be your super fans. Everyone across the organization should be aligned on who these super fans are and you should try to bring them in close to the product early and often, until further on when people are asking for your product (eg. having a market pull).

When creating something that doesn’t exist, it’s often hard enough to find one person who cares about it and genuinely wants to “hire” your product. Considering how many assumptions you’re probably basing your reasoning on, and how complex your product is; saying who your larger audience is, and designing your product around how you think they think (meta guessing), is non-sense. But we do it either way, because we need a good answer to the question “who is your customer?”. We have to start somewhere, and we’d all like to start somewhere good, when possible.

Instead, start with a few assumptions that answer “who cares a lot and why?”. These assumptions, if framed correctly, should point you towards your super fans. Start with your super fans and try to make them …super… happy, they are well positioned to teach you the most about your product at this stage. Before product-market fit, you’d rather have a few super-happy super-fans, than an imaginary slice of a super valuable market.

When you find them, if they really are your super fans—meaning that they absolutely love your product and would be very disappointed if it didn’t exist—they will be so excited about the problem you are solving that they will be willing to help you build the solution. They will be as interested and as personally invested as you in having the solution materialize, so you should bring them in as partners in your design process, they will be happy to partake.

There are many ways to do this, but to keep things simple, I suggest first screening them with Amy Jo Kim’s super-fan 5 discovery questions (adapt as needed), and then embedding them into your product development cycle. For example, you could show the new iterations to them every 2-3 week sprint and use their feedback to inform your next build cycle.

I would say that with five (real) super fans who share the same traits in relation to the problem you’re solving, you can already build enough momentum to reach your early adopters, who may already be willing to pay for a solution. You early adopters are your super fans + more people who also care but need a more polished product before adopting it. Every case is different but your project may be able to survive at this point, and that’s usually what you’ve been aiming for since the beginning.

There are many methods to conduct user research professionally, but if you are short on resources, you can go a long way in learning about the problem/solution by just being humble and using your intuition. With those things in mind, just continually keep trying to make them happier and you’ll be on track to solving the right set of sub problems of the PMF puzzle early on, hopefully giving both the same relevance:

• Who is the market? → Who cares and why? → Start with your super fans (Minimum Viable Audience).

• What is the product? → What should I build? → Start with an idea. (Minimum Viable Product).

Personally, as an indie hacker, I made the mistake of showing my prototypes to anyone who would listen, because I was often forced into scrappiness due to lack of resources, and although that helped with improving the usability of the product, it just made things worse in terms of understanding the market and their needs, often leading to Frankenstein-like products that made no one happy in an effort to make everyone happy. In other words, showing prototypes to non-fans helped me make the solution better in some way, but it made things worse in understanding the problem space.

Before you have product market fit, most of the value generation comes from having a deep and comprehensive understanding of the problem. “The search” is more about the underlying problem than about any specific solution. Problems are often more complex than they first seem once you start breaking them apart.

To find your super fans, who will help you understand the problem you need to start somewhere, so make a set of hypotheses, rank them, and try to prove them or disprove them.

Here’s how I formulated these hypotheses for a new project:

1. Write down a one sentence short and simple explanation of your value proposition. In my case, I wrote “Fast access to summarized high-quality content about anything”. It simply captures what this is and what makes it special. Note that this doesn’t include the “who” part.

2. Then try to come up with a few outcomes, think social, emotional, and functional that happen when someone “hires” your “what”? For example, I wrote, people may discover new ideas (functional), impress their friends (social), and feel smart (emotional), but I wrote a few more.

3. Then write “who cares most” and make a list of audiences that could potentially care about your “what”. Try to separate this buckets of people based on demographics and/or behaviors. For example, I wrote busy growth-minded people, DIY fans, people who listen to podcasts frequently, and self-taught modern polymaths, among others.

4. Lastly, look at everything you wrote, and use your sense making and intuition. Then choose one or two audiences, if you have a team, make the guess democratic. You’re trying to find who your super fans are by guessing who cares about what you do based on the outcomes they get.

5. Iterate, improve, and evolve both your product and your market.
   Note: It can happen that some day your product changes so much that your super fans no longer like it, and that’s ok. I’ve observed this phenomena with fresh and cool niche music that follows the MAYA principle when the band grows into the mainstream.

I suggest you write down what you’re going to do in a notebook and you make the habit of coming back to it regularly, this way you’ll help yourself re-focus on what matters and re-evaluate your approach and your progress. I had to learn this the hard way myself when I was working on solo projects.

Looking for your super fans, hypothesizing and iterating about who they are (systematically), giving them the importance they deserve, denoting them as your target audience company-wide, brining them in regularly and repeatedly, showing them your prototypes, and learning from them are underrated and often ignored activities that can help entrepreneurs navigate the problem space and help their ventures thrive and survive by creating valuable products that matter to someone somewhere.