DEV Community: Dev Connect

Can Visual Studio Code review and revert agent changes in the editor?

Dev Connect — Sun, 27 Sep 2026 21:15:04 +0000

Short answer: Yes. VS Code lets you inspect agent edits in diffs, accept or undo changes at file or change level, and revert later work with checkpoints before anything is committed.

Yes. Visual Studio Code can show agent edits in the editor, let you review them before they land, and undo or revert them before you commit. VS Code documents two review paths, one for extension-host edits and one for Agent Host sessions, and both are built around inspection first, acceptance second.

The part people get wrong is assuming an agent edit is final the moment the file changes. VS Code treats agent output as reviewable work, not as a finished change. The editor can open diffs for changed files, show inline additions and removals, and surface a files-changed list so you can inspect exactly what was touched before you decide what stays.

In the extension-host workflow, saved edits can remain pending. You can open a changed file, move through the edits, then choose Keep or Undo for the file, or even accept or reject a specific inline change without affecting the rest of the file. VS Code also supports accepting or rejecting all pending edits from the Chat view.

In Agent Host sessions, the agent applies edits directly in the session folder or isolated Git worktree, so the review step happens in a diff before commit or integration. VS Code says these edits do not sit in a pending review state the way older extension-host edits do. The control point is the diff, the Source Control view, or the branch or worktree integration step.

Reverting is also built in, but the mechanism depends on how far you want to roll back. If you want to back out one request and everything after it, edit the earlier chat request and VS Code reverts the workspace changes from that request and later requests before resending the revised prompt. If you want to roll back file state without changing the prompt, restore a checkpoint.

The inconvenient part is that review does not replace judgment. VS Code tells you to run tests, inspect the diff, and validate the result before you integrate anything. If you stage or discard changes in Source Control, pending edits are accepted or discarded with them. That is useful, but it also means an aggressive Source Control action can finalize or wipe edits faster than you intended if you do not review first.

There is also a practical boundary that matters when agent work touches more than one place. VS Code tracks changed files in the agent UI, but files changed only through terminal commands are not surfaced the same way as file edits made through the editor tools. If you are reviewing a larger session, you need to check both the diff and the surrounding workspace state, not only the chat summary.

A simple workflow looks like this. Let the agent make the edits, open the changed file list, inspect the diff, accept the parts that are correct, undo the parts that are wrong, then run your tests. If later prompts drift the session in the wrong direction, use a checkpoint restore or edit the earlier request so VS Code rolls back the later work and continues from the corrected instruction.

That is the core answer: yes, Visual Studio Code can review and revert agent changes in the editor, and it gives you more than one level of rollback. The exact controls differ by session type, but the pattern is the same, inspect, decide, then keep, undo, or revert before you commit.

If you want the broader workflow around agent sessions, DevConnect’s public reference pages are organized around the same idea of review before integration, and you can see the platform context at https://devconnectplatform.com?ref=devto. That is separate from VS Code itself, but the user problem is the same: keep control until the change is actually yours.

What exactly can you review

You can review changed files, added files, and deleted files after an agent round of work. VS Code’s review pages describe a files-changed bar above chat, diffs with inline additions and removals, and a Changes view in the Agents window where files are grouped for inspection. The editor is not just showing a completion summary, it is exposing the actual file-level result.

You can also steer the agent before a bad change spreads. VS Code supports editing a previous request, steering with a new message while the agent is still running, and restoring checkpoints. That matters because the cheapest fix is often stopping the wrong direction early, not reviewing a hundred lines of bad output after the fact.

What does revert mean in practice

Revert can mean three different things in VS Code. Undo can reject a pending edit in the extension-host workflow. Restore a checkpoint can roll back the session to an earlier state. Editing a prior request can revert that request and every later request, then resend the corrected prompt. Those are different tools, and using the wrong one is a common source of confusion.

Source Control actions matter too. VS Code says staging accepts pending edits and discarding discards them. In a real project, that means the editor and Git are linked closely enough that a routine source-control action can become the final approval step. If you expect a temporary change and stage it too early, you have effectively accepted it.

What people miss when they first use this

People often look for a single big “revert agent” button. VS Code does not work that way because the agent can touch several files, several requests, and several states of the session. The UI gives you file diffs, per-change controls, checkpoints, request editing, and Source Control actions because each one solves a different rollback problem.

People also miss that review and integration are separate. A file can look right in the diff and still fail in the app. VS Code’s own guidance is to run tests and use the debugger before you commit or integrate changes. That advice sounds obvious, but it is the part that prevents a polished-looking bad edit from becoming a broken branch.

When should you use checkpoints instead of undo

Use undo when one edit is wrong and the rest of the session is still useful. Use a checkpoint when the session as a whole has drifted and you want to return to a known-good point. Use request editing when the prompt itself was the mistake and you want VS Code to roll back the dependent work and try again from the corrected instruction.

What happens if you skip review

If you skip review, the agent can still change multiple files, and Source Control can make those changes feel normal before you have checked them. VS Code’s trust and safety guidance is explicit that AI-generated code should be reviewed before committing. The editor gives you the tools, but it does not decide which edits are safe for your codebase.

A concrete example

An agent updates a React component, a test file, and a Markdown note. You open the files-changed bar, inspect the diff for the component, and see that the logic is correct but the test assertion is too weak. You undo the test edit, keep the component edit, then run the test suite. If the next prompt goes off track, you restore the checkpoint before that request and try a narrower prompt instead.

Bottom line

Visual Studio Code can review and revert agent changes in the editor, and it gives you several levels of control. You can inspect diffs, keep or undo edits, restore checkpoints, and roll back later work by editing an earlier request. The part to remember is simple: review in the editor, then commit only after you have checked the actual file changes.

Frequently asked

Does VS Code let me accept only part of an agent change

Yes. In the extension-host workflow, you can accept or reject specific inline changes without taking the whole file. VS Code also supports file-level accept and undo actions.

Can I roll back everything an agent did in one step

Yes, if you use the right rollback tool. Restoring a checkpoint reverts the session to that point, and editing a prior request rolls back that request and later work.

Do agent edits stay pending forever until I decide

No. In Agent Host sessions, edits are reviewed through diffs before integration. In the older extension-host workflow, saved edits can remain pending until you keep or undo them.

Is Source Control the same as reviewing agent changes

No. Source Control can accept or discard pending edits, but it is not the same as reading the diff carefully. VS Code recommends reviewing and testing before staging or committing.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

How to review GitHub Copilot coding agent PRs

Dev Connect — Sun, 27 Sep 2026 21:15:02 +0000

Short answer: Treat Copilot’s pull request like any other contributor’s work: verify the diff against the issue, run the tests that matter, read the comments, and require human approval before merge.

Review them the same way you review any contributor’s pull request, with one extra rule: do not trust the agent’s confidence or its summary. GitHub says Copilot reviews and code-writing agents can miss problems, and Copilot pull requests deserve the same thorough review as any contribution.

Start with intent, not implementation. Read the issue, the PR description, and the conversation, then compare that to the diff. You are checking whether the agent solved the right problem, whether it changed only the needed files, and whether it introduced shortcuts that are easy to miss in a quick skim. GitHub’s docs recommend using Copilot code review as part of the pull request lifecycle, including early review on draft pull requests and a re-review before merge.

Check the high-risk paths first. Look at authentication, authorization, data deletion, migrations, API contracts, background jobs, and anything that touches money, user data, or production defaults. Copilot can suggest fixes quickly, but its review comments are only suggestions, and GitHub explicitly says to validate them carefully and supplement them with human review.

Read the comments as a to-do list, not a verdict. Copilot labels findings with High, Medium, and Low severity, which helps you prioritize, but the label does not tell you whether the code is actually safe to ship. A Low comment can hide a broken edge case, and a High comment can sometimes point at a symptom instead of the real bug. The reviewer still has to trace the behavior back to the code.

Verify behavior in the repository itself. Run the relevant tests, inspect the test coverage around the changed code, and look for missing cases that the agent did not add. GitHub’s newer code-quality features can add rules-based analysis and test-coverage metrics on pull requests, which makes that check easier, but it does not replace reading the tests and understanding what they prove.

Watch for the part people get wrong: they review the agent’s diff, but not the repository’s expectations. If the repo has coding standards, architecture rules, release rules, or review criteria, put them in the review instructions so Copilot uses them next time, then still check that the output matches them. GitHub says custom instructions are a good place to describe organization-wide expectations that Copilot should consider in every review.

