YouCanBuildTech articles

What Is Debugging in the AI Era? | YCBT

2026-09-06T00:00:00Z

You might have heard a lot about debugging and that it is one of those things you absolutely need to learn if you want to become a coder — or even a vibe coder.

Traditionally, that was true. Debugging was one of the fundamental skills of software development. You wrote code, something went wrong, and then you had to investigate your own code to figure out what was causing the problem.

But here is the thing: in the modern era, debugging is becoming something conceptually different.

When you work with a capable coding agent such as Codex, Claude, or another agent that understands your whole project, a huge amount of traditional code-level debugging can be performed by the agent itself. It can search the project, inspect functions, follow data, read errors, and find where something went wrong without you manually tracing every line.

In our experience, the overwhelming majority of that lower-level debugging work has effectively moved to the coding agent.

That does not mean debugging has disappeared. The human part has moved upward. Increasingly, your job is to recognize exactly what is wrong, describe exactly what happened, and explain exactly what you wanted instead.

And sometimes the bug is not something you wrote wrong in the code.

Sometimes it is something you said wrong.

What Is Debugging?

At its simplest, debugging is the process of finding out why software is not behaving the way it should and correcting the problem.

A bug can be obvious. A page might not load. An application might crash. A button might do nothing when you click it.

But bugs can also be subtle. The application may run perfectly while producing the wrong result. A setting might appear to save but disappear after restarting the app. A user interface might look correct on desktop but overlap on mobile. Everything might work until one particular sequence suddenly breaks something.

Traditionally, figuring out why could mean examining source code, reproducing the problem, studying console errors and logs, reading a stack trace, inspecting variables, setting breakpoints, stepping through functions, and eventually finding the root cause.

Those concepts still exist. It is worth knowing what they mean even if you never become an expert in manually using all of them.

What Do Bugs Actually Look Like?

For someone who has never programmed before, the word bug can sound more mysterious than it really is.

Usually, the programmer first notices that something is wrong. The page does not appear. The answer is incorrect. A button suddenly stops working. Everything was fine until the user did one particular thing.

Here are three traditional examples.

Bug Example 1: The Page Does Not Load

Imagine a website that loads a user's account information from a server. The programmer refreshes the page expecting to see a profile, but the profile area is blank.

The browser console shows:

Uncaught TypeError: Cannot read properties of undefined (reading 'name')
    at renderProfile (profile.js:14)
    at loadProfile (profile.js:8)

The relevant JavaScript might look like this:

async function loadProfile(userId) {
    const response = await fetch(`/api/users/${userId}`);
    const data = await response.json();

    renderProfile(data.user);
}

function renderProfile(user) {
    const profile = document.querySelector("#profile");

    profile.innerHTML = `
        <h2>${user.name}</h2>
        <p>${user.email}</p>
    `;
}

The server actually returned:

{
    "name": "Jordan",
    "email": "jordan@example.com"
}

The faulty line is:

renderProfile(data.user);

It should have been:

renderProfile(data);

The code expects data.user to exist, but there is no user object inside the returned data. renderProfile() receives undefined, and JavaScript throws an error when it tries to read user.name.

This is classic old-school debugging. The programmer sees the symptom — the profile does not appear — and uses the console error and stack trace as clues until they find the wrong assumption in the code.

The process starts with a simple question:

The page does not load. Why?

Bug Example 2: Everything Works, but the Output Is Wrong

Not every bug produces an error message.

Imagine a checkout where a customer buys two products costing $50 each. The cart works, the checkout loads, and there are no red console errors.

But the page displays:

Order total: $150

The correct answer should be $100.

The function might look like this:

function calculateOrderTotal(items) {
    let subtotal = 0;

    for (const item of items) {
        subtotal += item.price * item.quantity;
    }

    const shipping = 50;
    const total = subtotal + shipping;

    return total;
}

The faulty logic is:

const total = subtotal + shipping;

For this store, shipping was supposed to be free.

Nothing about the JavaScript is invalid. The program has not crashed, and there may be no warning at all.

The computer is doing exactly what the programmer told it to do.

It was simply told to do the wrong thing.

This is a logic bug. Traditional debugging was never only about red error messages. Programmers also had to recognize when the result itself was wrong.

Bug Example 3: Everything Is Fine... Until You Do This

Some bugs are harder because the application appears completely normal most of the time.

Imagine a business application with a customer record screen. A user opens a customer, changes the information and presses Save. It works.

Then somebody discovers another sequence: open the customer, make a change, leave without saving, return to the screen, and press Save.

Now nothing happens.

The console shows:

TypeError: Cannot set properties of null (setting 'name')
    at saveCustomer (customer.js:31)
    at handleSave (customer.js:42)

The relevant code might look like this:

let currentCustomer = null;

function openCustomer(customer) {
    currentCustomer = customer;

    document.querySelector("#name").value = customer.name;
    document.querySelector("#email").value = customer.email;
}

function leaveCustomerScreen() {
    currentCustomer = null;
    showDashboard();
}

function returnToCustomerScreen() {
    showCustomerScreen();
}

function saveCustomer() {
    const name = document.querySelector("#name").value;
    const email = document.querySelector("#email").value;

    currentCustomer.name = name;
    currentCustomer.email = email;

    updateCustomer(currentCustomer);
}

The program finally fails here:

currentCustomer.name = name;

currentCustomer.email = email;

But the actual problem began earlier:

currentCustomer = null;

When the user left the screen, the application cleared the selected customer. When they returned, the screen appeared again, but the customer object behind it was never restored.

The important discovery is the sequence:

Open customer → leave screen → return → press Save.

Traditionally, a programmer might reproduce those steps, add logging, set a breakpoint, inspect currentCustomer, and find exactly when it became null.

This is why reproducing a bug has always been such an important debugging skill. “The Save button sometimes doesn't work” is vague. “It fails after I leave the customer screen, return, and press Save” gives you something concrete to investigate.

That principle has become even more useful in the AI era.

The Traditional Debugging Vocabulary

If you spend time around programmers, you will hear a number of terms associated with debugging.

A debugger is a tool that lets a programmer inspect software while it is running. A breakpoint pauses the program at a particular point so you can see what is happening. A stack trace shows the sequence of functions that led to an error. Logs are messages generated by the program, while the console is one of the places developers see those messages, warnings and errors.

You may also hear about syntax errors, runtime errors, exceptions, logic bugs, crashes, regressions, and root causes. A syntax error means the code cannot be interpreted correctly. A runtime error happens while the software is running. A logic bug produces a valid but incorrect result. A regression happens when a new change breaks something that previously worked.

You should know that these things exist. But that does not mean you need to spend months mastering all of them before you can build software with AI.

Debugging Used to Mean Investigating the Code Yourself

Traditional debugging could consume a huge amount of a programmer's time. Something went wrong, so the developer had to reproduce the error, inspect logs, find the relevant code, add temporary logging, set breakpoints, inspect variables, and gradually narrow down the problem.

The goal was to move from the visible symptom to the underlying root cause.

If clicking a button crashed an application, the button itself might be fine. The actual cause could be several functions later, where a missing value causes something else to fail.

Historically, the programmer had to discover that chain.

The Good Bug and the Bad Bug

There is something else about traditional debugging that we think has been lost in the AI era.

When we were programming back in 2013, debugging was often part of learning the programming language itself. You wrote something, it failed, and then you spent twenty minutes, an hour, or sometimes much longer figuring out why.

Sometimes that was incredibly valuable.

We could call this the good bug.

Maybe you misunderstood how a function worked. You did not understand scope. You made the wrong assumption about an object or variable. Eventually you found the problem, fixed it, and understood the language better than you did an hour earlier.

There was also a genuine dopamine hit when it finally worked. That moment when a program had been broken for an hour and then suddenly did exactly what you wanted was part of programming.

But there was also the bad bug: forty minutes wasted because of a typo, a missing character, the wrong file path, or some tiny mistake that taught you almost nothing.

Modern coding agents are very good at removing both.

That is an enormous productivity improvement, but it changes the learning experience. If Codex finds the wrong variable, fixes the function and verifies the result in seconds, you may never need to understand exactly what went wrong.

For a vibe coder, that may be completely fine. But AI has started to separate fixing the bug from learning why the bug existed.

If you want the learning experience, you may now have to choose it. Ask the agent what caused the problem. Ask why the fix works. Look at the changed code.

Otherwise, you can simply continue building.

Coding Agents Changed the Investigation

A few years ago, AI-assisted coding often meant copying a piece of code into a chat window. If you showed the AI one function, it knew about that function. If the real problem existed somewhere else in a 20,000-line project, you had to figure out what additional context to provide.

Modern coding agents can work across the project itself. They can search the repository, inspect related files, follow function calls, examine configuration, read console output, trace state, and make coordinated changes across the codebase.

In our experience, this means that the overwhelming majority of traditional code investigation can now be delegated to the coding agent.

This is where we think the meaning of debugging begins to change.

Modern Debugging Is Learning to Say Specifically What Is Wrong

If we had to reduce modern debugging to one skill for an AI-assisted builder, it would probably be this:

Telling an agent, “Fix this,” gives it very little useful information. “The menu is broken” is slightly better, but still leaves a lot open to interpretation.

Compare that with:

On mobile, when I open the navigation menu, it covers the page heading. The menu should open beneath the header without overlapping the heading.

That tells the agent where the problem happens, what triggers it, what the result is, and what should happen instead.

Or:

When I select a new theme, the preview changes correctly. After I refresh the page, it returns to the default theme. I want the selected theme to remain saved.

You may have no idea whether the problem is in frontend state, local storage, an API route, the backend or a database.

That is fine. The agent can investigate that.

Your job is increasingly to describe the behavior clearly enough that the agent knows what to investigate.

What Happened, and What Should Have Happened?

A useful modern bug report usually contains four pieces of information: what you did, what happened, what you expected to happen instead, and where or when the difference appears.

1What you did
2What happened
3What you expected
4Where or when

Compare:

The Save button doesn't work.

with:

If I open an existing project, change the title and press Save, it works. If I go to Preview, return to the editor and then press Save, nothing happens. The project should save normally in both cases.

The second description gives the coding agent a reproducible condition. Once you can describe the problem precisely, the agent can usually take over the technical investigation.

Narrow Down When the Problem Happens

Another useful skill is narrowing the conditions that cause the problem.

“The app crashes” tells you very little. “The app crashes only when I upload a large image on Android” tells you much more.

Does it happen only on mobile? Only after restarting? Only for one account? Only after a particular sequence? Does it work in one browser but not another?

You do not need to know why yet. You are just narrowing the problem.

One of the Best Questions: What Changed?

If something worked before and suddenly stopped working, one of the oldest debugging questions is still one of the best:

What changed?

Maybe you added a feature, changed a setting, updated a package, or changed something that seemed unrelated.

This is where Git becomes useful. Git keeps a history of changes, and a diff shows what changed between two versions.

A coding agent can often inspect that history itself:

This worked before the last change. Check what changed and find what caused it to stop working.

That can narrow the investigation very quickly.

Do Not Guess the Cause Unless You Know It

Suppose a button does nothing.

You might tell the agent:

The event listener is broken. Fix it.

But perhaps the event listener is fine. Another element may be covering the button. The click may work while the server request fails. The server may respond correctly while the screen fails to update.

By confidently diagnosing the wrong cause, you can point the agent in the wrong direction.

A better report is:

Clicking the Save button produces no visible result. It worked before the previous change. It should save the project and show the confirmation.

Tell the agent what you know. Let it investigate what you do not know.

Not Every Problem Is Actually a Bug

Sometimes the software is doing exactly what it was told to do.

The problem is that what it was told to do was wrong.

Maybe you changed your mind about how a feature should behave. Maybe the plan was unclear. Maybe two parts of the specification contradict each other.

Before changing code, it can be useful to ask:

A coding agent can correctly implement a bad instruction.

The code works.

The idea does not.

