When AI can write code for you, how much do you need to learn yourself?

You do not need to memorise every command or understand every line before you begin. However, you need enough understanding to guide the work and make decisions about the result.

That starts with being able to explain what your app should do, how its main parts work together, what happens to its information, and how you know whether a change succeeded.

These are things you can learn gradually as you build.

Know What The App Is Meant To Do

The first thing you need to understand is the result you want someone to achieve.

For the task app used in our earlier examples, you might say:

“A person can write down something they need to do, find it again later, and mark it as finished.”

That sentence gives you a clear purpose against which to judge changes.

If AI adds a calendar, colour themes, and a points system, you can ask whether those additions help deliver the intended experience. You have a basis for deciding what belongs in the app.

You should also understand its important rules.

For example, should a finished task remain available? Can someone change its name? What should happen if they try to add a task without entering any text?

AI can help you explore these questions. The decisions should reflect what you want the app to do.

Know the main parts and their responsibilities

You do not need to remember where every line of code lives. You do need a basic picture of how the app works.

For a simple task app, that picture might be:

• The screen shows tasks and receives actions.
• The app’s rules decide what those actions mean.
• The saving system keeps information available for later.

These responsibilities may be spread across several files. Understanding them helps you locate the area involved in a change.

Suppose tasks appear correctly but disappear after the app closes. You can recognise that the problem may involve saving or loading information. Changing the colour of the task list would not address that behaviour.

A useful explanation from AI might answer:

“Which parts of this project display tasks, change them, and save them?”

The aim is to build a simple map you can use when discussing the work. Chapter 3 will develop this understanding in more detail.

Know what happens to the information

Many apps receive information, change it, and keep some of it for later.

You should be able to follow that movement in everyday language.

In the task app:

“The person enters a task name. The app creates a task, saves it, and shows it in the list. When the person finishes it, the app saves that change too.”

This description helps you connect what appears on the screen with what the software is doing.

It also raises important questions:

• Does the information stay on the person’s device?
• Is any of it sent to an external service?
• What remains after the app closes?
• What happens when someone deletes it?

These questions matter even if AI writes all the code involved.

For example, introducing an online service could change where task information is stored and who has access to it. You need to understand that decision before accepting the change.

Understand the consequences of a change

When AI proposes a change, aim to understand its purpose, the parts it affects, and its possible consequences.

Consider a request to remove finished tasks from the main list.

There are at least two ways to interpret it:

• Hide finished tasks from that view while keeping them saved.
• Delete finished tasks from storage.

Both could make the screen look the same immediately afterwards. Their consequences are different.

If the tasks are only hidden, the person might view them again later. If they are deleted, that information may be gone.

You do not need to understand every instruction used to make this change. You do need to know which behaviour you are accepting.

A useful question is:

“Does this change only affect what the person sees, or does it also change or delete saved information?”

The more lasting the consequences, the more understanding you need before proceeding.

Know How To Recognise A Successful Result

Before accepting a change, you should be able to describe what would show that it worked.

For example:

“When I mark a task as finished, it should look finished and remain that way after I reopen the app.”

You now have something specific to compare with the result.

This connects to the previous blog’s distinction between claims and evidence. Your role includes understanding whether the available evidence addresses the behaviour that matters.

A successful check of the screen’s appearance would cover only part of this example. You would still need evidence that the change was saved.

Later chapters will explain testing in more detail. The foundation is knowing what success means for the particular change.

Know How You Could Recover

You also need to understand what would happen if a change went wrong.

Could you return to the previous working version? Would doing so restore only the code, or would saved information also need attention?

You will learn about version history and backups later. For now, keep this distinction in mind:

Restoring an earlier version of the code does not necessarily restore information that was changed or deleted.

Knowing the recovery options helps you judge whether a proposed change is ready to try. It is especially important when the app already contains information that matters to someone.

Know Which Responsibilities Remain Yours

An app can affect people beyond its creator. It may collect personal information, request access to a device, take payments, or depend on another company’s service.

You need to recognise when those choices require further attention.

For example, if the task app begins sending task names to an external service, you should understand why that is necessary, what is sent, and what users need to know.

Chapter 7 will cover legal and platform responsibilities, including privacy policies, user agreements, and distribution requirements. When those issues affect an early design decision, you can read the relevant guidance before continuing.

The same principle applies to technical decisions with consequences you cannot yet assess. AI can help explain them, and there will be situations where review by an experienced developer or another qualified professional is appropriate.

Part of directing the work is recognising when you need that help.

Build your understanding around decisions

You do not need to pause the project and study every unfamiliar detail.

Focus first on the knowledge needed for the decision in front of you.

If you are changing a button’s wording, understand its meaning and where it appears. If you are changing how tasks are saved, understand what information is affected, how existing tasks will be handled, and what could happen if saving fails.

This gives your learning a practical direction.

When an explanation is unclear, you can ask:

“Explain this using the task app as an example. What changes for the person using it, what happens to their information, and what could go wrong?”

Then try to describe the answer in your own words. Any part you cannot explain points to something worth clarifying.

You are ready to delegate more confidently when you understand the purpose, consequences, and evidence well enough to make a decision. Your knowledge can deepen as the software grows.

In the next chapter, we will turn that first responsibility into a clearer foundation for development: describing the result you want before choosing the features.