DEV Community: Sergio D. Rodríguez Inclán

Devbox: Portable and Isolated Development Environments

Sergio D. Rodríguez Inclán — Sun, 06 Sep 2026 21:00:03 +0000

Introduction

I am one of those people who need to have everything in its place to be able to do something. This applies, of course, when I work with a local or remote repository. I need to have all the dependencies installed and configured; moreover, the environment must be prepared with all the tools and with signaling showing the current status of the environment.

By signaling, I mean the console "prompt," which should be as friendly and aesthetic as possible. For example:

The terminal is iTerm, running zsh by default, with the Presto extension, which allows me to configure plugins that enhance command searches in history, improve interaction with Git, and much more. Anyone interested can check its features by following the link.

In a development directory, the visual aspect should display the current path, the branch I’m on, and if I’m within a special environment like a virtualenv, etc. For example, the directory where I develop this blog:

The knowledgeable reader will notice that I am using a Nix environment and a terminal multiplexer (Zellij).

Nix

Nix is an ecosystem of several open-source projects supported by its community.

The most relevant ones in my opinion are:

NixOS: A complete GNU/Linux distribution.
nix-shell: An Ad Hoc shell that allows installing existing packages from the Nix repositories. These packages are downloaded to a Nix repo located at a local path.
Nix Language: A shell programming language of its own that allows manipulating Nix environments at will.

The nix-shell can be installed on MacOS, WSL (Windows), and GNU/Linux.

nix-shell works by creating an isolated area in the user’s environment where a local repository manages the Nix packages installed by the user.

The Nix shell is great, but it has a couple of drawbacks. The repository it creates is global for the user; all installed packages are stored in one place. Therefore, cleaning up dependencies can be somewhat complicated. The second problem is that to manage it efficiently, one has to learn the language it uses, which is quite complex. Not everyone will want to invest time in learning a language just to create their development environments.

There are several alternatives based on Nix, but the one I find best, at least for the usage I give it, is Devbox.

Devbox

Devbox is similar to Nix in every way (it uses it behind the scenes), except that it generates repositories by project and its definition is much simpler, using a structured JSON file called devbox.json, which can be shared in the repository and makes the environment reproducible and automatable.

We will create a very simple example that can be found in this repository https://github.com/Walsen/devbox-basics

We must assume that we are on a Unix-compatible system with a shell similar to bash in the terminal.

Step 0: Install Devbox

It’s as simple as running a shell command (Linux & MacOS):

curl -fsSL https://get.jetify.com/devbox | bash

After this, Devbox will be available for use.

Step 1: Create the directory

We create a simple directory with the mkdir command and enter it:

mkdir devbox-basics
cd devbox-basics

Step 2: Generate the 'devbox.json' file and review its content

Devbox can automatically generate its configuration file:

devbox init
cat devbox.json

We can identify three main sections:

$schema: The document definition according to the version specified in the URL.
packages: An array with the list of packages installed for this repository and their dependencies.
shell: An object that contains other objects that help us automate the environment, either when starting it or on demand.
- init_hook: An array with a list of commands that will be executed when starting the environment.
- scripts: An object that contains key/value pairs where the value is an array that may contain shell commands that will be executed when the key is invoked using the command devbox run [key].

There are additional sections: env, env_from, and include. The first two are used to initialize environment variables, either explicitly specified in the devbox.json or read from a .env file. The last one is used to include additional Devbox plugins.

Step 3: Adding Packages / Dependencies

Generally, it's easy to locate the packages we want to install just by their common name; for example, we will add a list of packages that I commonly use:

devbox add git direnv awscli2 python@3.12 terraform just zellij pipenv

As the reader may notice, it’s possible to specify versions using the at sign after the package name, followed by the version. To see what versions are available or to search for the correct package, this page is available: https://search.nixos.org/packages.

Nix does not provide binaries for some packages, so it must compile the code; that's what it did with Terraform during the installation.

Finally, Devbox also provides ready-to-use (out-of-the-box) configurations for languages like Python, for which it offers a functional virtual environment. In my case, I chose Pipenv, so it will take a couple more steps to get it ready.

So far, our devbox.json looks like this:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [
    "git@latest",
    "direnv@latest",
    "awscli2@latest",
    "python@3.12",
    "terraform@latest",
    "just@latest",
    "zellij@latest",
    "pipenv@latest"
  ],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Step 4: Start the Shell

To start the Devbox shell, we simply run the following command:

devbox shell

The resulting screen should be similar to this:

We can notice that the "Prompt" has changed, indicating that we are inside the Devbox shell.

Let's check the dependencies and test the virtualenv:

From here, we can develop in Terraform and/or Python without any issues.

Step 5: Configure the Environment Using direnv

direnv is a small utility that automates the use of environment variables; we simply declare the variables in a .envrc file, and direnv will automatically load them when we enter the folder where the .envrc resides.

Devbox comes with support for direnv. To generate a configuration file, we run the following command from outside the shell:

devbox generate direnv

When executing the command, Devbox automatically generates it and runs the shell with the configurations from the .envrc. An interesting detail is that this way, the "prompt" from my console has been imported into the Devbox shell, which is very convenient.

Now that direnv is loaded, we can start exporting variables such as our AWS user's access keys.

We edit the .envrc file and at the end, we add the variables:

#!/bin/bash

# Automatically sets up your devbox environment whenever you cd into this
# directory via our direnv integration:

eval "$(devbox generate direnv --print-envrc)"

# check out https://www.jetpack.io/devbox/docs/ide_configuration/direnv/
# for more details

export AWS_ACCESS_KEY_ID="ASIA4RRMHHCFXBM0DKRM"
export AWS_SECRET_ACCESS_KEY="4pqlKkaQNBlueLLHkNiWpgDNzihdNfgTYjy3tYk0w"

We run the command at the same directory:

direnv allow

Every time a change is made to the .envrc, it’s necessary to authorize the change, which will "reload" the environment:

Finally, we test the access keys by listing our buckets in S3.

🚨 WARNING!! 🚨

NEVER send credentials or any sensitive text to the repository. Therefore, a good practice would be to leave the value of the access keys blank, submit the .envrc to the repo, add it to .gitignore afterward, and then it wouldn’t be taken into account for future submissions. Other team members could use their personal credentials without fear of submitting them later.

Step 6: Implement Automation

To test the automation features of Devbox, we will add a simple Python script that shows us the buckets in S3, replicating the command aws s3 ls.

The code would be as follows:

#!/usr/bin/env python3

import boto3
from botocore.exceptions import ClientError

def list_s3_buckets():
    """
    List all S3 buckets in the AWS account
    """
    try:
        # Create an S3 client
        s3_client = boto3.client('s3')

        # Get list of buckets
        response = s3_client.list_buckets()

        print("S3 Buckets:")
        print("-----------")

        # Print bucket names
        for bucket in response['Buckets']:
            print(f"- {bucket['Name']}")

    except ClientError as e:
        print(f"Error: {e}")
        return None

if __name__ == "__main__":
    list_s3_buckets()

If we run the code, we will get an error message:

This is obviously because we haven’t activated the Pipenv virtualenv.

To avoid the hassle of doing it each time we enter the environment, we will automate this task by modifying the devbox.json as follows:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [
    "git@latest",
    "direnv@latest",
    "awscli2@latest",
    "python@3.12",
    "terraform@latest",
    "just@latest",
    "zellij@latest",
    "pipenv@latest"
  ],
  "env_from": ".env",
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!'",
      "pipenv shell"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Environment Variables in a Virtualenv Shell

We have added a new attribute: env_from, which reads a .env file from the specified path and loads the environment variables. The reader may wonder why we are doing this since we already have direnv exporting variables for our Devbox environment; it is important to note that when the Python virtualenv is activated, a new shell is created with its own environment variables. To export our access keys to the virtualenv, we have to do it using this feature.

There is also the possibility of adding the variables directly in the devbox.json using the env block, but we want to add our access keys directly. Therefore, a .env file can be sent empty, allowing each user to add the variables for their environment.

So, our .env file contains:

AWS_ACCESS_KEY_ID="ASIA4RRMHHCFXBM0DKRM"
AWS_SECRET_ACCESS_KEY="4pqlKkaQNBlueLLHkNiWpgDNzihdNfgTYjy3tYk0w"

Commands in the init_hook

We have added the command pipenv shell as the second value in the init_hook list so that when the Devbox shell starts, it also starts the Pipenv virtualenv. The result should be similar to this:

And if we run our script, we see that it works perfectly.

One thing I am still working on is updating the prompt, respecting the original shell’s or loading a new one. However, since the virtualenv’s activate script runs a bash shell, there is not much to do unless we patch this file, but unfortunately, that wouldn’t be portable.

If we don’t mind executing a simple command like pipenv shell manually, then the prompt will respect the current one, and we avoid this automation, especially since if we are working with Terraform in the same repository, we may not want to be in the virtualenv all the time. In any case, this is just an example of what we can do.

Scripts

Devbox allows us to run scripts using the environment without the need to activate the shell; for example, we can run the script that lists buckets by modifying the devbox.json as follows:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [
    "git@latest",
    "direnv@latest",
    "awscli2@latest",
    "python@3.12",
    "terraform@latest",
    "just@latest",
    "zellij@latest",
    "pipenv@latest"
  ],
  "env_from": ".env",
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!'"
    ],
    "scripts": {
      "getbuckets": "pipenv run python getbuckets.py"
    }
  }
}

Now we simply need to invoke the key getbuckets in the devbox run ... command:

Devbox will temporarily raise the shell, load the variables, and execute pipenv run, which in turn will execute python getbuckets.py in its Python environment.

We must emphasize that the devbox run command is executed when the Devbox shell has not been activated; if we have direnv configured to automatically load the environment, then it will not work. To disable the automatic loading of the Devbox shell, we simply run:
direnv disallow
And the shell will no longer load when entering the directory.

Integration with Tools and Advanced Automation

Devbox provides us with the ability to chain commands when starting the environment or when executing scripts, but we can do more than just run simple commands. We can take advantage of lightweight task execution and workflow tools, such as:

Just (which we have installed with Devbox)
go-task command runner
Dagger local CI that uses containers

To demonstrate this point, we will create a set of Terraform scripts to launch an EC2 instance.

main.tf

provider "aws" {
  region = var.aws_region
}

resource "aws_instance" "app_server" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = var.instance_type

  subnet_id                   = aws_subnet.main.id
  vpc_security_group_ids      = [aws_security_group.instance_sg.id]
  associate_public_ip_address = true

  tags = {
    Name = var.instance_name
  }
}

# Get latest Amazon Linux 2 AMI
data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

variables.tf

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "instance_name" {
  description = "Value of the Name tag for the EC2 instance"
  type        = string
  default     = "AppServer"
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "subnet_cidr" {
  description = "CIDR block for subnet"
  type        = string
  default     = "10.0.1.0/24"
}

network.tf

# VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "main"
  }
}

# Public Subnet
resource "aws_subnet" "main" {
  vpc_id                  = aws_vpc.main.id
  cidr_block             = var.subnet_cidr
  map_public_ip_on_launch = true
  availability_zone       = "${var.aws_region}a"

  tags = {
    Name = "Main"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "Main"
  }
}

# Route Table
resource "aws_route_table" "main" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name = "Main"
  }
}

# Route Table Association
resource "aws_route_table_association" "main" {
  subnet_id      = aws_subnet.main.id
  route_table_id = aws_route_table.main.id
}

security.tf

resource "aws_security_group" "instance_sg" {
  name        = "instance_sg"
  description = "Security group for EC2 instance"
  vpc_id      = aws_vpc.main.id

  # SSH access
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Outbound internet access
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "instance_sg"
  }
}

outputs.tf

output "instance_id" {
  description = "ID of the EC2 instance"
  value       = aws_instance.app_server.id
}

output "instance_public_ip" {
  description = "Public IP address of the EC2 instance"
  value       = aws_instance.app_server.public_ip
}

output "instance_public_dns" {
  description = "Public DNS name of the EC2 instance"
  value       = aws_instance.app_server.public_dns
}

Now that we have the Terraform script, we create a small build script called justfile to execute the Terraform commands. Additionally, we will include a task to run our script to retrieve buckets in Python:

justfile

# Set the default recipe to list available recipes
default:
    @just --list

# Initialize Terraform
init:
    terraform init

# Show changes required by the current configuration
plan:
    terraform plan -out=tfplan

# Apply the changes required to reach the desired state
apply:
    terraform apply tfplan