Sometimes the Code Is Fine

A problem can also look like a bug even when the source code itself is fine.

Something might work on your computer but fail after deployment. It might work on desktop but fail on a phone. A file may be missing from the build. An environment variable might not be set. A dependency might be a different version.

You may hear these described as environment, build, configuration, dependency, or deployment problems.

For the AI-assisted builder, the useful observation may simply be:

It works locally, but fails after deployment.

or:

It works on desktop, but not in the Android build.

That gives the coding agent somewhere more specific to look.

Sometimes the Bug Is Something You Said Wrong

This is where debugging in the modern era becomes much more interesting.

When programmers wrote the implementation themselves, a large part of debugging involved finding something they wrote wrong.

When a coding agent writes the implementation, sometimes the mistake is something you said wrong.

Maybe you explained a feature badly. Maybe you left something ambiguous. Maybe you described one approach in your project instructions and later asked for another without realizing they conflicted. Maybe your AGENTS.md file says one system controls something while another instruction says something else should control it.

The agent may not have misunderstood you. It may have implemented exactly what you asked for.

The problem is that what you asked for was contradictory, incomplete, or simply different from what you had pictured in your head.

That turns part of debugging into a human communication problem.

Debugging Your Instructions

When something behaves strangely, one of the questions we increasingly ask is not just, “Which function is wrong?”

We ask whether the instructions are wrong.

Did we describe the behavior clearly? Is there an old instruction sitting in AGENTS.md? Did we tell the agent two different things? Did we explain the normal case but forget an edge case?

Sometimes changing the code fixes the symptom while changing the specification fixes the real problem.

That is another kind of debugging:

debugging the instructions themselves.

Sometimes You Are Debugging the Design

The idea goes even deeper.

Sometimes the problem is not the syntax, the code or even one bad instruction. Two ideas inside the product simply conflict.

One system may save changes immediately while another assumes the user must press Save. One screen may treat a setting as belonging to the whole account while another treats it as belonging to one project. The frontend may expect data one way while the backend is designed around another.

Both systems may work exactly as designed.

They simply do not work together.

At that point, debugging starts to become a design and architecture question. You are debugging assumptions, relationships, ownership and behavior.

The coding agent may be perfectly capable of implementing Approach A and Approach B.

The problem is that you asked it to implement both.

The Better the Plan, the Fewer Real Bugs We See

This leads to one of our strongest opinions about AI-assisted programming.

In a well-planned project using a good coding agent, genuinely mysterious code-level bugs have become surprisingly rare in our experience.

We do not mean software can never have bugs. Of course it can.

We mean that the classic picture of programming — constantly fighting broken syntax, mysterious functions and endless crashes — increasingly does not resemble how our better-planned AI projects actually develop.

Most of the problems we encounter now are understandable. An instruction was unclear. A requirement changed. Two systems had different assumptions. We missed an edge case. Something looked wrong and needed adjusting.

Those are problems, but they often do not feel like the mysterious bugs people traditionally associate with programming.

Our MP3 Player Was a Good Example

Our MP3 player project is a good example.

It is not a tiny application. It contains music-library behavior, playback systems, multiple player interfaces, metadata handling, persistent state, visualizers, playlists, favorites, queue behavior, sorting, search and many interconnected features.

Despite that, the project has been remarkably smooth from a debugging perspective. When something did not behave as intended, the problem was usually understandable and easy to describe.

We believe a major reason is that we had already spent a lot of time deciding what the MP3 player actually was before asking the coding agent to implement it.

We had thought through how playback should behave, what should persist, what should not be stored, what different player interfaces could change, what systems should remain shared, and where the boundaries of the product were.

The code came after the concept.

We Have Seen the Same Thing Beyond 40,000 Lines of Code

We have seen the same pattern in even larger projects.

We have worked on SaaS-level software containing more than 40,000 lines of code where serious bugs were surprisingly rare. The size of the codebase did not automatically create chaos because the agent had a coherent architecture and a carefully defined concept to work from.

That experience changed how we think about AI coding.

Forty thousand lines implementing a coherent system can be easier to work with than five thousand lines implementing a confused one.

The quality of the concept matters. The architecture matters. The relationships between systems matter.

And meticulous planning matters.

Most Bugs Begin Before the Code

We increasingly think many software problems begin before the faulty code is written.

They begin when nobody has decided which system controls something, when a feature has only been described superficially, when two parts of the application have overlapping responsibilities, or when the expected result exists in the builder's head but has never actually been explained.

Eventually the coding agent reaches that missing decision and has to make a choice.

Sometimes it makes the choice you wanted. Sometimes it makes another perfectly reasonable choice.

If you never told it which one was correct, that is not necessarily an AI coding failure.

It may be a planning failure.

Why We Plan the Whole Concept

This is also why our approach differs from some traditional software-development advice.

We do not automatically believe every application needs to be built as an endless sequence of tiny milestones where the agent only sees the next miniature task.

Milestones can obviously be useful. But modern coding agents benefit enormously from understanding the whole concept.

Before building, we prefer to think about what the finished product should be, what its major systems are, how they relate, what should be configurable, what should stay fixed, and what important edge cases exist.

Once the concept is coherent, we are often comfortable letting the agent implement substantial parts of it relatively quickly.

The important thing is not making every coding step tiny.

Planning Files Matter

Files such as AGENTS.md, architecture documents, feature specifications and project notes can help keep that destination clear.

A good project instruction file can tell the coding agent how important systems should behave, what should stay consistent, what should not be changed, and what is intentionally outside the scope of the project.

The goal is not to create thousands of rules. Too many rules can create their own conflicts.

The goal is clarity.

Fix the Problem, Not Half the Project

Coding agents can change huge amounts of code very quickly.

That does not mean they should.

If one button is broken, the entire navigation system probably does not need to be rebuilt.

A useful instruction can be:

Find the root cause and make the smallest reasonable fix. Do not rewrite unrelated systems unless there is a real reason.

Sometimes the investigation really will reveal an architectural problem. But if the problem is small, the fix can usually stay small too.

A Fix Can Cause Another Bug

Fixing one problem can also break something that used to work.

That is called a regression.

You fix the mobile menu and suddenly the desktop menu breaks. The first bug is gone, but the software is not really fixed.

This is where testing comes in. A coding agent can rerun the behavior that originally failed, check related features, or run an automated test.

The basic distinction is enough:

Debugging finds and fixes the problem. Testing checks that the fix really worked.

Modern Debugging Requires Software Literacy

If you no longer need to manually trace every function yourself, what should you actually learn?

We think one of the most important skills is software literacy: understanding what the different parts of software are so you can recognize where a problem appears and communicate it accurately.

You do not necessarily need to know how to build every component manually.

But you should know what you are looking at.

Learn the Parts of a Web Page

Take a website.

You should be able to identify a heading, paragraph, button, navigation menu, header, footer, image, form, background, and content section.

You should understand that these elements have positions and sizes. They can sit above or beneath other elements, overlap, or be pushed outside the visible screen.

On the web, you will encounter words such as CSS, margin, padding, responsive design, viewport, and z-index.

You do not need to memorize every CSS property.

But this:

The mobile navigation is overlapping the heading.

is much more useful than:

The top looks weird.

Knowing what you are looking at helps you say what is wrong.

Learn What Frontend and Backend Mean

You should also understand the basic difference between the frontend and the backend.

The frontend is generally the part the user sees and interacts with: screens, forms, buttons, menus, text and images.

The backend handles things behind the interface, such as databases, accounts, business logic, storage, APIs, and communication with other services.

A server can receive a request from the frontend, get information from a database and send it back.

If information never appears on the screen, the problem might be in the frontend, the request, the server, or the database.

You do not need to manually fix all of those layers. You just need to understand that they exist.

Learn to See an App as Parts

The same idea applies to mobile apps, desktop software, games and SaaS products.

Do not think of everything as one giant object called the app.

Look at the pieces.

There are screens, buttons, text, images, navigation, data, state, configuration, audio, animations, storage, APIs, databases and other systems depending on what you are building.

Visually, something can be above another element, underneath it, hidden behind it, clipped by it, or pushed outside the screen.

Internally, information can also live in different places. A setting might exist only while the app is running, be stored on the device, be saved in a database, or come from a server.

The more clearly you see these parts, the more clearly you can explain what is wrong.

Learn What State Is

One concept you will hear constantly is state.

State is basically what the application currently knows.

Which user is logged in? Which screen is open? Which items are in the cart? Which setting is selected? Has something been saved?

A lot of strange software behavior turns out to be a state problem.

You may not know how the state system is programmed, but you can still say:

The setting changes correctly, but after restarting the app it returns to the old value.

That is enough to give the agent somewhere to start.

Error Messages Are Still Valuable

None of this means you should ignore technical errors.

If the console shows 404 Not Found, 500 Internal Server Error, TypeError, ReferenceError, or another wall of red text, give it to the coding agent.

You may not understand the stack trace.

You do not necessarily need to.

A good beginner rule remains:

If something breaks and red text appears, show the red text to the agent.

The Agent Understands the Code. You Understand the Result.

There is an interesting division of labor emerging in AI-assisted software development.

The coding agent can read thousands of lines of code, search the repository, inspect functions and trace relationships that would take a human a long time to follow manually.

But the human understands something the agent does not automatically know:

what you actually wanted the product to be.

You know the button should save. You know the screen should not reset. You know the menu should not cover the heading. You can look at the product and know when the result does not match the idea.

The agent understands the implementation.

You understand the intention.

Modern debugging increasingly happens between those two things.

What Should a Vibe Coder Actually Learn?

We do not think AI means you should learn nothing about software.

We think the emphasis has changed.

A modern AI-assisted builder should understand the main parts of an application, basic frontend and backend concepts, servers, databases, APIs, state, interface components, positioning, console output and some basic software architecture.

You should know what a debugger is. You should know what a breakpoint does. You should broadly understand stack traces, logs, runtime errors, logic bugs and regressions.

You should learn how to reproduce a problem, narrow it down, ask what changed, provide useful error messages, and explain what happened compared with what should have happened.

But we do not believe every beginner needs to master manual breakpoint debugging or spend months tracing variables through source code before they can build useful software with a modern coding agent.

The more important practical skill is learning to see software clearly.

Debugging Has Moved Up a Level

Traditional debugging often began with the question:

Which line of code did I write wrong?

Modern debugging can begin with a different question:

What exactly is the software doing wrong, and what should it be doing instead?

From there, you might discover a normal programming bug. Or you might discover that your instruction was unclear, two ideas conflict, an edge case was never planned, the environment is different, or the agent implemented exactly what you asked for even though you later realized you asked for the wrong thing.

That is why, in our opinion, debugging in the modern era is partly technical investigation, partly design, partly architecture, partly communication, and partly planning.

A capable coding agent can search through a huge codebase much faster than we can. What it needs from us is clarity about the intended result.

So instead of saying:

Fix this.

Explain what you did, what happened, when it happened and what should have happened instead. Include the error when there is one. Explain how to reproduce the problem. Mention whether it worked before. Name the part of the interface or system if you know what it is.

Then let the coding agent investigate the implementation.

That, more than anything else, is what we think debugging is becoming in the modern era.

How We Built Our MP3 Player With AI | YCBT

2026-09-05T00:00:00Z

Here at You Can Build Tech, we practice what we preach and build real projects on a weekly basis.

One of the things we want to show is that there is a big difference between the heavily marketed AI app builders you see every day on YouTube and social media, and using AI as part of a more complete development process.

You don't necessarily need months of planning before starting a project. But spending some time figuring out what you actually want to build before handing everything over to a coding agent can make an enormous difference.

For our latest project, we decided to build a full MP3 player.

The result is actually a relatively simple app underneath. It imports music, plays it, organizes it and remembers what the user is doing. But visually we went much further, with several completely different player interfaces inspired by the dedicated MP3 players of the 2000s.