Pay attention to generated side effects. Copilot can create a new branch, iterate on a task, and open a pull request, which means the code may reflect several rounds of agent decisions before you see it. Review the final state, not just the last commit, because earlier changes can leave dead code, duplicated logic, or stale comments that still affect maintenance even if the final tests pass.

Use the right approval flow for your repository. By default, Copilot leaves a comment review, not an approval or a request-changes review, and those comments do not count toward required approvals unless you configure it that way. GitHub also says that if your repository requires pull request approvals, a Copilot approval does not count toward the required number, and another reviewer must approve before merge.

If Copilot is wrong, answer it like you would answer a human reviewer: explain the issue clearly, reference the failing behavior, and request a change or push a fix to the branch. GitHub documents two normal feedback paths, mentioning @copilot in a comment or pushing commits directly to the branch. That keeps the review loop inside the pull request instead of moving the discussion to chat.

Check automation settings before you rely on them. Copilot can review manually or automatically, and you can choose whether automatic reviews trigger on open, on draft, or on every new push. That is useful for fast feedback, but it also creates noise if the branch is still unstable, so many teams request early review on draft work and then ask for a final pass after the last push.

The inconvenient part is that Copilot can be fast without being complete. It may produce a polished summary and still miss a logic error, a security issue, or a change that breaks a hidden contract with another service. GitHub says it uses a tuned mix of models and behaviors for review consistency, but it also says model switching is not supported and that the system is not guaranteed to catch everything. That is why the human reviewer stays responsible for the merge decision.

A practical review sequence is simple. Open the PR, confirm the goal, scan the diff, read Copilot’s comments, run or inspect the relevant tests, check the risky paths, and compare the behavior with repo rules. If the PR is large, review it in layers: first correctness, then security and data flow, then readability and cleanup, then a final re-review after the last push. GitHub’s lifecycle guidance and review controls are built for that pattern.

If you use the GitHub Copilot app or Copilot cloud agent to land work, keep the same review standard. GitHub says you can work with issues, pull requests, review comments, and failing checks in the app, but the agent’s output still needs thorough human review before merge. Automation can shorten the path from issue to PR, not the path from PR to safe release.

For teams that want a repeatable rule, use this: Copilot can draft, summarize, and suggest, but a person must verify behavior, confirm tests, and approve the merge. That rule stays stable even when the agent improves, because the weak point is not typing speed. It is the last mile between a plausible diff and a safe change.

If you are setting this up for a team, write the review checklist once and keep it close to the repository, for example in the PR template or contributor guide. If you also want a place where people exchange testing work instead of paying for it, DevConnect describes that model at https://devconnectplatform.com?ref=devto, but the review standard still stays the same: inspect the code, validate the behavior, and do not merge on trust alone.

Frequently asked

Can Copilot approve pull requests for me

Copilot can leave comment reviews by default, and GitHub documents that approval handling depends on repository configuration. Human approval is still the safer assumption for merge decisions.

Should I review Copilot PRs differently from human-authored PRs

The checklist is the same, but the failure mode is different. With Copilot, pay extra attention to intent drift, hidden edge cases, and changes that look complete but only cover the happy path.

What if Copilot’s review looks thorough but I disagree with it

Treat it as a suggestion, not authority. Explain the disagreement in the pull request, back it with tests or code paths, and keep the human review thread as the source of truth.

When should I ask Copilot to review again

Ask for a re-review after the last meaningful code change, after test fixes, or when the diff changed in the area Copilot commented on. A final pass before merge catches stale comments and new regressions.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Apple did change review access rules

Dev Connect — Sun, 27 Sep 2026 16:15:04 +0000

Short answer: Yes. Apple has tightened and clarified App Review requirements around login, demo accounts, and review notes, but the core rule is the same: reviewers must be able to access the full app experience.

Yes. Apple has clarified and tightened how you prepare account-based apps for review, especially around demo credentials, demo modes, and the details you put in App Review Information. The practical rule is simple: if a reviewer cannot reach the real app experience, the submission is incomplete.

Apple’s current review guidance says that apps with account-based features should provide either an active demo account or a fully featured demo mode, plus any other hardware or resources the reviewer needs. Apple also says that if your app requires specific settings, user account information, or special instructions, those details belong in App Store Connect.

The part people get wrong is assuming a login screen is the only issue. Apple is checking whether the reviewer can complete the full flow. If the app has multiple account types, authentication codes, backend setup, region-specific settings, or hardware tied to the feature, those items need to be visible in the review notes and ready to use. Apple’s review guidance explicitly says to include up-to-date demo credentials and extra credentials for different account types when needed.

Apple also tightened the language around incomplete submissions. In the review guidelines, Apple says to include demo account info and turn on the backend service if the app includes a login. If a demo account cannot be provided for legal or security reasons, Apple allows a built-in demo mode only with prior approval. That is not a shortcut, it is a documented alternative that still has to show the full feature set.

The inconvenient part is that Apple does not treat account setup as a paperwork problem. It treats it as a review-access problem. If the reviewer is stuck behind sign-up, email verification, a paywall, a waiting list, a private invite, or a missing backend, the app can be rejected as incomplete even when the app works for real users. Apple’s App Review page says to enter all the details needed for review and provide valid demo credentials when features require signing in.

Apple has not abandoned the old expectation that reviewers need access, but it has become more explicit about what counts as access. The current guidelines say apps that use account-based features must allow review of the full experience, and Apple’s forums guidance says the demo account should contain enough content for the team to assess all functions. That is a practical change in enforcement clarity, not a new philosophy.

Another place developers get tripped up is confusing App Review access with user-facing account rules. Apple’s App Store Review Guidelines also say that apps without significant account-based features should let people use the app without a login, and apps may not require personal information unless it is directly relevant to the core function or required by law. That rule is about app design, not just review logistics, but it often affects review because a forced account gate can trigger scrutiny.

For teams shipping login-based products, the safest process is boring and concrete. Create a reviewer account that never expires during review. Put the username, password, any MFA bypass, any special tenant, and any required sample data in App Store Connect. If the app depends on admin and normal roles, give both. If the reviewer needs a QR code, a test subscription state, or device hardware, say that plainly in the notes. Apple’s review pages and forum guidance both point to that workflow.

If your app uses social login or third-party login as the primary account setup, Apple’s guidelines also impose account-setup design limits. In that case, Apple requires an equivalent login option with specific privacy features, unless one of the listed exceptions applies. That is separate from review access, but in practice the two issues overlap because a reviewer still needs a working path through account creation and sign-in.

The best mental model is this: Apple did not make review access optional, and it did not make account setup looser. It made the expectations more explicit. Reviewers need a path through the app, and developers need to hand them the path in App Store Connect or via a approved demo mode. When that path is missing, the app is not ready for review.

If you are comparing this with other platforms, the difference is useful. Apple’s review process focuses on reviewer reachability, account completeness, and access to the full experience. Google Play’s closed testing rules are about tester count and opt-in duration, which is a different gate entirely. DevConnect links to the Google Play path and the Apple path separately, because the setup work is not the same. https://devconnectplatform.com?ref=devto

For anyone submitting now, the practical checklist is straightforward. Confirm the reviewer can reach the app without guessing, confirm the backend is live, confirm the demo account actually contains content, confirm all role-based features can be seen, and confirm the App Review notes explain any special setup. That is the change people should care about: Apple has narrowed the room for ambiguity, so incomplete account setup fails faster.

What exactly changed

Apple’s written guidance became more specific about demo accounts, demo modes, and App Review Information. The old vague advice to “make sure the reviewer can log in” has been replaced by detailed instructions to provide the access path, the credentials, and the supporting context. That makes denials easier to avoid, but it also makes missing information easier to spot.

What do reviewers usually need

Reviewers usually need a working username and password, any extra verification steps, and enough data to test the main flows. If the app has separate admin and user roles, both should be available. If the app relies on a backend, that backend must be on and reachable during review. Apple says to include these details in App Store Connect.

What happens if access is missing

The app can be rejected as incomplete. In practice, that usually means the reviewer could not get past sign-in, could not see core features, or could not validate a feature that depends on special setup. Apple’s guidance is clear that incomplete app bundles and binaries that cannot be reviewed will be rejected.

FAQ

