DEV Community: Dmytro Sirant

It’s AI coding era but naming is still hard

Dmytro Sirant — Mon, 13 Apr 2026 04:29:50 +0000

“There are only two hard things in computer science: cache invalidation and naming things.”
~ Phil Karlton

It’s been about a year since I started using AI daily.

In my core role as an SRE/DevOps engineer, AI behaves like a very fast and very obedient assistant. It helps me collect data across services via MCP, generate Terraform modules, work with Helm charts, and automate routine tasks.

There is no “wow” factor here. Just speed.

I don’t expect creativity.
I don’t want initiative.
I want predictable output.

In these scenarios, I already know what the result should look like. I have examples, constraints, and a clear definition of done. AI just accelerates execution. Control stays on my side.

Then I switch context.

I start using AI for software development. And everything changes.

As an AWS Community Builder, I have access to tools like Kiro and Kiro CLI - agentic AI development environments backed by Anthropic (and other) models. These tools are powerful.

But they expose a different problem.

Not in AI. In us.

The real bottleneck

When working with AI on anything non-trivial, the bottleneck is not code.

It’s how you describe what you want.

Not syntax.
Not frameworks.
Not even architecture.

Language.

If your instructions are vague, inconsistent, or overloaded with assumptions - the output will reflect that.

And unlike humans, AI won’t ask clarifying questions by default. It will generate something that looks correct but is fundamentally wrong.

This is where things start breaking.

Naming breaks everything

One example from practice.

I had to modify an old project that wasn’t maintained for ~8 years. The goal was simple: update dependencies, remove legacy functionality, and add new features.

The problem was not the code.

The problem was naming.

The same concept - a media file - was called:

track
item
product

Depending on the part of the codebase (mobile apps, backend, frontend), they were developed by different freelancers at different times.

From a human perspective, this is annoying.

From an AI perspective, this is chaos.

The model tries to infer relationships. It guesses. Those guesses propagate into generated code, queries, and logic.

Before doing any actual work, I had to:

Recall the real domain model
Standardise terminology
Refactor naming across the codebase

Only after that AI became useful again.

Non-native constraint (and advantage)

As a non-native English speaker, I hit another limitation.

My vocabulary is narrower. I often use simpler words. Sometimes these words are technically correct, but semantically ambiguous.

For humans, this is manageable. For AI, it creates drift.

At the same time, this constraint forces something useful:

More precision. Less noise.

And with AI, precision matters more than expressiveness.

Don’t start with code

Most people approach AI like this:

“Here’s the idea — build it.”

This is the fastest way to get something wrong.

The approach that actually works is different:

Define terminology
Lock naming conventions
Describe entities and relationships
Let AI ask questions
Refine understanding
Only then generate code
This feels slower. It isn’t. AI can write code in seconds. Refactoring unclear code takes hours.

The key shift is simple:

Don’t ask AI to build. Ask it to interrogate you.

“Ask me everything you need to fully define this system.”

This forces you to externalise assumptions — things that are obvious to you but invisible to AI.

This is not new. This is what business analysts have always done. What changes now is the leverage. AI handles a large part of implementation. The bottleneck moves to understanding and definition.

Which means:

People who can clearly describe problems gain more influence than people who can just implement solutions. Not because they write code. Because they define it. AI doesn’t remove complexity. It shifts it.

From code → to thinking

From implementation → to communication

The developers who benefit the most are not the fastest coders. They are the ones who can clearly describe what needs to be built.

Naming things is still hard. Now it’s also critical.

Looking for your comments, no matter if you agree or don’t!
Let’s connect on LinkedIn !

How I Overlooked the Problem and Shot Myself in the Foot

Dmytro Sirant — Fri, 07 Nov 2025 02:54:02 +0000

Migration Setup

