DEV Community: Paulo Victor Leite Lima Gomes

agent trust is a runtime problem

Paulo Victor Leite Lima Gomes — Tue, 21 Jul 2026 00:05:00 +0000

There is a sentence the industry keeps trying very hard to believe:

"We can make agents safe with better instructions."

I understand why. Instructions are cheap. Policies are familiar. A system prompt feels like a place where serious adults can write serious words like "never" and "must" and "only with approval." Then the agent reads a README from the internet, installs a package, opens a browser, calls an MCP server, touches a repository, and suddenly the serious words are trying to govern a live workflow with the authority of a sticky note.

This is why Docker's recent AI Engineer World's Fair write-up caught my attention. The headline is about agent trust, but the useful part is less dramatic: harden what agents build on, isolate where they run, control what they can reach, and govern the whole thing from one place.

That is platform engineering wearing a new jacket and pretending it just arrived.

Good. We have spent the last decade learning that useful software needs boring boundaries. Containers needed image policy, network policy, registries, scanners, signed artifacts, secrets management, and audit logs.

Agents deserve the same disrespect.

the agent does not need to be evil

The easy security story is that an agent might run a destructive command.

That is real, but it is also the cartoon version.

The more common risk is quieter. The agent reads too much. It connects dots that were never meant to be connected. It copies context from a private repository into a public tool call. It installs a dependency that opens a new network path. It calls an unreviewed MCP server because the server description sounded helpful and the afternoon was already long.

No villain required.

This is the annoying thing about useful agents: usefulness comes from access. A coding agent that cannot read files, run tests, inspect errors, install dependencies, call documentation tools, use a browser, or open a pull request is basically autocomplete with confidence issues.

So the question is not "should agents have access?"

The question is "where is that access mediated?"

If the answer is "in the prompt", we are being optimistic in the same way a team is optimistic when production credentials live in a wiki page titled "please rotate this soon."

prompts shape intent, runtimes enforce reality

Prompts matter. I am not joining the club of people who pretend instructions are useless because that sounds sophisticated. A clear instruction can improve behavior. A good system prompt can define task scope, escalation rules, and expectations.

But prompts shape probabilities.

Runtimes enforce boundaries.

That difference matters.

A prompt can say "do not access the network except for documentation." A runtime can actually block network destinations that are not allowed. A prompt can say "do not write outside the repository." A sandbox can mount the repository read-write and everything else read-only or not at all. A prompt can say "only use approved tools." A gateway can reject unapproved MCP calls before they happen.

This is why runtime governance research feels directionally right. One recent paper argues that agent behavior is path-dependent: the risk depends not only on one action, but on the sequence of actions that led there. Static access control catches some cases. Prompt rules catch some behavior. But once an agent is acting through tools, the execution path itself becomes the thing you need to observe and govern.

That sounds academic until you watch a real agent work.

It reads an issue. Searches the repo. Opens docs. Installs a package. Runs a test. Follows an error to a blog post. Copies an example. Edits code. Runs another command. Tries a browser route. Opens a PR.

Each step might be defensible alone.

The sequence might be a problem.

mcp made the tool layer everybody's problem

The Model Context Protocol is useful because it gives agents a common way to call tools. It is also dangerous for exactly the same reason.

Once tool access becomes portable, tool governance becomes unavoidable.

An MCP server is not just a plugin. It can be a route into databases, ticket systems, cloud APIs, internal docs, messaging tools, browsers, build systems, and customer-shaped data. If developers can add these servers faster than security or platform teams can review them, congratulations, you have reinvented browser extensions with production credentials.

Docker's governance page talks about central control for sandbox, network, and MCP access, with policy events exported to SIEM and compliance systems. The product details will change, and other vendors will build their own versions, but the shape is what matters.

Agent tooling needs an allowlist. It needs ownership. It needs review. It needs audit. It needs default-deny for things that can touch sensitive systems.

Not because developers are irresponsible.

Because serious tools need serious boundaries.

the laptop is not outside the platform

One subtle point in the Docker argument is that a lot of agent work starts on the developer laptop.

That sounds obvious, but many enterprise security conversations still behave as if the real platform begins in CI or the cloud. The laptop is treated as a messy prelude. The official system starts later, after the pull request, after the build, after the deployment pipeline wakes up and puts on a badge.

Agents make that mental model weaker.

If an agent can read a repository, run local tools, call network services, use a browser, and interact with MCP servers before code ever reaches CI, then the developer machine is already an execution environment for semi-autonomous work.

It means the agent runtime on the laptop belongs in the platform inventory.

Which agents are allowed? Which sandboxes do they use? Which directories can they mount? Which network paths can they reach? Which MCP servers are approved? Which credentials can enter the session? What gets logged? What is retained? What can a reviewer see after the agent opens a pull request?

These are not exotic AI questions.

They are old platform questions with a faster actor.

autonomy without evidence is just vibes at scale

The best version of agent autonomy is not "the agent did something and we hope it was fine."

The best version is "the agent did something inside a bounded runtime, using approved tools, with visible inputs and outputs, and left behind enough evidence for a human to review the work."

That evidence should not only be the code diff.

The diff tells you what changed. It does not tell you whether the agent read files it should not have read, called an unapproved tool, installed a sketchy package, copied from a questionable source, or hit a network endpoint nobody expected.

For agent-generated work, the provenance around the work starts to matter more.

Where did it run? What image or environment was used? What tools were available? Which commands executed? Which domains were reached? Which files were mounted? Which secrets were exposed? Which policy checks passed? Which ones warned? Which ones blocked?

We already learned this lesson in supply chain security. The artifact is not enough. You eventually want to know what built it, from which inputs, under which policy, with which attestations.

Agents are now part of that build story.

the punchline

Agent trust will not come from one magic layer.

Better models help. Better prompts help. Better reviews help. But the durable trust boundary is going to live in the runtime and the tool path: sandboxes, network controls, filesystem mounts, MCP governance, credential scoping, audit events, and reviewable evidence.

This is not the glamorous side of AI.

Good.

The glamorous side is where demos live. The boring side is where production survives.

The practical rule is simple: if an agent can act like a developer, operate it like a developer environment. Give it useful access, but make that access explicit. Let it move fast, but inside a boundary. Let it call tools, but only the tools the organization is willing to defend.

Do not ask the prompt to do the runtime's job.

The prompt can say "be careful."

The runtime can make careful the default.

That is where trust starts to become real.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

public registries are not your supply-chain strategy

Paulo Victor Leite Lima Gomes — Mon, 20 Jul 2026 00:05:25 +0000

AWS warned that Bitnami images were leaving Amazon ECR Public.

Not a vulnerability with a scary logo.

Not a zero-day.

Not a dramatic cloud outage with a dashboard slowly turning red.

Just a registry change.

And that is exactly why it matters.

Starting June 10, 2026, Bitnami container images are no longer available from Amazon ECR Public Gallery. AWS said Bitnami had 317 container image repositories there, and any pull from public.ecr.aws/bitnami/ would fail after the removal. They even scheduled a 24-hour brownout on June 1 for the top 20 repositories so teams could notice the dependency before it became permanent.

That is a very practical, very boring kind of supply-chain incident.

The kind that does not need an attacker.

the container still running is not the problem

The part that tricks people is that running containers do not immediately explode when a registry changes.

If the image is already on the node, the process keeps running. The service looks fine. The dashboard is green. Everyone goes back to arguing about roadmap priorities.

Then something normal happens.

A pod restarts. An ECS task is replaced. A node gets recycled. The deployment rolls. CI builds a new artifact. Autoscaling adds capacity. Someone runs a disaster-recovery test. The image has to be pulled again.

And now your application is not really failing because of Kubernetes, ECS, Helm, Terraform, or your app code.

It is failing because a public shelf you treated like infrastructure stopped being your shelf.

That is the uncomfortable lesson here. Container availability is not only about your cluster. It is also about every registry, namespace, tag, mirror, chart, and pipeline reference that sits between source code and a running workload.

public images are still dependencies

We have a weird habit in engineering.

If a dependency is in package.json, we admit it is a dependency.

If it is in a base image, a Helm value, a Dockerfile, a CI action, or an old Terraform module, we often treat it like background weather.

It is not weather.

It is a dependency.

public.ecr.aws/bitnami/postgresql:15 is a dependency. So is bitnami/redis. So is the chart value that pulls it indirectly. So is the build image used by the pipeline that nobody has edited since the migration from Jenkins.

The reason this registry change is interesting is that it exposes how much of production still depends on informal distribution assumptions.

Somebody else hosts it.

Somebody else publishes it.

Somebody else keeps the namespace alive.