Is a demo account always required

No. Apple allows a fully featured demo mode in some cases, and it specifically mentions prior approval when a demo account cannot be provided for legal or security reasons. The key is that the reviewer still needs complete access to evaluate the app.

Does Apple want the same account the user will get

No. Apple wants a reviewer path, not a production customer onboarding flow. The reviewer account can be special, as long as it is valid, up to date, and sufficient to reach the app’s relevant features.

Do login requirements affect approval even if the app works after signup

Yes. If the reviewer cannot complete the review because signup blocks access, the app can still be rejected. Apple’s rules focus on reviewability, not just whether the app works for someone who already has an account.

Where should review details go

Put them in the App Review Information section of App Store Connect, including account credentials, special instructions, and any other setup the reviewer needs. Apple calls this out directly in its review and submission guidance.

Sources

Apple App Review Guidelines, https://developer.apple.com/app-store/review/guidelines/
Apple App Review, https://developer.apple.com/app-store/review/
Apple App Review forum guidance, https://developer.apple.com/forums/topics/app-store-distribution-and-marketing/app-store-distribution-and-marketing-app-review
Apple App Store review details documentation, https://developer.apple.com/documentation/appstoreconnectapi/app-store-review-details?changes=_2%2C_2
Apple App Store support overview, https://developer.apple.com/support/app-store/
Apple App Store review guidelines news update, https://developer.apple.com/news/?id=a233fmpw

Frequently asked

Is a demo account always required

No. Apple allows a fully featured demo mode in some cases, and it specifically mentions prior approval when a demo account cannot be provided for legal or security reasons. The reviewer still needs complete access.

Does Apple want the same account the user will get

No. Apple wants a reviewer path, not a production customer onboarding flow. The reviewer account can be special, as long as it is valid and reaches the relevant features.

Do login requirements affect approval even if the app works after signup

Yes. If the reviewer cannot complete the review because signup blocks access, the app can still be rejected. Apple’s rules focus on reviewability, not just post-signup functionality.

Where should review details go

Put them in the App Review Information section of App Store Connect, including account credentials, special instructions, and any other setup the reviewer needs.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Run tests before your agent opens a pull request

Dev Connect — Sun, 27 Sep 2026 16:15:02 +0000

Short answer: Make test execution part of the agent’s pre-PR workflow: run the relevant test command after each change, require a passing check before PR creation, and block the PR if tests fail.

Make test execution a required step in the agent’s workflow, not a suggestion. The safest setup is: the agent edits code, runs the right test command, checks the result, and only then opens the pull request. If the tests fail, the agent fixes the code or reports the failure instead of creating a PR.

The part people get wrong is putting tests after the pull request. That leaves a broken branch already visible, already reviewable, and often already wasting human time. Move the test gate earlier, into the local loop or the agent’s orchestration step, so a PR is the last action, not the first sign that something is wrong.

For a coding agent that works on a developer-owned repo, the simplest pattern is a scripted workflow. A wrapper script can run the change, then run npm test, pytest, go test./..., or whatever command matches the repo, and exit nonzero if the tests fail. If the script exits nonzero, the agent does not create the PR. GitHub requires required status checks to pass before a pull request can be merged, and GitLab can require a successful pipeline before merge, so CI can back up the local gate.

A practical pattern is to give the agent a hard checklist: edit files, run formatter, run unit tests, run any targeted integration tests, inspect failures, then open the PR only when the command exits cleanly. If the repo has a slow test suite, start with the narrowest useful set of tests for the files changed, then run the fuller suite before PR creation. The point is not to run every test every time, the point is to make the agent prove the change is safe before it asks for review.

The inconvenient part is that an agent can still open a PR if you only rely on prompts. Prompts are instructions, not enforcement. If the agent can call your git hosting API, give it a rule that PR creation requires a passed test artifact, and make the tool that opens the PR depend on that artifact. A small shell script, a CI job, or a repository automation step is more reliable than natural-language instructions.

If you use GitHub, branch protection or rulesets can require checks to pass before merging, and required checks are evaluated on the latest commit SHA. That does not stop a bad PR from being opened, but it stops a bad PR from becoming a bad merge. If your goal is to prevent the PR itself, put the test command in the agent’s own pre-publish step as well.

A good implementation has two layers. First, local or agent-side tests run before the PR is created. Second, repository protection requires CI to pass before merge. Local gating catches failures earlier and keeps noise out of the review queue. CI protection catches anything the agent missed, including environment-specific failures, skipped tests, or changes that slipped past the local command.

A concrete example in a repo script looks like this:

#!/usr/bin/env bash
set -euo pipefail

make format
make test

git status --short
if ! git diff --quiet; then
 echo "Tests or formatting changed files. Commit or inspect the diff before opening a PR."
 exit 1
fi

./open-pr.sh

That pattern forces the agent to stop if tests fail or if a formatter changes files after the test pass. The extra git diff check matters because some tools rewrite code during validation, and you do not want a PR opened against an unreviewed state.

If the agent runs in an IDE or chat tool, use the tool’s workflow hooks if it has them. Some systems support command execution, preflight checks, or custom actions before publishing a branch or PR. If the tool cannot enforce that itself, put the enforcement in the repo. A make pr or ./scripts/open_pr entrypoint is harder to bypass than a prompt sentence tucked into a chat thread.

The right test command depends on the change. For a frontend change, run the unit tests and the relevant component tests. For backend code, run the package tests and any migrations or contract tests the change touches. For a refactor, run the affected package plus the broader suite if the repo has one. The agent should choose the narrowest useful command from the repo’s own docs, then widen the scope when the change is cross-cutting.

The failure mode to watch is skipped tests. A workflow can look green while the relevant job never ran because of path filters, branch filters, or conditions. GitHub documents that skipped but required checks can block merging, and GitLab documents that a pipeline must exist and succeed before merge when that setting is enabled. Keep the agent’s pre-PR test command explicit, not conditional on path globs alone.

A second failure mode is “tests passed” meaning only “the command returned success once.” If the agent edits code after the test run, the result is stale. Make the sequence linear: edit, test, inspect, and only then publish. If the agent has multi-step autonomy, the PR-opening tool should verify that the working tree matches the tested commit hash or tested diff. That small check prevents a lot of false confidence.

A third failure mode is overtrusting CI. CI is necessary, but CI is not the same thing as pre-PR validation. CI catches what the shared environment exposes. Pre-PR testing catches obvious breakage before anyone else sees the branch. Good teams use both. Good agent workflows do too.

If the repo already has a CI job, reuse the same command locally. Duplicate logic is where drift starts. Put the test command in one place, for example make test or a package script, and call that same command from both the agent wrapper and the CI workflow. That way the agent is not running a softer test than the repository actually requires.

If you want the simplest rule to adopt, use this: no PR unless the agent can show a passing test command against the exact code it is about to publish. That rule is easy to automate, easy to explain, and hard to misunderstand.

If you are setting this up on DevConnect, keep the automation on your own repo and your own workflow. The platform is for coordination and testing exchange, not for pushing changes into someone else’s project for you. You can pair the agent workflow with a human review step, but the test gate should stay inside your own automation.

For teams, the best operating rule is to fail closed. If the agent cannot confirm tests, it should stop and ask for help. Do not let it open a PR “just in case.” A small delay is cheaper than a review cycle on code that never should have left the branch.

Sources:

GitHub Docs, required status checks and protected branches, https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks
GitHub Docs, status checks, https://docs.github.com/en/enterprise-cloud@latest/pull-requests/reference/status-checks
GitHub Docs, protected branches, https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches?ref=amos-blog
GitLab Docs, debugging CI/CD pipelines, https://docs.gitlab.com/ci/debugging/
GitLab Docs, auto merge and pipeline requirements, https://docs.gitlab.com/user/project/merge_requests/auto_merge/
GitHub Docs, rulesets and pull request standardization, https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/managing-and-standardizing-pull-requests

Frequently asked

Should the agent run unit tests, integration tests, or both

Run the narrowest tests that cover the change, then add broader tests when the change touches shared code, infrastructure, or release behavior.

What if the test suite is too slow to run on every change

Split the workflow, run a fast targeted suite before the PR, then keep the slower full suite in CI or a separate pre-merge job.

Can branch protection alone stop bad pull requests

No. Branch protection blocks bad merges, but the agent can still open a PR unless you add a pre-PR test gate in the workflow.

