DEV Community: Ghazi saoudi

AI Agents Won’t Replace Humans — But a Bad Agent Can Break Production

Ghazi saoudi — Sun, 28 Jun 2026 00:58:39 +0000

Every few months, someone says:

“AI agents will replace developers.”

I don’t think that is the right way to look at it.

AI agents can write code, summarize logs, open pull requests, create tickets, call APIs, run tests, and even deploy software if we allow them to. That is impressive.

But replacing humans is not just about doing tasks.

In real production systems, the hard part is not only writing code. The hard part is understanding context, owning consequences, making trade-offs, protecting users, and taking responsibility when something goes wrong.

An AI agent can execute an action.

A human owns the outcome.

That difference matters.

What is an AI agent?

A simple chatbot answers a prompt.

An AI agent goes further. It can reason over a goal, choose tools, call APIs, read files, modify systems, and continue working through multiple steps.

Example:

Goal: Fix the failing payment pipeline

Agent actions:
1. Read the error logs
2. Search the codebase
3. Modify a retry function
4. Run tests
5. Open a pull request
6. Suggest deployment

That looks useful. And it is.

But now imagine the same agent has access to production credentials, deployment permissions, customer data, or database admin APIs.

Suddenly this is not just automation.

It is operational risk.

The dangerous question is not “Can the agent do it?”

The dangerous question is:

What happens when the agent is confidently wrong?

Humans make mistakes too. But production engineering has decades of safety patterns around human mistakes: code review, staging, rollback, access control, audit logs, incident response, separation of duties, and postmortems.

AI agents need the same discipline.

Actually, they need more.

Because agents can fail in strange ways:

Wrong assumption
   ↓
Wrong plan
   ↓
Wrong tool call
   ↓
Wrong production action
   ↓
Real customer impact

The risk is not that an AI agent is “evil.”

The risk is that it is useful enough to be trusted, but unreliable enough to be dangerous.

A critical production error example

Imagine this scenario:

User: Clean old test data from the database.

Agent:
- Finds a database token
- Misunderstands "test data"
- Connects to production
- Runs a destructive delete query
- Removes real customer records

The agent did not “intend” to destroy production.

But production does not care about intention.

Production cares about impact.

A wrong command from a human and a wrong command from an AI agent can both delete the same database.

That is why we should never give an AI agent unlimited access just because it gives smart answers in a chat window.

Simple architecture schema for safer agents

A production-grade AI agent should not connect directly to critical systems.

It should go through permission layers, approval gates, monitoring, and rollback mechanisms.

flowchart TD
    User[Human User] --> Agent[AI Agent]
    Agent --> Planner[Planner / Reasoning Layer]
    Planner --> Policy[Policy & Permission Engine]
    Policy -->|Read-only actions| Tools[Safe Tools]
    Policy -->|Risky actions| Approval[Human Approval Gate]
    Approval --> Tools
    Tools --> Logs[Action Ledger / Audit Logs]
    Tools --> Sandbox[Staging or Sandbox First]
    Sandbox --> Deploy[Production Deployment]
    Deploy --> Monitor[Monitoring & Alerts]
    Monitor --> Rollback[Rollback / Kill Switch]

The key idea:

The agent can suggest. The system controls. The human approves critical actions.

Agent safety policy schema

Before deploying an agent, define its permissions like you would define infrastructure, security, or API contracts.

Here is a simple YAML-style schema:

agent:
  name: production-assistant
  purpose: "Help engineers investigate issues and propose fixes"
  autonomy_level: supervised

permissions:
  read:
    - logs
    - metrics
    - source_code
    - documentation

  write:
    - draft_pull_request
    - create_ticket
    - comment_on_incident

  forbidden:
    - delete_database
    - modify_customer_data
    - deploy_to_production_without_approval
    - rotate_secrets
    - change_billing_rules

approval_required_for:
  - production_deploy
  - database_migration
  - infrastructure_change
  - customer_notification
  - security_policy_change

observability:
  action_ledger: true
  tool_call_logging: true
  prompt_and_response_audit: true
  alert_on_policy_violation: true

recovery:
  rollback_required: true
  snapshot_before_change: true
  kill_switch: true

This is not over-engineering.

This is basic survival.

If an agent can touch production, it must be treated like a production actor.

Risk formula for AI agents

A simple way to think about agent risk:

Risk = Autonomy × Permission × Irreversibility × Blast Radius

An agent that summarizes logs has low risk.

An agent that can deploy code has medium risk.

An agent that can modify production databases has high risk.

