AI 輔助軟件開發：為何理解程式碼仍然重要

Artificial intelligence can help us develop software faster. It can produce an initial implementation, suggest tests, explain unfamiliar code, and assist with debugging. These are practical opportunities whose value depends on the work we need to do.

But generating code in seconds and delivering a reliable product are two different outcomes.

The key is learning to use these tools while retaining the ability to understand what they produce. Generated code is a proposal to evaluate. Speed becomes an advantage when you know how to verify the result.

The Benefits of AI Start with a Good Question

Consider a common feature: deleting a document from an application. The request “add a button to delete documents” seems clear. Yet it leaves several questions unanswered.

Who can delete them? The owner, an administrator, or any authenticated user? Should deletion be permanent? What happens if another user is editing the same document?

AI can help us identify these questions. The answers, however, must reflect the product’s actual requirements. If we implicitly accept the assumptions embedded in the code, we risk implementing the wrong feature well.

Software development expertise also means knowing how to turn a request into verifiable rules before choosing classes, components, and libraries.

A Project Is More Than the Sum of Its Files

A solution can be correct in isolation yet poorly suited to the application it belongs to. It might duplicate existing functionality, introduce an unnecessary dependency, or mix user interface logic, data access, and business rules.

Guiding AI therefore requires context: the repository’s structure, conventions, software versions, and the responsibilities of its components. Asking it to “follow best practices” is not enough. We need to understand which choices actually serve the project.

This does not mean designing elaborate architectures for every problem. Recognizing when a simple solution is sufficient is also a design skill.

“It Works on My Screen” Is Only the First Check

A successful demo is useful, but it only tells us about the path we tested. It does not prove that the application handles missing data, network errors, concurrent requests, or unauthorized access.

GitHub’s documentation warns that generated code can appear valid while containing errors or security vulnerabilities, and recommends reviewing and testing it. This is a practical precaution—even when the AI’s explanation sounds convincing. GitHub documentation on the responsible use of code suggestions.

Compilation remains essential: it catches one category of problems. Correctness against requirements and security need additional checks.

A .NET Example: Hiding a Button Does Not Protect a Document

Imagine a Blazor application where only a document’s owner can delete it. The interface correctly hides the button from other users. Everything looks fine during the demo.

But what check runs when a deletion request arrives?

Microsoft explains that AuthorizeView controls the visibility of interface elements; it does not automatically secure the method associated with a button. Authorization must also be enforced in the relevant operation or API. In particular, checks performed in the browser are not a reliable security boundary for protecting server-side data. Blazor security documentation.

The requirement to verify is: “An authenticated user can delete only documents they own.” In an ASP.NET Core authorization handler, the core rule might look like this:

var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
if (context.User.Identity?.IsAuthenticated == true
    && !string.IsNullOrWhiteSpace(userId)
    && string.Equals(userId, resource.OwnerId, StringComparison.Ordinal))
{
    context.Succeed(requirement);
}

This is an excerpt from a small supporting example, rather than a complete authentication system. The user identifier must come from the authenticated server-side identity. The owner must be read from a trusted resource, rather than accepted from the browser. The authorization result must then be enforced before deletion.

In the local example, we verified six cases: the authenticated owner was allowed access; another user, an anonymous user, an unauthenticated identity with the same claim, an identity without an identifier, and a different identifier were denied. These checks exercise the rule using ASP.NET Core’s actual authorization service. They do not test an HTTP endpoint, a database, or a complete Blazor application.

This is where expertise matters: recognizing a missing requirement even when the screen looks correct. In a real application, resource-specific authorization must be integrated into the server-side workflow. Resource-based authorization.

Tests Deserve a Review Too

AI can help us write tests. But if both the implementation and the tests come from the same mistaken interpretation, they may agree with each other without checking the actual requirement.

In the previous example, testing only that the owner can delete the document would be insufficient. We also need to verify that another user cannot.

Expected results must come from the requirements. We can ask AI to identify edge cases, then compare them with documentation, product rules, and observed behavior. A second AI response can assist the review, but it is not proof of correctness.

Optimization Requires Measurement

Shorter code or a more sophisticated solution is not automatically more efficient. To determine whether performance has improved, we need relevant measurements: response times, memory usage, database queries, and behavior under representative workloads.

Productivity gains should also be assessed across the entire task. How many minutes did we save on writing? How many did we spend fixing, integrating, and reviewing? Will the code be understandable when we next need to change it?

We should avoid promises of faster development that supposedly apply to every project. In its February 2026 update, METR considers greater benefits than those observed in its 2025 study likely, but highlights experimental limitations that prevent reliable estimates of their size. Context matters. METR update.

Beginners Can Use AI—with a Method

You do not need to know everything before getting started. AI can support learning by explaining an error, suggesting an exercise, or comparing two solutions. It is useful to ask why a particular choice is appropriate, modify it, and check what changes.

The warning sign comes when we accept code we cannot explain and keep adding fixes without understanding their effects.

We do not need to memorize every API. We need sufficiently strong foundations to find our way, consult reliable sources, and recognize when a more experienced reviewer is needed.

A Checklist Before Accepting AI-Generated Code

• Have I clarified the expected behavior, including errors and permissions?
• Do I understand the main design choices and how they fit into the project?
• Have I checked APIs, dependencies, and compatibility with the versions in use?
• Have I compiled the code and run relevant checks, including negative test cases?
• Are performance claims supported by measurements?
• Could I diagnose a problem or modify this solution later?

Responsibility for the product remains with the people who build and deliver it. Using AI well means delegating tasks while retaining the judgment needed to evaluate the outcome.

What check do you never skip before accepting AI-generated code?

TheBetterWay — Blazor, C#, and .NET, one lesson at a time.

This is the English translation of the original Italian article published on TheBetterWay.