DEV Community: Daniil Kornilov

Two Rows Have the Same ID. Which One Should You Trust?

Daniil Kornilov — Tue, 27 Oct 2026 10:31:37 +0000

You are comparing two lists of stock. In the new file, item A-17 appears twice: one row says there are 2 left, the other says 5.

Which row is correct? The two rows alone do not tell you.

Perhaps the item was duplicated by mistake. Or perhaps the rows refer to different warehouses, but the file does not include the warehouse name. Taking the first row automatically can produce a tidy-looking comparison with the wrong answer.

Separate the uncertain rows

Put repeated IDs aside for review. Check the original source and look for a field that distinguishes the records, such as warehouse or product variant.

Then decide what makes a record unique for your task. If one product can appear once per warehouse, the product ID alone is not enough. You may need a key that includes both product and warehouse.

For example, A-17 / north and A-17 / south can represent two different records. But only use those labels if the source actually provides that distinction. Do not invent missing information to make the duplicate disappear.

You can continue comparing the unambiguous rows while keeping the uncertain ones visible in a separate review list. Fix or clarify the source before treating those rows as a reliable result.

When you find duplicate IDs, what do you check first?

Your Product Page Has the New Price. What Does Checkout Show?

Daniil Kornilov — Tue, 27 Oct 2026 10:31:15 +0000

The product page shows the new price. You refresh it and everything looks right.

But a customer sees more than the product page. They may add the item to a cart and move on to checkout, where an old price could still appear.

Follow one item through the order

Open the public site on a phone, as a visitor. Find the item, add it to the cart and continue to checkout.

Compare the item's price at each step. Then look at the final total: delivery, taxes or other fees can make it different from the item price. The important thing is that the customer can understand what was added.

You do not have to pay to perform this check. If you need to submit an order, mark it as a test and make sure nobody starts fulfilling it.

If the item price changes unexpectedly, record where it first differs and what you did before it happened. That gives the person fixing it a useful starting point.

A correct product page is a good start. A consistent path to checkout gives you more confidence that customers see the price you intended.

What do you check after changing a price: just the page, or the cart and checkout too?

“Click Here” for What? Your Links Should Answer That.

Daniil Kornilov — Mon, 26 Oct 2026 19:06:13 +0000

A page has three useful resources.

Every link says “Click here.”

One opens a price list. One downloads a checklist. One starts a booking form. The destination matters more than the instruction to click.

Name what is on the other side

Compare these labels:

“Click here” → “View the price list.”
“Learn more” → “See what is included in the website package.”
“Download” → “Download the launch checklist (PDF).”

Only promise a PDF if the link really opens or downloads one. A clearer label still needs the correct destination.

This is a small change you can review without redesigning the page: read the label, follow the link, and compare the promise with what appears.

Context can help. Guessing should not be the job

“Read more” is not automatically wrong. A descriptive sentence or article heading can give it meaningful context.

W3C's explanation of link purpose allows the purpose to come from the link text together with its associated context. It also recommends meaningful link text where possible. This helps people who navigate using assistive technology, including a list of links.

So you do not need to turn every link into a sentence. Start with the vague ones that lead to different things.

Open one page you maintain. Can you tell where its links go before following them?

Which label would you change first?

Your Contact Button Works. Does the Message Arrive?

Daniil Kornilov — Mon, 26 Oct 2026 19:06:04 +0000

A visitor fills in your contact form, presses Send and sees a pleasant green message.

You check the animation. It looks good.

But did the inquiry reach the person who is supposed to answer it?

That is a different thing to check.

Follow one message to its destination

Imagine a small business website that sends inquiries to an email inbox. A useful release check is simple:

Open the public page on a phone, signed out of your admin account.
Submit a clearly marked test inquiry using an address you control.
Find that exact message in the intended inbox.
Check that the sender's reply address and message are intact.
Reply and confirm that the answer reaches your test address.

You have checked one real route through the site. A screenshot of the green message cannot show you the same thing.

If the inquiry does not arrive, start tracing that route: was it recorded by the form service, sent to the intended address, or placed in spam? Check the evidence before guessing at a cause.

Make the confirmation match what you know

“Your request reached our team” is a stronger claim than “Your request was submitted.” Use wording that your system can actually support.

W3C's form notification guidance explains why users need clear feedback about the result of a submission. That feedback should also be truthful.

A successful test message does not prove that every future delivery will work. Keep a way to notice failures after launch, and repeat this check when the form or its destination changes.

What do you use as proof that your contact form works: the success screen, or a message someone can answer?

Your Form Says “Invalid.” Your User Says “Now What?”

