What Building an App with Zero Coding Background Taught Me About Vibe Coding

by Jackson Sophat on Unsplash

I do not know Swift at all, and I have no iOS development background. But recently, starting from a vague idea, I used Codex to finish an iOS app. Then I kept going: App Store release materials, a website, marketing assets. I still reread that list with some disbelief, because a year ago none of it would have been within my reach. What makes this worth writing down is not that I made another product. It is that someone who could not have crossed the engineering barrier completed the whole journey from idea to release preparation with the help of AI coding.

The app is called DailyTrace, a lightweight tool for recording the time of real life. Some quick background: it is not a task manager, and it is not a productivity scoring system. It helps you see roughly where your time goes.

But this article is not mainly about the product. What I want to write about is the first-hand experience: what vibe coding actually changes, and where it is easily misunderstood.

AI Coding Really Does Lower the Barrier to Starting a Product

Many people, the first time they see an AI coding tool, have the same strong reaction: does this mean one sentence is enough to produce an app? Can everyone program now? The idea is clearly exaggerated. But it is not entirely wrong.

Before this project, native iOS development was a high wall for me. I could propose product ideas and write requirements. I could judge whether a tool should be light or heavy, and whether an interaction felt right. But actually writing SwiftUI pages, handling SwiftData, local state, widgets, Live Activities, system permissions, and build configuration — none of that was work I could do on my own.

AI coding changed the entry point. It let me keep pushing "I want to build a tool like this" forward, instead of stopping at "I have an idea."

And what came out of it was not a toy prototype with only a home screen. I finished SwiftUI pages, local storage, a timeline, statistics views, share images, widgets, Live Activities, localized copy, internal testing, and separation between internal and production builds — plus the App Store materials and a privacy write-up. Typing that list out still surprises me a little. In the past, for someone who does not know Swift, this would have been very hard to do alone. That is what genuinely excites me about AI coding: it lowers the barrier to starting a real product.

But It Is Not "a Few Sentences and You Have an App"

A lower barrier does not mean a few sentences produce a good product. AI makes it easier to start, but it does not automatically produce the right thing. It can also implement a wrong direction quite completely — and unsettlingly fast. If you begin with a vague "make a time-tracking app" and keep asking the AI to extend it, you will likely end up with something that has many features and no clear direction.

So I do not think of vibe coding as a casual way to build, where you prompt whatever comes to mind and keep stacking features as long as it runs.

At least in this project, effective vibe coding required explicit constraints: state the goal, limit the scope of each change, define what success looks like, then verify the result. What surprised me was how much of my effort went into telling the AI what not to do. Left to itself, it would refactor code nobody asked it to touch, or dress up a small fix with abstractions the project did not need. It was never malicious — just eager — and reining in that eagerness became a routine part of the work.

AI executes fast, which is both the advantage and the risk. It speeds up the feedback loop, but it should not lower the bar. If anything, faster iteration means you need to know even more clearly what you want and why.

Get the Idea Clear Before Writing Code

This project did not start from a complete, well-defined product plan. At first I only had a vague idea: I wanted a very light tool for recording the time of real life — not a task manager or a Pomodoro timer, and definitely not a system that grades my discipline. It should simply help me see how my time is actually spent.

The direction sounds simple. Once you start thinking it through, the questions pile up. Should there be tasks? Tags? Should the app remind users to back-fill records, or analyze the empty time, or have AI summarize your day? Each feature looks reasonable on its own. Stacked together, they would quietly turn a light tool into another complicated system.

When this happens, my approach is to discuss with the AI first, but not to say "start coding." Instead, I have it ask me questions: What problem does this product solve, and for whom? What is the core flow? Which features look useful but might make the product heavier? The value of this process is not that the AI hands me answers. It is that it unfolds a muddled idea far enough for me to see which parts I have not actually thought through.

There is something to watch out for here, and it caught me off guard at first: AI really wants to please you. If I ask "should we add an AI summary feature," it happily designs a plausible plan in that direction. If I ask "should we remind users to back-fill records," it keeps going — a full reminder strategy, complete with trigger conditions and notification copy. The problem is that each of these plans can stand on its own and still not fit what the product wants to be. It took me a while to stop reading its enthusiasm as endorsement. So at the requirement stage, talking with the AI is not about letting it decide for me. It is about using it to keep asking myself: Do I really need this? Does it solve the core problem, or does it just make the product look more complete? Will it change the restraint I wanted in the first place?

The core boundaries came out of exactly this kind of convergence: tap an activity to start recording; only record what the user actively records; do not analyze empty time; no discipline scores; no task management; no AI analysis in the first version. None of these judgments is complicated. But they matter, because they set the direction for all the design and development that followed.

