DEV Community: Mauricio Choqueña Choque

Applying SAST Tools to Infrastructure as Code — A Hands-On Look at Checkov

Mauricio Choqueña Choque — Sun, 05 Jul 2026 19:53:14 +0000

Why Infrastructure as Code Needs Static Analysis Too

Infrastructure as Code (IaC) — Terraform, Pulumi, OpenTofu, CloudFormation — turned infrastructure into something version-controlled, reviewable, and reproducible. But that also means a single misconfigured line — an S3 bucket left public, a security group open to 0.0.0.0/0, an unencrypted database — can be committed, merged, and deployed automatically, at scale, before anyone notices.

Static Application Security Testing (SAST) for IaC works the same way it does for application code: it parses configuration files without deploying anything, and flags insecure patterns against a known rule set. OWASP's list of Source Code Analysis Tools includes several options for this. This article focuses on Checkov, an open-source policy-as-code scanner built by Bridgecrew (now part of Palo Alto Networks), chosen here specifically because it's free, multi-cloud, and multi-framework — without relying on tfsec.

Why Checkov

Checkov scans IaC files and builds a graph representation of the resources and their relationships, then evaluates that graph against hundreds of built-in security and compliance policies.

Key features:

Supports Terraform, OpenTofu, CloudFormation, Kubernetes manifests, Dockerfiles, Helm charts, Serverless framework, ARM templates, and more — not limited to one IaC tool.
Over 1,000 built-in policies covering AWS, Azure, GCP, and Kubernetes best practices (CIS Benchmarks aligned).
Supports custom policies written in Python or YAML, so teams can encode their own organizational rules.
Outputs in CLI text, JSON, JUnit XML, and SARIF — SARIF format integrates directly with GitHub's Security tab.
Can suppress specific findings inline with comments, without disabling the whole rule globally.

Installing and Running Checkov

pip install checkov

# Scan a directory of Terraform files
checkov -d ./infrastructure

# Scan a single file
checkov -f main.tf

# Output as JSON for CI pipelines
checkov -d ./infrastructure -o json --output-file-path ./checkov_report.json

A Real Example

Consider this Terraform snippet — a common pattern that looks harmless but hides several real misconfigurations:

resource "aws_s3_bucket" "data" {
  bucket = "company-data-bucket"
  acl    = "public-read"
}

resource "aws_security_group" "web" {
  name = "web-sg"

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

resource "aws_db_instance" "app_db" {
  identifier        = "app-database"
  engine            = "mysql"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  storage_encrypted = false
  publicly_accessible = true
}

Running checkov -f main.tf produces output like:
Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
FAILED for resource: aws_s3_bucket.data
File: main.tf:1-4
Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
FAILED for resource: aws_security_group.web
File: main.tf:6-13
Check: CKV_AWS_16: "Ensure RDS instances have storage_encrypted enabled"
FAILED for resource: aws_db_instance.app_db
File: main.tf:15-21
Check: CKV_AWS_17: "Ensure RDS instances are not publicly accessible"
FAILED for resource: aws_db_instance.app_db
File: main.tf:15-21

Each check includes a rule ID (CKV_AWS_20, CKV_AWS_24...), a human-readable description, the exact resource name, and the file/line range — enough for a developer to jump straight to the fix.

Fixing the Findings

resource "aws_s3_bucket" "data" {
  bucket = "company-data-bucket"
  acl    = "private"
}

resource "aws_security_group" "web" {
  name = "web-sg"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]  # restricted to internal VPC range
  }
}

resource "aws_db_instance" "app_db" {
  identifier          = "app-database"
  engine              = "mysql"
  instance_class      = "db.t3.micro"
  allocated_storage   = 20
  storage_encrypted   = true
  publicly_accessible = false
}

Re-running Checkov against the fixed file shows all four checks passing.

Integrating Checkov into a CI Pipeline

A minimal GitHub Actions workflow that scans every Terraform change and fails the build on findings:

name: IaC Security Scan with Checkov

on: [push, pull_request]

