DEV Community: Marcus Kim

GitHub's New Clone Authentication Rule: How to Stop Debugging the Wrong Problem

Marcus Kim — Tue, 20 Oct 2026 02:16:30 +0000

You open a tutorial, ask AI to set up the project, and watch the terminal fail before the app even starts.

The expensive part can come next: two hours of changing files that had nothing to do with the failure.

On October 19, GitHub announced temporary authentication requirements for some public repository clones and fetches over HTTPS. The protection applies during unusual traffic and can occasionally affect legitimate unauthenticated operations. It is not a blanket change making public repositories private.

That distinction matters when you build with AI. A setup command can fail because of the service it contacts, even when the project you want to run is perfectly fine.

My practical takeaway: before you authorize a fix, decide whether you have acquired the code, prepared its environment, or actually reached the application.

Give the failure an address

Imagine a fictional booking-app tutorial. Your assistant plans to download the starter repository, install its packages, start a local server, and test the booking form.

Those are four different jobs. If downloading the repository fails, there is no evidence yet about whether its package versions work or its booking form is broken.

I would ask the assistant to report three things before editing anything:

The last step that completed.
The first step that failed, with a sanitized error message.
The next step that never ran.

For this example, the answer might be: destination folder created; HTTPS clone requires authentication; package installation never started.

Now you have a useful problem statement. You do not need a new framework, a different database, or a rewritten booking form. You need a decision about repository access.

If you need help turning a vague app idea into small, inspectable tasks, my $3 AI App Builder Starter Prompts provide a guided starting point. Add a simple boundary to the task: explain a failed prerequisite before proposing application changes.

Read the provider's scope before changing yours

GitHub's announcement identifies an access protection, rather than a change to your application's behavior. Its scope is specific: some unauthenticated HTTPS clone and fetch operations. Authenticated HTTPS operations, SSH operations, pushes, and unrelated web or API traffic are described as unaffected.

GitHub recommends supported authentication for automated access, or waiting until the temporary protection lifts when authentication is unavailable. The post does not supply a universal waiting period.

That is enough to avoid several bad guesses. A repository loading in your browser does not establish that your terminal command has the right authentication. A failed clone does not prove a dependency is incompatible. Repeatedly rerunning the entire build does not investigate either question.

The durable habit is to identify the affected operation precisely. “GitHub is down” and “this project is broken” are much broader claims than the evidence supports.

Keep access work separate from feature work

GitHub's authentication documentation explains that the access method determines the authentication path. Browser sign-in and command-line Git are different contexts; HTTPS and SSH also use different mechanisms.

I would use the supported sign-in or credential-helper flow appropriate to the environment. I would not paste a credential into an AI conversation, commit one into the repository, or place one inside a remote URL that could appear in logs.

Before asking someone to change a remote, confirm what it is supposed to point to. GitHub's remote-management guide documents how remote names and URLs work. A transport change is a deliberate configuration decision, not a magic debugging incantation.

For a client project, the owner of access might be the client or their administrator. Your feature-development task should not silently become permission to expand account access.

Put a time budget on the detour

Here is the productivity rule I would use for a beginner build: spend ten minutes classifying a prerequisite failure before choosing whether to resolve it, hand it off, or work around it with an already approved task.

Ten minutes is my suggested working limit, not a GitHub retry interval.

During that window, preserve the exact failed operation, compare its message with current documentation, and identify who can resolve it. Avoid changing several unrelated settings to see what sticks.

At the end, write a short handoff:

Starter code has not downloaded. The HTTPS clone reports an authentication requirement. No application files were changed. Access needs the project owner's supported sign-in path; the next build step is package installation after acquisition succeeds.

That note lets you pause without losing the plot. You can continue drafting the booking flow, clarifying acceptance criteria, or reviewing an existing local copy if those tasks are useful and authorized. You do not have to produce a code diff to prove you worked.

Verify the boundary you just crossed

Suppose the access step succeeds later. Resume at acquisition, confirm you have the intended repository, then continue setup.

Do not report “the app is fixed.” You have proved that its source can now be obtained. Package installation, startup, and the booking journey still need their own evidence.

There is a tradeoff here. This approach can feel slower than letting an assistant try five speculative fixes. It also requires you to stop and read a dull error message.

But speculative changes create a second problem: now you must distinguish the original failure from the consequences of your attempted repair. A short triage pause can save a long cleanup session.

Your next action is small. Take one recent failed build and label the last completed step, first failed step, and first unattempted step. Then check whether your proposed fix operates at that same boundary.

Protect your working time by giving the problem an address before giving AI permission to renovate the house.

A guided next step

The $3 Starter Prompts help you turn an idea into guided building tasks. The $9 AI App Builder From Zero e-book organizes the path from idea through testing and publication. The $10 learning bundle includes both complete resources.

Bootcamp Bundle (Review Radar) is coming soon; preview it and request waitlist updates manually by email. Checkout is closed.

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/
Upwork: https://www.upwork.com/freelancers/marcusykim

Cloudflare's Bot Trust Update: Five Tests for an AI-Built Crawler in 2026

Marcus Kim — Sat, 17 Oct 2026 19:41:48 +0000

An automation can introduce itself correctly, stay logged in, and still be the worst visitor on a website.

On October 16, Cloudflare described a new system for continuously evaluating Verified bots. Its initial signals include whether traffic follows published robots preferences and adapts after a site returns HTTP 429. The company says it is using the system internally first; public scores and customer-selectable trust thresholds are planned, not something every customer can configure today.

The useful beginner lesson is smaller than the infrastructure announcement: knowing who your software is does not prove it listens.

If you ask AI to build a crawler, research assistant, or scheduled importer, do not stop testing after it downloads the first page. Test the moment the destination changes its answer.

I would give that behavior its own checklist before expanding the queue.

Start with a tiny, fictional job

Imagine a demo app that imports ten documentation pages from a site you are allowed to access.

The app has two workers. Each worker takes a queued page, downloads it, and records a result. You can pause and restart the process.

That is enough machinery to expose an important problem. Worker one can receive a slowdown signal while worker two keeps sending requests. A restart can forget a pause. A stale queue can contain pages that are no longer eligible.

You do not need to test those mistakes against somebody else's production website. Use a local test server or a controlled fixture with synthetic pages and a request log.

If turning the idea into a bounded first project is the hard part, my $3 AI App Builder Starter Prompts are a guided starting point. For this exercise, keep the project to one queue and five observable tests.

Test 1: A disallowed path never reaches the downloader

Create one allowed demo path and one path excluded by the fixture's robots rules. Put both in the queue.

The result you want is not an error after downloading the excluded page. It is no content request to that path, plus a visible reason for skipping it.

RFC 9309 defines the Robots Exclusion Protocol and explicitly separates it from access authorization. A robots file is not a login system or a universal permission slip. Your app still needs an appropriate basis for accessing the destination and must respect its other controls.

Ask AI to use an established parser for the protocol rather than inventing a few string checks. Then inspect the fixture's actual request log.

My acceptance line would be: "The excluded content URL received zero requests, and the queue explains why."

Test 2: One slowdown reaches both workers

Make the fixture return HTTP 429 with a short wait instruction on the first content request.

RFC 6585 defines 429 as rate limiting and permits a Retry-After header. The protocol does not give your app a universal quota; providers can count requests in different ways.

For this small demo, I would choose a conservative destination-wide pause. Both workers consult the same next-eligible time before starting another request. That is a design choice for the example, not a claim that every API uses a whole-site limit.

Now check the log during the pause. A message saying "worker one is waiting" is insufficient if worker two is still busy hitting the same destination.

Also account for requests that were already in flight. Record when each request started so you can distinguish those from newly dispatched work after the pause became known.

Test 3: Restarting does not erase the pause

Stop the demo during its waiting period. Start it again before that period ends.

The queue should retain the destination's next-eligible time. If the app immediately starts over, the pause existed only in one process's memory.

This is where I would ask AI to show the stored state, not just the function containing a sleep call.

A useful test record includes the destination, the feedback received, the resulting pause, and the next request start time. Keep credentials and response bodies out of that record unless they are actually necessary and safe to retain.

Test 4: Changed preferences affect queued work

Leave several demo pages waiting, then change the fixture's policy before the next batch begins.

Define when your app refreshes that policy and how queued work is checked against the refreshed result. Use the protocol's caching rules and the destination's documented requirements; do not assume one lookup at installation lasts forever.

The important product decision is what happens to old work. I would preserve an excluded item as skipped with its reason, rather than silently deleting it or trying an alternate identity.

Do not route around a refusal with a different account, address, or browser. A technically successful download is not a successful test if it evades the boundary you were meant to honor.

Test 5: The user sees incomplete work honestly

Pause the demo after four of ten pages finish.

The interface should not say "Research complete" because the process exited normally. Show four completed pages, the remaining items, the destination pause, and whether any result is stale or unavailable.

This is also where you decide whether partial output is useful. A documentation search may show the pages it has, with clear coverage. A comparison that requires all ten sources may need to remain incomplete.