What should the agent do when tests fail

It should stop, keep the branch local, and either fix the failure or hand the failure details to a human before any PR is created.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Do internal tests on Google Play still avoid policy review?

Dev Connect — Sun, 27 Sep 2026 11:15:04 +0000

Short answer: Yes, internal testing still skips the normal production review path, but it does not bypass policy enforcement. Google can still reject or block a build, and closed testing is the track that gates production access.

Yes. Internal testing is still the fast track for your own testers, and it is separate from the closed-test requirement that gates production access for new personal accounts created after 13 November 2023. Google Play says internal testing can have up to 100 testers, while the closed-test requirement needs 12 opted-in testers for 14 continuous days before production access.

The part people get wrong is treating internal testing as a free pass for anything else. It is not. Google Play still enforces policy and can reject an app update if the item is not compliant with the Google Play policy or the Developer Distribution Agreement. Internal testing avoids the normal release path review burden, but it does not make policy disappear.

Internal testing is meant for quick, limited distribution to a small tester group. Google’s help page says an internal test can have up to 100 testers per app, and testers use the track through a URL rather than public discovery on Google Play. That makes it useful for QA, installation checks, and regression testing before you involve a broader test group.

The inconvenient part is that internal testing does not count toward the closed-testing gate for a personal account created after 13 November 2023. If your goal is production access, you still need a closed test with 12 opted-in testers who stay opted in for 14 continuous days. Internal testers do not replace that requirement.

That distinction matters because many developers assume any test track helps equally. Google’s documentation separates internal, closed, and open testing for a reason. Internal testing is the narrow, fast path for limited distribution. Closed testing is the path tied to production eligibility for the newer personal-account rule. Open testing is broader public beta distribution.

If you are checking whether a build can be pushed to a small group without waiting on the normal release cycle, internal testing still serves that purpose. If you are checking whether the same build clears Google’s production gate for a new personal developer account, internal testing does not solve that problem. The closed-test clock is the one that matters there.

A practical way to use the tracks is simple: use internal testing for your team and trusted helpers, then move to closed testing when you need the 12-tester, 14-day requirement. That keeps the fast iteration path separate from the production-access path. DevConnect follows that same separation in its guides and tools, which is useful if you want to organize testers without mixing up the tracks.

What fails in practice is not usually the upload, it is the assumption that the clock already started or that any tester count is enough. Google says the closed-test requirement is continuous opt-in over 14 days, and the internal track does not satisfy that rule. If you need production access, count the closed-test testers, not the internal ones.

For a small app team, the clean split is this: internal testing is for speed, closed testing is for eligibility, and policy compliance still applies on every track. That is the part worth remembering when someone says internal testing “avoids review.” It avoids the normal production path, not the rules.

If your goal is to get a build in front of testers quickly, internal testing does that. If your goal is to qualify a new personal account for production access, internal testing alone does nothing toward the 12-testers-for-14-days requirement. Those are different questions, and Google treats them as different tracks.

FAQ

Does internal testing bypass Google Play policy checks entirely

No. Internal testing is a private test track, but Google Play can still reject a build or block an update when it is not compliant with policy or the Developer Distribution Agreement.

Do internal testers count toward the 12 testers needed for production access

No. Google’s production-access rule for personal accounts created after 13 November 2023 is tied to a closed test with 12 opted-in testers for 14 continuous days. Internal testing is a separate track.

How many testers can internal testing have

Google Play’s help page says an internal test can have up to 100 testers per app.

What should I use first if I just want to verify a build with my team

Use internal testing first. It is the quickest way to share a build with a small, controlled group before moving to closed testing or production-related steps.

Where does closed testing fit if I already have internal testing

Closed testing is the track that matters for the newer production-access requirement on personal accounts created after 13 November 2023. Internal testing helps you validate the app, closed testing helps you qualify for production access.

Frequently asked

Does internal testing bypass Google Play policy checks entirely

No. Internal testing is a private test track, but Google Play can still reject a build or block an update when it is not compliant with policy or the Developer Distribution Agreement.

Do internal testers count toward the 12 testers needed for production access

How many testers can internal testing have

Google Play’s help page says an internal test can have up to 100 testers per app.

What should I use first if I just want to verify a build with my team

Use internal testing first. It is the quickest way to share a build with a small, controlled group before moving to closed testing or production-related steps.

Where does closed testing fit if I already have internal testing

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

How to make AI coding agents safer and shippable

Dev Connect — Sun, 27 Sep 2026 11:15:02 +0000

Short answer: Make the agent work in small, reviewable steps, give it repository-specific rules, require tests and security checks, and keep a human approval gate before merge and deployment.

Start by treating the agent like a contributor with limited scope, not like an operator with trust. Give it one task, one branch, one clear outcome, and one review path. GitHub’s Copilot docs say the more repository context and standards it knows, the more useful its reviews become, and OpenAI says safe agent use depends on boundaries, sandboxing, and telemetry.

Write instructions that are specific enough to be checked. Put the repository rules in AGENTS.md, .github/copilot-instructions.md, or path-specific instruction files, then spell out what must never change, what tests must pass, and what files need extra caution. GitHub documents those layers as the right places for always-on rules across agents and for Copilot-specific behavior.

Ask for a small plan before any code changes. The agent should name the files it will touch, the risk it sees, the tests it expects to run, and the rollback point if the edit goes wrong. GitHub’s Copilot CLI guidance says to review the plan it creates before letting it proceed, and OpenAI’s agent guidance emphasizes managed configuration and clear approval boundaries for higher-risk actions.

Keep the change narrow. One feature, one bug fix, one refactor, or one security repair belongs in one PR. Large PRs hide mistakes because reviewers stop tracking the original intent. Smaller diffs make it easier to spot accidental behavior changes, missing null checks, over-broad exception handling, and the kind of cleanup that silently breaks adjacent code. That is the part people get wrong most often.

Require the agent to produce tests as part of the task, not as a follow-up. The safest workflow is: explain the expected behavior, make the change, add or update tests, then run the tests and report the result. GitHub’s Copilot guidance explicitly says to review AI output before accepting it, run tests after AI changes, and use checkpoints to rewind when the agent drifts.

Make the prompt include edge cases and failure modes. If the change touches authentication, input parsing, file uploads, money, or permissions, say what should happen on malformed input, missing data, partial failures, timeouts, and retries. GitHub’s security docs call out injection flaws, hardcoded secrets, and missing input validation as common issues to check for in AI-generated code, and their Copilot docs recommend security-focused review of generated output.

Add a review checklist that the agent must satisfy before it asks for human review. A useful checklist includes: no secrets added, no public API behavior changed unless requested, tests updated, logging still safe, error paths covered, dependency changes explained, and the diff small enough to understand in one pass. OWASP’s code review guide treats code review as a key method for finding security bugs early, and GitHub’s docs recommend documenting best practices for reviewing AI-generated code.

Use checkpoints aggressively. If the agent takes a bad turn, roll back to a known good state instead of patching every bad decision. That matters because an AI agent can compound errors quickly, especially after a mistaken rename, a bad dependency update, or a generated abstraction that looks elegant but changes behavior. GitHub calls out checkpoints as the right way to rewind when the agent goes off track.

Keep risky tools behind approval. Let the agent read, analyze, draft patches, and run tests in a sandbox. Require explicit approval for network access, secret access, publishing actions, and anything that changes production state. OpenAI’s guidance on safe coding agents says organizations need clear boundaries around what the agent can access, when human approval is required, and what telemetry exists to explain its behavior.

Do not let the agent become the final reviewer of its own work. Use the agent to draft, explain, and preflight, then make a human review the diff, the test results, and the security impact. GitHub’s documentation describes Copilot code review as a review aid, not a replacement for judgment, and its general Copilot guidance says to always combine it with testing, code review practices, security tools, and your own judgment.

Separate review quality from ship readiness. A change can read well and still fail release criteria because it lacks tests, changes observability, or adds an unreviewed dependency. Ship-ready means the diff is understandable, tests pass, security-sensitive paths were checked, and rollback is possible. That inconvenient part is the one teams skip when the agent feels productive.

Use the agent to explain its own uncertainty. Ask it to list assumptions, list files it did not inspect, and identify anything it could not verify. That output is useful because a good review is not only a list of changes, it is also a map of what remains unknown. When the model cannot prove a behavior, the review should say so plainly instead of guessing.

