You Don’t Have to Be a Developer to Build With AI. You Just Need to Learn How to Direct It

For years, turning an idea into a working software product required either knowing how to code or finding someone who did. An operator could understand a problem deeply, know exactly what needed to change and even design the workflow, but there was still a technical barrier between the idea and a working product.

Generative AI is beginning to change that relationship. The interesting shift is not simply that AI can write code. It is that AI can increasingly accompany someone through much more of the building process: defining the problem, thinking through a solution, selecting tools, generating code, explaining unfamiliar concepts, troubleshooting errors and documenting what was built.

I saw this firsthand during the first project-based learning session I hosted through Cred, a community I created for professionals who want to become more AI-native through learning, building and teaching.

Our facilitator, AI Product Manager Ayo-Fisher Oluwapamilerin, took us through the process of building Ayo, an AI-powered WhatsApp bot designed to help groups coordinate travel.

The big takeaway from the project is that a professional does not necessarily need to understand every technical component before beginning to build. What they increasingly need is the ability to define a useful problem, communicate it clearly to AI, evaluate the options AI presents, make decisions and keep iterating when something inevitably fails.

Start With the Problem, Not the AI

Ayo started with a familiar problem. Group trips are surprisingly difficult to coordinate. Someone creates a WhatsApp group, everyone is enthusiastic, destinations and dates start flying around and then the conversation begins to slow down. Decisions disappear inside hundreds of messages, people stop responding and one person gradually becomes the unofficial project manager for everyone's holiday.

The original solution was not a WhatsApp bot. Ayo-Fisher initially explored a web application where travellers could enter their nationalities, departure locations, destination, dates, group size, budget and preferred travel style. The application would then generate an itinerary and eventually allow the group to coordinate within the product.

The problem was behavioural rather than technical. Group travel planning was already happening on WhatsApp. Asking an entire group to create accounts and move their conversation to another application introduced friction before the product had even delivered value. The project therefore evolved from building another destination for users to bringing the technology into the environment they already used.

That is an important starting point for anyone experimenting with AI. “I want to build an AI agent” is not yet a problem statement. “My team spends hours every week searching for answers across internal documents” is. “Five people need to coordinate a decision in a WhatsApp group and nobody knows what has actually been agreed” is. The technology should follow the problem.

Claude Became Part of the Building Process

What happened next is where the project becomes particularly relevant for nontechnical professionals. Ayo-Fisher used Claude throughout the development process, beginning with conversations about the idea itself. He asked what tools could be used, how the product could be structured and how to build an affordable first version. Claude helped suggest the technical components, generate code and explain what needed to happen next.

The important point is that he did not approach Claude by pretending to know more than he did. During the session, he described deliberately communicating with it in straightforward language and asking it to explain unfamiliar parts of the build. The interaction became iterative: describe what you want to accomplish, receive a proposed next step, implement it, show Claude what happened and continue from there.

For someone without a technical background, the starting conversation could be remarkably simple.

Sample prompt:

I have an idea for a product that helps groups coordinate decisions inside a WhatsApp chat. Help me think through the build. Before giving me any code, explain in plain English what the product needs to do, what components I would need and how information would move through the system.

That prompt does something important. It asks the AI to establish a mental model before producing code. For a nontechnical builder, understanding the architecture at a conceptual level is far more useful than immediately receiving several hundred lines of unfamiliar JavaScript.

Once the architecture makes sense, the project can be broken into stages.

Sample prompt:

Turn this into a step-by-step build plan. For each stage, tell me what we are building, why we need it, which tool we will use, what I need to do manually and what you can help me generate. Assume I am a beginner and do not move to the next stage until I have tested the current one.

This is where AI begins to function less like a search engine and more like a technical guide.

Understanding the Architecture

Ayo's eventual architecture involved several technologies. Node.js provided the development environment. Baileys, an open-source library, enabled the WhatsApp connection used for the prototype. Claude handled different AI tasks. Supabase stored messages and trip context. Google services provided information about places and travel times. GitHub held the codebase, while Railway allowed the application to run in the cloud rather than only on a local computer.

