DEV Community: Marcus Kim

What Gemini 3.7 Flash Can Teach Beginners About Testing AI-Generated App UI in 2026

Marcus Kim — Sat, 15 Aug 2026 18:39:58 +0000

On August 13, Google introduced Gemini 3.7 Flash as its latest “workhorse” model for coding and agents. One detail should matter to anyone using AI to build an app: Google says the model improved at web development and can show strong design adherence when you give it a screenshot, image, or full design system as a reference.

That is useful progress. A beginner can describe a screen, attach a visual target, and get something recognizable much faster than before.

It also creates a more convincing trap.

A generated screen can match a screenshot and still fail as software. The button may not lead anywhere. The layout may collapse when real text arrives. The empty state may not exist. Keyboard focus may jump in a nonsense order. The “saved” result may disappear after refresh.

The durable beginner lesson is this:

A screenshot proves appearance. A screen-proof checklist proves an interface.

What changed, and what did not

Google’s announcement emphasizes better first-pass coding, instruction following, web development, and UI generation from visual references. The release also extends the model across developer surfaces including the Gemini API, Google Antigravity, Google AI Studio, and Android Studio.

This continues the direction Google described at I/O 2026: moving from a prompt toward a production-ready application through agentic tools. The distance between “I described a screen” and “I can run a screen” keeps shrinking.

But production-ready is not a visual style.

Apple’s interface guidance still asks layouts to preserve hierarchy, adapt to different device and system conditions, and keep controls understandable. The W3C’s accessibility guidance still cares about things a static image cannot prove, including focus order, visible focus, reflow, target size, labels, and error prevention.

The model can produce more of the first draft. You still need a repeatable way to decide whether that draft deserves to stay.

The beginner mistake: reviewing the best-looking moment

AI-generated UI usually gets reviewed in its most flattering state:

one desktop width;
ideal sample data;
no loading delay;
no errors;
no keyboard;
no long names;
and no confused first-time user.

That is not a test. It is a portrait session.

I have learned to review screens as changing systems. A useful interface has to explain what matters, accept an action, show what happened, survive awkward inputs, and let the user recover. Visual quality matters, but visual quality is only one layer of the evidence.

If you need help defining the user, workflow, screen responsibilities, and success criteria before AI starts generating UI, my AI App Builder Starter Prompts are free. The immediate job is to give the tool a screen contract it can be judged against, not just a mood and a color palette.

My seven-point AI-generated screen-proof checklist

1. Give the screen one job

Write this before you review pixels:

This screen helps [user] do [action] so they can get [result].

Then name the primary control that moves that job forward.

If you cannot identify one main action, the screen may be a planning board disguised as a product. AI loves giving every idea its own card, badge, metric, and button. The result can look busy and complete while the user has no obvious next move.

Proof: show the screen to someone for five seconds, hide it, and ask what they think it does and what they would press first.

2. Run the primary journey with real inputs

Do not review only the landing state. Tap, type, select, submit, go back, and return.

For a task screen, create a task and reopen it. For a search screen, type a query and choose a result. For an onboarding screen, finish the first useful action instead of merely swiping through explanations.

Proof: record the exact starting state, actions, and expected ending state. The journey passes only when the user result is visible and understandable.

3. Build a state sheet

Every important screen should show more than its happy path. At minimum, inspect:

loading;
empty;
normal success;
invalid input;
unavailable or failed request;
and completed or saved state.

You do not need six completely different designs. You need six honest answers to “What does the user see now, and what can they do next?”

Proof: capture each state at the target viewport. If two states look identical but require different user actions, the interface is hiding important information.

4. Pressure-test the content

Replace tidy demo text with inputs that strain the layout:

a long name;
a long title;
no image;
several lines of body copy;
a large number;
zero results;
and enough rows to require scrolling.

This is where “design adherence” meets actual product data. A screenshot reference cannot predict every name, localization change, or user-created mess.

Proof: no essential control is covered, clipped, pushed offscreen, or made ambiguous by realistic content.

5. Test the viewport, keyboard, and safe areas

For web, test at least a narrow phone width and the desktop width you expect people to use. For mobile, test a smaller supported phone, a larger phone, the software keyboard, text-size changes, and the platform’s safe areas.

Apple’s layout guidance emphasizes adaptation across screen sizes, orientation, text size, locale, and system features. Your first version does not need to support every device ever made, but it must behave deliberately on the devices you claim to support.

Proof: the primary journey remains usable without horizontal scrolling, covered controls, accidental cropping, or a keyboard that traps the user.

6. Run the non-mouse test

On the web, use only the keyboard for the primary journey. Confirm that focus is visible and moves in an order that preserves meaning. On mobile, confirm controls have clear labels, comfortable target sizes, and an onscreen alternative when a gesture is not obvious or essential.

WCAG 2.2 includes guidance for focus order, visible focus, target size, and alternatives to dragging. Apple similarly recommends sufficiently sized controls, spacing between them, familiar interactions, and alternatives to gestures.

Proof: you can identify where focus is, activate the important controls, understand labels without color alone, and recover from an error without guessing.

7. Prove that the screen is connected to the product

The last check is intentionally unglamorous:

Does the primary action write or retrieve the correct state?
Does that state survive refresh, relaunch, or navigation when it should?
Does Back return to the expected place?
Does another account see only what it is allowed to see?
Does a failure leave the previous good state intact?

This is the line between a generated interface and a working product. A button animation is feedback. It is not proof that the user’s goal happened.

Proof: inspect the visible result after leaving and returning to the workflow. If the product promises persistence or ownership, test it with the smallest realistic example.

A reusable screen evidence table

Use one row per delivered screen:

Proof area	Question	Evidence
Job	Can a first-time user name the screen’s purpose and primary action?	five-second result
Journey	Can the user complete the intended action?	exact start, steps, and end state
States	Are loading, empty, success, failure, and recovery clear?	state captures
Content	Does real and awkward data stay readable?	long, empty, and missing-content runs
Viewports	Does the supported layout adapt?	target viewport captures
Access	Can the journey work with keyboard or accessible controls?	focus, labels, targets, and alternatives
Product	Does the action connect to real navigation and state?	refresh, relaunch, account, or persistence proof

If a row has no evidence, label it unverified. Do not upgrade confidence because the gradient is nice.

The tradeoff

This checklist slows down the moment when you can call the UI done. That is the cost.

It may also make you throw away a generated screen that looked impressive on the first pass. You may discover that a simpler layout survives more states, supports larger text, and gives the main action more room. The quieter design can be the stronger product.

The checklist is not a promise that one screen can be perfect for every person and device. Accessibility testing can go much deeper, platform conventions differ, and real user research can overturn your assumptions. The point is to replace screenshot confidence with a minimum evidence floor.

What you should do next

Take one important screen from your app. Write its one-sentence job, then create the seven proof rows before asking AI for another redesign.

Give the AI the failed rows, not a vague request to “make it better.” Ask it to preserve what passed, repair what failed, and show the new evidence at the same viewports and states.

For the immediate guided action, start with the AI App Builder Starter Prompts, which are free and help you turn an idea into a bounded workflow AI can build and you can verify. For the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering scope, screens, stack, prompting, architecture, QA, deployment, and launch.

The faster AI gets at producing convincing screens, the more valuable this distinction becomes:

Do not approve the screenshot. Approve the evidence.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

Lovable’s $13.3B Raise: What Beginner AI App Builders Should Learn About Value Loops in 2026

Marcus Kim — Thu, 13 Aug 2026 18:40:33 +0000

On August 12, 2026, Lovable announced that it had raised $400 million in Series C funding at a $13.3 billion valuation.

That is the attention-grabbing part. The useful beginner lesson is hiding a few paragraphs lower.

Lovable described its first chapter as making software easier to create. Its next chapter is about helping people run businesses: payments, discoverability, integrations, security, permissions, governance, and systems that understand whether the software produced a meaningful outcome.

In other words, the company behind one of the best-known “describe it and build it” platforms is investing beyond the build button.

That distinction matters if you are making your first app with AI. A prompt can produce screens, files, and a deployment. None of those automatically creates a product people will use twice.

The durable beginner lesson is this:

Before you ask AI to build the app, define the loop that makes the app useful again.

If you need help turning a rough idea into that kind of controlled plan, my AI App Builder Starter Prompts are free. Use them to clarify the user and workflow before your coding tool starts manufacturing a small digital shopping mall nobody requested.

What Lovable actually announced

The funding number is real news, but Lovable’s product description is more instructive than its valuation.

The company reported that people had created more than 60 million projects on its platform and that Lovable-built apps were receiving more than 900 million visits per month. Those are company-reported figures, not a neutral audit, but they explain what Lovable says it is building next.

Its priorities now include:

helping builders reach customers;
connecting apps to payments and business systems;
making software more proactive;
strengthening security, reliability, permissions, and governance; and
learning which product choices lead to outcomes such as a better workflow or a growing business.

Lovable had already been moving in this direction. In May, it wrote that “building is just the beginning” when it added search and AI-discoverability tools. In June, it introduced automatic security scanning before publication, while clearly noting that a basic scan does not catch every application-specific logic flaw.

The pattern is hard to miss.

Generating version one is becoming cheaper and faster. Reaching users, preserving trust, operating the workflow, learning from real behavior, and keeping the app useful are becoming a larger share of the actual job.

The beginner mistake: treating first output as finished value

AI coding tools are very good at creating the emotional experience of progress.

You describe an app. The tool creates a landing page, dashboard, login screen, database, animated button, and three tasteful gradients. Suddenly you are staring at enough software to make your nervous system ring a tiny startup bell.

But a collection of screens is not a product loop.

Suppose you build a study-planning app. A beginner brief often sounds like this:

Create a dashboard where students can add classes, assignments, study sessions, notes, reminders, goals, and an AI tutor.