Daniil Kornilov — Sun, 25 Oct 2026 19:32:23 +0000

You spend twenty minutes polishing a button.

Then the form tells someone: “Invalid input.”

Invalid what? The date? The phone number? The file?

A neat interface still needs to explain what to do next.

Change the message, not just its color

Imagine a profile form that accepts JPG and PNG images up to 5 MB. Someone selects a larger file.

“Upload failed” only reports the failure.

“Your image is over 5 MB. Choose a smaller JPG or PNG” gives the person a next step.

The wording must match the real rule. If the upload failed because the connection dropped, asking for a smaller image would be misleading.

The same idea works elsewhere:

“Invalid date” → “Enter the date as DD/MM/YYYY.”
“Required” → “Enter an email address so we can send your receipt.”
“Something went wrong” → explain the known problem, or say that you could not identify it. Do not invent a cause.

Put the help where the problem is

Show the message near the field. Keep the person's other entries. A red outline alone does not explain the fix.

W3C's form notification guidance recommends clear error descriptions and simple correction instructions. For developers, it also describes linking fields and messages with aria-describedby so that assistive technology can connect them.

A quick review: deliberately submit the wrong value. Read only the message. Does it tell you which field needs attention and how to continue?

If you have to ask the developer what the message means, the wording needs another pass.

Which error message in your product would you rewrite first?

Stop Asking AI to “Make It Better.” Name One Thing.

Daniil Kornilov — Sun, 25 Oct 2026 19:30:21 +0000

“Make this page better.”

That sounds like a request. It leaves a lot of decisions open.

Better for whom? Easier to read? Faster to load? More colorful? An assistant can change all three while missing the thing that bothered you.

Take a simple example: the contact button is hard to find on a phone.

Give it a job you can point to

Instead of:

Make the landing page look more professional.

Try:

On a 360px-wide screen, make the contact button easy to find in the first section. Keep the current text, colors and desktop layout. Change only the button's size and spacing. Show me the changes before applying anything else.

The second request names the problem, the allowed change and what should stay put. You can open the page on a phone-sized screen and judge the result.

It is a clearer assignment, not proof that a particular model will follow it. You still have to inspect the output.

A small fix should have a small finish line

For this example, the finish line is practical:

The button is visible in the first section without sideways scrolling.
Its label still says what happens when you press it.
The desktop layout and the rest of the page remain as they were.

If changing only size and spacing cannot meet that goal, ask the assistant to explain the conflict before expanding the job.

“Improve everything” makes it hard to tell whether you are finished. One visible problem gives you something to accept, reject or revise.

This also works for writing. Instead of “make it smarter,” try “replace the jargon, keep one example and cut the introduction.” You can check each part without guessing what “smarter” means.

What is the smallest change you actually want from your next AI request?

Your Agent's confirmed: true Is Not Permission.

Daniil Kornilov — Sat, 24 Oct 2026 13:29:24 +0000

The agent sends {"projectId":"project-a","confirmed":true} to a deletion tool.

What established the permission: the authenticated user, a verified approval, or a boolean the model supplied?

If the execution component treats that boolean as proof, your confirmation dialog may be protecting the appearance of the action rather than the action itself.

Separate a proposed action from authority to perform it

Consider a hypothetical project-management assistant. It reads project notes and proposes an archive or delete action. The tool receives arguments chosen by the agent.

The note can describe a project. It cannot grant the current user permission to delete it. A model-produced statement that “the user approved” is also a statement to verify, not a new source of authority.

OWASP's AI Agent Security guidance calls for tool authorization outside the agent's context and explains why a confirmation flag alone is insufficient.

Test a policy the model cannot rewrite

Here is an intentionally narrow, in-memory example of an object authorization check:

function authorizeDelete(actor, project, args) {
  if (actor.role !== "maintainer" ||
      actor.tenantId !== project.tenantId ||
      args.projectId !== project.id) {
    throw new Error("Forbidden");
  }
  return project.id;
}

For this exercise, actor comes from a trusted server boundary, and project is the server-loaded record. Neither comes from the model's argument object. No actual deletion occurs.

Running controlled inputs gives these results:

Input	Policy result
Maintainer, matching tenant and project	Allowed
Reader adds `confirmed: true` and `role: "maintainer"` to arguments	Denied
Maintainer from another tenant	Denied
Mismatched project identifier	Denied

This illustrates one authorization layer. It does not implement a complete deletion endpoint, identity verification or an approval service. A production operation also needs input validation and an appropriate consistency strategy so the authorization decision cannot become stale before execution.

Approval needs an identity and an exact action