This is also how I came to understand vibe coding: it does not begin at the moment you write code. Requirement shaping and boundary convergence are part of it too.

Write Judgments into Documents, Not Just Conversations

Once the idea was talked through, the next step was not to have the AI write code at scale. It was to write the judgments down. Through development I became more and more certain: documentation matters enormously. I do not mean documents for the sake of looking formal, or process materials written for someone else to inspect. They are closer to shared-context infrastructure between me and the AI. And I did not believe this from the start.

Before this, I built a smaller project with almost no documentation, relying on talking with the AI and patching requirements as I went. Early progress was fast — deceptively fast. It even made me feel that you could let the AI build the product first and adjust slowly later. Then the middle and late stages arrived, and so did everything I had not thought through. The requirement boundaries were never clear, so the plan kept shifting under me, and I kept papering over the gaps with local patches. A project that was not inherently complex dragged on far longer than expected. The frustration of that stretch is what finally converted me.

That experience made me realize that AI can finish a lot of surface work quickly, but if the upfront judgment is thin, the small remaining part can consume the most energy. Worse, some problems cannot be fixed by adjusting details — the technical approach or the product boundary was never sound to begin with.

In this project, I wrote everything down: product spec, business rules, technical design, UI guidelines, development plan, dev log, release notes, screenshot plan. It looks like a lot, but every kind of document solves the same problem: when development is not finished in a day but stretches across dozens of conversations and several feature phases, how do you keep the project moving in the same direction?

I gradually formed a habit: every time a key judgment takes shape, write it into the corresponding document, and every time the implementation changes, sync the change back. Do not assume that in the next conversation, the AI will naturally remember what has already been ruled out. It will not.

Human memory blurs, and AI context shifts. If a judgment lives only in a conversation, it is easily forgotten later in development. "No empty-time analysis" and "no productivity scores" are not small page-level details. They are product direction, and they have to be written down so that the statistics, the share images, the App Store copy, and the privacy notes can stay aligned later.

Documents have another function: they force me to state my judgments clearly. Sometimes I think I have figured something out, but the moment I try to write it as a product rule, gray areas appear. After an activity is deleted, what happens to its history? Do statistics count only completed records, or in-progress ones too? If these questions are not written down, they become on-the-spot decisions during development. Enough on-the-spot decisions, and the product slowly loses its consistency.

Adding Traditional Chinese support later made this very concrete. I had assumed localization was mostly a matter of converting simplified characters into traditional ones. It was not, and the edge cases kept surprising me. Which copy follows the app language? Which content should preserve the user's original input? Should dates, number formats, and the first day of the week be overridden by the app language? All of this needs to be written down in advance. Otherwise the AI can easily read "localization" as "replace all the text," while a real product has content that no language setting should change.

Turn Mature Standards into Context AI Can Use

UI and interaction are where I felt the cost of unclear requests the most. If all you say to the AI is "make the interface nicer" or "make it feel like a real iOS app," it will likely give you something that looks complete but does not match platform conventions. Requests like these sound directional, but they carry no standard — what counts as nicer is left entirely to the AI's own interpretation, and there is nothing to review against.

The problem was not the AI's ability. It was that I had not given it a frame of reference. And a frame of reference often does not need to be invented. Interface design is a typical example: this knowledge is not easy to master, and even with years of experience you still have to think it through case by case. But Apple has already distilled it into a mature, public set of Human Interface Guidelines, updated with every generation of iOS and macOS. For an ordinary developer, consistently reaching the level of these guidelines is already a very good outcome.

This also widened my understanding of documentation: what is worth turning into context is not only the judgments you form yourself, but also the mature standards your industry already has. So I scraped the relevant pages of Apple's site into Markdown, put them in the project, and made them a reference the AI can read at any time. From then on, for UI and interaction work, I stopped saying "make it nicer" and started asking it to check against the guidelines: Does this control match platform conventions? Is the interaction feedback clear enough? Does this design violate expectations iOS users already hold?

The change is that the same request went from "adjust by feel" to "check item by item against a standard." This is not treating the guidelines as a constraint. It is giving the AI a reliable frame of reference — and the difference showed up quickly, in interfaces that started to feel like an iOS app rather than a rendering of one.

The lesson generalizes: wherever a field already has mature standards, you can turn them into context the AI can read, then ask it to work against that standard. It works far better than saying "be more professional."

What Really Separates People Is Judgment

Once AI lowers the barrier to writing code, in theory more and more people acquire some kind of "programming" ability. As long as you can express an idea, AI can generate the code and even a product that looks complete. In the past, "can you write it" was itself a barrier. Now that this barrier is lower, the questions that really matter move forward: What should be built, and what should not? Which results are merely complete, and which are actually correct? In the end, the most important thing in product development has not changed: serving real user needs. That a feature can be built quickly by AI does not mean it solves a user's problem. Vibe coding can change the path of implementation, but it cannot replace judgment about the need itself.