And despite eventually growing to more than 22,000 lines of code, this turned out to be one of our smoothest AI-assisted builds so far.

Here's How We Planned Our MP3 Player

We didn't start by writing a giant technical specification.

Instead, once we had decided what kind of MP3 player we wanted to make, we asked ChatGPT to take us through the product one feature at a time.

ChatGPT would suggest a feature or behavior, explain what it could add to the player, and then we would approve it, reject it or modify it before moving on to the next one.

We probably accepted somewhere around 80–90% of the suggestions.

Some were exactly what we wanted immediately. Others were good ideas that we customized further, and occasionally we decided that a suggestion simply didn't belong in the app.

This gave ChatGPT quite a lot of freedom to contribute to the product rather than using it purely as a machine waiting for us to tell it what to do.

At the same time, we retained the final say over everything that actually became part of the player.

We Went Deep Into the Small Details

The basic feature set of an MP3 player is obviously not difficult to imagine. You need playback, a music library, queues, playlists, favorites and the usual playback controls.

We went considerably deeper than that.

We discussed exactly what should appear inside menus, how queues should behave, how playlists should work, when a song should count as having been played, what statistics should be remembered, which metadata should be displayed, how the app should behave when reopened, what equalizer controls should be available and how different player interfaces could present those controls differently.

We also discussed what not to include.

For the music side of the application, we mostly concentrated on features that belonged in a real music player. We weren't interested in adding features simply because AI could build them.

Our main reference point was the era of standalone MP3 players rather than modern streaming applications. We were thinking about devices such as Apple's iPod, Microsoft's Zune, Creative players, Sony music players and the enormous variety of smaller MP3 players people used before smartphones took over.

That gave the project a very clear identity.

AI Designed Most of the Technical Architecture

Where we did not spend much time was manually deciding which software component should communicate with which other component.

Once the features and behavior had been established, AI worked out most of that for us.

It decided how the application should be divided, what should belong to the shared music system, what should belong to the individual player interfaces, what needed to reach Android or iOS directly, and how the different parts should communicate.

So it would be inaccurate to say that we designed the complete architecture and then gave it to AI to code.

The process was much closer to designing the product together with AI, approving the important decisions and then allowing AI to determine a sensible technical implementation.

For this particular project, that worked extremely well.

What Was Our Tech Stack?

The bulk of our technology stack was also decided during the planning phase.

For the main application framework, we used React Native 0.86 with React 19.

React Native was originally developed at Facebook, now Meta, and allows most of our application to exist in one shared codebase while still giving us access to native Android and iOS functionality when we need it.

We purposely stayed away from the myriad of generic UI kits and larger navigation frameworks available for React Native because we wanted as much control over the appearance of the player as possible.

That turned out to be important.

Our app doesn't have one conventional mobile interface with several themes applied to it. The individual player designs can have completely different proportions, controls, screens, menus, visualizers and ways of displaying album artwork.

Using a generic UI system everywhere would have introduced restrictions we simply didn't need.

This was another decision we discussed with ChatGPT before serious coding began.

Plan With a Chatbot, Then Move Into a Coding Agent

This project has reinforced a workflow that we have increasingly come to like.

We use a conversational AI such as ChatGPT to explore and plan the product first. Then, once we know what we want, we move into a coding agent such as Codex or Claude Code for the implementation.

The first stage gives us room to talk through ideas, reject features, compare approaches and change our minds without constantly modifying the actual codebase.

The coding agent then receives a much clearer idea of what it is supposed to build.

For us, that gives substantially more control over the finished product than simply opening a coding agent and typing something like "build me an MP3 player."

What Did We Use for Android Audio?

For Android playback and several of the player-specific audio features, we went with AndroidX Media3 and ExoPlayer.

ExoPlayer is now part of Google's Media3 framework and provides a mature native Android playback system, so there is very little reason for us to try to invent our own audio engine from scratch.

It is also open-source software under the Apache 2.0 license.

So we'll give Richard Stallman a symbolic thank-you for helping create the world in which we can build software on top of excellent free and open-source components, even though he obviously didn't write ExoPlayer himself.

For some of the more specialized audio functionality, including equalization and visualization, our application also reaches Android's native audio and media systems.

What About the iOS Version?

We haven't completed the native iOS implementation yet, but the application was planned for both Android and iPhone from the beginning.

For iOS, we plan to use Apple's AVFoundation family of frameworks for the native audio side, including AVPlayer or related components where appropriate.

One small technical distinction is that AVFoundation is mainly concerned with media. Importing and accessing files will use Apple's appropriate document and file APIs rather than pretending AVPlayer itself is a file-management system.

We also plan to use Core Motion for some of our more unusual player designs.

Core Motion exposes data from hardware such as the iPhone's accelerometer and gyroscope. That means we can potentially have certain interfaces visually respond when the user tilts or moves the phone.

Unlike Media3, Apple's frameworks aren't free software in the Richard Stallman sense. They are proprietary Apple platform frameworks, although there isn't a separate AVFoundation license fee that you pay every time you use them in an iOS application.

Why Did We Use TypeScript?

The shared React Native portion of the application is primarily written in TypeScript.

TypeScript is Microsoft's typed extension of JavaScript. In simple terms, it allows the code to describe more clearly what kind of information different functions and components expect.

We think that works particularly well with coding agents.

When different parts of an application have explicit types and relatively simple interfaces, there is less ambiguity about what the agent is supposed to pass between them. This is one reason we think strongly typed languages and clearly defined interfaces are becoming increasingly interesting in the AI coding era.

Programming Languages That Are Growing in the AI Era

How Does TypeScript Reach Android and iOS?

For communication between our TypeScript code and native Android or iOS implementations, we use React Native Turbo Native Modules and Codegen.

This is the modern React Native approach for building typed interfaces between the shared application and native platform code.

We define what the React Native side needs from the native implementation, and Codegen generates much of the repetitive plumbing needed to connect those interfaces.

On Android, the platform-specific implementation can then be written in Kotlin and talk directly to Android.

The equivalent iOS implementation can reach Apple's native frameworks.

So yes, this native layer is essentially the part that allows the shared React Native application to reach down into the operating system when JavaScript or TypeScript alone isn't the right tool for the job.

Metro, Babel and Hermes

As you would normally expect with React Native, the project also uses Metro, Babel and Hermes.

Metro is the bundler used by React Native. Babel handles JavaScript transformations where required, while Hermes is the JavaScript engine that runs the React Native JavaScript code on the device.

These technologies aren't really part of the personality of our MP3 player, and the user will hopefully never have any reason to know they exist.

But they are part of the machinery underneath the application.

Testing and Code Quality

For testing and code quality, we used Jest, React Test Renderer, ESLint, Prettier and the TypeScript compiler.

Interestingly, this area also gave us one of the few genuine workflow problems we encountered during the project.

We started noticing that Codex was sometimes consuming a surprisingly large number of tokens on relatively small fixes.

Eventually we discovered one of the reasons.

During one fairly minor change to the player user interface, Prettier ended up reformatting around 2,400 lines of code.

The application had not suddenly become 2,400 lines better. Most of the changes were simply formatting.

This becomes particularly wasteful when a coding agent is involved because unnecessary code changes create larger diffs, require the agent to process more code and ultimately consume more tokens.

We don't regularly sit down and manually admire the formatting of thousands of lines of AI-generated TypeScript anyway, so there was very little benefit to doing this.

We Eventually Gave Codex Its Own Rules

After noticing this behavior, we created a small Markdown (.md) instruction file telling Codex not to rewrite working code simply because another version might look prettier.

The idea was not to prevent Codex from making architectural changes.

That would be counterproductive.

Instead, we told it that when a small direct change can solve a problem, it should prefer that approach rather than performing a large unrelated rewrite.

If something genuinely needs restructuring, the agent can still do it.

We just don't want 2,400 lines changing because a formatting tool has strong opinions about whitespace.

How Is the App Structured?

At a high level, the application ended up divided into three major areas: the shared music system, the different player frontends and a relatively thin native platform layer.

That separation is one of the reasons we can create so many different-looking players without rebuilding the actual music functionality each time.

The Music Engine

The music engine owns the important state and functionality of the player.

That includes playback, the current song, queues, the music library, playlists, favorites, listening statistics, equalizer settings, search and other music-related behavior.

It also handles persistence, which simply means saving important information so it is still there after the application is closed and reopened.

For example, the app can remember which song you were listening to, your queue, your playback position, playlists, favorites, equalizer settings and other information that would be annoying to lose every time you closed the application.

The equalizer can also appear differently depending on the player interface.

One interface might expose simple controls such as Bass, Mid and Treble, while another can expose presets such as Rock, Pop, Jazz, Classical or Electronic.

They can look completely different while still controlling the same underlying audio system.

The Player Frontends

The second major part of the application is the collection of player frontends.

This is where most of the visual personality lives.

We can have as many player interfaces as we want, including designs inspired by both small and large standalone MP3 players from the 2000s.

Each can have its own screen arrangement, physical proportions, controls, menus, artwork presentation and visualizers.

The important part is that these are not completely separate music applications.

They sit on top of the same shared music system.

If a song is already playing and the user changes from one player to another, the new frontend picks up the same state. The queue remains intact, the current track remains intact and the playback position remains intact.

Only the presentation changes.

This turned out to be one of the most useful architectural decisions AI made for the project because it means we can continue creating radically different player interfaces without duplicating the music engine.

The Native Platform Layer

The third part consists of relatively thin native adapters that handle work requiring closer access to Android or iOS.

This includes things such as playing local files, importing music, accessing platform storage, responding to device motion, processing equalizer behavior, generating visualizer data and integrating with operating-system media functionality.

On Android, this is where our Kotlin code enters the picture.

On iOS, the equivalent functionality will use Apple's native APIs.

Most of the application therefore remains inside our shared TypeScript codebase, while the platform-specific layer deals with the jobs where Android and iOS genuinely need to be treated differently.

How Much Code Did the MP3 Player Take?

By the time we took the screenshots for this article, the repository had grown to around 22,159 lines of code across 165 files.

That might sound surprisingly large for something we have described as a relatively simple application, but the interesting part is where those lines actually went.

The project is overwhelmingly written in TypeScript and TSX, which together represent more than 90% of the codebase. Kotlin currently accounts for around 7%, while there is almost no Swift yet because the native iOS implementation has not been completed.

Overall repository breakdown for the MP3 player.

The shared React Native application itself currently contains around 15,476 lines of TypeScript and TSX.

Most of the Shared Code Is Actually the Player Designs

The most interesting number in our code breakdown is probably the frontend.

Our frontends section currently contains around 9,481 lines of code, while the actual music engine and music-related features contain around 3,415 lines.

Shared React Native application code breakdown.

In other words, roughly 61% of our shared application code currently lives in the player frontend area.

That describes this project extremely well.

Playing an MP3 file isn't particularly exotic technology. Modern operating systems already give developers extremely capable media frameworks.

What took considerably more work was making the application feel like a collection of actual music players rather than a generic mobile screen containing Play, Pause and Skip buttons.

Every player can have its own layout, screen proportions, controls, menu behavior, visualizer presentation and album artwork treatment. Once you start building genuinely different interfaces rather than simply recoloring the same screen, the amount of frontend code naturally grows very quickly.

A large part of this application's code exists because we wanted the product to look and feel far more elaborate than its basic purpose really is.

One Music System Underneath All of Them

Even though the player frontend code is large, the individual player designs don't each contain their own separate playback systems.

They all operate on top of the same shared music state.

This means adding another visual player doesn't mean rebuilding playlists, favorites, queues, playback or the music library again.

A new frontend is essentially another way of displaying and controlling the music system that already exists.

That separation gives us considerable freedom on the visual side without making the underlying application unnecessarily complicated.

How Much Native Android Code Did We Need?

At the time of writing, the Android playback area contained around 1,586 lines of custom Kotlin.

We also had only around 82 lines of TurboModule specifications defining parts of the communication between the shared TypeScript application and the native platform layer.