Somebody else decides when the business model changes.

That may be completely reasonable for a hobby project. For production, it needs to be a conscious decision, not an accident left behind by a copy-pasted tutorial.

mirroring is mitigation, not ownership

AWS gave the right immediate advice: find references to public.ecr.aws/bitnami/, mirror the images you need into your own private ECR registry, and update deployments to point at your registry.

Good.

Do that.

But do not confuse mirroring with solving the whole problem.

A mirror protects you from the immediate pull failure. It gives you a copy. It lets scaling, redeployments, and node replacement keep working after the upstream location disappears.

That is necessary.

It is not enough.

Once you mirror an image, you own a new question: who keeps it patched?

If the upstream source stops publishing to the place you used, your private copy can easily become a fossil with a nice AWS account ID in front of it. It will keep pulling. It may even make everyone feel safer. Meanwhile, the real update path is gone or moved somewhere else.

This is where teams get into trouble. They treat the mirror as a backup, but it slowly becomes the actual source of truth without the maintenance process that source of truth deserves.

A private registry is not a magic freezer where images stay safe forever.

It is inventory.

Inventory needs owners.

tags are not a recovery plan

The next trap is tag behavior.

A lot of teams still deploy images using loose tags because it is convenient. latest, minor-only tags, mutable chart defaults, whatever the tutorial suggested.

This is already risky when the registry is healthy.

During a removal event, it gets worse.

What exactly did you mirror? The tag name? The digest? The architecture variants? The chart dependency? The image used by the init container? The one in the backup job? The one in the dev namespace that production secretly depends on because environments are never as clean as diagrams?

If you cannot answer those questions, you do not have a supply-chain strategy.

You have hope with YAML.

The better practice is boring and slightly annoying:

inventory image references across repos, charts, task definitions, Dockerfiles, and CI
record the digests you actually run
mirror the specific tags and digests needed for production
update deployment config to your owned registry
make future image updates an explicit workflow
alert on direct pulls from public registries in production paths

That is not glamorous work. It is the work that prevents "why did the cluster stop scaling?" from becoming a registry archaeology exercise at 2 AM.

helm makes this easier to miss

Helm charts are a very common place for this problem to hide.

The application team installs a chart. The chart has image defaults. Maybe the defaults point to Bitnami. Maybe an environment override changes one image but not another. Maybe the chart pulls a sidecar or init container nobody remembers.

Six months later, the platform team asks, "Are we using public.ecr.aws/bitnami/ anywhere?"

Everyone searches the obvious repository and says no.

Then the brownout happens and a namespace quietly proves otherwise.

This is why registry policy cannot live only in human memory. The cluster should help. Admission control can reject unapproved registries. Image policy controllers can require known prefixes. CI can scan manifests before merge. SBOM and inventory tooling can tell you what is actually running, not only what the repo claims should be running.

None of that is perfect.

Perfect is not the point.

The point is to make hidden image dependencies boring enough to find before an upstream announcement finds them for you.

the platform team owns the paved path

This is not me saying every product team should become a container-registry specialist.

That is how you create twenty-seven slightly different solutions and one shared incident.

The platform team should provide the paved path:

approved base images
private registry namespaces
mirroring and promotion workflows
image signing and scanning
digest pinning guidance
pull-through cache rules where they actually fit
alerts for public registry usage in production
a clear exception process for teams that really need an external image

Then product teams can make real choices without memorizing every registry failure mode.

The key is to separate convenience from ownership.

It is fine to use public images. The ecosystem depends on that. The mistake is pretending public distribution is the same thing as production ownership.

Those are different things.

this is bigger than bitnami

Bitnami is just the visible example this week.

The broader pattern is older and much larger. Free tiers change. Public registries rate-limit. Namespaces move. Vendors retire channels. Images get renamed. Tags are deleted. Maintainers burn out. Companies acquire companies. Licensing changes. Security teams block a source. A registry outage happens on the day you need to replace nodes.

None of this is exotic.

It is normal software supply chain life.

Containers made packaging feel clean, but they did not remove the ownership problem. They just moved it into OCI layers, registry namespaces, tags, digests, chart defaults, cache behavior, and deployment controllers.

That is still better than the old world in many ways.

But better packaging does not mean free operational responsibility.

what i would do this week

If I owned a platform with Kubernetes or ECS workloads, I would not start with a heroic migration spreadsheet.

I would start with one sharp query:

Where do we reference public.ecr.aws/bitnami/?

Search repos. Search Helm values. Search Terraform and CloudFormation. Search task definitions. Search running workloads. Search CI.

Then I would split the results:

production workloads that must be mirrored immediately
build and CI images that can break releases
development-only images that need a replacement but not a panic
unused references that should be deleted

After that, I would mirror only what is actually needed, by digest where possible, and create a follow-up owner for the long-term migration path.

The important part is not only surviving June 10.

The important part is learning whether the organization can answer this kind of question quickly.

If it cannot, Bitnami is not the problem.

Visibility is the problem.

the punchline

The Bitnami removal from ECR Public is not dramatic because AWS gave notice, documented the impact, and described mitigation steps.

That is good.

But it is still a supply-chain fire drill.

It shows how easily a production system can depend on public image distribution without anyone treating that dependency as owned infrastructure.

Running containers are not enough. Cached images are not enough. A private mirror is not enough if nobody owns updates. A green dashboard is not enough if the next scale-out event cannot pull the image.

Public registries are useful.

They are not your supply-chain strategy.

Your strategy is the boring stuff around them: inventory, mirrors, digests, policy, owners, patch paths, and proof that the cluster is not quietly depending on someone else's shelf.

That is less exciting than another AI platform announcement.

It is also the kind of work that keeps production boring.

And boring production is still one of the best products engineering can ship.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

hardened images are becoming the default base layer

Paulo Victor Leite Lima Gomes — Sun, 19 Jul 2026 00:08:22 +0000

There is a line in almost every service that gets less respect than it deserves.

FROM something:latest

Or, if the team is feeling mature:

FROM something@sha256:...

That line looks small. It feels like setup. It sits above the "real" application code, so people treat it like the opening credits before the movie starts.

But the base image is not decoration.

It is inherited production infrastructure.

It brings an operating system shape, packages, libraries, certificates, shell behavior, update cadence, CVE noise, provenance, and sometimes a small museum of things your application never asked for. Then your team spends the next few years pretending the scanner is being dramatic.

Docker's push around Docker Hardened Images is interesting because it points at a better default. Not a perfect default. Please, we are still in software. But a better one: secure, minimal, transparent base images that are meant to be ordinary starting points, not elite artifacts hidden behind a compliance ceremony.

That is the useful part.

The best container security feature is not another dashboard yelling at developers.

It is making the thing developers already use less embarrassing by default.

the base image is a dependency stream

We talk about dependencies as if they mostly live in package.json, go.mod, requirements.txt, or a lockfile that nobody wants to review because it looks like a phone book fell into Git.

But a base image is also a dependency.

Worse, it is a dependency stream.

You do not choose python, node, nginx, postgres, or debian once and move on with your life. You inherit a flow of patches, rebuilds, tags, digests, package metadata, vulnerability disclosures, upstream decisions, and compatibility tradeoffs.

That stream becomes part of every service built on top of it.

If the base image carries unnecessary packages, every one can become a scanner finding. If it ships with a shell the workload does not need, that shell becomes part of the runtime surface. If the maintainer cadence is slow, your application teams become the people waiting with a red dashboard and a product manager asking why checkout work is blocked by libwhatever.

Very normal. Very relaxing.

This is why hardened images are not just "smaller images."

Smaller helps. Fewer packages mean fewer things to patch, fewer things to exploit, fewer things to explain to auditors, and fewer false alarms during the morning coffee ritual.

But the bigger value is ownership.

Someone is saying: this foundation has a maintenance model, an SBOM, provenance, signing, vulnerability policy, and a migration path. You can build on it without each application team inventing container supply-chain engineering from first principles.

That matters because most product teams should not be in the business of maintaining Linux distributions accidentally.

secure by default is not the same as secure by lecture

Security programs love education.

Sometimes that is good. Developers should understand the systems they ship. They should know what a base image is, why digest pinning matters, why curl | sh is a cry for help, and why "but it works locally" is not a threat model.

But education alone is a weak control.

If the safe path requires every team to remember ten practices, choose between fifteen image variants, configure scanning, interpret SBOMs, and manually chase upstream patches, many teams will drift.

Not because they are lazy.

Because they are busy.

Because the product still needs to ship. Because the incident from yesterday is still warm. Because the person who understood the old image moved teams and left behind one comment saying "do not upgrade this, breaks prod."

