DEV Community: Maksym Kuzmitskyi (MaximusFT)

Freelance Architect or Agency: Who Keeps the Decisions?

Maksym Kuzmitskyi (MaximusFT) — Sun, 18 Oct 2026 00:00:00 +0000

A team asks for an architect, but the work waiting for them is a backlog of implementation tickets.

Another asks an agency to build a feature, while every consequential decision still needs approval from an internal team that has no time to review it.

Neither arrangement is necessarily wrong. They are simply describing a different purchase from the one in the proposal.

When choosing between an independent engineer and an agency, I would spend less time comparing job titles and more time describing who owns the decisions while the work is happening. That tends to matter after the first few meetings, when everyone has access and the easy questions have been answered.

This is a way to evaluate an engagement, not a claim about particular suppliers, prices, or a universal ranking of one model over the other.

First separate diagnosis from capacity

Sometimes the team knows what it needs to build and lacks enough delivery capacity. Sometimes it has plenty of developers but cannot explain why every change crosses five modules. Sometimes a deadline exposes both problems at once.

An architecture-focused independent engagement can make sense when the central work is concentrated judgement: inspect a system, identify boundaries, work with the internal team, and make a few consequential changes.

An agency can make sense when the work needs a coordinated mix of implementation, testing, design, delivery management, and continuity across several people.

Those are tendencies, not guarantees. An independent engineer may deliver a complete feature; an agency may provide one specialist. The actual assigned people and operating agreement matter more than the supplier category.

I would write the first outcome in plain terms. "Reduce the number of modules needed to change policy validation" is more testable than "improve architecture." "Own delivery of this workflow through acceptance and handover" is clearer than "provide a frontend team."

Responsibility needs corresponding authority

If an external architect is responsible for quality but cannot change boundaries, influence sequencing, or obtain review decisions, the responsibility is mostly ceremonial.

The opposite arrangement is also uncomfortable: an external team makes choices that the internal owners must maintain, without involving them until handover.

For decisions with lasting consequences, agree who proposes, who approves, and who maintains. This does not need an elaborate governance document. A small record can be enough:

Decision: separate payment validation from page orchestration
Proposed by: external engineer
Approved by: internal payments owner
Maintained by: payments team
Evidence: two representative flows and regression tests
Fallback: keep the old adapter during migration

The example is hypothetical. Its useful property is that someone still owns the result after the external person's last invoice.

Review availability limits delivery

Adding implementation capacity does not increase the internal team's review or decision capacity automatically.

If an agency submits ten pull requests a week and the internal team can carefully review three, work accumulates at the boundary. More developers may increase that queue rather than shorten the release.

An independent engineer working on a difficult architectural change can encounter the same problem. One large refactor waiting for a busy owner is not inherently easier to absorb than several ordinary features.

I would include reviewer availability in the plan: expected turnaround, who can make product decisions, when integration questions get resolved, and how work is split into changes the team can evaluate.

This is particularly important when acceptance depends on integrations the supplier cannot access or change. A delivery date that assumes immediate internal answers is a date with an unstated dependency.

Prefer demonstrated uncertainty over polished certainty

Before a substantial commitment, a small paid diagnostic or bounded delivery slice can reveal the working relationship.

Choose something representative rather than conveniently isolated: a flow with an awkward API contract, an existing shared component, a realistic test requirement, and an internal reviewer.

The useful output includes what was discovered, what changed, what remains uncertain, and which assumptions affect the next estimate. An apparently slower answer that identifies a dependency may be worth more than a confident schedule built without examining it.

I would also distinguish an estimate for implementation from the time waiting on decisions, environments, and approvals. They belong in the same delivery discussion, but they are not the same kind of work.

Continuity is a mechanism, not a headcount

An independent engineer has a clear availability risk: one person may be absent or the engagement may end.

An agency may offer replacement capacity. That does not guarantee the replacement already understands the system. A named specialist can leave; an account can be reassigned; context still has to transfer.

Ask how continuity actually works. Which people have read the critical code? Where are decisions stored? Can another engineer deploy, reproduce an issue, and explain the outstanding risks without a private conversation with the original author?

For both models, I would favor shared context in the client's systems, small decisions recorded near the code, and at least one internal engineer involved in consequential changes.

Continuity becomes less fragile when it is exercised during delivery rather than promised in a final document.

The work should remain inside the client's control

Source repositories, deployment accounts, domains, package ownership, and design assets need deliberate ownership. An engagement can finish with working software and still leave the client dependent on credentials or infrastructure controlled by the supplier.

Use client-controlled repositories and appropriately scoped access where possible. Name any exception and the transfer procedure before it becomes necessary.

The same applies to automation. If a supplier uses AI-assisted tooling, clarify permitted data handling, review expectations, generated-code responsibility, and what configuration belongs to the client. Faster implementation does not change who must verify the result or who may access private source and customer information.

I would not equate a supplier's preferred toolchain with a requirement for the client to adopt it permanently.

Avoid a handover that only describes files

A directory tour helps. It does not answer why a boundary exists, which alternatives were rejected, or what would break if the API changes.

A useful handover includes the important decisions, reproducible checks, release and rollback steps, known limitations, and the first likely maintenance changes. Keep it proportionate; six understandable notes are better than a large template nobody can navigate.

Have an internal engineer perform one change and one deployment before the engagement ends. The external person can assist, but should not quietly do every step that the exercise is intended to transfer.

That is a more convincing ownership test than asking whether everyone has read the documentation.

Architecture needs an implementation consequence

If the engagement is mostly architecture, the deliverables should still meet the code at some point.

A dependency diagram can identify a problem. A bounded migration, representative slice, or working contract test shows whether the proposed boundary is usable. Without that contact, the design may be elegant while the team's practical cost remains unknown.

Conversely, measuring only shipped tickets can discourage the diagnostic work needed to prevent the next expensive change. Agree which technical outcomes matter: fewer coupled changes, faster verification, clearer ownership, or an integration that no longer needs several teams to coordinate every edit.

I would avoid treating diagrams and implementation as competing definitions of productive work. They should inform each other, with evidence appropriate to the risk.

Choose the arrangement that can leave well

For a focused diagnosis with a capable internal team, I would often consider an independent senior engineer or architect. For a delivery stream needing several disciplines and coordinated capacity, I would consider an agency with named people and explicit ownership.

If the organization has nobody available to own decisions, review changes, or maintain the result, neither category solves that absence by itself. The operating model needs attention before more external capacity arrives.

The end of the engagement is a useful design constraint from the beginning. What should the internal team be able to do without asking the supplier? Which promises must remain true when a person changes?

I would rather make those questions slightly awkward during selection than leave them until the final week. By then the software may be complete, and the ownership may still be under construction.

If you're deciding between these arrangements, tell me which decision or delivery responsibility is currently unowned. That detail makes the comparison much more useful than the labels on the proposals.

What a Skill Changed, and What It Didn't

Maksym Kuzmitskyi (MaximusFT) — Sat, 17 Oct 2026 00:00:00 +0000

A task went well with a reusable skill enabled.

It also had clear requirements, repository instructions, connected tools, a useful test, and an engineer who corrected an early assumption.

Which part made the result better?

I would not answer that from the final diff alone. The diff can establish what changed. It cannot, by itself, tell us which part of the workflow caused the change to be correct.

I participate in evaluating reusable agent skills and refining how they are applied to ordinary engineering work. The interesting question is not whether the process produced a polished artifact. It is what observable contribution the skill made, what it cost, and what remains unknown.

This article describes an evaluation approach. It does not report internal programme results, measurements, or a controlled comparison that has established a productivity gain.

A skill is one input among several

A reusable skill packages instructions or a workflow. It may help discover context, plan a change, validate it, or handle review. It is not a separately trained model or an autonomous employee.

Its contribution depends on what was already present.

If repository rules already require a focused check immediately after an edit, a skill that repeats that instruction may add consistency, but it is not evidence that the check originated with the skill. If a connected tool supplies current requirements, the tool can explain why the agent avoided a stale assumption.

The engineer's domain knowledge matters too. A person may notice that two services disagree, narrow the investigation, or reject an obsolete proposal. Leaving that correction out makes the skill look more independent than it was.

I want the record to include those existing controls. Otherwise we are comparing a named framework with an imaginary workflow that has no useful practices of its own.

Observe behavior before assigning credit

The earlier evaluation article discusses what to measure. Here the narrower question is which explanation the observations support.

Use a deliberately illustrative record, not a real reporting form or an internal task:

Task: update a client without changing its callers
Observed behavior: agent checked a contract before editing
Existing control: repository instructions also require that check
Correction: engineer identified one stale source
Verified outcome: retained change passes the relevant gates
Skill contribution: may have reinforced discovery; attribution unresolved
Residual risk: deployment compatibility needs a separate decision

The conclusion is modest because the evidence is modest. That is not a failed evaluation. It is an evaluation that did not replace uncertainty with enthusiasm.

If the skill visibly introduced a previously missing check, say so. If the task does not distinguish its effect from existing instructions, say that instead.

A useful outcome is not always delivered code

A cross-repository investigation can end with an obsolete PR being closed. An architecture task can produce a proposal with explicit assumptions for discussion. A session-handoff change can produce a clearer continuation scheme.

Those outcomes have value. They are not interchangeable with a merged feature, an approved architecture, or guaranteed reproducibility.

Describe the actual artifact and its decision state. A reviewable proposal is ready to evaluate; it is not production rollout. A documented handoff reduces reliance on conversation history; it does not establish identical behavior across models and people.

In the supplied generalized experiences behind this series, recovery and refinement are part of the work. I would not remove the initial incomplete diagnosis simply because the final action was sensible.

The sequence explains what the process learned. A cleaned-up success story explains much less.

Separate work from overhead without pretending overhead is worthless

Implementation, framework setup, planning, repeated approvals, and reporting take different kinds of effort.

A specification can prevent an expensive mistake. It can also repeat a small task's already clear requirements. Reporting can support honest evaluation. It can also consume time that should be counted rather than hidden.