Neither decision should be hidden inside the downloader.

A prompt that asks for behavior, not reassurance

I would give AI a prompt like this:

Build a local-only test harness for our documentation importer. Use synthetic pages and no external requests. Add fixtures for an excluded path, HTTP 429 feedback, two workers sharing a destination pause, restart during the pause, and a policy change while work is queued. State each expected request sequence before implementing it. Record request start times and queue transitions. Prove which requests did not occur. Show incomplete coverage truthfully. Do not change identities or bypass controls to make a test pass.

Notice what the prompt does not ask for: "Make the crawler robust."

That adjective leaves too much room for interpretation. A request sequence, a persistent pause, and a visible unfinished queue give you something to inspect.

Keep the first implementation modest

A destination-wide pause can be overly cautious for an API with separate documented limits. A multi-machine deployment needs stronger coordination than a tiny local demo. A fixture cannot prove that an outside service will behave exactly like your simulation.

Those are reasons to state the limits of the test, not reasons to skip it.

Start with one destination and one explicit policy. When you add workers or destinations, repeat the tests at that boundary.

The $3 Starter Prompts help you begin a bounded project. For the organized path through planning, implementation, QA, and publication, AI App Builder From Zero is available as a $9 standalone e-book. The separate 40-prompt workbook is not included. The $10 learning bundle includes the complete book and all 40 Starter Prompts.

Eligible purchases carry one future Bootcamp Bundle benefit: $20 with the $3 prompts, $30 with the standalone book, or $70 with the learning bundle. Verified Apple Books and Kindle combined editions qualify for $70; each store displays its own price. One verified benefit per buyer, used once on either package when checkout opens; benefits do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits retain their original terms.

Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Its planned research, specifications, screen designs, and guided curriculum are not a finished app. You can request waitlist updates through the existing page; checkout remains closed.

The final check is simple: when the destination changes its answer, can you show that every worker changed its behavior?

You can also find me here:

Salesforce's New Agentforce Portfolio: Should You Build or Configure Your First AI App?

Marcus Kim — Sat, 17 Oct 2026 19:24:57 +0000

On September 14, Salesforce announced a new Agentforce portfolio organized around jobs such as customer service, employee support, shopping, and back-office work. Its pitch is that companies can start with agents that already have relevant skills, actions, and data models, then tailor them.

There is an availability distinction worth keeping straight. Salesforce lists several agents as generally available, while its Hunter outbound-sales agent is in pilot with general availability planned for November. Hunter is also the first agent using the new runtime for work that extends across days and weeks. That does not make every announced capability available today.

What caught my attention was the starting point: a job that existing software already knows something about.

If you are a beginner with an app idea, this raises an uncomfortable question. Before you ask an AI coding tool to build your business software, have you made an existing tool attempt the actual job?

I studied entrepreneurship before software engineering, and I build apps with AI. I like building things. That makes this question especially useful for me. A working prototype can make a decision feel settled before I have compared the alternatives.

My rule is to earn the custom build with evidence: find one important task that your available tools cannot handle acceptably, then decide whether owning new software is the best way to close that gap.

If describing that task is where you get stuck, my $3 AI App Builder Starter Prompts give you a guided starting point for turning an idea into a first build. Use the exercise below before committing to that build.

Give the existing option a fair attempt

Imagine a fictional freelance studio that wants an AI project-update app. The owner wants to turn project notes into a weekly status update.

An attractive first prompt would be: “Build a dashboard with clients, projects, AI summaries, and email delivery.”

I would start with a smaller investigation. Choose one representative project and write down the required result:

“Produce an update that distinguishes completed work from planned work, includes the latest client decision, and leaves disputed items for my review.”

Now attempt that job with the tools the studio already has. A document, an existing project tracker, and a manual review step may be enough to learn something useful. You do not need a new subscription to begin.

Use three sample inputs: an ordinary week, a week with a changed decision, and a week with contradictory notes. Use fictional or appropriately sanitized material when evaluating a tool that should not receive client information.

Judge the result against the written requirement. A feature list that says “AI summaries” cannot tell you whether the update silently treats a proposed deadline as an agreed one.

Write down the gap precisely

Suppose the existing workflow produces a decent draft, but it cannot distinguish a client-approved decision from an internal suggestion.

That is a useful finding. “I need a better AI dashboard” was a preference. “The update needs an approval state attached to each decision” describes a missing capability.

I would classify each failure before creating a development task:

A missing setting: the capability exists, and we have not configured it.
Missing or unclear input: the tool cannot identify approval because our notes never record it.
A missing connection: the information exists in another tool but does not reach this workflow.
Missing product behavior: the available system cannot represent or enforce the rule we need.

Those diagnoses lead to different amounts of work. A notes convention may solve the second problem. A supported export may solve the third. The fourth may justify a custom component.

Ask the existing workflow to fail honestly before giving a new app credit for solving it.

Compare three paths on the same task

For the fictional studio, I would consider three options.

First, configure the current tools and keep a person reviewing the draft. This can be a good fit if updates are infrequent and the review is quick.

Second, add a narrow extension that records decision status and prepares the update. Keep the established project tracker if it already handles the rest of the job well.

Third, build a dedicated app because the approval behavior, recurring volume, or required user experience makes the smaller options inadequate.

Give every option the same sample inputs and required result. Record where it fails, what a person still has to do, and what you would have to maintain. For an unbuilt option, label the result as a hypothesis until a small prototype demonstrates it.

This comparison prevents an unfair contest between an existing tool's real limitations and an imaginary app that has none.

It also keeps you from building an entire project-management system to obtain one approval field.

Count the work after the first demo

In his 2020 AWS essay on build-versus-buy decisions, Gregor Hohpe explains why development cost alone is an incomplete comparison. Time spent creating one system cannot also be spent elsewhere, and writing your own software creates commitments of its own.

My beginner version is to name the recurring chores before celebrating the saved subscription.

Who corrects the source data? Who notices that the update is wrong? Who handles a changed integration? Who helps a new user? Can you return to the manual workflow if the tool becomes unavailable?

Packaged AI also requires this work. Salesforce's Testing Center documentation describes evaluating responses and actions across scenarios. It warns that tests consume requests and credits and can modify CRM data, so testing belongs in a sandbox.

That is relevant even if you never use Salesforce: obtaining an agent does not complete the job of operating it. For a zero-budget evaluation, write your cases and examine the current workflow first; do not assume a vendor's test button is free.

I would keep a short list of the chores each option leaves with me. If nobody can own them, the option is not ready to become part of the business.

Set a condition for changing your mind

There is a limitation to starting with existing tools. You can spend too long adapting your work to a system that cannot express the thing customers value.

The answer is to put a limit on the investigation. For this example, I might allow one afternoon to test the three sample inputs and the relevant configuration. If the approval rule still cannot be represented, I would prototype only that missing behavior.

Those are example limits, not universal benchmarks. Your consequence, workload, and available time should determine yours.

Record why you chose the current path and what would make you reconsider. Perhaps manual review becomes too slow. Perhaps a recurring exception becomes the main customer need. Perhaps the existing product adds the missing capability and your extension is no longer worth maintaining.

You are allowed to retire your own clever solution. The repository does not get a vote.

The question I would give AI next

Try this with your actual workflow:

Compare using my existing tools, adding one narrow extension, and building a custom app for this task: [task]. Use the same required outcome and three representative inputs for each option. Separate configuration problems, missing information, missing connections, and missing product behavior. Mark untested capabilities as unknown. List the recurring work I would own, propose a limited evaluation, and state what evidence would justify a custom build. Start with what I already have; do not purchase or activate paid services.

Choose one task today and attempt it with your current setup. Then write down the first important gap you can demonstrate.

The $3 AI App Builder Starter Prompts can help you turn that gap into a guided first-build conversation.

Review Radar is coming soon. Its planned public-review research, tailored screens, and AI-ready project folder are intended to help you define a specific app before implementation. Explore the public preview and join the email waitlist. Checkout is not open, and the package does not promise a finished app or revenue.

Build when you can explain the important gap, show why it matters, and accept the work of owning the solution.

For the complete beginner playbook, AI App Builder From Zero covers planning, design, building, testing, and publishing. The standalone e-book is $9 with $30 off Bootcamp Bundle (Review Radar); the separate 40 Starter Prompts workbook is not included. The Gumroad e-book + all 40 Starter Prompts bundle is $10 with $70 off instead. Verified Apple Books and Kindle combined editions qualify for $70 off; retailer prices are shown by each store. One verified reader benefit per buyer, used once on either Bootcamp Bundle package when checkout opens; discounts do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits retain their original terms. Bootcamp Bundle (Review Radar) is planned at $399 for one app project or $999 for three, with the same quality standards. Checkout remains closed.

Standalone e-book: https://marcusykim.gumroad.com/l/ai-app-builder-book-only

Gumroad bundle: https://marcusykim.gumroad.com/l/ai-app-builder-from-zero

You can also find me here:

GitHub Actions Lockfiles: How Beginners Can Keep Reviewed Code Running in 2026