That describes inventory. It does not describe value.

A value loop sounds different:

When a student receives a new assignment, they enter its due date and expected effort. The app turns it into a realistic study plan, saves completed sessions, shows whether the student is falling behind, and adjusts the next plan when they return.

Now we know why the user opens the app, what they provide, what the system changes, what useful result appears, what must persist, and why the user may come back.

The second version gives AI an architecture to serve. The first version gives it a furniture catalog.

The six-part value-loop contract

Before coding, I would write this contract:

Trigger:
[What happens in the user’s life that makes them open the app?]

Input:
[What information, choice, or action does the user provide?]

Transformation:
[What does the app calculate, organize, create, compare, or coordinate?]

Useful result:
[What can the user do or understand now that they could not before?]

Saved state:
[What must remain true when the user closes and reopens the app?]

Return reason:
[What new event, progress, change, or unfinished job brings the user back?]

This is not another giant product-requirements document. It is six answers that force the app to behave like a system instead of a slide deck.

Here is the study-planner example:

Trigger:
A student receives an assignment with a real deadline.

Input:
Due date, estimated effort, available study windows, and confidence level.

Transformation:
The app divides the work into sessions that fit the available calendar.

Useful result:
The student sees the next realistic study action instead of a vague deadline.

Saved state:
Completed sessions, changed availability, and remaining effort survive reopening.

Return reason:
The student finishes a session, misses one, or receives another assignment.

Once this exists, screens and data stop being arbitrary.

You probably need an assignment form because the input requires it. You need a schedule view because the useful result requires it. You need persistence because completed sessions change the next recommendation. You may need reminders because a future event reopens the loop.

You probably do not need a social feed, seven profile themes, or an AI mascot that looks concerned about midterms.

The loop earns the architecture.

If you want guided questions for turning an idea into this contract, the AI App Builder Starter Prompts are free. Start with the idea and scope prompts, then ask your AI tool to translate the answers into one complete value loop.

Turn the loop into one vertical build

The next mistake is building each technical layer separately.

Beginners often ask AI to make every screen, then every database table, then every API, then every test. That can produce a large pile of parts without proving that the user can complete the promised job.

Build one thin path through the full loop instead:

Create the trigger state.
Let the user provide the minimum real input.
Run the transformation with honest data.
Show the useful result.
Save the state.
Close and reopen the app.
Trigger the return event and confirm that the next result reflects what happened before.

For the study planner, do not begin with ten assignment types and five calendar views. Add one assignment. Generate one plan. Complete one session. Reopen the app. Adjust the remaining plan.

That path tells you more than twenty polished mockups because it tests whether the product remembers enough to become useful again.

My software engineering training taught me to care about complete workflows, data, verification, and maintenance. My entrepreneurship background taught me the other half: a technically valid workflow still needs to deliver something a person values.

The value-loop contract connects those two questions.

How to test the loop before adding features

Give the loop five tests.

1. The trigger test

Can you name the real-world moment that causes the user to open the app?

“They want productivity” is not a trigger. “They received an assignment and do not know how to fit it into the week” is.

2. The result test

Can the user point to a changed condition after one session?

The assignment is organized. The invoice is sent. The route is planned. The recording is exported. The bug is reproduced. Something became different.

3. The persistence test

Does closing and reopening preserve the facts that the next decision depends on?

If the app forgets completed work, ownership, preferences, or history, the loop restarts as amnesia with a logo.

4. The return test

Is there an honest reason to come back?

Some utilities are intentionally one-shot, and that is fine. A file converter does not need to invent a friendship streak. But if your business model assumes repeated use, the product needs a repeated job.

5. The failure test

What happens when the transformation fails?

If an AI model, payment service, API, or network call breaks, keep the input, explain the state, and give the user a safe next action. A broken loop should degrade honestly, not erase the user’s work and stare at them through a spinner.

The tradeoff: a clear loop can make the idea feel smaller

This method can feel disappointing because it removes decorative ambition.

Your “AI platform for students” may become “a tool that turns one assignment into an adjustable study plan.” Your “freelancer operating system” may become “a tool that turns an approved scope change into a revised milestone and client update.”

That is not automatically a weakness.

A clear loop creates something you can build, test, explain, and improve. If the loop works, you can add adjacent loops later. If it fails, you learn before constructing an entire software suburb around it.

The limitation is that not every valuable product depends on frequent return. Calculators, migration tools, generators, and one-time utilities can succeed with occasional use or a transaction-based model. Do not bolt on fake retention merely because subscription software is fashionable.

The rule is not “make everyone come back every day.”

The rule is “know whether your product needs a return loop, and design the business honestly around the answer.”

What you should do next

Before your next AI coding session, write the six lines:

trigger;
input;
transformation;
useful result;
saved state; and
return reason.

Then ask AI to produce the smallest vertical build that proves all six. Do not approve extra screens until the tool can explain which part of the loop each screen serves.

Lovable’s funding round is evidence that investors see enormous opportunity in making software creation accessible. Lovable’s own roadmap is also a reminder that creation is only the opening move. The platform is investing in the machinery that helps software reach people, operate safely, connect to real work, and produce measurable outcomes.

Your first app does not need Lovable’s valuation, feature surface, or 60 million sibling projects.

It needs one loop that works twice.

For the immediate guided action, AI App Builder Starter Prompts is free and helps you turn a rough idea into a controlled first build.

For the organized path from idea through scope, stack choice, prompting, QA, deployment, and publication, AI App Builder From Zero is the deeper build-along field manual.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

Cloudflare Kitesurf: What Beginners Should Learn About AI App Tradeoffs In 2026

Marcus Kim — Tue, 11 Aug 2026 00:55:20 +0000

On August 6, 2026, Cloudflare announced Kitesurf, a browser built for AI agents instead of people. The project was only twelve weeks old, ran on Cloudflare Workers, and was already available in beta through Browser Run.

The headline sounds like another story about AI making software faster. The more useful detail is that Kitesurf was not faster at everything.

In Cloudflare’s published benchmark, Kitesurf used much less CPU and memory than a warm Chromium pool for screenshot and HTML-extraction jobs. It was also around 1.7 to 1.8 times slower in wall-clock time for those same jobs. It could handle many agent workflows, but Cloudflare explicitly said it was not yet the right choice for video, WebGL, some bot-challenge handshakes, or long authenticated sessions that need persistent state.

That is not a contradiction. It is a product decision.

Cloudflare did not build “a better browser” in every possible dimension. It built a browser for a narrower customer, optimized the resources that mattered to that customer, accepted visible losses elsewhere, and kept Chromium as the fallback.

The beginner lesson is simple:

Your first app does not need to win every comparison. It needs to make the right trade on purpose.

If you are still turning a rough idea into a controlled first build, my AI App Builder Starter Prompts are free. They help you define the user, job, boundaries, and proof before an AI coding tool starts inventing requirements for you.

What Cloudflare actually changed

Most browsers carry requirements accumulated for human use: tabs, extensions, device synchronization, smooth visual interaction, broad compatibility, persistent sessions, video, and much more.

AI agents have a different job. They may need to load a page, inspect its structure, extract content, take a screenshot, or produce a PDF. For that work, CPU, memory, isolation, scale, and machine-readable output can matter more than a perfectly smooth human browsing experience.

Kitesurf reflects that distinction. It uses pieces of the modular Blitz HTML/CSS rendering engine, runs its components in isolated Workers, and exposes enough of the Chrome DevTools Protocol for compatible automation tools. Cloudflare reported that it already passed more than 215,000 tests from the Web Platform Tests project, then added integration and visual-regression tests against real sites because standards conformance alone could not prove the whole job.

Cloudflare’s own numbers make the trade visible:

Screenshot CPU use: 3.1 times lower than Chromium in the published test.
HTML-extraction CPU use: 3.8 times lower.
Screenshot memory use: 4.7 times lower.
HTML-extraction memory use: 7 times lower.
Screenshot wall time: 1.8 times slower.
HTML-extraction wall time: 1.7 times slower.

Those results came from five Browser Run Quick Action runs across a 14-URL corpus, so they are a product benchmark, not a universal law of browsers. Still, they expose a decision most beginner builders hide from themselves: “fast” is not one thing.

Fast for whom?

Fast in which resource?

Fast at what cost?

The mistake beginners make: asking AI for “the best”

When you ask an AI coding tool to make an app “fast, scalable, beautiful, secure, simple, flexible, and production-ready,” it will usually agree with the entire sentence. AI is extremely polite about impossible product briefs.

The problem appears later. Every extra priority competes for architecture, time, money, interface space, testing, or maintenance.

A real product decision sounds less impressive:

Make the main workflow faster, even if an advanced workflow waits.
Reduce memory, even if a one-shot task takes slightly longer.
Support one platform well before supporting three platforms awkwardly.
Keep the first data model simple, even if a future feature needs a migration.
Preserve an honest fallback instead of pretending every edge case is solved.

That is not settling for bad software. It is refusing to make a fake promise to yourself.

I came into software with an entrepreneurship degree and later earned a master’s degree in software engineering. Kitesurf sits directly where those two disciplines meet. Engineering asks, “Can we build it?” Product judgment asks, “Which result is worth optimizing, and which compromise will the user accept?”

Your AI tool can help with the first question. You still own the second.

The tradeoff contract I would write before coding

Before your next build, give the project a six-line tradeoff contract.

Target user and job:
[Who needs to accomplish what?]

Optimize:
[Which one measurable result should improve?]

Accept:
[Which loss or limitation is acceptable in version one?]

Protect:
[What must remain correct even while optimizing?]

Fallback:
[What happens when the optimized path cannot do the job?]

Proof:
[Which small benchmark or user flow will show whether the trade worked?]

This is more useful than telling AI to “keep it simple.” Simple is an opinion. A tradeoff contract gives the tool a decision boundary.