Keep normal engineering effort, framework overhead, and reporting effort distinguishable. Do not turn them into a single impressive number before understanding what each category contains.

The classification will sometimes require judgement. A discussion that clarifies an ambiguous requirement is engineering work even if a framework prompted it. A template completed only to satisfy the framework is a different contribution.

I would make that distinction visible rather than use it to prejudge whether the framework is good or bad.

Tiny tasks do not need a retrospective specification

For a small, clear change, the ticket and nearby contract may already be an adequate written requirement. A long specification can create another artifact to review without resolving a real uncertainty.

For ambiguous, risky, or multi-session work, a plan and checkpoints before implementation can be useful. They capture assumptions while there is still time for them to guide the work.

Do not write a specification afterwards and present it as evidence that the task followed specification-driven development. A retrospective note can explain the result, but it did not shape decisions that happened before it existed.

This is a simple chronology rule. It prevents polished documentation from making the process look more formal than it actually was.

Not using a skill can be the proportionate choice

An evaluation can tempt people to apply every available skill to every task so the record has plenty to discuss.

That changes the thing being evaluated. We are no longer observing useful selection; we are imposing ceremony for evidence collection.

Use a skill when it helps the task's current stage and risk. Record when a tiny or non-coding task offers limited evidence. Do not manufacture a repository-wide plan or another planning file after the fact to fill a reporting category.

A good workflow should be able to say "not needed here" without that becoming an admission that the whole framework failed.

Repeated success still has confounders

Several tasks going well can suggest a useful pattern. It does not automatically establish a causal productivity improvement.

Tasks differ in difficulty, familiarity, requirements, code quality, tools, models, and human involvement. An experienced engineer may become better at the domain during the same period the skills are introduced.

Without an appropriate baseline and comparison, avoid percentages, cost savings, or defect-rate reductions. Task counts and green checks are observations, not impact metrics by themselves.

Qualitative findings remain worthwhile: a missing boundary became explicit, a handoff had a clearer source of current decisions, or the process detected an unrelated generated change before review.

Name them as observations. They do not need a fabricated multiplier to be interesting.

Keep the evaluation record separate from public storytelling

An internal assessment may need task-level evidence, correction history, and reporting detail. A public article does not need to reproduce those artifacts.

Use generalized, explicitly labelled composite examples. Remove internal identities, programme details, source snippets, links, counts and model policy. Do not attach an employer's name to an anonymized case merely because the employment record is already public.

Even a collection of individually harmless details can make an episode identifiable. Preserve the engineering mechanism while changing or omitting unnecessary specifics.

The public claim should be something the available evidence can support without inviting the reader to inspect a closed system. "I evaluated and refined workflows" is a different claim from "this programme improved company delivery."

Feed the result back into the right layer

When an error repeats, decide which control should change.

An outdated repository convention belongs in repository context. A general validation habit may belong in a reusable workflow. A missing permission boundary may require tool access to change, not another paragraph in the prompt.

If the failure came from stale task evidence, repair the handoff or current-state check. If the skill added unnecessary steps, narrow when it applies. If the result remains ambiguous, keep the ambiguity in the record rather than forcing a favorable or unfavorable rating.

This is where evaluation becomes engineering work. The record is not the final product; the corrected operating arrangement is.

Useful attribution is specific enough to change the next task and modest enough not to invent a cause.

A smaller conclusion can be more reusable

I do not need every evaluation to end with a winner. I need to know which practice helped under which conditions, what required correction, and what the evidence could not distinguish.

That lets the next task inherit a more useful check or a simpler process instead of a larger claim.

The five articles in this wave share that approach. Context needs freshness. Green checks need scope. Tool output needs inspection. Reviews need a revision. Skills need honest attribution. None of those mechanisms removes the need for engineering judgement; they give it better material to work with.

That is the agentic engineering I want to describe: an environment that can learn from ordinary failures without pretending the agent was correct all along.

If a skill helped your work, what changed in the actual sequence of decisions? I'd be interested in that observation, including what your existing tools or judgement contributed alongside it.

The Backup Exists. The Restore Still Needs Work.

Maksym Kuzmitskyi (MaximusFT) — Fri, 16 Oct 2026 00:00:00 +0000

The database restores successfully to 10:42.

The payment provider has transactions through 11:07. Object storage contains invoices created after the restore point. The queue still holds jobs referring to orders the restored database does not remember.

The backup worked. We have not yet recovered the application.

I think this is the useful distinction to make before an incident. Recovery is not one storage operation. It is deciding which facts remain authoritative after different parts of the system have moved to different points in time.

Availability and recovery solve different failures

A replica can keep the service available after one machine fails. It may also faithfully replicate the accidental deletion we are trying to undo.

A backup preserves another state. Point-in-time recovery can reconstruct a database using a base backup and subsequent transaction-log records, within the retained recovery window. Its value depends on those records being available and the restore procedure actually working.

Neither mechanism automatically restores object storage, credentials, queue state, or external services.

I would define the failure being covered: infrastructure loss, accidental deletion, corruption, an incompatible migration, or compromised access. A design that handles the first can still be inadequate for the others.

Put a business meaning behind RPO and RTO

Recovery point objective describes acceptable data loss. Recovery time objective describes acceptable time to restore the required service.

"Fifteen minutes" sounds specific. It still needs a meaning. Can fifteen minutes of submitted support forms disappear? Of inventory reservations? Of charged orders? Those are different promises.

Some operations need reconciliation from another authoritative system even when the database recovery point is acceptable. A payment provider may tell us about a charge the restored database lost. We need a stable reference linking it back to the business operation.

For recovery time, include more than restoring bytes: provisioning, access approval, decryption keys, application startup, verification, reconciliation, traffic switching, and safe resumption of workers.

I would measure the whole exercise. A ten-minute restore inside a two-hour recovery procedure is not a ten-minute RTO.

Restore beside production, not blindly over it

For a logical data mistake, restoring an isolated instance gives us room to inspect the recovered state and compare it with current production. We may be able to repair a specific set of rows instead of rewinding everything.

Keep the recovery environment unable to send real emails, charge payments, consume production queues, or execute live webhooks. A copied database can contain pending work that application startup eagerly resumes.

Use controlled configuration and network access, not merely a promise that nobody will click the dangerous button. Preserve the original state as evidence while deciding which changes to apply.

Sometimes a full cutover is necessary. Even then, the new instance should be verified before traffic moves, with a deliberate plan for connections, endpoints, and old application instances.

DNS changes have the overlap behavior discussed earlier. Applications may also cache connection settings or continue using old pools. Changing a database endpoint is a release step, not a universal disconnect command.

Match data with code and configuration

A database restored to yesterday may have yesterday's schema. Today's application may require a column that did not exist then.

Record the schema migration state alongside artifact and configuration revisions. Retain deployable artifacts, not just source code that could theoretically be rebuilt with today's package registry.

An expand/contract migration gives recovery more options, but it does not remove the need to choose a compatible application version. Running every pending migration automatically against the restored instance may recreate the destructive change we were trying to investigate.

Secrets matter too. A backup encrypted with an unavailable key is not useful. A restored application with revoked credentials cannot necessarily reach its dependencies. Back up and test the recovery of access paths without scattering secret values through documents or logs.

External effects do not rewind with the database

Consider an order that was paid at 10:55 and lost from a database restored to 10:42. Asking the customer to retry can charge them again unless the payment operation has a durable, stable identity.

Reconcile against the provider using idempotency keys, merchant references, and the provider's authoritative transaction state. Do not infer a refund or charge from the absence of a local row alone.

Email is another external effect. A replayed confirmation job may send a second message. An invoice number may already have been issued. A shipment may already be in transit.

The recovery procedure should describe those consequences and the systems that settle them. We cannot restore the world to match a snapshot. We can reconstruct our records so they agree with the world that continued operating.

This is where the identity choices from the API and queue articles become more than implementation conveniences.

Queues and caches need a recovery policy

A restored outbox may contain events already published before the incident. A current queue may contain messages for records absent from the recovered database.

Pause consumers while reconciling. Decide which messages to preserve, replay, quarantine, or discard. Idempotent consumers reduce the cost of duplicates, but they still need a coherent business state to operate on.

Do not delete the queue simply to make its depth look tidy. It may contain the only remaining record of accepted work.

Redis also needs role-specific handling. Rebuild a disposable product cache from the recovered source. For sessions, consider whether invalidating them is safer than restoring older authorization state. For locks or scheduler metadata, old values may be actively misleading.

"Restore every dependency" is not always the right instruction. Some state should be restored, some reconciled, and some deliberately recreated.

Verify meaning, not only row counts

A database that starts and contains the expected number of rows is encouraging. It does not prove the checkout workflow is usable.

Check relationships, critical constraints, recent business operations, object references, account permissions, and one controlled end-to-end flow. Compare representative records with external authoritative systems where necessary.

Keep enough telemetry to tell when corrupted or missing data first appeared. Otherwise choosing a restore point becomes a sequence of guesses, each followed by another expensive restore.

Data integrity checks and recovery logs should avoid publishing private customer content. The people conducting a recovery need controlled access, not an unrestricted data export pasted into the incident channel.

Test the access path that an incident will use

A recovery exercise run by an administrator with every permission can conceal missing privileges in the actual emergency role. Test who can start the restore, decrypt it, deploy compatible code, change routing, and release the isolation controls.

For compromise scenarios, consider independent backup protection: restricted deletion, retention controls, and appropriate account or region separation. If the same credential can destroy production and every backup, the copies share a rather important failure mode.

There is no universal arrangement that makes all of this free. The choices should reflect the actual data, recovery promise, and threat model.

Document who makes the cutover decision and who handles reconciliation. That is operational ownership, not an excuse to collect an impressive runbook nobody has tried.

A useful drill has an inconvenient detail

Try restoring with an old schema, an unavailable primary region, a rotated credential, or a job already delivered once. Choose one complication rather than pretending the exercise must reproduce every disaster at once.