Secure defaults reduce the number of heroic choices a developer must make before doing normal work.

This is the part of Docker Hardened Images that I like. The pitch is not only "here is a security product." It is "what if the better base layer was the default thing developers could reach for?"

That is how platform work should feel: a paved path with fewer traps.

minimal does not mean magical

There is a bad version of the hardened-image conversation where everyone starts speaking as if switching the FROM line deletes risk.

It does not.

You can run bad application code on a hardened image. You can leak secrets from a minimal container. You can misconfigure Kubernetes, expose admin endpoints, ship vulnerable app dependencies, and create an incident with an image that looks beautiful in the scanner.

Hardened images lower some kinds of risk.

They do not absolve the rest of the system.

Engineers are allergic to silver bullets for good reasons. We have seen too many products arrive with "just use this" energy. Then the migration breaks native libraries, the team adds half the packages back, and six months later the "minimal" image has bash, curl, vim, and an emotional support package manager.

The useful hardened-image rollout is honest about this.

Some workloads will migrate easily. Some will need compatibility work. Some will discover they were relying on tools that should never have been in the runtime image.

If production requires a debugging shell, ask why. If the app needs a build tool at runtime, ask why. If the container includes utilities only used by one emergency script, ask whether that script is now the architecture.

Minimal images force those conversations.

Usually at an inconvenient time, because containers enjoy comedy.

platform teams should own the foundation

The wrong rollout is a Slack message: "Everyone please migrate to hardened images by end of quarter."

This produces predictable results. One team does it well. One team copies the first team badly. One team asks which image to use. One team says their legacy service cannot move. One team silently ignores the message because the scanner has been red since before the current manager joined.

The better rollout treats base images as a platform contract.

Give teams approved image families. Publish migration examples. Provide scanners that understand the image metadata. Make SBOMs and provenance easy to inspect. Define ownership for base image updates separately from application dependency updates. Track adoption by service. Make exceptions visible.

Also, please test the images against real internal workloads.

The demo service is always polite. It has no weird native dependency, no timezone sadness, no ancient certificate chain, and no business logic hiding in final-run.sh.

If a platform team can make the hardened image path boring enough, product teams will use it. If the path is confusing, teams will keep using whatever worked last year.

They will not be entirely wrong.

this is also an ai infrastructure story

There is an AI angle here, because of course there is. But this one is real.

Agentic systems multiply runtime surfaces. They run tool servers, execute code, browse, test, and connect to databases, SaaS APIs, internal dashboards, and all the strange little utilities that make a company function.

Those workloads still start from images. If the agent runtime, tool server, browser worker, model sidecar, or evaluation job starts from a sloppy base layer, the AI magic is standing on the same old supply-chain mud.

The lesson is boring and useful: AI infrastructure does not escape container hygiene. It makes container hygiene more important because semi-autonomous processes touch sensitive systems.

If an agent can act, the runtime foundation matters.

the punchline

Hardened images are not exciting in the way a new model release is exciting.

Good.

Exciting is overrated in infrastructure. A lot of production maturity is replacing chaotic defaults with boring ones that survive teams, audits, incidents, and budgets.

The base image is one of those defaults: the first layer of application security, the first inherited dependency, the first thing scanners will judge, and the first place many teams accidentally import more operating system than they need.

So yes, making hardened images easier to adopt is a big deal. Not because every developer should become a supply-chain specialist. Because they should not have to.

Developers still need to understand what they are shipping. Platform teams still need evidence, migration paths, exception handling, and update discipline. Security teams still need to distinguish real risk from dashboard noise.

But the default base layer should be less silly.

That is the whole point.

The best security platform work is not the work that makes everyone feel watched.

It is the work that makes the ordinary path safer before anyone has to remember a checklist.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

agentic autofix needs evidence, not applause

Paulo Victor Leite Lima Gomes — Sat, 18 Jul 2026 00:03:57 +0000

GitHub put agentic autofix for code scanning alerts into public preview this month, and it is exactly the kind of feature that sounds small until you imagine it touching a real backlog.

Code scanning used to give you an alert.

Now the tool wants to explore the repository, work across files, propose a fix, rerun the original analysis, and open a pull request.

That is not just "faster remediation."

That is AppSec crossing from detection into change management.

I like this direction, with the usual amount of fear in my eyes.

Security teams have lived for years with the world's least romantic queue: findings, duplicates, false positives, stale alerts, "we will fix it next sprint", and the immortal ticket assigned to someone who left the company in 2023.

So yes, a tool that can turn a code scanning alert into a reviewable pull request is useful. Very useful.

But the interesting part is not that Copilot can write a patch.

The interesting part is that the scarce skill moves.

Before, the scarce skill was often "can we understand and prioritize the alert?"

After agentic autofix, the scarce skill becomes "can we trust this remediation enough to merge it?"

That is a different job.

the alert was annoying, but at least it was honest

A static analysis alert is irritating in a very simple way. It says: "I found a pattern that may be dangerous."

Sometimes it is right. Sometimes it is nonsense. Sometimes it is technically right and operationally useless, which is the AppSec version of being stuck in a meeting with a spreadsheet.

But an alert has a clean boundary. It points at a potential problem.

A generated fix has a bigger blast radius.

It can change control flow. It can move validation. It can add escaping in the wrong layer. It can silence the scanner without fixing the actual vulnerability. It can make a test pass while changing behavior that was never tested because the legacy system was held together with vibes and one senior engineer's memory.

This is not an argument against autofix.

It is an argument against treating generated remediation as a magical cleanup button.

Security fixes are not only code changes. They are claims about risk.

If the tool opens a PR, the PR should carry those claims clearly.

generated security prs need evidence bundles

The mature version of agentic autofix is not "here is a diff, good luck."

The mature version is an evidence bundle.

A good security autofix PR should answer boring questions in plain language:

What vulnerability class was detected?
What input or state made it exploitable?
What files and data paths did the agent inspect?
Why is this remediation scoped to these changes?
Which analysis was rerun?
Which tests were added or updated?
What behavior might still be risky?
What did the agent not verify?

That sounds like paperwork.

It is.

Security is partly paperwork because humans need to build trust across teams that do not share the same context. The application team knows the weird code path. The security team knows the vulnerability class. The platform team knows how scanning is wired. The reviewer knows the change may wake them up later.

A generated PR has to be legible to all of them.

Without the evidence, the reviewer has to reverse engineer the agent's reasoning from the diff. That is not automation. That is outsourcing the confusing part to a human with less time.

Congratulations, we made the queue shorter and the review harder.

Very modern.

rerunning the scanner is necessary, not sufficient

GitHub says agentic autofix reruns the original analysis to confirm the alert closes before opening the pull request.

That is good.

It is also the floor.

Closing the original alert proves the scanner no longer sees the same shape. It does not prove the system is secure. It does not prove the fix belongs at the right abstraction layer. It does not prove the change handles adjacent inputs. It does not prove the application still behaves correctly.

This is where teams get into trouble with any automated remediation tool.

The machine optimizes for the detectable condition. The product carries the real-world behavior.

Imagine a SQL injection alert. A bad fix can parameterize one query and leave the actual untrusted path open somewhere else. A worse fix can escape strings manually because it makes the pattern disappear. A very cursed fix can add validation that blocks valid customer data because nobody wrote a test for the angry customer with a quote in their surname.

The scanner is a useful witness.

It is not the judge.

For serious vulnerabilities, I want a small test that fails before and passes after. I want the changed boundary explained. I want the agent to say whether it found similar patterns elsewhere. I want the reviewer to see what was intentionally left alone.

This is normal engineering discipline.

The only new part is that the first draft came from a tool.

appsec becomes review design

Agentic autofix will probably make some security programs look better in dashboards.

Fewer open alerts. Faster mean time to remediation. More security PRs created. A cleaner executive chart. Everybody loves a chart until it asks for nuance.

But the real metric is not how many alerts got patched.

The real metric is how many risky changes were safely understood, reviewed, merged, and kept healthy afterward.

That means AppSec has to care about review.

What should an autofix PR look like? Who is allowed to trigger one? Should high-risk fixes require security review plus code owner review? Should the agent be allowed to edit tests? Should it touch authentication code? Should it change dependencies? Should it open one PR per finding or group related findings in a campaign?

These questions sound procedural because they are.

That is where production safety lives.

The same feature can be excellent in one organization and chaos in another. A team with clear ownership, good tests, and reviewers who understand the affected code can absorb generated security PRs. A team with weak tests, overloaded reviewers, and twenty services nobody owns will just create a more efficient machine for generating false confidence.

Automation does not remove ownership.