As part of my work as an AWS consultant this year, I’ve been doing migrations from IAM Users to SSO (yes, I know, but better late than never). There’s a checklist I follow during such migrations, and one of the last stages is to keep IAM Users disabled (keys and web access) for about a month, just to ensure that everything works fine without issues. This approach proved helpful in the case of EKS clusters before AWS introduced the ability to manage cluster access via API instead of the legacy aws-auth configmap.

The Missed Detail

But there was one issue I kept overlooking until it finally caught up with me. Long story short: the migration from IAM to SSO was completed, and after the planned cooldown, IAM users were deleted. Some time later, I decided to upgrade the IaC with a new version of the terraform-aws-eks module. The terraform plan showed expected changes, but during terraform apply I got an error stating that my SSO account had no permission to update the KMS key alias (a minor change due to improved naming conventions).

A quick check showed that the KMS key created by the previous version of the module had a neat, least-privilege key policy — with kms:PutPolicy permission granted only to the IAM user I’d used to create the EKS cluster with KMS envelope encryption. Ironically, that IAM user had been disabled for a month and deleted only a week earlier.

False Sense of Victory

My first thought was that it wasn’t a big deal — I’d just remove the current KMS key object from the Terraform state, let it create a new key, and associate it with the cluster. Sounded good. Even better, terraform plan and terraform apply completed without errors. Problem solved!

or so I thought...

After a few small tweaks, I ran another change and noticed that Terraform tried to update the EKS cluster resource again. The only difference was the KMS envelope encryption key association. Multiple runs, same behaviour — Terraform applied the change successfully, yet it wasn’t reflected in the cluster settings (it still used the old KMS key I had no access to).

A quick check of the documentation confirmed that the envelope encryption key can’t be changed after creation. Fair enough. But why didn’t Terraform respect that? I’m not sure yet whether the AWS API isn’t returning a proper response code, or the Terraform AWS provider doesn’t handle it correctly.

Recovery Attempt

So, I needed recovery access to the KMS key somehow. How do you get maximum access permissions to an AWS account? Correct — use the root login. Unfortunately, even with root permissions, I couldn’t update the KMS key policy. Great for security, but I still needed to regain access to the key. Time to check if anyone else had faced the same issue, and within a few minutes the answer was clear — contact AWS Support.

I opened a support case, explained the problem, and provided the ARN of the KMS key along with the policy I wanted to attach. What could be simpler? The support response surprised me. I had to follow a specific set of instructions:

To recover your unmanageable keys, please follow these steps:

Create 1 IAM user for every affected key using the following naming convention: kms_key_recovery_ For Example. If the Key ID is “17e51010-cc0f-2268-bccd-2699f10c133a” , then the corresponding recovery user would be “kms_key_recovery_17e51010-cc0f-2268-bccd-2699f10c133a”. Create and attach the following IAM policy to the newly created users: { “Version”: “2012–10–17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “kms:ListAliases” ], “Resource”: “*” } ] }

Once the recovery users have been created, please respond to this case with a list of the ARNs of the keys for which you have made recovery users and the respective users ARNs.

We will then contact you via the phone number listed in your account Contact Information to verify the One-Time Password listed above. Once verified, we will engage our internal KMS team to initiate recovery and update your case when complete. Your key recovery users will have the ability to modify the key policies of their respective keys. If the process was abandoned, we will inform you which users in your account still have access.

Because it’s not a synchronous operation and the KMS key policy can be updated at any time within a 12-hour window, I was worried the cluster might enter a degraded state before I could apply the proper policy. Luckily, that didn’t happen. The AWS team just granted the required permissions to the key as an additional rule without dropping the existing ones. The next day, I received an update confirming the recovery procedure was complete, and I was able to attach the correct policy to the key.

Lessons Learnt

Now there’s a new step in my IAM-to-SSO migration checklist:
[ ] update KMS key policies before deleting IAM users.

Looking for your comments and let’s connect on LinkedIn

AWS and Docker Hub Limits: Smart Strategies for April 2025 Changes

Dmytro Sirant — Wed, 19 Mar 2025 09:01:10 +0000