Measure the result, record the steps that required undocumented knowledge, and repair those gaps. A failed rehearsal is useful when it changes the recovery path before the real incident.

A backup preserves data. A rehearsed recovery preserves the ability to use it safely.

That is where I would end this field guide. The database, cache, queue, proxy, and application are not independent checkboxes. Their boundaries become visible when a request fails, a deployment overlaps, or one component returns to an earlier state.

I would be satisfied with an ordinary system whose recovery procedure is unremarkable because it has been tested. That seems a more useful goal than another layer whose failure behavior we will learn later.

If you've attempted a restore rehearsal, what took longer than the database restore itself? I'd be interested in the dependency or decision the backup dashboard could not account for.

A Review Belongs to a Commit

Maksym Kuzmitskyi (MaximusFT) — Thu, 15 Oct 2026 00:00:00 +0000

A reviewer sees a change and raises a useful concern. The author pushes another commit.

The comment is still there. The code it described may not be.

Human reviewers handle this imperfectly too. An automated reviewer makes the state-management problem easier to notice because it can repeat the same concern every time it runs, or confidently act on a conclusion from the previous revision.

The earlier PR-reviewer article focused on useful language and visibility into a personal tool. This article is about a narrower engineering problem: what a finding, check, or review decision refers to as the code changes.

I have developed commit-aware tracking, duplicate-finding safeguards, dry-run checks, and guarded actions in personal review tooling with AI assistance. That describes development of mechanisms, not current continuous operation, organization-wide adoption, or a replacement for human approval.

A PR number is not the reviewed object

The PR is a container for an evolving proposal. The head commit identifies one version of that proposal. The base revision and comparison mode also affect what the reviewer sees.

If an automated tool records only "PR reviewed," it cannot distinguish unchanged work from a new commit. If it records only head SHA, it may miss a changed base or integration result that matters to its conclusion.

A useful record identifies what was reviewed and under which assumptions:

type ReviewSnapshot = {
  headSha: string;
  baseSha: string;
  comparison: 'pull-request-diff';
  rulesRevision: string;
  checkedAt: string;
};

This is an illustrative type, not an internal implementation. The rules revision matters because the same code can be assessed differently after the checking policy changes.

I would not let a convenient database row imply more history than it contains. "Reviewed" should be explainable as a particular observation, not a permanent property of the PR.

CI has a revision too

A green check from an earlier commit does not establish the state of the current one. A required integration check may run on a merge result rather than the branch head. Those are different artifacts.

Before review actions, identify which checks are relevant, which revision they exercised, and whether they are finished. A skipped check or an optional success is not necessarily equivalent to every required gate passing.

Even then, CI evidence has the scope limits discussed in Green Checks Only Cover What You Checked. It can support a reviewable state without proving the absence of semantic defects.

I want a tool to report that distinction rather than promote "green CI" into "safe to approve."

A finding needs identity and evidence

Line numbers are useful for placement. They are poor long-term finding identities.

An author can move the same risky expression to another line. The finding remains relevant, but a line-based key changes and the bot may publish it again. Conversely, new code at the old line can have a different risk that a naive key suppresses.

A more semantic identity can include the rule, affected symbol, risk category, and relevant normalized evidence. Keep the exact source revision alongside it.

Normalization introduces its own trade-off. Strip too much context and different findings collapse into one fingerprint. Keep every character and harmless formatting changes produce duplicates.

Treat a fingerprint as a useful matching mechanism, not proof that two concerns are identical. Re-evaluate the current evidence before deciding the old finding still applies or no new comment is needed.

Suppressed does not mean resolved

A repeated finding can be current and intentionally not republished. A missing finding can mean it was fixed, became unobservable in the selected diff, or was skipped because the analysis failed.

Those states need different names.

current: the concern is supported by the latest evidence
unchanged: current, but no repeated comment is needed
resolved: evidence supports that the concern no longer applies
not-observed: this run did not establish either outcome
needs-human: the tool cannot settle the question safely

The exact storage model can vary. The distinction keeps duplicate suppression from quietly becoming automatic resolution.

An unresolved human thread is another state the tool should not overwrite simply because its own detector no longer sees the pattern. The thread may concern context or a decision that the detector never understood.

Recheck state before publication

Analysis can take time. While it runs, the author can push new code. A comment created from the original diff may now point to invalid lines or describe a risk that has already changed.

Re-read the relevant state before publishing. If it no longer matches the reviewed snapshot, stop, discard the pending action, or schedule another review. Do not silently attach the finding to a different revision because that makes the API call easier.

The same applies to stronger actions. A guarded action should carry the expected revision and use a platform-supported condition where available:

type GuardedReviewAction = {
  expectedHeadSha: string;
  snapshotId: string;
  action: 'publish-review';
};

This type expresses the requirement; it does not implement an atomic guarantee. Reading head and then calling an API leaves a time-of-check/time-of-use interval. If the platform cannot condition the action atomically, handle that limitation explicitly and avoid unsupported claims about stale-action prevention.

A fresh check reduces risk. It does not freeze another person's branch.

A dry run has its own evidence boundary

A dry run can show which findings and actions a tool would produce. It is useful for inspecting scope, tone, duplicates, and targeting without creating external effects.

It does not prove that the later API call will be authorized, attach to the intended line, or observe the same PR state. Nor does a successful API call prove the review content was correct.

Use the dry run to inspect proposed actions. Use publication checks to verify current state and delivery. Keep the two results separate in the control interface.

If the inline attachment fails, a body-level review may preserve the concern, but should still identify the source revision. A fallback should not turn a precisely scoped observation into an unexplained general warning.

Human decisions need context, not silent reassignment

A person may approve a particular revision. New code can change the basis for that decision. The tool should make that change visible and follow the platform's review policy rather than assume an earlier approval means the new code is accepted.

Whether an approval is dismissed, still valid, or requires a new decision depends on the repository's settings and accountable reviewers. The automation should not invent its own release authority.

Likewise, an AI suggestion that a dependency update appears routine is evidence, not permission to merge it. Any permitted automatic action needs its own narrowly defined authorization and technical controls. It should not be inferred from the absence of findings.

A review result describes observed code. It does not transfer responsibility for whatever code arrives next.

Preserve enough history to explain the tool

The control surface should answer ordinary questions: which revision was analyzed, what was published, what was suppressed, why a run stopped, and what remains undecided.

Record identifiers and outcomes with appropriate retention. Avoid storing raw credentials, private payloads, or unnecessary code copies just to make a log feel complete.

When the tool is wrong, the history should help reproduce the decision. Was the input stale? Did normalization merge two findings? Did a missing detector result get treated as resolution? Did the action target change between analysis and publication?

Those are repairable mechanisms. Without the history, every correction becomes a guess about the model's intentions.

The quieter reviewer is not necessarily the better reviewer

Duplicate suppression makes the conversation less noisy. That is useful. It can also hide an unresolved issue if the lifecycle is poorly modelled.

I would evaluate the tool on the relevance and traceability of its findings, not merely on how few comments it emits. Check unchanged code, moved code, corrected code, a new risk at the old location, and a head update during analysis.

Keep a human in charge of interpretation and approval. A review assistant should make that person's evidence easier to find, not create a reassuring status that no one can explain.

The next article, What a Skill Changed, and What It Didn't, examines the same attribution problem at workflow level: what a reusable skill changed, and what it did not.

If your review automation remembers that it saw a PR, what exactly does it remember about the code? That is a useful place to inspect before adding another action to it.

The Dashboard Is Green. The Order Is Missing.

Maksym Kuzmitskyi (MaximusFT) — Wed, 14 Oct 2026 00:00:00 +0000

The API error rate is low. The workers are running. The browser reported no uncaught exception.

A user says their order never appeared.

All of those observations can be true. We measured the health of individual pieces, while the user described an outcome across several pieces. The missing part is the connection between them.

I do not think the answer is simply to log more. A larger pile of unrelated events gives us more to read, which is not quite the same thing as giving us more to understand.

Start with the outcome we need to explain

For checkout, I would distinguish browser intent, request acceptance, order persistence, payment confirmation, and follow-up work.

These are not synonyms. A click event proves that someone activated a control. A 200 response proves that an HTTP exchange returned that status. A database record proves that an order was stored. A confirmation email proves another effect entirely.

The analytics layer and an operational trace also serve different purposes. Product analytics can describe behavior; operational telemetry needs enough context to reconstruct a specific failure without assuming every recorded click became a completed purchase.

I would define the business success point explicitly, then work backwards to the evidence required at each boundary. Otherwise the most available metric quietly becomes the definition of success.

A request id is useful, but it is not the whole identity

A request id correlates one HTTP attempt. An idempotency key identifies one intent across retries. An order id identifies durable business state. A trace context links spans across participating services.

Keeping these separate is helpful:

{
  "event": "order.persisted",
  "request_id": "req_9c7",
  "operation_id": "checkout_62a",
  "order_id": "order_18f",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "release": "checkout-2026-10-14"
}

These are synthetic identifiers. The record does not include a customer's name, email, address, token, or raw payment data.

A retry gets a new request id but retains the operation identity. A background job can link to the operation after the original request has ended. Depending on timing and instrumentation, a span link may describe that relationship more honestly than an endlessly extended parent span.

Use established trace propagation and instrumentation, such as OpenTelemetry, rather than inventing a collection of vaguely compatible headers. Still validate untrusted incoming context and keep authorization separate from any telemetry identity.

Missing data has several explanations

If a trace is absent, the request may never have happened. It may also have been sampled out, rejected by a collector, dropped from a full buffer, or generated by an uninstrumented component.

Head sampling decides early which traces to retain. It keeps costs bounded, but it cannot know at the start which request will fail late. Tail sampling can select after observing more of the trace, at the cost of buffering, coordination, and its own resource limits.

Neither gives perfect evidence automatically. Keep critical outcome counters and durable business records independently of a sampling decision. Record the telemetry pipeline's own drops and health so absence is less ambiguous.

For frontend error reporting, the same limitation applies. Browser extensions, network conditions, consent settings, and navigation can affect delivery. No recorded exception is not proof that no exception occurred.