It finds out whether ownership was real.

security review is moving left and sideways

GitHub also added security reviews in the Copilot app through a slash command for in-flight code changes.

That pairs nicely with agentic autofix. One feature tries to fix known alerts. The other tries to catch high-confidence issues while code is still being written.

This is the part I find useful: security is getting closer to the work loop.

Not in the old "shift left" slogan way, where everyone repeats the phrase until the developer inherits six more tools and a guilt dashboard.

I mean literally closer to the work loop.

The IDE, CLI, code scanning alerts, pull requests, and review comments are starting to become one security surface. That is powerful because context is nearby. The diff is fresh. The author still remembers what they were doing. The fix can land before the finding becomes a fossil.

But it also means security automation is entering the same messy place where normal software decisions happen.

Half-written code. Experimental branches. Weird mocks. Deleted tests. Local assumptions. Deadlines.

So the tooling has to be humble.

It should say what it knows, what it checked, and what it did not check. It should preserve context for humans instead of pretending the human is just a merge button with a salary.

the punchline

Agentic autofix is a good feature because security teams need help with remediation, not just alert production.

But the useful future is not a robot silently cleaning the backlog while everyone applauds.

The useful future is generated remediation with evidence: clear scope, tests, analysis results, affected paths, remaining uncertainty, and ownership.

If a tool can open a security PR, it should also help the reviewer understand why the PR is safe to merge.

Otherwise we are not reducing risk.

We are just converting security alerts into code review debt with better branding.

And honestly, we already had enough debt. It came with free dashboards.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

custom metrics are the real autoscaling contract

Paulo Victor Leite Lima Gomes — Fri, 17 Jul 2026 00:04:40 +0000

Kubernetes has a very simple lie that everyone enjoys for a while:

CPU and memory tell you when to scale.

This is a useful lie. It gets teams started. It makes demos easy. It gives the HorizontalPodAutoscaler something obvious to watch. CPU goes up, replicas go up, everyone nods, the dashboard looks serious.

Then production arrives wearing dirty shoes.

The queue is saturated while CPU is bored. The payment provider is slow but your pods look healthy. The batch job is falling behind because one tenant sent a weird workload. The API is green, but the thing the customer actually cares about is waiting in a backlog somewhere.

Congratulations. You have discovered that autoscaling is not about resources.

Autoscaling is about pressure.

That is why the recent Kubernetes post about building a custom metrics exporter is more interesting than it looks. On the surface, it is a practical walkthrough: expose an application-specific metric, wire it through the custom metrics API, let the HPA consume it.

Fine. Useful.

But the bigger story is that Kubernetes is quietly telling teams something important: if CPU and memory are the only signals your platform exposes, your platform understands the wrong bottlenecks.

cpu is a symptom, not a business signal

CPU is not useless. Please do not turn this into another "metrics are fake" LinkedIn sermon. CPU matters. Memory matters. Saturation matters. If your service is burning cores like a crypto miner in a basement, the autoscaler should probably notice.

But CPU is usually an implementation symptom, not the user-facing problem.

A worker pool can be overloaded because queue depth is growing, even if every worker spends half its time blocked on a downstream API. A payment service can need more capacity because authorization latency is increasing, not because Go suddenly became CPU hungry. An inference service can need smarter routing because time-to-first-token and token throughput are drifting, not because average CPU crossed a nice round number.

This is where custom metrics become the real contract.

Not "scale when the pod is hot."

"Scale when the system is failing to absorb work."

Those are different sentences.

The first sentence belongs to infrastructure. The second belongs to the product.

And this is where things get uncomfortable, because platform teams cannot invent the right metrics alone. They can provide the plumbing, adapters, exporters, Prometheus integration, guardrails, naming rules, and examples. But they cannot know that checkout_pending_authorizations matters more than container_cpu_usage_seconds_total on Black Friday.

The application team has to bring domain knowledge.

The platform has to make that knowledge operational.

That is the contract.

custom metrics make ownership visible

I like custom metrics because they force a conversation that teams often avoid.

What does pressure mean for this system?

Not in general. Not in a diagram. In this service.

For a queue worker, pressure might be backlog age. For a fraud system, it might be decisions waiting longer than an SLA. For an AI gateway, it might be tokens per second, cache hit rate, provider throttle responses, or cost per successful answer. For a data pipeline, it might be lag behind the source. For a customer-facing API, it might be request latency split by tenant or endpoint.

Once that metric is used for autoscaling, it stops being decorative observability.

It becomes a control input.

That changes the seriousness of the metric. A dashboard panel can be wrong for months and survive because humans are very good at ignoring dashboards. A scaling metric that is wrong will spend money, hide incidents, create replica storms, or keep the system underprovisioned while everyone wonders why the HPA is "not working."

Very often the HPA is working exactly as configured.

The configuration is just measuring the wrong reality.

This is why custom metrics need ownership attached to them. Who defines the metric? Who validates it? Who changes thresholds? Who knows whether a spike means demand, a bug, abuse, a downstream outage, or a bad release?

If nobody owns those answers, the autoscaler becomes a very confident random number amplifier.

the adapter is plumbing; the metric is design

The Kubernetes mechanics matter.

You need a custom metrics API adapter, labels that match Kubernetes objects, sane cardinality, scraping, permissions, and failure behavior.

All of that matters.

But the hardest part is deciding which signal deserves to affect capacity.

That is design.

A bad custom metric can be worse than no custom metric. If you scale workers based on queue length alone, you may create a thundering herd against a downstream dependency. If you scale an inference service based only on request count, you ignore prompt length, cache behavior, model selection, and provider throttling. If you scale a batch system on average lag, one large tenant can hide many small tenants having a terrible day.

So the mature pattern is not "add custom metrics everywhere."

The mature pattern is to treat scaling signals like APIs.

Name them carefully. Document what they mean. Keep cardinality boring. Test them during load. Define what happens when they are missing. Review threshold changes like code.

Annoying, yes. Still cheaper than learning during an incident that your autoscaler has been scaling on a metric nobody trusts.

platform teams should ship metric paths, not magic

The platform team response should not be: "every service team, please become a metrics adapter expert by Friday."

That is how you get twelve half-working exporters, three naming conventions, and one service that accidentally exposes customer IDs as metric labels because someone copied a tutorial at 1 AM.

The better platform move is paved paths: safe exporter templates, a blessed custom metrics adapter, common examples, cardinality review, and clear ownership.

But do not pretend the platform can decide every threshold.

The useful division of labor is simple: platform owns the measurement path, service teams own the meaning of the signal, SRE owns the failure modes, and finance eventually asks why the graph looks like a staircase made of money.

That last one is not a joke. Autoscaling is spending automation. Every scaling decision is also a cost decision.

If a queue gets deep, should we scale to zero lag no matter the price?

Maybe.

Maybe not.

That is a product decision wearing Kubernetes clothes.

the ai angle makes this louder

AI workloads make this louder.

CPU and memory are comically incomplete for model-serving and agent systems. A model server can look "fine" while users wait too long for first token. An agent workflow can saturate a tool API, a browser pool, a vector database, or a code review queue. A gateway can burn money because requests are routed without understanding cache locality or token volume.

The pressure signal might be latency, tokens, queue age, tool-call failures, provider quota, cache misses, or cost per task.

None of those fit neatly into the old "average CPU utilization" mental model.

This is why custom metrics are going to become less optional. As Kubernetes absorbs more AI, batch, serverless, and specialized workloads, generic resource pressure becomes only the first layer.

Not magical autonomous infrastructure.

Just honest feedback loops.

The boring kind. The useful kind.

the punchline

A custom metrics exporter sounds like plumbing because it is plumbing.

But plumbing is often where the architecture tells the truth.

CPU and memory are easy to measure, but they are not always what the system is actually constrained by. Serious production systems care about backlog, latency, tenant pressure, provider limits, model throughput, payment failures, retry storms, cost, and work that is aging in a queue while the pod looks relaxed.

When you connect those signals to autoscaling, you are not just adding a metric.

You are declaring what pressure means.

That declaration deserves engineering discipline. Ownership. Tests. Documentation. Review. Failure behavior. Cost awareness.

The Kubernetes custom metrics path is useful because it lets platform teams move beyond generic resource watching. But the important question is not "can we expose this metric?"

The important question is:

"Do we trust this signal enough to let it move production?"

If the answer is yes, make it boring, visible, and owned.

If the answer is no, maybe keep it on the dashboard until it grows up.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

the kubernetes api server is part of your network policy now

Paulo Victor Leite Lima Gomes — Thu, 16 Jul 2026 00:04:48 +0000