Marcus Kim — Thu, 15 Oct 2026 19:12:53 +0000

You ask an AI coding tool to add an automated build. It writes a small workflow, explains the steps, and points to a successful run.

A week later, the workflow file has exactly the same text. Does that mean it will run exactly the same outside code?

I would want a beginner to pause before answering yes.

A version label in a workflow can point somewhere different later. You might have reviewed the recipe while leaving one ingredient supplier free to change what arrives.

On October 14, GitHub introduced workflow dependency lockfiles in public preview. The announcement addresses this gap: tags and branches can move, while a lockfile records the commits an onboarded workflow should execute. GitHub lists Free, Team, and Enterprise Cloud plans, including Enterprise Cloud with data residency, as eligible for the preview.

My beginner takeaway is this: keep the friendly dependency label for understanding, but give execution a specific code identity you can review.

That is a useful question to ask your AI assistant before accepting its next deployment workflow. If you need a structured way to ask questions like that, my $3 AI App Builder Starter Prompts provide forty guided prompts for planning and checking a first build. You can do the exercise below without buying anything.

The version name and the actual code are different things

Imagine a hypothetical action called example-org/package-app@v3.

The left side identifies a repository. The v3 part is a tag. Your workflow asks for that reference, and the service resolves it to code.

A commit identifies a particular revision. A tag is a label attached to a revision, and the label can move. That difference matters even when you have no plans to become a release engineer.

Picture an AI-generated workflow that packages your app every time you merge a change. You inspect the workflow on Monday. On Wednesday, the upstream tag points to another revision. On Thursday, your unchanged workflow runs again.

Your own app diff does not tell the whole story of what changed between those runs.

This is an illustrative scenario, not a claim that a particular action has been compromised. It explains why “we did not edit the workflow” is incomplete evidence about the code it executes.

Your direct dependency can bring friends

The first outside action in a workflow may call other actions. Those indirect dependencies are part of the execution story too.

GitHub's lockfile documentation explains that the repository's generated .github/workflows/actions.lock records dependency references, commits, and source-repository identities. It covers transitive action dependencies, with an important boundary: dependencies inside a called reusable workflow are covered by that workflow's own repository lockfile.

I read that boundary as a practical ownership question. If my build calls another team's reusable release workflow, who maintains the dependencies inside it?

A beginner does not need to memorize the entire graph. You do need to know where your review stops and someone else's starts.

For a hypothetical booking app, I would write a short inventory in plain English:

Our workflow checks out the app and runs its tests.
An outside action packages the result.
A reusable workflow handles deployment.
We own the first workflow's dependency record.
The reusable workflow's maintainers own its internal record, which we need to assess separately.

That small inventory makes “the build system” less mysterious. It also gives your AI assistant a concrete object to inspect instead of a vague instruction to make everything secure.

The first exercise I would give an AI assistant

Start with one existing test workflow in a practice repository. Keep production deployment out of the first exercise.

My prompt would be:

“Read this workflow and its referenced action definitions. List the outside executable dependencies, their readable references, and the exact revisions currently selected. Identify indirect actions and called reusable workflows. Mark anything you could not inspect. Explain the lockfile ownership boundary before proposing changes.”

The output should be a dependency map with evidence. If the assistant cannot inspect a source, an explicit unknown is more useful than a confident invented answer.

Then ask it to show one hypothetical update. Which resolved revisions would change? Does the change add another outside action? Does it alter the commands that run or the access they need?

Those questions put the review on executable behavior. A tidy YAML file alone cannot answer them.

Generate the record, then inspect what changed

GitHub supplies the gh-actions-lock CLI extension. Its repository documents installation through the GitHub CLI, generation with gh actions-lock, and a nonwriting check with gh actions-lock --verify. The tool is pre-1.0; its authors warn that behavior, flags, and the format can change during the preview. GitHub Enterprise Server is currently unsupported.

I would follow the current setup instructions in a branch, generate the files with the tool, and inspect the diff before committing. I would not ask AI to handwrite a plausible-looking lockfile. GitHub's documentation specifically says the file should be generated rather than edited manually.

For the exercise, a useful review note would say:

“Our test workflow now uses the generated dependency record. These are the outside revisions it selects. This reusable workflow has a separate ownership boundary. The test run completed against this app revision.”

Keep the last sentence factual. If the run failed, write that it failed and investigate. The lockfile's existence does not transform a failed build into a passing one.

Updating is a new review decision

A dependency record is useful because it makes a change deliberate. Eventually you will want newer dependency code, so you need an update path too.

The extension's README says normal generation preserves existing locked pins; --relock resolves legitimately moved references again. It also distinguishes online verification from the narrower offline --verify-local check.

That means I would not tell a beginner to regenerate everything blindly whenever CI complains. First understand whether you added a dependency, changed a reference, or encountered a failed identity or reachability check. A verification failure deserves an explanation before an update.

For an ordinary update, I would want the proposed diff to answer three questions:

Which dependency revisions changed, including indirect ones?
Why do we want the new behavior?
What app-level build or test result supports accepting it?

This is different from choosing an update time. It is about making the selected code visible at the moment you accept a change.

What locking cannot promise

GitHub's announcement explicitly cautions that locking does not establish whether a dependency is safe. You can consistently execute code that was a bad choice in the first place.

A lockfile also is not a claim that the whole environment is frozen. Your app packages, runner environment, external services, and deployment settings need their own reasoning. Keep the scope of the evidence clear: you are recording workflow dependencies, not proving that every possible input to a release is identical.

The tradeoff is another generated artifact and another review responsibility. For a small practice app, start with one workflow so you can explain the result. If the preview does not fit your environment, review GitHub's established full-commit pinning guidance and its limits rather than pretending the new mechanism is universally available.

Your next build should be easier to explain

Open one AI-written workflow and point to an outside uses reference. Can you explain whether it is a moving label or a specific revision? Can you identify who owns the dependencies behind a reusable workflow?

If you cannot, that is a useful next task for your assistant.

For guided practice, the $3 Starter Prompts are the immediate next step and carry a $20 buyer benefit toward the planned Bootcamp Bundle. The $9 standalone AI App Builder From Zero e-book provides the organized path from idea through testing and publication, with a $30 benefit. The standalone book excludes the separate forty-prompt workbook.

The $10 Gumroad learning bundle includes both complete resources and carries a $70 benefit.

Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Checkout remains closed. See the public preview and manually request waitlist updates by email; sending a request is not automatic registration. These are planned toolkits, not a promise of a finished app or revenue.

Benefits require verified purchases, apply once per buyer when checkout opens, do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits remain preserved.

My practical rule: when you review automation, name the code you are accepting as well as the job you want it to do.

You can also find me here:

OpenCode Stops Automatic Updates: How Beginners Can Protect Their AI Coding Workflow in 2026

Marcus Kim — Wed, 14 Oct 2026 20:37:37 +0000

You open your AI coding tool to finish one small feature. An update appears. You install it, explore a new setting, change a plugin, and spend the next hour figuring out why your old workflow feels different.

The feature is still unfinished.

That is a hypothetical example, but it captures a trap I want beginners to recognize: maintaining your tools can quietly become the work you do instead of finishing your app.

OpenCode’s October 11, 2026 release gives us a concrete reason to discuss it. Version 1.19.0 adds an /update command in its terminal interface for installing updates or moving to OpenCode 2. The release notes say updates are no longer installed automatically. They also identify opencode upgrade --major as the route to OpenCode 2.

I widened this week’s research beyond the previous 24 hours to use this October 11 development. The useful lesson is bigger than one command: routine maintenance should have a place in your workflow, rather than an unlimited claim on your attention.

My starting rule is simple. Before changing a working tool, decide whether the change is urgent, needed for the current task, or routine. Each category gets a different response.

If you are still learning how to give an AI tool clear project rules, my $3 AI App Builder Starter Prompts provide forty guided prompts for scoping and checking a first local build. You can practice the maintenance decision below without buying anything.

What the release does—and what it does not establish

OpenCode is making the update action explicit in its terminal interface. That gives the person operating it a decision point.

I am not claiming the maintainers made this change to improve your productivity. The release notes describe the behavior, not an experiment showing that manual updates make developers faster.

Nor does this mean every part of your AI environment is now frozen. The coding client, the model behind it, plugins, and your app’s dependencies are separate moving parts. A client update policy cannot guarantee that an outside service will keep behaving identically.

The official CLI documentation also describes opencode upgrade [target] for updating to the latest or a specific version. It lists --version as a global flag. Those are useful tools for recording what you run and choosing a target deliberately. They are not a promise that every migration can be reversed safely.

For a beginner, the misunderstanding to avoid is treating “update available” as “update required before I can work.” Sometimes an update really is urgent. Sometimes it is simply available.

Give each update one of three answers

Here is how I would make that distinction on a small freelance or personal app project.

Urgent: An official advisory identifies a security issue relevant to the way you use the tool, or a provider is retiring a capability you depend on. Interrupt the normal plan, read the actual guidance, and address the affected workflow. If necessary, stop using the exposed capability while you work through the fix.