jobs:
  checkov-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./infrastructure
          framework: terraform
          output_format: sarif
          output_file_path: checkov-results.sarif
      - name: Upload SARIF to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov-results.sarif

Uploading the SARIF report to GitHub's Security tab means findings show up alongside other code scanning alerts, with no separate dashboard needed.

Public Repository Example

You can see Checkov applied to real Terraform code here:

github.com/bridgecrewio/checkov — the tool's own repository, which includes hundreds of example Terraform/CloudFormation/Kubernetes files used as test fixtures for its own rule set, under tests/terraform/checks.
github.com/bridgecrewio/terragoat — a deliberately vulnerable, multi-cloud Terraform application built specifically to be scanned by tools like Checkov, useful as a public sandbox to practice against realistic misconfigurations.

Cloning either repo and running checkov -d . locally demonstrates the tool against real, non-trivial infrastructure code.

Where Checkov Fits Among IaC SAST Tools

Tool	IaC scope	License	Notes
Checkov	Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, ARM, Serverless	Open source (Apache 2.0)	Broadest framework coverage, graph-based analysis
Terrascan	Terraform, Kubernetes, Helm	Open source	OPA/Rego-based policies
KICS (Checkmarx)	Terraform, CloudFormation, Kubernetes, Docker, Ansible	Open source	Large community rule library
Cloud Custodian	Cloud resources (runtime, not pure static)	Open source	More focused on ongoing compliance than pre-deploy scanning

Compared to single-framework scanners, Checkov's advantage is breadth: one tool can cover Terraform, Kubernetes manifests, and Dockerfiles in the same pipeline run, which reduces the number of separate security tools a team needs to maintain.

Conclusion

Securing infrastructure code doesn't require a heavyweight commercial platform to get started. An open-source, policy-as-code scanner like Checkov can catch real, high-impact misconfigurations — public buckets, open security groups, unencrypted databases — before terraform apply ever runs, and it does so across multiple IaC frameworks at once. For teams adopting DevSecOps practices, plugging a tool like this into CI is a low-cost, high-value first step toward "shifting left" on cloud security.

Applying SAST Tools to Real Applications — A Hands-On Look at Bandit

Mauricio Choqueña Choque — Sun, 05 Jul 2026 19:51:15 +0000

What is SAST, and Why It Matters

Static Application Security Testing (SAST) analyzes source code — without executing it — to find security vulnerabilities before they ever reach production: hardcoded secrets, SQL injection risks, use of insecure functions, weak cryptography, and more. Unlike dynamic testing (DAST), which probes a running application, SAST catches problems at the earliest possible stage: while the code is being written or committed.

OWASP maintains a well-known list of Source Code Analysis Tools covering many languages and licensing models. This article focuses on Bandit, an open-source SAST tool built specifically for Python codebases, chosen here because it's lightweight, free, and easy to integrate into any CI pipeline without vendor lock-in.

Why Bandit

Bandit was originally developed by the OpenStack Security Project and is now maintained under the Python Code Quality Authority (PyCQA). It works by parsing Python source code into an Abstract Syntax Tree (AST) and running a set of security-focused plugins against it — no code execution involved, which makes it fast and safe to run on any repository, including untrusted third-party code.

Key features:

100% open source, no account or license required.
Detects common issues: use of eval()/exec(), hardcoded passwords, insecure subprocess calls, weak hashing algorithms (MD5/SHA1 for security purposes), unsafe YAML loading, SQL string concatenation, and more.
Configurable severity/confidence thresholds, so teams can fail builds only on high-severity findings.
Native CI/CD integration via exit codes, plus JSON/HTML/CSV report output.

Installing and Running Bandit

pip install bandit

# Scan a single file
bandit example.py

# Scan an entire project recursively
bandit -r ./src

# Generate a JSON report for CI pipelines
bandit -r ./src -f json -o bandit_report.json

A Real Example

Consider this deliberately vulnerable Python snippet — the kind of code that often slips into real projects unnoticed:

import hashlib
import subprocess
import yaml

def hash_password(password):
    # Weak hashing algorithm for security purposes
    return hashlib.md5(password.encode()).hexdigest()