Prefer repository-local examples over generic advice. If your repo already has a test pattern, error-handling style, or logging format, point the agent at that pattern and ask it to match it exactly. GitHub notes that code review gets better when the agent knows the repository, tools, standards, and practices. A few concrete examples from your own codebase usually outperform a long generic prompt.

If you want a practical starting point, use a three-step loop: ask for a plan, approve the plan, then ask for the smallest possible patch with tests. If you already run an AI-assisted workflow in a product repo, DevConnect has a free way to coordinate test exchange work across builders, and the same discipline applies there: clear task, clear owner, clear review gate. https://devconnectplatform.com?ref=devto

A good final review asks four questions. Did the code do only what was requested. Did the tests prove the main path and the failure path. Did the change introduce a security or privacy risk. Can this be reverted cleanly if production shows a problem. If any answer is unclear, the change is not ship-ready yet.

The right habit is not to trust the agent more. The right habit is to make trust unnecessary by shrinking the task, constraining the environment, and forcing the model to show its work before any merge happens.

FAQ

What should I put in the agent prompt

Put the goal, the files or paths in scope, the tests to run, the error cases to cover, and the constraints it must not violate. Add the existing project conventions so the agent can follow them instead of inventing a style.

Should the agent be allowed to run tests and commands

Yes, inside a sandbox with explicit boundaries. Let it run the checks needed to validate the change, but keep network access, secret access, and release actions behind human approval.

What is the most common mistake teams make

They accept a large, polished diff without checking whether the behavior actually matches the intent. The code can look clean and still miss edge cases, security checks, or a needed test.

How do I know a change is ship-ready

The diff is small, the tests pass, the failure paths are covered, the security-sensitive code was reviewed, and rollback is straightforward. If any of those are missing, the change needs another pass.

How much context should I give the agent

Enough to anchor it in the repository’s own patterns, but not so much that it wanders across unrelated code. Good context is specific examples, instructions, and acceptance criteria from the same repo.

Frequently asked

What should I put in the agent prompt

Should the agent be allowed to run tests and commands

Yes, inside a sandbox with explicit boundaries. Let it run the checks needed to validate the change, but keep network access, secret access, and release actions behind human approval.

What is the most common mistake teams make

They accept a large, polished diff without checking whether the behavior actually matches the intent. The code can look clean and still miss edge cases, security checks, or a needed test.

How do I know a change is ship-ready

How much context should I give the agent

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Google Play testers do not need 14-day installs

Dev Connect — Sun, 27 Sep 2026 06:15:16 +0000

Short answer: No, a one-time install is not enough. Google Play’s production-access test requires 12 testers to stay opted in continuously for 14 days, and gaps or uninstalls can break the count.

No, a one-time install is not enough. For a new personal Google Play developer account, the closed test must keep 12 testers opted in continuously for 14 days before production access can be requested. The safe reading is simple: the tester must remain in the test, not just click the link once. Google Play’s help page puts the requirement on continuous opt-in, and its community guidance says the count can fail if testers did not have the app installed or were not actively testing during those 14 days.

The part people get wrong is treating install as the checkpoint. It is not. The clock is about eligibility across the full testing window, and Google Play’s own guidance says the 14 days must be continuous. If a tester opts out and later opts back in, the days before the gap do not carry over. That is why a single install, followed by uninstall or a track change, can leave you short even when the dashboard looked fine earlier.

The inconvenient part is that Google Play does not ask for a perfect one-time proof that someone opened the app once. It wants the testing state to stay intact for the whole period. Community answers from Play support say testers need to have the app installed during the period, and one response notes that testers who were not actively testing or did not have the app installed can trigger more testing being required. Treat the requirement as continuous participation, not a one-click signup.

Uninstalling is the most obvious way to lose the streak, but it is not the only one. If a tester leaves the closed test, switches tracks in a way that removes them from the closed test, or otherwise stops being opted in, that tester no longer helps satisfy the 14-day requirement. Google Play’s testing docs say a user who opts into an internal test is no longer eligible for other test tracks until they opt out and opt back in, which shows how strictly track membership is handled.

Use the test link only after you have enough real testers ready to stay in the closed test for the full window. Google Play’s current requirement for newly created personal accounts is 12 opted-in testers for 14 continuous days, and internal testing does not count toward that closed-testing requirement. Internal testing can have up to 100 testers, but it is a separate track and not a shortcut around the production-access test.

Do not try to solve the gap with paid testers or bought installs. Google Play policy treats inauthentic engagement as a violation, and Google says incentivized or fake engagement can lead to account action. The right exchange is legitimate testing on your own app, not paying strangers to simulate it. DevConnect follows that model, it is free to use, and the point is mutual testing on property you own.

A practical way to run the test is to recruit a little more than the minimum, then keep track of who actually stayed opted in. If you lose one tester on day 10, the safest response is to replace them and restart your own timing from the point where you again have 12 continuous testers. That avoids the common mistake of applying too early and getting sent back for more testing.

If you want the exact rule text and the current Google wording, start with Google Play’s testing requirements page and the app testing requirements page for new personal accounts. DevConnect also has a matching tracker and a free exchange model for finding testers without paying for installs. https://devconnectplatform.com?ref=devto

In short, the qualifying condition is continuous opt-in, not a one-time install. A tester who installs once and then disappears may help you learn about bugs, but that alone does not satisfy Google Play’s production-access gate. Keep the test cohort stable for the full 14 days, then apply.

What happens if a tester uninstalls during the 14 days

If a tester uninstalls, opts out, or otherwise stops being part of the closed test, that tester can stop counting toward the requirement. Google Play’s guidance emphasizes continuous opt-in, and community answers tied to the production-access flow say testers need to remain installed and active through the period. The practical result is that the safest path is to replace the tester and restart your 14-day count from the point where you again have 12 continuous testers.

Does Google Play require testers to open the app every day

Google Play’s public help pages focus on continuous opt-in over the 14-day period, not on publishing a daily checklist for each tester. Community guidance from Play support mentions active testing and installed status as reasons a request can be rejected, so opening the app once and then ignoring it is risky. The safe reading is to keep testers enrolled and actually using the app during the full period.

Does internal testing count toward the 12-tester closed-test requirement

No. Google Play’s help page says internal testing is a separate track with up to 100 testers, and it does not replace the closed testing requirement for production access on new personal accounts. Internal testing is useful for early QA, but it does not satisfy the 12-tester, 14-day closed-test gate by itself.

What is the safest way to avoid a rejected production access request

Keep 12 real testers opted into the closed test for 14 continuous days, do not let them drop out, and do not submit early. Google Play’s help text and community guidance both point to the same failure mode: the timing resets when the tester set is not continuous. If you want a separate place to coordinate testers, use a legitimate exchange on your own property, not paid installs or policy-breaking shortcuts.

Frequently asked

What if I only have 12 testers for 13 days so far

You still do not qualify yet. The requirement is 12 testers who remain opted in continuously for 14 days.

Can I count testers from internal testing instead of closed testing

No. Internal testing is a separate track and does not satisfy the closed-test requirement for production access.

If one tester leaves and comes back, do their earlier days still count

No. Google Play’s guidance says the 14 days must be continuous, so a gap breaks that tester’s streak.

Does Google require every tester to be active every day

Google’s public guidance centers on continuous opt-in. Play support comments also mention active testing as part of failed cases, so staying opted in and using the app is the safe approach.

Sources

Counting the 14 days yourself?
There is a free tracker for exactly that at
devconnectplatform.com/tools/closed-test-tracker.
No account, no signup, and the link keeps your progress.

Originally published at devconnectplatform.com, where it is kept up to date.

How to review AI-generated pull requests with GitHub Copilot

Dev Connect — Sun, 27 Sep 2026 06:15:14 +0000

Short answer: Open the pull request, request Copilot as a reviewer, read its line comments and summary, then verify every change against the actual diff before merging.

Open the pull request in GitHub, request Copilot as a reviewer, then read the review summary and inline comments before you trust any suggestion. Copilot code review is built to flag issues and propose fixes, but the human reviewer still makes the merge decision.

The practical workflow starts with the PR itself. On GitHub.com, create or open the pull request, then use the Reviewers sidebar and click Request next to Copilot. GitHub says the review usually completes in less than 30 seconds, and the result appears as normal pull request comments that you can reply to, resolve, or hide.