Needed now: The current tool cannot do a specific part of today’s task, and the release documents the missing capability or a fix for the actual blocker. Give the update its own bounded task. Write down the problem it is supposed to solve before you install it.

Routine: The release is useful, but your current task can proceed without it. Put it in the next maintenance window and return to the feature.

The third answer needs a real date. “I will deal with it eventually” is how deliberate updating turns into abandoned maintenance.

These categories are my workflow recommendation, not an OpenCode feature. You can use them with another coding assistant, an editor, or a development plugin.

A maintenance appointment you can actually finish

Imagine you are building a simple booking app and promised yourself a working cancellation flow this afternoon. A new coding-tool version arrives with conveniences you would like to try.

I would record a short maintenance note:

Change: update the coding client to the chosen release.
Reason: try the documented improvement; it is not blocking cancellation work.
Owner: me.
Window: Friday morning, after the cancellation demo.
Time limit: thirty minutes for installation and a small workflow check.
Exit: record the result and either resume normal work or make a separate repair task.

Thirty minutes is an example budget, not a universal estimate. A major migration may need a longer appointment and preparation. The point is that you decide what gets displaced rather than letting a release notification decide for you.

At the appointment, save your current work through your normal version-control process. Record the installed version and read the release’s migration instructions. Check what state or configuration might change and whether the documented recovery path covers it. Do not assume reinstalling an older executable restores changed data.

Then perform the update using the supported route for your installation. Avoid adding a new plugin, switching the model, and upgrading app dependencies in the same appointment just because you are already there.

Finally, run one familiar, low-risk task: ask the tool to explain a small existing function, then make and review a disposable change in a test branch. Confirm the workflow you actually need still works. A successful installer is useful evidence, but it does not answer that second question.

If you hit the time limit with an unresolved problem, name the problem and plan the repair. Do not quietly consume the afternoon you reserved for delivery.

Manual updates have a cost

Automatic updates reduce the amount of maintenance a person must remember. Manual updates move more of that responsibility onto you.

That tradeoff matters. A fixed Friday appointment is not permission to ignore a relevant security advisory until Friday. Equally, the existence of a new feature is not evidence that your current work must stop.

A solo builder owns this decision personally. On a small team, someone needs to own the maintenance note, otherwise everyone can assume someone else handled it. Keep the decision visible in the project’s normal task system.

I would judge this habit by whether routine maintenance gets completed and planned delivery keeps its place. I would not claim a productivity percentage without measuring one.

Your next step

Before your next build session, write two things: the result you intend to finish and the next appointment for routine tool maintenance. Add the condition that would justify interrupting that plan.

That is enough to start. You do not need an elaborate operations dashboard to stop a tool notification from becoming your project manager.

For guided first-build practice, start with the $3 Starter Prompts. For the organized path through idea, architecture, QA, deployment, launch, and maintenance, AI App Builder From Zero is the $9 standalone e-book. The separate forty-prompt resource is not included in that standalone book. The $10 Gumroad learning bundle includes both complete resources.

Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Checkout remains closed. Visit the public preview and manually email a request for waitlist updates; this is launch interest, not automatic registration or a finished-app promise.

Verified Starter Prompts buyers qualify for a $20 Review Radar benefit, standalone e-book buyers for $30, and learning-bundle buyers for $70 when checkout opens. One benefit per buyer, used once; benefits do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued buyer terms remain preserved.

You can also find me here:

CodeQL 2.27.2: A Beginner's Checklist for Comparing Security Scan Results in 2026

Marcus Kim — Wed, 14 Oct 2026 07:54:17 +0000

If your AI coding tool changes three files and your security alerts fall from eight to five, what actually improved?

I would want to know whether the scanner changed too. Otherwise, you might congratulate a code fix for something the measurement tool did.

GitHub announced CodeQL 2.27.2 on October 9. The underlying release notes are dated October 7. I'm using that recent development from the past seven days because it offers a useful beginner lesson beyond a release headline: an analysis upgrade can change what a tool reports about the same application.

CodeQL analyzes code for patterns associated with security problems. This release improves Hapi request-input tracking in JavaScript and TypeScript. It also corrects a C# false positive involving generated Razor tag-helper attribute code. Those are two different reasons a report might change: the tool can understand a path better, or stop treating a particular pattern as a problem.

Neither outcome automatically tells you that your last app edit fixed anything.

My operating rule is simple: compare the measurement tool on unchanged code before you compare a code fix under the new tool.

If you're starting your first app, my $3 AI App Builder Starter Prompts provide a guided starting workflow. Add this comparison rule to your testing instructions so the next AI-assisted change comes with an explanation you can check.

1. Save the starting point

Before upgrading an analyzer or accepting a proposed fix, save a small evidence note. Record the exact code revision, scanner version, query suite, relevant custom queries, configuration, build mode, and whether the run completed successfully.

Also save the findings themselves. A total count is useful for orientation, but it cannot tell you whether three findings disappeared while two different ones arrived.

Think of the code revision as a labeled photograph of your repository. You need that label to compare the same application twice.

For a beginner, the important question is not whether you can memorize every tool option. It is whether you can ask your coding assistant to show what changed between the two runs without silently changing the app at the same time.

2. Hold the application still

When your environment supports it, analyze the same revision with the old and new analyzer. Keep the query suite, configuration, and build conditions comparable. Record any unavoidable differences.

That gives you a first comparison: old tool versus new tool, same code.

Then make the application fix and run the new tool again. That gives you a second comparison: old code versus changed code, same tool.

Here is a hypothetical example, not a report from one of my projects. A scanner reports an issue on revision A. After an analyzer upgrade, that issue disappears on revision A without an application edit. You can investigate the analyzer change as an explanation. You cannot honestly write that revision B fixed the issue when B did not exist yet.

Now imagine the finding remains on A under the new analyzer. You make a targeted change in B, and the same analyzer no longer reports it. That is more relevant evidence for the fix, although you still need to inspect the path and test the intended behavior.

3. Explain each changed finding

I would sort changed findings into four working explanations:

The analyzer now recognizes a behavior it previously missed.
The analyzer corrects an earlier false positive.
The application change alters the reported path.
The run or configuration changed, making the comparison incomplete.

These are investigation categories, not verdicts. Read the finding and the release notes before assigning one.

The CodeQL release's improved Hapi tracking makes a useful example. If your application uses wrappers around route registration, a newer analyzer may follow request input differently. A newly visible finding could concern code that was already there. It does not, by itself, prove that the upgrade introduced an application vulnerability.

Conversely, a removed finding deserves an explanation. A lower number can reflect better analysis rather than a safer code revision.

4. Check your custom queries separately

The release notes also describe changes to CodeQL's Go control-flow graph that can require existing custom queries to be updated.

If you maintain custom checks, ask whether those checks still compile and run as intended. A query compatibility failure belongs in the evidence note. Do not present it as a successful scan with no findings.

You probably do not need to write custom queries for your first app. You do need to recognize that the checking system has its own dependencies. An app build can succeed while a separate analysis job fails or checks something different from what you expected.

5. Give AI a comparison task before a repair task

Here is the instruction I would use:

“Compare these two security-analysis runs before editing application code. Identify the code revision, analyzer version, query configuration, and run completion state for each. List new, removed, and unchanged findings. Separate changes supported by analyzer release notes from changes supported by code differences. Mark uncertain explanations explicitly. Propose the smallest follow-up check for each uncertain finding.”

Keep secrets and private customer data out of the material you provide. A comparison note should describe the evidence needed for the task, not export your whole environment.

After the comparison, ask for one targeted fix and its verification plan. That sequence makes it harder for an assistant to produce a plausible explanation after changing several unrelated things.

The limitation: your old tool may be unavailable

Hosted tools can update automatically. GitHub says new CodeQL versions are automatically deployed to code-scanning users on github.com. You may not have a convenient old-versus-new rerun available.

In that case, preserve the previous report and compare it with a new run on the same revision where possible. Record the missing controlled comparison. Treat release notes as evidence for a hypothesis, not proof that a specific finding changed for that reason.

Do not hold important security work indefinitely for a perfect experiment. Investigate consequential findings and make needed fixes while stating what your evidence can and cannot establish.

The practical next step is small: pick one changed finding and write down the code revision, tool version, and reason you believe it changed. If you cannot name the reason, your next task is a check, not a victory announcement.

Continue from a check to a build workflow

Use the $3 AI App Builder Starter Prompts for guided first actions. For the organized path from idea through testing and publication, the $9 standalone AI App Builder From Zero e-book is the longer field manual; it excludes the separate 40-prompt workbook. The $10 Gumroad learning bundle includes both resources.

Those purchases provide respective $20, $30, and $70 buyer benefits toward Bootcamp Bundle (Review Radar) when checkout opens. One verified benefit per buyer, used once; benefits do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits remain preserved.

Bootcamp Bundle (Review Radar) is coming soon, planned at $399/$999, with checkout closed. See the public preview and request waitlist updates manually by email. An email request expresses launch interest; it does not automatically register you.

You can also find me here:

GitHub's Timeline Update: How to Make an AI-Built Activity Feed Accessible in 2026

Marcus Kim — Thu, 08 Oct 2026 20:54:27 +0000

I can look at an activity feed and immediately see that five updates belong together. A screen-reader user needs the app to communicate that relationship through more than spacing and a vertical line.

That is the useful beginner lesson in GitHub's October 8 timeline update. GitHub now exposes timelines as lists to assistive technology, providing orientation such as item count and position. Loading additional events also reports the number added. The announcement says the visual appearance is unchanged.

You could compare two screenshots and miss the improvement entirely.

When you ask AI to build an activity feed, order history, or project log, ask what the user can understand without visually scanning the page. That question belongs in your feature request before you accept the generated implementation.

Here is my starting rule: the user should be able to find the collection, understand one item, request more, and continue without losing their place.

If you want a guided first-build workflow, my $3 AI App Builder Starter Prompts help you turn an idea into a bounded build. Use this article's orientation check as an extra requirement in that workflow, rather than asking AI for a generic accessibility polish pass.

Start with the relationship between items

Imagine a small app that tracks freelance project updates. Its feed contains a milestone approval, a file upload, and a delivery note. AI could build that as three styled containers. They might look like a list while exposing little useful grouping to assistive technology.

The W3C's content-structure tutorial explains how semantic markup communicates meaning and groups information. It distinguishes unordered lists, ordered lists, and description lists according to the relationship between their contents.

My implementation advice is to start with the simplest native structure that fits the content. If sequence matters to the meaning, consider an ordered list. If you are presenting a collection without a meaningful sequence, an unordered list may fit. Do not choose based only on whether the mockup shows bullets: appearance and structure are separate decisions.

Give the collection a clear heading. Make each event understandable: who did what, to which project item, and when? A colored dot or icon can reinforce that meaning, but it should not carry the only explanation.

For a hypothetical event, “Maya approved the homepage milestone, October 8 at 10:15 AM” is more useful than “Approved” beside an unlabeled avatar. Use synthetic people and project data while testing.

You do not need to invent a complex custom widget for a short history. Native elements reduce the amount of behavior you must implement yourself. They still need to be checked in the actual app.

Treat loading more as a change in orientation

A Load more button introduces a second responsibility. The request can succeed at the network layer while the user remains unsure what happened.

For this project-history example, I would write the behavior before requesting code:

While loading, communicate that the request is in progress and prevent duplicate requests.
On success, communicate the number of events added.
On failure, explain that the existing history remains available and provide a retry action.
When there are no more events, make that state understandable.

Those are product expectations for this example, not a claim that GitHub implements every one of them.

Then decide what happens to focus. Should it remain on the Load more control so the user can continue at their own pace? Should it move to a newly loaded event after an explicit request? The right choice depends on your interaction and the user's task. GitHub's announcement describes moving focus to the newest event; I would not copy that into every feed automatically.

Automatic refresh is a different case from a deliberate button press. An incoming background event should not casually steal focus from a user composing a reply or examining an older update.

Ask AI to state its proposed focus behavior and why. If it cannot explain the choice, the implementation is not ready for you to accept.

Give AI a concrete request

For the hypothetical project log, I would use a request like this:

“Implement the project activity history as a semantically grouped collection with a clear heading. Each event must expose actor, action, target, and time in a meaningful reading order. Specify the focus behavior for an explicit Load more request before coding. Communicate loading, added-event count, failure, and exhaustion without relying on color. Background refresh must preserve the user's current focus. Use synthetic events and explain how I can verify the behavior with keyboard navigation and a screen reader.”

This request names the job and the changing states. It also makes AI explain the parts that a screenshot cannot prove.

Do not accept “added ARIA” as the outcome. Extra attributes can be wrong, redundant, or disconnected from the current state. Ask what a user actually encounters.

Verify a small journey

I would check a three-event history first, then a longer one with loading enabled. Use the platform's screen reader and learn its navigation commands before interpreting the results.

Find the history by its heading. Confirm that the collection and its events are understandable. Read an event without looking at the page. Request more and determine what changed, where focus went, and how you continue. Repeat with a failed request and with no remaining events.

Also use the keyboard without a screen reader. Check that controls are reachable, focus is visible, and the loading state does not strand you. These checks complement each other; one does not substitute for the other.

Record the browser, screen reader, and platform you tried. Say what worked and what remains untested. Automated checks can help detect mistakes, but a clean report does not establish that the journey makes sense.

For a beginner, there is a real tradeoff here: dynamic feeds, virtualization, and custom interactions add behavior that takes time to verify. A short, paginated history can be a better first version than an infinite feed if it lets you deliver understandable navigation reliably. That is a scope decision, not a reason to leave users without access.

Your next step

Pick one collection in your app: tasks, messages, history, or search results. Write down its grouping, each item's meaning, loading feedback, and focus behavior. Ask AI to inspect the existing implementation against those four responsibilities before changing it.

My $3 Starter Prompts are the immediate guided action, with a $20 buyer benefit toward Bootcamp Bundle (Review Radar) when checkout opens. The $9 standalone AI App Builder From Zero e-book gives you an organized path from idea to publication and a $30 benefit; it excludes the separate 40-prompt workbook. The $10 Gumroad learning bundle includes both resources and a $70 benefit.

Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Checkout remains closed. Visit the preview to request waitlist updates manually by email; this is launch interest, not automatic registration. It does not promise revenue or a guaranteed finished app.

One verified buyer benefit may be used once when checkout opens. Benefits do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits keep their original terms. Verified Kindle and Apple combined editions qualify for the $70 benefit; check each store for its price.

A feed is useful when you can follow what happened and continue from where you are. Make that true for someone who cannot see its layout, too.

You can also find me here:

Cloudflare's Auto Router: How to Measure AI Cost per Useful Result in 2026

Marcus Kim — Mon, 05 Oct 2026 18:50:06 +0000

A cheap AI answer gets expensive when you have to ask three more times, fix the result yourself, and explain to a client why the promised shortcut took the afternoon.

That is the question I brought to Cloudflare's October 5 Birthday Week recap. It collects 46 announcements from the previous week. One worth examining for freelancers and beginner builders is Auto Router, which launched on September 30—not today.

Cloudflare's Auto Router announcement describes a public-beta AI Gateway feature that selects a model for each request. Its internal knowledge-work benchmark reports both success rates and cost per success. The router scored 252 successful trials out of 291, at $2.10 total, or about $0.0084 per success. These are Cloudflare's own simulated-workspace results, not a promise about your app.

The useful lesson is in that last unit: cost per success.

I want you to measure the whole batch of work that produced the useful results. A low token price tells you the price of an ingredient. You still need to know how many ingredients you wasted and how much cleanup the recipe required.

If you need help turning one app idea into a guided build task, my $1 AI App Builder Starter Prompts give you a starting sequence. First, though, use the measurement method below on a task you already understand. You do not need a new subscription or paid experiment to start.

The denominator can flatter you

Imagine you are building a small feature that turns rough project notes into a client-update draft. It is an illustrative example, not a report of my results.

You try it on ten made-up sets of notes. You decide beforehand that an acceptable draft must preserve the completed work, distinguish blockers from promises, and invent no deadlines.

Setup A costs $0.20 for the whole batch. Four drafts pass.

Setup B costs $0.30 for the whole batch. Nine drafts pass.

Those figures are invented for the example; they are not provider prices.

A costs two cents per attempted task. B costs three cents. If you stop there, A looks cheaper.

But A costs five cents per accepted draft: $0.20 divided by four. B costs about 3.3 cents per accepted draft: $0.30 divided by nine.

Now suppose you retry A's six failures. Those additional calls belong in A's total cost, including the attempts that fail again. The six original failures do not disappear from the ledger because you dislike how they look.

You also need to show that A initially completed four of ten tasks while B completed nine of ten. A low cost per success can hide poor coverage if you quietly exclude hard tasks or count only the easy ones.

Give one user task one row

For a first measurement, I would keep a simple local sheet. Each row represents one requested result, even when it takes several AI calls.

Record the task identifier, whether the final result passed, the number of attempts, total model charges, any paid tool charges, elapsed time, and minutes spent reviewing or repairing it.

You do not need to store private prompts, client notes, or full generated answers to count these things. Use synthetic notes or work you are authorized to evaluate. Record failure categories such as invented deadline, missing blocker, or malformed output.

The key distinction is between a task and an attempt. Three attempts to produce one update are still one task. Three accepted alternatives for that same update are not three completed client requests.

For a batch, calculate:

Cash cost per accepted result = all batch model and paid-tool charges / number of accepted results.

Keep these beside it:

Accepted results out of all requested tasks.
Total review and repair minutes.
Tasks still unresolved after the attempt limit.
End-to-end time, including retries.

If nothing passes, write “no accepted results.” Do not report a zero-dollar success metric or divide by a made-up denominator.

Decide what passes before looking at the bill

You can make almost any workflow look efficient by lowering its quality bar afterward.

