DEV Community: Jihad Abu Zuhri

Refactoring in the AI Era: Code Smells Software Engineers Should Still Know

Jihad Abu Zuhri — Tue, 23 Jun 2026 06:45:12 +0000

AI coding agents have changed the way we write software. Today, you can ask an agent to extract a method, rename variables, reduce duplication, generate tests, or even redesign part of a class. What used to take hours can sometimes be done in minutes.

But there is a catch.

AI can refactor code faster, but it does not automatically know what should be refactored, why it matters, or which design trade-off is best for your system. That responsibility still belongs to us as developers.

The more we understand refactoring and code smells, the better we can guide AI tools instead of blindly accepting their suggestions. Clean code skills are not less important because of AI. They are more important, because now we are not only writing code, we are also reviewing, directing, and validating code produced by tools.

🔁 Refactoring Is Not Rewriting

Refactoring means improving the internal structure of code without changing its external behavior. This distinction is important because if the behavior changes, then you are adding a feature, fixing a bug, or changing functionality. Refactoring keeps the behavior the same while making the code easier to understand, test, and change.

For example:

public decimal Calc(decimal p, decimal d)
{
    return p - (p * d);
}

This method works, but it forces the reader to guess what p and d mean. A simple refactoring improves the name and intent:

public decimal CalculateDiscountedPrice(decimal price, decimal discountRate)
{
    return price - (price * discountRate);
}

The logic did not change. The code simply became easier to understand. This is exactly the type of improvement AI agents can help with, but only if we know what to ask for.

🧠 Why Refactoring Still Matters

Working code is not always maintainable code. A method can pass all tests and still be difficult to read. A class can work correctly and still have too many responsibilities. A service can produce the right result and still be painful to extend.

Refactoring helps us:

📖 Make code easier to read
🧪 Make code easier to test
🔧 Make future changes easier
♻️ Reduce duplication
🐛 Lower the risk of bugs
🚀 Keep development speed healthy over time

In the AI era, this matters even more. AI tools are very good at producing code quickly, which means teams can also produce messy code quickly. If we do not review, refactor, and simplify continuously, the codebase can become harder to maintain at a much faster rate.

👃 Code Smells Are Signals, Not Rules

A code smell is a sign that something might be wrong with the design. It does not always mean the code is broken, and it does not mean you must refactor immediately. It simply tells you to slow down and look closer.

Common code smells include poor names, long methods, duplicate code, deeply nested conditionals, primitive obsession, large classes, and hidden dependencies. These smells are especially useful when working with AI agents because they help you give better instructions.

Instead of giving a vague prompt like this:

Clean this code.

You can give the agent a more specific instruction:

This method has too much conditional complexity.
Refactor it using guard clauses and extract smaller methods.
Keep the behavior the same.

That is a much better prompt because it describes the problem, the preferred refactoring direction, and the most important constraint: behavior must stay the same.

🏷️ Smell 1: Poor Names

Poor names make code harder to understand than it needs to be. The code might be technically correct, but if the reader has to guess what each variable or method means, the code is still creating friction.

public decimal Calc(decimal x, decimal y)
{
    return x * y;
}

The method is simple, but the intent is unclear. What are x and y? Are they price and quantity, width and height, or something else?

A better version makes the meaning obvious:

public decimal CalculateTotalPrice(decimal unitPrice, decimal quantity)
{
    return unitPrice * quantity;
}

Nothing changed except the names, but the code is now easier to read. This is one of the safest refactorings to ask an AI agent for.

Rename variables and methods to make their intent clearer.
Do not change the behavior.

Good names reduce the need for comments and make future changes easier. When naming is clear, the code starts explaining itself.

🧱 Smell 2: Primitive Obsession

Primitive obsession happens when we use primitive types like string, int, or decimal for domain concepts that deserve their own types. This usually makes the code easier to write at first, but harder to protect later.