Problem

Docker Hub has implemented rate limits on image pulls back on November 2, 2020, which made a lot of headaches for those who are using it in their environment. The following limits were introduced:

Anonymous Users: Limited to 100 pulls per 6 hours
Authenticated Users: Limited to 200 pulls per 6 hours

Many of us migrated to private repositories, quay.io, ghrc.io, registry.gitlab.com, and others. For some, it was enough to use an authentication token to pull from Docker Hub.

Starting from April 1, 2025 there is a new limits:

Personal (authenticated): Limited to 100 pulls per hour
Unauthenticated Users: Limited to 10 pulls per IPv4 address or IPv6 /64 subnet per hour

Solution

Let’s see what we have at AWS to solve the problem with the rate limit and even more perks.

In November 2021, AWS introduced the pull-through cache feature for Amazon Elastic Container Registry (Amazon ECR), which can help us with the following problems:

caching public and private images using an authentication token in your private ECR registry
speedup pulling from private ECR to your local services (ECS, EKS, Lambdas, etc.)
lifecycle policy to keep only the required number of the latest tags
security scanning of images during pull
a single place to update your token in case of rotation or expiration (e.g. Gitlab do not allow you to create tokens with an expiration date longer than one year). Just imagine you need to go through all your credentials in all K8s clusters one per year to update tokens.

So, let’s dive into the implementation of this feature. To make it work, you need to create:

a pull-through cache rule, where you define the prefix you want to use in your registry and the destination registry where you forward all requests
secrets manager credentials you want to use to authenticate to the destination registry
a pull-through cache repository template if you want to have a lifecycle policy, security scans

and some other features, which are optional at this stage.

As you can see, you are not creating the repository itself. It will be created automatically during the first pull-through cache request using default settings or a template if you have assigned one.

If I created a rule with the prefix dockerhub in the us-east-1 region and say to forward my pull requests to the registry-1.docker.io, I can use the following command:

# direct pull from Docker Hub
docker pull timberio/vector:0.45.0-alpine
# pull through ECR
docker pull 123456789012.dkr.ecr.us-east-1.amazonaws.com/dockerhub/timberio/vector:0.45.0-alpine

As you can see, I only added my repository and dockerhub as prefix, and then the original image to pull. It’s what you need to update in manifests later to pull images through ECR, which is pretty straightforward.

Automation

Sounds easy, but why not make it using Terraform (with a Terragrunt wrapper)? I created a simple Terraform module which helps you create multiple pull-through rules from the basic YAML file with the following structure:

dockerhub:
  registry: registry-1.docker.io
  username: user
  accessToken: token
gitlab:
  registry: registry.gitlab.com
  username: user
  accessToken: token

and module will create two rules with prefixes: dockerhub and gitlab , secrets manager credentials with username and accessToken, and basic lifecycle policy to keep only 3 latest images in cache (makes sense to extend the YAML with per-registry settings but I have no time for it now).
Because I’m using Terragrunt I can encrypt this file with Sops and commit to the repository safely, so my terragrunt.hcl is looking like that:

terraform {
  source = "${get_parent_terragrunt_dir()}modules/ecr-pullthrough"
}

include "root" {
  path = find_in_parent_folders("root.hcl")
  expose = true
}

locals {
  registries = yamldecode(sops_decrypt_file("${get_terragrunt_dir()}/secrets.enc.yaml"))
}

inputs = {
  registries = local.registries
  tags = merge(include.root.locals.default_tags)
}

You can find my module on Github https://github.com/opsworks-co/ecr-pull-through

If you are using https://github.com/terraform-aws-modules/terraform-aws-eks module to create your cluster and using in-built role it is creating for the worker nodes, don’t forget to extend it with a new policy to allow ecr:BatchImportUpstreamImage because by default it attaches managed policy arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly which doesn’t allow pull-through cache.

Looking for your comments, suggestions and improvements!
Follow me on Medium, connect on LinkedIn!