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 went on to prepare the App Store release materials, build the website, and produce the marketing assets. 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 and the thinking that came out of it: what vibe coding actually changes, where it genuinely works, 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 or a website? 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, write requirements, judge whether a tool should be light or heavy, and evaluate whether an interaction or a visual 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. I also prepared App Store release materials, a privacy write-up, and a screenshot plan.

In the past, for someone who does not know Swift, that would have been very hard to do alone. What genuinely excites me about AI coding is that 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 generate pages, code, and documents quickly. It can also implement a wrong direction quite completely, and quite 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: prompt whatever comes to mind, and as long as it runs, keep stacking features.

At least in this project, effective vibe coding required explicit constraints. State the goal. Read the existing code. Match the project's style. Limit the scope of each change. Define what success looks like. Verify the result. And often, tell the AI explicitly: do not refactor in passing, do not add features nobody asked for, do not over-engineer a small fix.

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, what you do not 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, not a Pomodoro timer, not a habit tracker, and 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? Goals? Should the app remind users to back-fill records? Should it analyze the empty time? Should 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? Who is it for? In what situations? 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: AI tends to please. If I ask "should we add an AI summary feature," it will happily design a plausible plan in that direction. If I ask "should we remind users to back-fill records," it will keep going: reminder strategy, trigger conditions, copy. The problem is that each of these plans can stand on its own, and still not fit what the product really wants to be. 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 make the product heavier? 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, product definition, and boundary convergence are all part of vibe coding.

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, developing, and patching requirements as I went. Early progress was fast. It even made me feel that you could let the AI build the product first and adjust slowly later. But in the middle and late stages, the problems I had not thought through arrived all at once: unclear requirement boundaries, plans that kept changing, more and more local patches. A project that was not inherently complex ended up taking far longer than expected.

That experience made me realize that AI can finish a lot of surface work quickly, but if the upfront judgment and documentation are thin, the small remaining part can consume the most energy. Worse, some problems cannot be fixed by adjusting details. The technical approach, the product boundary, or the information architecture 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 goes through many conversations, many revisions, and many 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; every time the implementation changes, sync the change back into the documents. Do not assume that in the next conversation, the AI will naturally remember what has already been ruled out.

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, no productivity scores, no AI explaining the user to themselves — these are not small page-level details. They are product direction. They must be written into documents, 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? Should the share image emphasize results, or stay neutral? 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: the problem was not just converting simplified characters into traditional ones. Which copy follows the app language? Which content should preserve the user's original input? Should dates, times, 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 replacing 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, what counts as iOS-like — it is all left 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. Human 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? Are the hierarchy and navigation reasonable? 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 more reliable frame of reference: it knows what to align with, I know what to review against, and the result lands much closer to how a real iOS app should feel.

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

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, the pages, the documents, 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? What should not? Which features only look useful but will make the product heavier? 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. That a plan looks complete does not mean it carries enough user value. 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, what users needed, 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, when to stop, 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"; that "complete" does not mean "right for now"; that "rich" does not mean "more usable." 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? Will 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, sets icon colors, and decides whether to show a map entry. 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, completing code, and refining prompts, but by default it leans toward generic business logic. The real business constraints, authoritative sources, regional differences, and 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, I found that the stacked bar chart in the week view suddenly stopped responding to taps. If the problem is described only as "taps do not work," AI can certainly investigate, but the search space is large. My own judgment was that the problem was probably not in the chart itself, 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 very 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. It needs to know the context, what the user did, how the system should respond, and where reality deviates. 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: preconditions first, then steps, then expected, then actual. 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 every important change should be recorded, 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, and they cannot look like 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. Some visual treatments looked too much like generic marketing posters. Some information hierarchies were too heavy. Some titles were not specific enough. Some charts could technically be drawn, 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 point out the specific deviation: this looks like a template; the information density is too high here; this should directly show the day as a timeline; the time scale should be clearer; 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. A complete layout does not mean it fits the product. 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. I judged whether a design fit the character of this tool. I made the trade-offs among features, complexity, and experience. And I 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 checks for gaps, someone breaks a feature into executable steps. But the team needs someone to manage it, someone to set direction, and someone to judge whether the final delivery is correct.

When I need to think a product boundary through, the AI can list the questions for me. When I need to pin the boundary down, it can turn it into a spec. When I need a feature implemented, it can read code, change code, and run checks. When documents need syncing, it can write the settled implementation back into the dev log and the technical design. When I prepare for release, it can check naming, privacy, the internal scheme, and the App Store materials.

This feeling was especially strong when building the Live Activity and the Dynamic Island reminder. It was never as simple as "add a Dynamic Island screen." It meant considering the current recording state, the widget extension, relaunch recovery, and accidental-tap risk, plus whether there should be a stop button, whether to show statistics, and 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, and which not to.

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, clarifying standards, 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. During development, I used up the 5-hour usage limit almost every day. Waiting for it to reset felt like a real interruption — I would even time it, and pick up the moment the limit came back. The feedback loop is that fast: 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. The code is written, but the documents fall behind. The feature is done, but the release materials are not ready. The visuals need adjusting, but iteration costs too much. 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, it is not learning-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 clearly, say the boundaries clearly, write the judgments into documents, make the feedback specific, spell out the acceptance criteria. In traditional development these abilities always mattered. In AI collaboration they have not disappeared — they have become the core abilities. Because AI can execute quickly, but it needs to know where to execute, 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 owns direction, standards, and final acceptance. 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. Through round after round of conversation, judgment, documentation, implementation, and verification with Codex, it slowly became an app that runs, that can keep being polished, and that 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.