DEV Community: AsterXing

I kept seeing AI agents overreach permissions, so I made a tiny readiness kit

AsterXing — Thu, 30 Jul 2026 08:06:32 +0000

Most agent demos look fine right until they touch real repos, real secrets, or a teammate’s machine.

I kept seeing the same failure pattern: the team could tell the model was smart, but not whether the workflow was actually safe to let loose.

So I turned our internal checklist into a tiny readiness kit.

What it checks in a lightweight way:

where permissions are broader than the task needs
where prompts and tools can leak data across sessions
where “works in demo” breaks once the agent hits production-like context
where handoff, rollback, and audit evidence are missing

This isn’t a big platform pitch. It’s a practical preflight for teams testing coding agents or internal AI helpers before they create a very expensive surprise.

If you’re already using agents in repo, ops, or internal workflow environments, I’d love to know which failure mode shows up first for you: permissions, tool sprawl, missing audit trail, or rollback gaps?

Three small quality gates that make AI coding workflows cheaper and safer

AsterXing — Thu, 30 Jul 2026 01:24:58 +0000

A pattern I keep seeing: teams add an AI coding tool, get a burst of speed, and then quietly lose time on rollback, retesting, and noisy diffs.

The fix usually is not a bigger model. It is three boring gates:

A preflight gate before generation.
Ask: what files can change, what tests must pass, and what budget should this task stay under? A 30-second checklist prevents most oversized runs.
A validation gate after generation.
Run lint, unit tests, and one focused regression check tied to the task. If the agent changed auth, billing, or deploy code, add one explicit safety check instead of trusting a green summary.
A cost gate after merge.
Track token spend and rerun rate per task class. In practice, cheap models often win on narrow refactors, while expensive models only pay off on ambiguous multi-file work.

One simple rule of thumb: route easy edits to the cheapest model that can keep structure, and reserve premium models for planning, debugging, and risky migrations.

The interesting part is cultural: once people see cost, retry rate, and escaped bugs on the same board, prompts get shorter and handoff quality gets better.

Curious what gate catches the most failures for your team today: preflight, validation, or cost review?

A simple readiness checklist before you let an AI agent touch production

AsterXing — Sat, 25 Jul 2026 08:10:05 +0000

If you’re letting an AI agent touch production, a green unit test is not enough. The failure mode is rarely “the model was dumb” — it’s usually missing guardrails around scope, rollback, credentials, or observability.

Here’s the lightweight checklist I’d want before any agent can run outside a sandbox:

1) Make the blast radius obvious

What files, APIs, repos, or environments can it touch?
What is strictly read-only?
What is the one command or path that would hurt the most if it went wrong?

2) Require a human-readable plan first

Before execution, force the agent to say:

what it thinks the problem is
what it plans to change
what it will not change
how it will verify success
how to undo the change

If a human cannot read the plan in 30 seconds, the task is still too vague.

3) Separate “inspect” from “write”

A lot of teams mix safe diagnosis with risky execution.
Keep them split:

inspect / search / diff / dry-run
then explicit approval
then write / deploy / publish

That one boundary removes a surprising amount of risk.

4) Add a rollback sentence, not just a rollback script

You want both:

the command to revert
the plain-language condition for when to revert

Example: “If checkout latency rises or 5xx errors spike after deploy, revert immediately.”

5) Log the exact action, not just the result

For every production-touching run, capture:

prompt or task summary
changed files / commands
approver
timestamps
verification output
follow-up owner

Without that trail, postmortems become guesswork.

6) Don’t let analytics gaps masquerade as success

“Nothing broke” is not the same as “it worked.”
If you cannot observe the key event, you cannot close the loop.
At minimum, define one thing you expect to move after the change.

7) Start with a manual service before a full product

One thing I keep seeing: teams want a full “agent governance platform” before they’ve done five manual audits.
Usually the faster move is:

run the checklist manually
find repeat failures
turn only the repeated parts into product