public void CreateUser(string email, string role)
{
    if (!email.Contains("@"))
        throw new ArgumentException("Invalid email.");

    if (role != "Admin" && role != "Customer")
        throw new ArgumentException("Invalid role.");

    // Create user
}

This method accepts any string. That means invalid emails and invalid roles can easily move through the system unless every caller remembers to validate them correctly. The email validation here is intentionally simplified for the example, but the design issue is still real.

A cleaner model makes the domain concept explicit:

public sealed class EmailAddress
{
    public string Value { get; }

    public EmailAddress(string value)
    {
        if (string.IsNullOrWhiteSpace(value) || !value.Contains("@"))
            throw new ArgumentException("Invalid email address.", nameof(value));

        Value = value;
    }

    public override string ToString() => Value;
}

Now the method becomes clearer:

public void CreateUser(EmailAddress email, UserRole role)
{
    // Create user
}

public enum UserRole
{
    Admin,
    Customer
}

This makes invalid states harder to represent and keeps validation closer to the concept it protects. A useful AI prompt for this smell could be:

Replace primitive parameters with small domain types where it improves clarity.
Keep validation close to the domain concept.

📏 Smell 3: Long Methods

Long methods usually do too much. They often mix validation, business rules, persistence, logging, notifications, and formatting in one place. The result is a method that works, but is difficult to understand and risky to change.

public void ProcessOrder(Order order)
{
    if (order == null)
        throw new ArgumentNullException(nameof(order));

    if (!order.Items.Any())
        throw new InvalidOperationException("Order must contain at least one item.");

    var subtotal = order.Items.Sum(item => item.Price * item.Quantity);

    if (subtotal > 100)
        subtotal -= subtotal * 0.10m;

    order.Total = subtotal;
    order.Status = OrderStatus.Processed;

    _orderRepository.Save(order);
    _emailService.SendOrderConfirmation(order.CustomerEmail, order.Id);
}

This method validates the order, calculates a total, applies a discount, changes state, saves data, and sends an email. A better approach is to extract smaller methods with intention-revealing names.

public void ProcessOrder(Order order)
{
    ValidateOrder(order);

    var total = CalculateTotal(order);

    order.ApplyTotal(total);
    order.MarkAsProcessed();

    _orderRepository.Save(order);
    SendConfirmation(order);
}

private static void ValidateOrder(Order order)
{
    if (order == null)
        throw new ArgumentNullException(nameof(order));

    if (!order.Items.Any())
        throw new InvalidOperationException("Order must contain at least one item.");
}

private static decimal CalculateTotal(Order order)
{
    var subtotal = order.Items.Sum(item => item.Price * item.Quantity);

    return subtotal > 100
        ? subtotal - (subtotal * 0.10m)
        : subtotal;
}

private void SendConfirmation(Order order)
{
    _emailService.SendOrderConfirmation(order.CustomerEmail, order.Id);
}

Now the main method reads like a workflow. The details still exist, but they are hidden behind clear method names. This is a great place to use an AI agent, as long as the instruction is specific.

Refactor this long method into smaller private methods.
Use intention-revealing names.
Keep the public behavior unchanged.

♻️ Smell 4: Duplicate Code

Duplicate code is dangerous because every future change must be repeated in multiple places. Copy and paste can feel productive in the moment, but it often creates maintenance problems later.

public void RegisterUser(string email, string password)
{
    if (string.IsNullOrWhiteSpace(email))
        throw new ArgumentException("Email is required.", nameof(email));

    if (string.IsNullOrWhiteSpace(password))
        throw new ArgumentException("Password is required.", nameof(password));

    // Register user
}

If the same validation appears across many methods, we can extract it into a reusable helper:

private static void EnsureNotEmpty(string value, string parameterName)
{
    if (string.IsNullOrWhiteSpace(value))
        throw new ArgumentException($"{parameterName} is required.", parameterName);
}

Then the original method becomes shorter and more consistent:

public void RegisterUser(string email, string password)
{
    EnsureNotEmpty(email, nameof(email));
    EnsureNotEmpty(password, nameof(password));

    // Register user
}