Denominators need their own definition

"Twenty failed orders" is difficult to interpret without knowing how many attempts occurred and which attempts count.

Counting API requests exaggerates user intent when retries occur. Counting clicks includes actions rejected before a request. Counting created orders excludes failures before persistence.

For an outcome metric, define both numerator and denominator around the promise being measured. For example: distinct accepted checkout operations that reach a confirmed or explicit terminal state within a chosen interval.

Then describe exclusions: abandoned carts, expected validation failures, test traffic, and operations still inside their allowed processing window. An illustrative target is not a universal SLO.

The arithmetic is usually easy. The difficult part is resisting a reassuring percentage with a poorly chosen population.

Cardinality is a modelling choice

Metrics work well with bounded dimensions such as route templates, status categories, region, and service.

Attaching order_id, raw URLs, or customer email to every metric label creates huge numbers of distinct time series. It also turns the monitoring system into a rather expensive and unsuitable customer index.

Use /orders/:id, not every concrete order URL, as a metric dimension. Put specific identities in controlled logs or traces when needed, with retention and access appropriate to their sensitivity.

Histograms deserve some care too. Percentiles computed independently by instances cannot generally be averaged into the fleet's percentile. Aggregate compatible histogram observations rather than averaging whichever p95 numbers happen to be on the screen.

The goal is not to avoid detail. It is to put detail into the kind of evidence that can handle it.

Frontend context can make a backend trace usable

A server sees requests. The browser knows which route, interaction, and release led to them.

For an error-reporting tool such as Sentry, a release identifier and matching source maps can turn a minified stack into something useful. Upload source maps through controlled tooling; decide whether publicly serving source files is intended. A production error should identify the bundle that actually ran, not the latest source in main.

Session replay can help explain interaction sequences, but I would not enable it broadly without reviewing masking, consent, sensitive fields, retention, and access. "It is an internal admin screen" is often a reason for more care, not less.

Expected cancellation should not appear beside faults as though a user navigating away is a broken system. The AbortController article covers that distinction at the interface boundary.

An alert should name a response

High CPU may deserve investigation. Missing orders deserve investigation for a more direct reason.

Prefer alerts connected to user-visible impact or exhausted safety margins: sustained error-budget consumption, queue age beyond the product allowance, connection-pool waits, failure to complete accepted operations, or a recovery dependency approaching expiry.

The notification needs an owner, a scope, and a useful next action. A chart link is helpful. So are a recent deployment marker and a runbook that says which evidence separates an application failure from a shared-dependency failure.

I would not page someone every time one instance reports a brief spike unless that spike calls for a meaningful intervention. Noise does not stay harmless; it changes what people notice later.

Telemetry is another dependency

Exporters have buffers, network calls, timeouts, and shutdown behavior. A slow collector should not cause the checkout handler to wait indefinitely or allocate unbounded memory.

Use bounded, asynchronous export appropriate to the instrumentation. Decide what can be dropped and what must be durably recorded elsewhere. Business events required for fulfilment belong in a durable mechanism such as the transactional outbox, not solely in a best-effort log stream.

Also test redaction failures and collector outages. Observability should help us explain failure without becoming its next cause or a route for leaking data.

A telemetry event is evidence with delivery conditions, not a second database transaction.

Reconstruct one unsuccessful operation

I would exercise a deliberately failed checkout and try to follow it from browser intent to its final state. Can we distinguish a request that never arrived from an order that persisted but lost its response? Can we find the background job? Can we identify the release and a retry without counting them as two purchases?

If those questions are difficult, another dashboard will not necessarily improve the situation. A better identity or an event at the missing boundary might.

The green dashboard becomes useful when we know exactly what its green means. Until then, I would keep the user's missing order as the more interesting observation.

The final part of this guide covers backups and recovery: what happens when diagnosis is finished and some part of the system actually has to be rebuilt.

Which production question still sends you comparing timestamps across three tools? I'd like to hear the missing connection, not just which monitoring product you use.

The Command Succeeded. The Scope Changed.

Maksym Kuzmitskyi (MaximusFT) — Tue, 13 Oct 2026 00:00:00 +0000

The agent inspects a small diff and runs the required command.

The command succeeds. A hook also regenerates a contract file from a newer source, and the resulting commit contains a change nobody asked for.

That is not a runaway agent. It is fairly normal repository automation doing what it was configured to do. The workflow still needs to decide whether the output belongs in this task.

I have used this kind of scope drift to refine the checks around delegated work. Reviewing an initial diff is useful; reviewing the artifact after automation is also necessary. They are not always the same artifact.

The example is deliberately synthetic

Consider this illustrative composite, not a file tree from an actual company repository.

A task updates one client dependency. Before the commit, the changes are:

package.json
package-lock.json

A repository hook refreshes generated API code. The commit now also contains:

src/generated/catalog-api.ts
src/generated/catalog-schema.json

The generator may be correct about the source it read. The new contract may be a legitimate change. Neither fact says it belongs in a dependency-only PR.

It could need another owner, another compatibility check, another release sequence, or simply a separate explanation. A successful generator run does not provide those decisions.

There are several versions of the change

A Git operation has more than one relevant state: working tree, index, commit tree, and the remote branch used by review.

An agent can inspect the working tree, stage a subset, and then assume the commit contains that subset. A hook can change files or restage content between those steps. Later, a push hook or generated build output can leave additional local changes that are not committed at all.

The useful question is "which artifact did we verify?"

These generic inspection commands address different artifacts:

git diff --name-status
git diff --cached --name-status
git show --format= --stat HEAD
git show --format= HEAD
git status --short

The first two compare working and staged changes. The next two inspect the actual commit. The final status shows what remains outside it. None, by itself, establishes whether the whole task is correctly scoped.

I would inspect the post-hook commit before treating it as ready for review or push. If the repository runs consequential automation during push, inspect its effects too rather than assuming the operation left no new state.

Capture the starting state

Scope checks are less useful if the agent does not know which changes existed before it started.

A working tree can already contain another person's edits. A generated file may have been dirty before the task. A script may update it again, mixing pre-existing content with the agent's output.

Record the branch, base revision, and clean or dirty status before implementation. For relevant dirty files, understand the existing changes instead of treating everything outside the task as disposable.

This is especially important when recovering from generated drift. "Remove unrelated files" is not permission to overwrite a colleague's uncommitted work.

The safe recovery depends on provenance: which change was introduced by this operation, which was already present, and which now conflicts with the authorized work. If that cannot be established cheaply, stop and ask rather than manufacture a clean tree.

A file allowlist helps, but it is not the contract

For a bounded task, an expected file set can reveal surprises:

Expected: dependency manifest and lockfile
Observed: manifest, lockfile and generated service contract
Decision needed: does the contract change belong to this task?

Sometimes the right implementation legitimately needs another file. A test, a call site, or an adapter may be required to satisfy the original behavior. A strict allowlist should expose that question, not force an incomplete fix.

The reverse is also true: changes inside an expected file can be unrelated. A lockfile may contain several package updates. One generated module can include multiple contract changes with different owners.

Review semantics as well as filenames. The requested scope is an engineering constraint, not a glob pattern.

Generated does not mean low risk

Generated artifacts can encode public APIs, schemas, route tables, database clients, or configuration. A small mechanical change there can affect more consumers than a large handwritten component edit.

A tool may regenerate against a remote source whose revision is not recorded. Run it twice and it can produce two different outputs from the same local commit. The task has acquired an external input even though nobody edited an external file by hand.

Where practical, pin and record the generator version and input revision, or preserve the relevant source snapshot. Keep generated output reproducible enough to explain a future diff.

If a live input is intentional, review the new output with that knowledge. Do not present it as a consequence of the dependency change when it came from unrelated source drift.

Do not bypass the gate just to avoid its output

The tempting response is to disable the hook and finish the small PR.

That may discard a required repository control. It also avoids the useful question of why this hook introduces changes unrelated to the task.

Follow the repository's supported procedure. It may allow a separate generated update, a pinned input, a check-only mode, or an explicitly approved exception. The agent should not invent an exemption because the hook is inconvenient.

After separating unrelated drift, run the checks that matter for the retained change and inspect the final artifact again. A repaired scope still needs verification; the earlier green result may have observed a different set of files.

Tool success is not scope approval

An exit code tells us whether the tool considers its operation successful. It does not certify that the operation had the intended inputs or that every resulting change was authorized.

This applies beyond Git hooks. A formatter can touch unrelated documents. A package manager can alter registry URLs or transitive versions. A code migration can rewrite more call sites than the agreed rollout intended.

The agent's explanation should identify those effects, not compress them into "all commands passed."

The command's success belongs to the command. Approval of the resulting scope belongs to the task.

That distinction allows useful automation without pretending tools understand the whole purpose of a change.

Make the check repeatable, not the incident immortal

After a scope problem, I would refine the workflow around the failure condition: record the starting state, inspect after mutating automation, and verify the artifact that will actually be reviewed.

I would not add a permanent paragraph describing every generated file from that one incident. Those details age quickly. The principle remains useful across different generators and repositories.

The rule also needs proportion. A read-only test command does not need the same artifact accounting as a commit hook that regenerates contracts. Use the checks where state can change, and keep the explanation local enough that the agent can apply it.

The final diff should be unsurprising for the right reason

An agent can produce a neat initial patch and still need help with the effects of the surrounding toolchain. That is not a contradiction. The repository is part of the execution environment, and it can change the result.

I want a reviewer to find the final scope unsurprising because the task explains every meaningful change, not because generated files were hidden from the description.

The next article, A Review Belongs to a Commit, follows that reviewed artifact as it changes again. A later commit can make yesterday's finding or decision stale.

If a tool in your repository can change the artifact after its last inspection, where is the next inspection scheduled? That small gap is worth closing before adding more autonomy.

More Replicas, the Same Database

Maksym Kuzmitskyi (MaximusFT) — Mon, 12 Oct 2026 00:00:00 +0000

The application is slow, so the autoscaler adds replicas.