That gives you better language, clearer scope, and fewer fake features.

I’m experimenting with a small Agent Readiness / Governance Audit workflow around exactly this problem. Not a full platform claim — more a practical preflight for teams that want to catch the obvious mistakes before an agent touches production.

Curious where your own process still feels weakest today:

approvals
rollback
credentials
observability
task scoping

3 gates I now use before letting an AI coding agent touch production

AsterXing — Sat, 25 Jul 2026 01:24:18 +0000

AI coding agents are great at speed, but I only trust them in production after three gates.

Gate 1: scope gate
The task has to be narrow enough that a human reviewer can explain the expected diff in one sentence. If I can't describe the change clearly, the agent usually expands the blast radius.

Gate 2: verification gate
Before merge, I want at least one fast test, one failure-path check, and one plain-English review note. "It ran" is not enough. I need to know what was checked and what was intentionally left unchecked.

Gate 3: cost + rollback gate
If the agent triggers extra APIs, background jobs, or long CI runs, I estimate the cost first. And if I can't roll the change back in minutes, it should not ship automatically.

The pattern that helped most: let the agent draft, let tests narrow the risk, and let humans own the final release decision.

Curious what your gate is before AI-generated code touches prod: permissions, tests, or rollback?

Palworld 1.0 breeding: why owned-Pal route planning is different from pair calculators

AsterXing — Fri, 24 Jul 2026 07:45:06 +0000

Most Palworld breeding calculators answer a very useful question: if I pick two parents, what child do I get? Or, if I want a target Pal, what parent pairs can produce it?

After Palworld 1.0 changed a lot of breeding data, that is still the first thing players need. But there is another planning problem that shows up once you have a messy Palbox:

Given the Pals I already own, what is the shortest practical route to the target Pal?

That is a slightly different workflow from a pair calculator.

Pair calculators are good for direct lookup

A normal breeding calculator is best when you already know the search shape:

choose Parent A + Parent B and see the child
choose a target Pal and browse all possible parent pairs
compare direct parent combinations
check whether 1.0 data changed a known combo

For example, if you are only asking “what makes Anubis?”, a target-to-parent calculator is enough.

Route planning starts from your actual Palbox

Owned-Pal route planning starts from a different constraint: you do not own every possible parent.

A route planner needs to treat your current Pals as the starting nodes, then walk the breeding graph until it finds a reachable path. That lets it answer questions like:

Can I reach Anubis from only early-game Pals?
What is the next missing parent I should breed first?
Is there a shorter route if I already own a mid-game Pal?
Which target is impossible from my current Palbox without one more reachable parent?

This is closer to a shortest-path problem than a simple lookup table.

Example: route pages should show real steps

Thin pages that only say “breed X” are not very useful. A better route page should show the actual chain, the assumptions, and a way to reproduce the result.

For example:

Anubis route example: https://palroutes.com/palworld-breeding-routes/anubis
Aegidron route example: https://palroutes.com/palworld-breeding-routes/aegidron
Direhowl route example: https://palroutes.com/palworld-breeding-routes/direhowl

These pages are meant to be route examples, not a replacement for checking every passive, IV, gender edge case, or mutation plan.

What I built

I am building PalRoutes as a small fan-made planner for this exact owned-Pal workflow:

https://palroutes.com/

The current scope is intentionally narrow: paste or select your owned Pals, choose a target, and look for a practical Palworld 1.0 breeding route. The data source and limits are visible because breeding tools can go stale fast after patches.

I also wrote a short guide here:

https://palroutes.com/palworld-1-0-breeding-guide

Caveat

This does not solve every optimization layer. If you are min-maxing passives, IVs, mutations, gender-specific exceptions, or cake cost, you still need to check those constraints separately.

The useful split for me is:

use a breeding calculator for direct pair lookup
use a route planner when your real constraint is the Pals you already own

3 deployment gates I now use before letting an AI coding agent touch production