def run_backup(filename):
    # Command injection risk: shell=True with unsanitized input
    subprocess.call(f"tar -cvf backup.tar {filename}", shell=True)

def load_config(path):
    with open(path) as f:
        # Unsafe deserialization
        return yaml.load(f)

Running bandit -r . against this file produces output like:
Each finding includes a rule ID (B303, B602, B506), a severity/confidence rating, and the exact file and line number — enough context for a developer to fix the issue without needing a security background.

Fixing the Findings

import hashlib
import subprocess
import yaml

def hash_password(password):
    # Use a strong, purpose-built hashing function instead of MD5
    return hashlib.sha256(password.encode()).hexdigest()

def run_backup(filename):
    # Avoid shell=True; pass arguments as a list instead
    subprocess.call(["tar", "-cvf", "backup.tar", filename])

def load_config(path):
    with open(path) as f:
        # safe_load restricts deserialization to simple Python objects
        return yaml.safe_load(f)

Re-running Bandit against the fixed file returns zero findings — confirming the issues were resolved.

Integrating Bandit into a CI Pipeline

A minimal GitHub Actions workflow that fails the build on any high-severity finding:

name: SAST Scan with Bandit

on: [push, pull_request]

jobs:
  bandit-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install Bandit
        run: pip install bandit
      - name: Run Bandit
        run: bandit -r ./src -ll

The -ll flag tells Bandit to only report (and fail on) medium and high severity issues, filtering out noise from low-severity findings during early adoption.

Public Repository Example

You can see Bandit applied to a real, public codebase here:

github.com/PyCQA/bandit — the tool's own repository, which also runs Bandit against itself as part of its CI pipeline.
github.com/OWASP/django-DefectDojo — a large, real-world Django application (a vulnerability management platform, ironically) where Bandit-style static analysis patterns are commonly applied and can be run directly against the source.

Cloning either repo and running bandit -r . locally shows the tool working against production-scale code, not just toy examples.

Where Bandit Fits Among SAST Tools

Tool	Language scope	License	Notes
Bandit	Python only	Open source (Apache 2.0)	Lightweight, AST-based, fast
Brakeman	Ruby on Rails only	Open source	Rails-specific vulnerability patterns
SpotBugs + FindSecBugs	Java	Open source	Bytecode analysis, plugin-based
CodeQL	Multi-language	Free for public repos	Query-based, very powerful but heavier setup
PMD	Java, Apex, others	Open source	General code quality + some security rules

Compared to multi-language commercial platforms, Bandit trades breadth for simplicity: it does one language well, has no licensing cost, and can be added to a pipeline in minutes.

Conclusion

SAST doesn't require an expensive enterprise platform to start delivering value. A focused, open-source tool like Bandit can catch real, exploitable issues — insecure hashing, command injection, unsafe deserialization — directly in the CI pipeline, before code is merged. For teams working primarily in Python, it's a practical, zero-cost entry point into DevSecOps practices, and a good complement to broader multi-language tools as security maturity grows.

Applying API Testing Frameworks — A Hands-On Example with REST Assured

Mauricio Choqueña Choque — Sun, 05 Jul 2026 19:45:40 +0000

Why API Testing Frameworks Matter

APIs are the backbone of modern software — they connect frontends, mobile apps, microservices, and third-party integrations. If an API breaks silently, everything built on top of it breaks too. That's why API testing frameworks exist: to validate that endpoints return the right status codes, the right data structure, and the right values, automatically, on every code change.

There are dozens of tools in this space — Postman, SoapUI, Karate DSL, JMeter, Swagger, Katalon Studio — each with different trade-offs between ease of use, coding requirements, and CI/CD integration. This article focuses on one of the most widely adopted code-based frameworks: REST Assured, a Java DSL built specifically to make testing REST APIs readable and maintainable.

Why REST Assured

Unlike GUI-based tools (Postman, SoapUI), REST Assured is a library, not an application — tests are written in Java and run like any other unit test (JUnit/TestNG), which means they plug directly into existing CI pipelines (Jenkins, GitHub Actions, GitLab CI) without any extra setup.