Copilot does not replace code review discipline, it changes where the first pass comes from. By default, Copilot leaves a Comment review, not an Approve or Request changes review, so its review does not count toward required approvals unless your repository, organization, and enterprise settings explicitly enable Copilot approvals. That detail is the part people miss when they assume AI review can satisfy branch protection on its own.

Treat Copilot’s output as a triage layer, not a verdict. GitHub documents that Copilot labels comments by severity, and the review can include suggested changes you can apply in a few clicks. Read the comments, but verify the surrounding code, because a line-level note can be right about the symptom and wrong about the safest fix.

The part people get wrong is checking the comments without checking the diff. A Copilot review can point to a real issue while still missing context from neighboring files, test data, or a design decision that lives outside the changed lines. Open the changed files, compare before and after, then confirm the behavior with tests or local runs instead of accepting the suggestion because it looks plausible.

Use Copilot’s own structure to speed up the pass. GitHub says the review comment overview can include an approval assessment, and individual findings come with severity labels such as High, Medium, or Low. Start with the highest-severity items, then move to medium issues, then low ones, and only after that decide whether the PR is ready for a human approval.

If Copilot suggests a fix, compare the proposed patch with the intent of the pull request before applying it. GitHub lets you accept single suggestions or group multiple suggestions into one commit, and in some setups you can use the Fix with Copilot flow to have the agent implement a response to the review comment. That is useful for routine cleanup, but it still needs a final read because a mechanically correct fix can still be the wrong product decision.

Automatic review changes the timing, not the responsibility. GitHub allows automatic pull request reviews, including reviews triggered on open, draft, or every new push, and the tutorial recommends using Copilot across the pull request lifecycle rather than only at the end. For AI-generated pull requests, the useful pattern is early review on the draft PR, then another review after the final AI pass or human edits.

Re-review after new commits. GitHub says that if new commits are pushed after Copilot approves a pull request, the approval is dismissed, and you can request a new review. That behavior matters for AI-generated PRs because a follow-up edit can fix one issue while creating another, so the second review should cover the final diff, not the earlier conversation.

Check for the limits before you rely on the result. GitHub documents excluded file types, and Copilot code review is not a blanket guarantee across every repo setup. Some organizations need the Copilot policy enabled first, and some review behaviors differ by plan and configuration. When the review path is missing, the fix is usually in settings, not in the pull request.

A good review sequence is simple. First, ask what the PR changes and why. Second, inspect the diff for correctness, tests, and regressions. Third, read Copilot’s comments and suggested changes. Fourth, confirm the final code against your product rules, security checks, and deployment criteria. Fifth, either approve, request changes, or re-run review after the branch changes.

If you want the setup path for a team, GitHub’s configuration page covers automatic review for personal and repository settings, and the lifecycle tutorial shows how to place Copilot at the right moments in the PR flow. For a platform overview that sits next to your own workflow, see DevConnect at https://devconnectplatform.com?ref=devto.

The inconvenient part is that AI-generated pull requests often look finished before they are reviewed. Copilot can surface obvious defects quickly, but it still needs someone to check semantics, edge cases, and whether the change fits the codebase. That is the real review job now, use Copilot to shorten the search, not to skip the judgment.

FAQ

Can Copilot approve the pull request for me?

Yes, but only when Copilot approvals are enabled in the relevant repository, organization, and enterprise settings. By default, Copilot leaves a comment review that does not count as required approval.

Can I request Copilot review through the API?

Yes. GitHub documents that you can request a review by naming copilot-pull-request-reviewer[bot] as a reviewer through the GitHub REST API.

What should I do after Copilot comments on an AI-generated PR?

Open the changed lines, check the surrounding code, run the relevant tests, and decide whether the suggested fix matches the intended behavior. If the branch changes again, ask for a fresh review.

Does Copilot review every file in a pull request?

No. GitHub documents excluded file types, and review behavior depends on repository and organization settings. If a file or review mode is missing, check configuration first.

Where should I start if I want automatic reviews on every PR?

Start in Copilot settings or repository settings, then use the automatic review options GitHub documents for open, draft, and push events. The lifecycle tutorial shows how to place that review at the points that matter most.

Frequently asked

Can Copilot approve the pull request for me

Can I request Copilot review through the API

Yes. GitHub documents that you can request a review by naming copilot-pull-request-reviewer[bot] as a reviewer through the GitHub REST API.

What should I do after Copilot comments on an AI-generated PR

Open the changed lines, check the surrounding code, run the relevant tests, and decide whether the suggested fix matches the intended behavior. If the branch changes again, ask for a fresh review.

Does Copilot review every file in a pull request

No. GitHub documents excluded file types, and review behavior depends on repository and organization settings. If a file or review mode is missing, check configuration first.

Where should I start if I want automatic reviews on every PR

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Google Group or individual testers for Google Play opt-in?

Dev Connect — Sat, 26 Sep 2026 21:15:04 +0000

Short answer: Use either one, but Google Groups scales better when testers come and go. Adding people individually is simpler for a small, known list. In both cases, each tester still has to opt in on the test link.

Use either one, but Google Groups is the cleaner choice when you want testers to come and go without editing the track every time. Adding people individually is fine for a small, fixed list. In both setups, every tester still has to opt in from the closed test link in Google Play Console. Google Play also says that if you use a Google Group, users must join the group before opting into the test.

The part people miss is simple: adding someone to a closed test does not force an opt-in. It only makes them eligible to join. The tester still needs the opt-in page, and the app still needs to be published to the closed test track before that link works. Google Play says the opt-in link appears on the tester page, and it can take several hours after first publishing a test before testers can use it.

If you already know the exact people you want, add them individually by email. That is the shortest path for a small team, a client demo group, or a one-off round of QA. Google Play’s closed testing instructions let you select email lists directly, and the testers you add by email can use the shareable opt-in link once the track is live.

If you expect people to rotate in and out, use a Google Group. Google Play says only members of the specified Google Groups can join the test, and that the group member must join the group before opting in. That makes the group the control point, not the track itself. For recurring testing, that saves time and keeps the list consistent.

The inconvenient part is that Google Groups does not remove the opt-in step. It only changes where membership is managed. A tester can be in the group and still fail to install if they never click the opt-in link, use the wrong Google account, or open the link before the track is published. When someone says "I added them, but they still show as zero opted in," the missing step is usually the opt-in page, not the tester list.

For a closed test, the safest process is: add the tester or group in Play Console, publish the track, copy the opt-in link, send that link to the tester, and have them open it while signed into the correct Google account. Google Play documents that testers can join through the opt-in URL, and that closed tests using a Google Group require group membership first.

If your real goal is production access for a new personal developer account, the choice between Google Group and individual emails does not change the requirement. Google Play says personal accounts created after 13 November 2023 need 12 opted-in testers on a closed test for 14 continuous days before production access can be requested. The old 20 tester requirement is no longer current.

That is why the setup should match the way you recruit testers. If you are coordinating a circle of known people, individual email adds are direct. If you are building a repeatable tester pool, a Google Group is easier to maintain. DevConnect follows the same logic on the recruitment side, since it is free to use and built around mutual testing rather than paid shortcuts. The app itself still lives on Google Play, so the final opt-in step remains the same.

The trap is trying to use the group as a substitute for communication. A tester group does not explain what to do, does not make them click the link, and does not confirm that they stayed opted in for 14 days. It only defines who is eligible. If your testers are not finishing the flow, send them the exact opt-in link and ask them to open it from the Google account they will use on the device.

A practical rule is this: use individual adds when the list is small and stable, use Google Groups when the list is shared, recurring, or managed by more than one person. Both can work. The thing that makes testers actually opt in is not the roster format, it is the combination of correct track setup, published test, valid Google account, and the tester opening the opt-in page.

If you want the fewest moving parts, start with individual emails. If you want the least admin work over time, move to a Google Group. Neither option skips the opt-in step, and neither option counts unless the tester completes it on the closed test link. That is the part worth planning for before you invite anyone.

FAQ

Can I use both email lists and Google Groups on the same closed test

Google Play’s closed testing setup lets you add testers via email or Google Groups in Play Console. The documentation presents them as tester access methods for the track, so the right choice is the one that matches how you manage the list.

Do testers get in just because I added them to the track