AsterXing — Wed, 22 Jul 2026 01:27:06 +0000

I’m seeing more teams move from “AI can write code” to “AI can change real systems.” That second step is where most of the avoidable damage happens.

After a few messy experiments, I now use three simple deployment gates before letting an AI coding agent touch anything production-adjacent.

1) Scope gate: can the task fail small?

If the failure radius is unclear, the agent should not run with write access.

My quick check:

Can I name the exact files, services, or environments it may touch?
Is there a clean rollback path?
Would a wrong action stay local, or cascade?

If I can’t answer those in two minutes, the task gets downgraded to draft-only or read-only.

2) Evidence gate: what proof must exist before merge or deploy?

A lot of “agent worked” claims are really “the tool returned success.” That’s not evidence.

For each task I now ask for concrete proof:

test output
diff summary
screenshot or URL for UI changes
exact command results
explicit note about what was not verified

This sounds obvious, but it cuts out a huge amount of false confidence.

3) Cost gate: what is the maximum token/tool spend for this run?

Runaway loops are not just reliability bugs; they are budget bugs.

I put a ceiling on:

total turns
total model spend
retries per failing step
tool classes allowed in the session

Cheap guardrails beat heroic postmortems.

The practical rule

If a task can break prod, spend money indefinitely, or silently fake success, it should pass all three gates before autonomy expands.

I’m curious what others are using here. Do you have a preflight checklist for coding agents, or are you relying more on sandboxing plus human review?

Building Pal Routes: shortest Palworld breeding paths from your owned Pals

AsterXing — Sat, 18 Jul 2026 08:50:54 +0000

I built a small fan-made web tool for Palworld players: Pal Routes.

Most Palworld breeding calculators answer a local question: "which parent pair makes this Pal?" That is useful, but while playing I often wanted a more route-oriented workflow:

Given the Pals I already own, what is the shortest species path to a target Pal?

What Pal Routes does

Uses Palworld 1.0 breeding data shown in the app as 299 Pals and 44,851 breeding pairs
Lets you paste/type your current Palbox species
Lets you pick a target such as Anubis, Direhowl, or Aegidron
Returns a step-by-step species breeding route
Keeps the output copyable so it can be used while playing

What it does not do yet

This is intentionally narrow. It is species-route only.

It does not optimize passive skills, IVs, gender checks, Cake/resource costs, mutation, or save editing. Players should still verify routes in game before spending resources.

Why I am sharing it here

The product decision I am testing is whether a narrow “owned Pals → shortest route” workflow is valuable enough before adding adjacent features. For game utility tools, it is easy to keep adding filters and calculators; I am trying to keep the first workflow very focused.

If you build game tools or play Palworld, I would love feedback on two things:

Is the route output format clear enough?
What is the next constraint you would add: passive skills, resource cost, gender, or something else?

Disclosure: Pal Routes is independent and is not affiliated with, endorsed by, or sponsored by Pocketpair.

A practical preflight checklist for AI coding agents

AsterXing — Sat, 18 Jul 2026 01:23:23 +0000

AI coding agents are getting good enough that the bottleneck is often not generation anymore. The bottleneck is deciding what can safely be delegated, what evidence counts as done, and when a human should step back in.

Here is the small preflight checklist I use before letting an agent touch a non-trivial codebase.

1. Write the task as a contract, not a vibe

A weak task says: "improve the checkout flow".

A safer task says:

change only the checkout summary component and its tests
preserve the existing payment provider integration
do not modify database schema or environment variables
success means the current checkout tests pass and one new regression test covers the empty-cart state

The agent needs boundaries more than enthusiasm.

2. Separate exploration from editing

I like to run agent work in two passes:

read-only reconnaissance: map files, risks, dependencies, and likely test commands
implementation: make the smallest change that satisfies the contract

This prevents the common failure mode where the agent starts editing before it understands the code path.