Each new replica opens its normal database connection pool. The database was already waiting on locks. Now it has more callers waiting on the same locks.

CPU on the application instances improves. Checkout latency does not.

Nothing in that sequence is especially exotic. We scaled the part that could multiply, without checking the capacity of the part all those copies still share. I find that a more useful starting point than the usual discussion of which load-balancing algorithm looks fairest.

The unit of scaling includes its dependencies

An application replica is not just a process with some CPU. It is also a database pool, a set of cache connections, outbound calls, retry behavior, and startup work.

Consider a simplified connection budget:

database limit: 200
reserved for administration: 20
workers and other services: 40
available to the web application: 140

8 replicas x 15 pool connections: 120
12 replicas x 15 connections: 180

These numbers are illustrative. A pool maximum does not mean every process immediately opens every connection, but it is a capacity promise we need to bound. A rolling deployment can temporarily run both old and new replicas. The maximum deployment overlap belongs in the budget too.

I would cap replica count and per-process concurrency together. A connection pooler may help, but it cannot make a transaction release its locks sooner or make a slow query cheaper.

Queuing moves; it does not disappear

If the application accepts work faster than it can finish, requests wait somewhere: at the proxy, inside the process, in the pool, or in the database.

An unlimited internal queue can make an overloaded service look healthy until requests exceed every client timeout. By then the service may still be doing work for callers that already gave up.

Explicit admission limits give the system a more useful response. Bound concurrency, reject excess work with a deliberate status, and decide whether a retry can safely occur. Do not spend thirty seconds doing an operation whose result the caller is no longer waiting for.

Cancellation matters, but cancelling a browser request does not automatically cancel the database operation. Deadline propagation needs to reach the layers that support it, with transaction cleanup handled deliberately.

I would prefer a small number of quick, understandable overload responses to a large number of ambiguous timeouts. That choice is less attractive on a throughput chart and more attractive during an incident.

Retries can manufacture the next spike

A browser retries. The gateway retries. The application retries its upstream call. Three attempts at each layer can multiply rather than merely add.

If the original work is slow because a shared dependency is saturated, retrying immediately adds more work to that dependency. The request deadline may also restart at each hop, extending the actual time spent far beyond what the caller expects.

Assign retry ownership. Use a bounded budget, backoff, jitter, and idempotency for writes. Honor useful rate-limit guidance such as Retry-After rather than asking every client to guess its own recovery rhythm.

Retries are appropriate when another attempt has a reasonable chance of finding different conditions. They are not a substitute for an overload policy.

Stateless does not mean there is no state

The practical meaning is narrower: another instance can handle the next request without relying on unique state in the previous instance's memory.

Sessions may live in a shared store. Uploaded files belong in durable object storage. Order state belongs in the database. Any replica can reconstruct what it needs.

Local caches are still possible. So are in-memory counters and background bookkeeping, provided they are explicitly disposable and do not claim global correctness.

Sticky sessions can keep a client on one instance, which may be useful for a specific workload. They do not make that instance durable. When it disappears, the unique state disappears too unless a recovery path exists.

I would describe required affinity as a constraint rather than advertise a system as stateless while quietly depending on the load balancer to remember each user.

Health checks are routing policy

A liveness check asks whether the process can continue. A readiness check asks whether it should receive new work. A synthetic business check asks whether a useful operation succeeds. They do not necessarily belong in the same endpoint.

Suppose every instance's readiness check requires Redis to respond. Redis has a shared outage, so every instance becomes unready. Removing all instances may be correct for a session-only application that cannot authenticate anyone. It may be unnecessary for public product pages with a database fallback.

Restarting all processes because a shared dependency is slow can also worsen recovery by creating connection and cache-warming bursts.

There is a specific AWS detail worth knowing: ALB fails open when a target group has only unhealthy registered targets. It can route to those targets rather than treating health failure as a guarantee of no traffic.

This is not a recommendation to return false health results. It is a reminder to understand the platform's actual response and keep application safeguards in place. The health check does not become a security boundary just because the dashboard colors it red.

Scaling needs time to become useful

A new instance may need to pull an image, initialize connections, load configuration, and warm required state before becoming ready. Autoscaling follows observations with a delay; it cannot instantly absorb a sudden spike.

Keep enough baseline capacity for the workload that cannot wait, and choose signals that reflect the bottleneck. CPU can help for compute-heavy traffic. Queue age may better describe workers. Pool wait time or active-request concurrency may reveal pressure that average CPU hides.

Avoid a warmup procedure that makes every new replica perform the same expensive full-cache refresh. The capacity meant to help the database can briefly become its largest customer.

Scale-in is equally important. A quiet instance may still hold a long request or many WebSocket connections. Removing it is a lifecycle event, not just subtracting one from a counter.

Draining coordinates several timers

The load balancer has a deregistration delay. The process has a shutdown grace period. Requests have deadlines. Connections have idle timeouts. These settings need to agree on how ongoing work ends.

Stop admitting new requests, allow existing work a bounded interval, then shut down. If the platform kills the task before the drain interval finishes, the load balancer's generous delay does not help.

For WebSockets, draining may require application messages and client reconnection. A reconnected client can land on another replica; events and subscriptions need shared or reconstructible state. The replacement must not assume the old connection's in-memory history is available.

A slow deployment should not require every user to discover the reconnection policy through a frozen screen.

Test a removal, not only an addition

A useful scaling exercise removes an instance while traffic is active. It observes errors, latency, duplicate writes, session continuity, and long-lived connection recovery.

Test mixed versions too. Schema compatibility and old frontend bundles remain relevant while the load balancer serves both generations. Retain content-hashed assets long enough for active clients to finish or recover cleanly.

These tests make capacity a statement about the whole service rather than a count of containers.

I am comfortable with modest scale when the limits are known. I am less comfortable with an autoscaling policy whose only promise is that more processes will appear whenever something becomes slow.

The shared database has not read that promise. It will keep accepting only the work it can actually perform.

Next, the upcoming article on production observability looks at how to see these limits before an error report becomes the first measurement.

When your replica count grows, which downstream quantity grows with it? I'd start a scaling review with that number, before choosing another autoscaling signal.

Green Checks Only Cover What You Checked

Maksym Kuzmitskyi (MaximusFT) — Sun, 11 Oct 2026 00:00:00 +0000

The build passes. The tests pass. The dependency update is small.

The integration check disagrees.

I do not find that especially surprising. A local check and an integration check can ask different questions about the same change. The awkward part begins when the agent treats the first green result as evidence for a larger conclusion than the check supports.

In The Work Around the Agent Is Engineering Work, I described the work around an agent as part of the engineering itself. One useful responsibility in that work is keeping the scope of evidence visible.

A fictional contract makes the distinction easier to see

The following is an illustrative composite. Names, fields and implementation details are invented; it is not a reconstruction of an identifiable system or an internal contract.

A booking service consumes a delivery window from a planning service. The contract previously used an ISO timestamp. An updated client expects an integer timestamp in milliseconds.

The booking service's local fixture is updated too:

type DeliveryWindow = {
  startsAtMs: number;
};

const window: DeliveryWindow = {
  startsAtMs: 1_800_000_000_000,
};

The compiler accepts the fixture. The local tests confirm that the booking code handles that fixture correctly.

Neither observation tells us which representation the deployed planning service actually returns. If it still returns the previous shape, the local result is not wrong. It is simply narrower than "these services remain compatible."

This is one reason I would not call local validation a miniature version of the whole production system. Its exclusions are often exactly what lets it run quickly.

Evidence has a scope and a revision

For each check, ask what it exercised and which code it observed.

A test against a mock exercises the mock contract. A test against a generated client exercises the declaration and the path using it. An integration gate may inspect a combined contract or contact a real environment. A package's exported type can differ from its runtime behavior or from what another participant still expects.

The checks have different value. They do not automatically inherit each other's coverage.

I would keep a small evidence record:

Check: booking service unit tests
Observed revision: current task commit
Established: local handling of the declared delivery window
Not established: compatibility with the deployed planner

Check: shared integration contract gate
Observed inputs: declared participating revisions
Established: compatibility within that selected set
Not established: behavior of every deployed client

This is not a demand for a document after every test command. It is a way to make the distinction explicit when the check is being used to justify a consequential decision.

A green integration result also needs an honest boundary. It can be based on a particular environment, selected revisions, or a contract model. It is stronger evidence for some questions, not proof of every runtime property.

Read the package, not only its version label

When a dependency change is involved, inspect what was installed: package metadata, declarations, runtime exports, and the relevant contract representation.

A requested version in a manifest is not the full observation. The lockfile, registry artifact, workspace resolution and build output determine what code is actually used. A stale installation can make an agent diagnose a version that is not the one under test.

This does not mean dumping the entire dependency tree into context. Start with the disputed boundary and follow the few inputs that decide it.

I want the agent to compare evidence it can point to, rather than expand an explanation around a guessed package behavior. More confident prose does not resolve disagreement between an artifact and a declaration.

Several repositories do not form one snapshot

Giving an agent access to related repositories is helpful. It does not make their branches, local changes, and deployed versions coherent automatically.

One repository may be on a current base. Another may have an old checkout. A third may contain a pending fix that already changed the intended migration path.

Before reasoning across them, identify the revisions and the purpose of each source: current main, active task branch, proposed change, or deployed release. A locally visible implementation can be real without being the implementation production uses.

Repository memory should help locate those questions, not answer them from an earlier session. The source of truth for current compatibility is the current relevant state.

Recheck the problem before repairing the diagnosis

The composite continues. Further investigation finds a compatible change already delivered through another path. The original dependency update is now obsolete.

There are two different next actions available: make the old proposal more elaborate, or stop pursuing it.

An agent can be quite good at the first. It has a task, a branch and an explanation to complete. That momentum is useful when the task remains valid. It is not useful when the current system no longer needs the proposed work.

The correct result can be closing the obsolete PR and recording why it was superseded. Do not describe that as delivering the other change. Do not rewrite the history so the incomplete initial diagnosis becomes a clean success.