# Destroy all remote objects managed by this Terraform configuration
destroy:
    terraform plan -destroy -out=tfplan
    @echo "Review the destruction plan carefully!"
    @echo "To proceed with destruction, run: just apply"

# Clean up local Terraform files
clean:
    rm -rf .terraform/
    rm -f tfplan
    rm -f .terraform.lock.hcl

# Format Terraform files
fmt:
    terraform fmt -recursive

# Validate Terraform files
validate:
    terraform validate

# Show current workspace
workspace-show:
    terraform workspace show

# Create and switch to a new workspace
workspace-new name:
    terraform workspace new {{name}}

# Switch to an existing workspace
workspace-select name:
    terraform workspace select {{name}}

# List all workspaces
workspace-list:
    terraform workspace list

# Combined recipe to plan and apply in one command (use with caution)
deploy: plan apply

# Combined recipe to initialize, plan and apply in one command (use with caution)
setup: init plan apply

# Combined recipe to destroy and clean up
teardown: destroy apply clean

# Execute Python Boto3 script to get a formated list of S3 buckets
get-buckets: 
  pipenv run python getbuckets.py

The advantage of using a task runner is that we can chain processes, add logic, and integrate tools. As seen in the justfile, we have added numerous capabilities for running sequences with Terraform as well as combining them with other tools, such as our Python script.

We will modify the devbox.json to use the tasks that interest us most:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [
    "git@latest",
    "direnv@latest",
    "awscli2@latest",
    "python@3.12",
    "terraform@latest",
    "just@latest",
    "zellij@latest",
    "pipenv@latest",
    "starship@latest"
  ],
  "env_from": ".env",
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!'"
    ],
    "scripts": {
      "tasklist": "just",
      "tfinit": "just init",
      "tfplan": "just plan",
      "tfapply": "just apply",
      "tfdestroy": "just destroy",
      "tfdeploy": "just deploy",
      "tfsetup": "just setup",
      "tfteardown": "just teardown",
      "tfclean": "just clean",
      "getbuckets": "just get-buckets"
    }
  }
}

To start, let’s check the list of available tasks in Just:

Now let’s try to obtain the list of buckets:

Let’s initialize the Terraform environment:

Now we can run a Terraform plan:

All good, let’s execute a deploy (apply):

The resources were successfully created in AWS:

The instance is accessible:

We have verified that the scripts and automation work; it could easily be run from a CI as well.

Now, let’s destroy the resources and clean up the environment:

devbox tfteardown

Checking the console:

Conclusions

Dependencies can become a nightmare, especially for those working with different technologies at the same time. Devbox allows us to have a clean host, with only the applications that the user truly needs installed permanently.

It also enables us to share an environment among an entire team, promotes best practices, and can be extended and automated programmatically.

In my opinion, learning to use these tools should be a fundamental chapter in the education of every computer scientist.

The Future of Work

Sergio D. Rodríguez Inclán — Sun, 06 Sep 2026 21:00:02 +0000

The Future of Work

Current Landscape

As I write this article, technology companies find themselves in a transitional phase. With the advent of artificial intelligence, the way software is produced will change, and so will the type of professionals required to build it—if this transformation hasn't already begun.

In the IT field, the most common professional roles include: architects and developers, quality assurance (QA) specialists, infrastructure engineers, database analysts, and all related variants of these specialties.

Architects and developers design and implement all product-related code.

QA specialists ensure that products meet quality requirements.

Infrastructure engineers manage company infrastructure, including servers, databases, cloud automation, and much more.

Database analysts handle databases, including schema design, data migration, and related tasks.

Obviously, there are other roles of a more administrative nature, but we won't focus on them in this analysis.

The fundamental issue is that AI is redefining how the industry creates its products, with software being the first and most significantly affected sector. Software engineers, who until recently were highly sought after for their ability to produce code and deploy it to production, performed their work in a predominantly artisanal manner. Although good practices and processes have always been followed, most existing software has been designed and programmed by human minds and hands.

Today, Large Language Models (LLMs) have surpassed previous AI models (such as BERT) and have established themselves as the most powerful tool for the software industry.

Additionally, generative AI techniques such as vibe coding, agents, and MCP (Model Context Protocol) servers, when combined, could potentially replace a considerable portion of the traditional development work that currently dominates the software industry.

Consequently, technology companies, especially the largest ones, have begun replacing traditional development engineers with AI-specialized engineers.

What's the Difference Between Traditional Development and AI-Powered Development?

Simply put, it will no longer be necessary for a developer to create an API, or for a DevOps specialist to deploy a cloud solution—an agent with those specific capabilities can do it.

How Do AI Agents Work?

AI agents are systems that combine language models (LLMs) with tools and execution capabilities. Unlike a simple chatbot, an agent can:

Reason about what actions to take
Execute tools and commands
Observe the results
Iterate until completing the task

Here's a small example flow of deployment using an AI agent.

Key System Components

LLM (Language Model): The "brain" that reasons and makes decisions
Agent: Orchestrator that coordinates between the LLM and tools
Tools: APIs, CLI commands, file access, databases, etc.
Environment: The actual system where actions are executed

Workflow

User Input: Defines the high-level task
Reasoning: The LLM analyzes which tools to use and in what order
Execution: The agent invokes the necessary tools
Observation: Receives the results of each action
Iteration: The LLM decides the next step based on results
Completion: When the task is finished, reports to the user

This cycle of Reason → Act → Observe repeats until the agent completes the task or determines it cannot continue.

The image below illustrates what I call the "tower of abstraction." As with any process, there's a natural evolution where components become progressively more specialized and their interactions become more concrete and optimized.

Consider this example: the human brain doesn't directly "know" how to make the hand grip an object. It simply decides that a situation requires gripping and sends the signal to the specialized organ—in this case, the hand muscles. In the image, we can establish the following analogy: the LLM represents the brain, transport symbolizes the nerves, and each agent corresponds to a specific hand muscle.

Similarly, in the software world, the process evolved from implementing a single monolithic module to executing specific tasks in microservices orchestrated by a controller. This controller decides which microservice should be invoked in response to an event or condition. Applying this analogy to the image, the LLM corresponds to a Control Plane, transport to networking and routes, and agents to Pods/containers.

In this evolution, the AI agent determines which tools to use and in what sequence, while the LLM decides the next step based on the obtained results.

The next step in traditional development turned out to be perhaps more unexpected than logical. This evolution in the software industry (and many others) translates into delegating development, implementation, testing, and deployment work to intelligent agents. These can perform such work continuously and with superior efficiency compared to humans, consuming fewer resources and thus leaving behind the artisanal aspect of the process.

So What Will Happen to...?

Yes, the crucial question: what fate awaits traditional engineers who, day after day, deliver task after task?

Two clear alternatives present themselves: either we let events overwhelm us and the "tsunami" buries us under tons of water, or we reinvent and adapt ourselves (once again), learning to navigate the vast sea of changes ahead.

From now on, the industry will no longer require developers who write code from start to finish, engineers who deploy complete solutions, or analysts who exhaustively review code or data structures. Instead, the industry will demand engineers capable of orchestrating agents offered by other providers, as well as creating their own agents for their business's specific use cases.

Work previously performed by teams of dozens will now be carried out by just a few, who will nevertheless produce the same amount or even more than those "small armies."

Since creating products will be much simpler, numerous startups will likely emerge that, despite having few people, will achieve significant impact and establish themselves in the market. Additionally, many new positions will be created for those who learn to interact with and improve agents.

Education must undoubtedly transform as well, especially higher education, which still trains engineers with a "classical" profile who will enter a market that no longer needs them. Higher education institutions must reform their curricula urgently!

Similarly, software companies that intend to retain their engineers must encourage them to update their skills and make this transition as smoothly as possible. As engineers, we take pride in our capabilities, but we sometimes show stubbornness and reluctance, or even disbelief, in the face of change, especially when it doesn't seem to favor us.

Where to Begin?

As a leader of an AWS User Group, one of my duties is to guide the community toward this future.

There's no more powerful tool than education. Therefore, my first recommendation would be to pursue certifications related to this topic, created and designed by the very companies leading this transition. Personally, I believe there's no better incentive to study than a certification, as the knowledge it requires is not only theoretical but also encompasses practical day-to-day mastery; consequently, those without that experience will be compelled to acquire it on their own.

The first and most important certification to begin this journey would be the "AWS Certified AI Practitioner," which covers the fundamentals: what an LLM is, what a vector database is, what an agent is, how to create effective prompts to interact with an AI agent, among other aspects. Since it's an AWS certification, it requires at least basic knowledge of many of its services and their minimum configuration. Therefore, reviewing the material for the "AWS Certified Cloud Practitioner" certification is also very beneficial; and of course, if you're motivated to obtain it, all the better.

Once you've obtained the first certification, you can begin creating AI agents and thus gradually advance in the transition.

The first option is a fully managed service called Amazon Bedrock, which integrates numerous LLMs and offers tools for creating agents, integrating models, etc. Here you can find an exhaustive list of articles related to Amazon Bedrock.

AWS also offers an open-source framework called Strands Agents, code-oriented (currently in Python) and easy to use. Its GitHub repository contains excellent examples to get started, particularly highlighting the personal assistant:

This example employs several integrated agents, such as those for information search, image search, and video search, among others; as well as a main agent responsible for answering user questions. It constitutes a very didactic example for understanding Strands' capabilities in creating agents.

Once you've acquired the necessary experience, you could pursue the "AWS Certified AI Developer Professional" certification, which, at the time of writing this article, is in beta phase. Upon obtaining this professional-level certification, you'll be able to demonstrate proficiency in developing applications with and oriented toward AI.

Although this certification, despite being professional-level, doesn't require any prerequisites for taking it, community sentiment suggests that the following are ideal certifications as preparation:

Time will tell if this is the case.

Conclusion

If there's one certainty in this life, it's that everything changes. Therefore, we must all be prepared for the changes that will inevitably come.

Personally, I've begun my own transition journey and must confess that I'm enjoying it immensely. I've always been a "Developer Wannabe" who hadn't found the time or courage to realize my aspirations. However, now I can do so without needing to invest so much time delving deeply into programming, and with the ability to create functional applications in significantly less time. I know my esteemed developer colleagues criticize vibe coding vehemently, but it's imperative to shed prejudices, relearn, and open our minds, because this change, which has already begun, won't stop, no matter who it displeases.

A Kiro Ambassador at the AWS Community Day Bolivia 2026

Sergio D. Rodríguez Inclán — Fri, 04 Sep 2026 21:07:49 +0000

What a weekend!

This past August 28th, I attended the largest AWS community event in my country: "AWS Community Day Bolivia 2026."

As a Kiro Ambassador, it is my duty and delight to showcase this wonderful tool to anyone who hasn't yet had the pleasure of working with it. Thanks to José Verbel, who pioneered the idea in Colombia of having a booth dedicated exclusively to Kiro, we replicated his idea here in Bolivia. We were very sad that he couldn't be with us that day, but we are hopeful it will happen soon somewhere in Latin America.

At our booth, my good friend Alejandro and I welcomed countless people, handing out massive amounts of swag to those who were able to log into Kiro Web, and even Kiro credits to the most daring ones who managed to beat our challenge of live-coding an application in Kiro and showcasing it to the audience. It was amazing to see the initiative and creativity of these folks. One of our winners even managed to get Kiro CLI running on his tablet! Plus, fortune smiled upon him in the raffle, and he took home a beautiful branded jacket.

A packed room for the opening keynote

Attendees scanning in at the Kiro booth

Some of the folks who stopped by to take on the challenge

Demoing Kiro CLI live at the booth

The main auditorium, packed for one of the talks

Our raffle winner with the branded jacket

Couldn't resist the swag horns

And these are some of the apps our visitors built live, from scratch, in a matter of minutes:

A countdown timer app, built live at the booth — click the thumbnail to watch

A prize wheel, complete with winner history — click the thumbnail to watch

A records intake form, built during the challenge — click the thumbnail to watch

One of our winners presenting his solution to the audience — click the thumbnail to watch

I want to note that most of the people who approached us asked: why choose Kiro over other solutions? The answer is simple: quality and accessibility.

Every serious developer or development team has an initial planning stage, where they shape their future application according to technical and business criteria; this very thing can be done with Kiro. Furthermore, Kiro guides you through this process with its innate ability to generate specifications and design using SDD (Spec-Driven-Development). From there, during implementation, you can combine a set of powerful features that Kiro brings to the table to make the user's life easier. To summarize, what surprised our visitors the most was that we weren't just talking about a regular IDE—even one with agentic capabilities—but rather a suite of interconnected products and features:

Out-of-the-box planning and requirements engineering capabilities: Spec-Driven-Development (SDD).
Working on the go, on your way to study or work from your mobile or tablet: Kiro Cloud, Kiro Mobile.
Need to incorporate Kiro's capabilities into your automation and even recover your previous work by integrating it with Kiro Cloud?: Kiro CLI.
Need to establish a clear architecture and rules that define the scope of assisted development?: Steering Documents.
Need to trigger actions in response to specific events?: Hooks.
Need to extend prompts that are recurring in your workflow?: Skills.
Need to leverage capabilities from other services?: MCP Integrations.
Need to combine all the above and package it?: Kiro Powers.
Need a platform to run dozens of tasks in parallel using swarms of agents?: KiroCrew.

With this, we clarify that it's not that other products don't offer something similar, but rather that the difference in service quality becomes apparent when you experience the speed, stability, and accuracy of the Kiro agent. It uses Amazon Bedrock under the hood (a highly proven service in the market), and on top of that, AWS engineers add optimization layers that other products lack.

Unfortunately, we couldn't attend to everyone who stopped by in the way we would have liked, but I believe we made an excellent impression on all of them.

Aside from the booth, as I mentioned earlier, I also gave a Strands Agents workshop, where we gave away more Kiro credits and swag, but that will be a story for another post.

Hands-on time during the Strands Agents workshop

A full room for the Strands Agents workshop

Walking through the agent architecture

Thanks to José for his idea and continuous collaboration in the planning, to Alejandro for helping me at the booth, and to the event organizers who made it incredible.

Let's talk

If you or your company would like to know more about Kiro, feel free to write to me at srinclan@arcamo.org, or find me on all my networks: about.me/srinclan

DevSecOps Fundamentals Project

Sergio D. Rodríguez Inclán — Fri, 20 Feb 2026 14:42:43 +0000

Introduction

Every engineer has that one project — the one that starts as a simple idea and evolves into a full-blown learning laboratory. For me, that project is this Publisher Web App: a system designed to publish announcements across multiple social media channels simultaneously. The primary use case? The AWS Certification Announcer, a community tool where members submit their AWS certification achievements and the platform automatically publishes them to Facebook, Instagram, WhatsApp, LinkedIn, Email, etc.

What began as a practical need for the AWS User Group quickly became an exercise in applying every DevSecOps principle I wanted to put into practice, but couldn't until now. This article walks through the fundamentals of the project — the architecture, the security posture, the deployment strategy, and the lessons learned along the way.

The entire project is open source and available at github.com/Walsen/devsecops-poc.

The Vision: More Than Just Posting

The goal was never to build "yet another social media scheduler." The vision was to create a platform that could serve as a reference implementation for modern cloud-native development — one that demonstrates how to build software that is secure by design, portable across deployment models, and maintainable over time.

The platform needed to:

Publish to several channels: Facebook, Instagram, WhatsApp, LinkedIn, Email, and more
Support social authentication: Google, GitHub, LinkedIn, or email/password via Amazon Cognito
Schedule messages: Queue announcements for future delivery
Enforce role-based access: Admin and Community Manager roles with strict boundaries
Be secure from day one: Zero Trust networking, encrypted everything, WAF protection, and a hardened supply chain
Run in two deployment modes: Containers (ECS Fargate) or Serverless (Lambda + DynamoDB), switchable at deploy time

Hexagonal Architecture: The Foundation

If there is one architectural decision that made everything else possible, it is the adoption of hexagonal architecture (also known as Ports & Adapters).

This pattern separates the system into three concentric zones:

Zone	Responsibility	Dependencies
Driving Adapters	Receive external input (HTTP, Kinesis events, cron)	Depend on Inbound Ports
Application Core	Business logic, use cases, domain model	Zero external dependencies
Driven Adapters	Implement outbound integrations (DB, queues, APIs)	Implement Outbound Ports

The application core — domain entities, use cases, and port interfaces — has absolutely zero knowledge of the outside world. It doesn't know if it's running on ECS or Lambda. It doesn't know if the database is PostgreSQL or DynamoDB. It only knows about abstractions.

The Domain Model

The domain is built with pure Python dataclasses:

Entity / Value Object	Description
`Message` (Aggregate Root)	Tracks content, channels, schedule, status, and per-channel deliveries
`Certification` (Entity)	AWS certification achievement with member info and type
`ChannelType` (Value Object)	Enum: `facebook`, `instagram`, `linkedin`, `whatsapp`, `email`, `sms`
`MessageStatus` (Value Object)	Lifecycle: `DRAFT` → `SCHEDULED` → `PROCESSING` → `DELIVERED` / `FAILED`
`DeliveryResult` (Value Object)	Per-channel outcome with external ID or error

Ports and Adapters in Practice

The MessageRepository port is the same interface regardless of deployment mode. Only the adapter changes:

# Port (shared across both modes)
class MessageRepository(ABC):
    @abstractmethod
    async def get_by_id(self, id: UUID) -> Message | None: ...

    @abstractmethod
    async def save(self, message: Message) -> None: ...

# Container adapter
class PostgresMessageRepository(MessageRepository):
    def __init__(self, session: AsyncSession):
        self._session = session

# Serverless adapter
class DynamoMessageRepository(MessageRepository):
    def __init__(self, table_name: str):
        self._table = boto3.resource("dynamodb").Table(table_name)

This is the key enabler for the dual-mode deployment strategy. Business logic is completely decoupled from infrastructure.

Three Services, One Stream

The platform is composed of three microservices connected by Amazon Kinesis Data Streams:

API Service: Handles HTTP requests, authentication, and message scheduling. Implements the full hexagonal stack with FastAPI routes, middleware, and Cognito JWT validation.
Worker Service: Consumes messages from Kinesis and delivers them to the appropriate channels. Supports two publishing strategies — direct API calls or AI-powered content adaptation via Amazon Bedrock.
Scheduler Service: Polls the database for scheduled messages and publishes them to Kinesis when their delivery time arrives.

Each service has its own main.py that serves as the composition root — the only place where concrete implementations are imported and wired together. No other module imports from infrastructure/ directly.

Dual-Mode Deployment: Containers or Serverless

This is where hexagonal architecture pays off in a very tangible way. The platform supports two fully independent deployment modes, switchable at deploy time via a single CI/CD parameter:

	Containers (`infra/`)	Serverless (`infra-fs/`)
Compute	ECS Fargate	Lambda
Database	PostgreSQL (RDS)	DynamoDB (Single-Table)
API Gateway	ALB + CloudFront	API Gateway + CloudFront
Scheduler	ECS Service (APScheduler)	EventBridge + Lambda
Cost (low traffic)	~$180-200/mo	~$5-15/mo

Both modes share the same domain and application layers. Only the infrastructure adapters change. The deploy workflow selects the mode via infra_type input (containers or serverless), routing to the corresponding CDK project. Stack names are fully independent, so both can coexist in the same AWS account during migration.

Why This Matters

Different stages of a project have different needs:

Stage	Recommended Mode	Reason
Development / Prototyping	Serverless	Near-zero cost, instant deploys
Staging / QA	Either	Match production or save costs
Production (steady traffic)	Containers	Predictable latency, no cold starts
Production (variable traffic)	Serverless	Pay-per-use, auto-scaling

You can start cheap with serverless and migrate to containers when traffic justifies the fixed cost — or vice versa — without rewriting a single line of business logic.

Running Both Simultaneously

Since stack names are independent, you can run both modes in parallel during a migration window. This allows smoke testing against the new mode before cutting over, gradual traffic shifting using weighted DNS routing (Route 53), and instant rollback by switching DNS back.

Zero Trust Security: Trust Nothing, Verify Everything

Security is not a feature you bolt on at the end. It is a design principle that permeates every layer of the system. The platform implements a Zero Trust architecture based on three pillars:

Network Security

All traffic flows through multiple security layers:

The VPC is segmented into public, private, and isolated subnets. Security groups enforce micro-segmentation — the ALB can only talk to the API, the API can only talk to the Worker and the database, and the database accepts connections only from authorized services.

Authentication Flow

Every request is validated against Cognito JWTs with strict algorithm restriction (RS256 only), audience and issuer validation, and JWKS caching with TTL refresh. OAuth credentials for social providers are stored in AWS Secrets Manager.

API Security Middleware

The API service implements a comprehensive security middleware stack:

Concern	Implementation
Authentication	Cognito JWT validation with algorithm restriction
CSRF Protection	Double Submit Cookie with HMAC-signed tokens
Rate Limiting	Per-user sliding window (60 req/min)
Request Validation	1MB size limit, input sanitization, HTML escaping
Security Headers	CSP, HSTS, X-Frame-Options, Permissions-Policy
Content Filtering	Prompt injection detection + PII scanning
Idempotency	Hash-based dedup on message_id + channels

Data Protection

Encryption is applied at every layer:

In Transit: TLS 1.3 everywhere — CloudFront to ALB, ALB to ECS, ECS to RDS, ECS to Kinesis
At Rest: KMS encryption for S3, RDS, and Kinesis
In Use: No PII in logs, field-level encryption for sensitive data

Secure Supply Chain

The build pipeline is hardened against supply chain attacks with multiple security gates:

Defense in Depth: Multiple Scanners

No single scanner catches everything. The project uses six complementary tools:

Scanner	Type	Purpose
Semgrep	SAST	OWASP Top 10 patterns, custom rules
Bandit	SAST	Python-specific security issues
pip-audit	SCA	Python CVE database (PyPI Advisory)
Trivy	SCA	SBOM vulnerability scanning
Gitleaks	Secrets	Hardcoded secrets detection in git history
Checkov	IaC	AWS security misconfigurations in CDK/CloudFormation

Each tool covers blind spots the others miss. Semgrep catches SQL injection and XSS patterns. Bandit finds Python-specific issues like unsafe YAML loading. pip-audit and Trivy handle known CVEs. Gitleaks prevents credential leaks. Checkov ensures the infrastructure itself is secure — no public S3 buckets, no missing encryption, no overly permissive IAM.

Container Security

Production containers are built with security as a first-class concern:

Distroless base images: No shell, minimal attack surface
Non-root user: Containers run as nonroot by default
Read-only filesystem: No writes to the root filesystem
Pinned dependencies: Lock files with hashes for reproducibility
Resource limits: CPU and memory constraints to prevent abuse

CI/CD with GitHub Actions OIDC

The project uses GitHub Actions OIDC to assume AWS IAM roles without storing long-lived credentials. A CDK bootstrap stack (GitHubOIDCStack) creates the OIDC provider and two IAM roles:

Deploy Role (github-actions-deploy): For CDK deployments and ECR pushes
Security Scan Role (github-actions-security-scan): For Prowler audits with read-only access

No AWS access keys are stored in GitHub Secrets. Every deployment uses short-lived credentials (1 hour) obtained via OIDC federation.

The Golden Thread: Distributed Security Tracing

One of the most interesting aspects of the project is the Golden Thread — a distributed tracing exercise that demonstrates end-to-end request correlation across all infrastructure layers using a single correlation ID (X-Request-ID).

The correlation ID flows through:

Edge Layer: WAF logs (CloudFront + ALB)
Application Layer: API structured logs (structlog JSON)
Async Layer: Kinesis event → Worker logs
Database Layer: PostgreSQL audit logs (pgaudit) with SQL comments

/* correlation_id=golden-thread-test-1739... */ INSERT INTO messages (id, content_text, ...) VALUES (...)

All queryable from CloudWatch Logs Insights with a single filter:

fields @timestamp, service, event, correlation_id, method, path, status_code
| filter correlation_id = "YOUR_TRACE_ID"
| sort @timestamp asc

Attack Simulation Exercises

The project includes hands-on exercises that simulate real attacks and trace them across layers:

SQL Injection: Send a ' OR 1=1-- payload, verify WAF blocks it, confirm the request never reaches the application
XSS Attempts: Send <script>alert(1)</script>, trace the WAF block in CloudWatch
Brute Force Detection: Send 60 rapid requests, observe rate limiting kick in, check CloudWatch alarms
Full Pipeline Trace: Schedule a message with a known correlation ID, trace it from CloudFront WAF → ALB WAF → API → Kinesis → Worker → PostgreSQL

The documentation also includes exercises using professional penetration testing tools — nmap, nikto, sqlmap, ffuf, nuclei, and hydra — each with corresponding CloudWatch queries to trace the attack signatures across the infrastructure.