Native Android and TurboModule code breakdown.

These numbers are another good illustration of why we chose React Native.

We don't need to write the entire application again in Kotlin for Android.

Most of the application can remain shared, while the relatively small native layer handles the jobs where direct Android access genuinely makes sense.

When we complete the iOS side, Swift and Apple's frameworks will naturally become a larger part of the repository as well.

More Than 22,000 Lines Doesn't Mean We Typed 22,000 Lines

There is another fairly obvious point worth making in an article about AI-assisted development.

We did not manually type 22,159 lines of code.

That is precisely what makes this type of development interesting.

The coding agent handled the overwhelming majority of the implementation. Our time was much more heavily concentrated on deciding what the product should do, testing what had been built, identifying things we didn't like and refining the result.

And despite eventually reaching more than 22,000 lines, the actual coding phase was almost bump-free.

We Never Encountered a Major Bug

Throughout this project, we never encountered what we would describe as a major bug.

That doesn't mean everything was perfect on the first attempt.

One example was a song failing to continue correctly after switching from one player interface to another. That needed to be fixed.

But problems at roughly that level were about as dramatic as the project became.

Much more commonly, the things we asked Codex to change were visual.

A control needed moving slightly. Spacing didn't look quite right. A visualizer needed adjusting. One player screen needed different proportions. An element needed to sit a little higher or lower.

Most of the development time was therefore not spent rescuing broken software. It was spent polishing software that was already working.

For an application of this size, that made the entire project feel surprisingly straightforward.

The Code Count Is Slightly Misleading

Looking at more than 22,000 lines of code can make the project sound much more technically complicated than it really is.

At its core, the application has a fairly simple purpose.

It imports music, organizes it, plays it properly and remembers the user's state.

The reason the codebase grew substantially larger is that we put so much effort into the different ways that simple functionality can be presented.

The core music engine is relatively modest compared with the amount of code devoted to the player interfaces.

That was intentional.

We weren't trying to make an MP3 player technically complicated just for the sake of it. We wanted to take something fundamentally simple and make it feel unusually polished, fun and complete.

The final result looks far more elaborate than the underlying concept really is, and when you use it, it behaves exactly the way a real MP3 player should.

How Is the Finished App Configured?

The appearance and available options of a finished version of the app can largely be described using a versioned JSON configuration bundle.

The important distinction is that the JSON file is not generating the entire application from nothing.

The player frontends, music engine and underlying capabilities already exist.

The configuration determines things such as which frontends are available, which colorways they use, which assets belong to them and which optional features should be enabled.

The application validates this configuration before using it so that broken or incomplete combinations can be caught rather than blindly loaded.

Because the presentation and music state are separated, switching player designs doesn't destroy what the user was doing. The current track, queue and playback position can remain intact while the interface around them changes.

This gives us a remarkably flexible application without needing to create separate versions of the music engine for every visual design.

What Did We Learn From Building It?

One of the clearest lessons from this project was how effective feature-by-feature planning with AI can be.

We didn't walk into the project knowing every feature we wanted.

Instead, we allowed ChatGPT to contribute ideas.

It suggested something, we considered it and then we approved, rejected or refined it before moving on.

By the end of that process, we had effectively produced a very detailed product specification through conversation without sitting down and manually writing one from scratch.

AI then translated those decisions into the technical architecture and the coding agent implemented it.

For this project, the process worked exceptionally well.

The app itself isn't conceptually complicated, and that probably helped. But we also believe the amount of planning we did before serious implementation contributed to how few technical problems we encountered later.

We spent a lot of time deciding what we wanted before asking a coding agent to build it.

Once development began, most of our effort could therefore go into refinement rather than repeatedly changing the fundamental product underneath it.

That distinction is increasingly important to how we think about AI development at You Can Build Tech.

There is a big difference between simply asking AI to build you an app and actually building an app with AI.

The amount of manual coding required has changed dramatically.

The importance of deciding what is worth building has not.

How Much Money Can You Make With Google AdMob? | YCBT

2026-09-02T00:00:00Z

How Much Money Can You Make With Google AdMob?

By YouCanBuildTech Published September 2, 2026

What Is Google AdMob?

AdMob is an ad service created by Google that enables you to run advertisements in your mobile game or app. It's easy to set up an account, but it requires some coding to get it working inside your app.

This article is meant to give you a solid understanding of what AdMob is, how it works, and the kind of money you can expect to earn using it.

Let's get started.

A Short History of AdMob

AdMob is a mash-up of the words "advertising on mobile." It's been owned by Google since 2010, and it makes it easy to earn money with your app by showing in-app ads.

Google AdMob

How Does Google AdMob Work?

You make money with AdMob by integrating ads into your mobile app, and you get paid when users view or interact with those ads.

It's simple to set up and only requires you to sign up on the Google AdMob platform using your Google account. After that, you integrate the Google AdMob Software Development Kit, or SDK, into your mobile app's codebase.

How Much Does AdMob Pay You?

This is a tricky question that no one can give a definitive answer to. Not even AdMob gives us one fixed number because it uses a variety of factors to calculate your payouts.

These include the type of ad, such as full-screen ads, banner ads, or video ads, and the geographical location of the views.

Ad views from a wealthy country can pay significantly more than views from less-developed countries.

But What Are the Actual Numbers?

Like we said, there is no fixed number, but for a simple example we can use an estimated $6 USD per 1,000 ad views.

This essentially means that if your app gets some moderate traction and gains 10,000 users who use your app once per day, that could equal 300,000 or more ad views per month.

Divide those views by 1,000:

300,000 / 1,000 = 300

Then multiply that by $6 USD:

300 × $6 = $1,800 USD

That gives you an estimated payout of $1,800 USD per month.

AdMob Payout Estimates for Your App

Basically:

10,000 users: around $1,800 per month
1,000 users: around $180 per month
100 users: around $18 per month

This number could potentially be 2–5 times higher if users spend a while inside your app and see multiple ads during each session. However, it could also be lower if they don't use your app every day.

So at the end of the day, this is just a very speculative estimation.

What Do Real App Developers Report?

Real-world reports from app developers show just how much AdMob earnings can vary.

One developer reported usually seeing around $15–$25 eCPM for interstitial ads in the US. Reddit discussion

Another developer with users mainly in Egypt and the Middle East reported around $0.70–$1.20 eCPM for interstitial ads, with rewarded ads earning around $1.50–$2.50 eCPM. Reddit discussion

There are also examples showing how much the size and location of your audience matter. One developer with around 2,000 active users, 42% of them from the US, reported earning around $200–$250 per month from one game. Reddit discussion

These are individual developer reports and not official AdMob payout figures, but they demonstrate why there is no single answer to how much AdMob pays.

Your users, their location, the type of ads you show, and how often they use your app can make an enormous difference.

Which Programming Languages Are Growing Fastest in the AI Era? | YCBT

2026-08-30T00:00:00Z

Studies & Statistics

Which Programming Languages Are Growing Fastest in the AI Era?

By YouCanBuildTech Published August 30, 2026

Although much of the reason for these languages being the fastest-growing is due to their corporate utility in the AI era, it doesn't mean that they are irrelevant to vibe coders. Neither does it mean that vibe coders should use these languages simply because they are being used heavily in the corporate world due to agentic coding becoming the new standard.

What's useful to take away from this article is the types of applications they are being used in and why they are so effective with AI / agentic coding practices.

1. TypeScript — 66.6% YoY Growth

TypeScript is the typed version of the legendary web language called JavaScript, which was invented for easy-to-do browser coding.

And now, in the age of AI, it's become quite clear that coding agents work better when they use a strongly typed language, which means less ambiguity about the type of data used in the program.

So since TypeScript adds static typing and JavaScript is a dynamically typed language, companies are now finding out that they can take on much larger rewrites and migrations of websites and web apps in TypeScript using AI.

This is likely one of the main reasons we see TypeScript beating out both Python and JavaScript in GitHub's latest YoY programming language data.

TypeScript grew 66.63% year over year in monthly contributors and overtook both Python and JavaScript to become the most-used language on GitHub by contributor count in August 2025.

Source: GitHub Octoverse 2025

2. Rust — More Than Doubled Since 2022

High-performance software has always needed languages that were low on abstraction and closer to the CPU and hardware, and historically those languages were C and its younger brother C++.

But in 2015, a new language named Rust was released that was intended to compete with C and C++ on raw speed while introducing new code-safety features that prevent your code from exploding and sinking the entire ship.

However, it wasn't so easy to use since it required very structured programs and lots of jumping through hoops.

Yet Rust saw slow but steady growth for years, but it's not until lately that developers and companies are realizing that Rust may just be the perfect language for coding high-performance software with a coding agent.

One particularly interesting reason is that Rust's strict compiler can give the coding agent very specific feedback when something is wrong, allowing the agent to fix the problem and try again.

Rust is now described by SlashData as the fastest-growing major programming language community, with its developer community more than doubling in size since 2022.

Source: SlashData — Global Developer Population Trends 2025

3. Python — 50.7% YoY Growth in AI Repositories

Python was always a very people-friendly language and beloved by both serious scientists & academics and beginner coders alike due to its uncomplicated readability and writability, and the high-level abstraction that makes it easy to accomplish tasks in a shorter and less complicated way.

In fact, Python has always been strongly associated with AI, but since the dawn of mainstream AI / LLMs, we are seeing a massive spike in Python use.

Python sits right at the center of the modern AI ecosystem and also acts as the glue for human-written code that connects these heavy LLMs to the everyday practical applications that we use in business, medicine, science and education.

GitHub found that Python-powered AI repositories grew 50.7% year over year, while Python itself grew 48.78% in monthly contributors.

Source: GitHub Octoverse 2025

4. Go (Golang) — One of the Fastest-Growing Modern Languages

Go is a modern programming language that was invented at Google to handle large software systems, networking, concurrency and infrastructure across major industries, and thus it is quickly becoming a go-to language (pun not intended) for the very infrastructure that powers the AI era.

It is built from the ground up to be simple, straightforward and lightweight, which are features that all contribute to it being a great language to use with agentic coding on backend services of any scale.

Its deliberately simple syntax and strict tooling also give coding agents fewer complicated ways to arrive at the same solution.

Go developers are already heavily adopting AI development tools. In the official 2025 Go Developer Survey, 53% said they used AI-powered development tools daily, while another 40% said they were at least occasionally trying agentic modes of working.

Go itself also continues to gain developer adoption. JetBrains' 2025 research found that Go has steadily gained market share over the past five years, with more developers saying they planned to adopt Go next than any other programming language.

Don't be surprised if we continue to see more growth with this particular language in the coming years.

Sources: JetBrains State of Developer Ecosystem 2025 and the 2025 Go Developer Survey

Small Developers Already Dominated the App Store. Now They Have AI

2026-08-28T00:00:00Z

Studies & Statistics

Small Developers Already Dominated the App Store. Now They Have AI

By YouCanBuildTech Published August 28, 2026

AI Changed the Speed of Development

Since the dawn of the LLM era, we have seen a steady increase in software productivity. With the initial tentative and apprehensive approach seen in the early days, we now (August 2026) see broad acceptance that AI can write code at a speed no human developer could ever hope to match manually, while producing increasingly high-quality results.

Here at You Can Build Tech, we started leveraging AI assistance much earlier than the industry average when we experimented with the "copy-and-paste" method by simply chatting with the "regular" ChatGPT. We found that by the summer of 2024, it was highly capable of rapidly increasing the speed of development. By May 2025, OpenAI released Codex, its autonomous agentic coding service, and it was blatantly clear that the entire game had changed.

And this leads us to the topic of this article, which is the rapid increase of software products being released into the market. Here at You Can Build Tech, we focus heavily on what the solo developer or small team can accomplish in this new world of agentic coding.

Small Developers Were Already Everywhere