That list can sound intimidating to someone who has never built software. The easier way to understand it is to ask what job each component performs.

WhatsApp is where the conversation happens. Claude provides the intelligence. Supabase gives the system memory. External services provide information the model does not already have, such as relevant places or realistic travel times. Railway keeps the application running when the builder's laptop is closed.

The resulting mental model is much simpler: a message comes in, the system understands the context, retrieves or stores relevant information, uses AI and other services to determine an appropriate response and sends that response back to the group.

This is another place where AI can help a nontechnical builder learn while building.

Sample prompt:

Explain the architecture we have designed as if you were explaining it to a business operator who has never written code. For every component, tell me what it does, why the project needs it, what information it receives and what information it sends to the next component. Then give me a simple text-based workflow from user input to final output.

The objective is not to eliminate technical understanding. It is to acquire the amount of understanding required to make informed decisions about the system you are building.

From Conversation to an Actual Codebase

A nontechnical builder can ask Claude to generate files one at a time while explaining where each file belongs and what it does. Instead of copying fragments of code without context, the AI can be instructed to maintain a clear project structure and provide complete files when changes are required.

Sample prompt:

We are ready to build the first working version. Give me one step at a time. Whenever code is required, give me the complete file, tell me the exact filename and where it belongs in the project. Explain what the file does in plain English, tell me exactly what I need to do after saving it and tell me what I should see if the step has worked correctly. Do not assume I know how to use the terminal or development tools.

As the project expands, the same conversation can be used to maintain an understandable record of the codebase.

Sample prompt:

Create a current map of this codebase. List every important file and folder, explain what each one does in one sentence and show how they connect. Highlight anything I should understand before making further changes.

This matters because the goal should not be to accumulate AI-generated code that the builder cannot explain. The goal is to progressively build both the product and the builder's understanding of it.

AI Can Also Help You Debug

One of the most useful moments in our session was not when the product worked. It was when it didn't.

Ayo was experiencing a connection problem. The application appeared to be connected in one environment, but the bot was not responding to WhatsApp messages. Ayo-Fisher's debugging process involved looking at logs and taking relevant error information back into Claude to diagnose what might be happening.

This is an important part of AI-assisted building because prototypes rarely work perfectly from beginning to end. Libraries change. APIs update. Deployments fail. Connections time out. A builder therefore needs to become comfortable moving between the product, the evidence of what is failing and the AI assistant.

A useful debugging interaction could look like this:

Sample prompt:

This application was working previously, but the WhatsApp bot has stopped responding. I am going to give you the relevant error message and deployment logs. First explain in plain English what the logs are telling us. Then rank the most likely causes from most to least likely. Give me one diagnostic step at a time so we can identify the cause before changing the code. Do not expose or ask me to share passwords, API keys or other secrets.

This last instruction is important. AI can lower the barrier to development, but it does not remove the need for basic security practices. API keys, credentials and other secrets should not be exposed in prompts, screenshots, public repositories or portfolio materials.

AI can also be wrong. It can misunderstand an error, recommend an unsuitable tool or suggest a solution that introduces another problem. Ayo-Fisher supplemented Claude's recommendations with his own judgment and external research, including community discussions on Reddit comparing different tools. AI-assisted building still requires evaluation.

The Many Use Cases

Travel is the initial use case for Ayo, but the underlying problem is broader. The system is attempting to understand multiple people, maintain shared context and help a group progress towards decisions.

Once you understand that architecture, several other applications become possible.

A study group could use a similar system to track deadlines, assignments, responsibilities and outstanding decisions. An event-planning group could coordinate vendors, attendees, schedules and logistics. A household could use one to manage shared responsibilities and recurring tasks. Teams that already coordinate work through messaging applications could explore assistants that remember decisions and surface outstanding actions.

That is one of the skills AI-native professionals will increasingly need: not simply knowing how to use a particular tool, but understanding a problem well enough to adapt a technological pattern from one context to another.