For a destructive operation, a real approval mechanism must verify who approved, which operation and target were approved, whether the approval is still valid, and whether it was already consumed. The execution boundary should check and consume it atomically before the action. A changed target or changed parameters must not silently reuse the original approval.

Keep ordinary authorization in place too. Confirmation does not give a reader the permissions of a maintainer.

OWASP's Authorization Cheat Sheet describes denying access by default and validating permissions on each request. Those principles still matter when an agent constructs the request.

Review the tool boundary before polishing the prompt

Ask the team to show what happens when the agent submits a valid-looking call for the wrong tenant. Then change the project after approval. Then try to reuse the approval.

Observe the executor's decision and resulting state. Do not accept a reassuring explanation from the model as the test result.

A system prompt can describe the intended behavior. The executor still needs to enforce the permissions independently.

Which check in your agent would still hold if the model supplied the wrong arguments?

The Test Passed All Three Bugs. That's the Problem.

Daniil Kornilov — Sat, 24 Oct 2026 13:28:42 +0000

Three deliberately broken shipping functions. The same test passes every one.

That result should make a green test badge feel less reassuring.

Here is a small experiment you can run in Node.js. The business rule is explicit: shipping costs 500 cents below a subtotal of 5,000 cents, and is free at or above that threshold. All inputs in the experiment are valid nonnegative integer subtotals.

A plausible test with a large blind spot

import assert from "node:assert/strict";

// Amounts are integer cents. This example uses valid subtotals only.
const variants = {
  reference: s => s >= 5000 ? 0 : 500,
  wrongBoundary: s => s > 5000 ? 0 : 500,
  alwaysFree: s => 0,
  wrongFee: s => s >= 5000 ? 0 : 5000
};

for (const [name, shipping] of Object.entries(variants)) {
  assert.equal(shipping(6000), 0);
  console.log(name, "PASS");
}

The output is four passes. The correct implementation passes. So do three incorrect ones: a threshold off by one, free shipping for every order, and a fee ten times too large below the threshold.

Nothing is wrong with assert.equal. The test asks only about an order that qualifies for free shipping. All four implementations answer that particular question correctly.

Ask the test to distinguish the alternatives

Keep the 6,000-cent case, then add observations at the boundary and immediately below it:

assert.equal(shipping(4999), 500);
assert.equal(shipping(5000), 0);
assert.equal(shipping(6000), 0);

Running those assertions against the four implementations produces this matrix:

Implementation	Original check	Three-case check
Correct rule	Pass	Pass
`>` instead of `>=`	Pass	Fail
Always free	Pass	Fail
Wrong fee	Pass	Fail

These are results from the local example, not measurements of a model or a production checkout. The three-case check detects these three changes. It does not establish complete input validation, tax correctness, currency handling or checkout reliability.

The same assistant can miss the rule twice

When a coding assistant proposes both an implementation and its tests, inspect which examples it chose. If both artifacts share an omitted boundary, agreement between them tells you little about that boundary.

There is no model comparison hidden in this experiment. A person can write the same weak test. The useful question is whether the test can reject a believable wrong implementation.

A more useful review request is:

Name three plausible mistakes in this rule. Change the implementation to each one separately, then show which assertion fails.

That asks for evidence of discrimination. “Add more tests” can produce a longer suite of the same happy path.

You can start without another test framework

The deliberate changes here are a small manual exercise. Automated mutation testing applies this idea more broadly. Stryker's documentation explains the difference between changes that tests detect and changes that survive.

Start with a consequential rule whose expected outcomes you can explain independently: a shipping threshold, a permission decision or an import rejection. Keep the expected behavior separate from the implementation under review.

If no one can explain why an expected value is correct, asking another model to repeat it does not settle the requirement.

Which believable bug would your current test suite accept without turning red?

TypeScript Passed. Your JSON Is Still Lying.

Daniil Kornilov — Sat, 24 Oct 2026 01:56:12 +0000

The compiler is happy. Your API returned {"quantity":"3"}. Adding one produces "31".

The suspicious line can look reassuring:

type Order = { quantity: number };
const order = JSON.parse('{"quantity":"3"}') as Order;
console.log(order.quantity + 1); // "31"

This is a runnable failure example, not an account of a production incident.

TypeScript's handbook explains that type assertions are removed during compilation. They do not introduce runtime validation. The assertion tells the compiler what to assume; it does not convert the incoming string to a number.

Put the check where data enters

Suppose our order contract requires a positive safe integer. Treat the parsed value as unknown, inspect it, then construct the internal object:

type Order = { quantity: number };