For the client-update example, a short acceptance rule might be: every claim must be supported by the input; blockers must be visible; no delivery date may be added unless supplied; and the result must be readable without rewriting its central message.

An invented deadline is a failure even if the prose sounds excellent. A correctly formatted paragraph is not enough.

Apply the same rule to every setup you compare. Keep the same task set, instructions, and tool access where practical. Note unavoidable differences instead of attributing every change to the model.

Ten examples can expose an obvious failure pattern. They cannot establish a dependable success rate for every future task. Keep difficult cases, extend the set gradually, and avoid treating a tiny trial as a scientific verdict.

Human repair is a separate bill

I would keep human minutes visible rather than immediately translating them into dollars.

Your own time, a client's wait, and an API charge are different quantities. Combining them too early can bury the very tradeoff you need to understand.

Suppose one setup saves ten cents but needs twenty extra minutes of rewriting. You do not need an elaborate spreadsheet to see the question: is this feature reducing your work, or moving it into cleanup?

If you later assign an internal hourly value to review time, state that assumption. Report the cash cost and minutes separately as well. An estimated total is useful only when you can still inspect its ingredients.

This is especially relevant to freelancing. I use AI to help build software, but I remain responsible for the result. The client receives the update or the working feature; they do not receive a discount coupon for my cheap first attempt.

Put a ceiling on retries

An unlimited retry loop makes the denominator problem worse. It can keep charging while the same task stays unresolved.

For a small draft workflow, you might allow one initial attempt and one targeted retry. If it still fails, route it to manual handling and record that outcome. That is an example policy, not a universal limit.

Choose the limit for the actual task. Repeating a wording task is different from repeating an external action. Sending an email twice or submitting a payment twice creates consequences that a better cost metric cannot undo.

Keep evaluation read-only or in a test environment. This article is about measuring the workflow, not permission to let an agent repeat live actions until the numbers improve.

What the router cannot prove for you

Cloudflare says lower token prices can still produce higher overall costs, and that model switches in long sessions carry context and cache costs. That reinforces the need to count the complete attempt path.

Its Auto Router documentation is the place to check current configuration and support. You do not need to install a router to apply this lesson, and routing does not replace your acceptance check.

Your own task mix may have different failure modes, review demands, and latency constraints from a vendor benchmark. A workflow can win on cash cost while losing on completion rate or turnaround time. Keep those columns visible.

Your next step

Pick one repeated, low-risk task. Write its acceptance rule. Review ten existing examples or use synthetic inputs in a local exercise. Group all attempts under their original task, then calculate cost per accepted result with coverage and human minutes beside it.

If you lack billing information, mark the cash figure unknown and start with attempts, acceptance, and time. Do not invent precision or buy access just to fill a cell.

My $1 AI App Builder Starter Prompts are the immediate guided action if you want to turn an idea into a controlled first build. The $9 AI App Builder From Zero e-book provides the organized path from idea through testing and publication, with all 40 Starter Prompts included as a free bonus inside its PDF and EPUB.

For the research and product-definition stage, Review Radar is coming soon. Its planned package combines research, tailored screens, and an AI-ready project folder. Preview it and join the email waitlist if that would help you define a build worth measuring; it does not promise revenue or a guaranteed finished app.

Measure what it took to produce a result you could actually use. Keep the failures in the calculation.

You can also find me here:

GitHub's Longer App Tokens: A Beginner's Integration Checklist for 2026

Marcus Kim — Sun, 04 Oct 2026 07:21:10 +0000

Your app accepts a value from another service. AI writes a neat validation rule. The example works. You move on.

Then the service changes the value's format, and your app rejects something it should accept.

That is the beginner lesson I take from GitHub's October 2 update to GitHub App installation tokens. The rollout is complete: new installation tokens are roughly 520 characters instead of 40. Their prefix remains ghs_, while permissions, repository scope, and the one-hour lifetime are unchanged.

GitHub also says its temporary format-selection header will be deprecated November 30. Integrations should handle these values as opaque strings: pass them through without making assumptions about their internal structure.

You do not need a GitHub App to learn from this. Payment references, pagination cursors, storage keys, and outside record identifiers can create the same design question: which properties does the provider promise, and which did your code infer from an example?

I want you to make that distinction before asking AI to harden an integration. A stricter rule can be a worse rule if it rejects valid input.

Once you have identified one integration to inspect, my $1 AI App Builder Starter Prompts can help you turn a rough build task into a guided next action. Start with the checklist below; you can use it without buying anything.

The mistake: treating an example as a specification

Imagine a small app that imports project activity from another service. Its test fixture has a 12-character record ID.

AI suggests limiting the stored ID to 12 characters. That sounds tidy. But unless the provider documents that limit, your app now depends on an accidental property of one example.

The next record could have a longer ID. A storage layer might reject it. Worse, an intermediate layer could shorten it and leave you holding a different identifier.

I call this an assumption audit: find every place where your app interprets, limits, or transforms a value it does not own. You are checking the boundary, rather than deciding that all validation is bad.

Here are five prompts I would use.

1. Ask which rules have a documented owner

Give AI the relevant integration code and the provider's official documentation. Keep real credentials out of the prompt.

"List every assumption this code makes about external values. For each assumption, identify the supporting documentation or mark it unsupported. Separate our product rules from provider rules. Do not change code yet."

A useful answer names a specific operation: a length check, a prefix test, a conversion to a number, a split on punctuation, or a fixed-width field.

Reject an answer that merely says the integration follows best practices. You need to know why each restriction exists.

2. Trace one value through the whole path

"Trace this external identifier from receipt to its final use. Include validation, storage, serialization, transport, and diagnostic handling. Identify any step that could change or shorten it."

Use a made-up identifier. For a secret, inspect code and configuration with placeholders rather than fetching or printing a real value.

The result should be a short sequence you can check. For example: response field, application variable, saved record, outgoing request. A perfect input validator cannot protect a value that a later layer silently changes.

3. Build fixtures that challenge the assumption

"Create synthetic fixtures that vary the undocumented properties we found. Test whether the value remains identical through the integration boundary. Clearly separate local preservation tests from provider acceptance tests."

For an opaque identifier, useful variations might include a longer value, leading zeroes, and punctuation where the documented contract permits it. Select cases from the actual contract; do not invent a universal list of characters every service must accept.

A string such as 000123 is especially revealing if your app converts IDs to numbers. If those zeroes matter to the provider, converting it to 123 changes the identity.

These local checks prove your code preserves fixtures. They do not prove a fabricated token can authenticate. Never send made-up credentials to production to turn a unit test into a live experiment.

4. Keep security decisions in the right place

"Explain what this app can validate locally, what the provider must verify, and what our own authorization policy must enforce. Show how failures become safe user-facing states without exposing secrets."

Opaque does not mean trusted. A value can travel intact and still be expired, unauthorized, or invalid.

GitHub's installation-authentication documentation describes access in terms of installation permissions and repository access. Knowing a token's appearance does not establish either of those things.

In your app, keep identity, access decisions, and representation checks separate. Do not let a plausible-looking string become proof that someone owns a record.

5. Repair the smallest unsupported dependency

"Propose the smallest change that removes the unsupported format assumption. Preserve documented constraints, request-size protections, authorization, and secret handling. Show the failing synthetic case before the change and the passing case after it."

Do not ask AI to remove every length limit across your app. Size limits still protect resources, and user-created fields still need product rules.

The goal is to replace an unjustified constraint with a justified one. If a provider offers no explicit maximum, document your operational limit, choose it deliberately, and fail clearly when it is exceeded. Do not silently truncate.

A ten-minute task for your first app

Pick one value owned by an outside system. Find its documentation. Write down what your app needs to know about it and what it should simply preserve.

Then trace that value through your code with one synthetic fixture that breaks an unsupported assumption. You may discover there is nothing to repair. That is useful evidence too.

This checklist cannot guarantee compatibility with every future provider change. A service can change behavior as well as representation. But it removes one avoidable source of fragility: making your app depend on details the provider never promised.

For a guided immediate step, the $1 Starter Prompts help you structure the questions you give an AI builder. For the organized path from idea through testing and publication, my $9 AI App Builder From Zero e-book includes all 40 Starter Prompts as a free bonus inside its PDF and EPUB.

Review Radar is coming soon. It brings together research, tailored screens, and an AI-ready project folder to help you prepare a build; it does not promise revenue or a guaranteed app. See the existing preview and join the email waitlist.

My takeaway: when your app receives an outside value, understand the contract before teaching your code to understand its shape.

You can also find me here:

GitHub's Coverage Upload Fix: Green Does Not Mean Checked

Marcus Kim — Sat, 03 Oct 2026 15:27:13 +0000

Your AI coding tool says the tests passed. GitHub shows a green check. The app opens on your laptop.

Can you invite people to use it?

Maybe. But those three facts do not tell you whether saving works, whether another account can read private records, or whether your tests ran against the version you are about to publish.

I want beginners to ask a more useful question than "Is everything green?"

What actually ran, and what does its result prove?