AI-Powered Content Adaptation

The Worker service supports two publishing strategies, selectable via configuration:

The AgentPublisher uses the Strands Agents SDK with Amazon Bedrock (Claude) to intelligently adapt content for each platform:

Platform	Adaptation
Facebook	Longer posts, emojis, hashtags at end
Instagram	Visual focus, heavy emojis, hashtags
LinkedIn	Professional tone, formal language
WhatsApp	Short, celebratory, personal

The agent reasons about which tools to call, executes them, observes results, and continues until the task is complete. Content filtering middleware protects against prompt injection and PII leakage in AI-generated output.

AI-Powered Security Testing Agent

Perhaps the most novel addition to the project is the Security Testing Agent — an AI-powered interactive penetration testing assistant built with the Strands Agents SDK and Amazon Bedrock. Instead of manually running security tests and interpreting results, you have a conversation with an agent that can run tests, diagnose failures, query AWS resources, and even auto-fix test code.

The interaction looks like this:

🔒 Penetration Testing Agent Ready!

You: Run all fast tests
Agent: I'll run the fast test suite in parallel, skipping slow scans...
       ✅ All tests passed in 8 seconds!

You: The TLS test is failing, can you debug it?
Agent: Let me run the TLS test and check the logs...
       [runs test, queries CloudFormation for endpoints, checks CloudWatch]
       The certificate for api.ugcbba.click expired. Here's what I found...

Strict Guardrails

The agent enforces strict security boundaries:

Can only run tests from a hardcoded allowlist — no arbitrary command execution
AWS access is read-only — cannot create, modify, or delete any resources
File access is sandboxed to the testing/ directory — path traversal is blocked
Refuses tasks unrelated to penetration testing

The Test Suite

The agent wraps a comprehensive pytest-based security test suite running inside a Kali Linux container:

Category	Tests	Duration
Fast (< 10s each)	Health, security headers, TLS, CORS, cookies, error disclosure, HTTP methods, origin access, SQLi, XSS	~10s total
Medium (15-30s)	Rate limiting, CSRF end-to-end, IDOR protection	~1 min
Slow (30s-10min)	nmap port scan, Nikto web scan, sqlmap automated injection	~15 min

The agent is smart about which tests to run — it prioritizes recently failed tests, skips slow scans unless explicitly requested, and caches successful results for 5 minutes to avoid redundant runs. Parallel execution via pytest-xdist makes the full fast suite complete in about 8 seconds.

Automated Penetration Testing Framework

Beyond the AI agent, the project includes a standalone automated penetration testing framework using Dockerized Kali Linux. This is the foundation that the agent builds on, but it can also be used independently in CI/CD pipelines.

# Build the Kali container
docker build -f testing/Dockerfile.kali -t pentest:latest testing/

# Quick smoke test
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest smoke

# Full test suite
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest all

# Generate report
docker run --rm -v $(pwd):/tests -e TARGET_URL=$TARGET_URL pentest report

The framework integrates with GitHub Actions for scheduled weekly scans and on-demand testing, with results uploaded as workflow artifacts.

Threat Detection and Incident Response

The platform implements automated threat detection and response:

GuardDuty monitors for threats. When a finding with severity >= 4 is detected, an EventBridge rule triggers a Lambda function that automatically blocks the offending IP in the WAF IP set and sends a detailed alert to Slack. Security Hub aggregates findings from GuardDuty, CloudTrail, and AWS Config rules for a unified compliance view.

Security Observability

CloudWatch dashboards and alarms provide real-time visibility:

Metric	Threshold	Action
Auth failures (5min)	>= 20	Alarm + SNS
CSRF failures (5min)	>= 20	Alarm + SNS
Access denied (5min)	>= 30	Alarm + SNS
Rate limit hits (5min)	>= 100	Alarm + SNS
Error rate (5min)	>= 10	Alarm + SNS
Critical errors (1min)	>= 1	Alarm + SNS
API latency p95	> 1000ms	Alarm + SNS

The Developer Experience

A good DevSecOps project is not just about security and architecture — it is also about making the developer's life easier. The project uses Devbox for isolated development environments and Just as a task runner.

The justfile provides a comprehensive set of commands:

# Development
just dev          # Start local services and tail logs
just up           # Start PostgreSQL + LocalStack
just test         # Run all tests
just lint-local   # Lint all services locally

# Security
just security-scan    # SAST + SCA + Secrets scan
just trivy-scan       # Container vulnerability scan
just sbom-scan        # Generate and scan SBOMs
just iac-scan         # Infrastructure scan with Checkov
just pentest-full     # Run the full penetration test suite

# AWS Resource Management (Cost Saving)
just aws-up       # Scale up ECS services + start RDS
just aws-down     # Scale down to zero (save money)
just aws-status   # Check resource status

The aws-up and aws-down commands are particularly useful — they allow scaling the entire infrastructure to zero when not in use, saving significant costs during development.

Project Structure

The codebase is organized for clarity and separation of concerns:

.
├── api/                    # API service (FastAPI + hexagonal)
│   ├── src/
│   │   ├── domain/         # Business entities, value objects
│   │   ├── application/    # Use cases, ports, DTOs
│   │   ├── infrastructure/ # Adapters (DB, Kinesis, Secrets)
│   │   └── presentation/   # HTTP routes, middleware
│   └── tests/
│
├── worker/                 # Worker service (Kinesis consumer)
│   ├── src/
│   │   ├── domain/         # Ports for channels, publishers
│   │   ├── application/    # Delivery service
│   │   ├── infrastructure/ # Publisher adapters (Direct, AI Agent)
│   │   └── channels/       # Channel gateways (FB, IG, LI, Email, SMS)
│   └── tests/
│
├── scheduler/              # Scheduler service (cron + ECS)
├── api-lambda/             # API Lambda handler (serverless)
├── worker-lambda/          # Worker Lambda handler (serverless)
├── scheduler-lambda/       # Scheduler Lambda handler (serverless)
├── web/                    # Frontend (React + Vite + TypeScript)
│
├── testing/                # Penetration testing framework
│   ├── pentest_agent.py    # AI security testing agent (Strands SDK)
│   ├── test_pentest.py     # Security test cases (pytest)
│   ├── Dockerfile.kali     # Kali Linux container with tools
│   └── justfile            # Pentest task runner
│
├── infra/                  # CDK infrastructure (containers)
│   └── stacks/             # Network, Security, Auth, Data, Compute, Edge, Monitoring
│
├── infra-fs/               # CDK infrastructure (serverless)
│   └── stacks/             # Data, Auth, API, Worker, Scheduler, Security, Frontend
│
├── docs/                   # Comprehensive documentation
├── .github/workflows/      # CI/CD (deploy + security scan)
├── devbox.json             # Development environment
├── docker-compose.yml      # Local services
└── justfile                # Task runner

Lessons Learned

Building this project reinforced several convictions:

Hexagonal architecture is not academic overhead. It is the single decision that enabled dual-mode deployment, clean testing, and a codebase that remains navigable as it grows. The upfront investment in defining ports and adapters pays for itself many times over.

Security scanning must be layered. No single tool catches everything. The combination of SAST, SCA, secrets scanning, IaC scanning, and DAST provides genuine defense in depth. The key is making these scans fast and automatic — if they slow down the developer, they will be bypassed.

Correlation IDs are non-negotiable. The ability to trace a single request from CloudFront through the API, into Kinesis, through the Worker, and into the database is invaluable for debugging, incident response, and security forensics. Implement them from day one.

Cost management is a feature. The aws-up / aws-down pattern for scaling resources to zero when not in use is simple but effective. For a project like this, it is the difference between a $200/month bill and a $5/month bill during development.

AI agents need guardrails. The Strands Agents integration is powerful, but without content filtering, prompt injection detection, and output validation, it is a liability. The agent can only execute pre-approved operations through well-defined tool interfaces — never raw API calls. The same principle applies to the Security Testing Agent: it operates within a strict allowlist of tests and read-only AWS access, proving that AI-powered automation and security boundaries can coexist.

Conclusion

This project is a living laboratory. It is not finished, and it probably never will be — because the landscape of threats, tools, and best practices is always evolving. But it serves its purpose: a concrete, open-source reference for how to build modern cloud-native applications with security woven into every layer.

If you are starting a new project and wondering where to begin with DevSecOps, my advice is simple: start with the architecture. Get hexagonal architecture right, define your ports and adapters, and the rest — security, testing, deployment flexibility — becomes dramatically easier.

The code is open source. Fork it, break it, improve it. That is what it is there for.

An Incredible Operations Platform - Rundeck

Sergio D. Rodríguez Inclán — Sun, 01 Feb 2026 19:56:51 +0000

Introduction

There's a moment every operations engineer knows well: it's 2 AM, something's broken, and you're frantically SSH-ing into servers trying to remember the exact sequence of commands to fix it. You've done this before, but was it systemctl restart first or the config update? And which servers exactly?

This is the problem Rundeck solves. It's an open-source runbook automation platform that lets you define, schedule, and execute operational procedures across your entire infrastructure—with proper access control, audit trails, and the peace of mind that comes from knowing the procedure will run exactly the same way every time.

I've been using Rundeck for years, and recently I decided to contribute back to the ecosystem by creating three tools that solve specific pain points I encountered: a production-ready Docker image, a plugin for copying files between nodes, and a GitHub Action for seamless CI/CD integration. Let me walk you through all of them.

What Makes Rundeck Special

Rundeck occupies a unique space in the DevOps toolchain. It's not a configuration management tool like Ansible or Puppet—though it integrates beautifully with them. It's not a CI/CD platform like Jenkins—though it can trigger and be triggered by pipelines. Rundeck is specifically designed for operational workflows.

Core Capabilities

Job Definitions: Create multi-step workflows with conditionals, error handling, and node targeting
Node Management: Maintain a centralized inventory of your infrastructure with custom attributes
Access Control: Fine-grained RBAC so developers can restart their services without full SSH access
Key Storage: Secure credential management for SSH keys, passwords, and API tokens
Execution History: Complete audit trail of who ran what, when, and with what results
Scheduling: Cron-like scheduling for recurring maintenance tasks
REST API: Full API for integration with CI/CD pipelines, monitoring systems, and AI agents

Where It Shines

In my experience, Rundeck excels at:

Incident Response: Pre-built runbooks that on-call engineers can execute confidently
Self-Service Operations: Let developers restart services or clear caches without ops tickets
Coordinated Procedures: Multi-node operations that need to happen in a specific order
Compliance Tasks: Scheduled security scans, backup verifications, audit reports
Deployment Orchestration: Coordinate deployments across environments with approval gates

REST API: Automation Beyond the UI

One of Rundeck's most powerful features is its comprehensive REST API. Every action you can perform in the web interface is available programmatically, making Rundeck a perfect backend for automated operations.

API Capabilities

The API supports:

Job execution: Trigger jobs with custom parameters
Execution monitoring: Check status, stream logs, abort running jobs
Job management: Create, update, delete, import/export job definitions
Node inventory: Query and manage node sources
Key storage: Programmatic credential management
System info: Health checks, metrics, cluster status

Authentication

Rundeck supports multiple authentication methods for API access:

# Using API Token (recommended)
curl -H "X-Rundeck-Auth-Token: YOUR_TOKEN" \
  https://rundeck.example.com/api/41/projects

# Using session cookie
curl -c cookies.txt -b cookies.txt \
  -d "j_username=admin&j_password=admin" \
  https://rundeck.example.com/j_security_check

Triggering Jobs Programmatically

# Run a job by ID
curl -X POST \
  -H "X-Rundeck-Auth-Token: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"options": {"environment": "production", "version": "1.2.3"}}' \
  https://rundeck.example.com/api/41/job/JOB_ID/run

# Response includes execution ID for monitoring
{
  "id": 12345,
  "href": "https://rundeck.example.com/api/41/execution/12345",
  "status": "running"
}

Integration Scenarios

CI/CD Pipelines

Trigger deployment jobs from Jenkins, GitHub Actions, or GitLab CI. I created a dedicated GitHub Action to make this integration even easier: rundeck-github-action.

# Using the Rundeck GitHub Action
- name: Deploy via Rundeck
  uses: Walsen/rundeck-github-action@v1
  with:
    rundeck_url: https://rundeck.example.com
    rundeck_token: ${{ secrets.RUNDECK_TOKEN }}
    action: run_job
    job_id: ${{ vars.DEPLOY_JOB_ID }}
    job_options: '{"version": "${{ github.sha }}", "environment": "production"}'
    wait_for_completion: true
    timeout: 600