The useful outcome is a rejected unsuitable proposal and a better freshness check for the next task.

Before asking whether the patch works, ask whether it is still the patch the system needs.

This is particularly valuable with agents because implementation is relatively easy to continue. Deciding not to continue still requires evidence and an accountable owner.

Correct the workflow at the missing boundary

If the initial diagnosis relied on stale or incomplete sources, merely fixing the current diff leaves the same failure available next time.

Move the relevant current-base or related-change check earlier. If a shared contract matters, make the integration gate part of the verification criteria. If the package contents were assumed, inspect the actual artifact before proposing a fix.

Keep the correction proportional. One incident does not justify requiring every task to scan every repository. A small single-repository CSS change and a shared dependency migration do not need identical discovery work.

The rule should describe the condition that makes the check useful: cross-service contracts, dependency behavior, version skew, or an active related change. Otherwise a lesson becomes another universal instruction the agent follows even when it has no bearing on the task.

Separate a failed assumption from a failed person

An incomplete AI diagnosis deserves correction. It does not need a theatrical explanation about agents being incapable, nor a reassuring story in which the model secretly intended the right thing.

Record the assumption, the contradicting evidence, the correction, and the remaining uncertainty. That is enough to learn from the task.

It also gives credit accurately. A person may notice the stale base. CI may reject the shared contract. The agent may then help compare sources and prepare the explanation. Those contributions can all be real without being compressed into "AI solved it."

Keep green useful by keeping it specific

I want local checks to stay fast and valuable. Their usefulness does not depend on pretending they cover the whole system.

A build confirms something about the selected sources and toolchain. A test confirms behavior under its chosen conditions. A related contract check adds another layer. Current-state investigation tells us whether the task itself still makes sense.

The result is not certainty. It is a decision with evidence that matches its scope.

I would rather close one well-explained obsolete proposal than merge an increasingly polished implementation of yesterday's requirement. There is less to show in the diff, but more of the system has been understood.

The next article, The Command Succeeded. The Scope Changed., looks at another boundary green checks do not automatically cover: what automation changed after the initial edit.

If a check in your workflow is routinely used to justify more than it tested, which claim gets attached to it? That gap is usually worth examining before adding another test suite.

A Small AWS Deployment, With the Awkward Parts Included

Maksym Kuzmitskyi (MaximusFT) — Sat, 10 Oct 2026 00:00:00 +0000

A diagram with CloudFront, a load balancer, some containers, and a database is a reasonable start.

It does not tell us whether the checkout page can cache someone else's order, whether the containers can download their image, or who is allowed to restore the database after a bad migration.

Those details are where I would spend the second pass. The boxes are familiar enough. Their permissions and failure behavior deserve a little more attention.

For this article, assume an illustrative React application with a Node backend, PostgreSQL, and a few background workers. This is a proposed deployment shape, not a claim about a system I have operated or a measured monthly bill.

Give each component a limited job

One possible layout is:

public DNS -> CloudFront
                -> static assets in S3
                -> application routes through ALB
                     -> ECS/Fargate application tasks
                          -> RDS PostgreSQL
                          -> optional ElastiCache

queue -> separate worker tasks

CloudFront is the public edge. ALB distributes application traffic. ECS manages tasks; Fargate avoids operating the underlying servers directly. RDS runs the database. Redis is optional and should have the explicit job we discussed earlier.

I would not add Redis simply to complete the diagram, or Kubernetes simply to make the deployment feel serious. A managed application platform may also be sufficient. The point of this layout is understanding responsibility, not demonstrating the largest collection of AWS abbreviations.

A cache policy is part of authorization safety

Static, content-hashed assets are good candidates for long-lived caching. A signed-in customer's order page is not the same kind of object.

CloudFront distinguishes which values form the cache key from which values are forwarded to the origin. Sending a session cookie to the backend does not, by itself, guarantee responses are isolated correctly in the cache.

For private application responses, start with caching disabled and explicitly configure authentication forwarding. For public cacheable responses, include the dimensions that actually change the representation. Test with two separate users, not twice with the same session.

There is a particularly useful detail in the CloudFront cache behavior documentation: a minimum TTL above zero can force caching even when the origin sends private, no-store, or no-cache.

That is not a theoretical distinction. The application and infrastructure can each look reasonable in isolation while their combined policy is wrong.

Path-pattern ordering matters too. A broad public behavior matching before a narrower protected behavior can apply the wrong rule. I would review edge configuration like application code, including tests for authenticated and unauthenticated variants.

Private does not mean disconnected

Application tasks and databases should not be needlessly reachable from the public internet. But tasks still need outbound paths: pull images, obtain secrets, write logs, and contact payment or email providers.

Putting a task in a private subnet without arranging those paths produces a deployment that cannot start or cannot finish its normal work.

NAT provides general outbound connectivity. VPC endpoints can provide private access to supported AWS services. They have different setup, availability, and cost implications; neither is a universal instruction to copy without checking the task's actual dependencies.

For a small deployment, NAT, load balancers, logs, and minimum database capacity can be a meaningful part of the bill even when application traffic is low. I would estimate those standing costs before optimizing the price of one container.

Do not publish the database merely because it makes a first connectivity test easier. Use a controlled administrative path and keep the production network model intact.

Security groups express specific relationships

Rather than allowing the whole subnet to reach every component, define who needs to talk to whom.

The application's security group can accept traffic from the ALB group on the application port. The database can accept its database port from the application and worker groups that need it. Other callers do not acquire access simply by sharing a VPC.

Also consider origin bypass. If clients can call the public ALB directly, they may bypass restrictions applied only at CloudFront. Depending on the design, use a supported private-origin arrangement or restrict the public origin with appropriate network and request controls. The application must still enforce authentication and authorization itself.

These controls compose. A hidden origin is not an authorization system, and an authenticated route is not a reason to leave every network port open.

The task has two different identities

ECS distinguishes an execution role from a task role.

The execution role supports platform work such as pulling images and delivering configured logs or secrets. The task role is the identity the application uses when calling AWS APIs.

Giving the execution role permission to read an application bucket does not necessarily give the running code that access. Conversely, copying a broad deployment role into the task gives every application bug more authority than it needs.

Keep the roles narrow and separate. Use workload credentials rather than embedding long-lived AWS keys in the image. When access fails, identify which role made the request before adding permissions until the error goes away.

That last approach does work remarkably well at producing permissions nobody can later explain.

Fargate tasks still need a resource budget

Managed compute does not remove per-process connection pools or memory behavior. Two tasks with twenty PostgreSQL connections each are a different load from twenty tasks with the same setting.

Deployment overlap counts too. New tasks start before old tasks drain. The database must tolerate that temporary peak, or the release can run out of connections while average CPU remains comfortable.

RDS Proxy may help pool and manage connections, but it is not a cure for long transactions or unlimited concurrency. Application behavior still determines how long connections remain occupied.

Set a maximum scale consistent with downstream capacity. Separate workers from HTTP tasks so increasing export throughput does not quietly change the web service's deployment and resource profile.

Managed availability is not application continuity

Multi-AZ database deployment can improve availability during infrastructure failure. A read replica addresses a different concern and may lag. Neither undoes an accidental deletion that the database correctly accepted.

Redis failover also has semantics. If cached product descriptions disappear, the database can refill them. If sessions or coordination state disappear, the product consequence is different.

I would name those outcomes before choosing service options. "Highly available" is a useful infrastructure property, but it does not mean an order can be repeated without duplication or that a replica provides the latest permission change.

Backups and recovery get their own article, The Backup Exists. The Restore Still Needs Work. They belong in the initial infrastructure plan even if the first restore exercise comes later.

Deploy an artifact, not a moving tag

A controlled release records an image digest, configuration revision, migration step, and deployment outcome. Infrastructure as code records the intended topology so another environment can reproduce it without reconstructing yesterday's dashboard clicks.

Use an additive migration phase, deploy compatible tasks, observe health and business outcomes, then perform destructive cleanup in a later release. Give long-lived connections a drain policy and old browser assets a retention policy.

A rollback should name which pieces return to their previous state. The database does not automatically move backwards because ECS deploys the previous image.

Finally, add alarms with an owner: application error rate, latency, failed deployments, queue age, database saturation, and spend. Budgets are notifications unless explicit controls say otherwise; they are not a promise that AWS will stop the bill at an exact amount.

I would rather deploy this modest layout with known limits than a more elaborate one nobody can safely change. The diagram can stay small. The operating agreement needs enough detail to survive the first inconvenient event.

The next article examines load balancing and scaling, including why adding healthy replicas can make a shared database less healthy.

When reviewing an AWS layout, which relationship takes the longest to explain: network access, IAM, cache policy, or recovery? That is usually a useful place for the next design conversation.

The Work Around the Agent Is Engineering Work

Maksym Kuzmitskyi (MaximusFT) — Fri, 09 Oct 2026 00:00:00 +0000

A coding agent returns a plausible diff. The local tests pass. It has followed the requested format and written a sensible explanation.

There is still a fairly ordinary question left: what does that evidence actually establish?

Perhaps the tests cover only one service. Perhaps a hook added files after the diff was inspected. Perhaps another change already solved the problem, so the proposed update is now unnecessary. The output can be quite competent while the decision to ship it remains wrong.

That is the part of working with agents that increasingly interests me. Not another way to phrase the request. The conditions around the request that make a result possible to check, continue, and sometimes reject.

I have been designing and iteratively refining that environment as part of my engineering work. Repository instructions, connected tools, validation steps, review handling, and session handoffs became things to maintain rather than instructions to repeat in every conversation.

I would describe this as agentic workflow engineering. It is still software engineering. The responsibilities have moved around a little; they have not disappeared.

The diff is one artifact in a longer operation

Here is a deliberately generalized composite, not a reconstruction of one identifiable project.

Two services share a contract. An agent updates a dependency in one repository. The local build accepts the new types, and the tests confirm the behavior that repository knows about. A separate integration check finds that the other service still expects a different representation.