Suppose you are building a meal-planning app. Your contract might say:

Target user and job:
A busy beginner creates one editable weekly meal plan from saved preferences.

Optimize:
Time from opening the app to receiving an editable plan.

Accept:
No social feed, grocery delivery integration, or household collaboration in version one.

Protect:
Dietary exclusions must survive every generated plan and every edit.

Fallback:
If generation fails, preserve the user’s inputs and offer a manual template.

Proof:
Five test users can create, edit, save, reopen, and export one plan.

Now AI has something it can reason against. If it proposes a social feed, the contract rejects it. If it makes generation faster by dropping dietary exclusions, the contract rejects it. If the model call fails and destroys the form, the fallback rejects it.

The app is not merely smaller. It is smaller in service of a chosen result.

If you want guided language for writing that first boundary, the AI App Builder Starter Prompts are free. Use the planning prompts to define the job, exclusions, and proof, then turn the answers into your tradeoff contract.

Why tests still matter when the tradeoff is intentional

A deliberate compromise is not permission to guess.

Cloudflare used the Web Platform Tests suite to give AI agents concrete conformance goals. Humans still curated which features came next, reviewed the agents’ approaches, and added real-site and visual tests where the standards suite was not enough.

That workflow matters because optimization can cheat.

You can make a page load faster by removing the content the user needed. You can reduce a database bill by failing to save data. You can simplify onboarding by hiding every setting and leaving the user trapped in the default path.

Your proof line prevents that kind of victory.

For a beginner app, you do not need 215,000 tests. You need a compact comparison:

Record the current result for the target workflow.
Make one change intended to improve one metric.
Re-run the target workflow.
Re-run the protected behavior.
Trigger the fallback on purpose.
Keep the change only if the full trade still makes sense.

This is where AI becomes leverage instead of a slot machine. The tool can implement and measure quickly, but it cannot quietly redefine a win.

The limitation: specialization can cut the wrong thing

Kitesurf’s limitations are part of the lesson, not an embarrassing footnote.

If your task needs video, WebGL, broad pixel fidelity, a persistent authenticated session, or compatibility with a difficult site, Kitesurf may be the wrong browser today. Cloudflare’s Browser Run documentation still supports Chromium-based sessions and multiple integration methods. The fallback exists because the specialized path does not cover every job.

Your first app needs the same humility.

Do not remove a feature merely because it is expensive. Remove it only if the target user can still complete the promised job. Do not optimize a backend bill by making the app unreliable. Do not simplify a screen by hiding the one control people actually came to use.

The tradeoff contract should make a product narrower, not pointless.

What you should do next

Before your next AI coding session, stop asking for the best version of everything.

Write six lines:

the target user and job;
the result you will optimize;
the loss you will accept;
the behavior you will protect;
the fallback you will keep; and
the proof that will judge the trade.

Then ask AI to challenge the contract before it writes code. If the tool cannot explain what gets better, what gets worse, and how the user still completes the job, the build is not ready to begin.

Kitesurf is useful because Cloudflare did not pretend a browser could be cheaper, faster, lighter, more compatible, more persistent, and more visually complete all at once. It chose a job and made the exchange visible.

That is a durable beginner rule: a controlled first app is not the app with no compromises. It is the app whose compromises have names.

For the immediate guided action, AI App Builder Starter Prompts is free and helps you turn a rough idea into a bounded first build.

For the organized path from idea through scope, stack choice, prompting, QA, deployment, and publication, AI App Builder From Zero is the deeper build-along field manual.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

GitHub Copilot’s New /worktree and /rewind Commands: A Beginner’s AI Coding Experiment Checklist for 2026

Marcus Kim — Sat, 08 Aug 2026 18:39:31 +0000

On August 7, 2026, GitHub published a Copilot update that looked like a bag of small conveniences: a /worktree command for isolated code experiments, /rewind for restoring a session and its files, /side in the Copilot app, and /btw in VS Code for asking a parallel question without interrupting the main task.

I think those features point to one bigger problem in AI-assisted coding:

Exploration contaminates the real project surprisingly fast.

You ask an innocent question about a different database. The agent edits three configuration files to “show you.” You ask whether the screen would be cleaner with another navigation pattern. The agent starts refactoring the current layout. Ten minutes later, your working app has become a museum of half-decisions.

The beginner mistake is not exploring. Exploration is useful. The mistake is exploring in the same lane where your last known-good version lives.

The durable lesson behind GitHub’s update is simple: separate a question, an experiment, and a product change before you ask AI to act.

What GitHub actually changed

GitHub’s August 7 weekly release added several ways to keep work from colliding:

Copilot CLI’s experimental /worktree command creates an isolated Git worktree from the current HEAD and starts a separate conversation there.
/rewind can return a conversation and its file state to an earlier point without requiring Git in every mode.
The Copilot app’s /side and VS Code’s /btw let you ask a related question without redirecting the main task.
VS Code 1.132 also added element-level browser feedback, so a builder can point at the exact page element that needs attention instead of asking for a broad redesign.

These are not proof that an agent can safely run wild. They are controls for keeping different kinds of work separate.

If you are still turning a rough app idea into one controlled first build, my AI App Builder Starter Prompts are free. They help you define the job, boundaries, and proof before an AI coding tool starts changing files.

The three lanes I would give every beginner

You do not need enterprise process. You need three labels.

1. Question lane

Use this when you want an explanation, comparison, or second opinion but do not want files changed.

Examples:

“What are the tradeoffs between a tab bar and a navigation drawer for this app?”
“Why did this test fail?”
“Would local storage still work if I add accounts later?”

The output is knowledge. It is not permission to edit.

A side chat is helpful here because it can share enough context to answer the question without hijacking the agent’s current turn. But the tool is optional. The operating rule matters more: a question stays read-only until you explicitly promote one answer into an experiment.

2. Experiment lane

Use this when the answer must be tested in code.

An experiment should have its own branch or worktree, one hypothesis, and a discard option. The official Git documentation describes worktrees as multiple working trees attached to one repository, each with its own checked-out state. It specifically notes that a throwaway worktree is useful for experimental changes that should not disturb current development.

That is perfect for questions such as:

Can this list render 1,000 records without stuttering?
Can I replace this API client without changing the screen contract?
Does the new layout make the primary action clearer on a small phone?

The experiment exists to answer one question. It does not earn a place in the product merely because the code runs.

3. Product lane

This is your last known-good version plus changes that passed a stated check.

The product lane should be boring. It should not contain abandoned files from three possible stacks, half of a visual redesign, or a package that was installed “just to see.”

Only promote an experiment after you can name:

the user outcome it improves;
the exact files or behavior it changes;
the evidence that it works; and
the experiment files you are deliberately leaving behind.

The seven-step AI coding experiment checklist

Here is the checklist I would use before letting an AI tool explore a real app.

1. Mark the last known-good state

Before the experiment, make sure you can identify the version that currently works. For a Git project, that usually means a clean status and a named commit.

Write down one sentence:

Last known-good proof: [workflow] passed at [commit or checkpoint].

If you cannot identify the starting point, you will not know whether the experiment improved the app or merely changed it.

2. Write an experiment card

Use this tiny template:

Question:
[What are we trying to learn?]

Allowed change:
[Files, screen, component, or service the experiment may touch]

Must not change:
[Working behavior that must remain intact]

Pass evidence:
[Visible result, test, timing, or user-flow proof]

Exit decision:
[Merge, revise, or discard]

This is more useful than “try another approach.” It gives the AI a finish line and gives you a way to reject an impressive detour.

If you want guided language for defining those boundaries, use the free AI App Builder Starter Prompts and turn the relevant planning prompt into your experiment card.

3. Decide whether the task needs code

Keep comparisons and explanations in the question lane. Move to an isolated experiment only when the uncertainty requires a running result.

This sounds obvious, but AI tools make editing so easy that builders use code changes as a substitute for thinking. You do not need to install a second backend to understand its tradeoffs. You need an experiment only when documentation and reasoning cannot answer the product question.

4. Isolate the file changes

Create a separate worktree or branch before the agent edits. GitHub’s current Copilot CLI reference says /worktree leaves uncommitted changes in the current worktree and begins the separate task from HEAD.

That detail matters: isolation is strongest when the starting point is intentional. If your main workspace already contains five unrelated unfinished changes, an experimental branch does not magically clarify them.

One experiment should have one name. “test-auth-error-copy” is better than “ai-idea-4-final-new.” Your future self is already tired. Be kind to that person.

5. Ask side questions without changing the mission

During the experiment, questions will appear. Ask them without silently replacing the original goal.

Keep the experiment card visible and use this sentence:

Answer this as a side question. Do not edit files or change the experiment goal.

GitHub and VS Code now provide dedicated side-question surfaces, but this sentence works as a policy in any capable AI coding tool.

6. Review the experiment as a decision, not a demo

Run the pass evidence from the card. Then compare the experiment with the last known-good state.

Ask:

Did the target workflow improve?
Did a protected behavior change?
Did the experiment add a dependency, migration, or maintenance burden?
Can I explain the diff without asking the agent to explain its own explanation?
Would I choose this result if the code had taken a human two days to write?

That last question removes the “AI made it quickly, so we may as well keep it” bias.

7. Merge deliberately or discard completely

There are three honest outcomes:

Merge: the experiment passed and the diff belongs in the product.
Revise: the idea is useful, but the implementation or proof is incomplete.
Discard: the question was answered and the product should remain unchanged.

Discarding code is not wasted work. The experiment bought information without charging the main branch for maintenance.

Why /rewind is a recovery tool, not a backup plan

The new /rewind command sounds comforting, but GitHub’s rollback documentation includes an important warning: a Git-based rewind can restore the entire workspace snapshot, including manual edits and new files created after that point. Rewinding also removes later session history, and the rewind itself cannot be undone.

That is the tradeoff beginners can miss.

