# AI is a Tool, You Are the Owner This guide was initially generated using AI. Rather than writing every sentence from scratch, I used AI as a research, drafting and teaching assistant to help produce a comprehensive first draft. The prompt instructed the AI to act as an experienced Staff Software Engineer, Engineering Manager and Site Reliability Engineer, and to create a detailed learning guide centred on the following principle: > *"AI is a tool, not the owner. The human engineer owns the decision, the implementation and the outcome."* Using AI to generate content doesn't transfer *ownership* of that content. The ideas presented here were **prompted**, **reviewed** and **intentionally selected** before publication. **I** have evaluated the explanations, verified them for accuracy where appropriate, and **accepted responsibility** for the final version of this guide. **That distinction is the very subject of this article.** Just as an engineer remains accountable for code that was written with the assistance of AI, I remain accountable for the content I share🙂. AI accelerated the drafting process, but it didn't decide to publish this article, nor does it assume responsibility for any inaccuracies or omissions. Those decisions remain **mine**. The goal here is to explain ***why*** AI should be viewed as a powerful engineering tool rather than the owner of technical decisions. Whether you are writing code, designing cloud infrastructure, reviewing security controls or documenting operational processes, the responsibility for understanding, validating and standing behind the final outcome continues to rest with the human engineer. With that context established, let's explore what ownership looks like in the age of AI. * * * ## The Core Principle: AI is a Tool, You Are the Owner In modern software engineering, AI is a powerful assistant, but its not the owner of the systems we build. When a system succeeds, its because human engineers designed, verified, and deployed it correctly (correctly in this context doesn't necessarily mean perfect, secure and/or scalable). When a system fails, the responsibility lies with the humans who approved the changes. Organisations assign responsibility to **people** rather than AI systems because AI lacks legal standing, ethical judgement, and operational awareness. **Accountability** means taking ownership of the consequences of an action. An AI **cannot** be **fired**, **sued**, or **put on an on-call rotation** to fix a broken prod environment over a weekend or at "2AM". Using AI as an assistant means leveraging it to generate templates, suggest solutions, or automate "boilerplate" code. Delegating ownership, which is a critical mistake, means accepting these outputs without verification. "AI built it" **undermines your value** as an engineer. "AI broke it" is an **unacceptable excuse** for failing to review what you deployed. * * * ## Ownership Throughout the Software Development Lifecycle (SDLC) *The SDLC is the process used to design, develop, and test high-quality software*. AI can accelerate this process, but the engineer must maintain control at every step. ### 1. Requirements Gathering * **AI can assist with:** Summarising meeting notes, drafting user stories, or suggesting edge cases based on prompts. * **Engineer must own:** Validating that the requirements solve the actual business problem and aligning them with stakeholders. * **What can go wrong:** Building a perfectly functioning feature that nobody needs because the AI misunderstood the business context. ### 2. System Design * **AI can assist with:** Proposing architectural patterns or comparing database technologies. * **Engineer must own:** Choosing the final architecture based on budget, team skills, and non-functional requirements (like scalability and compliance). * **What can go wrong:** Adopting an overly complex, distributed microservices architecture for a simple internal tool. ### 3. Threat Modelling (Identifying Security Risks) * **AI can assist with:** Generating a baseline list of common threats for a given architecture. * **Engineer must own:** Contextualising threats. Only the engineer knows the true value of the data being protected. * **What can go wrong:** Missing bespoke logic flaws that generic AI models do not recognise. ### 4. Development * **AI can assist with:** Generating boilerplate code, writing functions, or explaining syntax. * **Engineer must own:** Ensuring the code is maintainable, follows team standards (like SOLID principles), and accurately implements the requirements. * **What can go wrong:** Introducing subtle bugs or technical debt by pasting code you do not fully understand. ### 5. Code Review * **AI can assist with:** Spotting syntax errors or highlighting missing unit tests. * **Engineer must own:** Evaluating the logic, architectural fit, and clarity of the code. * **What can go wrong:** Approving a pull request that looks syntactically correct but breaks existing business logic. ### 6. Security Review * **AI can assist with:** Flagging known vulnerable patterns or outdated dependencies. * **Engineer must own:** Verifying the findings, investigating false positives, and ensuring secure logic (e.g., proper access controls). * **What can go wrong:** Trusting the AI's "clean bill of health" while a severe authorisation flaw remains hidden in the logic. ### 7. Testing * **AI can assist with:** Generating mock data or drafting standard unit tests. * **Engineer must own:** Defining the test strategy, writing complex integration tests, and ensuring edge cases are covered. * **What can go wrong:** AI writes tests that merely assert the generated code does what it does, rather than testing what it *should* do. ### 8. CI/CD Pipeline * **AI can assist with:** Writing workflow scripts (e.g., GitHub Actions YAML). * **Engineer must own:** Securing the pipeline, managing secrets, and ensuring deployment gates are enforced. * **What can go wrong:** A generated pipeline script exposes an environment variable containing a database password in the build logs. ### 9. Production Deployment * **AI can assist with:** Drafting release notes or rollout plans. * **Engineer must own:** The decision to press "deploy" and the readiness to roll back if things fail. * **What can go wrong:** Deploying during peak business hours because the AI-generated schedule lacked timezone awareness. ### 10. Monitoring * **AI can assist with:** Writing query syntax to create dashboards or suggesting alert thresholds. * **Engineer must own:** Defining the Service Level Objectives (SLOs) that actually matter to the user experience. * **What can go wrong:** Alert fatigue from overly sensitive, AI-suggested monitors that wake engineers for non-issues. ### 11. Incident Response * **AI can assist with:** Parsing logs quickly or suggesting potential root causes. * **Engineer must own:** Making the final call on mitigation strategies and communicating with stakeholders. * **What can go wrong:** Executing a destructive AI-suggested database command while panicking during an outage. ### 12. Post-Incident Review * **AI can assist with:** Summarising chat transcripts into a timeline. * **Engineer must own:** Identifying the systemic failures and committing to actionable preventive measures. * **What can go wrong:** Producing a generic, shallow report that fails to address the specific cultural or technical root cause. * * * ## Realworld Examples Here we look at practical scenarios using a modern enterprise stack. ### Example 1: Creating a CI/CD Pipeline * **The Task:** Create a GitHub Actions workflow to build a Docker image for a Python Django application and push it to a registry. * **What AI suggested:** A valid YAML file that builds the Docker image and uses `docker-compose` to run tests. However, it hardcoded the registry credentials in the YAML file. * **What the engineer reviewed:** The engineer noticed the hardcoded credentials and the lack of a specific base image tag (it used `python:latest`). * **The final decision:** The engineer modified the YAML to pull credentials securely from GitHub Secrets and pinned the Docker image to a specific version (`python:3.11-slim`). * **Potential business impact if incorrect:** Hardcoded credentials could be leaked to anyone with repository access, allowing malicious actors to replace production images. ### Example 2: Building a REST API Endpoint * **The Task:** Create a Django REST API endpoint that allows a user to fetch their billing history from a PostgreSQL database. * **What AI suggested:** A clean, syntactically correct endpoint. However, the query filtered only by `invoice_id` and did not verify if the requesting user owned that invoice. * **What the engineer reviewed:** The engineer recognised a Missing Object-Level Authorisation flaw (also known as Insecure Direct Object Reference or IDOR). * **The final decision:** The engineer rewrote the query to filter by both `invoice_id` and [`request.user.id`](http://request.user.id). * **Potential business impact if incorrect:** Customers could guess other users' invoice IDs and view confidential financial data, leading to a massive privacy breach and legal fines. ### Example 3: Provisioning Cloud Infrastructure * **The Task:** Use AWS to host a static frontend securely via CloudFront and route traffic using Route 53, while a Lambda function retrieves an API key from Secrets Manager. * **What AI suggested:** Provided the correct Terraform code for CloudFront and Route 53, but the IAM (Identity and Access Management) role assigned to the Lambda function was granted `secretsmanager:*` (full access to all secrets). * **What the engineer reviewed:** The engineer identified that the IAM policy violated the Principle of Least Privilege. * **The final decision:** The engineer scoped the IAM policy down to `secretsmanager:GetSecretValue` for only the specific API key's Resource ARN (Amazon Resource Name). * **Potential business impact if incorrect:** If the Lambda function were compromised, the attacker could read every secret in the AWS account, including database passwords and third-party API keys. * * * ## Security Perspective AI models prioritise providing a ***functional*** answer over a secure one (**This has been my experience on numerous occasions especially around docker image builds and third-party libraries**). It often generates code based on historical, sometimes outdated, public repositories.

Security Risk	How it happens (AI Context)	Detection	Prevention	Tools
Security Vulnerabilities	AI uses outdated functions (e.g., MD5 for hashing).	Code review, static analysis.	Enforce modern cryptography standards.	SonarQube, Bandit.
Logic Errors	AI misinterprets complex business rules (e.g., refunding the wrong amount).	Unit testing, QA.	Write clear tests before using AI.	Pytest, JUnit.
Race Conditions	AI writes asynchronous code without proper locking mechanisms.	Load testing, concurrency testing.	Deep understanding of threading models.	JMeter, Thread Sanitizer.
Authentication Mistakes	AI suggests custom auth logic instead of standard libraries.	Security architecture review.	Always use established frameworks (e.g., OAuth).	OWASP ZAP, Burp Suite.
Authorisation Flaws	AI forgets to check if a user owns the resource they are accessing.	Manual code review, penetration testing.	Implement mandatory access control checks.	Semgrep, manual review.
Secret Leakage	AI placeholders (e.g., `api_key = "12345"`) are accidentally committed.	Pre-commit hooks scanning for secrets.	Use environment variables and secret managers.	GitLeaks, TruffleHog.
Supply Chain Risks	AI suggests importing a helpful but unmaintained or malicious package.	Dependency auditing.	Vet all new third-party libraries.	Snyk, Dependabot, socket.dev
Dependency Vulnerabilities	AI suggests a specific version of a package that has known CVEs.	Software Composition Analysis (SCA).	Automate dependency checks in CI/CD.	OWASP Dependency-Check.
Misconfigured Cloud	AI generates permissive IAM policies or open security groups (0.0.0.0/0).	Infrastructure code scanning.	Apply Principle of Least Privilege.	Checkov, tfsec.

* * * ## Incident Ownership: Case Studies ### Case Study 1: Infrastructure Code Failure * **Timeline:** 10:00 AM: Engineer prompts AI for Terraform to add a read-replica to PostgreSQL. 10:05 AM: Engineer applies the code. 10:10 AM: Primary database drops. * **Root Cause:** The AI generated a script that recreated the database cluster instead of appending a replica, destroying the primary volume. * **Technical Investigation:** The Terraform state showed a `destroy` and `create` action, which the engineer ignored during the `terraform plan` phase. * **Impact on Customers:** 45 minutes of total application downtime. * **Recovery Process:** Restored database from the most recent snapshot. * **Lessons Learned:** Always review the execution plan of infrastructure-as-code before applying. * **Accountability:** The engineer is accountable for failing to review the `terraform plan` output. AI simply provided a string of text. ### Case Study 2: Application Code Race Condition * **Timeline:** Black Friday sale begins. 12:00 PM: Support receives calls about negative inventory. * **Root Cause:** An AI-generated Python function for deducting inventory checked stock levels and updated them in two separate database calls without an atomic transaction. * **Technical Investigation:** High concurrent traffic allowed multiple users to pass the "check stock" conditional before any of them updated the database, leading to overselling. * **Impact on Customers:** Hundreds of orders had to be cancelled and refunded, damaging reputation. * **Recovery Process:** Rolled back to previous version; implemented `SELECT ... FOR UPDATE` row-level locking. * **Lessons Learned:** AI cannot predict concurrency issues under load; engineers must apply database locking strategies. * **Accountability:** The engineer is accountable for not testing the code under concurrent load or understanding database transaction isolation. ### Case Study 3: Security Configuration Breach * **Timeline:** 02:00 AM: Unauthorised data exfiltration detected from AWS S3. * **Root Cause:** An engineer used AI to create an S3 bucket policy. The AI suggested a policy allowing `*` (public) read access to fix a "permission denied" error the engineer was facing. * **Technical Investigation:** The bucket contained PII (Personally Identifiable Information). The public policy was active for 72 hours. * **Impact on Customers:** Legal compliance breach requiring customer notification and regulatory fines. * **Recovery Process:** S3 public access blocked; forensic audit of accessed files. * **Lessons Learned:** Never solve "permission denied" errors by granting public access. * **Accountability:** The engineer is accountable for deploying a policy that violated basic security principles to save time. * * * ## Why AI Doesn't Remove Engineering Skill To effectively verify AI output, an engineer must possess deep fundamental knowledge. If you don't understand the underlying system, you cannot tell when the AI is wrong. * **Operating Systems:** If AI suggests a Bash script to manage file descriptors, you must understand kernel limits and process lifecycles to know if it will crash the server. * **Networking:** If AI suggests modifying a Docker bridge network, you must understand subnets and NAT (Network Address Translation) to ensure containers can still reach the internet securely. * **Databases:** AI will happily write an SQL query that scans an entire 100-million-row table. You must understand indexing and execution plans to ensure performance. * **Security:** AI cannot understand the business context of data. You must know what constitutes sensitive data to protect it adequately. * **System Architecture:** AI might suggest caching everything in Redis. You must understand cache invalidation and memory limits to design a robust system. * * * ## AI as an Engineering Tool AI is a tool, joining a long lineage of developer aids.

Tool	Strengths	Limitations
AI Assistants	Fast, synthesises context, generates boilerplate.	Can hallucinate confidently, lacks business context.
Google Search	Broad access to diverse, real-world opinions.	Requires sifting through irrelevant or outdated SEO spam.
Stack Overflow	Community-vetted answers with upvotes and discussion.	Often highly specific to a slightly different problem than yours.
Documentation	The ultimate source of truth for a tool.	Can be dense, difficult to read, or lack practical examples.
IDE Autocomplete	Saves keystrokes, prevents typos.	Only predicts the next few words; lacks architectural vision.
Linters/Compilers	Enforces objective syntax and style rules.	Cannot catch logical business errors.
Senior Colleagues	Understands business context, culture, and architecture.	Limited time and availability.

**Key difference:** A compiler throws an error if your code is wrong. An AI will confidently explain why its incorrect code is right. You must treat AI like a junior developer who is eager to please but occasionally invents facts. * * * ## Professional Responsibility Engineering organisations use specific gates to enforce human accountability. **None of these can be transferred to an AI.** * **Pull Requests (PRs) & Code Reviews:** The reviewer acts as a human gatekeeper. They sign off on the logic, security, and maintainability of the code. * **Change Approval Board (CAB):** A human committee that evaluates the risk of a deployment against business operations. * **On-call Rotations:** Humans are paid to wake up and fix systems because they can think critically under pressure and take legal/financial responsibility for outages. * **Blameless Postmortems:** We investigate *how* a system allowed a failure, rather than punishing the human who made the mistake. However, the human is still responsible for participating, learning, and improving the system. You cannot invite an AI to a postmortem. * * * ## Beyond Software Engineering: A Universal Principle While this guide has focused primarily on the Software Development Lifecycle, cloud infrastructure, and enterprise architecture, the core principle—*AI is a tool, not the owner*—is entirely universal. The concepts of accountability, verification, and critical analysis apply to almost every modern profession. Whether you are a medical doctor using AI to assist with diagnostics, a lawyer generating legal research, or a financial analyst modelling market trends, the professional boundaries remain identical: * **In Medicine:** An AI might rapidly flag a potential anomaly on an MRI scan, but the consultant physician must own the final diagnosis and treatment plan. An AI cannot be held liable for a misdiagnosis. * **In Law:** An AI might draft a comprehensive contract or search through decades of case law, but if it hallucinates (invents) a legal precedent, the human lawyer faces professional sanctions or disbarment, not the software provider. * **In Finance:** An AI might analyse global supply chain data to recommend an investment strategy, but the financial advisor and their institution must answer to regulatory bodies and clients if the risk assessment is fundamentally flawed. Across all disciplines, AI is an extraordinary lever. It scales capability, speed, and pattern recognition to unprecedented levels. However, it cannot scale accountability, liability, or ethical judgement. True professionals in any field differentiate themselves not by how much work they can blindly delegate to a machine, but by the depth of understanding, rigorous validation, and ultimate responsibility they bring to the final outcome.