The first diagnosis is incomplete. Before making another patch, the engineer checks the actual package contents, current contracts, base branch, and related changes. A compatible solution has already arrived through another change. Continuing the original update would now introduce a regression rather than finish the task.

The useful result is to stop and close the obsolete proposal.

There is no new feature to celebrate. There is a clearer account of the system and one unsuitable change that did not enter it. I think that is worth recognizing as an engineering outcome, without pretending it measures a productivity gain.

The agent helped investigate. A person still had to decide what the evidence meant, correct the initial assumption, and change the workflow so freshness checks happened earlier next time.

My contribution is the operating arrangement

There is an unhelpful choice in some descriptions of AI-assisted work: either the engineer wrote everything personally, or they merely asked a chatbot to do it.

Neither explains what I am doing.

My contribution includes defining the task, organizing access to relevant context, choosing constraints, examining decisions, interpreting failures, and refining the next attempt. The agent can inspect sources, propose changes, run checks, and prepare reviewable artifacts inside that arrangement.

I do not need to claim manual authorship of every generated line to own those engineering decisions. Equally, a generated implementation does not make the environment around it automatically good.

I have integrated existing tools rather than built every tool involved. MCP connections help bring requirements and documentation into reach. Git, CLI/API access, tests, type checks, builds, and browser verification contribute different kinds of evidence. Each needs a clear reason to participate in the task.

The distinction matters when describing the work: integration, configuration, development, evaluation, and adoption are separate claims. I would rather use the smaller accurate verb than let a convenient headline imply the larger one.

Context needs authority and a lifetime

Giving an agent more text is not necessarily giving it better context.

Personal working preferences, shared engineering standards, repository rules, and task requirements answer different questions. A general suggestion should not override the API contract in the current code. A remembered convention should not defeat a test result observed now.

I use saved context to reduce repeated explanation and support continuation. I still expect the agent to verify current sources. Memory can become stale, and instructions can preserve a decision after the reason for it has changed.

For an active task, a compact continuation record might look like this:

Goal: accept the new response shape without changing existing callers
Current observation: one caller still consumes the previous field
Decision: retain the compatibility adapter for this release
Verified: caller inventory and focused adapter tests
Unverified: downstream deployment sequence
Next step: confirm the rollout contract before removal

This is an illustrative record, not an internal artifact. It separates observations, decisions, checks, and uncertainty. A new session can challenge it against the repository instead of treating the summary as a complete memory of reality.

I do not promise identical behavior across models or sessions. The more defensible promise is a documented place to resume and a way to notice when it no longer matches the work.

Autonomy is partly a permissions problem

Written boundaries are useful: which operations are allowed, when to ask, and what must not be disclosed. They are not enforcement by themselves.

Tool credentials, available commands, environment isolation, branch protections, and executable gates also determine what can happen. A rule that says "do not release" is weaker than an environment where the agent cannot release without an accountable person's action.

The design depends on the task. Low-risk investigation and focused checks can usually proceed without a sequence of tiny approvals. Business requirements, architectural commitments, sensitive actions, and release decisions need the appropriate owner.

I want the agent to have enough room to work, not enough authority to settle every question it encounters.

This also makes a stop meaningful. If acceptance criteria are unclear or current evidence contradicts the request, continuing to produce code is not necessarily progress. The next useful artifact may be a question or a bounded proposal.

A small change deserves a discriminating check

Before the first edit, I ask the agent to locate the code that controls the behavior, state a local hypothesis, and choose a check that could disprove it.

That is less impressive than a long repository survey, but often more useful. The goal is not to read every nearby file before acting. It is to know which assumption the next small edit will test.

After that edit, run the focused check before expanding the change. If it fails, decide whether it exposed a local defect or showed that the hypothesis was wrong. Broader tests, lint, build, CI, and acceptance checks follow according to the risk and repository requirements.

The focused check does not replace the broader gates. It keeps us from spending a large patch on an assumption we could have disproved cheaply.

For a small, clear task, I do not need a specification document that repeats the ticket. For a risky or multi-session change, writing down assumptions and a plan before implementation can be valuable. The timing is part of the evidence: a plan written after the work cannot demonstrate that the work was specification-driven.

Tools have outputs that need their own review

A command can succeed and still change more than the task authorized.

Generators, package installation, hooks, formatting, and deployment tooling can all transform the artifact after the initial edit. The working diff we reviewed may not be the commit tree that a hook produced.

I have used that kind of failure to refine the workflow: inspect the result after automation, separate unrelated generated drift, and verify what is actually being proposed.

It is a fairly undramatic control. That is one of its useful qualities. It does not require the agent to recognize every possible reason a generator changed a file. It requires the scope of the result to be checked before it leaves the local operation.

The next two articles, Green Checks Only Cover What You Checked and The Command Succeeded. The Scope Changed., examine those boundaries in more detail.

Review is evidence attached to a changing object

I have also developed personal PR-review tooling with AI assistance. The work includes tracking revisions, avoiding repeated unchanged findings, dry-run checks, and guarding actions against stale state.

That is a statement about mechanisms I developed, not a claim that the tool is continuously operating today, deployed across a company, or safely replacing human approval.

The engineering problem is interesting on its own. A finding can remain relevant while its line number changes. A new commit can remove the risk but leave an old comment. A review decision can become stale when the object it described changes.

I want the automation to provide useful evidence without silently taking over accountability. A Review Belongs to a Commit follows that boundary, including the limitations of duplicate suppression and head checks.

Improvements need careful attribution

I participate in evaluating reusable agent skills against real engineering work. That does not make me the owner of an organization-wide transformation, and it does not establish that a particular framework caused a measured improvement.

A successful task can depend on repository instructions, tool access, a well-chosen test, current domain knowledge, or a person's correction. A skill may contribute, add ceremony, or simply describe a practice already present.

I try to keep those explanations apart. Record the outcome, corrections, residual risks, and what the available evidence can attribute. Unknown is a reasonable answer when the task does not support a stronger one.

What a Skill Changed, and What It Didn't will make that distinction concrete without inventing comparative results.

The useful specialization is not a new claim about the model

This work does not mean I train models, conduct ML research, or operate production MLOps. It also does not mean role-based agent configurations have become reliable multi-agent execution simply because the definitions exist.

It means I design the conditions in which coding agents participate in software delivery: context, tools, boundaries, checks, human decisions, and a way to learn from ordinary failures.

My frontend and full-stack background is part of that, not something to replace with a new label. Interfaces, data ownership, service contracts, tests, and release behavior provide the questions against which generated output gets evaluated.

The diff at the beginning can remain plausible. I still need to know what changed, what was checked, and who owns the unresolved decision. I am comfortable letting an agent do a substantial part of the work when those answers are available. I am less comfortable calling the work complete because the explanation sounds finished.

If your agent workflow is reliable until one ordinary exception appears, tell me which assumption the exception exposed. That is usually a more useful starting point than another prompt template.

Same Container Image, Different Application

Maksym Kuzmitskyi (MaximusFT) — Thu, 08 Oct 2026 00:00:00 +0000

The image passed staging. Production starts the same digest with different environment variables.

The browser still calls the staging API.

There is no contradiction. The server received its configuration at startup. The browser bundle received its configuration earlier, during the build. "Same image" was true. "Same application, configured at runtime" was only partly true.

I like building once and promoting an immutable artifact. It removes a whole class of uncertainty about what was tested. But that promise deserves a more careful definition than "we use Docker now."

Separate the configuration clocks

There are at least three moments when configuration can become fixed:

build time, when the artifact is produced;
process startup, when the runtime initializes;
request time, when a value is consulted again.

A public frontend environment variable may be substituted into JavaScript during the build. Changing the container environment does not rewrite the compiled bytes. Next.js documents this behavior for NEXT_PUBLIC_ values; Vite's VITE_ values have a similar public-build role.

For a browser API address, I would first consider same-origin paths such as /api. The proxy selects the environment-specific backend without putting that address into the bundle.

If the browser truly needs runtime settings, publish a small, explicitly public configuration resource or inject them into the initial response. Validate it and decide its cache behavior. No secret becomes safe because the file is named runtime-config.json.

This also creates compatibility work: an old bundle may read new settings. Keep the public configuration schema additive, and record which artifact and configuration revision were deployed together.

Environment variables do not form a typed contract

The process can start with ORDER_TIMEOUT_MS=ten. It can also start with a missing variable that quietly activates a development default.

I would rather reject an invalid production configuration before the instance receives traffic:

import { z } from 'zod';

const RuntimeConfig = z.object({
  DATABASE_URL: z.string().url(),
  ORDER_TIMEOUT_MS: z.coerce.number().int().min(100).max(30_000),
  ENABLE_EXPORTS: z.enum(['true', 'false']),
});

const config = RuntimeConfig.parse(process.env);
const exportsEnabled = config.ENABLE_EXPORTS === 'true';

The values are illustrative, not recommended timeouts. Notice the boolean handling: the string 'false' is truthy in JavaScript. A generic truthiness conversion is not a configuration parser.

Errors should identify the invalid setting without dumping every environment value into logs. Validation is useful; printing a database password beside the validation failure is not.

Secret mounts solve one part of the problem

Builds sometimes need credentials to download private dependencies. Passing them through Docker build arguments or environment instructions can leave them in image metadata or layers. Deleting a file in a later layer does not remove it from the earlier layer.

BuildKit secret mounts expose a credential to one build step without intentionally baking it into the image:

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

That does not prevent the invoked tool from copying the credential into output or printing it. The mount is a delivery mechanism, not a guarantee about everything executed in that step.

Runtime secrets have a different lifecycle. An environment-injected database password usually stays unchanged in the process until it restarts. A mounted secret file may update while the application still holds the old value in memory. A secrets service can rotate credentials while existing database connections continue to work and new connections fail.

Rotation therefore includes application behavior: refresh or restart, connection-pool replacement, overlap between old and new credentials, and rollback. A secret manager can store the next password. It cannot decide when your client library rereads it.

Pin the artifact you mean to deploy