An undo button is useful. It is not a substitute for a known-good commit, an isolated worktree, or a reviewable diff.

My rule would be:

Isolate before the experiment. Rewind only when you understand what the chosen checkpoint will remove. Verify the repository afterward.

GitHub recommends checking status, the current commit, and the diff after a rollback. The larger lesson applies to every AI coding tool: never treat a recovery message as proof that your project state is correct.

What you should do next

Before your next AI coding experiment, draw three lines in your task note:

Question: What do I need to understand?
Experiment: What isolated change would prove it?
Product: What evidence would earn the change a merge?

Then refuse to skip a line.

That habit survives every tool update. GitHub may rename a command. Another AI coding tool may use sessions, branches, sandboxes, or checkpoints. The control stays the same: questions may inform experiments, and experiments may inform the product, but neither gets to become the product by accident.

For the immediate guided action, AI App Builder Starter Prompts is free and helps you turn a rough idea into bounded, testable work.

For the organized path from idea through architecture, QA, deployment, and publication, AI App Builder From Zero is the deeper build-along field manual.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

What OpenAI’s GPT-5.6 Rollout Can Teach Beginners About Choosing AI Model Effort for AI App Builds

Marcus Kim — Thu, 06 Aug 2026 18:10:53 +0000

On August 6, 2026, OpenAI rolled out a practical update that looked small on the surface and big in implication for builders like you: GPT-5.6 Sol is now in ChatGPT with multiple reasoning settings, and GPT-5.6 Luna is becoming the default for Free and Go users.[^1] The same update also added a dedicated Think flow for harder questions on some plans and made the newer reasoning model available as a real, selectable option for paid users instead of just a hidden behavior.

The line I noticed came from the same release: ChatGPT now gives you multiple levels of reasoning effort, while Work and Codex are not changing in that update.[^2] That may sound like product detail noise, but for beginner builders it is the core lesson:

Model choice is not just "better vs worse". It is a control decision.

If you want a clear starting point before your first AI build, use the AI App Builder Starter Prompts first—these prompts are free and force you to define intent, scope, constraints, and success tests before your model starts iterating for you.

What actually changed on August 6, 2026

I won’t call the update a revolution. It is better described as a better operating interface for a familiar problem:

OpenAI introduced a new family with Sol, Terra, and Luna roles for different cost and speed positions.
In chat, users can move from default behavior to more deliberate reasoning modes.
For many users, Luna becomes the cheaper/high-volume default path while Sol handles harder reasoning.
At the API layer, model availability differs by product and plan, and Luna appears as a cost-efficient model for suitable work.[^3][^4]

If you’re building with AI every day, this is familiar territory. You already allocate money between dev tools and hosting; now you are also allocating model effort. But beginners frequently make this mistake: they optimize only for speed or novelty and leave reliability as an afterthought.

The more useful way to think about it is as a build pipeline:

Fast mode (low reasoning) is great for drafting and small repetitive work.
Higher reasoning is for architecture decisions, edge cases, and code paths where one wrong assumption becomes user-visible damage.
Higher cost and slower modes should be reserved for the irreversible moments.

That is the same principle I use when writing production scripts or database migrations.

Why beginner builders usually misunderstand model controls

Most beginners hear about advanced model modes and think they are merely a “quality slider.” I think the deeper misunderstanding is this: model controls are treated like UI preferences, not like engineering controls.

Here is what I see repeatedly:

Start with high reasoning because “I want better answers.”
Hit speed limits or token caps.
Spend more time switching models than adding tests.
Lose traceability because every response is a different quality/cost strategy.

In other words, you are making model settings a post-hoc reaction instead of a pre-planned policy.

That becomes expensive quickly, especially when building full-stack features.

When I worked on prior projects, the most stable AI workflows were built around a simple guardrail: do not let one pass of the model own a critical action by itself. For example, for a checkout flow, authentication layer, or migration script, I ask for:

first-pass implementation,
concise reasoning summary,
a manual quick test checklist,
only then the version that may affect real users.

You can reuse the same structure now with model effort.

The transfer from model rollout to your app architecture

The GPT-5.6 launch is useful because it mirrors the same architecture decision you already need for any builder:

Who should run with default behavior?
Who can run with high effort?
Who is allowed to touch irreversible state?

If you build an app feature using an AI assistant and skip this question, you’re effectively giving your “draft mode” and your “publish mode” the same key.

That is exactly the beginner trap I saw in many fast builds last year: we spend effort optimizing the first response quality and then skip the separate verification gate.

Your job is not to choose one perfect model for everything.

Your job is to assign each task a reasonable budget:

use cheaper/fast modes for exploration,
use stronger reasoning for schema, security-sensitive logic, and cross-file changes,
use the strongest mode only when the output is about to cross a user-facing boundary.

I would call this effort stratification.

A practical lesson: choose by consequence, not by habit

When GPT-5.6 was announced, it was tempting to call it a “smarter model” update only. But the practical lesson for you is older and sharper: you should make consequence the first axis.

Ask this before coding:

What is the exact consequence if this output is wrong?
How expensive is a revision if it is wrong?
How easy is rollback?

If you can answer those three questions, model selection is no longer random. For a beginner builder, that means:

a safe mode task (notes, scaffolding, small components) can use default response behavior,
a decision task (data relationships, authentication flow, migration logic) gets higher reasoning,
a launch task (payment flow, permissions, publish pipeline) gets your strictest review and the most expensive reasoning mode you are willing to pay for.

The release notes say the Work experience has specific model availability behavior and that the chat layer does not change all modes at once.[^2] That split is important because it tells you OpenAI is building this as a product of contexts, not one monolithic “best model for everything.”

For beginner app projects, that context split is healthy.

I have a phrase I use in my own planning prompts: prepare cheaply, validate carefully, execute only when the cost of failure is accepted.

The tradeoff you cannot skip

There is a tradeoff in every model strategy:

High reasoning can improve quality, but it increases cost and can increase response latency.
Low effort is fast and cheap, but it can overfit to likely answers and miss hidden assumptions.

So the point is not “pick the highest reasoning model always.”

The point is to use the tool’s own cost/quality knobs as part of your architecture, the same way you choose test environment, deployment strategy, and data model.

When you do this well, your AI-assisted workflow becomes repeatable:

you get faster first drafts,
cleaner checkpoints,
fewer emergency rewrites after wrong assumptions,
and a clearer signal when to ask for human review.

A beginner workflow you can use this week

To turn this from theory into a habit, try this minimal 5-minute workflow:

Start with a one-sentence goal.
Map each output into one of three consequence buckets: Draft, Validate, or Release.
Assign model effort by bucket (fast defaults for Draft, high reasoning for Validate, strongest for Release candidates).
Record your choice in your task notes.
Require a visible check before moving draft output into release.

If you want a scaffold for that structure, use the AI App Builder Starter Prompts first—they are free and they force a project plan before generation starts.

If you want the full build-and-launch flow—from idea to architecture, QA, and publishing—in one path, AI App Builder From Zero gives you the context and workflow layers that make these model choices sustainable.

What to do next, as a builder

Don’t wait for your next “bigger model” upgrade to fix your process. The upgrade just exposed a clearer control surface.

Before your next coding session, make three explicit decisions in writing:

Which tasks deserve default chat behavior,
Which tasks require deliberate reasoning,
Which tasks require the strongest reasoning and a manual release gate.

This gives your AI assistant less freedom than you think—and more speed where it matters.

If you do nothing else after reading this, at least add a one-line preface in your own prompts: “Use low-effort mode for drafts, high-effort mode for decisions, and verify before release.” That one sentence is small, but it is the beginning of a real builder discipline.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

npm's New 2FA Token Rules: What Beginner AI Builders Should Learn About Permissions in 2026

Marcus Kim — Mon, 03 Aug 2026 18:37:38 +0000

The most dangerous sentence in an AI-assisted project is not “the code failed.”

It is “the code worked, so I gave the tool access to everything.”

On July 31, npm restricted what granular access tokens configured to bypass two-factor authentication can do. Those tokens can no longer perform sensitive actions such as creating or deleting tokens, changing package access, adding maintainers, or changing trusted-publishing settings. npm says those operations now need an interactive 2FA challenge.

I did not find a more substantial AI or developer-tool development in the previous 24 hours, so I widened the search window to seven days. This change happened three days ago.

npm also previewed the next boundary. It plans to remove direct publishing from those bypass-2FA tokens in January 2027. Automation will still be able to read private packages and stage a release, but a maintainer will approve the public release with 2FA.

That is not just a package-registry detail. It is a useful operating model for anyone building with AI:

Let the tool prepare the irreversible action. Do not automatically let it own the irreversible action.

What actually changed

The immediate change applies to npm granular access tokens, not every kind of GitHub or npm credential. A bypass-2FA token can no longer use its convenience to become an account-management master key.

That closes a nasty chain of possibilities. If an attacker obtained one of those tokens, the token could previously help change maintainers, create more credentials, or alter package access. The problem was not only that the credential had power. It could use that power to create more power.

The planned publishing change makes the separation even clearer:

Automation may build and stage a package.
A human maintainer sees what is about to become public.
A separate authenticated approval promotes it.

npm's trusted-publishing documentation recommends short-lived, workflow-specific OIDC credentials instead of long-lived publishing tokens. It also describes a stage-only configuration built around staged publishing, in which CI may prepare a release but a maintainer must approve it with 2FA before publication.

The exact npm setup will not apply to every app. The durable structure does.

What beginners may misunderstand about AI permissions

The npm change is about package credentials, not AI coding agents. I am applying its release model to AI-assisted work because the permission problem is the same: a system that can prepare a change does not automatically need the authority to make that change public, bill a customer, delete data, or alter account access.

Beginners often treat permissions as a binary switch:

the AI can do nothing, so every step is slow
the AI can do everything, so every step is exciting right up until it becomes a crime scene with excellent autocomplete

There is a better middle.

Give the tool enough access to create evidence. Keep a separate gate for actions that are difficult to reverse.

Before you connect more tools, I made the AI App Builder Starter Prompts free so you can name the user workflow, scope, data, constraints, and proof the AI should produce first.

The three-gate workflow: prepare, prove, release

I would divide an AI-assisted release into three gates.

Gate 1: Prepare

At this gate, the AI can do a lot.

It can inspect the repository, edit code, run local tests, generate a build, draft release notes, create a migration plan, and stage a deployment candidate. It can also explain the files it changed and the assumptions it made.

But “prepare” should end in a reviewable artifact, not a public consequence.

For a web app, the artifact might be a preview deployment. For a mobile app, it might be an archive or internal test build. For a package, it might be a staged version. For a newsletter, it might be a filled draft with no send permission.

The tool's job is to move the work from vague intent to inspectable candidate.

Gate 2: Prove

Now the candidate has to earn promotion.

Proof should match the risk. A button-color change may need a screenshot and a quick viewport check. An authentication change may need two accounts, expired-session behavior, password recovery, and permission tests. A database migration needs a backup, a dry run, row-count checks, and a rollback path.

For most beginner app releases, I would ask for five pieces of evidence:

Change summary: what changed in user language.
Automated checks: which tests, builds, or linters passed.
Manual journey: which real user path was completed from start to finish.
Failure check: what happened with bad input, missing data, or an unavailable service.
Rollback note: how to return to the last known-good state.

Your AI coding tool can help produce all five. It should not get to mark its own homework merely because the output contains green checkmarks.

Gate 3: Release

Release is the shortest gate and the most protected one.

The release identity should have only the permissions required for that release. Prefer short-lived credentials when the platform supports them. Require a separate confirmation for the action that changes the outside world.

That might mean:

promote a staged package
deploy the verified commit to production
submit the tested build to an app store
run the reviewed database migration
send the approved email campaign
switch a payment integration from test mode to live mode

The important word is reviewed. Release should point to the exact candidate that passed Gate 2. If the code changes after review, it goes back through proof.

A beginner permission table

You do not need an enterprise security department to start. Write a small permission table for your project.

Action	AI may prepare	AI may execute in test	Separate approval for live
Edit application code	Yes	Yes	No live effect
Run local tests	Yes	Yes	No
Create preview deployment	Yes	Yes	No
Read production secrets	No	No	Not needed for normal work
Change account owners or maintainers	No	No	Yes
Run destructive data migration	Draft only	On disposable test data	Yes
Publish a package or app	Stage only	Internal/test channel	Yes
Charge a real customer	Prepare test request	Test mode only	Yes

This table is not universal. Your app may need different rows. The point is to stop permissions from being accidental.

Ask three questions about every tool connection:

What useful evidence can this permission create?
What damage could it create if the instruction or credential were wrong?
Can the live action be separated from preparation?

The free AI App Builder Starter Prompts are useful here because the same scope and QA prompts can define what the tool may prepare and what proof you expect before release.

Why approval pauses are a productivity feature

People hear “human approval” and imagine a committee meeting where twelve people discuss a button for six weeks.

That is not the goal.

A good approval gate is narrow. The tool has already done the slow work. The human is answering a small question with visible evidence: Is this exact candidate allowed to cross this exact boundary?

GitHub applied a similar idea on July 28 when it announced that certain potentially malicious GitHub Actions workflows in public repositories would be held for approval. The workflow does not run until a collaborator with write access approves it through an authenticated web session.

The pause is valuable because it sits immediately before execution. It does not require a person to manually rebuild the whole workflow.

That is how I want approvals in a small AI-assisted project to feel: a speed bump before the cliff, not a parking lot at the beginning of the road.

The tradeoff: too many gates create permission theater

You can absolutely overdo this.

If every local test, preview build, typo fix, and reversible change needs manual approval, people will click through prompts without reading them. A gate that fires constantly becomes wallpaper.

The other limitation is that approval does not prove the candidate is safe. A human can approve the wrong commit, misunderstand the evidence, or miss a malicious dependency. Two-factor authentication protects the approval identity; it does not review the code for you.

That is why the three gates have different jobs:

preparation creates the candidate
proof creates the evidence
release controls the consequence

Do not use the release gate as a substitute for testing. Do not use testing as a reason to hand every credential to the build tool.

What you should do next

Pick one live action in your project: production deployment, database migration, package publication, app-store submission, email send, or payment activation.

Write down:

what the AI may prepare
what it may execute in a test environment
which evidence must exist
who or what can approve the live step
how the release identity gets its credential
how you roll back

Then remove any permission the preparation step does not need.

You do not have to make your workflow slow to make it controlled. You want the AI doing the broad, repeatable work and a narrow verified identity owning the irreversible moment.

If you want the immediate guided action, start with the AI App Builder Starter Prompts, which are free. If you want the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering scope, stack, project rules, QA, deployment, and launch.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

GitHub Models Shut Down: What Beginners Should Learn About AI Vendor Lock-In

Marcus Kim — Sun, 02 Aug 2026 19:20:14 +0000

An AI feature can look permanent right up until the provider removes the sign from the building.

GitHub Models reached that moment on July 30. GitHub had announced that the playground, model catalog, inference API, and bring-your-own-key endpoints would all be retired for existing customers, not just closed to new ones.

I did not find a more substantial AI or developer-tool development in the previous 24 hours, so I widened the window to seven days. The shutdown happened three days ago.

GitHub pointed developers toward Microsoft Foundry for model access or GitHub Copilot for AI workflows inside GitHub. That is a reasonable migration path. But the useful beginner lesson is bigger than which replacement you choose:

An outside AI service should power a feature. It should not become the shape of your entire app.

Yesterday I wrote about choosing an AI coding model by matching it to your bottleneck. This is the next architectural question. Even a sensible model or service choice can change, become more expensive, lose a feature, move to a different product, or disappear.

You do not need an enterprise architecture team to prepare for that. You need one replaceable seam.

What actually changed

GitHub's retirement notice was unusually concrete. After July 30, the GitHub Models interface and API would no longer be available, including BYOK. GitHub even ran brief service interruptions before retirement so developers could see what failure would look like.

That last detail matters. A brownout is not only an inconvenience. It is an architecture test.

If one AI endpoint fails and your whole app becomes unusable, the app probably knows too much about the endpoint.

The same problem appears with payments, maps, email, analytics, storage, and authentication. AI services just make it easier to ignore because the first integration can be so fast. You install a package, paste a key, call a model from a screen, and celebrate when text appears.

Then the prototype becomes the product, and the shortcut becomes structural steel.

What beginners often misunderstand about vendor lock-in

Vendor lock-in does not mean “using a vendor.” Every useful app depends on other people's software.

The problem begins when provider-specific details spread everywhere:

model names live inside UI components
API calls are copied across several screens
provider response objects become your app's data model
error messages are shown directly to users
prompts are mixed into button handlers
there is no record of what the feature is supposed to return

Now changing providers is not one integration task. It is an archaeological dig.

The opposite extreme is also a mistake. A beginner can spend two weeks building a grand multi-provider framework before proving that one user wants the feature. That is architecture cosplay.

The goal is smaller: put the unstable dependency behind the narrowest useful contract.

If you are still turning a rough app idea into one buildable workflow, I made the AI App Builder Starter Prompts free so you can define the user, outcome, inputs, constraints, and proof before choosing an AI service.

The one-seam workflow

Imagine you are building a note app with a feature that turns a long note into three action items.

The user journey is simple:

The user opens a saved note.
The user presses “Find action items.”
The app returns zero to three short action items.
The user can accept, edit, or discard each one.
The original note never changes unless the user confirms it.

That is the product contract. None of it requires the screen to know the provider, model name, SDK, or raw response format.

Here is how I would keep the integration replaceable.

1. Name the capability in product language

Call it something like extractActionItems(noteText).

Do not name the main function after the vendor. The rest of the app cares about the outcome, not which company produced it.

2. Define your own input and output

The input might be:

note text
maximum number of items
language

The output might be:

an array of action-item strings
a status such as complete, empty, or unavailable
a safe message the UI can show

Your app should validate that result before the screen sees it. A provider's response object is evidence arriving at the border, not your internal constitution.

3. Put the provider call in one adapter

One server route, service file, or backend function owns the provider SDK and model identifier.

The UI calls your capability. Your capability calls the adapter. The adapter translates the outside response into your output shape.

That is the seam.

Vercel's AI SDK documentation describes this same broad idea through a standardized language-model interface. Its provider-management guide goes further with a central registry, aliases, and multiple providers. You do not have to use that library. The important design lesson is centralization: switching should happen in one known place.

4. Keep secrets and model IDs out of the client

Do not ship provider secrets in a browser or mobile app. Keep them on the server or in a secure backend function.

Also keep the chosen provider and model in configuration rather than scattering them across feature code. A model change should not require editing five buttons and three screens.

5. Save three fixtures

Keep three small examples that represent the feature:

a normal note with two clear action items
a note with no action item
a messy note that could tempt the model to invent one

For each fixture, write the acceptable result. When you change a prompt, model, or provider, run the same fixtures again.

This is not a perfect benchmark. It is a product-specific migration test.

6. Design the unavailable state

Decide what the user sees when the provider times out, rejects the request, reaches a limit, or disappears.

For the note app, the rest of the product should still work. The user can read and edit the note. The action-item feature can say it is temporarily unavailable without corrupting data or trapping the user behind a spinner.

GitHub's pre-retirement brownouts are a good reminder: test the failure while you still control the timing.

7. Write a one-page exit note

Record:

where the provider is called
which environment variables it needs
the input and output contract
the three migration fixtures
which provider-specific features you rely on
what the user experiences during an outage