AWS announced a small-looking Amazon EKS feature in June that says a lot about where Kubernetes operations are going.

Customer-routed control plane egress.

I know. The name sounds like a feature flag generated by a committee that was not allowed to leave the room until everyone had inserted one noun.

But the idea is useful: EKS can now route customer-controllable Kubernetes API server outbound traffic through your own VPC. Admission webhook callbacks, OIDC provider lookups, aggregate API server requests, and the DNS resolution for those calls can leave through an ENI in your network instead of only through the EKS-managed control plane path.

In less AWS-language:

The API server makes outbound calls.

Those calls matter.

And now you can treat some of them like real network traffic instead of mystical cloud weather.

the api server was never just a thing you call

Most engineers learn the Kubernetes API server as the thing clients talk to.

kubectl talks to it. Controllers talk to it. Nodes talk to it. CI talks to it. Your platform automation talks to it, sometimes with permissions that make security people stare silently at the wall.

So we naturally think about API server networking as inbound access.

Can my node reach it?

Can my laptop reach it?

Is the endpoint public?

Did someone add 0.0.0.0/0 because "temporary" is apparently a religion?

That model is incomplete.

The API server also calls out. It calls admission webhooks. It fetches OIDC discovery documents. It proxies requests to aggregated API servers. If your cluster has serious extension points, the API server is not just receiving traffic. It is participating in your network design.

That is the part this EKS feature makes very explicit.

admission webhooks made this inevitable

Admission webhooks are one of those Kubernetes features that start innocent and then become load-bearing.

At first, maybe you use a validating webhook to block privileged containers. Nice. Useful. Easy to explain.

Then you add mutation for sidecars. Then policy enforcement. Then security scanning. Then internal platform defaults. Then some vendor controller installs a webhook with a certificate rotation story that feels like folklore.

Eventually a pod creation request is not just a write to the API server. It is a small distributed transaction involving your control plane, webhook services, DNS, network routing, TLS, timeouts, retries, and humans asking why deployments are stuck.

Very calm technology.

When the API server calls an admission webhook, that outbound path is part of your availability and security boundary. If you cannot observe it, route it, restrict it, or explain it during an audit, then it is not really governed. It is just trusted.

And "trusted because the cloud provider handles it somewhere" is not always enough, especially for regulated teams.

private endpoints solved only half the story

EKS has had private endpoint options for a long time. Those are about how clients reach the Kubernetes API server. Private endpoint access is the inbound side of the conversation.

Customer-routed control plane egress is the other direction.

It answers a different question:

Where does the API server go when it needs to call something on my behalf?

That distinction matters because a private cluster endpoint can make a team feel more secure than it really is. Yes, your workers and operators may reach the API server privately. Good. But if the API server still needs to call a webhook, identity provider, or extension API, the outbound path has its own controls, logs, failure modes, and surprises.

This is the kind of detail that does not fit nicely in architecture diagrams. The diagram has a box named "EKS control plane" and a line to "VPC" and everyone nods because meetings must end eventually.

Reality is more annoying.

The control plane has traffic classes. Some are AWS-managed. Some are customer-controllable. Some can now route through your VPC. Some cannot. AWS is explicit that EKS-managed components keep using EKS-managed paths, and that things like EKS Capabilities run in separate AWS-managed infrastructure. The IAM Authenticator's STS calls continue on the EKS-managed path too.

That is not a flaw. That is the contract.

The useful work is understanding the contract instead of pretending the box is magic.

this is network policy for the grown-up cluster

The phrase "network policy" usually makes Kubernetes people think about pod-to-pod traffic.

Which namespace can call which service? Which egress destinations are allowed? Is DNS open? Did we accidentally allow half the internet because the payment API changed IP ranges again?

All still important.

But serious platform teams are going to start applying the same instinct to control-plane initiated traffic.

If the API server calls a webhook, should that traffic stay inside the VPC? Should it go through AWS Network Firewall? Should it use PrivateLink? Should VPC Flow Logs capture it? Should an organization policy require customer-routed egress for certain clusters?

AWS even added an IAM condition key for this, eks:controlPlaneEgressMode, which is the kind of boring detail that tells you the feature is aimed at real enterprise control, not demo confetti.

This is what platform maturity looks like. Not always heroic. Often just routing a packet through the boring place where your controls already live.

extensions turned the control plane into an application dependency

The bigger story is that Kubernetes keeps moving more business logic into extension points.

Admission controllers enforce policy. Aggregated APIs extend the platform. Operators reconcile the weird stuff. OIDC connects identity. Controllers talk constantly. The "cluster" is no longer just a scheduler plus some pods. It is an operating system made of APIs, callbacks, controllers, and disappointed YAML.

So the API server's outbound traffic is not background noise.

It can decide whether deployments proceed, whether identities validate, whether custom resources work, and whether your platform rules actually run.

That means it belongs in the same discussions as workload egress, service mesh policy, private networking, audit trails, and incident response. Not because every company needs maximum lockdown. Because every company needs to know which parts of the system are allowed to call which other parts, and what happens when they cannot.

managed kubernetes is not an excuse to stop understanding kubernetes

The lazy interpretation of managed Kubernetes is "the cloud provider runs the hard parts, so I do not have to care."

The better interpretation is "the cloud provider runs some hard parts, and I still need to understand the contract at the boundaries."

Customer-routed control plane egress is one of those boundary features. It does not make the EKS control plane yours. It does not turn managed Kubernetes into self-managed Kubernetes. Please do not take a useful feature and convert it into weekend suffering.

It just gives you more control over specific outbound traffic that exists because of your cluster configuration and your extension choices.

That is exactly the sort of feature regulated and platform-heavy teams need. Not because it looks exciting in a keynote, but because it lets them answer practical questions: where did this traffic go, which policy controlled it, can we prove it, and can we explain the failure?

This is the boring endgame for a lot of cloud features. The first version makes the thing easy. The later versions make it governable.

the punchline

The Kubernetes API server is not just a sacred endpoint in the sky.

It is part of your system.

If it calls your webhooks, identity providers, and extension APIs, then its outbound path is part of your architecture. It deserves routing, logging, policy, failure testing, and ownership.

That may feel like one more thing for platform teams to carry.

It is.

Sorry.

But it is also healthier than pretending the control plane is outside the blast radius of the extensions we keep attaching to it.

Managed Kubernetes made clusters easier to create.

Extension-heavy Kubernetes made them harder to reason about.

Customer-routed control plane egress is a useful reminder that the control plane is not above the network.

It is in the network.

Act accordingly.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

ai-era interviews should test evidence, not leetcode muscle memory

Paulo Victor Leite Lima Gomes — Wed, 15 Jul 2026 00:06:25 +0000

Software engineering interviews have always had a strange theater problem.

We ask people to reverse a linked list, then hire them to spend six months arguing with YAML, logs, flaky tests, half-migrated services, and the undocumented billing job everyone fears.

Very normal industry. No notes.

Now AI is making the old ritual look even weirder.

Recent coverage from The Guardian, Business Insider, and ITPro all circles the same point: software engineering is not disappearing, but the visible shape of the job is changing. More code can be generated. More candidates will show up with AI in their workflow. Some companies already encourage it in interviews. At the same time, people are worried about juniors skipping fundamentals because the assistant gives them a plausible answer before they understand the question.

That does not mean interviews should become "prompt this chatbot while we watch."

It also does not mean we should retreat into LeetCode nostalgia and pretend the last decade did not happen.

The better interview should test evidence.

Not vibes. Not memorized puzzle moves.

Evidence.

code generation made the old signal weaker

The classic algorithm interview was never perfect, but it had a theory behind it. If someone could solve a constrained problem under pressure, maybe they had enough programming fluency, decomposition, and correctness thinking to do real work.

Sometimes that signal was useful. Sometimes it filtered for people who had time to grind the format. Sometimes it selected for confidence more than judgment. We all know the game.

AI makes the signal weaker because the easiest parts to test are now the easiest parts to outsource.

Write a function from a clean prompt? Generate boilerplate? Remember syntax? Produce a first-pass implementation? Those are no longer rare skills. They are table stakes plus tool usage.

That does not make programming knowledge obsolete. The opposite, actually.

When the assistant produces code, the engineer still has to know whether the code is correct, maintainable, secure, idiomatic for that codebase, and compatible with the mess already in production. The assistant can write a migration. It cannot feel the cold sweat of being on call when that migration locks the wrong table.

So an interview that only tests raw code production is increasingly testing the part of the workflow that is getting commoditized.

The more valuable signal is what happens after the code appears.

give candidates a messy diff

One good AI-era interview is simple: give the candidate a generated pull request.

