What I enjoy about being a mentor at Outskill, plus practical advice on Claude Code, Codex, APIs, small working prototypes, and checking what you build.
The best part of being a mentor at Outskill is working with people who genuinely want to build.
This screenshot is from a Catalyst session on building AI content creation apps with APIs. We explored Claude Code, advanced Codex workflows, web scraping, and APIs. It was a good session, and I enjoyed it.
But the tools are only one part of the experience. What stays with me is the learners' curiosity. They ask thoughtful questions and want to get hands-on. As a mentor, that gives you something meaningful to work with: people who are willing to try, get stuck, ask for help, and keep building.
I am grateful to be a mentor at Outskill. I also wanted to use this reflection to share the advice I would give someone learning to build with AI today.
The following workflow is an illustrative starting project, not a claim about something every learner built in the session.
1. Start with a useful outcome, not a tool list
It is easy to get pulled into choosing tools before you have chosen a problem. You hear about Claude Code, Codex, a scraping service, an API, and an automation platform. Soon you have an impressive stack and no clear definition of what it should do.
My suggestion is to begin with one sentence: "I want to help this person do this task with this input."
For example: "I want to help a creator turn an article they own into a draft summary and social caption they can review."
That sentence gives you a user, a task, an input, and a boundary. It also gives you a way to judge whether the first version is useful. You are not trying to build a complete content platform. You are trying to make one repeatable task clearer and easier.
Tools should earn their place in that workflow. A scraper is unnecessary if pasting the article text is enough for the first experiment. A publishing integration is unnecessary if you have not yet checked the quality of the drafts.
2. Write a brief that includes context and boundaries
"Build me an app" leaves the AI to make too many decisions. It does not explain who the app serves, which information it can use, or what must not happen.
A more useful brief has five parts: the user, the input, the output, the constraints, and the test.
For the content example, that could be: "Build a local prototype for a creator. It accepts article text and produces a short summary and one caption. Use only the supplied text. If information is missing, say so instead of inventing it. Show the original beside the draft. Do not publish anything. A working version must handle a normal article, an empty input, and incomplete text. Explain the approach before making changes."
This is not about finding a magical prompt. It is about giving the tool enough information to work toward a result you can inspect.
If you already have a project, add the relevant files and conventions. If there are actions that require approval, name them. The AI should not have to guess what "done" means or how much responsibility it has.
3. Build the smallest complete path from input to output
I would rather see a small working flow than a beautiful interface with unfinished connections behind it.
For this example, start with a text box, a generation step, and a review screen. Submit one article. Inspect the draft. Fix the obvious failures. Only then decide what to connect next.
A sensible sequence is: manual text input, draft generation, source comparison, local saving, and then an optional approved data connection. Each addition should solve a problem you can actually point to.
This also makes debugging easier. If a draft is poor, you can check the supplied text and instructions before wondering whether a scraper extracted the wrong page. If a connection fails, you can isolate it without rebuilding the entire application.
Do not confuse "small" with "careless." A small version still needs clear errors, sensible handling of missing input, and an honest statement of what has been tested.
4. Ask AI to teach you while it helps you build
You do not need to become an expert in every framework before starting. But accepting code you cannot explain is a weak foundation for a project you want to maintain.
Ask the tool to walk you through the important pieces in plain language. What does this function receive? What does it return? Which file connects the interface to the API? What happens if the request fails? Where is the generated draft saved?
One prompt I like is: "Explain this workflow as if I have to demonstrate it to someone else. Identify the input, transformation, output, and failure points. Then show me the files responsible for each part."
When a fix works, ask why. When it fails, ask for evidence about the cause before another rewrite. Otherwise, it is easy to end up with a pile of changes and no understanding of which one solved the problem.
The goal is not to memorise every line. It is to understand enough to make decisions and recognise when the system is behaving unexpectedly.
5. Understand what scraping and APIs add to the system
In plain language, a scraper retrieves information from a page. An API gives software a defined way to request data or perform an operation. Both can be useful, but adding either means checking a new boundary.
With scraping, inspect what was actually retrieved. Did you get the article body, or a navigation menu and cookie notice? Is the source complete? Are you allowed to use that material? Do not bypass access controls or assume that visibility equals permission to republish.
With an API, look at the response before building assumptions around it. Which fields are present? Can a result be empty? How does an error appear? What happens if the provider is unavailable or a usage limit is reached?
Keep API credentials out of public repositories and shared screenshots. Be deliberate about sending personal or confidential information to external services. A successful connection does not settle the privacy or permission question.
For a learning project, use sample material you own or have permission to process. That lets you explore the mechanics without casually turning someone else's data into a test fixture.
6. Test the result, not just the happy path
"It runs" is an important milestone. It is not the same as "it does the right thing."
For a content app, review whether the summary preserves the source's meaning, whether names and numbers are correct, and whether the caption invents a result or endorsement. Fluent text can still be wrong.
Try a few deliberate failures: an empty input, a very short source, missing context, a broken URL, and an unavailable API. Decide what the user should see in each case. A clear explanation of a missing input is better than a confident answer built from assumptions.
Ask the AI to report the tests it actually ran, the results, and what remains unverified. A description of a test is not evidence that the test happened.
If you cannot reproduce the working result with another sample, keep the project in the experiment category. That is an honest stage of progress, not a failure.
7. Separate preparing work from taking an external action
Generating a caption and publishing it are different actions. So are suggesting a database update and making it, or preparing a message and sending it.
For an early workflow, make that boundary visible. Let the app prepare a draft, show the input and output, and wait for a person's decision. Add an external action only when you understand the failure cases and have permission for that action.
This is not about making every useful automation slow. It is about giving the workflow responsibility in proportion to what you have verified.
Before connecting a publishing account, ask: Can I identify exactly what will be posted? Can I stop it? Can I tell whether it succeeded? If the response is lost, can I check for an existing post before retrying?
Those questions are less glamorous than a feature demo, but they matter once a tool starts doing things outside your local project.
A prompt you can adapt for your next build
"Here is the person I am building for, the outcome I want, my sample input, and what a good output looks like. Explain the approach before editing. Build the smallest complete version using the project's existing tools. Handle missing input and errors clearly. Show me how you tested it, what passed, and what remains unverified. Do not publish, send messages, or change external data without my approval."
Replace the general parts with your actual problem. Keep the structure: outcome, context, constraints, implementation, and verification.
Why I enjoy being a mentor
The tools will keep changing. The habit I want learners to keep is simpler: choose a useful problem, ask good questions, understand the moving pieces, and check the result.
That is what I appreciate about the people at Outskill. They bring curiosity and a genuine desire to build. I am grateful to help people work through their ideas and make their learning practical.
The Catalyst session in this screenshot is one part of that broader mentoring experience. Thank you to the Outskill learners for the questions, effort, and builder mindset you bring to these sessions.
Start with one useful thing. Build it, understand it, and improve it from there.
Subscribe free to Harshith's Newsletter to read every article in the interactive edition.
Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.