That note is enough to keep a future migration from starting with “Where is this thing even wired in?”

A practical provider-exit test

You can ask your AI coding tool to inspect the project and answer these questions without changing code:

Where does the app call the AI provider?
How many files contain provider or model names?
Does the UI import the provider SDK directly?
Does provider output flow into stored app data without validation?
What still works if every AI request fails for an hour?
What is the smallest boundary that could contain the dependency?
Which three fixtures would prove a replacement behaves well enough?

Then ask for a migration plan with one constraint: preserve the user journey and change the fewest product-facing files possible.

The free AI App Builder Starter Prompts can help you define that workflow and its proof before the tool starts moving code around.

The tradeoff: abstraction can hide useful differences

A provider boundary is not free.

Different models and services support different tools, context sizes, structured-output behavior, safety controls, latency, and pricing. If you force every provider into the lowest common denominator, you can lose the feature that made your first choice valuable.

That is why I would not pretend all providers are identical.

Keep the product contract stable, but allow provider-specific settings inside the adapter. If one provider supports a useful capability, use it deliberately and document it in the exit note. Your replacement may need a different implementation as long as it preserves the user outcome.

Routing layers can also help, but they introduce another dependency. Vercel's AI Gateway routing rules, for example, can rewrite requests from one model to another without an application code change. That can improve recovery, but it does not remove your responsibility to verify that the destination still produces an acceptable result.

The rule is not “never depend on anything.”

It is “know where the dependency ends and your product begins.”

What you should do next

Pick one outside service in your app. It can be AI, email, payments, maps, or storage.

Draw three boxes:

Your screen -> Your capability -> Outside provider

If you cannot draw those boundaries because provider details appear everywhere, do not rewrite the whole project tonight. Choose one user workflow, write its input and output, move the outside call behind one seam, and save three fixtures.

That is enough architecture for a first migration plan.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

How To Choose An AI Coding Model For Your First App In 2026

Marcus Kim — Sat, 01 Aug 2026 18:39:12 +0000

The newest AI coding update is often treated like a shopping event.

A new model arrives. A coding tool adds another model picker. A benchmark chart moves. Then you are left wondering which button to press before you build your first app.

That confusion is understandable. On July 28, GitHub said Grok 4.5 was rolling out in GitHub Copilot for fast, agentic coding and complex multi-step work. On July 29, GitHub announced that Copilot code review support for agent skills and MCP servers was generally available. OpenAI's July 9 GPT-5.6 launch also put multiple capability and cost tiers into one family, including programmatic tool calling and multi-agent options.

Those are meaningful developments. But the beginner lesson is not “always use the newest model.” It is this:

Choose the model that matches your current bottleneck, then prove the choice on a small task.

I have watched AI-assisted projects lose days to model comparison when the real problem was an unclear feature, an unverified data flow, or a missing test. A model can be excellent and still be the wrong choice for the job in front of you.

What changed in the model-picking problem

The old question was simple: “Which assistant writes the best code?”

The current question has more dimensions:

Do you need fast autocomplete or a long-running agent?
Do you need careful reasoning or cheap iteration?
Can the model use your repository, browser, terminal, review rules, or external tools?
Is the task code generation, debugging, planning, review, or release preparation?
What is the cost of being wrong?

The recent releases make those tradeoffs more visible. GPT-5.6 describes different tiers, tool coordination, and parallel agents. GitHub's Copilot updates add more model choice inside an existing development workflow and give code review more context through skills and MCP.

The practical result is that “best model” is no longer a useful beginner category. “Best for this next proof” is better.

What beginners often misunderstand

More capability does not automatically mean more progress.

If you ask an agent to build a vague app with the most powerful setting, it may produce more files, more abstractions, and more decisions than you can inspect. The output can look impressive while making the project harder to own.

The opposite mistake is choosing only on price. A cheaper model may be perfectly good for renaming variables or generating a first draft, but expensive mistakes in authentication, payments, permissions, or data migration can erase the savings.

So I use a simple rule: model selection is a risk decision, not a popularity contest.

The beginner decision checklist

1. Name the task before naming the model

Write one sentence:

“I need help with [task] so that [user outcome] can be verified by [evidence].”

Examples:

“I need help designing a small database so a signed-in user can save one note and retrieve it tomorrow.”
“I need help fixing a failing form so an invalid email shows an error without losing the user's other input.”
“I need help reviewing a pull request so I can test the changed checkout path and its permission boundary.”

If you cannot finish that sentence, you do not have a model-selection problem yet. You have a task-definition problem.

2. Identify the bottleneck

Pick one primary bottleneck:

Speed: you need a quick draft or small transformation.
Reasoning: the task crosses several files or has competing design options.
Context: the answer depends on a larger repository or project history.
Tool use: the agent must inspect, run, or coordinate several steps.
Cost: you need many safe iterations on low-risk work.
Review: you need a second pass focused on failure modes.

Do not pick every bottleneck. A first app becomes hard to manage when every task is labeled “complex.”

3. Match the tool to the risk

For low-risk work, use the fastest affordable option that produces a clear diff: naming, formatting, a small component, a test stub, or a documentation pass.

For high-risk work, pay for better reasoning and spend more time on evidence: authentication, permissions, payments, migrations, external APIs, and anything that can expose or delete user data.

For repository-wide or tool-heavy work, choose a workflow that can see the relevant project context and show you what it changed. The feature that matters is not “agent” by itself. It is the ability to inspect the plan, diff, commands, and proof.

4. Run a same-task trial

Give two candidate setups the same small task. Keep the prompt, repository snapshot, and acceptance checks identical.

Score each result from 0 to 2:

Check	0	1	2
Correct user outcome	missed	partly works	works in the stated flow
Scope discipline	wandered	some extras	changed only what was needed
Explainability	unclear	partial explanation	clear files, assumptions, and tradeoffs
Verification	no proof	one happy-path check	happy path plus a relevant failure check
Recovery	hard to undo	possible with effort	small, reviewable diff

The highest total is not automatically the winner. If a cheaper setup scores 9 on a low-risk task and a more capable one scores 10, the cheaper option may be the better operating choice. If the task involves permissions and both skip the important check, neither is ready.

5. Keep a model decision log

For each meaningful task, record:

task type
chosen model or tier
expected bottleneck
what it changed
what it got wrong
how you verified it
whether you would choose it again

This turns model selection into evidence instead of vibes. After a few tasks, you will know which setup helps you plan, which helps you debug, and which is only good at producing plausible first drafts.

Why this lesson lasts longer than the release cycle

The names and prices will change. The decision stays useful because every AI coding tool eventually asks you to trade speed, cost, context, autonomy, and confidence.

The durable skill is not memorizing the current winner. It is building a small feedback loop:

Define the user outcome.
Choose one bottleneck.
Run a bounded task.
Inspect the diff and the evidence.
Keep or change the tool based on what happened.

I made the AI App Builder Starter Prompts free because this is the kind of setup work beginners should be able to practice immediately. The starter prompts are free, and they help turn an app idea into a bounded first workflow before you ask an AI tool to build it.

The tradeoff and limitation

Benchmarks and launch announcements can tell you what a vendor measured. They cannot tell you whether a model understands your app, your users, your constraints, or your tolerance for risk.

Your own trial can also mislead you if the test is too easy. A model that writes a clean button is not automatically the model you should trust with authorization logic. Test the kind of failure you care about, not only the kind of demo that makes the tool look good.

There is also a human cost. Switching models constantly can interrupt your understanding of the project. For a first app, consistency and a readable change history may be worth more than chasing a small benchmark advantage.

What you should do next

Take the next feature in your app and write the one-sentence task. Circle its bottleneck. Choose one model setup and run a small slice that can be reviewed in fifteen minutes.

Then ask the AI to show you:

the files it changed
the assumptions it made
the test or manual proof it ran
one failure case it did not cover
the easiest rollback path

That is a better first experiment than asking which model is “best.”

If you want the immediate guided action, start with the AI App Builder Starter Prompts, which are free. If you want the organized path from idea to publication, the deeper next step is AI App Builder From Zero, my $19 field manual for building and shipping a first app with AI.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

What GitHub Copilot's New July 2026 Agentic Review Features Can Teach Beginners About Trust in AI Coding

Marcus Kim — Thu, 30 Jul 2026 18:12:47 +0000

The biggest shift in AI-assisted coding lately is not that tools can write code faster.

It is that they can now write reviews faster too.

On July 29, 2026, GitHub announced that Copilot code review gained GA support for agent skills and MCP-style integrations. In plain terms, AI can now read a larger chunk of your project context and run more structured checks without you manually typing every command.

That is useful, especially for you if you are building your first real AI-assisted app.

The change sounds great. It also sets a trap for beginners: when the agent starts doing more, you might start doing less.

That’s where the hidden lesson is.

I have worked long enough with AI in public coding to know this pattern. We used to ask AI to “just build this” and then spent too much time cleaning after. Now we ask AI to build and review, and beginners can spend too little time on ownership. The skill is not to eliminate your judgment. The skill is to move your judgment earlier.

What actually changed

Before this update, many AI coding workflows felt like this:

Ask the assistant to build a feature.
Spot-check the output.
Hope it is coherent.

Now you can configure a model that does both code generation and review logic with more context through skills and MCP integrations. That gives you a second AI voice in the loop, not just one.

In 2026, that matters because beginners get less excuse to skip process. If an AI can generate files, it can also generate a decent-looking suggestion list.

The beginner misunderstanding: “If a review exists, I don’t need a plan"

A common beginner mistake is to treat automation like a maturity badge.

You don’t ship safely because a review model exists.

You ship safely because you defined:

What counts as a good implementation.
What failure modes matter to your specific app.
Who signs off.
How to prove the change works before users see it.

When I see beginners ask why they still need review when the AI can review, I use the same response every time:

“An AI can propose checks. You still need to define the checks.”

And that means you need a small, written contract before code starts moving.

The practical lesson: write a reviewer contract before the first code prompt

I use this contract for my own work and for this article’s lesson:

1) Outcome statement

What exact user outcome should this change prove in one minute?

For a beginner app, this is often one workflow:

User signs in.
User saves one meaningful record.
User sees success state.

If you can’t state that outcome in one sentence, you don’t yet have a build task.

2) Scope boundary

What should not happen?

If your feature adds one happy path and accidentally changes another, your app looks “working” while your support queue grows.

Name the boundary explicitly:

Which screens are in scope.
Which data paths are allowed to change.
Which external integrations must not run.

3) Evidence checklist

A code review suggestion is not proof until you verify evidence locally.

Before code is merged, check:

At least one happy path with real sample data.
One failure path.
A security or permissions path.
One neighboring workflow that could break.

4) Ownership and rollback rule

If Copilot can make many edits quickly, your rollback path must be quick too.

When I work with beginner projects, I keep one rule visible: “If no reviewer and no quick rollback, pause and simplify.”

That keeps AI output from becoming an irreversible commit.

Why this lesson stays useful after the news passes

This is the part I care most about.

The update itself is useful, but the durable lesson is bigger: AI-assisted coding gets safer when your project has explicit controls.

For a beginner, the wrong assumption is that new features in your tools remove the need for architecture basics. The right assumption is that new tools make those basics non-negotiable.

I made AI App Builder Starter Prompts free on purpose. They help you define outcomes, constraints, and done-when rules before the assistant starts changing files. The prompts are free.

If you already have a running project, this is where you begin:

Add a simple AGENTS.md-style note for your own style and guardrails.
List the five checks your first AI build must pass.
Ask the AI to generate only the code and review artifacts that directly support those checks.

That is the opposite of prompt dumping. It is controlled leverage.

The tradeoff and limitation

Agentic tools improve with visibility, but they still create a false sense of completion.

The limitation is real:

Reviews can be useful and still miss edge cases.
Context can be incomplete.
Automation can optimize for speed and still move in the wrong direction.

That is why your biggest beginner protection is not “more tools.” It is a tiny habit:

Every claim must pass your own test before you trust it.

You do not need a giant enterprise process. You need one clear proof path.

What you should do next

For your next AI coding task, add one line before the first prompt:

“Do not mark this complete until [one user flow], [one failure path], and [one ownership decision] are verified.”

Then only run the first change.

For app builders trying to move from prototype panic to shipping confidence, this is the bridge:

Starter prompts are the immediate action: AI App Builder Starter Prompts (free)
The full field manual is the next step for repeatable outcomes: AI App Builder From Zero

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

What OpenAI's New Task-Crossover Research Can Teach Freelancers About Owning the Handoff in 2026

Marcus Kim — Tue, 28 Jul 2026 04:37:12 +0000

The most useful line in today's AI news is not that AI can do more work.

It is that AI is changing who does the work.

In a new OpenAI Economic Research report, researchers analyzed more than 800,000 work-related messages from U.S. ChatGPT users. They found that 16.8% of work-related messages crossed into tasks associated with another occupation. When generic tasks such as writing, summarizing, and scheduling were removed, 43.5% of occupation-specific messages were outside the user's own occupation.

That is a meaningful shift for freelancers and small teams. A marketer can troubleshoot a website. A small-business owner can do a first pass on financial analysis. A salesperson can explore customer data. The person who first encounters a problem can often make progress before waiting for a specialist.

But there is a trap hidden inside that freedom: crossing a role boundary is not the same as owning the result.

The new freelancer advantage is range

I have never thought of freelancing as staying inside one perfectly labeled job description. A client does not experience a project as “design,” “development,” “copy,” and “QA” in separate boxes. They experience a user trying to complete something and either succeeding or getting stuck.

AI makes it easier for one freelancer to move across those boxes. You can draft the page copy, ask AI to turn the workflow into a rough interface, inspect the data shape, write a test plan, and prepare a launch checklist. That range can make a small project much more useful.

OpenAI's research supports the direction of travel. Its examples show engineering and marketing tasks moving across many occupations, and it found more outside-occupation work among smaller workspaces than among workspaces with more than 100 seats. That makes intuitive sense: when there is no analyst, QA team, or developer sitting two desks away, the person closest to the problem has to make the next useful move.

The opportunity is not “become every specialist.” The opportunity is “reduce the number of blocked handoffs.”

I made AI App Builder Starter Prompts for this kind of first move. The starter prompts are free, and they help turn a rough app idea into a defined user, workflow, scope, and first build before the tool starts generating screens.

The handoff is where projects lose trust

The danger is not that a freelancer uses AI outside their formal specialty. The danger is that nobody can answer what happens next.

AI can give you a plausible first draft of a landing page, a database query, a test case, or an integration. A plausible first draft is valuable. It is not yet a deliverable.

The work becomes accountable when you can answer five questions:

Who is the user of this output?
What decision or action should it enable?
What must remain true when it reaches the next person or system?
What can fail, and how will we notice?
Who owns the final call?

Those questions are a small operating system for cross-functional work. They keep “I used AI to help with that” from becoming a substitute for “the result is ready to use.”

This distinction matters even more as agents take on longer tasks. OpenAI reports that users are moving from short interactions toward work that can take more than an hour or much longer. In another July report about scientific work, OpenAI described the need to pair models with tools, workflows, expertise, infrastructure, and human validation. The pattern is consistent: more capability increases the value of a well-defined boundary around the work.

A workflow I use for crossing roles safely

When I need to work across a boundary, I use a five-part handoff note before I ask AI to produce the next artifact.

Outcome. Write the sentence the user should be able to complete. “The owner can see which leads need a follow-up today” is better than “build a dashboard.”

Input. Name the actual source: a form submission, CSV, API response, customer interview, or existing screen. If the input is vague, the output will be vague too.

Constraint. State the boundaries that matter: permissions, platform, deadline, budget, brand rules, privacy, or what is explicitly out of scope.

Proof. Define the evidence that makes the work believable. That might be a screenshot of the empty state, a test with two user accounts, a saved record, a failed API response, or a client demo using realistic data.

Owner. Name the person who decides whether the result is ready. The owner does not have to personally perform every task. They do have to notice when the output is incomplete and choose what happens next.

Here is a concrete example. Instead of asking, “Can you make me a lead dashboard?” I would write:

A sales freelancer needs to identify today's follow-ups from submitted leads. The input is the existing lead table. The first version shows name, last contact date, status, and next action. A user can mark a follow-up complete and see that state after refresh. A second user must not see private notes. Proof is a two-account test plus an empty-state screenshot. I own the workflow decision; AI can help with the interface and test cases.

That note gives AI room to help without giving it permission to invent the product.

What this does not mean

Task crossover is not proof that expertise no longer matters. It is not a reason to skip review, hire no specialists, or let an AI-generated answer cross into production because it looks polished.

The recent OpenAI and Hugging Face security disclosure is a useful reminder. During an internal evaluation, models chained vulnerabilities and reached information in a production environment. The companies described containment, monitoring, access controls, patching, and forensic investigation as necessary responses. The limitation is important: a sandbox is a boundary, but a boundary that nobody monitors is only a hope.

The same principle applies to a small freelance app. AI can expand your range, but you still need permissions, review points, tests, and a recovery path. The smaller the team, the more deliberately those controls need to be written down.

Your next move

Pick one recurring handoff in your work this week: copy to design, design to development, development to QA, or a client request to a delivery plan.

Write the five-part note: outcome, input, constraint, proof, owner. Then use AI to help with the next artifact, not to decide what “done” means. Afterward, compare the generated work with the proof you promised.

That is the durable lesson in today's task-crossover news. AI can make you more useful across a project. Judgment is what keeps that usefulness from becoming a new source of confusion.

If you want a more organized path from idea to publication, AI App Builder From Zero takes the same principle through the full build: define the idea, choose the smallest useful version, build in stages, test the result, and publish it.

The free starter prompts are the immediate guided action. The e-book is the deeper path when you want the complete system in one place.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

How To Know Whether AI Fixed The Bug Or Hid The Bug In 2026

Marcus Kim — Sat, 25 Jul 2026 20:48:43 +0000

The most dangerous sentence in an AI-built app is often:

The bug is fixed.

That sentence can mean several different things:

the original symptom disappeared;
the error message was hidden;
the failing path was bypassed;
the code now handles one example but not the workflow; or
the change fixed one screen while quietly breaking another.

I have learned to treat an AI-generated bug fix as a claim that needs evidence, not as a conclusion.

The beginner-friendly rule is this:

A bug is fixed only when the original failure is gone, the intended behavior works, and the nearby behavior still works.

That is a small regression test. You do not need a large QA department to run it. You need a clear before-and-after record.

If you are staring at a blank prompt box, my AI App Builder Starter Prompts are free and include prompts for scope, debugging, QA, deployment, and launch. The useful part is not asking AI to sound confident. It is making the proof request specific.

First, Capture The Bug Before Changing Code

Before asking AI to fix anything, write down the smallest reproducible version of the failure.

Use this format:

Starting state:
[what must already be true]

Actions:
1. [action]
2. [action]
3. [action]

Expected result:
[what a user should see or be able to do]

Actual result:
[what happens instead]

Evidence:
[error text, screenshot, console output, or saved record]

For example:

Starting state: I am signed in and have one saved task.
Actions: open the task, edit its title, press Save, refresh the page.
Expected result: the new title remains after refresh.
Actual result: the screen says Saved, but the old title returns.
Evidence: the network request succeeds, but the database record is unchanged.

That description is much more useful than “Saving is broken.” It gives AI a path, an expected outcome, and a place to look for false success.

The Four Proofs Of A Real Fix