Key features:

BDD-style syntax (given() / when() / then()), close to plain English.
Built-in JSON/XML response validation — no need to manually parse responses.
Works seamlessly alongside Selenium/Serenity for combined UI + API test suites.
No need to be an HTTP protocol expert to write solid tests.

A Real Example

Here's a real, working REST Assured test against a public test API (reqres.in, commonly used for practicing API testing):

import io.restassured.RestAssured;
import io.restassured.response.Response;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.*;

public class UserApiTest {

    @Test
    public void testGetSingleUser() {
        given()
            .baseUri("https://reqres.in/api")
        .when()
            .get("/users/2")
        .then()
            .statusCode(200)
            .body("data.id", equalTo(2))
            .body("data.email", containsString("@reqres.in"))
            .body("data.first_name", notNullValue());
    }

    @Test
    public void testCreateUser() {
        String requestBody = "{ \"name\": \"morpheus\", \"job\": \"leader\" }";

        Response response =
            given()
                .baseUri("https://reqres.in/api")
                .contentType("application/json")
                .body(requestBody)
            .when()
                .post("/users")
            .then()
                .statusCode(201)
                .body("name", equalTo("morpheus"))
                .body("job", equalTo("leader"))
                .extract().response();

        System.out.println("Created user ID: " + response.jsonPath().getString("id"));
    }
}

What this example shows in practice:

given() sets up the request (base URL, headers, body).
when() performs the action (GET, POST, etc.).
then() validates the response — status code, JSON fields, string patterns — all in a single fluent chain.
No manual JSON parsing, no raw HTTP client boilerplate: the assertions read almost like a specification of what the API should do.

Public Repository Example

You can see this exact pattern in real open-source repositories that use REST Assured against public test APIs:

github.com/rest-assured/rest-assured — the official framework repository, including its own extensive test suite as a live reference.
github.com/vsingh181/reqres-api-automation — a public example project testing the reqres.in API specifically, similar in structure to the snippet above.

Both repositories can be cloned and run locally with Maven or Gradle to see the tests execute against a live API.

Comparing to Other Frameworks

Framework	Type	Coding required	Best for
REST Assured	Java library	Yes (Java)	Teams already using JUnit/TestNG, CI-first workflows
Postman/Newman	GUI + CLI runner	Minimal	Quick manual testing, exploratory testing, non-devs
Karate DSL	Gherkin-based DSL	Minimal	BDD scenarios without full Java knowledge
JMeter	GUI + scripting	Minimal	Load testing repurposed for functional checks
SoapUI	GUI	Minimal (Pro: Groovy)	SOAP-heavy legacy systems

REST Assured sits closer to the "developer-first" end of the spectrum — it requires knowing Java, but in exchange gives full programmatic control: loops, conditionals, data-driven tests from CSV/JSON files, and direct integration into the same test suite as unit tests.

Conclusion

Choosing an API testing framework is less about which tool is "best" overall, and more about matching the tool to the team. For a team of developers already comfortable with Java and JUnit, REST Assured turns API contracts into readable, maintainable, CI-friendly test code — with no separate GUI tool to install or maintain. For teams with mixed technical backgrounds, a GUI-first tool like Postman may still be the faster path to adoption.

The best way to evaluate any API testing framework, as always, is to clone a real repository — like the ones linked above — and run the suite yourself.

CI Testing Management Tools Compared — A Hands-On Look at GitHub Actions

Mauricio Choqueña Choque — Sun, 05 Jul 2026 17:59:07 +0000

Why "Testing Management Tools" Matter

Every serious software team eventually asks the same question: how do we make sure tests run automatically, consistently, and block bad code from reaching production? The answer is a CI/CD pipeline tool — GitHub Actions, GitLab CI, Jenkins, CircleCI, TeamCity, Travis CI, Bitbucket Pipelines, Tekton, Harness, and others all solve this problem, but with different philosophies, pricing models, and levels of ceremony.