function parseOrder(value: unknown): Order {
  if (typeof value !== "object" || value === null ||
      Array.isArray(value) || !("quantity" in value)) {
    throw new Error("Expected an order object");
  }
  const quantity = value.quantity;
  if (typeof quantity !== "number" ||
      !Number.isSafeInteger(quantity) || quantity <= 0) {
    throw new Error("Expected a positive safe integer quantity");
  }
  return { quantity };
}

The function deliberately rejects the string "3". If the API contract permits numeric strings, define and test that conversion separately. Accepting several representations by accident makes malformed input harder to identify later.

Returning a new object also makes the selected fields explicit. This parser ignores additional fields; it does not claim that the entire incoming document matches an exact schema. Decide whether that policy fits your boundary.

Review values that look almost right

For this contract, test the following fixtures:

Input	Expected result
`{"quantity":3}`	Accepted
`{"quantity":"3"}`	Rejected
`{"quantity":0}`	Rejected
`{"quantity":1.5}`	Rejected
`{}`, `null`, `[]`	Rejected
An integer outside the safe range	Rejected

A test that supplies only a correctly typed object never exercises the JSON boundary. It can pass while the network integration remains broken.

Keep the failure observable

If parsing fails, stop before performing the operation that depends on the value. The interface can explain that the response was invalid and provide a recovery path appropriate to that feature.

Avoid turning the error into an empty order or defaulting quantity to one without a product decision. That would hide a data failure behind plausible output.

For a larger schema, use the validation approach already established in your codebase. The useful review question stays the same: which runtime check makes this external value safe to use?

When a coding assistant fixes a type error by adding as, ask it to show the rejected input that justifies the assertion. If the answer contains no runtime check, inspect whether the assertion is only removing a compiler warning.

Where does your application first validate data after JSON parsing?

Your API Returned 202. Why Does the UI Say Done?

Daniil Kornilov — Sat, 24 Oct 2026 01:55:49 +0000

Your export button turns green. The API returned 202. The worker has not produced a file.

That screen may be reporting a success your system has not observed yet.

Here is a hypothetical implementation:

const response = await fetch("/exports", { method: "POST" });
if (!response.ok) throw new Error("Export request rejected");
showToast("Your export is ready");

The last line silently changes the meaning of the response. HTTP 202 means the request was accepted for processing. Processing may be incomplete or may not have started, and it can still fail. A successful HTTP response is insufficient evidence that this particular file exists.

Give the button a job lifecycle

For this export feature, use distinct application states: submitting, queued, running, completed and failed. Add a state for losing the ability to observe the job. That last state matters when the browser loses its connection while a worker continues.

These are proposed product states, not extra meanings assigned to the HTTP status code. Your backend must define how the client observes them: a status resource, events, or another documented mechanism.

An illustrative response contract could be:

{
  "jobId": "export-demo-17",
  "state": "queued",
  "statusUrl": "/exports/export-demo-17"
}

Those field names are specific to the example. HTTP 202 does not automatically supply a status endpoint.

Make each claim depend on evidence

“Request received” can follow acceptance. “Preparing your file” needs a known active job. “Download ready” needs a completed result the user can access.

If a status request fails, keep the job identifier. Show that its state cannot currently be checked and let the user check again. Creating another export immediately can duplicate work and leave two jobs whose results are difficult to distinguish.

Refreshing the page is another useful rehearsal. Does the screen reconnect to the original job, forget it, or start over? Decide that behavior before shipping the optimistic toast.

Test the promise made by the interface

I would use a controlled service with these outcomes:

acceptance followed by completion;
acceptance followed by worker failure;
acceptance followed by a lost status response;
page reload while the job is queued;
a completed job whose download is no longer available.

For every case, compare the visible message with the state the application actually knows. Include a check that observation failure never becomes a “ready” badge.

The interesting review artifact is a short sequence of observations: accepted response, job state, final result, visible copy. A screenshot of the green toast by itself cannot establish that an export worked.

Which part of your product currently uses “success” for a request that only entered a queue?

Promise.all Failed. Your Database Write Might Still Be Running.

Daniil Kornilov — Sat, 24 Oct 2026 01:55:01 +0000

The checkout request failed. The inventory reservation still completed.

If your error handler assumes that failure means nothing happened, the retry can be the most dangerous line in the feature.

Consider a hypothetical implementation that starts an inventory reservation and a notification together, then awaits Promise.all. Notification fails. The page shows an error. The reservation is still in flight.

Reproduce the order without a timer

This small JavaScript example lets us finish one operation manually after the combined promise has already rejected:

const events = [];
let finishReservation;
const reservation = new Promise(resolve => {
  finishReservation = () => {
    events.push("stock reserved");
    resolve();
  };
});

try {
  await Promise.all([
    reservation,
    Promise.reject(new Error("notification unavailable"))
  ]);
} catch {
  events.push("request failed");
}

finishReservation();
await reservation;
console.log(events);
// ["request failed", "stock reserved"]

The resulting event order is the point: a side effect can finish after the caller enters its failure path. The example models that side effect with an array; it does not connect to a real store.

Promise.all rejects when an input rejects. That does not cancel the other operations or undo completed writes. Promise.allSettled can collect every outcome, but it does not provide rollback either.

Review the state left behind

For this checkout, I would ask the reviewer to fill in a small failure table:

Observation	Question before offering retry
Reservation succeeded, notification failed	Can notification be retried separately?
Reservation is still pending	Where can its final state be checked?
The response was lost	Can the existing operation be identified?
Both operations succeeded	Which record establishes the completed order?

“Catch and show a toast” leaves these questions unanswered. The user can see a failure while the server holds a reservation.

Pick the boundary that must be consistent

For this example, inventory and order state belong in a server workflow with an explicit consistency strategy. Sending a notification can follow a committed order, with its own delivery status. The exact design depends on which services own the data.

Putting the calls in sequence can prevent a later step from starting too early. It still does not undo a first step when the second fails. A transaction is useful only within the boundary it actually covers; several unrelated HTTP APIs do not become one transaction because they share an await.

If retry is supported, define what identifies the same operation. Check the destination's contract before assuming that repeating a write is safe. A random new identifier on every retry does not identify the original attempt.

Ask a harder question of generated code

“Does the happy path work?” is easy to demonstrate. Try this review request instead:

Fail the second operation after the first has started. Show the final server state, then show what a retry does.

Run the same exercise on code written by a person or by a coding assistant. The source of the code does not change the failure semantics.

Which side effect in your app could finish after the UI has already told the user the operation failed?

Your AI-Built Portfolio Has a Problem: You Still Have to Explain It

Daniil Kornilov — Thu, 22 Oct 2026 11:56:30 +0000

The portfolio has animations. The repository has a README. The deployment works.

Then someone asks: “Which decision in this project was yours?”

“I built it with React” does not answer that question. Neither does a list of tools or a paragraph about a seamless user experience.

A polished site can help people inspect your work. It cannot supply the reasoning behind work you have not thought through.

Try this before adding another project

Open one project you actually understand. Explain a single decision without naming the framework first.

Use four prompts:

What behaviour needed to change?
What options did you have?
Why did you choose this one?
What can another person inspect to check your explanation?

Treat this as a preparation exercise, not a claim about what every employer asks. If you cannot answer yet, investigate the project before rewriting the portfolio copy.

Replace a claim with a small, inspectable case

Here is a fictional example, not a project result from my work.

Thin version: “Built a responsive product catalogue with advanced filtering.”

Useful version: “The selected filters disappeared when someone shared the catalogue URL. I put the shareable filter state in URL parameters, kept temporary input outside that state, and defined defaults for missing parameters. The check was to select filters, copy the URL into a fresh tab, and compare the visible selection and results.”

That version gives a reader something to question. Why separate temporary input? What happens with an invalid parameter? Does the browser's Back button restore the previous state?

Those questions reveal understanding more effectively than another adjective about the interface.

Include the tradeoff you did not hide

In the fictional example, putting state in the URL makes it shareable, but it also makes the chosen representation visible and persistent in browser history. You still have to decide what belongs there.

Write down an alternative you considered and a reason for rejecting it. The reason should come from a constraint in your project, not a generic claim that one approach is always better.

If you did not measure conversion, do not invent an improvement percentage. A reproducible behaviour check is already evidence of something specific. It just proves less than a controlled business experiment.

If a coding tool helped, explain what you checked

You can describe a suggested implementation you accepted, a change you rejected and the check that informed the decision. Keep the account accurate. Do not replace missing reasoning with a made-up story about ownership.

For team projects, separate your contribution from the team's result. For confidential work, use only material you can share; a public portfolio does not need customer data to explain a technical choice.

A stronger next step than another redesign

Take your weakest case and remove every sentence that could describe a hundred other projects. Add the constraint, your decision and one inspectable result.

Then ask a reader what they would question. If their questions are about the engineering rather than what the project even does, the case is becoming easier to discuss.

I'm Daniil. I write about frontend decisions, practical developer tools and explaining engineering work. Follow for more concrete examples.

What is the hardest part of your portfolio to explain without opening the code?