In fact, small developers already made up the overwhelming majority of App Store developers before the agentic coding era. A May 2023 study done by Apple / Analysis Group found that more than 90% of App Store developers fit Apple's definition of a "small developer."

Big Tech Never Owned App Development

This blows to pieces the idea that software development or the App Store is solely the territory of "Big Tech" companies, and shows that computers are, and always were, an open frontier that empowers the people far beyond what was possible before.

Then Coding Got 55% Faster

Another early statistic comes from the famous code-hosting platform GitHub's 2022 research on developer productivity and happiness.

The findings included that developers using GitHub Copilot completed a coding task 55% faster than developers who completed the same task without Copilot. This meant that a coding task that took the non-Copilot group an average of 2 hours and 41 minutes took the Copilot group only 1 hour and 11 minutes to complete.

And That Was Only the Beginning

Of course, this was only the beginning of the AI coding era, and we've seen enormous progress in just these last four years. But it points to the almost astronomical effect AI is having on coding productivity that we are currently experiencing.

More Power in the Hands of Developers

So it's undoubtedly an exciting time in the software industry and for developers, and You Can Build Tech is thrilled to be a part of it. We are proud that we are able to help educate individuals on how to harness this incredible power and use it to build software that can change people's lives for the better.

See what current research suggests about the programming languages growing fastest in the AI era.

App Builder or Coding Agent? The Real Difference | YCBT

2026-08-25T00:00:00Z

Choosing your building environment

App Builder or Coding Agent? The Real Difference

Choose the app builder when you want the shortest road to a working app. Choose the coding agent when you care more about how far that road can eventually go.

By YouCanBuildTech Published August 25, 2026

You have an app idea.

Now you have two very different ways to build it with AI.

You can open an AI app builder, describe what you want, and have the app appear inside a ready-made environment.

Or you can use a coding agent and let AI work directly on a real software project.

Both can work.

Both can make surprisingly good apps.

But they give you very different amounts of freedom.

And that difference usually becomes more obvious the further you get into the project.

The short version

If you want to get something working quickly without thinking much about programming tools, an app builder is usually easier.

If you want more control over what the app can become, a coding agent usually gives you more room.

Think of it this way:

An app builder gives you a prepared workshop.

Most of the tools are already there. The benches are set up. You can start making something almost immediately.

A coding agent gives you access to the entire hardware store.

You have more choices, but somebody still has to decide what to buy and how everything should fit together.

That somebody is increasingly the AI.

But you still have to tell it what you are trying to build.

What an AI app builder actually does

AI app builders try to remove as much setup as possible.

Instead of installing programming languages, frameworks and development tools, you normally open a website and type something like:

Build me an app where dog walkers can create profiles and customers can book them.

The builder starts making it.

You can then say:

Make the homepage cleaner.

Add user accounts.

Let customers leave reviews.

Add Stripe payments.

And the project grows from there.

This is why app builders are so attractive.

You can go from an idea to something you can actually click around in very quickly.

Popular options include:

App builder	Rough starting price	Mostly aimed at
Lovable	Free / around $25 per month for Pro	Websites and web apps
Bolt	Free / around $25 per month for Pro	Web apps and some mobile development
Replit Agent	Free / paid plans from around $20–25 per month	General software projects
v0	Free / around $30 per month for Plus	React and Next.js web apps
FlutterFlow	Free / around $39 per month for Basic	Mobile and web apps using Flutter

Prices change, and most of these services also have usage limits or credits.

That matters.

A “$25 per month” AI builder does not necessarily mean you can spend all month endlessly generating and rebuilding a huge app.

Where app builders are really good

For a lot of normal apps, an app builder makes perfect sense.

Imagine you want:

user accounts
a dashboard
a booking system
a simple marketplace
a subscription app
forms
profiles
a basic database
an admin area

These are common problems.

App builders have already been designed around them.

So instead of spending your first hour installing things, the builder can spend that hour actually building your app.

For a beginner, that is a massive advantage.

You also don’t have to understand every technical decision being made underneath the app.

The builder may choose the database.

It may choose the hosting.

It may choose the framework.

It may handle deployment.

That lets you concentrate more on the app itself.

But there is a trade-off.

The builder is also choosing part of your future

This is the part that is easy to miss when everything is working nicely.

An app builder does not simply make programming easier.

It also gives you a particular path through programming.

Lovable is heavily focused on web apps.

v0 strongly favors the React and Next.js world.

FlutterFlow is built around Flutter.

Bolt has its own supported technologies and workflows.

None of that is necessarily bad.

In fact, those restrictions are part of why the builders are easy to use.

The problem comes when your idea starts wandering outside the path the builder prepared for you.

Here’s where the magic can start wearing off

Imagine your app is mostly finished.

Then you decide you want something unusual.

Maybe you want:

strange custom animations
an uncommon payment service
complicated offline behavior
Bluetooth hardware support
a very unusual navigation system
advanced audio features
a custom drawing interface
a niche business API
complicated background processing
a game-like interface

Now the question becomes:

Does the builder support this nicely?

If the answer is yes, great.

If the answer is no, something that sounded easy can suddenly become awkward.

You may have to export the code.

You may have to edit parts manually.

You may need another service.

Or you may discover that the platform simply wasn’t designed around what you are trying to do.

That is probably the biggest difference between an app builder and a coding agent.

An app builder removes decisions.

A coding agent gives you more decisions.

Does an app builder own your code?

This question gets oversimplified a lot.

Several major app builders now let you export or sync your code.

Lovable can sync projects with GitHub.

Bolt says the code you create is yours.

v0 works with GitHub.

FlutterFlow lets paid users download generated Flutter code.

That is good.

But owning the code does not necessarily mean you can press one button, leave the platform forever and take absolutely everything with you.

Your app may also depend on:

a database
uploaded files
passwords and secret API keys
authentication
hosting
scheduled jobs
domains
payment accounts
analytics
email services

So the useful question isn’t just:

Can I download my code?

Ask:

Could I realistically run this app somewhere else?

That is a much better ownership test.

If portability matters to you, connecting the project to GitHub early is usually a smart move.

And no, the builder doesn’t do absolutely everything

Another beginner trap is thinking:

The AI built my app. So now I publish it.

Sometimes.

But often there is still some boring real-world work waiting for you.

A mobile app may still need:

an Apple Developer account
a Google Play Developer account
screenshots
app-store descriptions
icons
privacy information
certificates
testing
AdMob setup
payment accounts
app-store review

A web app may still need:

a domain
hosting
email
analytics
backups
payment setup
privacy pages

AI has made building software much easier.

It has not made all the other companies involved disappear.

Will app-builder apps all start looking the same?

This is a more interesting problem.

And the answer is:

They can.

Ask an AI:

Make me a modern fitness app.

There is a good chance you will get:

rounded cards
a progress chart
some large numbers
a dashboard
a few gradient colors
a settings screen
the usual fitness features

Ask for a productivity app and you may get:

tasks
streaks
statistics
goals
a profile
dark mode

None of these things are bad.

The problem is that AI knows the common answer.

So if you give it a common question, you often get a common app.

An app builder can make this problem slightly stronger because the AI is already working inside a smaller set of technologies and interface systems.

You can absolutely make a distinctive app inside an app builder.

But you normally have to push it there.

What about original graphics, sounds and animations?

This is another area where the difference becomes noticeable.

An app builder may let you use:

your own images
custom fonts
generated graphics
animations
custom CSS
audio files

For many apps, that is more than enough.

But a coding agent can potentially reach much further.

It can use thousands of existing programming libraries and tools.

Want advanced animation?

There’s probably a library for it.

Want 3D graphics?

There are engines for that.

Want interactive audio?

There are libraries for that too.

Want to build an interface that looks nothing like a normal website?

Possible.

The important word here is possible.

A coding agent does not magically become a great product designer just because it has access to more tools.

If you tell it:

Make this look cool.

You can still get generic AI design.

You need to give it direction.

The coding agent simply has fewer walls around what it can build once you do.

So what is a coding agent?

A coding agent works much closer to the actual software project.

Instead of giving you one prepared app-building environment, it can create files, edit code, install packages, run tests, inspect errors and work with normal development tools.

Some popular coding agents in 2026 include:

Coding agent	Rough individual price
OpenAI Codex	Available through ChatGPT plans
Claude Code	Around $20 per month for Pro, higher plans available
Cursor	Free / around $20 per month for Pro
GitHub Copilot	Free / around $10 per month for Pro
Gemini CLI	Free individual usage available

The line between an app builder and a coding agent is getting blurry.

Replit, for example, sits somewhere in the middle.

But there is still a useful difference.

With a coding agent, the project is usually the main thing.

With an app builder, the platform is usually the main thing.

What do you actually have to install?

This sounds much scarier than it usually is.

You do not need to install every programming tool ever made.

You install what your project needs.

For example, a normal web app might need:

VS Code, Cursor or another editor
Git
Node.js
the coding agent

That’s basically enough to start.

If you’re making an Android app, you may eventually need Android Studio.

If you’re making an iPhone app, you will eventually need Xcode on a Mac.

If you’re making a Godot game, you install Godot.

Your coding agent can usually help you set this stuff up.

You do not need to memorize twenty terminal commands first.

Is coding with an agent harder?

At the beginning, yes.

A little.

An app builder might let you type:

Make me a booking app.

And thirty seconds later there is already something on the screen.

A coding agent may first need to create the project, install packages and start the development server.

That feels more technical.

But the difference is much smaller than it used to be.

Modern coding agents can handle a huge amount of the setup themselves.

You can literally tell one:

I want to build an iPhone and Android habit tracker. Set up a sensible project for me and explain anything I need to install.

That is a very different programming experience from learning software development ten years ago.

Does a coding agent make a better app?

Not automatically.

This is important.

Using Codex instead of Lovable does not sprinkle some kind of professional developer dust over the finished app.

A badly planned React app is still a badly planned React app.

A well-designed app made with an app builder can be much better than a poorly designed app made with a coding agent.

But coding agents generally give you a higher ceiling.

Imagine both tools can get you to level 7 fairly easily.

The difference is that one road may continue to level 8, 9 and 10 without you having to fight the platform.

That matters when the product becomes unusual.

Connecting other services

Modern apps almost always talk to other services.

Examples include:

Stripe
Supabase
Firebase
OpenAI
Google Maps
Twilio
Spotify
weather services
email providers
analytics services

App builders often make the popular ones extremely easy.

You might click a button and connect Supabase in minutes.

That’s excellent.

Coding agents become more attractive when you want something the builder doesn’t have a nice button for.

If a service has an API or programming library, a coding agent can usually work with it.

There are far fewer situations where you have to ask:

Does my builder support this?

Instead the question becomes:

Does this service provide a way for software to connect to it?

If it does, there is usually a path.

The biggest difference may actually be the UI

This is where coding agents start becoming really interesting.

An app builder usually gives you some flexibility over the interface.

But a normal software project can use an enormous number of UI libraries, animation systems and graphics tools.

For example, a web project could use:

React
Tailwind
shadcn/ui
Three.js
PixiJS
Rive
Lottie
Framer Motion

You do not need to know what all of those are.

The point is simply that your AI does.

You can say:

I want the home screen to feel more like an old MP3 player than a modern mobile app.

Or:

I want the buttons to physically move and snap into place when the user drags them.

Or:

I want this section to have animated 3D objects in the background.

Now the coding agent has a much bigger toolbox.

This is why I would lean toward a coding agent when the look or interaction itself is part of the product.

Does a coding agent automatically give you more features?

Not necessarily.

AI has favorite features.

Give it a vague request for a habit app and it may happily add:

streaks
goals
statistics
reminders
dark mode

Give another AI the same request and you may get almost exactly the same list.

That isn’t really an app-builder problem.

It’s an AI problem.

AI tends to produce the obvious answer unless you give it a reason not to.

So if you want a richer or stranger app, you have to think about what makes it different.

Maybe your habit app has no streaks at all.

Maybe it behaves like a game.

