Your Accountability as a Builder

Every lesson in this module has circled the same truth from a different angle. This lesson states it directly: you are accountable for what you ship. Not the AI tool you used. Not the open-source library you copied. Not the tutorial you followed. The person who makes the decision to put software in front of users owns the consequences of that decision.

Accountability Is Not Optional

Accountability means being answerable for your actions and their outcomes — including outcomes you did not intend, and including actions carried out by systems you set in motion. This is not a harsh or punitive standard. It is the standard that makes trust possible. When someone uses your software, they are trusting that the person who built it took their interests seriously. Accountability is the structure that gives that trust a foundation. Three layers of accountability every builder carries: Legal accountability: software that causes harm may expose you to civil or criminal liability. This includes privacy law violations (GDPR, COPPA), consumer protection violations, accessibility discrimination claims, and negligence claims. 'I did not know' reduces culpability in some circumstances, but 'the AI built it' does not. Professional accountability: within a team, organization, or community, your reputation is staked on your work. Code that ships with unaddressed security holes, inaccessible interfaces, or hidden data collection damages your professional standing — regardless of how it was generated. Moral accountability: separate from legal and professional consequences, there is the question of what kind of builder you want to be. Software affects people. Taking that seriously is a moral position. A case study: in 2016, Uber deployed a 'greyball' feature that used app data to identify regulatory inspectors and show them a fake version of the app. The engineers who built greyball were accountable — they made it work. The product managers who specified it were accountable. The executives who approved it were accountable. Courts and regulators agreed: Uber paid settlements. The defense that 'I was following instructions' or 'I only wrote the code' was not exculpatory.

What does accountability look like in practice? Know what your software does: before you ship, be able to give a plain-language description of what your software does with user data, what decisions it makes automatically, and what happens when it fails. If you cannot answer these questions, you are not ready to ship. Disclose honestly: if your product uses AI to make decisions that affect users, tell them. If you collect data, describe what you collect and why. Informed users can make informed choices. Surprise is the enemy of trust. Respond when things go wrong: a security breach, a bug that caused real harm, an accessibility failure that excluded users — these require honest public communication, not defensive silence. The handling of a failure often determines how much trust survives it. Maintain a contact path: users who have been harmed need a way to reach you. A working email address, a GitHub issue tracker, a feedback form — some channel for accountability to flow through. In AI-assisted development specifically: AI tools generate code that may be subtly wrong in ways that look correct. The speed of generation creates an illusion that the code has been reviewed. It has not — unless you reviewed it. Every line of code in your production system should have been read and understood by the person responsible for that system.

Accountability in the Age of AI Assistance

AI assistance changes the speed of development but not the structure of accountability. If anything, it raises the stakes: AI can generate plausible-looking code that has subtle but serious flaws — in security, in logic, in edge case handling — that a fast-moving builder might not catch. Some specific accountability risks in AI-assisted work: Confident incorrectness: AI tools often generate code that is wrong with the same tone and formatting as code that is right. The text around the code may be helpful and accurate even when the code itself has a bug. Visual plausibility is not correctness. Hidden data access: AI-generated code sometimes accesses more data than requested — querying additional fields, storing more than necessary, or transmitting information to logging services. A builder who never reads the code they ship may not know this is happening. Licensing violations: as discussed in Lesson 5, AI-generated code may incorporate patterns from training data. If you ship that code without review, you may be shipping license violations you are unaware of. Each of these risks is mitigated by the same practice: read the code before you ship it. Not to understand every line in depth — that is an unrealistic bar for complex AI-generated output. But enough to identify surprising behavior, unexpected data access, and logic that does not make sense to you.