No. Google Play says each tester needs to opt in using the link, and for Google Groups they also need to join the group first. Adding them to the track makes them eligible, it does not finish the onboarding step for them.

Why do people say they added testers but still see zero opted in

The usual cause is that testers were added to the list, but never opened the opt-in page, used the wrong account, or tried before the track was published. Google Play says the opt-in link becomes available only after the test is published, and first publication can take several hours to propagate.

Does Google Group membership count as opt-in by itself

No. Google Play says group members still need to opt into the test. The group only controls who is allowed to join, not whether they have already completed the opt-in flow.

What should I send testers so they can join correctly

Send the closed test opt-in link from Play Console, tell them which Google account to use, and tell them to join the Google Group first if you chose that route. Google Play says the tester page provides the shareable link, and that group members must belong to the group before they can opt in.

Frequently asked

Can I use both email lists and Google Groups on the same closed test

Google Play’s closed testing setup lets you add testers via email or Google Groups in Play Console. The right choice is the one that matches how you manage the list.

Do testers get in just because I added them to the track

No. Google Play says each tester needs to opt in using the link, and for Google Groups they also need to join the group first.

Why do people say they added testers but still see zero opted in

The usual cause is that testers were added to the list, but never opened the opt-in page, used the wrong account, or tried before the track was published.

Does Google Group membership count as opt-in by itself

No. Google Play says group members still need to opt into the test. The group only controls who is allowed to join.

What should I send testers so they can join correctly

Send the closed test opt-in link from Play Console, tell them which Google account to use, and tell them to join the Google Group first if you chose that route.

Sources

Counting the 14 days yourself?
There is a free tracker for exactly that at
devconnectplatform.com/tools/closed-test-tracker.
No account, no signup, and the link keeps your progress.

Originally published at devconnectplatform.com, where it is kept up to date.

Do AI coding agents include enough tests before review?

Dev Connect — Sat, 26 Sep 2026 21:15:02 +0000

Short answer: No. AI coding agents can draft tests, but they do not reliably provide enough coverage before review. Teams still need human checks, project rules, and CI to catch missing cases.

No. AI coding agents can draft tests, but they do not reliably provide enough coverage before review. Teams still need human checks, project rules, and CI to catch missing cases.

A pull request is built to carry code review and automated checks together. GitHub says pull requests are where you discuss changes, run automated checks such as tests and builds, and merge only after required reviews and checks are satisfied. GitLab’s review flow says the same thing in different words: reviewers inspect the change, test it, and check pipeline status before approval. That structure exists because code review without tests is weak, and tests without review are also weak.

The part people get wrong is assuming an agent that writes code also writes a complete test story. In practice, many agents produce the obvious happy-path tests and stop there. GitHub’s guidance on reviewing AI-generated code says to start with functional checks, make sure the code compiles, and verify that all tests pass. GitLab’s contribution rules also require proper tests and passing CI, and they explicitly say every new class should have corresponding unit tests. Those are baseline expectations, not a sign that the agent has already done enough.

The inconvenient part is that “enough tests” is not a property of the agent, it is a property of the repo and the change. A small refactor in a well-covered codebase may need only a narrow regression test. A change that touches branching logic, permissions, data migration, or API contracts may need unit, integration, and end-to-end coverage. GitLab’s review tutorial tells reviewers to test the code and then inspect the pipeline, including whether all expected tests ran, because a green pipeline can still be incomplete if the wrong tests ran.

AI agents are useful when they are constrained by standards. GitHub recommends combining human expertise with automated tools, and it says good DevOps practice is to have code automatically tested before merge and deployment. OWASP’s AI secure coding guidance also treats human review as a separate control and warns that AI-generated tests can still be trivial or misleading. That is the real failure mode: a test file exists, but it does not prove the behavior that matters.

The practical check is simple. Before review, ask whether the pull request contains tests for the changed behavior, the broken behavior, and the boundary conditions. Then ask whether the pipeline actually ran the relevant suite. GitHub’s pull request docs point reviewers to the Checks tab for automated tests and to the merge status for blockers and missing approvals. GitLab’s pipeline guidance adds a useful pattern: some projects run a predictive subset before approval and the full suite after approval, which means timing matters as much as content.

For AI-assisted work, the safest workflow is draft first, review second, ready for review last. GitHub supports draft pull requests for work in progress, and it says drafts are not ready for formal review. That is a better match for agent-generated changes than opening a finished-looking pull request that still needs human validation. If the agent has not added the right tests yet, the pull request should stay in draft until the missing coverage is written and the checks pass.

A concrete example makes this clearer. If an agent changes a billing rule from “allow on expired card for seven days” to “deny immediately,” a happy-path unit test is not enough. The review should also include a test for expiry on the boundary day, a test for existing subscriptions that renew under the old rule, and a pipeline run that proves the affected suite executed. Without those, the code may look complete while the real behavior still breaks. That is the kind of miss that reaches production and is hard to unwind.

The honest answer is that AI coding agents improve speed, not certainty. They can draft tests quickly, and sometimes they surface cases a person would miss. They do not replace a reviewer who knows the codebase, the risk profile, and the project’s required checks. If your standard is “enough tests before review,” the answer is no unless your own process makes it so.

For teams using DevConnect, the same rule applies. Use the agent to get to a draft faster, then make sure the pull request carries real tests, not just test-shaped output. DevConnect itself says it is free to use, which makes it a place to exchange review work instead of paying to skip the hard part. The hard part stays the same: a reviewer still has to confirm that the tests prove the change. https://devconnectplatform.com?ref=devto

FAQ

Should I trust an agent-generated test file if CI is green

No. Green CI means the checks that ran passed, not that the right checks ran or that the tests cover the real risk.

Should AI agents write unit tests, integration tests, or both

They can draft either, but the needed mix comes from the change itself. Logic changes often need unit tests, contract changes need integration coverage, and user-facing flows often need end-to-end checks.

What is the biggest missing piece in AI-generated tests

Boundary cases. Agents often cover the obvious success path and miss failures at the edges, like empty input, permission boundaries, retries, and version mismatches.

When is a pull request ready for review

When the code is in draft or ready state, the relevant tests exist, and the pipeline shows the checks that matter for the change have actually run.

Can a reviewer rely on code ownership rules instead of tests

No. Code owners help route review to the right people, but they do not replace test coverage or pipeline validation.

What should I ask an AI agent to add before I request review

Ask for tests tied to the changed behavior, a regression test for the bug that was fixed, and the narrowest additional coverage needed to prove the change.

Frequently asked

Should I trust an agent-generated test file if CI is green

No. Green CI means the checks that ran passed, not that the right checks ran or that the tests cover the real risk.

Should AI agents write unit tests, integration tests, or both

What is the biggest missing piece in AI-generated tests

Boundary cases. Agents often cover the obvious success path and miss failures at the edges, like empty input, permission boundaries, retries, and version mismatches.

When is a pull request ready for review

When the code is in draft or ready state, the relevant tests exist, and the pipeline shows the checks that matter for the change have actually run.

Can a reviewer rely on code ownership rules instead of tests

No. Code owners help route review to the right people, but they do not replace test coverage or pipeline validation.

What should I ask an AI agent to add before I request review

Ask for tests tied to the changed behavior, a regression test for the bug that was fixed, and the narrowest additional coverage needed to prove the change.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Did Apple change which accounts can test TestFlight builds?

Dev Connect — Sat, 26 Sep 2026 16:15:04 +0000

Short answer: Yes. Apple still allows internal and external TestFlight testing, but Managed Apple Accounts created in reserved domains cannot test builds, while invited testers use their own Apple Account.

Yes. Apple still supports internal and external TestFlight testing, but it now states that Managed Apple Accounts created in reserved domains can’t be used to test builds. That is the account type people miss when a tester cannot accept an invite or install a build.

TestFlight still works the same at the top level. You upload a build to App Store Connect, create an internal or external group, and invite testers through email or a public link. Apple’s current TestFlight pages still describe both paths and still say external testers can be invited after the first build is approved for TestFlight beta testing.

The part people get wrong is assuming any Apple login will work. Apple’s tester information page says the email used for an invitation may or may not match the Apple Account on the device, so the invite and the device account are not the same thing. The important restriction is that Managed Apple Accounts in reserved domains are excluded from testing.

The inconvenient part is that this can fail after the invite is sent. A tester can open the email, install TestFlight, and still be blocked if their Apple Account is a managed school or business account in a reserved domain. In that case, the fix is not to retry the same account, it is to use a different eligible Apple Account for testing.