Because of this, I have come to think the impact of vibe coding is not evenly distributed. People who already have product thinking and product experience may benefit the most: they knew what should be built and how restrained the product should be — they were only limited by engineering ability, and vibe coding fills exactly that gap. For people who can already code, it mostly improves development speed and the speed of trial and error. And for people with no product or development experience, it is more like suddenly receiving a powerful tool without a manual: the tool can do many things, but the user still needs to know what to use it for, and how to judge whether the result is right. Being able to tell "should build" from "should not build" is exactly the value of experience.

I used to work at Smartisan and Xiaomi on tool-type products. That experience mattered a lot in this project. It made it easier for me to see that "can be built" does not mean "should be built," and that "complete" does not mean "right for now." Looking back, this experience showed up in five kinds of situations: product judgment, business judgment, technical judgment, engineering habits, and judgment about visuals and expression.

The first is product judgment. Take interaction documents. AI can organize page structures, user flows, and interaction notes from requirements, but whether what it generates is reasonable still needs human review. Where should an entry point live? Will a reminder create pressure, or an empty state imply the user has not done enough? Does an operation interrupt what should be a lightweight recording flow? None of these are formatting questions. They are product judgment questions.

The second is business judgment. Some business logic makes sense only to people who actually do the work, and who face concrete users and concrete flows over a long time. AI tends to adopt the most common, most generic business logic and generate a plausible default plan. But in real products, the differences that matter are often hidden exactly outside those defaults.

I ran into a problem like this on an earlier project, CanBin, a garbage-classification app. The initial recognition logic used a model that was generic but not true to the business: classification results went straight into four categories — green, blue, black, special. The logic looks reasonable, because many people intuitively understand waste sorting as "green bin, blue bin, black bin, special recycling." AI easily adopts the same common, abstract model.

But in the actual business, the authoritative classification is not the color of the bin. It is the official classification standard published by the local government. Different cities and provinces can have different category names, recyclable items, exceptions, and disposal instructions. Bin color is only an auxiliary expression in the UI — it helps users understand and sets icon colors, but it cannot serve as the final basis for classification.

What this correction exposed is the core problem: AI easily mistakes the superficially common way of classifying for the business truth. It can quickly produce a plausible implementation, but if no one from the business side points out that the official classification is primary and bin color is only supporting information, the system will drift from the real scenario exactly where it matters. AI is very good at assisting implementation, but by default it leans toward generic business logic. The real business constraints — authoritative sources, regional differences, priorities — are usually known only to the people who actually do the work. AI has to be told these rules explicitly. Otherwise it will mistake common practice for correct practice.

The third is technical judgment. During development, the stacked bar chart in the week view suddenly stopped responding to taps. It had worked before, and nothing about the chart itself had changed — which made the bug maddening for a moment, then genuinely interesting. If the problem is described only as "taps do not work," AI can certainly investigate, but the search space is large. My own hunch was that the problem was probably not in the chart at all, but in an earlier change to swipe-gesture handling that affected tap recognition. Once I gave Codex that judgment, it could investigate close to the root cause — gesture handling, event priority, hit areas — instead of searching broadly through unrelated code.

The fourth is engineering habits. The bug-report format from my previous jobs turned out to be unexpectedly useful in vibe coding. A good bug description states four things. Preconditions: which screen, under what conditions. Steps: how to reproduce. Expected: what each step should produce. Actual: what happens instead. Most of the time, telling the AI "there is a bug here" is not enough. Described as preconditions, steps, expected, and actual, the problem becomes much clearer, and the AI can locate and fix it much more easily.

Later, when describing problems to Codex, I naturally kept this order. The more complex the problem, the less you should rush the AI into guessing. First make the problem reproducible and verifiable.

Version control is a similar kind of experience. AI can modify code very quickly, but without this background, the issue may not be "can you use Git." It is that you may not realize a real project needs version control at all. You may just be talking with the AI round after round, letting it keep modifying files, without realizing that wrong directions should be revertible and that different phases of work should have boundaries.

This matters even more because AI can modify many files at once and push a large amount of work forward in a short time. Without version-control awareness, a project quickly accumulates a pile of changes no one can account for: you do not know which change introduced a problem, and you do not know how to return to a correct state. Just talking with the AI will probably never make you aware of this infrastructure. AI can help write the code, but you still need to know how a project should be managed.

The fifth is judgment about visuals and expression. Development is full of moments that need human acceptance, and a typical example is the share image. A share image looks like an accessory feature, but it carries a lot of the product's character. This tool's statistics share images cannot look like report cards or workout check-in posters. They should show the distribution of the time the user recorded, in a voice that stays neutral and restrained — no ranking pressure, no hint about whether your day was good or bad.