An agent that can modify production databases without approval is a disaster waiting to happen.

What famous tech people are really warning us about

Linus Torvalds has been skeptical of AI hype. His point is important for engineers: do not confuse demos with real-world reliability.

A demo can look magical.

Production is where the truth appears.

Jensen Huang has argued that AI will not simply remove engineers, but increase what productive teams can build. I agree with that more than the “AI will replace everyone” narrative.

The future is not fewer humans.

The future is humans with more powerful tools — and more responsibility.

Yann LeCun’s work also reminds us that current AI systems are still not equivalent to human intelligence. They do not learn from the world like humans and animals do. They do not truly understand business context, social consequences, or moral responsibility.

Sam Altman has said that AI agents may “join the workforce.” That wording is interesting.

Join.

Not replace.

That is the mindset engineering teams should adopt.

Why humans still matter

Humans are not valuable only because they type code.

Humans are valuable because they can ask:

Should we do this?
Who is affected?
What happens if this fails?
Is this legal?
Is this fair?
Can we recover?
Are we solving the right problem?

AI agents are good at generating possible actions.

Humans are responsible for choosing acceptable actions.

That is the boundary.

Production checklist before using AI agents

Before allowing an AI agent into your engineering workflow, ask:

[ ] Does the agent have least-privilege access?
[ ] Can it access production secrets?
[ ] Can it perform destructive actions?
[ ] Are dangerous actions blocked by policy?
[ ] Is human approval required for production changes?
[ ] Are all tool calls logged?
[ ] Can we replay what happened during an incident?
[ ] Is there a rollback plan?
[ ] Is there a kill switch?
[ ] Was the agent tested against prompt injection?
[ ] Does it run in staging before production?
[ ] Are engineers trained to verify its output?

If the answer to these questions is “no,” the agent is not ready for production.

It is ready for a sandbox.

The real future: human + agent

AI agents will change software engineering.

They will make some tasks faster. They will reduce repetitive work. They will help small teams move like bigger teams. They will help developers understand unfamiliar codebases faster.

But they should not replace human judgment.

The best engineering teams will not be the teams that blindly automate everything.

The best teams will be the ones that know what to automate, what to supervise, and what must always remain a human decision.

AI agents are powerful.

But power without control is not intelligence.

It is risk.

So no, AI agents will not replace humans.

But teams that understand how to safely use agents may replace teams that do not.

That is the real shift.

I Built a macOS GUI App to Find Instagram Unfollowers

Ghazi saoudi — Sat, 27 Jun 2026 22:33:04 +0000

Introduction

Managing an Instagram following list can become messy over time.

You follow people, some follow you back, some do not, and eventually it becomes difficult to know who is actually mutual. I wanted to build a simple desktop tool that makes this easier without sending user data to an external server.

That is why I built InstaClean, a macOS GUI application that helps users find Instagram accounts that do not follow them back and unfollow selected accounts from a local interface.

The goal was simple:

Build a clean, local, dark-mode desktop app for checking Instagram unfollowers.

What the App Does

InstaClean scans your Instagram following list and compares it with your followers list.

Then it shows the accounts that you follow but that do not follow you back.

The app includes:

A dark modern interface inspired by Instagram
A scan button to detect non-followers
Search functionality
Pagination for easier navigation
Multi-select checkboxes
An “Unfollow Selected” button
Local execution, meaning data stays on your machine

The idea was to make the workflow fast and simple:

Open the app
Scan your account
Review the results
Select accounts
Unfollow only the ones you choose

Why I Built It as a Desktop App

I could have built this as a web app, but I wanted the project to stay local.

A desktop app made more sense because:

users do not need to upload their Instagram data anywhere
the app can run directly on macOS
the interface feels more private
setup is simple for Python users
the project can be packaged later as a .app

Privacy was one of the main design goals. The app does not need a separate backend server, database, or hosted API.

Everything runs locally.

Tech Stack

The project uses Python and a desktop GUI approach.

The basic stack is:

Python 3.9+ for the application logic
macOS as the target platform
Instagram web session cookies for authenticated requests
py2app as an optional tool for generating a macOS .app

The project can be run directly with:

python app.py

For users who want a real macOS application bundle, it can also be packaged with:

pip install py2app
python setup.py py2app

The generated app is placed inside the dist/ folder.

Main Features

1. Scan for accounts that do not follow back

The main feature is the scan system.

When the user clicks Scan Now, the app checks the account’s following and followers data, then displays users who are not following back.

This makes the app useful for people who want to clean their following list manually instead of scrolling through Instagram one account at a time.