On October 1, GitHub changed its Code Quality coverage-upload action. A push to a non-default branch without an open pull request now skips the upload instead of failing because the pull request number is missing. A notice and step summary explain the skip. Supported pull request events and default-branch uploads keep their existing behavior.

There is a timing detail: a workflow triggered only by pushes will not upload merely because you open a pull request. It needs another push, or an appropriate pull request trigger. This particular feature is for GitHub Team and Enterprise Cloud, not Enterprise Server.

That is a sensible fix for a misleading failure. My broader lesson is not that green checks are bad. It is that a job completing successfully and a particular piece of evidence being collected are different facts.

Start with four honest outcomes

I would give every important check one of four labels:

Passed: the check ran, and its stated expectation was met.
Failed: the check ran, and its expectation was not met.
Skipped: the check intentionally did not run, with a recorded reason.
Unknown: there is no reliable result, or the result cannot be matched to this build.

A skipped coverage upload does not mean the tests failed. It also does not mean coverage was uploaded. Both statements can be true without any contradiction.

The dangerous move is translating skipped or unknown into passed because the overall page looks reassuring.

Imagine a hypothetical appointment app. Its automated build succeeds, but the check that needs a test database is skipped because that database was unavailable. The app may still package correctly. You have not established that it can save an appointment.

If you are just getting started, the $1 AI App Builder Starter Prompts guide your AI from an idea toward a working first build. Keep this four-outcome rule beside those prompts: an assistant should explain what it could verify, not hide missing checks behind a confident summary.

Give each check a narrow job

"Test the app" is too broad to judge. I would break it into claims a beginner can understand.

A build check asks whether the source can be turned into a runnable product. A small logic test might ask whether cancelling an appointment changes its status. A browser test might ask whether a user can book a slot and see it after refreshing.

A permission test asks a different question: can a second user read or change an appointment they do not own?

One successful check does not substitute for all the others. An app can compile while saving nothing. A save can work while ownership protection is broken. A correct permission rule can exist while the screen still sends the wrong request.

Before asking AI to add tests, write the behavior you want to protect in plain English:

"A signed-in customer can book an available slot, reload the page, and see the booking. A different customer cannot view or cancel that booking."

Now your assistant has a concrete promise to test rather than a vague request to produce impressive output.

Read the denominator before the percentage

Code coverage describes which portions of code were exercised during a test run. It is useful evidence, not a verdict on whether the product is good.

For example, Vitest's documentation explains that its default report shows files imported during the test run. To include uncovered files, you need an appropriate inclusion pattern.

That makes the denominator important. A high percentage across a small selected portion of your project is not the same claim as a high percentage across the application you intended to assess.

Ask your AI which source files the report includes and excludes. Ask whether the important save, permission, and recovery paths are represented. Do not demand an arbitrary percentage before understanding what it measures.

Even fully exercised code can contain weak assertions. A test that clicks Save and checks only that the button exists proves much less than a test that reloads and checks the saved appointment.

Require evidence from the exact build

Yesterday's successful test run is a useful history entry. It is not automatically evidence for today's edited version.

I would ask AI to keep a small verification note with each candidate release:

Version: the commit identifier, or another exact build identifier.
Environment: local development, test deployment, or production-like staging.
Checks: names, outcomes, and reasons for any skips.
Evidence: paths to reports, screenshots, or relevant logs.
Gaps: behavior that remains untested or could not be verified.
Decision: what can proceed and what must wait.

Keep credentials, private customer records, and access tokens out of that note. Test with synthetic records whenever practical.

This is not paperwork for its own sake. It prevents a screenshot from an old preview or a report from a different branch from quietly becoming approval for the current app.

Test the journey, not just the machinery

Testing Library's guiding principles favor checks that resemble how people use the interface rather than relying on a component's private internals.

For our hypothetical appointment app, I would start with one complete journey: sign in, choose a slot, book it, reload, inspect it, and cancel it. Then I would test the same record with another account and an invalid request.

Use a disposable test environment for destructive actions. Do not run a cancellation test against someone's real booking.

This approach also helps you review AI work. You can understand "the appointment survives a refresh" without understanding every line of its storage implementation.

The $9 AI App Builder From Zero e-book connects these steps to the wider path from idea to publication: scope, design, architecture, building, testing, and launch. All 40 Starter Prompts are included as a free bonus inside its PDF and EPUB; you are paying for the e-book, not an extra prompt pack.

The prompt I would use before a beta

Inspect the current project and identify its exact build or commit. List the verification checks that actually ran for this version. Classify each as passed, failed, skipped, or unknown. Explain what each result proves in plain English. Show the report or evidence path, and identify excluded files, mocked dependencies, missing environments, and untested user journeys. Do not convert a skip into a pass. Propose the smallest safe test that would resolve each important unknown. Do not change production data, spend money, or deploy without asking me.

Read the answer for missing evidence, not just positive language.

If a required check is skipped, restore its prerequisite or run an appropriate equivalent and record the result. If you cannot do either, keep that limitation visible and defer the affected release decision. Do not remove the check just to make the dashboard green.

Review Radar is coming soon. Its planned package brings review-backed research, tailored screen designs, and an AI-readable project folder together with build prompts and acceptance criteria. View the preview and join the email waitlist. Checkout is not open; the package does not promise a finished app, users, or revenue.

A green dashboard should be the beginning of your evidence review, not the end of your thinking.

You can also find me here:

Cloudflare Now Sends Errors to AI Agents: Which Failures Actually Need a Code Fix?

Marcus Kim — Sat, 03 Oct 2026 12:30:53 +0000

Your app has an error. You paste it into an AI coding tool and say, "Fix this."

That sounds reasonable. But what if the app correctly refused an invalid booking? What if an outside email service is unavailable? What if a customer is asking for a feature you never promised?

An AI can produce a convincing code change for all three. None of them necessarily needs one.

On September 30, Cloudflare introduced Issues for Workers in open beta. It groups recurring exceptions, server errors, and error logs, then can send diagnostic context to a configured coding agent. That context includes the affected Worker version. Cloudflare describes a workflow where the agent proposes a fix and the owner reviews and deploys it.

The useful beginner lesson is not "your app can maintain itself now." It is that a reported failure can reach an AI faster, so you need a better decision about what the AI should do next.

I would classify the incident before asking for a patch. Otherwise, "make the error disappear" can quietly become "remove the rule that protected the app."

Start with the promised behavior

Imagine a small appointment-booking app. This is a hypothetical example, not a claim about a client project.

You promised that a customer can choose an available time, confirm a booking, and see that booking when they return. You did not promise that two people can reserve the same appointment, that email never fails, or that every business can support unlimited bookings.

Those distinctions give you a starting point for maintenance. Write down the behavior that should have happened, the behavior you observed, and which part of the promise was broken.

An error message alone is not enough. "Booking failed" might describe a defect, a sold-out appointment, or a temporary connection problem. The remedy depends on which one it is.

Five incidents, five different next steps

1. The app broke its own promise

You reserve an available appointment. The app says "Confirmed," but the booking is missing when you refresh. The same failure happens with a disposable test account.

That is a good candidate for a code investigation. Give the AI a repeatable example and a clear expectation. Ask for a test that fails before the repair and passes afterward.

Keep the change tied to that example. "Repair booking persistence" is a smaller, more inspectable task than "improve the booking system."

Next step: reproduce the defect, identify the responsible code, and propose a narrow repair.

2. The app correctly rejected a request

Two customers try to reserve the same appointment. One succeeds. The other sees a confusing error.

The reservation rule may be working. Removing the rule would make the screen look friendlier while creating a real scheduling problem.

The needed improvement is likely the recovery path: explain that the slot is gone, offer available alternatives, and preserve the customer's other choices. Test the two-customer case again to make sure the clearer message did not weaken the rule.

Next step: improve the explanation and recovery without changing the business constraint.

3. An outside service is unavailable

The booking is saved, but the confirmation email provider is down.

A patch to the booking code cannot make that provider healthy. Worse, an eager rewrite might accidentally create a second booking while trying to resend the email.

Decide what the app should do during the outage. In this example, I would show the saved booking in the app and distinguish it from the email's delivery status. An existing retry mechanism may need investigation, but that is a separate question from whether the booking exists.

Next step: preserve the correct result, communicate the degraded service, and investigate the delivery path separately.

4. The app hit an operating limit

An import works for ten appointments and fails for ten thousand.

That might be a defect. It might also expose an explicit file-size, processing-time, or service limit. First establish the supported workload. Do not ask the AI to disable a limit just because it interrupted a test.

A smaller batch, a background process, or a clearer upload boundary may be appropriate. Choosing among them requires a product decision about what you intend to support and what you are willing to operate.

Next step: confirm the limit, choose the supported workload, and design the handling around that choice.

5. Someone wants a different product

Your appointment app has one location. A customer wants several locations, staff assignments, and recurring group classes.

That is valuable feedback. It is not automatically a bug.

Put it in the product backlog with the user, the desired outcome, and the changes it would require. Ask whether it belongs in the current release. Treating every request as urgent maintenance is an easy way to lose control of a small app.