This article focuses on GitHub Actions, using a real, public repository to show exactly how automated test management looks in practice — not just in theory.

Where GitHub Actions Fits in the Landscape

Tool	Hosting	Config format	Best for
GitHub Actions	Cloud (GitHub-hosted or self-hosted runners)	YAML in `.github/workflows/`	Projects already on GitHub, fastest setup
GitLab CI/CD	Cloud or self-hosted	YAML (`.gitlab-ci.yml`)	Teams fully inside GitLab, built-in Docker registry
Jenkins	Self-hosted	Groovy (`Jenkinsfile`)	Full control, complex enterprise pipelines
CircleCI	Cloud	YAML (`.circleci/config.yml`)	Fast parallel builds, strong caching
TeamCity	Self-hosted or cloud	Kotlin DSL or UI-based	Large enterprise, strong Windows/.NET support
Travis CI	Cloud	YAML (`.travis.yml`)	Legacy open-source projects
Bitbucket Pipelines	Cloud	YAML (`bitbucket-pipelines.yml`)	Teams using Bitbucket + Jira
Tekton	Kubernetes-native	YAML CRDs	Cloud-native, container-first pipelines
Harness	Cloud/self-hosted	YAML + UI	CD-focused, feature flags, progressive delivery

GitHub Actions is a good starting point for this comparison because it requires zero external infrastructure — the pipeline lives in the same repository as the code, and any public GitHub repo can be used as a live example.

A Real Example: Automated Testing Workflow

Here is a realistic workflow file that runs a Python test suite on every push and pull request — the kind of file you'd find in thousands of public repositories under .github/workflows/tests.yml:

\`yaml
name: Run Tests

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11"]

steps:
  - name: Checkout repository
    uses: actions/checkout@v4

  - name: Set up Python ${{ matrix.python-version }}
    uses: actions/setup-python@v5
    with:
      python-version: ${{ matrix.python-version }}

  - name: Install dependencies
    run: |
      python -m pip install --upgrade pip
      pip install -r requirements.txt
      pip install pytest pytest-cov

  - name: Run tests with coverage
    run: pytest --cov=src --cov-report=xml

  - name: Upload coverage report
    uses: actions/upload-artifact@v4
    with:
      name: coverage-report
      path: coverage.xml

`\

A few things worth pointing out for anyone comparing tools:

Matrix strategy: this single job actually runs three times (Python 3.9, 3.10, 3.11), testing compatibility across versions without writing three separate jobs. CircleCI and GitLab CI support similar matrix features, but Jenkins requires more manual scripting to achieve the same result.
Reusable actions (actions/checkout, actions/setup-python): GitHub Actions has a large marketplace of pre-built steps, which reduces boilerplate compared to Jenkins' plugin-heavy model.
Artifacts: the coverage report is uploaded as a build artifact, viewable directly from the GitHub Actions UI — no need for a separate reporting server.

Public Repository Example

You can see this exact pattern live in real open-source projects. For example, the workflow structure above is modeled directly on the CI setup used by:

github.com/pallets/flask — check .github/workflows/tests.yml for a production example of matrix-based testing across Python versions.
github.com/psf/requests — another widely used repo with a clean, minimal GitHub Actions test pipeline.

Both are public and can be cloned or forked to study or reuse the exact YAML configuration.

What This Reveals About "Testing Management" as a Category

Comparing these tools side by side shows that the differences aren't really about whether tests can be automated — nearly all of them can run pytest, jest, mvn test, etc. The differences show up in:

Where configuration lives (YAML in-repo vs. Groovy scripts vs. UI-based config in TeamCity/Harness).
Native integrations (GitHub Actions ties tightly to GitHub PRs/checks; Bitbucket Pipelines ties to Jira; Tekton ties to Kubernetes).
Infrastructure burden (Jenkins and TeamCity need a server you maintain; GitHub Actions, CircleCI, and Travis CI are fully managed).
Scaling and parallelism (CircleCI and Tekton are built with heavy parallel/container workloads in mind).

Conclusion