2. Search bar

When the result list is long, searching becomes important.

The app includes a search bar so users can quickly filter accounts by username.

This makes the interface much easier to use when there are many results.

3. Pagination

Instead of displaying every result at once, the app uses pagination.

Each page shows a limited number of accounts, which keeps the interface cleaner and easier to navigate.

This also improves usability because the user is not overwhelmed by a huge list.

4. Multi-select unfollow

The app allows users to select multiple accounts and then click Unfollow Selected.

This is faster than unfollowing one by one, but it still gives the user control because they choose which accounts to remove.

5. Local-first design

One of the most important decisions was keeping the app local.

The app is designed so user data stays on the machine. There is no external database, no cloud processing, and no separate server.

For a tool that interacts with a personal social media account, this matters a lot.

Installation

The project can be installed by cloning the repository:

git clone https://github.com/ghazy001/InstaClean.git
cd InstaClean

Then install the Python dependencies:

pip install -r requirements.txt

After that, configure the required Instagram session values inside the app.

The app needs:

CSRFTOKEN = "your_csrftoken"
SESSIONID = "your_sessionid"
DS_USER_ID = "your_user_id"

These values come from your own browser session after logging in to Instagram.

Important: these values should be treated like sensitive credentials. Never share them, never commit them to GitHub, and never publish them in screenshots.

A better future improvement would be to move them into a .env file instead of writing them directly in the code.

Running the App

After setup, the app can be started with:

python app.py

Once the GUI opens:

Click Scan Now
Wait for the app to load accounts that do not follow back
Use the search bar if needed
Select the accounts you want to unfollow
Click Unfollow Selected

The app gives the user a more organized way to review accounts before taking action.

Important Notes

This project uses Instagram’s unofficial web API through the user’s own browser cookies.

Because of that, there are some important limitations:

The app is not officially approved by Meta
Instagram may change its internal endpoints
Too many unfollow actions can trigger temporary restrictions
Users should avoid aggressive automation
Cookies must be kept private

This project should be used responsibly and only with your own Instagram account.

What I Learned

Building this app taught me a lot about combining GUI development, local automation, and user-focused design.

1. A simple GUI can make automation safer

Instead of blindly unfollowing accounts from a script, a GUI gives the user control.

The user can review results, search names, select accounts manually, and decide what to do.

That makes the tool more transparent.

2. Pagination improves usability

At first, it may seem easy to show every result in one list.

But if the list is large, the interface becomes messy.

Pagination makes the app cleaner and easier to use.

3. Local apps are still useful

Not every project needs to be a web app.

For personal tools, desktop apps can be a great choice because they are private, direct, and easy to run.

4. Credentials should be handled carefully

Using browser cookies works, but it also creates security responsibility.

A future version should avoid hardcoding cookies and instead use environment variables or a local configuration file ignored by Git.

Possible Improvements

There are several improvements I would like to add in the future:

Store cookies in a .env file
Add better error handling for expired sessions
Add confirmation dialogs before unfollowing
Add rate limiting to reduce the risk of temporary blocks
Add a progress bar during scanning
Add export to CSV
Improve packaging as a macOS .app
Add a safer login/session setup flow
Add light mode and theme customization

These features would make the app more polished and safer to use.

Final Thoughts

InstaClean started as a simple idea: make it easier to see who does not follow you back on Instagram.

But it became a useful exercise in building a local desktop app with Python, designing a clean GUI, handling user interaction, and thinking carefully about privacy.

The most important lesson from this project is that automation tools should not just be powerful. They should also be understandable, controlled, and respectful of user privacy.

For me, this was a fun project that combined Python, GUI development, and real-world social media workflow automation into one practical macOS app.

Building an Artist Attribution Model with PyTorch and ResNet-50

Ghazi saoudi — Sat, 27 Jun 2026 22:21:53 +0000

Introduction

Can an AI model look at a painting and predict who created it?

That was the main idea behind this project: an artist attribution system built with PyTorch and ResNet-50. The goal was to train a deep learning model on a dataset of paintings and allow it to predict the most likely artist behind a new image.

Instead of building a convolutional neural network from scratch, I used transfer learning with a pretrained ResNet-50 model. This made the project more practical, faster to train, and easier to adapt to a custom art dataset.

In this article, I’ll walk through the idea, project structure, training process, inference flow, and the lessons learned while building it.

What the Project Does

The project classifies paintings by artist.

Given an input image, the model predicts:

the most likely artist
the confidence score
the top 3 possible artist guesses