Before removing duplication, make sure it is real duplication. Sometimes two blocks look similar today but represent different business rules that may change independently later. That distinction matters.

Find real duplication in this class.
Extract shared behavior only when the duplicated logic represents the same business rule.

🌲 Smell 5: Deeply Nested Conditionals

Nested conditionals make code harder to scan because the reader has to keep multiple branches in mind. The deeper the nesting gets, the easier it becomes to miss the main purpose of the method.

public decimal CalculateDiscount(Customer customer, Order order)
{
    if (customer != null)
    {
        if (customer.IsActive)
        {
            if (order.Total > 100)
            {
                if (customer.IsPremium)
                {
                    return order.Total * 0.15m;
                }

                return order.Total * 0.10m;
            }
        }
    }

    return 0;
}

Guard clauses make the code flatter by handling invalid or uninteresting cases early.

public decimal CalculateDiscount(Customer customer, Order order)
{
    if (customer == null)
        return 0;

    if (!customer.IsActive)
        return 0;

    if (order.Total <= 100)
        return 0;

    return customer.IsPremium
        ? order.Total * 0.15m
        : order.Total * 0.10m;
}

The behavior is the same, but the main logic is easier to see. This is another refactoring where AI can help quickly, but the prompt should make it clear that all branches must keep the same result.

Reduce nesting in this method using guard clauses.
Do not change the result of any branch.

🏢 Smell 6: Large Classes

A large class often means too many responsibilities. Classes with names like Manager, Helper, or Processor are not always bad, but they often become places where unrelated behavior accumulates over time.

public class OrderManager
{
    public void CreateOrder() { }
    public void ValidatePayment() { }
    public void SaveToDatabase() { }
    public void SendEmail() { }
    public void GenerateInvoice() { }
    public void ApplyDiscount() { }
}

This class may be difficult to test and maintain because many different reasons can cause it to change. Payment rules, invoice generation, email content, persistence, and discounts are separate concerns.

A cleaner design separates responsibilities:

public class OrderService
{
    private readonly IPaymentValidator _paymentValidator;
    private readonly IInvoiceGenerator _invoiceGenerator;
    private readonly IEmailSender _emailSender;

    public OrderService(
        IPaymentValidator paymentValidator,
        IInvoiceGenerator invoiceGenerator,
        IEmailSender emailSender)
    {
        _paymentValidator = paymentValidator;
        _invoiceGenerator = invoiceGenerator;
        _emailSender = emailSender;
    }

    public void CreateOrder(Order order)
    {
        _paymentValidator.Validate(order.Payment);
        _invoiceGenerator.Generate(order);
        _emailSender.SendOrderConfirmation(order.CustomerEmail);
    }
}

Now each dependency has a clearer responsibility. If payment rules change, you know where to look. If invoice generation changes, that logic has its own place. The goal is not to create too many tiny classes, but to avoid one class becoming responsible for everything.

Review this class for multiple responsibilities.
Suggest possible extracted classes, but keep the design simple.
Do not over-engineer it.

🔒 Smell 7: Hidden Dependencies

Hidden dependencies make code harder to test and harder to replace. They often appear when a class creates its own dependencies directly instead of receiving them from the outside.

public class ReportService
{
    public void GenerateReport()
    {
        var fileWriter = new FileWriter();

        fileWriter.Write("report.txt", "Report content");
    }
}

The class creates FileWriter directly, so it is tightly coupled to that implementation. This makes it harder to replace the writer in tests or switch to another storage mechanism later.

A better version depends on an abstraction:

public interface IFileWriter
{
    void Write(string path, string content);
}

Then the dependency is injected through the constructor:

public class ReportService
{
    private readonly IFileWriter _fileWriter;

    public ReportService(IFileWriter fileWriter)
    {
        _fileWriter = fileWriter;
    }

    public void GenerateReport()
    {
        _fileWriter.Write("report.txt", "Report content");
    }
}

Now the dependency is explicit. The class clearly communicates what it needs, and tests can provide a fake implementation.

Identify hidden dependencies created with new inside this class.
Refactor them into constructor-injected abstractions where appropriate.

🤖 How to Guide an AI Agent During Refactoring

AI agents are powerful, but vague instructions produce vague results. If you ask an agent to “make this code cleaner,” it may rename things, move logic around, introduce unnecessary patterns, or accidentally change behavior.

A better approach is to give the agent a specific refactoring goal.

Less helpful:

Make this code cleaner.

More helpful:

Refactor this method by extracting smaller private methods.
Keep the behavior unchanged.
Preserve public method signatures.
Do not introduce new design patterns unless necessary.

You can also ask the agent to analyze before changing anything:

Analyze this class for code smells.
List the smells first.
Then suggest a small refactoring plan.
Do not change the code yet.

This keeps you in control. The agent becomes a refactoring assistant, not the designer of your entire system. You decide which smell matters, which refactoring is appropriate, and how much change is safe.

🛡️ Refactor Safely

Whether you refactor manually or with AI, the safety rules are the same:

✅ Start from working code
✅ Make sure tests pass
✅ Refactor in small steps
✅ Run tests after each change
✅ Review the diff carefully
✅ Avoid mixing refactoring with behavior changes

This is especially important with AI-generated changes. An agent may produce code that looks cleaner but subtly changes behavior. It might reorder logic, simplify a condition incorrectly, or introduce a new abstraction that does not match the domain.

Your job is to verify the result, not just admire the diff.

🎯 Final Thoughts

AI has made refactoring faster, but it has not removed the need for clean code skills. Actually, it has made those skills more valuable. Developers who understand code smells can guide AI agents with better prompts, review generated changes more effectively, and avoid turning fast code generation into fast technical debt.

The goal is not to ask AI to “clean the code” and accept whatever comes back. The goal is to understand the design well enough to tell the agent what smell you see, what refactoring you want, and what behavior must stay the same.

Clean code in the AI era is not about writing every line yourself. It is about understanding the codebase deeply enough to guide the tools, review the result, and keep the system healthy over time.

📚 References

Understanding Rate Limiting: An Essential Guide for Developers

Jihad Abu Zuhri — Tue, 31 Dec 2024 21:40:34 +0000

What is API Throttling / Rate Limiting?

Rate limiting is a crucial technique used to manage the consumption of resources by an application, an individual user, or an entire service. It plays a vital role in preventing misuse and overuse of resources, ensuring fair distribution among all users, and maintaining the overall stability and performance of the system.

Why Do Applications Rate Limit?

Protection Against DDoS Attacks:
DDoS (Distributed Denial of Service) attacks aim to overwhelm a server with a flood of requests, rendering it unavailable to legitimate users. Rate limiting helps mitigate these attacks by restricting the number of requests a user can make in a given time frame, thus protecting the server from being overwhelmed.

Server Stability and Consistency:
By controlling the load on the server, rate limiting ensures that legitimate traffic can be handled without degradation in performance. This consistency in service delivery is critical for maintaining user satisfaction and trust.

Cost Control:
In cloud environments, resource consumption directly impacts operational costs. Rate limiting helps manage and predict these costs by capping resource usage, preventing unexpected spikes in expenditure.

Rate Limiting Techniques

Let's explore various rate-limiting techniques that can be implemented to ensure efficient resource management:

1. Concurrency Limiter

Description:
This technique controls the number of concurrent requests being processed at any given time.

Algorithm:

Maintain a counter for the current number of concurrent requests.
Define a maximum concurrency limit.
For each incoming request:
- If the current number of concurrent requests is less than the limit, increment the counter and process the request.
- If the limit is reached, deny the request or queue it for later processing.
Upon completion of the request, decrement the counter to free up space for new requests.

Pseudocode:

class ConcurrencyLimiter {
    int maxConcurrency;
    int currentConcurrency;

    ConcurrencyLimiter(int maxConcurrency) {
        this.maxConcurrency = maxConcurrency;
        this.currentConcurrency = 0;
    }

    bool AllowRequest() {
        if (currentConcurrency < maxConcurrency) {
            currentConcurrency += 1;
            return true;
        } else {
            return false;
        }
    }

    void CompleteRequest() {
        if (currentConcurrency > 0) {
            currentConcurrency -= 1;
        }
    }
}

2. Fair Queuing

Description:
This technique ensures fair distribution of requests among multiple clients by maintaining separate queues for each client and processing them in a round-robin fashion.

Algorithm:

Maintain separate queues for each client.
Add each request to the respective client's queue.
Process requests from each client's queue in a round-robin manner.
If a client's queue is empty, skip to the next client.

Pseudocode:

class FairQueuing {
    Dictionary<string, Queue<Request>> clientQueues;
    List<string> clientList;
    int currentClientIndex;

    FairQueuing() {
        this.clientQueues = new Dictionary<string, Queue<Request>>();
        this.clientList = new List<string>();
        this.currentClientIndex = 0;
    }

    void AddRequest(string clientId, Request request) {
        if (!clientQueues.ContainsKey(clientId)) {
            clientQueues[clientId] = new Queue<Request>();
            clientList.Add(clientId);
        }
        clientQueues[clientId].Enqueue(request);
    }

    Request GetNextRequest() {
        while (clientList.Count > 0) {
            string clientId = clientList[currentClientIndex];
            currentClientIndex = (currentClientIndex + 1) % clientList.Count;

            if (clientQueues[clientId].Count > 0) {
                return clientQueues[clientId].Dequeue();
            }
        }
        return null;
    }
}

3. Fixed Window

Description:
This technique limits the number of requests in a fixed time window (e.g., 100 requests per minute). Once the limit is reached, further requests are denied until the next window.

Algorithm:

Define the maximum number of requests and the size of the time window.
For each request, check the current time against the start of the window.
If the window has elapsed, reset the request count and start a new window.
If the request count is within the limit, allow the request and increment the count.
If the request count exceeds the limit, deny the request.

Pseudocode:

class FixedWindow {
    int maxRequests;
    TimeSpan windowSize;
    DateTime windowStart;
    int requestCount;

    FixedWindow(int maxRequests, TimeSpan windowSize) {
        this.maxRequests = maxRequests;
        this.windowSize = windowSize;
        this.windowStart = DateTime.Now;
        this.requestCount = 0;
    }

    bool AllowRequest() {
        DateTime currentTime = DateTime.Now;

        if ((currentTime - windowStart) > windowSize) {
            windowStart = currentTime;
            requestCount = 0;
        }

        if (requestCount < maxRequests) {
            requestCount += 1;
            return true;
        } else {
            return false;
        }
    }
}

4. Sliding Window

Description:
Similar to the Fixed Window technique, but uses a rolling time window to more accurately account for request times, providing a smoother rate limit.

Algorithm:

Define the maximum number of requests and the size of the time window.
For each request, remove timestamps of requests outside the current window.
If the number of requests within the window is within the limit, allow the request and add the current timestamp.
If the number of requests exceeds the limit, deny the request.

Pseudocode:

class SlidingWindow {
    int maxRequests;
    TimeSpan windowSize;
    Queue<DateTime> requestTimestamps;

    SlidingWindow(int maxRequests, TimeSpan windowSize) {
        this.maxRequests = maxRequests;
        this.windowSize = windowSize;
        this.requestTimestamps = new Queue<DateTime>();
    }

    bool AllowRequest() {
        DateTime currentTime = DateTime.Now;

        while (requestTimestamps.Count > 0 
            && (currentTime - requestTimestamps.Peek()) > windowSize) {
            requestTimestamps.Dequeue();
        }

        if (requestTimestamps.Count < maxRequests) {
            requestTimestamps.Enqueue(currentTime);
            return true;
        } else {
            return false;
        }
    }
}

5. Token Bucket

Description:
Tokens are added to a bucket at a fixed rate (e.g., 10 tokens per second). Each request consumes a token. When no tokens are available, requests are either denied or delayed.

Algorithm:

Initialize the bucket with a certain capacity and refill rate.
For each request, calculate the number of tokens to be added based on the elapsed time since the last refill.
If the bucket has enough tokens, allow the request and decrement the token count.
If the bucket does not have enough tokens, deny the request.

Pseudocode:

class TokenBucket {
    int capacity;
    double tokens;
    double refillRate;
    DateTime lastRefillTime;

    TokenBucket(int capacity, double refillRate) {
        this.capacity = capacity;
        this.refillRate = refillRate;
        this.tokens = capacity;
        this.lastRefillTime = DateTime.Now;
    }

    bool AllowRequest() {
        DateTime currentTime = DateTime.Now;
        double elapsedTime = (currentTime - lastRefillTime).TotalSeconds;

        tokens = Math.Min(capacity, tokens + elapsedTime * refillRate);
        lastRefillTime = currentTime;

        if (tokens >= 1) {
            tokens -= 1;
            return true;
        } else {
            return false;
        }
    }
}

6. Leaky Bucket

Description:
Similar to the Token Bucket, but ensures a smooth outflow of requests. Excess requests are buffered and processed at a steady rate.

Algorithm:

Initialize the bucket with a certain capacity and leak rate.
For each request, calculate the amount of water (requests) leaked since the last check.
If the bucket has enough capacity, allow the request and increase the water level.
If the bucket is full, deny the request.

Pseudocode:

class LeakyBucket {
    int capacity;
    double leakRate;
    double waterLevel;
    DateTime lastChecked;

    LeakyBucket(int capacity, double leakRate) {
        this.capacity = capacity;
        this.leakRate = leakRate;
        this.waterLevel = 0;
        this.lastChecked = DateTime.Now;
    }

    bool AllowRequest() {
        DateTime currentTime = DateTime.Now;
        double elapsedTime = (currentTime - lastChecked).TotalSeconds;
        lastChecked = currentTime;
        double leakedWater = elapsedTime * leakRate;
        waterLevel = Math.Max(0, waterLevel - leakedWater);

        if (waterLevel < capacity) {
            waterLevel += 1;
            return true;
        } else {
            return false;
        }
    }
}

Rate Limiting Implications

Server Perspective

Decide on an Identity for Throttling:
- Choose an identifier such as IP address, client name, or API key to apply rate limits.
Determine Your Application's Traffic Volume:
- Assess the traffic load and establish the maximum capacity your server can manage without performance degradation.
Implement Rate Limiting:
- Utilize existing rate-limiting libraries tailored for your programming language or develop custom solutions to manage request rates effectively.

Client Perspective

Use Retry Policies:
- Exponential Backoff:
- Gradually increase the wait time between retries to reduce server load.
- Jitter:
- Introduce randomness in the wait time to prevent synchronized retries that could overwhelm the server.
- Retry Limit:
- Define a maximum number of retries to avoid infinite retry loops and potential resource exhaustion.
Be Fault Tolerant:
- Design your application to handle failures gracefully by providing fallback mechanisms and ensuring continuity of service even during rate limiting scenarios.

Learning Resources

Refer to the following resources if you would like to learn more about rate limiting and API throttling:

Polly Rate Limiting Strategies and Techniques:
- Explore Polly's comprehensive guide on implementing rate limiting strategies and techniques in .NET applications.
Rate Limiting Pattern - Azure Architecture Center:
- This article from Microsoft's Azure Architecture Center provides detailed insights into the rate-limiting pattern, including its implementation and benefits in cloud-based applications.
ASP.NET Core Performance - Rate Limiting:
- Learn how to implement rate limiting in ASP.NET Core applications to enhance performance and ensure fair resource distribution.