Ethics and Best Practices in AI-Assisted Software Development

AI-based coding assistants are no longer a curiosity. Today they write complete functions, propose tests, explain errors, and on some teams generate most of the new code. The problem is not the tool: it is that many organizations adopted it without changing anything else. The same review process, the same quality standards, and the same idea of who is accountable when something fails remain in place.

This article is not about whether to use AI for programming. It is about how to use it without losing control of the code, without dragging in legal risks, and without the team losing its understanding of what it maintains. Ethics, in this context, is above all a matter of accountability and professional judgment.

Accountability is not delegated to the tool

The first misunderstanding is believing that if an assistant wrote the code, accountability is diluted. That is not the case. Whoever signs a commit, whoever approves a pull request, and whoever puts the system into production is accountable for what that code does, regardless of which part was generated automatically.

This leads to a simple rule that is hard to uphold in practice: no one should approve code they do not understand. If a generated fragment is opaque to the reviewer, the problem is not minor. Code that no one understands is code that no one can debug at three in the morning.

• The author of the commit is accountable for the content, even if an AI drafted it.
• The reviewer must be able to explain what the change does and why it is correct.
• If no one on the team can explain it, the change is not ready for production.

It is worth stating this explicitly in internal policies. When expectations are not written down, each person improvises and the quality of the result depends on the individual judgment of whoever is at the keyboard that day.

Verify before trusting: hallucinations, dependencies, and licenses

Models generate plausible code, not necessarily correct code. They invent methods that do not exist in the version of the library we use, propose packages with names that sound reasonable but are not the official ones, and sometimes suggest configurations that work in an example and fail in production.

The case of dependencies deserves special attention. A package suggested by an assistant may not exist, may be abandoned, or, worse, may have been registered by someone with impersonation intentions. Before adding a dependency, it is worth checking who maintains it, when it was last published, how many downloads it has, and whether the name exactly matches the official project.

The other front is licensing. Generated code may reproduce fragments with terms of use that are not compatible with the project. On teams that distribute software to third parties or work with open-source components, this is not a theoretical detail: it is a risk discovered late, when clients are already using the product.

• Cross-check every suggested API against the documentation for the version we actually use.
• Review the origin of any new dependency before incorporating it.
• Maintain an inventory of dependencies and their licenses, and review it when something new comes in.
• Treat generated code as third-party code: it is read, tested, and adapted.

Sensitive data and confidentiality

One of the most delicate decisions is what gets pasted into the assistant's window. Proprietary code, credentials, connection strings, customer data, database schemas with real information: all of this can leave the organization without anyone noticing.

The question to answer before adopting any tool is where the data is processed, whether it is stored, for how long, and whether it is used to train models. The answer varies by provider and by the plan contracted, and it is not always the same for the free version as for the enterprise version.

In practice, this is resolved with clear rules and habits:

• Define which environments and repositories may use external assistants.
• Prohibit pasting credentials, personal data, or extracts from real databases.
• Anonymize or substitute data before asking for help with an error that includes real records.
• Prefer tools with data processing agreements and configurable retention when working with client code.

It is also worth reviewing which editor extensions have access to the code. An assistant installed without judgment may have more permissions than necessary and send more context than we assume.

Quality, testing, and technical debt

AI accelerates code writing, not understanding of the problem. When the volume of code grows faster than the team's capacity to review it, recurring patterns appear: duplicated functions that solve the same thing in three ways, unnecessary abstractions, dependencies added to save twenty lines, and tests that verify the behavior of the generated code instead of the expected behavior of the system.

The antidote is the usual one, applied with more discipline: tests that describe the required behavior, reviews with judgment, and a definition of done that is not negotiated away because things moved faster.

• Write the test first or, at least, the acceptance criteria; then generate the code.
• Reject code in review that cannot be explained, even if it works.
• Watch for duplication: it is the most frequent symptom of mass generation without consolidation.
• Set aside explicit time for refactoring; writing speed does not eliminate that need.

There is a useful and underused indicator: how long it takes someone new to understand a module. If that time grows, the team is accumulating debt even if delivery metrics look good.

Transparency with the team and with the client

Transparency has two audiences. Internally, the team needs to know when a change was generated with assistance, not to penalize it, but to review it more carefully and so that whoever maintains it later knows what to expect. One line in the pull request description is usually enough.

Externally, the conversation depends on the type of product. In systems where decisions affect people—application evaluation, case prioritization, automated customer service—the client and the end user have the right to know what role automation plays and what human review exists. Documenting those decisions is not bureaucracy: it is what allows you to answer when someone asks.

It is also healthy to agree on which uses are out of the question. For example, generating code for a payroll calculation module without specialized review, or automating decisions that have legal effects on a person. Having that list in writing prevents improvised discussions under deadline pressure.

A starting point for the team

You do not need a hundred-page manual. A brief, agreed-upon, and revisable guide that answers five questions is more useful: who is accountable for generated code, what data does not leave the organization, how is code that is not understood reviewed, what tests are required before integrating, and in what cases is the client notified.

AI is a powerful tool and, used well, it improves daily work. But professional judgment remains human: deciding what is accepted, what is tested, and what is documented. A team that preserves that judgment can adopt any assistant without losing control of its software.