Example output:

🎨 Predicted artist: Vincent van Gogh
🔒 Confidence: 0.87
🔎 Top 3 guesses:
 - Vincent van Gogh (0.874)
 - Claude Monet (0.054)
 - Paul Cézanne (0.032)

This makes the project useful as a practical introduction to computer vision, fine-tuning, and image classification.

Why ResNet-50?

ResNet-50 is a powerful convolutional neural network architecture that has already learned useful visual patterns from ImageNet.

For this project, using a pretrained model made sense because painting classification requires the model to understand visual features such as:

brush strokes
color palettes
composition
texture
artistic style
recurring visual patterns

Training a deep model from zero would require a much larger dataset and more compute. Transfer learning allowed me to reuse the knowledge from ResNet-50 and adapt it to the artist classification task.

Main Features

The project includes several useful features:

Transfer learning with ResNet-50
Safe image loading to skip corrupted images
Support for CUDA, Apple Silicon M-series, and CPU
Training and inference scripts
Top-3 prediction output
Colab notebook support for cloud training

This makes the project flexible enough to run locally or in a cloud notebook environment.

Project Structure

The repository is organized like this:

artist-classification/
├── dataset/              # dataset folder
├── train.py              # training script
├── predict.py            # inference script
├── artist_model.pth      # trained model weights
├── README.md
└── test.jpg

The dataset is not included directly in the repository because of its size. After downloading it, the expected folder structure is:

dataset/
├── train/
│   ├── artist_1/
│   ├── artist_2/
│   └── ...
└── val/
    ├── artist_1/
    ├── artist_2/
    └── ...

This structure is important because image classification tools in PyTorch often rely on folder names as class labels.

For example, if the folder is named Vincent_van_Gogh, the model can treat that folder as one class.

Installing Requirements

The project uses a simple Python setup.

Install the required dependencies:

pip install torch torchvision pillow

The main libraries are:

torch for deep learning
torchvision for pretrained models and image transforms
Pillow for image loading and processing

Training the Model

To train the model locally, run:

python3 train.py

The training script handles several steps:

Detects the available device
Loads the painting dataset
Applies image transformations
Fine-tunes ResNet-50
Saves the trained model as artist_model.pth

One detail I liked about this project is that it supports multiple environments:

CUDA for NVIDIA GPUs
MPS for Apple Silicon Macs
CPU as a fallback

That makes the project easier to run across different machines.

Running Inference

After training, you can classify a test image with:

python3 predict.py

The prediction script loads the trained model and runs inference on an image.

Instead of only returning one answer, it gives the top 3 predictions. This is useful because art attribution can be uncertain. Two artists may have similar visual styles, especially if they belong to the same movement or period.

A Top-3 output gives more context than a single prediction.

What I Learned

This project helped me understand several important deep learning concepts.

1. Transfer learning saves time

Starting from a pretrained ResNet-50 model made the project much more realistic. The model already understands general image features, so the training process focuses on adapting those features to paintings.

2. Dataset structure matters

For image classification, clean folder organization is very important. If the dataset is not structured correctly, training can fail or produce incorrect labels.

A simple structure like this works well:

train/class_name/
val/class_name/

3. Inference should be user-friendly

A model prediction is more useful when it includes confidence scores and alternative guesses.

Instead of only printing:

Vincent van Gogh

the project prints:

Vincent van Gogh (0.874)
Claude Monet (0.054)
Paul Cézanne (0.032)

This makes the output easier to understand and debug.

4. Hardware support improves accessibility

Not everyone has the same machine. Supporting CUDA, Apple Silicon, and CPU makes the project easier for more developers to try.

Possible Improvements

There are several ways this project could be improved in the future:

Add a Streamlit or Gradio web interface
Include evaluation metrics such as accuracy and confusion matrix
Add data augmentation for better generalization
Support batch prediction for multiple images
Add model checkpointing during training
Deploy the model as an API
Compare ResNet-50 with EfficientNet or Vision Transformers

A simple web interface would make the project especially impressive because users could upload a painting and instantly see the predicted artist.

Final Thoughts

This project was a great way to combine art and machine learning.

By using PyTorch, transfer learning, and ResNet-50, I built a model that can classify paintings by artist and return the top predictions with confidence scores.

The most important lesson is that deep learning projects do not always need to start from scratch. With transfer learning, we can build useful and interesting computer vision applications faster while still learning the core ideas behind model training, inference, and evaluation.

If you are learning PyTorch or computer vision, building an artist classification model is a fun and practical project to try.