The action supports multiple operations:

Action	Description
`run_job`	Execute a Rundeck job with options
`get_job_info`	Get job details
`list_jobs`	List jobs in a project
`get_execution`	Get execution details
`list_executions`	List executions for a job or project
`abort_execution`	Abort a running execution

You can also wait for job completion and get the execution status:

- name: Run deployment and wait
  id: deploy
  uses: Walsen/rundeck-github-action@v1
  with:
    rundeck_url: https://rundeck.example.com
    rundeck_token: ${{ secrets.RUNDECK_TOKEN }}
    action: run_job
    job_id: ${{ vars.DEPLOY_JOB_ID }}
    wait_for_completion: true

- name: Check result
  run: |
    echo "Status: ${{ steps.deploy.outputs.execution_status }}"
    echo "URL: ${{ steps.deploy.outputs.execution_url }}"

Monitoring Integration

Have your monitoring system trigger remediation jobs automatically:

# PagerDuty webhook handler example
def handle_alert(alert):
    if alert['type'] == 'high_memory':
        requests.post(
            f"{RUNDECK_URL}/api/41/job/{CLEAR_CACHE_JOB}/run",
            headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN},
            json={"options": {"server": alert['hostname']}}
        )

AI Agents and LLM Integration

This is where things get interesting. Rundeck's API makes it an ideal execution backend for AI-powered operations. Using the Strands Agents SDK from AWS, you can build intelligent agents that leverage Rundeck as their operational backbone.

First, install the dependencies:

pip install strands-agents strands-agents-tools requests

Create a custom Rundeck tool for your agent:

from strands import Agent, tool
import requests

RUNDECK_URL = "https://rundeck.example.com"
RUNDECK_TOKEN = "your-api-token"

@tool
def list_rundeck_jobs(project: str) -> dict:
    """List available runbooks in a Rundeck project.

    Args:
        project: The Rundeck project name

    Returns:
        List of available jobs with their IDs and descriptions
    """
    response = requests.get(
        f"{RUNDECK_URL}/api/41/project/{project}/jobs",
        headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN}
    )
    return response.json()

@tool
def run_rundeck_job(job_id: str, options: dict = None) -> dict:
    """Execute a Rundeck job/runbook.

    Args:
        job_id: The UUID of the job to execute
        options: Optional parameters for the job

    Returns:
        Execution details including status and execution ID
    """
    response = requests.post(
        f"{RUNDECK_URL}/api/41/job/{job_id}/run",
        headers={
            "X-Rundeck-Auth-Token": RUNDECK_TOKEN,
            "Content-Type": "application/json"
        },
        json={"options": options or {}}
    )
    return response.json()

@tool
def get_execution_status(execution_id: int) -> dict:
    """Check the status of a Rundeck job execution.

    Args:
        execution_id: The execution ID to check

    Returns:
        Execution status and details
    """
    response = requests.get(
        f"{RUNDECK_URL}/api/41/execution/{execution_id}",
        headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN}
    )
    return response.json()

# Create the operations agent
ops_agent = Agent(
    system_prompt="""You are an operations assistant with access to Rundeck runbooks.
    When asked to perform operational tasks:
    1. List available jobs to find the appropriate runbook
    2. Execute the job with the correct parameters
    3. Monitor the execution and report the results
    Always confirm before executing destructive operations.""",
    tools=[list_rundeck_jobs, run_rundeck_job, get_execution_status]
)

# Example interaction
response = ops_agent("The app servers are running low on disk space. \
    Can you clear the log files on the production cluster?")
print(response)

This pattern keeps humans in control—the AI can only execute pre-approved runbooks with proper access controls and audit trails. It's autonomous operations with guardrails. The agent can reason about which runbook to use, execute it, and report back the results, all while respecting Rundeck's RBAC policies.

Low-Code Integration with n8n

If you prefer a visual approach to automation, n8n offers native Rundeck integration. You can build workflows that connect GitHub events to Rundeck job executions without writing code.

The n8n Rundeck node supports:

Execute: Trigger any Rundeck job with parameters
Get Metadata: Retrieve job definitions and status

Combined with n8n's 400+ integrations, you can create powerful automation chains—for example, triggering a deployment job when a GitHub release is published, then notifying your team on Slack when it completes.

Licensing: Open Source vs Enterprise

Rundeck follows an open-core model. The community edition is fully open source under the Apache 2.0 license, while PagerDuty (who acquired Rundeck) offers commercial versions with additional features.

Rundeck Community (Open Source)

Free forever, includes:

Workflow execution and job definitions
Node management and key storage
Access control (ACL-based)
Scheduling and job activity logs
Community plugins
REST API

This is what my Docker image uses—perfect for small to medium teams and learning environments.

PagerDuty Runbook Automation (Commercial)

The enterprise offerings add:

Feature	Description
High Availability	Clustered deployments with auto-takeover
SSO Integration	SAML, LDAP, OAuth support
Enterprise Plugins	ServiceNow, PagerDuty, Datadog, VMware integrations
Advanced Scheduling	Blackout calendars, schedule forecasting
Failed Job Resume	Resume from the failed step instead of restarting
Enterprise Support	SLA-backed support and account management

PagerDuty offers two commercial options:

Runbook Automation Self-Hosted: You manage the infrastructure, they provide the enterprise features
Runbook Automation (Cloud): Fully managed SaaS with 99.9% SLA

Which Should You Choose?

For most use cases, start with the open source version. It's production-ready and covers the core functionality. Consider upgrading when you need:

High availability for mission-critical operations
SSO integration with your identity provider
Enterprise integrations (ServiceNow tickets, PagerDuty incidents)
Professional support with SLAs

The open source version isn't a "lite" version—it's a complete operations platform that many organizations run successfully in production.

The Gap: Node-to-Node File Transfers

While building a configuration distribution workflow, I hit a limitation. Rundeck's built-in file copier moves files from the Rundeck server to target nodes. But I needed to copy files from one node to multiple other nodes—specifically, distributing generated configs from a central server to application nodes.

The workaround was clunky: download to Rundeck, then upload to each destination. For large files or many destinations, this becomes a bottleneck.

So I built a plugin.

Rundeck Node-to-Node Plugin

The rundeck-node-to-node plugin adds a workflow step that copies files and directories between nodes using SSH/SFTP, fully integrated with Rundeck's node definitions and key storage.

Features

Two Transfer Modes: Route through Rundeck (reliable) or direct node-to-node (fast)
Parallel Transfers: Copy to multiple destinations simultaneously
Directory Support: Recursive copy with preserved permissions and timestamps
Key Storage Integration: Uses Rundeck's secure credential management
Error Handling: Option to continue on partial failures

Transfer Modes Explained

Via-Rundeck (Default)

Files download to Rundeck once, then upload to all destinations. Works in any network topology.

Direct Mode

Source pushes directly to destinations via SCP. Faster, but requires source-to-destination SSH access.

Node Configuration

The plugin uses Rundeck's standard node attributes:

config-server:
  hostname: 10.0.1.10
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: config

app-server-01:
  hostname: 10.0.1.20
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: app,production

app-server-02:
  hostname: 10.0.1.21
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: app,production

Plugin Options

Option	Required	Default	Description
Source Node	Yes	-	Node name where files originate
Source Path	Yes	-	File or directory path on source
Destination Nodes	Yes	-	Comma-separated destination node names
Destination Path	Yes	-	Target path on destinations
Recursive Copy	No	true	Copy directories recursively
Preserve Attributes	No	true	Keep timestamps and permissions
Transfer Mode	No	via-rundeck	`via-rundeck` or `direct`
Parallel Transfers	No	true	Transfer to multiple nodes in parallel
Continue on Error	No	false	Don't fail if some destinations fail

Installation

Download the JAR from Releases
Copy to Rundeck's libext directory
Restart Rundeck (or wait for auto-reload)

The plugin appears as a new workflow step type: "Node to Node File Copy".

Production-Ready Docker Image

Installing Rundeck traditionally means dealing with Java, databases, reverse proxies, and process management. To streamline this, I created a Docker image that bundles everything for production use.

The rundeck-image provides:

Rundeck 5.18.0 (configurable version)
Nginx reverse proxy for proper HTTP handling
Supervisor for process management
PostgreSQL support for production databases
Node-to-Node plugin pre-installed

Architecture

Quick Start

docker run -d \
  -p 8080:8080 \
  -e RUNDECK_GRAILS_URL=http://localhost:8080 \
  ghcr.io/walsen/rundeck-image:latest

Access Rundeck at http://localhost:8080.

Production Setup with Docker Compose

version: '3.8'

services:
  rundeck:
    image: ghcr.io/walsen/rundeck-image:latest
    ports:
      - "8080:8080"
    environment:
      RUNDECK_GRAILS_URL: https://rundeck.example.com
      RUNDECK_DATABASE_URL: jdbc:postgresql://db:5432/rundeck
      RUNDECK_DATABASE_USERNAME: rundeck
      RUNDECK_DATABASE_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./config/realm.properties:/etc/rundeck/realm.properties
      - rundeck-data:/var/rundeck
    depends_on:
      - db

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: rundeck
      POSTGRES_USER: rundeck
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  rundeck-data:
  postgres-data:

Environment Variables

Variable	Default	Description
`RUNDECK_GRAILS_URL`	`http://localhost:8080`	External URL (must match your setup)
`RUNDECK_DATABASE_URL`	-	PostgreSQL JDBC connection string
`RUNDECK_DATABASE_USERNAME`	-	Database user
`RUNDECK_DATABASE_PASSWORD`	-	Database password

User Authentication

Mount a realm.properties file for basic authentication:

# username:password,role1,role2
admin:admin,user,admin
operator:operator123,user
readonly:viewer456,user

For production, integrate with LDAP or SSO—Rundeck supports both.

Custom Port Mapping

The image handles any external port. Just match RUNDECK_GRAILS_URL:

# Running on port 4440
docker run -d \
  -p 4440:8080 \
  -e RUNDECK_GRAILS_URL=http://localhost:4440 \
  ghcr.io/walsen/rundeck-image:latest

Practical Example: Config Distribution Workflow

Let me show how these tools work together in a real scenario.

The Setup:

1 config server generates environment-specific configuration files
5 application servers need these configs
Updates should happen without manual intervention

The Workflow:

Job Configuration:

Step	Node(s)	Action
1	config-server	`/opt/scripts/generate-config.sh`
2	config-server → app-01..05	Node-to-Node copy `/etc/myapp/config.yml`
3	app-01..05 (sequential)	`systemctl reload myapp`

The Result:

One-click config updates
Parallel distribution to all servers
Rolling reload to avoid downtime
Complete audit trail
Anyone with permissions can run it

Testing the Plugin

The plugin repository includes a Docker-based test environment:

cd test/
docker-compose up -d

This spins up:

A Rundeck instance with the plugin
Multiple test nodes for source/destination testing
Pre-configured SSH keys

See test/README.md for detailed testing instructions.

CI/CD Integration

Both repositories include GitHub Actions workflows:

rundeck-image:

Builds on every push to main
Publishes to GitHub Container Registry
Tags releases with version numbers

rundeck-node-to-node:

Builds and tests the plugin
Creates release artifacts
Publishes JAR files to GitHub Releases

Deploying Rundeck on AWS

If you're running on AWS, you have several options for deploying Rundeck. Here's my recommendation based on cost and operational effort:

Best Option: Amazon ECS on Fargate

For most teams, ECS Fargate hits the sweet spot between cost and operational simplicity:

Factor	ECS Fargate
Operational Effort	Low - no EC2 instances to manage
Cost	~$30-50/month for small workloads
Scaling	Easy horizontal scaling
Integration	Native ALB, Secrets Manager, CloudWatch
Persistence	EFS for Rundeck data, RDS for database

Budget Option: ECS with PostgreSQL Sidecar

For cost-conscious deployments, you can run PostgreSQL as a sidecar container instead of using RDS. This cuts costs significantly while maintaining a containerized approach:

Factor	With RDS	With PostgreSQL Sidecar
Monthly Cost	$50-80	$20-35
Database Backups	Automatic	Manual (EFS snapshots)
High Availability	RDS Multi-AZ option	Single container
Complexity	Two services	Single task

For most Rundeck deployments, the sidecar approach works great—Rundeck isn't a high-transaction workload, and EFS provides durability for your data.

Comparison of AWS Options