An image tag is a name. A digest identifies particular content.

If checkout:production is overwritten while deployment is in progress, instances pulling at different moments can receive different bytes under the same tag. It is possible to build safeguards around tags, but deploying a recorded digest gives the release a less ambiguous identity.

Record the source revision, image digest, configuration revision, and migration state. That is enough to explain considerably more than "version 18 is running."

Architecture matters too. A locally built image for one CPU architecture is not automatically a usable artifact on another. Multi-platform builds help, but native dependencies still need testing in the runtime actually deployed.

A container does not make local files durable

A generated invoice written into the container filesystem belongs to that instance. The next request may land elsewhere, and the next deployment may remove it entirely.

Use the local filesystem for temporary work with a known lifetime. Put durable exports, uploads, and receipts in deliberately managed storage. Return an object identifier rather than a path inside the process that happened to create the file.

The same distinction applies to caches. A local cache is useful if losing it is safe and other instances can tolerate different entries. A shared product truth should not accidentally live in whichever container first computed it.

Read-only root filesystems and non-root execution can make accidental persistence and unnecessary privileges harder. They also expose implicit assumptions in libraries that want to write temporary files. Test the constrained runtime, not just the permissive development container.

Resource limits change behavior before a process dies

CPU throttling can stretch an ordinary request past its timeout without high host CPU usage. Memory limits can kill a process while the host still has plenty of RAM. Event-loop delay may explain latency that database timing does not.

I would set concurrency and heap behavior with the container's actual limits in mind. More parallel promises are not always more throughput.

The database pool deserves particular attention. A pool of twenty connections seems modest until twelve replicas each create one. During a rolling deployment, old and new replicas overlap, and the peak connection count can be larger than the steady-state count.

We will examine that budget in the scaling article. For now, the useful habit is to treat per-process settings as quantities that multiply when the scheduler adds processes.

Do not let every replica migrate the database

Running migrations in the application's startup command is convenient for one instance. Start ten instances and you have ten potential migration runners, possibly while the old application still serves traffic.

Use a controlled release step with explicit migration ownership, lock behavior, retry policy, and compatibility gates. Database tools may provide advisory locking; that still does not make a destructive change compatible with the old deployment.

The expand/contract approach belongs to the release sequence, not merely to the SQL file.

Startup and readiness also need separate meanings. The process may be alive while warming caches or preparing required resources. Conversely, restarting every replica because one shared dependency is briefly unavailable can add more load to that dependency.

Health checks should support the failure response we want, rather than giving every unpleasant condition the same instruction: restart.

Test shutdown as carefully as startup

A container usually gets a termination signal and a finite grace period. If the process ignores the signal or an intermediate shell fails to forward it correctly, deployment ends by force-killing work.

Use a process arrangement that forwards signals. Stop accepting new work, allow in-flight requests to finish within a bound, and let queue workers acknowledge only completed jobs. Design what happens after the deadline too; the platform will not wait indefinitely because an export is nearly done.

An immutable image is useful precisely because it narrows uncertainty. It does not remove configuration, storage, or process lifecycle from the design. I would keep the artifact fixed and make those moving parts explicit enough to reproduce.

Next, a practical AWS deployment puts these decisions into a concrete infrastructure layout, without treating every available service as a requirement.

Which setting in your application changes at a different time than people assume? I'd be interested in the small configuration detail that made an otherwise sound release behave differently.

The Domain Moved. Some Requests Did Not.

Maksym Kuzmitskyi (MaximusFT) — Tue, 06 Oct 2026 00:00:00 +0000

The new domain works on your laptop. The certificate is valid. The application responds.

Someone else is still reaching the old server.

There is usually nothing particularly mysterious about this. The system has several caches, several connections, and several ideas about what "the address" means. They do not update together because we changed a record in a dashboard.

In the first part of this guide, I followed a request from the browser into the backend. Here I want to stay at the entrance, where fairly small configuration changes can leave an application working for one group of users and quietly wrong for another.

A DNS change has a transition period

Lowering a record's TTL immediately before changing its value does not shorten answers already cached under the previous TTL. A resolver that cached an hour-long answer ten minutes ago can keep it for the remaining fifty minutes.

I would lower the TTL ahead of a planned cutover, wait for the old lifetime to pass, and keep both destinations usable during the move. DNS TTL is a cache instruction, not a synchronized release mechanism.

There is another easy-to-miss cache: the absence of a record. If someone queried a hostname before it existed, their resolver may retain a negative answer. Creating the record does not necessarily make that user able to resolve it immediately.

Existing HTTP connections can also outlive a DNS update. A client does not need to resolve the name again for every request on an already-open connection.

None of this is a reason to avoid DNS cutovers. It is a reason not to delete the old destination the moment your own lookup looks correct.

Check both address families

A hostname can publish both an A record for IPv4 and an AAAA record for IPv6.

If the IPv4 route is healthy while IPv6 reaches an old endpoint, the result may depend on the user's network. Browsers have strategies for choosing between address families, but those strategies cannot turn a wrong AAAA record into the right infrastructure.

The symptom is frustratingly ordinary: "It works here."

These are diagnostic commands, not a deployment script:

dig +short A api.shop.example
dig +short AAAA api.shop.example
curl -4 -I https://api.shop.example/health
curl -6 -I https://api.shop.example/health

The last command requires a working IPv6 path from the machine running it. Failure there is evidence to interpret, not automatic proof that the server is broken.

I would also inspect the authoritative records and compare them with the resolver used by an affected client. "Propagation" is often used as a name for any uncertainty around DNS. It is more useful to identify which answer is cached where.

The certificate belongs to a connection, not a diagram

With a CDN in front of a load balancer, there may be two TLS connections: browser to CDN, and CDN to origin. Each has its own certificate validation and hostname expectations.

A valid browser-facing certificate says nothing about whether the CDN can validate the origin certificate. The origin address, TLS server name, certificate names, and HTTP Host header have related but distinct jobs.

Suppose the origin certificate covers origin.shop.example, while the CDN connects using a load balancer's generated hostname. Depending on the configured origin behavior, verification can fail before the application sees a request.

I would debug the two connections separately rather than temporarily disable origin verification. The latter makes the immediate error disappear by removing the property we were trying to establish.

Renewal is the configuration test that arrives later

A certificate issued successfully today still needs an automated renewal path.

An HTTP-01 challenge requires the validation resource to be reachable through the public route. Add authentication, a new redirect, or a different proxy rule later, and renewal may fail while ordinary application requests continue working.

DNS-01 avoids that HTTP path and supports wildcard certificates, but introduces credentials and DNS update behavior into the renewal system. Give the renewal process narrowly scoped access rather than the registrar's unrestricted credentials. Challenge delegation can help separate that responsibility.

The Let's Encrypt challenge documentation explains these trade-offs. A wildcard for *.shop.example also does not cover the apex shop.example; certificate names deserve the same explicit review as routing rules.

I would monitor expiry from outside the application and exercise renewal before the certificate becomes urgent. A calendar reminder is not quite the automation people usually mean when they say HTTPS is handled.

The proxy changes what the application believes

Behind TLS termination, the application may receive plain HTTP from the load balancer. Without trusted forwarding information, it can generate HTTP callback URLs, fail to set secure cookies, or redirect a request that is already HTTPS into a loop.

Forwarded protocol, host, and client-address headers provide that context. They are not trustworthy merely because they have conventional names.

An internet client can supply X-Forwarded-For too. The proxy must remove or normalize incoming values according to the topology, and the application must trust only the known proxy path. Blindly trusting every hop makes client-IP rate limits and audit records easier to mislead.

For password-reset and OAuth URLs, I prefer a configured, validated public origin rather than constructing an absolute URL from an arbitrary Host header. It is less flexible. That is sometimes the point.

Public address, transport address, and trusted request context are separate configuration decisions.

Moving the hostname can change authentication

A host-only cookie for shop.example is not sent to api.shop.example. A cookie scoped to the parent domain has a broader reach, which can be undesirable if another subdomain is less trusted.

Also, two subdomains can be same-site while still being different origins. SameSite cookie rules and CORS answer different questions. Cross-origin browser requests still need the right credential mode and CORS response; a credentialed response cannot use a wildcard allowed origin.

The distinction becomes visible after a seemingly harmless move from /api on the main origin to a separate API hostname. Authentication, preflight requests, callback allowlists, and browser storage behavior may all change.

I would test an existing session, not just a fresh login. I would test logout too. Deleting a cookie with the wrong path or domain can leave the original cookie present, which is a fairly unhelpful way to discover how cookie scope works.

Preserve request semantics through redirects

A canonical-domain redirect is fine for a public page. Applying the same rule indiscriminately to API writes is less comfortable.

Some redirect statuses can lead clients to change a POST into a GET. Others preserve the method and body. Even a method-preserving redirect can encounter credential and origin rules that an ordinary page navigation does not.

For a moved API, I would keep the old route compatible during the transition rather than expect every client to follow a redirect correctly. The client might be a browser tab, an SDK, or a webhook sender that cannot be upgraded today.

Permanent redirects can be cached too. A rollback of DNS or application code does not necessarily rewind the redirect already stored by a client.

Test an address change as a release

A useful cutover check includes more than a homepage returning 200: authenticated reads, writes, OAuth callbacks, uploads, streaming responses, certificate renewal, and the old endpoint during overlap.

Proxy buffering is worth checking if the application streams. A server can emit chunks correctly while a proxy collects them and sends everything at the end. The request technically works; the intended latency behavior does not.

I would keep the old endpoint alive until observed traffic has moved, then remove it deliberately. The decision comes from request logs and compatibility requirements, not the moment the DNS control panel says the record was saved.

The domain is a small part of the application, but it has a long memory. Caches, cookies, certificates, and old clients all remember slightly different versions of it. A good move gives those memories time to become harmless.

Next comes container and environment configuration, where the application can have the right address and still be running the wrong settings.

If a domain move left one awkward client behind, I'd be interested in which layer retained the old assumption. Those details are more useful than another checklist that stops at a green padlock.