For a team already hosting code on GitHub, GitHub Actions offers the lowest-friction path to automated testing: no servers to maintain, a large marketplace of reusable steps, and matrix builds that make cross-version testing trivial. Other tools in this comparison — Jenkins, TeamCity, Harness — trade that simplicity for more control, which matters more in large enterprise environments with complex, multi-stage deployment pipelines.

The best way to evaluate any of these tools isn't reading documentation — it's cloning a real public repository, like flask or requests above, and watching the pipeline run.

Agentes que se auto-corrigen: Text-to-SQL con smolagents (Hugging Face)

Mauricio Choqueña Choque — Sun, 05 Jul 2026 17:51:15 +0000

El problema de los pipelines "texto → SQL" tradicionales

La mayoría de las soluciones de IA para bases de datos siguen el mismo patrón: el usuario escribe una pregunta en lenguaje natural, un modelo la traduce a una consulta SQL, y esa consulta se ejecuta directamente contra la base de datos. Es simple, pero frágil: si el modelo genera una consulta incorrecta, esta puede ejecutarse sin errores y devolver un resultado que parece válido pero no lo es. Nadie se entera de que la respuesta está mal, porque no hubo ningún fallo visible que lo delate.

La documentación oficial de smolagents, el framework de agentes de Hugging Face, propone una alternativa: en vez de un pipeline de un solo paso, construir un agente capaz de revisar el resultado de su propia consulta y decidir si necesita corregirla. Este patrón —conocido como ReAct (Reasoning + Acting)— convierte una traducción ciega en un proceso iterativo de prueba y verificación.

El stack utilizado

smolagents — framework de agentes de código de Hugging Face.
CodeAgent — la clase principal del framework: un agente que razona escribiendo y ejecutando código, iterando sobre sus propios resultados anteriores.
SQLAlchemy — para crear una base de datos SQLite en memoria y ejecutar las consultas.
InferenceClientModel — conecta el agente con modelos alojados en la Inference API de Hugging Face (Serverless o dedicada).
Repositorio del framework: github.com/huggingface/smolagents
Documentación del ejemplo: Self-correcting Text-to-SQL

Paso a paso: cómo se construye el agente

1. Preparar la base de datos

Se crea una tabla receipts (recibos) en SQLite, con columnas receipt_id, customer_name, price y tip, y se insertan algunas filas de ejemplo (nombres de clientes, precios y propinas).

2. Convertir la tabla en una herramienta (`tool`) para el agente

Aquí está el detalle más importante del diseño: la descripción de la tabla no se le "explica" al modelo en un prompt suelto, sino que se incrusta directamente en el docstring de la función sql_engine, decorada con @tool:

\`python
@tool
def sql_engine(query: str) -> str:
"""
Allows you to perform SQL queries on the table. Returns a string representation of the result.
The table is named 'receipts'. Its description is as follows:
Columns:
- receipt_id: INTEGER
- customer_name: VARCHAR(16)
- price: FLOAT
- tip: FLOAT

Args:
    query: The query to perform. This should be correct SQL.
"""
output = ""
with engine.connect() as con:
    rows = con.execute(text(query))
    for row in rows:
        output += "\\n" + str(row)
return output

`\

Ese docstring es lo que el CodeAgent "lee" para entender qué esquema tiene disponible y cómo debe formar sus consultas.

3. Crear el agente

\`python
from smolagents import CodeAgent, InferenceClientModel

agent = CodeAgent(
tools=[sql_engine],
model=InferenceClientModel(model_id="meta-llama/Llama-3.1-8B-Instruct"),
)
agent.run("Can you give me the name of the client who got the most expensive receipt?")
`\

Con solo esto, el agente ya es capaz de generar la consulta SQL correspondiente, ejecutarla mediante la herramienta sql_engine, y devolver el nombre del cliente con el recibo más caro.

Nivel 2: cuando el esquema se complica (joins)

La prueba de fuego llega cuando se agrega una segunda tabla, waiters (meseros), que relaciona cada receipt_id con el nombre del mesero que lo atendió. Esto obliga al agente a razonar sobre un join entre dos tablas para responder algo como "¿qué mesero recibió más propinas en total?".

