Learn
Build with AI. Understand what you build.
I'm Sunny Patneedi. These practical lessons are for adults, including nontechnical builders, who want to make useful things with AI and stay in charge of the decisions. Start with a written example, test the work, then check whether you can explain and improve it.
A booking button is not a booking system
Written, illustrative lesson. The dog-walking schedule below is a teaching scenario, not a shipped project, a learner case study, or reported test results.
Imagine making a simple dog-walking schedule with AI. Start with one slot, Tuesday at 10:00, and one rule: that slot can have at most one confirmed booking. Use made-up names and a test copy, not real customer information.
Step 1
Initial attempt: ask for a schedule
A vague starting prompt is “Make a dog-walking schedule with a Book button.” A plausible first version lists available times and adds a booking whenever someone clicks. It may look finished, but the prompt never says what happens when two people want the same time.
Write the rule before accepting the output: one confirmed booking per slot. Keep the first version so you can compare it with the revision.
Step 2
Failure: trace two requests
On paper, start with an empty booking list. Add Alex’s request for Tuesday at 10:00. Then add Sam’s request for the same slot. If each request simply adds a row, the list now contains two confirmed bookings. This hand-trace exposes the missing rule; it is not an observation from a real app.
Changing the button to “Taken” can help the next visitor, but a second browser may still show an old “Available” button. A label is not an enforcement rule.
Step 3
Test: decide what would count as correct
Before asking AI for a fix, write expected outcomes. One request should be accepted. A second request for the same slot should be rejected. Two nearly simultaneous requests should still leave exactly one confirmed booking.
If you build a prototype, run the test plan below in a disposable test copy. Check the saved bookings as well as the screen. Record the actual result, the version, and any assistance used; do not treat this page’s expected outcomes as your results.
Step 4
Improvement: enforce the rule where bookings are saved
Ask AI to reserve the slot in one indivisible operation at the shared booking store. With a database, one possible design is a unique slot identifier on confirmed bookings, plus a handler that reports a conflict instead of saving a duplicate. Ask it to explain how that design behaves when two requests arrive together.
Update the display only after the booking is accepted. Show a clear “Slot already taken — choose another time” message for a conflict. Re-run every test after the change, including the first successful booking so the fix does not block everyone.
Before: plausible but incomplete
Pseudocode, not runnable code
When Book is clicked: add a confirmed booking for the selected slot show “Booked”
After: the intended rule
Pseudocode, not runnable code
When Book is clicked: ask the shared store to reserve the slot atomically if reserved: show the confirmed booking if already reserved: show “Slot already taken” if the request fails: show an error, not a confirmation
A more precise prompt to try
My rule is one confirmed booking per slot. Keep the schedule simple. Enforce the rule in the shared booking store, including simultaneous requests; do not rely only on a disabled button. Explain where the rule is enforced, how conflicts and errors reach the visitor, and how I can test the saved records. Name any assumptions or missing backend setup before claiming the fix works.
Run your own test plan
Reset test data between cases. Keep a separate column in your notes for the actual result and saved-record evidence. Nothing in this table is a claimed test result.
| What to try | Expected behavior |
|---|---|
| Reset the test slot; send one request. | One confirmation and exactly one saved booking. |
| Send a second request for that same slot. | A conflict message; the saved booking count remains one. |
| Reset; open the slot in two browsers and request it in both. | Only one request succeeds. Check the saved records; clicking manually alone is not a reliable concurrency test. |
| Ask for a repeatable test that sends two requests together to the booking handler. | Exactly one succeeds and one conflicts; exactly one booking is stored. Inspect the test setup rather than trusting an AI-written “pass” summary. |
| Request a different, empty slot. | It succeeds without changing the existing booking. |
| Make the booking service unavailable in the test copy. | A visible failure, no false confirmation, and no invented saved booking. |
Check 1: does the project work?
- Check the saved records against the rule, not just the button text.
- Record expected versus actual results for each test; a blank actual result is untested, not passed.
- Name what is still untested: retries, cancellation, login and permissions, time zones, and real traffic are outside this small lesson.
Check 2: does its creator understand?
- Without rereading the walkthrough, explain why “Taken” on the screen cannot stop two browsers from booking.
- Trace the first and second requests, name where the rule is enforced, and predict what happens if the service fails.
- Try a changed requirement: a cancelled booking should reopen the slot. Write the new rule and a test before asking AI to implement it.
- A week later, apply the same one-reservation rule to a different example, such as borrowing a library item. Record which tools or hints you needed.
This is a reasoning and test-planning exercise, not a complete booking app. A browser-only demo cannot establish multi-user safety. Atomic storage, permissions, privacy, and deployment need their own implementation and review. A passing project test does not establish that its creator learned, and one explanation does not establish lasting transfer.
Guided learning for adults
Beyond Vibes is a provisional name for a proposed guided-learning workshop, not a scheduled program. It is for adults who want help building a small project with AI, including people without a technical background. Dates, pricing, format, and enrollment are not confirmed.
The proposed scope is one small build, a record of the choices and revisions, a project test, and a separate explanation or changed-requirement exercise. This is a learning interest route, not investor or founder advisory, and not the children's SayMake product.
Interested? Open my LinkedIn profile and send a message with the suggested subject "Adult guided learning interest — Beyond Vibes". Tell me what you want to build, your experience with AI, and where you get stuck. This expresses interest; it is not a booking, enrollment, or payment.
- Build a small project
- Test the project
- Explain and improve it
Adult learning interest, suggested subject: Adult guided learning interest — Beyond Vibes
For parents: SayMake
SayMake is an AI-supported maker studio that helps young people turn their interests into real projects and real-world capability. It is listed as an experiment; availability is unverified.
Children start from something they care about and practice the full build loop: choose, frame, build, test, explain, and improve. The AI is intended as a scaffold that helps a kid get unstuck while leaving the consequential decisions with them.
As a next step, see SayMake's status in the project archive, read how the build loop works, or ask whether SayMake fits your child’s interests and what next steps could look like. Suggested subject: "SayMake parent question".
Parent inquiry, suggested subject: SayMake parent question
The ideas underneath
Adult learning and SayMake are separate paths, but both rest on the same principle: AI should scaffold thinking, not surrender it. These pieces explain it in more depth.