AI Ethics for Developers: 7 Principles to Follow When Building with AI
It’s 5:40 on a Thursday. You’re trying to finish a search endpoint before the weekend, so you ask your AI assistant for a quick implementation. In seconds, you get clean, readable code. It runs. The tests you wrote pass.
You merge it.
Two weeks later, a teammate notices something odd in the logs. The assistant built the SQL query by concatenating the user’s input into a string. Your happy-path tests never tried anything hostile, so nothing caught it.
Nobody was malicious here, and the tool wasn’t broken. The code looked right, it came fast, and the process skipped the part where a human asked, “What could go wrong?”
That gap is what this article is about.
AI Is an Assistant, Not a Decision-Maker
AI tools are good at drafting boilerplate, explaining unfamiliar code, suggesting tests, and untangling error messages. Used well, they save real time.
But they don’t know your threat model, your users, your legal obligations, or what happens when your feature fails at 2 a.m. They produce output that sounds confident whether or not it’s correct.
So treat AI like a fast, well-read junior colleague. You’d use their draft, but you wouldn’t merge it without review. The boundaries below are what that looks like in practice.
1. Human Oversight: Review Everything You Ship
If you can’t explain a block of code, you’re not ready to ship it.
Review AI-generated code the way you’d review a stranger’s pull request. Read it, run it, and test the edges, not just the happy path. Ask what happens with empty input, huge input, malformed input, and input from someone who’s trying to break things.
A useful habit: before accepting a suggestion, summarize what it does in your own words. If you can’t, ask the assistant to explain it, then verify the explanation against the code.
2. Privacy: Know What Leaves Your Machine
The fastest way to debug is to paste everything. That’s also how secrets end up in places they shouldn’t.
Here’s a realistic case. A developer is debugging a failing support chatbot and pastes a real customer conversation into a public AI tool, complete with a name, email address, and order details. The bug gets fixed, but customer data has now left the company’s control.
Don’t paste into public tools:
- API keys, tokens, passwords, or connection strings
- Customer data or logs that contain it
- Proprietary source code or unreleased product plans
- Anything covered by an NDA or internal policy
Instead, redact and anonymize. Replace real values with placeholders, build a minimal reproduction, and check your company’s policy on approved tools. If your organization offers a vetted internal option, use it.
If you’re building an AI feature, the same rule applies to your users. Don’t send their data to a third-party model unless you’ve decided that’s acceptable, told them, and have a legitimate reason.
3. Security: Assume the Code Is Untrusted
AI-generated code can be insecure in ordinary, boring ways. The query below is the kind of thing an assistant might hand you:
Vulnerable SQL query:
query = f"SELECT * FROM users WHERE name = '{name}'"
cursor.execute(query)
It works, and it’s injectable. The fix is a parameterized query:
Safer SQL query:
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))
Watch for other patterns too:
- Hallucinated libraries: Assistants sometimes suggest packages that don’t exist, or names that are close to real ones. Someone can register such a name with malicious code, so verify that a package is real, maintained, and the one you meant before installing it.
- Outdated or risky dependencies: Check versions and known advisories as you would for any dependency.
- Unsafe defaults: Look for disabled certificate checks, overly broad permissions, hardcoded secrets, and missing input validation.
Run your usual safeguards: linters, static analysis, dependency scanning, and code review. AI code doesn’t get a shortcut around them.
4. Fairness: Ask Who Gets Hurt When It’s Wrong
Some features carry more weight than others. A bug in a color picker is an annoyance. A bug in a system that screens résumés, approves loans, flags medical risk, moderates content, or controls access can change someone’s life.
Imagine a team uses an AI-assisted scoring system to shortlist job applicants. It’s trained on past hiring decisions, and it quietly learns to favor patterns that reflect old biases. Nobody wrote a biased rule, but the outcome is biased anyway.
You don’t need a PhD to take this seriously. A few practical steps:
- Test outputs across different user groups, not just on average.
- Keep a human in the loop for high-stakes decisions.
- Give people a way to appeal or correct a decision.
- Ask whether the data you’re using is a reasonable proxy for what you care about.
If you can’t explain why the system made a decision, be careful about letting it make that decision alone.
5. Transparency: Don’t Pretend
If users are talking to an AI, tell them. A support chat that poses as a human erodes trust the moment someone figures it out.
The same goes for content. AI output can be fluent and wrong, so don’t present it as verified fact. If your product shows AI-generated summaries, recommendations, or answers, label them clearly and make it easy to check the underlying source or flag a mistake.
Transparency also applies inside your team. If a pull request was heavily AI-assisted, say so. It helps reviewers know where to look harder, and it keeps the culture honest.
6. Accountability: The Name on the Commit Is Yours
“The AI wrote it” isn’t an explanation, and it isn’t a defense. Your users won’t care which tool produced the bug, and neither will your incident review.
Whoever merges the code owns it. So does the team that ships the product and the organization that profits from it. That’s not meant to scare you. It’s the reason review and testing matter, and it’s why clear ownership of AI-assisted features is worth setting up before something breaks.
7. Proportionality: Use AI Where It Earns Its Place
Not every problem needs a model. Sometimes a regular expression, a lookup table, or a simple rule is cheaper, more predictable, and easier to explain.
Ask three questions before adding AI to a feature:
- Does this genuinely help the user, or does it just sound impressive?
- Do we need all the data we’re collecting to make it work?
- Could this be used to track, manipulate, or mislead people?
Surveillance, deceptive design, and “collect it now, figure out why later” data habits are red flags, with or without AI in the loop. If a feature only works by quietly gathering more than users would expect, that’s a sign to rethink it.
A Practical AI Ethics Checklist for Developers
Keep this near your pull request template:
- I understand the AI-generated code and can explain what it does.
- I’ve tested edge cases and failure modes, not only the happy path.
- I’ve checked for injection flaws, hardcoded secrets, and unsafe defaults.
- I’ve verified that every suggested package exists, is maintained, and is the one I intended.
- No customer data, credentials, or confidential code went into a public AI tool.
- For features affecting people’s opportunities or access, I’ve tested for uneven outcomes across user groups.
- Users can tell when they’re interacting with AI, and AI output isn’t presented as verified fact.
- High-stakes decisions have human review and a way to appeal.
- The data collected is the minimum the feature needs.
- There’s a named owner responsible for the feature after it ships.
The Bottom Line
AI can make us faster. It can take the tedious parts of the job and give us more time for the thinking that matters. That’s a real benefit, and there’s no need to pretend otherwise.
But speed without boundaries just moves problems downstream, to your users, your teammates, and your future self reading logs on a Friday night. The boundaries here aren’t bureaucracy. They protect the people who use what we build and the trust that makes people willing to use it.
Use the tool, and keep your judgment switched on while you do.
Top comments (0)