Codex Changed How I Think About Building
There's a before and after for how I think about building things.
Before: I thought in constraints. "How will I build this? Is this technically possible for someone who isn't a developer? How long will this take to learn?" The barrier between idea and attempt was high enough that most ideas never became attempts.
After: Those questions still exist, but they're no longer the first ones. The first question now is "what exactly do I want this to do?" — and once I can answer that precisely, the path to building it is usually findable.
Codex — and AI-assisted coding more broadly — didn't teach me to code. What it did was change the relationship between clear thinking and shipped things. That change has been more significant than I expected.
The Habit App and What It Became
The clearest example is the Habit Tracker I built for personal use.
It started simple: Track two things — time spent reading (timer-based) and daily habits like brushing at night (check-in based). A straightforward personal accountability tool.
But once I had the basic structure working, I kept noticing adjacent problems. Accountability works better when it's social — when someone else can see whether you're keeping your habits.
What it became:
- ✅ Friend requests and discovery
- ✅ Shared streaks with mutual visibility
- ✅ Unique invite links
- ✅ Email and phone-based friend discovery
- ✅ Permission controls for activity visibility
- ✅ Notification systems
The final product is something I would not have attempted before AI-assisted coding — not because I couldn't imagine it, but because the distance between the idea and a working version felt too large to justify starting.
What Codex did was compress that distance. Each feature became a specification problem — describe precisely what you want — rather than a learning problem — acquire the skill to build from scratch.
Specification Is the Actual Skill
Here's the thing I tell people who ask about AI coding tools:
The output quality is almost entirely determined by the quality of the input.
| Prompt Quality | Output |
|---|---|
| "Build me a habit tracker." | Generic, often wrong |
| "Build a React component that displays a circular progress ring showing % of daily habits completed, where habits is an array of objects with id, name, and completed boolean, filling clockwise from the top in green." | Usable, precise |
The skill that matters is specification — the ability to describe, precisely and completely, what you want a system to do.
This turns out to be the same skill that matters in:
- Engineering requirement documents
- Marketing briefs
- Product specs
- Growth strategy decks
It's the discipline of removing ambiguity before you start.
AI tools reward this discipline heavily. Ambiguous prompts produce ambiguous output. Precise prompts produce precise output. The limiting factor is almost always the clarity of the specification, not the capability of the tool.
My Prompting Workflow
Developed through iteration across six projects:
- Write a detailed specification — not "a chatbot" but exactly what it fetches, how it processes, what it returns, what it does with edge cases
- Break into phases — authentication, data model, core functionality, UI, edge cases
- Build one phase at a time — test thoroughly before moving to the next
- When something breaks — describe the breaking behaviour precisely rather than asking generically for help
The specification step is where most of the real thinking happens. The building step is faster than it used to be.
What It Changed About My Work
Change 1: I raise more ideas now.
When building required months of engineering time, I filtered ideas heavily. Small operational improvements — a dashboard that shows me one thing, an automation that saves two hours a week — weren't worth the cost of the engineering process. Now they are.
A dashboard I spec on Monday can be live on Thursday. An automation that seemed too small to prioritize gets built in an afternoon.
The aggregate effect of shipping many small, useful things is larger than it appeared when those things were stuck in backlogs.
Change 2: The set of problems I'm willing to attempt has expanded.
Not in a hyperbolic "AI can do anything" way. But in a practical way, the set of problems worth attempting has grown meaningfully. And expanding the set of things you attempt is how you find the things that turn out to matter.
The Honest Limits
I want to name what AI coding tools don't do, because hype obscures real limitations:
They don't make architectural decisions well. When I built the 4DX dashboard on Firestore and Next.js, I made early architectural choices that I later had to undo. The tool helped me build what I described — but describing the wrong thing efficiently still produces the wrong thing. Architectural judgment comes from experience, not AI assistance.
They don't debug complex systems reliably. When something breaks across multiple interacting components, the debugging process requires systematic thinking about what each piece is doing. AI assistance is useful but not sufficient here.
They don't replace understanding what you're building. If I don't understand the difference between a client-side fetch and a server-side API call, I'll make bad decisions about when to use each — and no AI assistance will catch that error, because it won't know my intention.
The tools amplify clear thinking. They don't substitute for it.
What This Means More Broadly
The most durable skill in the next decade of knowledge work is probably the one that's always been most valuable: the ability to think clearly about a problem. To define it precisely, break it into parts, identify constraints, and work toward a solution systematically.
AI tools make that skill more powerful because they compress the distance between clear thinking and tangible output.
A person who thinks clearly and can specify precisely will get more out of these tools than a person who codes better but thinks less clearly.
That's a meaningful shift. And it rewards people with varied backgrounds — engineering, marketing, operations, design — who've developed clear thinking in different domains.
The domain expertise is the moat. The tools are increasingly available to everyone.
Dhairya Mehta is Director of Growth and Marketing at Testbook, where he owns the P&L of India's largest exam-prep subscription. He writes about growth, India's developing market, and building things.
Post a Comment