Document the Project While You Build It

There is another opportunity that professionals frequently miss. We experiment with AI, build workflows, automate processes and create small prototypes, but much of that work disappears as soon as we move on to the next task.

At Cred, I created a Project Learning Portfolio specifically to address this. The framework is deliberately straightforward: document the problem, the build, the learning, the application and finally the evidence of what you created.

Start with the problem. Who experiences it? What is the context? Why is it worth solving? Then document the build in simple terms, including the workflow from input through AI and other tools to the eventual output. Record the tools you used and what each one contributed.

The next part is equally important: document your thinking. What did you learn? What decisions did you make and why? What surprised you? What failed? A portfolio that only shows a polished final screen misses much of the evidence that demonstrates how someone actually thinks and builds.

Then consider application. Where else could the same logic be useful? What would you build next? This is where someone who learned from Ayo might identify a completely different coordination problem and create their own implementation.

Finally, collect evidence. That might include a working prototype, screenshots, a workflow diagram, a short demonstration video and, where appropriate, a GitHub repository. The goal is not to document everything. It is to capture enough to demonstrate practical capability and make the learning reusable.

Let Claude Help You Document the Entire Journey

There is an additional benefit to building through an extended AI conversation: the conversation itself contains a significant amount of the project's history. It can include the original idea, architecture discussions, rejected approaches, code iterations, errors, fixes and decisions.

Instead of allowing that history to remain buried inside dozens of conversations, use the AI to periodically consolidate it.

Sample prompt:

Based on everything we have done on this project so far, create a project development log. Document the original problem, our initial solution, major changes in direction, the current architecture, every tool we selected and why, important decisions, problems we encountered, how we solved them and what remains unfinished. Do not invent anything that is not contained in our project conversation.

The same approach can be used to create technical documentation.

Sample prompt:

Create a complete README for this project. Include what the project does, the problem it solves, the architecture, the technology stack, the role of each component, installation and setup instructions, required environment variables without exposing their values, how to run the project locally and known limitations. Write it so another person can understand and reproduce the project.

Then use the same material to help create the portfolio narrative.

Sample prompt:

Using our complete project history, help me document this project using the following structure: The Problem, The Build, The Learning, The Application and Portfolio Evidence. Separate what I personally decided or built from what the AI suggested. Include failures and iterations rather than presenting the project as if everything worked on the first attempt. Do not claim outcomes for which we do not have evidence.

At that point, the builder has three related assets: a working project, technical documentation that explains the system and a portfolio case study that demonstrates the capability developed through building it.

The Skill Is Not Just Prompting

It would be easy to reduce all of this to “prompt engineering,” but I think that misses the more consequential shift.

The professional advantage is not simply knowing the perfect sentence to type into Claude. It is being able to recognise a worthwhile problem, break ambiguity into smaller decisions, give AI sufficient context, evaluate its recommendations, understand the system at a useful level, test what it produces, troubleshoot failures and decide what should happen next.

AI may write much of the first version of the code. That does not mean judgment disappears. If anything, judgment becomes more important because producing something has become easier.

For a nontechnical professional, this creates an interesting opportunity. You do not have to begin by deciding that you are going to become a software engineer. You can begin with a problem you understand deeply.

Look at your own work. Where are people repeatedly searching for information? Which process requires constant manual follow-up? Where do decisions stall? What information is repeatedly copied between systems? What process lives in a spreadsheet because nobody has built a better tool?

Pick one problem and describe it in plain language.

Sample prompt:

I want to explore whether AI could help solve the following problem: [describe the problem]. I am not technical. Before suggesting a solution, ask me the questions you need to understand the users, current process, pain points, available information and desired outcome. Then propose the smallest useful project I could build to test whether the idea works.

That is a very different starting point from asking AI to “build me an app.”

It forces the technology to follow the problem.

The barrier between identifying a problem and creating a working technical prototype is getting smaller. That does not make technical expertise irrelevant, nor does it mean every AI-generated application is ready for production. It does mean that many more professionals can participate in building than could before.