Codex could implement a share-image page quickly, and render 9:16 previews from the existing statistics. But a first version that runs is not the same as a right one, and the early drafts frustrated me in a way I found hard to articulate at first. Some looked too much like generic marketing posters. Others packed the information too densely, or drew charts that were technically fine but did not match the direction of quietly presenting facts.

At that point, my job was not to say "good" or "not good." It was to find words for that frustration and turn it into specific deviations: this looks like a template; the information density is too high here; this should directly show the day as a timeline; the caption should read like the brand speaking, not a feature description.

The value of AI is that it can adjust quickly based on this kind of feedback. But the direction has to be held by me. This process confirmed something for me: AI can execute, but a human must own acceptance. Especially for visuals, copy, and product character, "the code runs" proves very little. Being able to generate an image does not mean it is fit to share, and fluent copy does not mean it says the right thing.

I also found that visual feedback cannot just be "this does not look good." It has to say what it fails to match: "not this product's character," "information density too high," "looks like a template," "not neutral enough," "time scale unclear." The more specific the feedback, the more easily the AI converges in the right direction. This is exactly where past product experience and taste directly shape the result of working with AI.

One Person, Like a Small Team

Only after the idea work, the documents, the standards, and the judgment does the value of AI fully open up. My role in this project was closest to "product manager plus project lead." I decided what the product would and would not become, made the trade-offs among features, complexity, and experience, and did the final acceptance of what the AI produced.

Nearly all the remaining execution work was carried by the AI.

This is why I do not think vibe coding is as simple as "AI writes code instead of people." It is more like temporarily organizing a small team. On this team, someone writes engineering code, someone maintains documents, someone breaks a feature into executable steps — but the team still needs a person to set direction and judge whether the final delivery is correct.

When I need to think a product boundary through, the AI lists the questions for me; when I need the boundary pinned down, it turns the discussion into a spec. It reads code, changes code, and runs checks. It writes the settled implementation back into the dev log and the technical design, and when I prepare for release, it checks naming, privacy, the internal scheme, and the App Store materials. Watching one tool slide between all these roles was one of the quieter pleasures of this project.

This feeling was especially strong when building the Live Activity and the Dynamic Island reminder. I went in thinking of it as "add a Dynamic Island screen." It was not, and the number of decisions hiding behind that one sentence genuinely surprised me: the current recording state, the widget extension, relaunch recovery, accidental-tap risk, whether there should be a stop button, whether to introduce remote push. And beyond that, these decisions had to be written back into the documents. Codex could handle each of these problems separately, but I had to decide which ones to do at all.

It made me feel that one person is no longer just writing code alone, but managing a very small collaborative team. Of course, this team does not run itself. AI does not naturally know that this tool should be restrained, or that I do not want it to become a complex productivity system. It can do a great deal of work — provided I keep supplying context, pointing out deviations, and accepting the results at every stage.

In the End, It Still Comes Down to Saying Things Clearly

Having finished this app, I am pragmatically optimistic about AI coding. I do not think it is just a toy, and I do not think it can replace developers yet. What it truly changes is the scope of work one person can carry, and the speed at which an idea becomes a real product. Here is the honest tell: during development, I used up the 5-hour usage limit almost every day, and waiting for it to reset felt like a real interruption. I would time it, and pick up the moment the limit came back. That is a little embarrassing to admit, but it says something about how addictive the feedback loop is — propose an idea, see it implemented, find problems, keep adjusting. The whole process keeps handing you a sense of forward motion.

In the past, building an independent product alone made it easy to get stuck in one role: the product is thought through but engineering moves slowly, or the feature is done but the release materials never quite get made. AI cannot remove all of these difficulties, but it genuinely shortens the distance between the stages.

I do not want to package this as a magic method. It is not thinking-free, and it is certainly not generating a pile of output and calling it done. If AI changed anything, I think it changed more than the speed of writing code. It made saying things clearly more important: say the goal and the boundaries clearly, write the judgments into documents, make the feedback specific enough to act on. In traditional development these abilities always mattered. In AI collaboration they have become the core abilities — because AI can execute quickly, but it needs to know what counts as right and what counts as drift.

So for me, vibe coding is not a way to be lazy. It is a new way to collaborate: AI makes execution fast, while the human holds the direction and signs off on the result. Its core is not letting AI think for me. It is letting me push a vague idea all the way into a real product.

That is what this project was for me. It began as a fuzzy idea about recording the time of daily life, and through round after round of work with Codex it slowly became an app that runs — one that can keep being polished, and is ready to move toward release.

If you are also interested in Codex, vibe coding, or independent development, I would love to hear from you.