Not a perfect one. A realistic one.

The diff should include a small feature or bug fix with a few problems: maybe an edge case, a weak test, a security issue, a hidden coupling, or a migration with bad production behavior.

Then ask the candidate to review it.

What worries you?

Which tests would you add?

What would you ask the author?

Which part can ship today and which part needs another pass?

What evidence would make you comfortable approving this?

This tests something closer to the work.

A good engineer reads code skeptically without becoming theatrical. They separate style nitpicks from correctness issues. They notice when a change violates a boundary. They know when a test is useful and when it is just a decorative green checkbox.

That is much harder to fake with a memorized problem set.

It is also exactly where AI changes the job. If teams use coding agents, review load goes up unless the agent output is boringly good. The candidate who can inspect generated work, ask for evidence, and improve the change without turning every review into a personality contest is valuable.

That person saves production.

Or at least saves the team from another "tiny cleanup PR" that somehow rewrites authentication.

test debugging, not just building

Another better interview: give the candidate a failing test and an incident-shaped timeline.

The service started returning 500s after a dependency update. The logs show a weird serialization error. A teammate already asked an AI assistant and got a confident but probably wrong explanation. The candidate gets the code, the logs, and the failing test.

Ask them to debug out loud.

Not perform confidence. Debug.

What do they inspect first? Do they form hypotheses? Do they know how to reduce the problem? Do they distrust the first plausible answer? Do they know the difference between fixing the symptom and fixing the cause?

This is where fundamentals still matter.

Git matters because you need to understand what changed.

Tests matter because you need a reproducible signal.

Logs matter because production does not care that your local run was beautiful.

Architecture matters because a local bug often has system-level consequences.

AI can help with each step, but it cannot replace the engineer's responsibility to verify. If anything, it makes verification more important because the assistant can produce a very clean wrong answer.

prompt fluency is useful, but judgment is the product

Yes, candidates should probably know how to use AI tools.

Pretending otherwise is silly. It is like interviewing a backend engineer in 2026 and acting surprised that they use an IDE, docs, and a terminal. Tool fluency is part of the job.

But "can prompt well" is not enough.

The useful question is whether the candidate can turn AI output into accountable engineering work.

Can they write a prompt that includes constraints from the existing system? Can they ask the model for alternatives instead of accepting the first answer? Can they force the assistant to produce tests, assumptions, and failure modes? Can they spot hallucinated APIs?

That last one matters more than people admit.

Sometimes the fastest AI workflow is closing the chat and opening the file.

This is also why companies should stop treating AI-assisted interviews as cheating by default. If the real job allows AI tools, the interview should observe how candidates use them. The interesting signal is whether the tool makes their work more inspectable or just more confident.

juniors still need the boring foundations

There is a real concern in the ITPro/O'Reilly-style discussion about fundamentals. If new developers skip Git, testing, debugging, code review, and architecture because AI gives them runnable-looking answers, they become productive enough to create change, not grounded enough to own it.

That is not a reason to ban AI from learning. It is a reason to design interviews and apprenticeships around ownership.

Ask junior candidates to explain a diff, a failing test, and a safe revert. Let them use AI, but require them to validate every claim against the codebase.

hiring should reward the work we actually need

The industry says it wants engineers with judgment, ownership, debugging skill, systems thinking, security awareness, and the ability to work with AI.

Then many interviews still reward speed-running toy problems.

This mismatch was annoying before.

Now it is expensive.

If the job is becoming more about reviewing generated work and deciding what evidence is enough, then the interview should look like that. Give candidates a generated patch, an ambiguous ticket, a flaky test, or an AI-produced explanation and ask them to verify it.

A strong candidate should be able to say what is correct, what is risky, which test is weak, which requirement is ambiguous, and where the AI answer sounds plausible but the code says something else.

That is not less technical than a puzzle. It is more technical because it connects code to consequences.

the punchline

AI did not make software engineering interviews easy to fix.

It made the old laziness harder to defend.

The question is no longer "can this person produce code in isolation while someone watches awkwardly?"

The question is "can this person turn code into reliable engineering evidence?"

That means review. Debugging. Tests. Logs. Git history. Architecture boundaries. Security thinking. Rollback plans. Clear explanations. The unglamorous stuff that keeps systems alive.

LeetCode muscle memory is not useless. It can still test some fluency.

But if it remains the center of the interview while the actual job moves toward AI-assisted delivery, companies will hire for the wrong reflexes.

The best interview now is not the one that proves a candidate can write code without help.

It is the one that proves they can be trusted when help produces code too quickly.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

choosing the right agent surface: Codex, Claude Code, Copilot, and when not to use an agent

Paulo Victor Leite Lima Gomes — Tue, 14 Jul 2026 21:32:11 +0000

This is part 5 of a 5-post series on professional agentic coding for senior engineers.

There is no single best coding agent.

There is a best surface for the task.

That distinction matters.

If you choose the tool because it is fashionable, you will bend the workflow around the tool. Senior engineers should do the opposite: choose the surface that gives the right context, permissions, verification loop, and review path.

use Codex when you want repo-aware terminal work

Codex is a strong fit when the work is close to the repository and you want the agent to inspect files, edit code, run commands, manage plans, use subagents, and produce a verified diff.

Good Codex tasks:

bug fixes with tests
repo investigations
refactors with clear boundaries
PR review with /review
multi-step terminal workflows
tasks that benefit from AGENTS.md
long-running goals with explicit verification

Good Codex prompt:

Goal: fix the import cycle causing the API package to fail typecheck.
Context: start with pnpm typecheck output and packages/api/src.
Constraints: no new dependencies, preserve public exports.
Done when: typecheck passes and /review finds no blocking correctness issues.

Codex is not magic because it is Codex. It is useful because it can work in the same environment as the code and show evidence.

use Claude Code for terminal-native planning and hooks

Claude Code is strong for terminal-native coding flows, plan/explore workflows, subagents, project memory through CLAUDE.md, and hooks for repeatable checks.

Good Claude Code tasks:

explore a new codebase area before editing
implement a bounded change with a plan
use subagents for specialized review
run repeatable local checks
keep recurring project notes in CLAUDE.md

Good Claude prompt:

Use plan mode.
Inspect the checkout flow and current tests.
I want to add retry handling for transient PSP timeouts.
Do not edit files until you explain the existing flow and propose a minimal plan.

Claude Code's plan-first workflow is especially useful when the engineer wants the model to slow down before touching files.

use GitHub Copilot agents for GitHub-native issue-to-PR work

GitHub Copilot coding agent is useful when the work naturally starts as a GitHub issue and should end as a PR.

Good Copilot agent tasks:

well-scoped issues
small-to-medium feature changes
docs updates
test additions
simple bug fixes with clear reproduction
repository-governed workflows

The issue has to be concrete.

Bad issue:

Improve onboarding.

Good issue:

## Goal

Show validation errors inline on the signup form instead of only as a toast.

## Scope

- apps/web signup form only
- no API changes

## Done

- invalid email and missing password errors show inline
- existing signup tests pass
- PR includes screenshot

Copilot can also use repository instructions and custom agents. That makes it good for org-level workflows, but only if the instructions are maintained.

use IDE chat or autocomplete for small local edits

Not every task needs a full agent.

Use IDE chat or autocomplete when:

you are editing one function
you know exactly what to change
the risk is small
verification is immediate
the surrounding context is already in your head

Example:

Rewrite this function to remove the duplicated null checks.
Keep behavior identical.

No need to spin up a full autonomous loop for every small cleanup.

when not to use an agent

Sometimes the right answer is: do not delegate this yet.

Avoid agents when:

the product decision is unclear
the acceptance criteria are political or subjective
the change affects money movement without strong tests
the task requires production secrets the agent should not access
the migration is destructive
the blast radius is not understood
there is no realistic verification path

This does not mean agents can never help.

They can investigate, write a plan, enumerate risks, or draft tests.

But implementation should wait until the human decision or verification path exists.

bad practice: tool loyalty

Tool loyalty is when engineers say:

I do everything in Claude.

Or:

I only use Codex.

Or:

Copilot should handle all issues.

That is not engineering judgment. That is brand attachment.

Better:

use Codex when the local repo and terminal loop matter
use Claude Code when plan/explore and subagent workflows fit
use Copilot when GitHub issue-to-PR governance is the cleanest path
use IDE completion for tiny edits
use no agent when the problem is not ready

the selection checklist

Before choosing a surface, ask:

Where does the source of truth live: local repo, GitHub issue, production logs, design doc?
Does the task need local secrets or local state?
Does the task need a PR from an issue?
Does it need a plan before edits?
Does it need subagents or fresh-context review?
What tools must run to prove success?
What permissions are safe?
What is the blast radius if the agent is wrong?