Maybe habits grow a virtual garden.

Maybe there is no traditional dashboard.

Maybe the entire interface is controlled through one screen.

Those are product decisions.

The AI can build them.

It probably won’t invent the best ones for you.

What about performance?

A coding agent does not automatically create faster software.

A simple app-builder project can be extremely fast.

A coding agent can also create a giant mess with seventeen libraries nobody needed.

The advantage is control.

With a coding agent, you can usually change more things if performance becomes a problem.

You can replace libraries.

Change how data loads.

Compress images.

Add caching.

Profile slow code.

Move work onto a server.

Use native functionality.

But unless your app actually has a performance problem, this probably shouldn’t decide which route you take.

Most beginner apps are not being held back because React rendered a button three milliseconds slower.

What should you build with if you choose a coding agent?

You do not need to spend six months researching programming languages.

Here are some sensible starting points.

Web apps

Try:

TypeScript + React + Next.js

This is one of the biggest ecosystems in modern web development.

There are libraries for almost everything.

Supabase is also a beginner-friendly option for things like databases, accounts and file storage.

iPhone and Android apps

Try:

React Native + Expo

You can build for both platforms using mostly the same project.

It also gives a coding agent an enormous amount of existing documentation and code to work with.

Games

Try:

Godot + GDScript

Do not force a normal app framework to become a game engine.

Godot already gives you graphics, physics, animation, sound, input and scene management.

AI, automation and data-heavy projects

Try:

Python

Python has a huge ecosystem for AI, automation and data work.

FastAPI is a popular way to turn Python code into a backend that other apps can communicate with.

Desktop apps

A beginner could start with:

TypeScript + Electron

It lets you build Windows and Mac applications using technologies that are very similar to web development.

Which one would I choose?

For a normal first app, I would seriously consider an app builder.

Especially if your goal is:

I have an idea and I want to see whether it works.

You can get something in front of yourself very quickly.

That matters.

You may discover that your idea isn’t very good.

Or you may discover that the small version is all you ever needed.

There is no prize for building the most technically sophisticated todo app in history.

But I would start looking at coding agents much earlier if your thought process sounds like this:

I want the app to work in a pretty unusual way.

I care a lot about how it feels.

I want strange animations or custom interactions.

I need to connect to uncommon services.

I want native phone features.

I already know this project is going to become large.

I don’t want my development environment deciding what technologies I can use.

That is where the extra freedom starts becoming valuable.

You can also start with one and move to the other

This may actually be the smartest route for a lot of people.

Start in an app builder.

Get the idea working.

Connect it to GitHub early.

Then keep using the builder for as long as it makes your life easier.

If you eventually find yourself constantly trying to work around the platform, move the project to a coding agent.

You don’t have to swear allegiance to one development philosophy.

These are tools.

Use the easiest tool until it stops being the easiest tool.

The part that matters more than either tool

AI has made software development dramatically more accessible.

But the biggest advantage still comes from knowing what you want to make.

Not knowing JavaScript.

Not memorizing React.

Not knowing fifty libraries.

Knowing things like:

what should the first screen do?
what shouldn’t the app do?
what makes it different?
what will the user actually care about?
what should feel fast?
what should feel fun?
what can be removed?
what does the app look like when it is truly finished?

An app builder can build the obvious version of your idea very quickly.

A coding agent can give you far more freedom to escape that obvious version.

But neither tool knows what your version should be until you start making those decisions.

Choose the app builder when you want the shortest road to a working app.

Choose the coding agent when you care more about how far that road can eventually go.

How to Turn an App Idea Into a Buildable First Version | YCBT

2026-08-16T00:00:00Z

Planning your first build

How to Turn an App Idea Into a Buildable First Version

Choose one person, one useful outcome or fun mechanic, and the smallest complete experience that delivers it.

By YouCanBuildTech Published August 16, 2026 Updated September 5, 2026

An app built with AI does not need to be simple, and it does not need to be advanced. It needs to satisfy a more basic premise: someone should find it useful or fun.

That person could be you, a customer, a colleague, a child, an older relative, or a particular group of people. The project might be a passion project, something you hope to sell, or a tool that helps a business save time or make money.

Your first version is the smallest version that lets you find out whether the central idea works. It is not every feature you may eventually want.

A buildable first version gives one person one complete reason to use it.

Begin with the reason to use it

Before choosing features or tools, finish one of these sentences:

For an app: This helps [a particular person] do [one useful thing].
For a game: The player repeatedly [does one action] because [the challenge or result is fun].

“An app for local businesses” is still an area, not a buildable idea. “A cleaner can open today’s jobs and mark each room complete” gives the project a person, an action, and a useful result.

“A fun puzzle game” is also too open. “The player combines matching ingredients before the board fills” identifies the action and the pressure that makes it a game.

For business apps, solve one problem with one core workflow

Focused business tools are often easier to explain, demonstrate, and sell. The first version should take someone from a recognizable problem to a useful result without trying to run their entire business.

The ideas below represent familiar needs that businesses already use software to solve. That does not guarantee customers. It gives you a grounded place to begin asking who has the problem and what the smallest useful solution would be.

Idea	A focused first version	Leave until later
Quote maker	Add a customer and a few services, then create a clear quote.	Payments, accounting integrations, and a complete customer database.
Job checklist	Open today’s job, complete its tasks, and record that it is finished.	Staff scheduling, payroll, route planning, and performance reports.
Stock counter	Record an item’s quantity and show which items are running low.	Supplier ordering, barcode hardware, and multiple warehouses.
Client intake tool	Collect the information needed before one type of appointment or job.	A general-purpose form builder and every possible client journey.
Expense or mileage log	Add an entry, see the total, and export a simple record.	Tax filing, bank connections, and financial advice.
Follow-up organizer	Record who needs a reply and mark the follow-up complete.	A complete sales and marketing platform.

Notice what makes each version small: it completes the central workflow. A quote maker that creates a usable quote is a product someone can judge. A quote maker with a login screen, settings page, and unfinished quote system is not.

For games, protect the core mechanic

A game can follow the same principle. One understandable mechanic can supply enough interest for a complete game when the feedback, challenge, and progression support it.

Wordle asks the player to guess one word with limited attempts. 2048 asks the player to slide and combine matching tiles. Crossy Road asks the player to keep moving forward while avoiding hazards. These finished games contain far more polish than those descriptions suggest, but their central actions remain easy to explain.

For a first game, define the repeatable action before characters, shops, achievements, story chapters, or multiplayer. You might sort objects before time runs out, guide one character through changing lanes, connect shapes to clear space, or defend one position against increasingly difficult waves.

If the fun cannot yet be described in one sentence, adding more features will not make the first version clearer.

Decide where the first version will be used

Your first version also needs a home. Will someone open it through a web link, or install it on a phone?

A web app or web game is often the quickest way to test an idea. Modern browsers such as Chrome, Edge, Firefox, and Safari already know how to display HTML and CSS and run JavaScript. You can share a link without asking someone to install an app or visit an app store.

The browser does not contain every development tool your project may need. An app with accounts, saved information, payments, or other online services still needs those parts to be created and hosted. The advantage is that the person using the finished version already has the environment needed to open it.

Begin with mobile when the idea depends on being installed on a phone or on phone features such as the camera, location, notifications, or sensors. Mobile also introduces more setup, device testing, store requirements, and publishing decisions. Those steps are achievable, but they should be part of the choice rather than a surprise at the end.

Visual builders such as Adalo and Thunkable can simplify some mobile projects. AI builders including Bolt and Replit Agent also support mobile workflows. For more control, a coding agent can work on a React Native project, often with Expo providing a more approachable route to Android, iOS, and web. Games have their own choices; YCBT’s game-engine comparison explains how Godot, GDevelop, Construct, and GameMaker differ.

Do not choose mobile only because it sounds more serious, and do not choose the web only because it is quicker. Choose the place where the intended person would naturally use the idea.

Turn the idea into a short build brief

You do not need a long business plan or technical specification. Write these eight decisions in plain language:

Person: Who is the first version for?
Reason: What useful result or fun experience do they want?
Core action: What is the main thing they do?
Starting point: What information, choice, or game state do they begin with?
Result: What do they see, receive, complete, or achieve?
Home: Is the first version a web app, mobile app, web game, or mobile game?
Success check: What must you be able to do before calling the first version complete?
Not now: Which tempting features are deliberately postponed?

The success check makes the idea testable. “The app is complete when a shop owner can add five products and immediately see which ones are low” is clearer than “build an inventory platform.” “The game is complete when a player can start, understand the controls, lose, and immediately try again” is clearer than “make an addictive arcade game.”

Use a few different ideas to test your thinking

A personal project might only need to help you record a daily practice and see your recent history. A business tool might help a café manager record wasted stock at the end of each day. A children’s game might ask the player to match an animal to its habitat and keep a simple score.

These ideas have different audiences and purposes, but the thought process is the same. Identify the person, protect the core experience, and postpone everything that does not need to exist for that experience to work.

Give the brief to the way you have chosen to build

If you are using an AI app builder, begin with the short brief and ask it to create only that first experience. If you are using a coding agent, you can develop the brief with a chat assistant first and then give it to an agent such as Claude Code, OpenAI Codex, or Gemini CLI. You can also plan and build with the same agent.

That planning-to-agent handoff is the workflow we used for our AI-assisted MP3 player build, where ChatGPT helped us define the features before Codex implemented the React Native app.

Tell the AI what the product should let someone do, not merely what pages it should contain. Ask it to restate the proposed first version before it starts. If the restatement adds accounts, social features, subscriptions, dashboards, or other systems you did not request, remove them unless the central experience truly depends on them.

If you have not chosen your workflow yet, compare an AI app builder with a coding agent. The right starting point depends on how much setup you want handled and how much control the project needs.

Your first version should answer one question

Can this idea give its intended person one useful or fun experience?

You may eventually build something large, advanced, and commercially successful. You do not need to prove that entire future now. Create enough of the idea to use it, judge it honestly, and learn what deserves to come next.

Platform capabilities and official documentation links checked August 16, 2026. Builder features, mobile support, and publishing requirements can change.

What Is GitHub and Why Does It Matter for AI-Built Apps? | YCBT

2026-08-12T00:00:00Z

Technical concepts

What Is GitHub and Why Does It Matter for AI-Built Apps?

GitHub gives the code and files behind your app an online home with a recorded history of changes.

By YouCanBuildTech Published August 12, 2026

When an AI app builder connects to GitHub, it can send your project to a place that exists beyond the builder itself. A coding agent can also work with a project stored there.

This gives you more ways to continue, recover, or move the project later. It does not automatically give you every part of the working app, but it is an important piece of keeping control.

A repository is the home for a software project

GitHub stores software projects in repositories. A repository usually contains the code, images, configuration, and other files needed to build the software. It can also record how those files have changed.

You do not need to think of a repository as something mysterious. It is the project's working files plus a useful history. GitHub's repository documentation describes it as a place containing a project's code, files, and revision history.

Git and GitHub are related, but they are not the same thing

Git is the system that records changes to files. GitHub hosts Git repositories online and adds tools for accessing, sharing, reviewing, and working with them.

A recorded group of changes is called a commit. You can think of a commit as a named checkpoint: it records what changed, when it changed, and who made the change. GitHub provides a fuller explanation in its guide to commits.

You do not need to learn every Git command before using GitHub. For a first AI-built project, understanding repository, commit, and clone is enough to make better decisions.

Change history makes AI experimentation easier to control

An AI tool can change several connected files in one request. That speed is useful, but a later change can also break something that worked before.

If the working versions were committed and sent to GitHub, you have checkpoints to inspect or return to. The important qualification is that GitHub can only preserve changes that actually reach the repository. Connecting GitHub once is not enough if the builder stops synchronizing later work.

GitHub is useful because it gives a fast-moving project a visible history—not because you must become a Git expert before building.

GitHub gives the code another way forward