Option	Monthly Cost	Ops Effort	Best For
EC2 (t3.small)	$15-20	Medium	Budget-conscious, 24/7 workloads
EC2 Spot	$5-10	Medium	Dev/test, can tolerate interruptions
Lightsail	$5-20	Low	Learning, simple setups
ECS Fargate	$30-50	Low	Production, low maintenance
EKS	$100+	High	Already running Kubernetes

Why Not the Others?

EC2: More operational overhead (patching, monitoring), but cheaper for 24/7 workloads with Reserved Instances
EKS: Overkill unless you already have a Kubernetes cluster—adds complexity and ~$70/month just for the control plane
App Runner: Simpler but limited networking control, harder to reach private infrastructure
Lightsail: Cheapest option but limited VPC integration for node access

My Recommendations

Small team/learning: EC2 t3.small or Lightsail (~$10-20/month)
Production with low ops effort: ECS Fargate + RDS (~$50-80/month)
Enterprise/HA: ECS Fargate multi-task + RDS Multi-AZ (~$150+/month)

ECS Task Definition Example

{
  "family": "rundeck",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "rundeck",
      "image": "ghcr.io/walsen/rundeck-image:latest",
      "portMappings": [
        {"containerPort": 8080, "protocol": "tcp"}
      ],
      "environment": [
        {"name": "RUNDECK_GRAILS_URL", "value": "https://rundeck.example.com"}
      ],
      "secrets": [
        {"name": "RUNDECK_DATABASE_URL", "valueFrom": "arn:aws:secretsmanager:..."},
        {"name": "RUNDECK_DATABASE_PASSWORD", "valueFrom": "arn:aws:secretsmanager:..."}
      ],
      "mountPoints": [
        {"sourceVolume": "rundeck-data", "containerPath": "/var/rundeck"}
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/rundeck",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "rundeck-data",
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-xxxxxxxx",
        "transitEncryption": "ENABLED"
      }
    }
  ]
}

This setup gives you a production-ready Rundeck deployment with persistent storage, secrets management, and centralized logging—all with minimal operational overhead.

Conclusions

Rundeck transforms operational chaos into repeatable, auditable procedures. It's the tool I reach for when I need to bridge the gap between "we should automate this" and "we have time to build proper automation."

The Node-to-Node plugin fills a specific gap—efficient file distribution between nodes without routing everything through Rundeck. And the Docker image removes the friction of getting a production-ready Rundeck instance running.

If you're drowning in operational toil, give Rundeck a try. And if you need these specific capabilities, the tools are ready for you.

GitHub Action to Publish Hugo Posts to Dev.to

Sergio D. Rodríguez Inclán — Mon, 26 Jan 2026 04:01:50 +0000

Introduction

As developers who maintain technical blogs, we often face a common dilemma: should we publish exclusively on our own site, or should we cross-post to platforms like Dev.to, Medium, or Hashnode to reach a wider audience?

The answer is usually "both," but that creates a new problem: manual cross-posting is tedious, error-prone, and time-consuming. You write a post in Hugo, publish it to your site, then manually copy-paste the content to Dev.to, adjust the formatting, add tags, set the canonical URL, and hope you didn't miss anything.

I experienced this friction firsthand with my Hugo-powered blog at blog.walsen.website. After publishing several posts and manually cross-posting them to Dev.to, I realized this workflow was unsustainable. There had to be a better way.

That's when I decided to build hugo2devto: a GitHub Action that automatically publishes Hugo blog posts to Dev.to with full frontmatter support, canonical URLs, and zero manual intervention.

The Problem: Cross-Posting is Painful

Let me paint a picture of the traditional workflow:

Write your post in Hugo with YAML frontmatter
Build and deploy your Hugo site
Open Dev.to in your browser
Copy-paste your markdown content
Manually configure:
- Title
- Tags (max 4)
- Cover image
- Canonical URL
- Published/draft status
- Series information
Preview and publish
Repeat for every post update

This process has several problems:

Time-consuming: 10-15 minutes per post
Error-prone: Easy to forget canonical URLs or tags
Not scalable: Discourages cross-posting
No version control: Changes aren't tracked
Manual synchronization: Updates require repeating the entire process

The Solution: Automation Through GitHub Actions

The ideal solution would:

Detect when a Hugo post is created or updated
Automatically extract frontmatter metadata
Publish or update the post on Dev.to
Set the correct canonical URL
Handle tags, cover images, and series
Work seamlessly with existing Hugo workflows

This is exactly what hugo2devto does.

Building the Action: Technical Deep Dive

Architecture Overview

The action is built with TypeScript and runs on Node.js 20. Here's the high-level architecture:

Key Features

1. Full Hugo Frontmatter Support

The action understands Hugo's frontmatter format natively:

---
title: "My Awesome Post"
description: "A deep dive into something cool"
publishdate: 2026-01-25T22:23:37-04:00
draft: false
tags: ["hugo", "devto", "automation"]
series: "Hugo Automation"
eyecatch: "https://example.com/cover.png"
---

It automatically maps these fields to Dev.to's API format:

title → title
description → description
tags → tags (limited to 4)
series → series
eyecatch / cover_image → main_image
draft → published (inverted)

2. Automatic Canonical URL Generation

One of the most important SEO considerations when cross-posting is setting the canonical URL to point back to your original post. The action automatically generates this:

const canonicalUrl = `${baseUrl}/${language}/posts/${slug}/`

For example, a post at content/en/posts/my-post.md becomes:

https://blog.walsen.website/en/posts/my-post/

3. Multi-Language Support

The action detects the language from the file path:

content/en/posts/my-post.md  → English
content/es/posts/mi-post.md  → Spanish

This is crucial for Hugo sites with i18n support.

4. Mermaid Diagram Support (v1.1.0)

Hugo uses shortcodes for mermaid diagrams, but Dev.to doesn't support mermaid natively. The action automatically converts Hugo mermaid shortcodes to rendered PNG images using the mermaid.ink service:

<!-- Hugo format (in your source) -->
{{</* mermaid */>}}
flowchart TD
    A --> B
{{</* /mermaid */>}}