The answer usually tells you the tool.

closing the series

The professional workflow is not "use more AI."

It is design the loop.

Context.

Plan.

Patch.

Proof.

Review.

Reusable instructions.

Senior engineers who do that will get leverage from agents.

Senior engineers who skip it will get bigger diffs and more review fatigue.

The model matters.

The loop matters more.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

review and verification: making agent code mergeable

Paulo Victor Leite Lima Gomes — Tue, 14 Jul 2026 21:31:35 +0000

This is part 4 of a 5-post series on professional agentic coding for senior engineers.

Agent-written code should pass a stronger bar, not a weaker one.

That sounds obvious.

In practice, teams do the opposite.

The agent writes a diff quickly. The diff looks coherent. The human skims. The PR ships.

Then production explains what the review missed.

The fix is not to distrust agents blindly. The fix is to make verification explicit.

tests before trust

For a bug fix, ask for a regression test first when practical.

Before changing production code, add a failing test that reproduces expired sessions returning 500.
Run only that test and show the failure.
Then implement the fix.
Then rerun the test and the focused auth suite.

This is not only about correctness. It also teaches the agent the target behavior.

Without a failing test, the agent may fix a nearby problem and still miss the actual one.

focused checks first

Do not start with the entire CI pipeline if the feedback loop is slow.

Start focused:

changed package tests
changed file tests
typecheck for changed package
lint for touched files
UI screenshot or Playwright spec for the changed screen

Then broaden:

full package test suite
full typecheck
build
integration tests
PR checks

This mirrors how senior engineers work manually.

Fast feedback first. Wider confidence later.

require evidence in the final summary

A useful agent final summary includes:

files changed
behavior changed
commands run
outputs or pass/fail state
checks not run and why
remaining risks

Bad:

Done. I fixed it.

Good:

Changed:
- src/auth/session.ts
- tests/auth/session.test.ts

Verification:
- npm test -- tests/auth/session.test.ts: passed
- npm run typecheck: passed

Risk:
- Did not run full integration suite because local database is unavailable.

This is the minimum useful handoff.

fresh-context review

The writer agent should not be the only reviewer.

Use fresh context.

Codex has /review, which can inspect uncommitted changes, a branch diff, or a commit and report prioritized findings without changing the working tree.

Claude Code can use a separate reviewer session or a review-focused subagent.

GitHub Copilot can review PRs too, but do not confuse automated review with approval. It is one input.

Good Codex pattern:

/review
Review the branch diff against main.
Prioritize correctness, regressions, missing tests, and security issues.
Do not suggest style-only changes unless they hide a real risk.

Good Claude pattern:

Use a fresh reviewer subagent.
Review the diff for auth/security risks only.
Return file/line references, severity, and suggested fixes.
Do not modify files.

The key is independence. The reviewer should not be carrying the implementation plan in its head.

compare against product intent

Agent code can pass tests and still be wrong.

Maybe the test asserted the wrong behavior.

Maybe the implementation solves a technical symptom but violates product expectations.

Maybe the API now behaves correctly for one client and breaks another.

Senior review is where product intent comes back into the room.

Ask:

Does this solve the user-visible problem?
Does it preserve existing contracts?
Does it create a migration or rollout risk?
Does it make observability better or worse?
Are failure modes clearer?
Can support explain this behavior?

Agents are good at local code changes. Senior engineers are supposed to see the system.

be careful with workflow changes

GitHub's Copilot docs warn about reviewing Copilot output and being careful with generated changes. This is especially important when the PR touches workflows, permissions, or automation.

Do not casually approve agent changes to:

GitHub Actions workflows
deployment scripts
secrets handling
auth middleware
database migrations
package-lock-level dependency changes

Those are high-leverage files.

The agent may be right.

Read them anyway.

bad practice: writer self-certification

The most common bad pattern:

Implement the fix and tell me if it looks good.

Of course it will say it looks good.

You asked the author.

Better:

Implement the fix, run the focused tests, then stop.
After that, I will run a fresh-context review.

Or:

After implementation, spawn a read-only reviewer subagent to inspect the diff for correctness and missing tests.

Make review a separate step.

checklist

Before merging agent-written code:

Is there a regression test when practical?
Did focused tests pass?
Did typecheck/lint/build run where relevant?
Did a fresh-context review happen?
Are the final commands and results visible?
Are skipped checks explicitly explained?
Did a human compare the diff to product intent?

If the answer is no, the PR is not ready.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

subagents and specialized agents: parallelism without chaos

Paulo Victor Leite Lima Gomes — Tue, 14 Jul 2026 21:30:59 +0000

This is part 3 of a 5-post series on professional agentic coding for senior engineers.

Subagents are one of the most useful ideas in agentic coding.

They are also one of the easiest ways to create a mess.

The rule is simple:

Use subagents to isolate context and specialization.

Do not use subagents to create uncontrolled shared-state writes.

why subagents work

Main agent context is expensive attention.

If you fill it with logs, search results, failed attempts, screenshots, and five different hypotheses, the final implementation gets worse.

Subagents let you move noisy work out of the main thread.

Good subagent work:

read-heavy research
security review
test gap analysis
log investigation
API surface mapping
migration planning
docs summarization
fresh-context review

Bad subagent work:

six agents editing the same files
parallel refactors in one checkout
broad write access with vague roles
"everyone go fix payment bugs"

The first category reduces cognitive load.

The second creates coordination debt.

Codex example: read-only review swarm

Review this PR using parallel read-only subagents.

Spawn:
- one agent for security and correctness
- one agent for missing tests
- one agent for maintainability and API design

Keep all agents read-only.
Wait for all three.
Summarize findings by severity with file references.

This is a good use of parallelism because each agent has a different lens and no agent writes.

The main agent or human engineer integrates the findings.

Claude Code example: isolated investigation

Use a subagent to inspect token refresh edge cases.
It should read src/auth and tests/auth.
Report only:
- likely bug locations
- missing tests
- risks
- file references

Do not modify files.

That subagent can consume a lot of context without polluting the implementation thread.

Then the main session can turn the result into a small plan.

GitHub Copilot custom agents

GitHub Copilot's custom agents are useful when a repository has repeated specialized work.

Examples:

security reviewer
migration planner
accessibility reviewer
test coverage reviewer
documentation maintainer

The custom agent should have a narrow role, clear instructions, and constrained tools.

Bad custom agent:

---
name: backend-genius
tools: ["*"]
---

You are a world-class backend engineer. Fix whatever is needed.

Good custom agent:

---
name: migration-reviewer
description: Reviews database migrations for safety and reversibility.
tools: ["codebase", "search"]
---

Review migration changes only.
Check for reversibility, locking risk, destructive operations, and missing rollout notes.
Do not modify files.
Return findings with file references and severity.

Specific beats powerful.

parallel writes need separate worktrees

Sometimes parallel write work is valid.

But it needs isolation.

If two agents are implementing unrelated parts of a system, use separate worktrees or branches. Give each agent a narrow file ownership boundary. Merge deliberately.

Good:

Agent A: implement frontend validation in apps/web only.
Agent B: implement backend validation in apps/api only.
Use separate worktrees.
Do not edit shared packages without stopping for review.

Bad:

Both agents: improve checkout flow.

That is how you get two plausible designs, overlapping diffs, and a human stuck doing archaeology.

writer and reviewer is the safest pattern

The best first subagent pattern is not parallel implementation.

It is writer and reviewer.

Main agent or writer session implements a bounded change.
Fresh reviewer agent reads the diff.
Reviewer reports risks and missing tests.
Main agent fixes.
Human reviews final diff.

The reviewer has fresh context. It is not emotionally attached to the plan. It is not trying to defend its own code.

That alone catches a surprising amount.

bad practice: every agent gets every tool

Tool access should follow the role.

A log-analysis subagent probably does not need write access.

A security-review subagent probably should not push branches.

A migration planner probably should not execute production migrations.

Broad tools feel convenient until the wrong agent takes the wrong action.

This is normal engineering governance. Apply least privilege to agents too.

checklist

Before spawning a subagent, ask:

What specialized question should it answer?
Should it be read-only?
What files or systems can it inspect?
What output format do I need back?
Will its work pollute or clarify the main context?
If it writes, what ownership boundary prevents conflicts?

If you cannot define the role in one sentence, it is probably not a good subagent yet.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

instructions as code: AGENTS.md, CLAUDE.md, and copilot-instructions.md

Paulo Victor Leite Lima Gomes — Tue, 14 Jul 2026 21:30:11 +0000