A GitHub repository can be copied to a computer through a process called cloning. GitHub says a clone includes the repository data available at that time, including the versions of its files and folders. See GitHub's cloning documentation.

That matters when you begin in an AI app builder. If the platform sends a usable project to a repository you control, you may be able to open it elsewhere, give it to a coding agent, or continue developing it with different tools.

The word usable matters. Platforms connect to GitHub in different ways, and an exported project may still depend on services provided by the original platform. A GitHub connection creates options; it does not guarantee that moving the complete app will be effortless.

GitHub does not automatically contain your entire app

A working app can include more than code. Its database, user accounts, uploaded files, secret keys, domain, analytics, and hosting may live in other services. Those parts are not automatically moved just because the code appears on GitHub.

GitHub is therefore not proof that you own or can move the complete system. It gives you control over the project material stored in the repository. You still need to know where the app's data and online services live, who controls those accounts, and what can be exported.

What should a beginner do?

If your AI app builder supports GitHub, connect a repository you control early in the project. Then open the repository and confirm that new changes continue appearing as the app develops.

Keep the repository private unless you intentionally want to share the source code. GitHub allows repositories to be public or private; its visibility documentation explains who can access each type.

You do not need to master branches, pull requests, or advanced Git workflows yet. Start by knowing where your repository is, confirming that it receives changes, and keeping access to the account that owns it.

GitHub concepts and documentation checked August 12, 2026. AI-builder integrations and export behavior can change by platform.

Still deciding how you want to build? Compare an AI app builder with a coding agent, including the tradeoff between an easier starting point and greater control.

AI App Builder vs Coding Agent: Which Should You Use? | YCBT

2026-08-10T00:00:00Z

Choosing how to build

AI App Builder vs Coding Agent: Which Should You Use?

Choose an AI app builder when you want the easiest route from an idea to a working app. Choose a coding agent when you want more control over how the app is built and where it can go later.

By YouCanBuildTech Published August 10, 2026

The short answer

AI app builders give you one place to describe, preview, and publish an app. They handle more of the setup for you.

Coding agents work directly with the files behind an app. It can change those files, run the app, and check its work.

AI app builders are well suited to landing pages, portfolios, booking tools, directories, dashboards, simple customer portals, and first versions of online products.

Coding agents are especially useful for changing an existing project, building desktop software, creating more advanced mobile apps, or making something that needs unusual features.

Both are genuine ways to build. You do not need to become a programmer before choosing either one.

What you want to build	Best starting point	Why
Website	AI app builder	The quickest route to a polished page you can put online.
Web app	AI app builder for most first projects	Ideal for tools, dashboards, booking systems, and other apps used in a browser.
SaaS product	AI app builder for the first version; coding agent as complexity grows	A SaaS product is software people use online, often through a subscription. Start simply, then move closer to the code if the product needs more control.
Mobile app	AI app builder for a simple first version; coding agent for a more advanced app	Some builders support phone apps. A coding agent offers more freedom when app-store publishing or special phone features become important.
Desktop app	Coding agent	Software installed on Windows or Mac usually needs tools outside the normal app-builder path.

Mobile support is improving quickly. For example, Replit Agent and Bolt can create mobile projects. Always check that the builder supports the kind of app you want before committing to it.

The real difference is the environment around the AI

Both approaches create real software and can write code—the instructions that tell an app what to do. The main difference is what they provide around the AI.

An AI app builder brings the chat, working preview, stored information, user sign-ins, and publishing tools into one place. A coding agent works more directly with a software project: the files, images, settings, and instructions that make up an app.

The categories overlap, and both are becoming easier to use. Think of an app builder as giving you more help around the project, while a coding agent gives you more freedom inside it.

Choose an AI app builder when you want to reach a working result quickly

An AI app builder handles many early decisions before you ever need to think about them. You describe the idea, see it working, and improve it one request at a time.

An AI app builder is a particularly good fit when:

you have an idea but no existing app
you want to create a website or an app that runs in a browser
seeing a working version will help you decide what to build
you want one platform to handle most of the setup

Platforms such as Lovable and Bolt let you describe a product in everyday language and then work with a functioning version of it. They can bring the app, its stored information, and the tools for putting it online into one place.

This is a friendly way to begin. If the project later needs something the platform cannot provide, you can decide whether to move it or continue with a coding agent.

Choose a coding agent when control and flexibility matter more

A coding agent is a good choice when you want the AI to work directly with the project. You gain more freedom without having to write every line yourself.

It is a good fit when:

you already have an app or website
your idea has unusual requirements
you want direct access to the project’s files
you may want to move the project between different tools

Tools such as Claude Code and Gemini CLI can read files, make changes, run the app, and check their work.

You may meet unfamiliar folders, settings, or tools, but you can learn them as you go. You Can Build Tech will be making step-by-step videos showing how to set up coding agents and their working environments on your computer. You will not be expected to figure out the setup alone.

An app builder is easier at the beginning—not automatically easier forever

An AI app builder usually makes the first steps easier. A coding agent often makes it easier to take the project in a new direction later.

If you are still discovering your idea, let an app builder remove the early setup. If you already know the project needs something unusual, a coding agent may give you the freedom you need from the start.

There is no wrong choice here. You are choosing where you want the extra help.

Do you want more help getting started, or more freedom over where the project can go?

Owning the code is not the whole ownership question

Many AI app builders let you send your code to GitHub, an online place that keeps your project’s files and records how they change. This can make it easier to work on the project outside the original builder.

If GitHub is new to you, start with what GitHub is and why it matters for an AI-built app. The important distinction is that a repository can preserve your code without automatically containing your database, user accounts, hosting, or every other part of the working app.

Bolt says a project connected to GitHub can be worked on outside Bolt and published using other services. With v0, the connected GitHub copy becomes the main copy of the project. See the official Bolt GitHub documentation and v0 GitHub documentation.

Code is only one part of a working app. Its saved information, user accounts, uploaded files, web address, and online services may live elsewhere. Before choosing a builder, check what you can take with you if you leave. You do not need to fear using a platform; you simply want to know that your successful project has somewhere to go next.

YCBT’s recommendation

If this is your first AI-built product and it is a website or a fairly normal web app, begin with an AI app builder that can connect the project to GitHub.

You are likely to see a result sooner, and keeping the code on GitHub gives you more options later. Make that connection early.

Begin with a coding agent when you already have a project, want to build desktop software, or know that your idea needs more freedom.

Whichever route you choose, start with one small version you can use and check. You can always learn another tool later. The best choice is the one that helps you begin building with confidence today.

Product capabilities and official documentation checked August 10, 2026. Features, supported technologies, and plan restrictions can change.

Once you have chosen how to build, the next step is to turn your app idea into a focused first version that you can use and check.

What Is AI Coding? A Beginner's Introduction | YCBT

2026-08-03T00:00:00Z

AI coding fundamentals

What Is AI Coding?

AI coding means using artificial intelligence to help understand, create, and change software.

By YouCanBuildTech Published August 3, 2026 Updated August 10, 2026

You describe what you want in ordinary language, and an AI tool helps turn that intention into code. It may explain something, suggest a small change, create files, or work through several steps of a larger project.

The important part is that you are still building software.

The project still contains code, files, logic, data, and technical decisions. AI changes how you work with those things; it does not make the underlying system disappear.

What AI coding can help you do

AI coding can help create websites, apps, games, scripts, automations, and other software. It can also explain or change a project that already exists.

The process is usually iterative. You describe the result, inspect what the AI produces, explain what is missing or incorrect, and continue from there. A clearer goal gives the AI a clearer target, but the first result may still be incomplete.

Some AI tools suggest code while a programmer types. Others can explain an error, describe how existing code works, or produce a small piece of code that someone adds to a project.

Newer tools can inspect a complete project, make connected changes, run the software, and respond to problems they find. The human builder gives the direction and checks the result.

Do you need to know programming?

You do not need to master a programming language before beginning with AI coding. You can ask for a change without knowing the exact syntax required to create it.

Technical understanding still helps. You might understand that an app stores information in a database without knowing how to build that database yourself. That understanding helps you describe what you want, recognize misunderstandings, and make better decisions.

You can learn the concepts your project needs as you encounter them instead of studying the entire field before you begin.

What you still control

AI can implement a feature, but it does not decide whether that feature should exist. The human builder still decides what to make, who it is for, how it should behave, and whether the result is useful.

AI can also produce something that looks convincing but behaves incorrectly. You need to run the product, use it, and check whether it does what you intended. You do not have to understand every generated line to judge the result by what it actually does.

Where to begin

Start with something small, visible, and easy to check. The first goal is not to build an entire business from one prompt. It is to experience the basic relationship: you describe an intention, the AI helps implement it, and you judge the result.

Once you have made one working change, the process becomes much easier to understand. You can make the next request, learn the next concept, and continue building from there.

Coding agents work inside a software project

A coding agent can work directly with a project and its development tools. It can read and edit files, run terminal commands, test changes, and continue through multiple steps toward a stated goal. This is often called agentic coding.

For example, you might ask a coding agent to add account settings, find the cause of an error, or make an existing website work better on phones. The agent works on the codebase while you describe the outcome and try the result.

Examples of coding agents

Claude Code can read a codebase, edit files, run commands, and work across development tools.
OpenAI Codex can help understand codebases, build and test features, fix bugs, and review changes.
Gemini CLI is Google's open-source terminal agent for tasks such as fixing bugs, creating features, and improving tests.

This brings you closer to folders, dependencies, commands, and other development concepts. You do not need to understand them all before beginning; learn the concepts your project uses as it grows.

AI app builders provide a place to build

An AI app builder gives you a managed environment for creating an app or website. You describe the product, watch a working preview appear, and request changes through chat or visual controls. The platform handles more of the initial setup and may connect services such as databases, user accounts, and hosting.

This can make the first result feel immediate because the code, preview, and publishing tools are brought together. The software still has a technical structure, even when the builder keeps much of that structure out of sight. Each platform also differs in how easily you can edit, export, host, or move the project later.

Examples of AI app builders

Lovable builds full-stack web applications from natural-language instructions and provides editable code.
Bolt provides a browser-based environment for building and publishing websites, web apps, and mobile apps.
Replit Agent turns ideas into software inside Replit's hosted development and publishing environment.
v0 creates real code and full-stack applications with previews and a direct path to deployment on Vercel.

Some app builders include their own agents, code editors, and terminal tools. Their defining experience is still the integrated platform: you begin with an idea and shape the working product in one place.

In plain language: a coding agent works with a software project, while an AI app builder gives you a managed place to create one.

Product descriptions and official documentation links checked August 5, 2026.

See what early research suggests about the leverage AI gives small App Store developers.

Ready to choose a starting point? Compare an AI app builder with a coding agent and find the approach that fits your project.

Why YCBT Is Free—and What We Believe About Learning to Code | YouCanBuildTech

2026-01-01T00:00:00Z

YCBT philosophy

Why YCBT Is Free—and What We Believe About Learning to Code

Coding should be free for a simple reason: typing is free, and the ability to use a computer to its full potential shouldn’t require a half-year salary. In a world where AI tools make building more accessible than ever, we should be expanding access—not gatekeeping it behind expensive funnels.

By YouCanBuildTech Published January 2026 Updated July 29, 2026

If you own a computer, you should be able to use it fully

A computer is not just a consumption device. It’s a general-purpose machine—one of the most powerful tools humans have ever created. If you own a computer, you own the right to explore what it can do: build tools, automate tasks, create apps, and understand the systems you rely on.

Historically, that’s been the magic of computing: curiosity, tinkering, experimentation, and a culture of sharing. The web itself grew because people could learn, publish, and collaborate without asking permission.

Learning to code should be free on the web

Learning to code should be free on the web.

Not locked behind paywalls. Not hidden inside overpriced bootcamps. Not gatekept by artificial scarcity.