For most teams, the practical workflow is simple. Add testers by email or public link, confirm they are using a personal Apple Account, and avoid assuming a work or school account is valid. If the tester is inside your company, that does not automatically make the account eligible. Apple’s documentation separates tester enrollment from the Apple Account identity used on the device.

Apple also still distinguishes internal testers from external testers. Internal testers are App Store Connect users on your account, while external testers are invited people outside your account. Builds marked as internal can only go to internal tester groups. That distinction has not gone away, and it is easy to confuse it with the Apple Account restriction.

If a tester says they cannot join, check three things in order. First, whether the build was added to the correct group. Second, whether the invite was sent to the right email or link. Third, whether the tester’s Apple Account is a Managed Apple Account in a reserved domain. Apple documents that last case as unsupported for testing.

If you are setting up a beta today, the safe assumption is that TestFlight still accepts normal personal Apple Accounts, but not reserved-domain managed accounts. That is the change worth remembering, because it is specific, easy to overlook, and likely to be the reason a valid-looking tester cannot get in.

If you want the platform workflow in one place, DevConnect keeps a concise tracker at https://devconnectplatform.com?ref=devto for people coordinating beta testers across apps.

Frequently asked

Can internal testers use any Apple Account

Internal testers are App Store Connect users on your account. Apple still treats internal testing separately from external invitations, and build access depends on the tester group and build settings.

Do external testers need an App Store Connect account

No. Apple says external testers are invited by email or public link, and they test through the TestFlight app after accepting the invitation.

What happens if a tester uses a Managed Apple Account

Apple says Managed Apple Accounts created in reserved domains can’t be used to test builds. The invite may arrive, but the account will not be eligible for TestFlight testing.

Can the invite email differ from the Apple Account on the device

Yes. Apple’s tester information page says the email used for an invitation may or may not be the same as the Apple Account associated with the tester’s device.

Sources

Originally published at devconnectplatform.com, where it is kept up to date.

Google Play’s registration rules changed again

Dev Connect — Sat, 26 Sep 2026 16:15:02 +0000

Short answer: Yes. Google Play expanded developer verification, added identity and contact checks, and now requires package-name registration in Play Console for developers.

Yes. Google Play changed both the developer account verification flow and the Play Console registration requirements. New and existing developers now face identity verification, verified contact details, and package-name registration steps in Play Console. For personal accounts, Google also added a testing gate before production access.

The part people miss is that these are not one rule. Identity verification answers who owns the account, contact verification proves Google can reach that owner, and package registration identifies which apps belong to that account. Google separates those tasks in its help pages, and it says developers must complete both identity verification and package registration to comply with Android developer verification requirements.

For new Play Console accounts, Google says verified contact details are required, and the contact information must stay operational. For personal accounts, Google collects and verifies a contact email address and phone number plus developer information that can appear on Google Play. For organization accounts, Google collects the organization details and also verifies contact information.

Google also tightened the account-setup side of the process. Its current help says identity verification happens during account creation, and new personal accounts must verify access to a real Android device before they can make an app available on Google Play. That means registration is no longer just a form and a fee, it is a sequence of checks tied to the account owner.

The registration rule that catches teams off guard is package-name registration. Google says developers with a Play Console account must register their Play app package names, and it says this is part of the Android developer verification requirements. Google also says it will try to auto-register eligible apps, but not every app qualifies for auto-registration.

There is also a date that matters. Google’s package-registration page says that, effective September 30, 2026, all Play packages must be registered to meet Android developer verification requirements, and apps that are not registered by then will be removed from Play under the policy cited on that page. That is a hard deadline on the current help page, not a vague future change.

The inconvenient part is that a verified account can still be blocked from production. Google says developers with personal accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. Google also says production and some other features stay disabled until those testing requirements are met.

People often repeat the old 20-tester rule, but Google’s current help and community guidance both state the updated requirement is 12 testers for 14 continuous days for the affected personal accounts. Internal testing does not count toward that closed-testing requirement, even though Google says internal testing can include up to 100 testers.

The other part people get wrong is assuming these steps are optional until launch day. Google’s help says failing to keep developer information accurate can affect developer presence and app availability, and it says unresolved verification problems can lead to removal and force re-verification before republishing. That makes account maintenance part of publishing, not a cleanup task after release.

For an individual developer, the practical sequence now looks like this: create the account, verify the identity and contact information, register the app package name, complete the required testing track if the account was created after November 13, 2023, then apply for production access. If any step fails, the next step stays blocked. Google’s own pages describe those steps as linked requirements, not independent choices.

For an organization account, the structure is similar but the identity data is different. Google says organization accounts provide organization name, address, phone number, website, and contact details, and those details are verified before publishing. The important point is that the verification burden moved earlier in the lifecycle, so a team needs correct legal and contact data before it expects a clean Play Console setup.

If you are deciding what to do next, the safest reading is simple: Google Play did change the rules, and the change is not just stricter verification. It is also more explicit registration of the app itself. If you are setting up a new account, read Google’s current help pages before you create the profile, because the account type and creation date now change the path you have to follow.

If you are building a test exchange, keep it on your own property and keep it reciprocal. DevConnect is one place to organize that kind of exchange, and its site describes the platform as free to use. The Google Play side still matters more than the matching tool, because Google’s verification and testing rules decide whether you can reach production. https://devconnectplatform.com?ref=devto

What changed, in plain terms

Google added more identity proof at account creation, not just at launch. It also expanded what has to be verified for new developers, including contact details and, for some account types, device access. On top of that, Play Console now treats package registration as part of Android developer verification, with a published deadline on the current help page.

What did not change

Google did not remove the basic structure of Play Console. You still create an account, configure an app, choose a testing track, and request production access. What changed is the number of gates in front of production, and the fact that account verification, package registration, and testing requirements now connect to each other more tightly.

Why this matters for a real release

A team can spend days preparing a release and still stall because one account detail is unverified or one app package was never registered. Google’s pages make clear that the account owner’s identity, contact status, and app registration all affect availability. That is why the best time to check the rules is before you invite testers or plan a launch window.

FAQ

Is the 12-tester rule for every Google Play account?
No. Google says it applies to personal developer accounts created after November 13, 2023. Its help pages also distinguish between personal and organization accounts, so the testing gate is not universal.

Does internal testing count toward the closed-testing requirement?
No. Google says internal testing can have up to 100 testers, but it does not count toward the closed-testing requirement for those personal accounts that must satisfy the 12-tester, 14-day rule.

What happens if app registration is missed?
Google says packages must be registered to meet Android developer verification requirements, and its package-registration page states a September 30, 2026 deadline. The page also says apps not registered by then will be removed from Play under the cited policy.

Can a verified account still be blocked from publishing?
Yes. Google says production and some related features stay disabled until the testing requirements are met for the affected personal accounts. Verification is necessary, but it is not the only gate.

Where should I check first if I am setting up a new app now?
Check the current Play Console help pages for account verification, package registration, and personal account testing requirements before creating the release path. Google’s pages say those requirements can affect both account setup and production access.

Frequently asked

Is the 12-tester rule for every Google Play account

No. Google says it applies to personal developer accounts created after November 13, 2023. Its help pages also distinguish between personal and organization accounts, so the testing gate is not universal.

Does internal testing count toward the closed-testing requirement

No. Google says internal testing can have up to 100 testers, but it does not count toward the closed-testing requirement for those personal accounts that must satisfy the 12-tester, 14-day rule.

What happens if app registration is missed

Google says packages must be registered to meet Android developer verification requirements, and its package-registration page states a September 30, 2026 deadline. The page also says apps not registered by then will be removed from Play under the cited policy.

Can a verified account still be blocked from publishing

Yes. Google says production and some related features stay disabled until the testing requirements are met for the affected personal accounts. Verification is necessary, but it is not the only gate.

Where should I check first if I am setting up a new app now

Check the current Play Console help pages for account verification, package registration, and personal account testing requirements before creating the release path. Google’s pages say those requirements can affect both account setup and production access.

Sources

Counting the 14 days yourself?
There is a free tracker for exactly that at
devconnectplatform.com/tools/closed-test-tracker.
No account, no signup, and the link keeps your progress.

Originally published at devconnectplatform.com, where it is kept up to date.