This is part 2 of a 5-post series on professional agentic coding for senior engineers.

Agent instruction files are becoming part of the engineering system.

Codex has AGENTS.md.

Claude Code has CLAUDE.md.

GitHub Copilot supports repository instructions such as .github/copilot-instructions.md, path-specific instruction files, and cloud-agent instruction surfaces.

This is good.

It is also a new place to create technical debt.

instructions should be short and operational

The agent does not need a philosophy essay.

It needs the facts that change what it should do in this repository.

Good instruction files include:

install commands
focused test commands
typecheck and lint commands
repo layout
naming conventions
important boundaries
dependency rules
how to verify work
project-specific gotchas
PR expectations

Bad instruction files include:

stale onboarding docs
generic rules like "write clean code"
huge architecture histories
every preference someone has ever had
commands nobody has run in six months

The point is not to make the agent read more.

The point is to make it read the right things.

a useful AGENTS.md

# AGENTS.md

## Commands

- Install: pnpm install
- Test API: pnpm --filter @app/api test
- Test web: pnpm --filter @app/web test
- Typecheck: pnpm typecheck

## Repo Layout

- apps/api: backend HTTP API
- apps/web: React frontend
- packages/db: migrations and query helpers
- packages/shared: shared types and utilities

## Rules

- Prefer existing patterns over new abstractions.
- Do not add production dependencies without explicit approval.
- For bug fixes, add regression tests when practical.
- Do not edit generated files directly.

## Done Means

- Relevant tests pass.
- Typecheck passes for changed packages.
- Final response lists commands run and checks skipped.

That is not glamorous.

It is useful.

Codex loads AGENTS.md from global, project, and nested scopes, with closer files applying more specifically. That means you can keep root instructions broad and put package-specific rules closer to the code.

Root:

Prefer existing repo patterns. Run relevant tests. Do not add dependencies without approval.

apps/api/AGENTS.md:

Use Fastify plugin patterns already in this package.
Run pnpm --filter @app/api test for API changes.
Database migrations must be reversible.

This is better than one giant instruction file trying to govern everything.

a useful CLAUDE.md

Claude Code's memory guidance has the same shape. CLAUDE.md should contain recurring project knowledge, commands, conventions, and workflow notes.

Good:

## Common Commands

- pnpm typecheck
- pnpm --filter @app/api test
- pnpm --filter @app/web test

## Project Notes

- Auth sessions live in apps/api/src/auth.
- Payment ledger code is append-only; do not update historical rows.
- Prefer repository query helpers over raw SQL in application services.

## Verification

- Bug fixes should include regression tests when practical.
- UI changes need a screenshot or Playwright check.

Bad:

Be smart.
Write clean code.
Do not make mistakes.
Use best practices.

That feels nice and changes almost nothing.

Copilot instructions need the same discipline

GitHub Copilot's cloud agent works from issues and repository context. That makes durable instructions especially important, because the task often starts in GitHub rather than your local terminal.

Use .github/copilot-instructions.md for repository-wide guidance.

Use path-specific instructions when the rules differ.

Use custom agents when a role needs a narrow prompt and constrained tools.

The mistake is to assume "Copilot knows our repo." It knows what it can read and what you tell it to prioritize. If your issue is vague and your instructions are stale, you get a vague PR with stale assumptions.

what belongs in the prompt instead

Do not put task-specific details in durable instructions.

Bad AGENTS.md:

For the current auth bug, inspect ticket AUTH-123 and fix refresh tokens.

That belongs in the task prompt.

Durable instructions should be true next week.

One-off prompts should describe today's outcome.

This separation matters because instruction files survive. A stale one-off note inside a durable file becomes a hidden source of bad behavior.

bad practice: instruction dumping

Instruction dumping is when the team responds to one agent mistake by adding five more rules.

The file grows.

The model follows less of it.

The commands drift.

Nobody reviews it.

Then people say "agents do not follow instructions."

Sometimes true.

But often the instructions are unmaintainable.

Treat these files like code:

review changes
delete stale rules
keep commands executable
prefer specific rules over generic advice
keep path-specific context near the path
add rules only when they prevent repeated mistakes

checklist

A good instruction file answers:

How do I install and test this repo?
Where are the important packages?
What conventions are non-obvious?
What should I never do?
What does done mean here?
Which checks should I run for common changes?

If it does not affect the next action, cut it.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

the senior engineer's agent loop: context, plan, patch, proof

Paulo Victor Leite Lima Gomes — Tue, 14 Jul 2026 21:30:10 +0000

This is part 1 of a 5-post series on professional agentic coding for senior engineers.

The series:

the senior engineer's agent loop: context, plan, patch, proof
instructions as code: AGENTS.md, CLAUDE.md, and copilot-instructions.md
subagents and specialized agents: parallelism without chaos
review and verification: making agent code mergeable
choosing the right agent surface: Codex, Claude Code, Copilot, and when not to use an agent

The biggest mistake senior engineers make with coding agents is treating the prompt as the unit of work.

It is not.

The unit of work is the loop.

Context -> plan -> bounded execution -> verification -> review.

If that loop is strong, the model can be useful even when it is imperfect. If that loop is weak, even the best model becomes a confident diff generator.

start with the real outcome

Bad task:

Fix auth.

Better task:

Goal: expired sessions should redirect to login instead of returning 500.
Context: start in src/auth, src/session, and tests/auth.
Constraints: no public API changes and no new dependencies.
Done when: add a failing regression test, implement the fix, run npm test -- auth, and show the final output.

That second version is not "prompt engineering." It is normal engineering.

It says what is wrong, where to look, what not to change, and how we know the work is done.

Claude Code's best-practices docs make this very explicit: give the agent a verification signal. Tests, builds, screenshots, logs, fixture diffs, anything machine-checkable. Do not ask for "better." Ask for evidence.

Codex behaves the same way. A strong Codex task brief should include the goal, context, constraints, and done criteria. The more the agent has to infer, the more you are buying lottery tickets with your repository.

use planning when the scope is uncertain

Planning is not always needed.

If the change is tiny, let the agent edit.

But when the task is broad, unfamiliar, cross-cutting, or risky, split exploration from implementation.

Claude Code example:

claude --permission-mode plan

Read src/auth, src/session, and the existing auth tests.
I want Google OAuth login added without changing the current password login path.
First explain the current session flow, then propose the minimal implementation plan.
Do not edit files yet.

Codex example:

Use plan mode.
Read the payment retry flow and the tests around failed card charges.
Explain the current behavior, list the files that likely need changes, and identify risky edge cases.
Stop before editing.

GitHub Copilot coding agent example:

## Goal

Add retries for transient card network failures.

## Scope

- Only payment authorization retry behavior.
- Do not change settlement, refunds, or ledger posting.

## Done

- Regression tests cover network timeout and retry exhaustion.
- Existing payment tests pass.
- PR explains any behavior changes.

If the issue is not concrete enough for Copilot to produce a reviewable PR, the issue is not ready for an autonomous coding agent.

constrain the patch

Agents are very good at "while I was here" edits.

That is dangerous.

A senior engineer should define the allowed patch surface before implementation starts.

Good:

Only edit src/auth/session.ts and tests/auth/session.test.ts unless you find a hard blocker.
If another file must change, stop and explain why first.

Bad:

Clean this up while fixing it.

"Clean this up" is where a small bug fix turns into an architecture argument hidden inside a diff.

ask for proof, not confidence

The final response should not be:

Done, the issue is fixed.

The final response should look more like:

Changed:
- src/auth/session.ts
- tests/auth/session.test.ts

Verification:
- npm test -- auth/session.test.ts: passed
- npm run typecheck: passed

Notes:
- No public API changes.

If a check cannot run, the agent should say why.

If a test fails, the agent should read the error, fix the root cause, and rerun it.

This is where senior engineers keep control. Not by manually writing every line, but by refusing to accept unverifiable work.

bad practice: "prompt and pray"

The failure mode looks like this:

vague request
broad edits
no test added
no focused verification
same agent self-certifies
human spends review time reverse-engineering intent

That is not a workflow. That is a cleanup job.

The fix is boring and powerful:

define the outcome
give high-signal context
set boundaries
ask for a plan when needed
demand proof
review the diff

That loop is the difference between agentic coding as engineering practice and agentic coding as expensive autocomplete.

checklist

Before giving an agent write access, ask:

What is the exact customer or system behavior I want?
Where should the agent start reading?
What files or areas are out of bounds?
What checks prove the work?
Should the agent plan first?
Who reviews the final diff?

If you cannot answer those, you are not ready to delegate the task yet.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.