Programming languages are free. Compilers have been free for decades (C, C++, GCC). JavaScript runs freely in every browser. PHP thrived on free stacks like Linux, Apache, MySQL, and PHP (LAMP/WAMP).

This is not accidental. It is cultural.

A degree and a bootcamp are not the same promise

To be fair: a full computer science degree can justify tuition because it typically covers a broad, rigorous foundation—hardware, software systems, algorithms, mathematics, and the theory behind computing.

What’s harder to justify is the modern “bootcamp economy” where people are charged premium prices to learn skills that are widely available: JavaScript fundamentals, frontend basics, and standard framework patterns. The problem is not that teaching has value—it does. The problem is the mismatch between price and what’s being sold.

Core principle: learning materials and clarity should be accessible. Paid education should be for deep mentorship, structured accreditation, or high-touch support—not for basic access to understanding.

Confusion should not be a business model

A lot of modern tech education marketing is built around urgency and insecurity:

“If you don’t pay now, you’ll fall behind.”
“If you don’t join this program, you’ll never break in.”
“If you don’t follow our exact path, you’ll fail.”

This creates an environment where people are pressured into expensive commitments before they even understand what they’re committing to. It turns learning into anxiety management.

The AI era changed the work

Coding is now abundant. Tools are abundant. Knowledge is abundant. Compute is increasingly abundant.

Modern learners still need fundamentals, but the fundamentals now include system and application architecture, frameworks and ecosystems, tooling and integration, problem decomposition, and using AI effectively.

The best teachers always focused on fundamentals. Today, the fundamentals include what many now call “vibe coding”—understanding intent, structure, and outcomes, not memorizing syntax.

YouCanBuildTech has to be free

Knowing all of the above, it’s genuinely difficult for us to imagine YouCanBuildTech as anything but totally free. We’re not here to trap curiosity behind subscriptions. We’re here to make software understandable again—especially for beginners navigating the AI era.

Is it tempting to introduce special offers or premium gates? Sure. But it wouldn’t align with the learning culture many of us grew up with: open tutorials, shared knowledge, and experimentation—especially in the early 2010s era of web learning.

What YCBT does differently

Teach the fundamentals clearly (without academic overload).
Explain frameworks and tools so you understand what’s happening, not just what to click.
Teach Vibe Coding responsibly—how to use AI effectively, and where it breaks.
Keep everything open: no paywalls, no hidden tiers, no gated “knowledge.”

We aim to educate and entertain simultaneously, because learning works better when curiosity and enjoyment are involved.

The point is possibility

One of the best parts of the 2000s internet and early web culture was the feeling that you could build anything. That spark matters. And paradoxically, with AI-assisted coding (what many now call Vibe Coding) becoming widely available, those possibilities are more reachable than ever—if people have the right mental models.

At YouCanBuildTech, we want to restore the original spirit: experiment, learn, build, share—and do it without paywalls.

No paywalls. No bootcamp pressure. No nostalgia-driven lies.
And yes—we’re free. Now beat that.

Learn on the homepage Compare practical tools

Building a Tetromino-Style Mobile Game With AI | YouCanBuildTech

2026-01-01T00:00:00Z

Building a Tetromino-Style Mobile Game With AI | YouCanBuildTech

Build note · Real Build Overview

Building a Tetromino-Style Mobile Game With AI

This is not a tutorial. It is a first-hand note on the tools and decisions behind a two-week, AI-assisted mobile game build in Godot.

By YouCanBuildTech Published January 2026 Updated September 2, 2026

Real Build Mobile Games AI-Assisted Coding Godot Two-Week Build

After two weeks, our polished UI looked like this.

The project and the result

We built a tetromino-style puzzle game in which players pick up and place shapes instead of waiting for pieces to fall from the top of the screen. After two weeks, the project had a polished mobile interface and Google AdMob integrated.

We treated the result as app-store ready from the project side. That describes the state of the build; it is not a claim about store acceptance, downloads, revenue, or user feedback.

Why we used Godot

We had already chosen the Godot game engine. Three things mattered during this project:

The editor felt light, quick to start, and responsive on our machine.
Godot is free and open source under the MIT license, which fits YCBT’s preference for tools that do not place a royalty on the finished game.
GDScript was readable enough for a beginner-facing project and practical for rapid iteration.

How AI actually helped

We used Claude, ChatGPT, Grok, and some Copilot during the build. The useful pattern was not loyalty to one model. When one conversation got stuck, handing the problem to another system sometimes produced a different route through it.

For the record: AI assisted with scaffolding, iteration, and debugging—not with core game design decisions.

That distinction matters. The owner still chose the game, decided how it should feel, evaluated the output, and decided what belonged in the build.

Visuals and voice

AI tools also helped create the block sprites and interface graphics, including the score, high-score, and settings icons. We used ElevenLabs text-to-speech to generate phrases for the character that gives audible feedback.

Debugging was still part of the job

Viewing the game in our game engine debugger.

AI-generated code did not remove the need to inspect the running game, understand state, and debug the result. The project still depended on human decisions about:

Where AI helped—and where it got in the way
How game state and variables were structured
Whether a suggested change matched the intended game behavior

What this build demonstrated

Two weeks was enough to move from an idea to a polished, monetization-integrated mobile build. The evidence is the working interface, the Godot project in the debugger, and the completed integration work—not a claim that AI finished the project by itself.

The durable lesson is simple: AI can accelerate a small build when the builder keeps ownership of the decisions, changes models when a line of attack stalls, and verifies the project in the actual engine.

Compare game engines

Game Engines for Solo Developers: A Finish-First Comparison | YCBT

2025-10-01T00:00:00Z

Finish-first engine choice

Game engines for solo developers

The best engine is the one whose complexity matches your game, your way of thinking, and the platforms you can realistically support.

By YouCanBuildTech Published October 2025 Updated July 29, 2026

Engine	Best fit	Logic model	Control and export
Godot	Builders who want a full 2D/3D engine and are willing to learn engine concepts.	GDScript, C#, and extension options.	MIT-licensed and open source; official export paths include desktop, Android, iOS, and web.
GDevelop	Fast 2D/3D prototypes and small releases without starting in code.	No-code event system, behaviors, plus JavaScript extension.	Open-source engine; official one-click paths cover web, mobile, and desktop, with plan/tooling details varying by target.
Construct	Browser-first 2D work and creators who think clearly in event sheets.	Event sheets, with JavaScript and TypeScript available.	Exports to web, mobile wrappers, and desktop wrappers; project copies can be downloaded.
GameMaker	Focused 2D games where a mature purpose-built workflow matters.	GML Visual or GML Code.	One project can target multiple platforms; available targets and commercial terms should be confirmed for your release.

If ownership and a conventional project matter: Godot

Godot is the strongest default here for builders who want an open-source engine, local project files, and room to grow from a small 2D game into more custom systems. The tradeoff is that you are learning an engine, not merely arranging behaviors.

If visual events help you move: GDevelop or Construct

GDevelop’s no-code event system, built-in behaviors, and open-source base make it a fast route to a playable result. Construct’s event sheets are also a powerful alternative to traditional programming, and its browser-based editor makes the start unusually frictionless. Try the same mechanic in both; the event model that stays readable after the prototype is the better fit.

If the project is resolutely 2D: GameMaker

GameMaker is designed primarily for 2D work and offers both visual actions and its own scripting language. That focus can be an advantage when a solo developer does not need a general-purpose 3D engine.

A practical one-evening test

Build player movement, one enemy, one score state, one restart flow, and one export.
Close the project, reopen it, and change the rules without a tutorial.
Inspect what you can back up locally and what the target platform requires.
Choose the tool that leaves enough energy for art, sound, polish, store work, and finishing.

For a concrete example of that finish-first process, read the YCBT build note: Building a tetromino-style mobile game with AI.

Current product facts checked July 29, 2026 against Godot’s introduction, Godot’s licensing FAQ, Godot’s export guide, GDevelop’s official feature reference, Construct’s event documentation, Construct’s publishing documentation, and GameMaker’s official introduction.

Framer vs Webflow: Speed, CMS, and Site Ownership | YCBT

2025-04-01T00:00:00Z

Website builders

Framer vs Webflow

Choose Framer for fast, design-led publishing. Choose Webflow when structured content, CSS-like control, and an export path matter more.

By YouCanBuildTech Published April 2025 Updated July 29, 2026

Decision	Framer	Webflow
Strongest fit	Landing pages, portfolios, and highly visual marketing sites built quickly.	Structured marketing sites and content-driven sites that need a deeper CMS model.
Publishing	Publishes directly to a Framer domain, with custom domains supported.	Publishes through Webflow hosting, with staging and production workflows depending on setup.
Custom code	Supports scripts, custom CSS, JavaScript, and structured data additions.	Supports embeds and custom code, including on CMS collection pages.
HTML export	Framer’s official FAQ says HTML export/self-hosting is not supported.	Paid Workspace plans can export HTML, CSS, JavaScript, and assets, but CMS and several hosted features do not come with the export.

Framer: design speed with hosted convenience

Framer is strongest when the work is primarily visual and the fastest route from design to a live marketing page is the priority. Custom code can extend a site, but the publishing model remains tied to Framer’s infrastructure.

Webflow: more structure, more web concepts

Webflow’s model maps more visibly to classes, layout systems, structured CMS collections, and dynamic pages. That brings more control and more concepts to manage. Its code export is a real differentiator, but it is not a full export of Webflow’s hosted CMS, ecommerce, accounts, search, or form processing.

The ownership question

If self-hosting exported static code is a requirement, Webflow is the viable option of these two—provided the project does not rely on features excluded from export. If hosted convenience is acceptable and speed matters most, Framer’s lack of HTML export may not be a practical problem.

Current product facts checked July 29, 2026 against Framer’s publishing guide, Framer’s custom-code guide, Framer’s official FAQ, Webflow’s code-export guide, and Webflow’s CMS guide.

Adalo vs Thunkable: Which Visual App Builder Fits? | YCBT

2025-04-01T00:00:00Z

App builders

Adalo vs Thunkable

Choose Adalo when the product is mostly screens, data, and straightforward actions. Choose Thunkable when visual logic and device behavior are the center of the project.

By YouCanBuildTech Published April 2025 Updated July 29, 2026

The short version

Adalo’s current builder emphasizes responsive screen design: one app can target mobile, tablet, desktop web, iOS, and Android. Thunkable also targets web and native mobile, but its defining workflow is wiring app behavior with visual blocks.

Decision	Adalo	Thunkable
Best starting point	Data-driven screens, directories, listings, bookings, and straightforward MVPs.	Interactive app logic, device features, learning projects, utilities, and prototypes.
Main mental model	Design screens, connect data, define actions.	Design screens, then connect behavior with visual blocks.
Web publishing	Mobile-only or responsive apps can publish to the web; responsive apps adapt across screen sizes.	Mobile web apps and responsive web apps are separate publishing choices.
Native publishing	Official documentation covers Apple App Store and Google Play publishing on eligible plans.	Official documentation covers iOS App Store publishing and Android download/publishing flows.

Pick Adalo when the interface is the product

Adalo is a natural fit when the project can be described as a set of screens backed by users, collections, forms, lists, and actions. The responsive builder is especially relevant if the same product needs to work as a native app and a desktop-capable web app.

Pick Thunkable when behavior is the product

Thunkable’s blocks make logic visible. That can be easier to reason about when the important work is “when this happens, do that,” when a project depends on device components, or when the builder wants to learn computational thinking without starting in a text editor.

Do a real exit test before committing

Build the hardest screen, the hardest data flow, and the hardest device interaction in both tools. Then test the exact publication target you need. A quick prototype can hide constraints that only appear in state management, offline behavior, custom logic, store requirements, or platform-specific components.

Current product facts checked July 29, 2026 against Adalo’s official design documentation, Adalo’s official publishing documentation, Thunkable’s web-app documentation, and Thunkable’s iOS publishing guide. Pricing and plan gates can change; confirm them before choosing.