3. Require a verification plan before code changes

Before accepting edits, ask for:

commands it expects to run
tests it expects to add or update
what it will not verify and why
rollback points if the change touches multiple files

If the verification plan is vague, the implementation will usually be vague too.

4. Put hard stops around sensitive areas

For most projects, I do not let agents change these without explicit approval:

auth/session logic
billing and subscriptions
migrations or production data scripts
security headers and permission checks
analytics events used for decisions
deployment configuration

The goal is not to distrust AI. It is to keep high-blast-radius changes under human control.

5. Review for behavior, not just diff size

Small diffs can still change behavior. I check:

did it alter an API contract?
did it remove an edge-case branch?
did it make a test weaker to pass?
did it introduce hidden cost, latency, or privacy impact?

The best agent workflows treat tests, screenshots, logs, and rollback notes as part of the deliverable, not as afterthoughts.

A simple rule of thumb

Delegate implementation when the task has clear boundaries and cheap verification. Keep planning, architecture, security, billing, and product tradeoffs human-led.

AI agents are most useful when they are treated like fast junior teammates with excellent recall: give them context, define done, inspect the evidence, and keep the dangerous switches out of reach until you are ready.

A lightweight preflight checklist before trusting an AI coding agent

AsterXing — Wed, 15 Jul 2026 08:04:25 +0000

Most AI-coding failures I see are not model failures. They are missing preflight checks: unclear repo state, unreviewed permissions, no rollback path, and no tiny verification step after the agent finishes.

Here is the lightweight checklist I now use before I let an agent touch a project:

Define the one allowed change

Write one sentence: "The agent may only change ___ to achieve ___." If you cannot write that sentence, the task is probably still too vague.

Freeze the starting state

Before the agent starts, record:

current branch and commit
whether the working tree is clean
which files or directories are in scope
which production systems are off limits

This avoids the classic "it also cleaned up a few unrelated things" problem.

State forbidden actions explicitly

Examples:

do not deploy
do not touch billing or payment config
do not read private customer data
do not rotate keys
do not rewrite history
do not change prompts or security policy

For agents, an unstated boundary is often not a boundary.

Require a rollback note before execution

The rollback does not have to be fancy. It can be:

revert commit X
restore file Y from git
disable feature flag Z
re-run previous deployment command

If there is no rollback path, the task is probably too large for one agent turn.

Use the smallest meaningful verification gate

Pick one real check:

unit test
typecheck
build
lint
screenshot
direct browser check
curl against a health endpoint
manual inspection of the exact changed file

Do not accept "looks good" if no gate was run.

Separate read-only research from write actions

An agent can search docs and inspect logs in a broad way, but writes should be narrow and auditable. I treat external posting, account settings, production deploys, billing, privacy data, and scheduler changes as separate permission zones.

Keep a short handoff

At the end, ask for:

what changed
what was not changed
what check passed
what remains risky
exact files touched

I am experimenting with a small readiness workflow around this for early AI-agent projects: a preflight card that turns a vague task into scope, forbidden actions, rollback, and verification before the agent starts. Not a full platform pitch yet; I am mainly validating whether this checklist catches the mistakes teams actually care about.

If you use coding agents in a real repo, what is the one preflight check you wish you had enforced earlier?

A small readiness checklist before letting AI coding agents touch deployment

AsterXing — Wed, 15 Jul 2026 01:25:24 +0000

AI coding agents are getting good enough that the bottleneck is no longer only code generation. The risk has moved into workflow design: what permissions the agent has, when CI runs, who reviews the diff, and how much money an automated loop can spend before a human notices.

Here is the lightweight checklist I use before letting an agent work near a deploy path:

Define the target outcome, not just the task. “Reduce flaky checkout tests” is safer than “fix tests” because it gives reviewers a measurable bar.
Put the agent in a branch or worktree with a clear rollback path. Never let experimental agent work start from an uncommitted local state.
Require tests or a reproducible verification command in the prompt. If the agent cannot run it, it should explain why.
Add a deployment cost brake. Preview builds, CI minutes, serverless invocations, and model calls all multiply when agents make many small commits.
Review the diff for permission, data, and migration boundaries before reviewing style. The expensive failures are usually “the agent touched the wrong thing,” not “the code is ugly.”
Keep a short failure log. When an agent loops, over-edits, or invents constraints, turn that into a new guardrail instead of just retrying.

My rule of thumb: treat an AI coding agent like a fast junior teammate connected to automation. Give it context, a sandbox, tests, budget limits, and a human merge gate. That keeps the speed while avoiding the hidden costs.

Recent prompt for discussion: agent workflows are becoming less about “which model is smartest?” and more about “which workflow keeps permissions, CI, and budget under control?” I think that is the right shift.

Tiny UX notes from building an unofficial fan sentiment tracker

AsterXing — Thu, 02 Jul 2026 08:07:12 +0000

I recently built a tiny, unofficial fan sentiment tracker for reality-TV conversations. The product is simple, but a few UX lessons were more useful than the code itself.

1. Make the boundary obvious

Fans are used to official voting, polls, spoilers, predictions, and recaps all being mixed together. If a tool is not an official vote, the page has to say that clearly before asking anyone to interact.

The wording that worked best for me was plain: unofficial, fan-made, prediction/sentiment only.

2. Let people understand the result before they act

A prediction tool should not feel like a black box. Even a small explanation like “this is based on public fan signals, not official results” reduces confusion and keeps the experience honest.

3. Optimise for quick sharing, not long onboarding

For casual entertainment products, most visitors will not create an account first. A lightweight page, a direct result, and a shareable link matter more than a complex dashboard.

4. Track support intent separately from usage

Page views are not enough. For a small fan tool, I now treat support clicks, share clicks, and feedback clicks as separate signals. They answer different questions:

Did people understand it?
Did they think it was worth sharing?
Did anyone care enough to support it?

The tiny project I used for these experiments is VillaVote: https://www.villavote.com/?utm_source=devto&utm_medium=article&utm_campaign=star_growth_20260702_villavote

It is still intentionally small, but building it reminded me that “simple” consumer UX often needs more explicit boundaries than developer tools do.

What I learned building a tiny fan sentiment tracker during Love Island USA

AsterXing — Sun, 28 Jun 2026 12:35:04 +0000

I built a small side project around a very non-enterprise problem: following Love Island USA fan sentiment without manually checking a bunch of threads, polls, and recap posts.

The interesting part was not the show itself as much as the product lesson: fan communities often have fast-moving opinions, but the data is scattered across comments, informal polls, and episode discussions. That creates a surprisingly clear UX problem.

A few notes from the build:

1. Fan prediction is not official voting

This boundary matters a lot. The official vote still happens through the official Love Island USA app during voting windows. A fan tracker should never imply that it replaces that.

So the copy has to be explicit: this is unofficial, community-oriented, and only useful for reading sentiment or comparing predictions.

2. The best metric is not always the most complex one

For this kind of project, a simple ranking or trend line can be more useful than a heavy model. Viewers want quick answers:

who seems safest right now?
who is losing support?
are Reddit polls different from general fan chatter?

That shaped the interface more than any technical preference.

3. Small niche tools still need trust signals

Even when a tool is just for fun, users want to know:

is this official or unofficial?
where does the signal come from?
can I submit or correct something?
will the results be updated after each episode?

I added the project here as an example of the boundary and UX pattern: https://thevillavote.com/?utm_source=devto&utm_medium=article&utm_campaign=star_growth_20260628_villavote_evening

If you are building small community tools, I think the main lesson is to spend as much time on context and disclaimers as on the chart itself. The product can be lightweight, but the trust boundary cannot be vague.

Would be curious how others handle unofficial/community-data wording in small fan or hobby projects.