DEV Community: RODRIGO SIDNEY COLQUE QUISPE

Breaking the SQL Barrier: How to Build a Natural Language Database Assistant

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 04:45:15 +0000

Tags: #DataEngineering #AI #Python #HuggingFace #Streamlit

For decades, SQL has been the universal language for extracting insights from databases. But there's a catch: it creates a bottleneck. Business analysts, product managers, and marketers often have to wait for data teams to write queries for them.

What if we could skip the code and just talk to our databases in plain English?

Thanks to the rapid advancements in Artificial Intelligence and Large Language Models (LLMs), this is now entirely possible. Today, I'll walk you through how I built a Text-to-SQL assistant using Python, and how you can do it too.

What is Text-to-SQL?

At its core, Text-to-SQL is an AI capability that translates conversational questions into executable SQL code. Imagine typing, "Show me all employees in the Sales department earning over 50k" and having the AI instantly generate:

SELECT * FROM employees WHERE Department = 'Sales' AND Salary > 50000;

It’s like having a senior data engineer at your fingertips 24/7.

The Tech Stack

To keep things simple and accessible, I chose a modern, lightweight stack for this project:

Hugging Face: To power the AI model (we're using t5-base-finetuned-wikiSQL).
Streamlit: To quickly build a clean, interactive user interface.
SQLite & Pandas: To handle our local mock data.

How It Works Under the Hood

1. The Brains (Hugging Face API)

Instead of training a model from scratch, we leverage Hugging Face's Inference API. By sending an HTTP request with our user's question, the API returns the translated SQL query. It's incredibly fast and requires very little code:

import requests

API_URL = "https://api-inference.huggingface.co/models/mrm8488/t5-base-finetuned-wikiSQL"

def get_sql_from_text(user_query):
    payload = {"inputs": f"translate English to SQL: {user_query}"}
    response = requests.post(API_URL, json=payload)
    return response.json()[0]['generated_text']

2. The Data Layer

For demonstration purposes, the app initializes an in-memory SQLite database loaded with some dummy employee records. This allows the app to actually execute the AI-generated SQL and prove that it works, rather than just showing the query on the screen.

3. Putting it together with Streamlit

Streamlit ties everything beautifully. We capture the user's input through a text box. When they hit "Generate", the app fetches the SQL from Hugging Face, executes it against our SQLite database using pandas.read_sql_query, and renders the final dataset directly in the browser.

Why This Matters

Tools like this represent a massive shift in data democratization. When you remove the technical barrier of SQL, you empower everyone in an organization to be data-driven, speeding up decision-making across the board.

Want to see the code in action or try running it yourself?
I've made the entire project open-source. Check out my repository here:
👉 https://github.com/FabricioRams/Research-Team-Work-N-01-SQL-AI-Database-Solutions.git

(Note: Just install the requirements and run streamlit run app.py to start chatting with your data!)

Under the Hood: How Bandit SAST Analyzes Your Python Code

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 16:10:54 +0000

Abstract
While many developers use security scanners, few understand how they actually "read" code. This article explains the inner workings of Bandit, focusing on its use of the Abstract Syntax Tree (AST) to identify security patterns without ever executing a single line of code.

1. The Core Engine: AST (Abstract Syntax Tree)
Unlike a simple text search (which might give many false positives), Bandit doesn't just look for words like "password". It converts your Python code into an AST.

What is AST? It is a tree representation of the abstract syntactic structure of your source code.

Why it matters: By building a tree, Bandit understands the context. It knows if a string is just a comment or if it's actually being assigned to a sensitive variable or passed to a dangerous function like eval().

2. How the "Scanning" Happens
Bandit works through a set of plugins. Each plugin is designed to look for a specific type of vulnerability:
Blacklist Plugins: These look for the use of insecure modules (like pickle or telnetlib).
Function Call Plugins: These trigger when they see dangerous calls (like subprocess.shell=True).
Hardcoded Secret Plugins: These use heuristics to identify strings that look like passwords or API keys.

3. Severity and Confidence levels
One of Bandit's best features is its scoring system:
Severity: How bad is the bug? (Low, Medium, High).
Confidence: How sure is Bandit that this is actually a bug and not a mistake?

Why use it in the CI/CD?
The main advantage is speed. Because it doesn't need to compile or run the code, it can scan thousands of lines in seconds. Integrating it into GitHub Actions (as shown in my previous post) ensures that no "illegal" AST patterns make it into the main branch.

Conclusion
Bandit isn't just a linter; it's a security-focused parser. By understanding the structure of Python, it provides a robust first line of defense for any backend developer.

Implementing SAST in Your Infrastructure: Detecting Vulnerabilities with Checkov and GitHub Actions

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 03:50:44 +0000

Abstract
This article explores the implementation of Static Application Security Testing (SAST) for Infrastructure as Code (IaC) using Checkov. We demonstrate how to identify common security misconfigurations, such as publicly accessible S3 buckets, and seamlessly integrate the scanning process into a CI/CD pipeline using GitHub Actions.

What is Checkov?
Checkov is an open-source static analysis tool (maintained by Bridgecrew / Prisma Cloud) designed specifically for Infrastructure as Code.

Unlike tools aimed at application code (like Bandit for Python), Checkov scans configuration files for misconfigurations that could lead to security vulnerabilities or compliance issues.

Why use Checkov?

Built-in policies: It comes with hundreds of out-of-the-box policies covering AWS, Azure, and GCP best practices.
Multi-framework: Supports Terraform, CloudFormation, Kubernetes, Dockerfiles, Serverless, and more.
Easy integration: Runs from the command line or directly in your CI/CD pipelines.

The Scenario: Vulnerable Infrastructure

Imagine you have a Terraform file (main.tf) where you define an S3 bucket. By mistake (or for a quick test), you configure it to have public read access:

# main.tf resource "aws_s3_bucket" "my_vulnerable_bucket" { bucket = "my-dev-test-bucket" acl = "public-read" # ❌ Security risk! }

If we deploy this, anyone on the internet could access our data. Let's make our repository catch this error before it gets merged into the main branch.

Automating with GitHub Actions
The real magic happens when we integrate Checkov into our CI/CD workflow. This way, every time someone pushes code or opens a Pull Request, Checkov will analyze the infrastructure automatically.

In your repository, create a file at .github/workflows/checkov.yml and add the following:

What exactly does this workflow do?

1. Checkout: Clones your code into the GitHub Actions virtual environment.
2. Run Checkov: Uses the official Bridgecrew action. The directory: . parameter tells it to look for infrastructure files throughout the repository.
3. soft_fail: false: This is the key to DevSecOps. If Checkov finds a failing policy (like our public bucket), the pipeline will fail, preventing vulnerable code from being integrated.

Conclusion
Shifting security to the left (Shift-Left Security) by implementing SAST in your Infrastructure as Code is no longer optional. With tools like Checkov and GitHub Actions, it's a fast and highly effective process. With just a few lines of code, you can ensure your team doesn't accidentally deploy insecure configurations.