Como el esquema cambió, la descripción de la herramienta sql_engine se actualiza dinámicamente, incluyendo ahora las columnas de ambas tablas:

\`python
sql_engine.description = updated_description

agent = CodeAgent(
tools=[sql_engine],
model=InferenceClientModel(model_id="Qwen/Qwen3-Next-80B-A3B-Thinking"),
)
agent.run("Which waiter got more total money from tips?")
`\

Dos cosas clave suceden aquí:

El agente actualiza su comprensión del entorno simplemente porque la descripción de su herramienta cambió — no hace falta reentrenar nada ni reescribir la lógica del agente.
El modelo se cambia por uno más potente (Qwen3-Next-80B-A3B-Thinking en lugar de Llama-3.1-8B-Instruct) porque la tarea de razonar sobre un join es más difícil que una consulta simple sobre una sola tabla. La documentación confirma que este cambio de modelo mejora notablemente el resultado frente a consultas más complejas.

Por qué este enfoque es superior a un pipeline directo

Pipeline directo texto→SQL	Agente con smolagents (ReAct)
Genera y ejecuta la consulta en un solo paso	Genera, ejecuta, observa el resultado y puede corregir
Un error puede pasar desapercibido	El agente puede detectar resultados sospechosos o vacíos y reintentar
El esquema debe estar "hardcodeado" en el prompt	El esquema vive en la descripción de la herramienta y se puede actualizar en caliente
Rígido ante consultas complejas (joins, subconsultas)	Escala mejor cambiando de modelo o ajustando la herramienta

Conclusión

El ejemplo de smolagents demuestra que el salto de calidad en text-to-SQL no viene solo de tener un modelo de lenguaje más grande, sino de darle al modelo la capacidad de actuar, observar y corregir, en lugar de generar una única respuesta "a ciegas". Esto es especialmente valioso en bases de datos reales, donde los esquemas cambian, las consultas se vuelven complejas (joins, agregaciones, filtros anidados), y un error silencioso puede llevar a decisiones basadas en datos incorrectos.

Para quien quiera experimentar: el repositorio huggingface/smolagents incluye este ejemplo listo para correr en Google Colab o SageMaker Studio Lab, y es un excelente punto de partida para adaptar el patrón a una base de datos propia.

DEV Community: Mauricio Choqueña Choque

Applying SAST Tools to Infrastructure as Code — A Hands-On Look at Checkov

Why Infrastructure as Code Needs Static Analysis Too

Why Checkov

Installing and Running Checkov

A Real Example

Fixing the Findings

Integrating Checkov into a CI Pipeline

Public Repository Example

Where Checkov Fits Among IaC SAST Tools

Conclusion

Applying SAST Tools to Real Applications — A Hands-On Look at Bandit

What is SAST, and Why It Matters

Why Bandit

Installing and Running Bandit

A Real Example

Fixing the Findings

Integrating Bandit into a CI Pipeline

Public Repository Example

Where Bandit Fits Among SAST Tools

Conclusion

Applying API Testing Frameworks — A Hands-On Example with REST Assured

Why API Testing Frameworks Matter

Why REST Assured

A Real Example

Public Repository Example

Comparing to Other Frameworks

Conclusion

CI Testing Management Tools Compared — A Hands-On Look at GitHub Actions

Why "Testing Management Tools" Matter

Where GitHub Actions Fits in the Landscape

A Real Example: Automated Testing Workflow

Public Repository Example

What This Reveals About "Testing Management" as a Category

Conclusion

Agentes que se auto-corrigen: Text-to-SQL con smolagents (Hugging Face)

El problema de los pipelines "texto → SQL" tradicionales

El stack utilizado

Paso a paso: cómo se construye el agente

1. Preparar la base de datos

2. Convertir la tabla en una herramienta (tool) para el agente

3. Crear el agente

Nivel 2: cuando el esquema se complica (joins)

Por qué este enfoque es superior a un pipeline directo

Conclusión

2. Convertir la tabla en una herramienta (`tool`) para el agente