When AI proposes a patch, I want four separate proofs.

1. The original reproduction now passes

Run the exact same starting state and actions. Do not paraphrase the steps because the patch may only work under a slightly different condition.

If the original reproduction cannot be run anymore, ask why. Sometimes the code change genuinely changed the workflow. Sometimes the test data disappeared. Sometimes the error was hidden. “I cannot reproduce it” is not the same as “it is fixed.”

Record the result plainly:

original steps: pass or fail;
expected result: observed or not observed; and
evidence: screenshot, saved record, test output, or visible state.

2. The data or state is correct underneath

Screens can lie by being polite.

A toast that says “Saved” does not prove that the record was saved. A blank error area does not prove that an invalid request succeeded. A loading spinner that stops does not prove that the correct result arrived.

Check the state behind the screen using the safest visible tools available to your project:

refresh the page;
close and reopen the app;
sign out and back in when ownership matters;
inspect the visible record in the database dashboard if that is part of your workflow; or
run the project’s existing test or logging command.

The question is: did the promised state change persist in the place where the product actually owns it?

3. The failure is still honest when it should fail

A real fix does not turn every input into a success message.

Try one invalid input, one missing value, one offline or timeout condition, or one unauthorized account when the bug involves those boundaries. The exact test depends on the feature, but the principle is stable: the app should fail clearly and safely.

If AI changed a validation error into an empty result, it may have hidden the bug. If it catches every exception and returns a generic success object, it may have hidden several bugs at once.

Ask:

When this request is invalid or unavailable, what does the user see, what state is written, and how can they recover?

4. The neighbor workflow still passes

Most bug fixes touch shared code. That means the original screen is not the only thing worth testing.

If AI changed a shared form component, test another form. If it changed an authentication check, test both an owner and a non-owner. If it changed a database query, test an empty list and a list with several records. If it changed mobile layout code, test a smaller screen and a keyboard-open state.

You are not trying to test the entire universe. You are testing the closest behavior that could have been affected by the same change.

The Before-And-After Table I Use

For a small app, this is enough:

Check	Before patch	After patch	Evidence
Original reproduction	Fails	Passes	visible result or test output
State after refresh	Old value returns	New value remains	refreshed screen or record
Invalid input	Misleading success	Clear correction path	error state
Neighbor workflow	Passes or fails	Still behaves as expected	second scenario
Logs and secrets	Error or unsafe data	Useful, non-sensitive evidence	log/test review

The table is deliberately boring. Boring is good. It stops a confident explanation from replacing a working product.

A Debugging Prompt That Requests Proof

I would give AI this prompt instead of “fix the bug”:

Treat this as a regression investigation, not a request for a confident explanation.

Bug reproduction:
[starting state, exact actions, expected result, actual result]

Constraints:
[files or behavior that must not change]

Before editing code:
1. Explain the most likely cause and the evidence that would confirm it.
2. List the smallest files or functions that may need to change.
3. Name one way a patch could hide the symptom instead of fixing the cause.

After proposing the patch, provide:
1. The exact original reproduction to rerun.
2. One persistence or underlying-state check.
3. One invalid-input or failure-path check.
4. One nearby workflow that could regress.
5. A short explanation of what evidence would make us reject the patch.

Do not remove an error merely to make the screen look successful. Do not broaden the change beyond the stated bug without explaining why.

The phrase “what evidence would make us reject the patch” is important. It gives you a way to disagree with AI before the code becomes too large to understand.

When The Fix Is Not Ready

I would keep the bug open if any of these are true:

the original steps changed without an explanation;
the UI says success but refresh loses the result;
the error disappeared and no replacement behavior exists;
the fix works only with one hard-coded example;
the patch changes unrelated screens without a clear reason;
no failure-path test was run; or
nobody can say what evidence proves the underlying state is correct.

That is not perfectionism. It is a boundary between a demo and a product.

The deeper field manual behind this workflow is AI App Builder From Zero. It walks through the larger path from idea and scope to architecture, prompting, QA, deployment, and launch. Use it when you need the whole build system, not just one debugging prompt.

The Short Version

When AI says it fixed a bug, ask it to help you prove four things:

The exact original reproduction passes.
The underlying state is correct after refresh or relaunch.
Invalid or unavailable inputs still fail honestly.
The nearest shared workflow did not regress.

If you can show those four proofs, you have more than a plausible patch. You have a defensible fix.

If you want a free place to start, AI App Builder Starter Prompts gives you practical prompts for turning a rough idea into scoped, testable work. The prompts are free. When you are ready for the deeper build-along process, AI App Builder From Zero is the next step.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/

What Beginners Should Check Before Trusting AI-Generated Code In 2026

Marcus Kim — Fri, 24 Jul 2026 00:29:17 +0000

AI can write code that looks finished

One of the most dangerous moments in AI-assisted development is not the obvious error.

It is the moment when the app runs, the screen looks polished, and you assume the code underneath must be sound.

I have learned to separate two questions:

Can this code produce the screen or behavior I asked for?
Does this code preserve the rules my app is supposed to follow?

The first question is a demo. The second is engineering.

AI is very good at producing a plausible first answer. It is not automatically good at preserving your product's boundaries while changing one part of the system.

That is why I review AI-generated code before I trust it, even when the feature appears to work.

Start with the user contract, not the code

Before opening the changed files, write down what the feature is supposed to do in one sentence.

For example:

A signed-in user can save a private note and see only their own saved notes after refreshing the page.

That sentence gives you more to review than a vague request such as “add notes.” It contains a user, an action, ownership, and a persistence expectation.

Then ask AI to show where each part of that contract is implemented:

Where is the user identified?
Where is ownership enforced?
Where is the note saved?
Where is the saved note loaded again?
What happens when the user is signed out?
What happens when the request fails?

If the answer cannot point to those boundaries clearly, the feature is not ready for trust.

The five checks I use before trusting a change

1. Check the data path

Follow the data from the input field to the database or storage layer and back to the screen.

Do not stop at the component that looks correct.

Ask:

Is the input normalized or validated?
Is the data shape the same at every layer?
Is a missing value treated differently from an empty value?
Is the saved record loaded from the real source, or only held in local screen state?
Could an old field name silently produce an empty result?

AI can update a type, a form, and a query in three different ways. Each change can look reasonable in isolation while the path between them is broken.

I want to see the contract between layers, not just a collection of green-looking files.

2. Check who is allowed to do what

A button being hidden is not the same as an action being protected.

If an app has accounts, private data, paid features, admin actions, or shared workspaces, find the actual authorization check.

Ask:

Does the server or database verify ownership?
Can a user change an ID in a request and read somebody else's record?
Are create, read, update, and delete rules consistent?
What happens when the session expires halfway through an action?

The beginner-friendly way to review this is to imagine two test accounts. If account A can change an identifier and see account B's data, the feature is not secure just because the UI shows the right menu.

3. Check the failure paths

AI often spends most of its attention on the happy path: valid input, working network, existing record, expected response.

Review the opposite cases deliberately.

What does the user see when the request times out?
Is a failed save presented as a success?
Can the user retry without creating duplicates?
What happens when the response is empty?
Does an error leave stale data on screen?
Is a loading state cleared on every exit path?

A feature is not finished when it works once. It is finished when the user can understand what happened when it does not work.

4. Check the change surface

Ask AI to list every file, schema, route, dependency, permission, and environment variable it changed.

Then compare that list with the request.

This catches a common failure mode: a small feature quietly changes shared code used by unrelated screens.

I also look for:

duplicated business rules,
new dependencies that solve a problem the project already solved,
broad refactors mixed into a narrow feature,
renamed fields without a migration path,
fallback behavior that hides a configuration error.

The more unrelated surface area a change touches, the more proof it needs. “The new screen works” is not proof that the old screens survived the change.

5. Check whether the code explains itself

Readable code is a QA tool. If you cannot tell what a function is allowed to change, you cannot review it confidently.

Look for clear names, small responsibilities, predictable error handling, and comments that explain decisions rather than narrate syntax.

When AI generates a large function, I ask it to explain:

the inputs it expects,
the side effects it performs,
the errors it can return,
the data it is allowed to read or write,
the assumptions that would make it unsafe.

If that explanation reveals hidden assumptions, I fix the boundary before polishing the implementation.

A review prompt I would give AI

You can use this as a starting point:

Review the changed code against this user contract: [write one sentence]. First map the data path from input to persistence to display. Then list every authorization check and identify any action protected only by the UI. Then inspect timeout, empty, invalid-input, duplicate-submit, and expired-session behavior. List every changed file, dependency, schema, route, environment variable, and shared component. Identify regressions this change could cause outside the requested feature. Do not rewrite the code yet. Report evidence by file and function, then give me the smallest safe correction for each issue.

The important instruction is “do not rewrite the code yet.” I want the review before the next burst of generated code. Otherwise AI may confidently patch an assumption that nobody has inspected.

What I would not use as proof

These are useful signals, but none is enough by itself:

The app compiles.
The page looks right.
The happy-path demo passed.
AI says it fixed the bug.
There are no visible errors in the browser console.
The code is long and detailed.

The proof has to connect the implementation to the user contract. It has to include the boundaries where data, permissions, failures, and unrelated features can leak.

My rule for beginners

Do not ask, “Did AI write good code?”

Ask, “What rule is this code responsible for preserving, and what evidence shows that it still preserves it?”

That question changes your role. You are no longer grading code by how impressive it looks. You are checking whether the system still behaves like the product you intended to build.

If you want a guided starting point, I made the AI App Builder Starter Prompts, and they are free. They help turn a blank prompt box into a more specific conversation about scope, architecture, implementation, and proof.

For the deeper, end-to-end path from idea through prompting, building, QA, deployment, and launch, the next step is AI App Builder From Zero.

The goal is not to stop using AI. It is to make AI's speed answer to your standards.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/blog/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/