<!-- Converted to (on Dev.to) -->
![Mermaid Diagram](https://mermaid.ink/img/base64encodeddiagram)

This means your diagrams render beautifully on both platforms without any manual intervention.

5. Idempotent Updates

The action checks if an article already exists on Dev.to (by canonical URL) and updates it instead of creating a duplicate. This means you can run the action multiple times safely.

Implementation Highlights

Here's a simplified version of the core logic:

// Read and parse the markdown file
const fileContent = fs.readFileSync(filePath, 'utf-8');
const { data: frontmatter, content } = matter(fileContent);

// Extract metadata
const title = frontmatter.title;
const description = frontmatter.description || '';
const tags = (frontmatter.tags || []).slice(0, 4); // Dev.to limit
const published = !frontmatter.draft;

// Generate canonical URL
const slug = path.basename(filePath, '.md')
  .toLowerCase()
  .replace(/\s+/g, '-');
const language = filePath.includes('/en/') ? 'en' : 'es';
const canonicalUrl = `${baseUrl}/${language}/posts/${slug}/`;

// Prepare Dev.to article
const article = {
  title,
  body_markdown: content,
  published,
  tags,
  canonical_url: canonicalUrl,
  main_image: frontmatter.eyecatch || frontmatter.cover_image,
  series: frontmatter.series,
  description
};

// Check if article exists
const existingArticle = await findArticleByCanonicalUrl(canonicalUrl);

if (existingArticle) {
  // Update existing article
  await updateArticle(existingArticle.id, article);
} else {
  // Create new article
  await createArticle(article);
}

Using the Action: Practical Examples

Basic Setup

First, get your Dev.to API key from https://dev.to/settings/extensions and add it to your repository secrets as DEVTO_API_KEY.

Then create .github/workflows/publish-devto.yml:

name: Publish to Dev.to

on:
  push:
    branches: [main]
    paths:
      - 'content/*/posts/*.md'

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: 'content/en/posts/my-post.md'
          base-url: 'https://blog.walsen.website'

Advanced: Automatic Detection of Changed Posts

For my blog, I wanted the action to automatically detect which posts changed and publish only those:

name: Publish to Dev.to

on:
  push:
    branches: [main]
    paths:
      - 'content/*/posts/*.md'

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      posts: ${{ steps.changed-files.outputs.posts }}
      has-changes: ${{ steps.changed-files.outputs.has-changes }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2

      - name: Get changed files
        id: changed-files
        run: |
          CHANGED_FILES=$(git diff --name-only HEAD^ HEAD | grep -E 'content/en/posts/.*\.md' || echo "")

          if [ -n "$CHANGED_FILES" ]; then
            POSTS_JSON=$(echo "$CHANGED_FILES" | jq -R -s -c 'split("\n") | map(select(length > 0))')
            echo "posts=$POSTS_JSON" >> $GITHUB_OUTPUT
            echo "has-changes=true" >> $GITHUB_OUTPUT
          else
            echo "posts=[]" >> $GITHUB_OUTPUT
            echo "has-changes=false" >> $GITHUB_OUTPUT
          fi

  publish-changed:
    if: needs.detect-changes.outputs.has-changes == 'true'
    needs: detect-changes
    runs-on: ubuntu-latest
    strategy:
      matrix:
        post: ${{ fromJson(needs.detect-changes.outputs.posts) }}
      fail-fast: false
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: ${{ matrix.post }}
          base-url: 'https://blog.walsen.website'

This workflow:

Detects which markdown files changed in the last commit
Converts them to a JSON array
Uses a matrix strategy to publish multiple posts in parallel
Sets fail-fast: false so one failure doesn't stop others

Manual Trigger

You can also trigger publishing manually:

on:
  workflow_dispatch:
    inputs:
      post_path:
        description: 'Path to the post'
        required: true
        type: string

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: ${{ github.event.inputs.post_path }}
          base-url: 'https://blog.walsen.website'

Real-World Results

Since implementing this action on my blog, the results have been transformative:

Before:

⏱️ 15 minutes per post to cross-post manually
🐛 Frequent mistakes (forgotten canonical URLs, wrong tags)
😓 Discouraged from updating posts on Dev.to
📉 Inconsistent presence on Dev.to

After:

⚡ Automatic publishing in ~30 seconds
✅ Zero manual intervention required
🔄 Updates synchronized automatically
📈 Consistent cross-posting to Dev.to
🎯 More time for writing, less for publishing

Lessons Learned

Building this action taught me several valuable lessons:

1. Start with a Script, Then Package It

I initially built a TypeScript script (publish-to-devto.ts) that worked locally. Once it was stable, I packaged it as a GitHub Action. This iterative approach made debugging much easier.

2. Frontmatter Mapping is Tricky

Hugo and Dev.to use different field names and formats. Creating a robust mapping layer required careful testing with various post formats.

3. Idempotency Matters

The action needed to handle both new posts and updates gracefully. Checking for existing articles by canonical URL was crucial.

4. Documentation is Key

I created multiple documentation files:

README.md - Overview and quick start
GETTING_STARTED.md - 5-minute setup guide
SETUP.md - Comprehensive instructions
HUGO_COMPATIBILITY.md - Hugo-specific details
API_KEY_SETUP.md - Security best practices

This made the action accessible to users with different needs.

5. Community Feedback is Invaluable

Publishing the action to the GitHub Marketplace exposed it to real-world use cases I hadn't considered. User feedback helped improve error handling and edge cases.

Future Enhancements

While the action works great, there's always room for improvement:

Batch Publishing: Support publishing multiple posts in a single action invocation
Dry Run Mode: Preview what would be published without actually doing it
Custom Field Mapping: Allow users to configure their own frontmatter mappings
Image Upload: Automatically upload local images to Dev.to
Analytics Integration: Track publishing metrics
Multi-Platform Support: Extend to Medium, Hashnode, etc.
Additional Shortcode Support: Transform other Hugo shortcodes (YouTube, Twitter embeds, etc.)

Conclusion

Building hugo2devto solved a real problem I faced as a technical blogger: the friction of cross-posting content. By automating the process through GitHub Actions, I eliminated manual work, reduced errors, and made it effortless to maintain a presence on Dev.to.

The action is open source and available for anyone to use. Whether you're running a Hugo blog, a Jekyll site, or any markdown-based platform, the core concepts apply: automate the boring stuff so you can focus on writing great content.

If you're interested in trying it out or contributing, check out the repository:

Repository: https://github.com/Walsen/hugo2devto

GitHub Marketplace: https://github.com/marketplace/actions/hugo-to-dev-to-publisher

The future of technical blogging is automated, and I'm excited to see where this journey leads. Happy blogging!

A Wild Ride Into Vibe Coding

Sergio D. Rodríguez Inclán — Fri, 23 Jan 2026 11:32:21 +0000

Introduction

Since I was a child, computers have held a magnetic fascination for me. I vividly remember the first time I saw one in my mother’s office at the age of eleven; in that exact moment, I knew precisely what I wanted to do with my life.

Although destiny led me down the path of infrastructure, I never truly abandoned the dream of developing applications. While I have a solid foundation in programming and can hold my own in the terminal, a lack of daily practice and the time required for a deep dive had—until now—prevented me from producing professional-grade software.

Today, however, the landscape has shifted. With the rise of Artificial Intelligence, LLMs, and Generative AI, a new horizon has opened for profiles like mine: the ability to bring complex applications to life without needing to be an expert in deep syntax, by leveraging AI-powered editors that amplify our creative potential.

The Challenge: AWS Community Day Bolivia 2025

This adventure began with the organization of AWS Community Day Bolivia 2025. This year, the honor of leading the event fell to the AWS User Group Cochabamba, a team where I serve as one of the leaders. Organizing an event of this magnitude requires impeccable coordination with volunteers; while tools like Google Forms or Sheets are useful, I was looking for something more: a comprehensive, custom-built solution.

My vision was to build a platform that would allow us to:

Manage Projects: Create and administer specific initiatives for the event.
Dynamic Registration: Allow volunteers to sign up directly for projects.
Multichannel Communication: Send announcements and updates from a centralized hub.
Admin Panel: A secure portal for operations exclusive to authorized leaders.
Technological Innovation: Test Kiro, Amazon’s current IDE, and its powerful generative AI capabilities.
Community Legacy: Create a project "by the community, for the community" that could serve as a real-world case study in our talks.

The Journey is the Reward

Although the development wasn't finalized in time for the Community Day, the experience was a revelation. This process deeply enriched my understanding of Generative AI, application architecture, and the modern software development lifecycle. Above all, it allowed me to discover the "tips & tricks" of working with AI agents and the delicate human-machine synergy required to achieve the desired result.

As of this writing, Kiro has advanced significantly. Many of the initial limitations I encountered have been addressed—particularly regarding session management and memory—solidifying its position as a cutting-edge tool that leaves previous versions behind.

"Vibe Coding" is No Joke

I must confess, I was quite naive at first. I trusted Kiro’s output almost blindly because, initially at least, it generated the site’s starting structure correctly and surprisingly fast. The project kicked off with a specifications proposal (a Spec) designed by Kiro itself; in my prompt, I asked it to generate a three-tier serverless project: AstroJS for the frontend, FastAPI for the backend, and DynamoDB for data persistence.

During the early stages, I worked with three editors open and deployed directly from my local machine to the User Group’s AWS account. However, the time came to do things right and set up deployment via a CI/CD workflow (because, as the saying goes: "the shoemaker's son always goes barefoot"). For this, I decided to use AWS CDK. In my experience, managing state files is an additional headache I wanted to avoid, so I ruled out Terraform and Pulumi from the start.

Unifying All Projects Under a Single Session

At the start of every task, I would enter a prompt to polish details that didn’t quite look right or weren't functioning correctly. This is where I hit my first major roadblock: I had four different Kiro sessions that shared no context with one another.

If Kiro detected an API bottleneck while developing the frontend, the tool was essentially "blind" to the other components. This forced me into a constant cycle of copying and pasting to transfer data from one environment to another. To solve this, I decided to centralize everything into a single session. I grouped all the repositories into a root directory so that Kiro could navigate between them with full awareness of how the components interacted.

Below is the local structure I defined to achieve that synchrony:

❯ tree -L 1 -a
.
├── .amazonq
├── .devbox
├── .envrc
├── .gitignore
├── .kiro
├── .python-version
├── .venv
├── README.md
├── devbox.json
├── devbox.lock
├── generated-diagrams
├── pyproject.toml
├── registry-api
├── registry-documentation
├── registry-frontend
├── registry-infrastructure
└── uv.lock

9 directories, 8 files

The reader will notice that I have Devbox configured in the root directory. I made this choice because Kiro frequently needed to run Python scripts to sanitize repositories, perform searches, or handle troubleshooting tasks. Therefore, I saw the need to provide it with an isolated dependency chain, thus avoiding the installation of unnecessary software on my primary operating system.

Clear Rules: The Art of Coexistence

This was the most complex stage and the one that demanded the most time. It was a period of alignment between the AI and myself; the moment where we discovered our character, our limits, and just how much we could tolerate one another. Readers might be skeptical, but after working through dozens of sessions, I can confirm that each one develops a distinct "personality." There is a subtle but real difference: the speed at which they grasp previous context, the tone of the conversation, and the level of initiative varies from session to session.

For those who haven't yet experimented with Kiro (or Amazon Q), there are fundamental aspects that must be taken very seriously:

Session Volatility: Sessions are temporary. Upon reaching a context limit, the session resets, transferring only a very brief summary of what happened. Critical details can be lost in this process, especially if the previous activity was intense.
Trust Management: When running tools, Kiro asks if commands are safe. If you decline, it won't execute anything; if you accept, it will run everything without further confirmation. It’s an "all or nothing" situation that requires vigilance.
Git Structure Invisibility: Kiro does not natively understand the concept of a "repository." It ignores the existence of commits, branches, or staged files. Because of this, you must be surgical: you have to tell it exactly which file to modify and which change to make.
Project Ecosystem Disconnect: It doesn’t automatically assume the existence of config files, dependencies, or CI/CD workflows. To Kiro, every file is an isolated entity unless you provide the full map.

Ignoring these rules comes at a high price: Kiro will generate code that doesn't work or doesn't align with your goals. The most dangerous part is that the tool will always confidently assure you that everything is fine, leaving you with a false sense of success.

The breaking point came during an iteration where I requested an architectural adjustment. Kiro misinterpreted the instruction and altered the entire project: it transformed a Serverless architecture into one based on ECS and Aurora. It was a frustrating experience, but a necessary one. At that moment, I decided to establish rules of engagement: I created an "Architecture Primitives" document. In it, I defined strict guidelines on project structure, repository management, and expected behavior when publishing changes.

From that "contract" onward, the project stabilized. I moved forward with a fluidity that previously seemed impossible, and thanks to that, the beta version materialized much sooner than expected and is already available online.

The Blueprint: Anatomy of an Efficient Architecture

The project's architecture is illustrated in the following diagram:

To achieve the goals of cost-efficiency and scalability, I designed a modular structure divided into logical layers. Here is how the components interact:

1. Access and Delivery Layer (Edge & Auth)

This is the first line of contact with the user, prioritizing security and speed.

Amazon CloudFront: Acts as a CDN to distribute content with low global latency.
Amazon Cognito: Serves as the Identity Provider (IdP), managing authentication and the lifecycle of both users and administrators.

2. Interface Layer (API Gateway)

We separated the control planes to ensure the security of sensitive operations.

App API: The public entry point for application functionalities.
Admin API: A dedicated, isolated Gateway for privileged administrative operations.

3. The Brain: Orchestration and Serverless Logic

This is where the system's intelligence resides, utilizing an event-driven microservices approach.

AWS Step Functions: Orchestrates complex workflows, ensuring each step executes in the correct order.
Lambda Functions (Multi-purpose): Specialized functions that execute business logic, ranging from the Route Manager to access control (HBAC).
Amazon ECR: Stores the container images that power our Lambdas, enabling consistent execution environments.
AWS CDK: The "glue" of the entire project, allowing this infrastructure to be 100% reproducible through code.

4. Service Layer and Dynamic Registry

The heart of the system uses the Service Registry pattern to avoid tight coupling.

Service Registry Pattern: Implemented via Lambdas acting as a central directory, enabling dynamic service discovery at runtime.
Specialized Services: Dedicated modules for searches (Search Service), scheduled tasks (Cron Service), and personnel management (People Service).

5. Persistence and Communications (Data Layer)

A polyglot combination to handle different data types efficiently.

Amazon DynamoDB: Our NoSQL database for high-speed caching and case management.
Amazon S3: The central repository for image and object storage.
Amazon SES: The notification engine for direct communication with volunteers.

6. Cross-Cutting Layers: Security and Observability

Components that span the entire architecture to ensure health and protection.

Security and Configuration: Intensive use of AWS Secrets Manager and Parameter Store for secret management and zero-trust policies.
360° Observability: Implementation of Amazon CloudWatch for tracing, performance metrics, and log centralization.

The Project Manifesto: Patterns and Guidelines

To prevent our collaboration with AI from descending into the architectural chaos I mentioned earlier, I had to formalize our knowledge into two fundamental pillars. These documents didn't just guide Kiro; they established the foundation of what I consider modern assisted development.

1. Enterprise Architecture Patterns (EAP)

It isn’t just about writing code; it’s about following principles that guarantee the system’s evolution. Based on the documentation from the Registry Project, we implemented three golden rules:

Isolation and Decoupling: Every service operates autonomously. The use of the Service Registry is not optional; it is the mechanism that allows our infrastructure to scale without creating rigid dependencies (spaghetti code).
Design for Resilience: We apply the Saga Pattern to manage distributed transactions in serverless environments, ensuring that if one step fails, the system can automatically recover or compensate for the error.
Security by Design (Zero-Trust): No component trusts another by default. Every interaction requires identity validation through Cognito and access control based on strict policies.

2. AI Coexistence Manual: The "AI Assistant Guidelines"

Learning to talk to an agent like Kiro requires more than simple instructions; it requires a framework. These are the key takeaways from our Assistance Guidelines:

Incremental Context: Instead of firing off massive prompts, we feed the AI specific fragments of context. If Kiro knows the database structure but not the authentication flow, we explicitly remind it of the latter before asking for a change in that area.
Mandatory Human Validation: The AI proposes; the human disposes. We established that no deployment occurs without a manual review of the generated diffs. This prevented the project from accidentally transforming back into costly and unnecessary infrastructure.
Living Documentation: Every time the AI generated an innovative solution, that logic was immediately documented. In this way, the "memory" of the project didn't rely solely on Kiro's current session, but on our central knowledge repository.

The Reasoning Behind a "Multi-Cloud-Ready" Architecture in an AWS Environment

Although the project lives and breathes in the Amazon Web Services ecosystem, I made a strategic decision from day one: the architecture had to be Multi-Cloud-Ready.

Many might ask: Why complicate the design if we already have the AWS toolset? The answer lies in technical sovereignty and cost control. By implementing patterns like the Service Registry and using Devbox to isolate environments, we avoid the dreaded vendor lock-in.

Designing this way forces us to separate business logic from infrastructure. This means that if the community decided tomorrow to migrate part of the workload to another platform or integrate external services, the core of our application would not suffer a technical trauma. It is an architecture designed for freedom—where AWS is our choice of excellence, but not our only possibility.

Conclusion

This project allowed me to experience a new way of working and a new way of thinking about software development. It isn’t about replacing developers; it’s about empowering them—freeing their minds so they can focus on what truly matters: creativity, innovation, and solving complex problems.

Generative AI is a powerful tool, but it requires a human to guide it, correct it, and refine it. That is what I love most about this experience: the fact that there is a human behind every line of generated code, and that this human has the capacity to learn, evolve, and improve.

It is not about letting the AI do everything; it is about learning to work alongside it, leveraging its power to do more, be more, and achieve things that previously seemed impossible.

I hope this journey serves as an inspiration for you to explore new ways of working, thinking, and creating. May it also remind you that the future isn't something that just happens to us—it is something we build together, with tools, with technology, with AI, and with humanity.

Finally, to all those who have always wanted to develop applications but haven't been able to: now is the time. From this point forward, nothing is impossible. However, do not go into this process blindly; you must do it with a solid foundation. So, it's time to hit the books!

Thank you for reading this far, and as always, see you next time!

El Futuro del Trabajo

Sergio D. Rodríguez Inclán — Mon, 10 Nov 2025 20:37:38 +0000

English version here!

Situación actual

En el momento de escribir este artículo, las empresas tecnológicas se encuentran en una fase de transición. Con la llegada de la inteligencia artificial, la forma de producir software cambiará, y el tipo de profesionales requeridos para su construcción también lo hará (si no ha empezado a suceder ya).

En el ámbito de la informática, los roles profesionales más comunes incluyen: arquitectos y desarrolladores, especialistas en control de calidad (QA), ingenieros de infraestructura, analistas de bases de datos, y todas las variantes relacionadas con estas especialidades.

Los arquitectos y desarrolladores diseñan e implementan todo el código relacionado con el producto.

Los especialistas en control de calidad (QA) aseguran que el producto cumpla con los requisitos de calidad.

Los ingenieros de infraestructura se encargan de la infraestructura de la empresa, abarcando elementos como servidores, bases de datos, automatización en la nube, y un largo etcétera.

Los analistas de bases de datos se ocupan de estas, incluyendo el diseño de esquemas y la migración de datos, entre otras tareas.

Obviamente, existen otros roles de carácter más administrativo, pero no nos centraremos en ellos en este análisis.

La cuestión fundamental es que la IA está redefiniendo la manera en que la industria crea sus productos; el primer y más importante sector afectado es, sin duda, el software. Los ingenieros de software, que hasta hace no mucho tiempo eran muy demandados por su capacidad para producir código y llevarlo a producción, realizaban su trabajo de forma predominantemente artesanal. Aunque siempre se han seguido buenas prácticas y procesos, la mayor parte del software existente ha sido diseñado y programado por cerebros y manos humanas.

Hoy en día, los modelos de lenguaje de gran escala (LLM, por sus siglas en inglés) han superado a otros modelos de IA anteriores (como BERT) y se han consolidado como la herramienta más potente para la industria del software.

Además, las técnicas de IA generativa, como el vibe coding (si es un término específico), los agentes y los servidores MCP (Machine Control Program), combinadas, podrían potencialmente reemplazar una parte considerable del trabajo de desarrollo tradicional que impera hoy en la industria del software.

Por lo tanto, las empresas tecnológicas, especialmente las de mayor envergadura, han comenzado a reemplazar ingenieros de desarrollo tradicionales por ingenieros especializados en IA.

¿Cuál es la diferencia entre el desarrollo tradicional y el desarrollo con IA?

En pocas palabras, ya no será necesario que un desarrollador cree una API, o que un especialista DevOps despliegue una solución en la nube; un agente con esas capacidades específicas podrá hacerlo.

¿Cómo funcionan los Agentes de IA?

Los agentes de IA son sistemas que combinan modelos de lenguaje (LLM) con herramientas y capacidades de ejecución. A diferencia de un simple chatbot, un agente puede:

Razonar sobre qué acciones tomar
Ejecutar herramientas y comandos
Observar los resultados
Iterar hasta completar la tarea

He aquí un pequeño flujo de ejemplo de despliegue usando un agente de IA.

Componentes clave del sistema

LLM (Modelo de Lenguaje): El "cerebro" que razona y toma decisiones
Agente: Orquestador que coordina entre el LLM y las herramientas
Herramientas: APIs, comandos CLI, acceso a archivos, bases de datos, etc.
Entorno: El sistema real donde se ejecutan las acciones

Flujo de trabajo

Entrada del usuario: Define la tarea de alto nivel
Razonamiento: El LLM analiza qué herramientas usar y en qué orden
Ejecución: El agente invoca las herramientas necesarias
Observación: Recibe los resultados de cada acción
Iteración: El LLM decide el siguiente paso basándose en los resultados
Completación: Cuando la tarea está terminada, reporta al usuario

Este ciclo de Razonar → Actuar → Observar se repite hasta que el agente completa la tarea o determina que no puede continuar.

La imagen a continuación ilustra lo que denomino la "torre de la abstracción". Al igual que en todo proceso, existe una evolución natural donde los componentes se especializan progresivamente y su interacción se vuelve más concreta y optimizada.

Consideremos un ejemplo: el cerebro humano no "sabe" directamente cómo hacer que la mano apriete un objeto. Simplemente decide que existe una situación en la que la acción de apretar es necesaria y envía la señal al órgano especializado, que en este caso son los músculos de la mano. En la imagen, podemos establecer la siguiente analogía: el LLM representa el cerebro, el transporte simboliza los nervios, y cada agente equivale a un músculo específico de la mano.

De manera similar, en el mundo del software, el proceso evolucionó desde la implementación de un módulo monolítico único hasta la ejecución de tareas específicas en microservicios orquestados por un controlador. Este controlador decide qué microservicio debe ser invocado como resultado de un evento o una condición. Aplicando esta analogía a la imagen, el LLM se correspondería con un Control Plane, el transporte con el networking y las rutas, y los agentes con los Pods/containers.

En esta evolución, el agente de IA determina qué herramientas utilizar y en qué secuencia, mientras que el LLM decide el paso siguiente basándose en los resultados obtenidos.

El siguiente paso en el desarrollo tradicional resultó ser, quizás, más inesperado que lógico. Esta evolución de la industria del software (y de muchas otras) se traduce en la delegación del trabajo de desarrollo, implementación, pruebas y despliegue a agentes inteligentes. Estos pueden realizar dicha labor de manera ininterrumpida y con una eficiencia superior a la humana, al consumir menos recursos, dejando así atrás la faceta artesanal del proceso.

¿Y entonces, qué pasará con...?

Sí, la pregunta es crucial: ¿qué destino aguarda a los ingenieros tradicionales que, día a día, entregan tarea tras tarea?

Se presentan, entonces, dos alternativas claras: o dejamos que los acontecimientos nos arrollen y el "tsunami" nos sepulte bajo toneladas de agua, o bien, nos reinventamos y adaptamos (una vez más), aprendiendo a navegar el vasto mar de cambios que se avecinan.

De ahora en adelante, la industria ya no requerirá desarrolladores que elaboren código de principio a fin, ingenieros que desplieguen soluciones completas, o analistas que revisen exhaustivamente el código o la estructura de datos. En cambio, la industria demandará ingenieros capaces de orquestar los agentes ofrecidos por otros proveedores, así como de crear sus propios agentes para los casos específicos de su negocio.

El trabajo que antes era realizado por equipos de decenas de personas, ahora será llevado a cabo por unos pocos, quienes, sin embargo, producirán lo mismo o incluso más que aquellos "pequeños ejércitos".

Dado que la creación de productos será mucho más sencilla, es probable que surjan numerosas startups que, aunque con pocas personas, lograrán un gran impacto y se posicionarán en el mercado. Además, se crearán muchas nuevas posiciones para aquellos que aprendan a interactuar con los agentes y a mejorarlos.

La educación, sin duda, deberá transformarse también, especialmente la educación superior, que aún forma ingenieros con un perfil "clásico" que saldrán a un mercado que ya no los necesita. Las instituciones de educación superior deben reformar sus currículos ¡con urgencia!

Del mismo modo, las empresas de software que pretendan retener a sus ingenieros deberán impulsarlos a actualizarse y a realizar esta transición de la forma menos traumática posible. Como ingenieros, nos enorgullecemos de nuestras capacidades, pero en ocasiones mostramos necedad y reticencia, o incluso incredulidad, ante el cambio, sobre todo cuando este parece no favorecernos.

¿Por dónde empezar?

Como líder de un AWS User Group, uno de mis deberes consiste en guiar a la comunidad hacia este futuro.

No hay herramienta más poderosa que la educación. Por lo tanto, mi primer consejo sería buscar las certificaciones relacionadas con el tema, creadas y diseñadas por las mismas empresas que están liderando esta transición. Personalmente, considero que no hay mejor incentivo para estudiar que una certificación, ya que el conocimiento que exige no solo es teórico, sino que abarca también el dominio práctico del día a día; en consecuencia, quien no posea esa experiencia se verá impulsado a adquirirla por medios propios.

La primera y más importante certificación para iniciar este camino sería la "AWS Certified AI Practitioner", donde se abordan los fundamentos: qué es un LLM, qué es una base de datos vectorial, qué es un agente, cómo crear prompts efectivos para interactuar con un agente de IA, entre otros aspectos. Dado que es una certificación de AWS, requiere el conocimiento básico, al menos, de muchos de sus servicios y su configuración mínima. Por lo tanto, revisar el material de la certificación "AWS Certified Cloud Practitioner" resulta también muy beneficioso; y, por supuesto, si uno se anima a obtenerla, tanto mejor.

Una vez obtenida la primera certificación, se puede comenzar a crear agentes de IA y, de este modo, avanzar paulatinamente en la transición.

La primera opción es un servicio completamente administrado denominado Amazon Bedrock, que integra numerosos LLM y ofrece herramientas para crear agentes, integrar modelos, etc. Aquí puede consultarse una lista exhaustiva de artículos relacionados con Amazon Bedrock.

AWS también ofrece un framework de código abierto llamado Strands Agents, orientado a código (actualmente en Python) y de uso sencillo. Su repositorio en GitHub contiene excelentes ejemplos para iniciarse, destacando particularmente el asistente personal:

Este ejemplo emplea varios agentes integrados entre sí, como los de búsqueda de información, imágenes y videos, entre otros; así como un agente principal encargado de responder a las preguntas del usuario. Constituye un ejemplo muy didáctico para comprender las capacidades de Strands en la creación de agentes.

Una vez adquirida la experiencia necesaria, se podría optar a la certificación "AWS Certified AI Developer Professional", la cual, en el momento de redactar este artículo, se encuentra en fase beta. Obtenida esta certificación de nivel profesional, se podrá acreditar la proficiencia en el desarrollo de aplicaciones con y orientadas a la IA.

Aunque esta certificación, a pesar de ser de nivel profesional, no exige ningún requisito previo para su realización, el sentir de la comunidad sugiere que las siguientes son certificaciones ideales como preparación:

El tiempo dirá si es así.

Conclusión

Si hay algo seguro en esta vida es que todo cambia. Por lo tanto, todos debemos estar preparados para los cambios que inevitablemente llegarán.

Personalmente, he comenzado mi propio camino de transición y debo confesar que lo disfruto enormemente. Siempre fui un "Developer Wannabe" que no había encontrado el tiempo ni el coraje para concretar sus aspiraciones. Sin embargo, ahora puedo hacerlo sin la necesidad de invertir tanto tiempo profundizando en programación, y con la capacidad de crear aplicaciones funcionales en un tiempo significativamente menor. Sé que mis estimados compañeros desarrolladores critican el vibe coding con vehemencia, pero es imperativo despojarse de prejuicios, reaprender y abrir la mente, porque este cambio, que ya ha comenzado, no se detendrá, le pese a quien le pese.

DEV Community: Sergio D. Rodríguez Inclán

Devbox: Portable and Isolated Development Environments

Introduction

Nix

Devbox

Step 0: Install Devbox

Step 1: Create the directory

Step 2: Generate the 'devbox.json' file and review its content

Step 3: Adding Packages / Dependencies

Step 4: Start the Shell

Step 5: Configure the Environment Using direnv

Step 6: Implement Automation

Environment Variables in a Virtualenv Shell

Commands in the init_hook

Scripts

Integration with Tools and Advanced Automation

Conclusions

The Future of Work

The Future of Work

Current Landscape

What's the Difference Between Traditional Development and AI-Powered Development?

How Do AI Agents Work?

Key System Components

Workflow

So What Will Happen to...?

Where to Begin?

Conclusion

A Kiro Ambassador at the AWS Community Day Bolivia 2026

Let's talk

DevSecOps Fundamentals Project

Introduction

The Vision: More Than Just Posting

Hexagonal Architecture: The Foundation

The Domain Model

Ports and Adapters in Practice

Three Services, One Stream

Dual-Mode Deployment: Containers or Serverless

Why This Matters

Running Both Simultaneously

Zero Trust Security: Trust Nothing, Verify Everything

Network Security

Authentication Flow

API Security Middleware

Data Protection

Secure Supply Chain

Defense in Depth: Multiple Scanners

Container Security

CI/CD with GitHub Actions OIDC

The Golden Thread: Distributed Security Tracing

Attack Simulation Exercises

AI-Powered Content Adaptation

AI-Powered Security Testing Agent

Strict Guardrails

The Test Suite

Automated Penetration Testing Framework

Threat Detection and Incident Response

Security Observability

The Developer Experience

Project Structure

Lessons Learned

Conclusion

Links

An Incredible Operations Platform - Rundeck

Introduction

What Makes Rundeck Special

Core Capabilities

Where It Shines

REST API: Automation Beyond the UI

API Capabilities

Authentication

Triggering Jobs Programmatically

Integration Scenarios

Licensing: Open Source vs Enterprise

Rundeck Community (Open Source)

PagerDuty Runbook Automation (Commercial)

Which Should You Choose?

The Gap: Node-to-Node File Transfers

Rundeck Node-to-Node Plugin

Features

Transfer Modes Explained