Next step: make a scope decision before asking the AI to build anything.

Keep a small incident record

You do not need a complicated operations dashboard to make this useful. A note in your project folder can be enough for a first app.

For each incident, record:

What the user tried to do and what should have happened.
What actually happened, including whether any action partially succeeded.
The app version and environment: a local test, beta build, or live release.
A reproduction using test data, with private details removed.
Your current classification and the evidence that supports it.
The person or service responsible for the next step.
What evidence would let you call the incident resolved.

If you are unsure about the classification, write "unknown." That is a useful state. It tells the AI to investigate instead of treating your guess as a fact.

Cloudflare's Issues documentation describes its monitoring feature. You do not have to adopt that specific service to use this incident record. The same questions work with a screenshot, a test failure, or a carefully described customer report.

Give your AI a triage prompt before a repair prompt

Try this with a sanitized incident record inside your project folder:

Read the project description and the promised behavior for this workflow. Compare them with this incident. Classify it as a reproducible defect, expected rejection with poor recovery, outside-service failure, operating-limit problem, new feature request, or unknown. Show the evidence for your classification. Identify any action that may already have succeeded. Do not change code yet. Propose the smallest safe next check using test data, then explain what result would justify a repair.

After that check, a repair prompt can be specific:

Repair only the confirmed defect. Add a regression test for the reproduced case. Preserve the existing business constraints and unrelated behavior. Report the files changed, the checks actually run, any unresolved failures, and the evidence still needed before release.

These prompts do not make the AI infallible. They make its assumptions easier to see and challenge.

Keep "proposed" separate from "released"

A pull request is a proposed change, not a repaired live app. A passing test is evidence for the scenario it checks, not proof that every user journey works.

GitHub documents protected-branch settings for required reviews and status checks. Availability depends on the repository and plan. Check whether your rules apply to the account doing the work rather than assuming an administrator is covered by default.

For a small app, I would still keep a plain release note: the incident, the repair, the version released, the post-release check, and what to do if the problem returns. Then close the incident only after checking the promised behavior in the intended environment.

The point is not to make maintenance bureaucratic. It is to keep a fast AI from confidently fixing the wrong problem.

A practical next step for your first app

Choose one workflow in your app and write its promised behavior. Then classify one failure without editing anything. If you cannot tell which category it belongs to, your next task is collecting evidence, not generating more code.

My $1 AI App Builder Starter Prompts guide beginners from an idea to a first working build. AI App Builder From Zero is $9 and continues through testing, publishing, and launch, with all 40 starter prompts included as a free bonus.

Review Radar is coming soon. It combines public app-review research with an app-specific project folder, screen designs, and sequenced build guidance. Explore the preview and join the email waitlist. It is not available for purchase yet, and no downloads, users, or revenue are promised.

Fix the broken promise. Explain the expected rejection. Manage the outside dependency. Decide the operating limit. Scope the new request. Those are different jobs, even when they all arrive as "an error."

You can also find me here:

Cloudflare's New Crawl Events: A Beginner's Checklist for AI App Background Jobs

Marcus Kim — Fri, 02 Oct 2026 03:15:39 +0000

You ask an app to research ten pages. It returns “Started.” A little later, it returns “Finished.” You open the result and find two usable pages, three errors, and a blank summary.

Was the job successful? The background worker might be done, but the user still does not have the thing you promised.

On September 25, Cloudflare announced lifecycle events for Browser Run crawl jobs. A Queue subscription can receive crawl.started, crawl.updated, and crawl.finished events. That is a useful way to react to a crawl without repeatedly asking for its status.

The more interesting beginner lesson is about what happens after “finished.” If you build an AI feature that gathers pages, generates a report, processes a file, or sends a batch of messages, the status of the worker is only one piece of evidence. Your app still has to retrieve the output, check what worked, and show a truthful result.

In my freelance app work, I have learned to describe what a user can actually do at the end of a workflow. “The job ran” is an internal event. “You can open a report with three checked sources and see why two were excluded” is a user outcome.

If describing that outcome is the hard part of your first build, my $1 AI App Builder Starter Prompts can guide you through the initial workflow. Then use the checklist below to tell your AI coding tool what “done” must mean for any background task.

What the new events tell you

Cloudflare's crawl documentation describes a two-step process. Starting a crawl returns a job ID immediately. Later, you use that ID to get the job's status and results. The new events offer a push-based way to notice changes, but the event does not contain the crawled page content. After a crawl.finished event, you still fetch the results.

The event schemas make the distinction concrete. A crawl.finished payload includes a job status and counts for total, completed, errored, and skipped pages. Cloudflare's example even shows a job with two completed pages and one errored page. A finished crawl can therefore include incomplete source coverage.

Another detail matters if you run several jobs: Browser Run subscriptions are account-wide. A handler has to match the event's job ID to the request your app stored. It should not assume that the next event belongs to the user currently watching the screen.

I would not make a beginner adopt Queues just to build a first prototype. Polling a job-status endpoint can be enough at small scale. The lesson applies either way: a notification tells you to check the work, not to invent its outcome.

The five-check background job checklist

Imagine a small app that turns a public website into a research brief. A user submits a site, the app starts a crawl, and an AI tool summarizes what it finds. This is a hypothetical build example, not a claim about a client project.

Before I call that feature ready, I would run five checks.

1. Can you connect the result to the original request?

Save a record when the user starts the job: who requested it, the target site, when it began, and the provider's job ID. Show the user a pending state tied to that record.

When an event or status response arrives, look up the matching job ID. If it is unknown, do not attach it to whichever brief happens to be open. If the request was cancelled, do not quietly publish a late result as a fresh answer.

Test: Start two research jobs for different test users. Finish them in the opposite order. Each user should see only the result tied to their own request.

2. Did the job end, and how did it end?

“Not running” is not the same as “completed successfully.” Cloudflare documents terminal states that include timeout, account limits, user cancellation, and errors as well as completion. Your UI needs the distinction, even if the labels are simpler than the provider's labels.

Test: Give a test job a failed terminal state. The screen should show a failure or a clear next step, not a success checkmark.

3. How much of the requested work produced usable material?

A completed crawl can still have errored, skipped, or disallowed pages. Compare the final counts and examine the retrieved records. Decide the minimum usable coverage for your product before writing a summary.

For a research brief, I might allow a partial report if it clearly lists which sources were used and which were unavailable. If the missing page is the only source for an important claim, I would withhold that claim. That is a product rule I would choose, not a guarantee Cloudflare makes.

Test: Return two good records, one blocked page, and one empty record. The brief must cite only material it actually has and label its gaps.

4. Did the output make it into the product?

The crawl.finished event is a signal. The full page content comes from a later result request. Your app may then need to parse, summarize, save, and display it. A failure anywhere in that chain can leave a successful provider job with no usable user result.

Write down each state: waiting, collecting, processing, ready, and needs attention are one possible set. Move to ready only after the saved brief can be reopened. Refreshing the page is a cheap, useful proof that the result is durable.

Test: Interrupt processing after the crawl ends but before the brief is saved. The app should preserve the job ID and show a recoverable state, rather than claim the report is ready.

5. Can you explain the result without exposing too much?

Keep a narrow receipt: request ID, provider job ID, terminal status, source counts, result location, and the reason any sources were excluded. That helps you investigate a bad brief without copying entire crawled pages or user inputs into every log.

Cloudflare says Queues provides at-least-once delivery, so a consumer can occasionally receive a message more than once. Use the stored job ID and result record to recognize that repeat. The deeper duplicate-action design deserves its own review; for this checklist, the immediate question is whether a repeated finish signal can overwrite a good report with an empty one.

Test: Deliver the same finish signal twice. The user should still see one coherent report and one honest status.

A prompt to give your AI coding tool

Trace one background job from the user's click to the reopened result. List the request ID, external job ID, every status, where the full output is retrieved, the minimum usable result, and the exact point the UI says “ready.” Show what happens for a failed job, a partial result, a processing interruption, and a repeated completion signal. Propose the smallest change that makes the user-facing status truthful. Do not add a queue unless the existing flow needs one.

Run that prompt on one workflow, then try the five tests with disposable data. You can start with a simple status check and one stored result. Add event subscriptions when they solve a real waiting or coordination problem.

Cloudflare's release makes background work easier to observe. It does not change the definition of a useful app: the person who asked for the work should be able to open the result and understand what it contains.

If you want a guided first action, use my $1 AI App Builder Starter Prompts to write down one user request and its promised output, then apply this checklist to that path.

For the organized route from idea through scope, screens, build, QA, and publication, AI App Builder From Zero is my $9 e-book. All 40 Starter Prompts are included as a free bonus inside its PDF and EPUB, so you do not need the separate $1 pack if you buy the book.

Review Radar is coming soon: preview it and join the email waitlist. It is being built to turn research about an app idea into tailored screens and an AI-ready project folder. Those can make a first build concrete; they do not promise revenue, a finished app, or a background workflow that has passed the checks above. Checkout is not open.

The shortest version: do not mark a job complete until the user can open the result you promised.

You can also find me here: