Generative AI
Read this when you start using AI tools on the project, and again when one burns you; it gives you the habits that keep you accountable for the output.
Generative AI tools are now part of professional engineering work. Engineers use AI to brainstorm ideas, explore design options, write and review code, generate documentation, and accelerate analysis tasks.
But there is a catch: you are still responsible for the correctness, safety, legality, and professionalism of anything the AI helps you create. An AI tool can write code faster than you can type it. That does not mean the code is correct, secure, or appropriate for your project. Treat AI output the same way you would treat a suggestion from a junior colleague: consider it, verify it, and take ownership of the final result.
What AI Can and Cannot Do
Section titled “What AI Can and Cannot Do”Understanding what AI tools are good at and where they fall short helps you use them effectively rather than fighting their limitations.
What AI helps with
Section titled “What AI helps with”The pattern across these is that the model is good where the space of acceptable answers is wide, where you can recognize a good answer faster than you could produce one, and where being wrong is cheap to detect. Brainstorming fits all three; a security-critical authentication flow fits none of them.
- Brainstorming ideas and exploring alternatives
- Drafting code, tests, documentation, and plans
- Explaining unfamiliar topics, APIs, or code snippets
- Generating sample data, interaction flows, or boilerplate
- Refactoring, debugging, and code review
- Accelerating “first drafts” of writing or implementation
What AI cannot do well
Section titled “What AI cannot do well”These are not temporary gaps waiting for a better model, at least not all of them. A model cannot apply your partner’s unstated preference because nobody wrote it down, and it cannot make an ethical call on your behalf because that call is yours to own. Hallucination deserves a definition rather than a bullet: the model produces fluent, confident text that is not grounded in anything real, including libraries that do not exist, API methods that were never written, and citations to papers nobody published. It is not lying, because it has no model of truth to violate; it is generating plausible continuations, and plausible is not the same as correct. The practical consequence is that any specific factual claim (a function signature, a flag, a citation) needs checking against a source, and the cost of checking is the real price of the speedup.
- Exercise engineering judgment
- Apply your project’s specific constraints (your team’s architecture, your project partner’s requirements, your deployment environment)
- Produce secure, efficient, or trustworthy code without oversight
- Guarantee correctness: AI frequently hallucinates information, including fabricated libraries, nonexistent APIs, and incorrect citations
- Understand the nuances of your Capstone project’s unique context
- Make ethical decisions
The risks below share a structure worth naming: each one is invisible at the moment it occurs and expensive later. Nobody notices the over-reliance in week 3; they notice it in week 18 when a bug lands in code no one on the team can read.
- Incorrect or misleading information presented confidently
- Insecure or poorly optimized code
- Over-reliance leading to lack of understanding: if you cannot explain what the code does, you should not commit it
- Privacy and intellectual property issues (be careful about what you paste into AI tools, especially if your project involves NDA-protected or sensitive data)
Using AI Effectively
Section titled “Using AI Effectively”The difference between productive AI usage and frustrating AI usage usually comes down to a few habits.
Start with clear intent
Section titled “Start with clear intent”Before asking an AI tool to generate code, know what you want. “Build the authentication system” is a poor prompt. “Add a login endpoint that accepts email and password, validates against the users table, and returns a JWT” gives the AI enough context to produce something useful. The clearer your intent, the less time you spend correcting the output.
Verify what matters, and build the net that lets you trust the rest
Section titled “Verify what matters, and build the net that lets you trust the rest”AI-generated code can look correct while being subtly wrong: off-by-one errors, missing edge cases, insecure defaults, hallucinated library methods. The obvious response is “read everything it writes”, and that advice fails in practice for the same reason a tech lead does not read every line their team ships. It does not scale, so people stop doing it, and then they have no strategy at all.
The strategy that does scale has two parts.
Spend your attention where mistakes are expensive to undo. Database schema, authentication and authorization, deployment topology, data migrations, licensing, and public interfaces are one-way doors: getting them wrong costs far more than the review would have. Most feature code is a two-way door, cheap to fix once something tells you it is broken. Validate hard at the doors; delegate freely elsewhere.
Make “elsewhere” safe by building the net. You may reasonably delegate exactly as far as your safety net catches: tests that would actually fail if behavior broke, CI running on every pull request, review gates on the paths that are hard to undo, a staging environment, a rollback path you have actually tried. Trust without a net is recklessness. Trust with one is ordinary engineering. If you want to hand off more, improve the net first rather than reading harder.
That is the standard worth holding yourself to, whatever any policy says.
You still own the result. If you cannot explain why the code works when your project partner asks, no tool and no net will cover for that.
The AI practice activities turn all of this into exercises you can run on your own repository this week.
Use AI to learn, not just to produce
Section titled “Use AI to learn, not just to produce”When the AI generates code you do not understand, ask it to explain. Use it as a learning tool, not just a production tool. The goal of Capstone is to grow as an engineer. Shipping code you cannot maintain or debug is not growth; it is debt.
Know when to stop prompting
Section titled “Know when to stop prompting”If you have gone back and forth with an AI tool more than a few times on the same problem and the output is still wrong, step back. Read the documentation. Look at examples. Ask a teammate. Sometimes the fastest path is not through the AI.
Setting Up AI Tools for Your Project
Section titled “Setting Up AI Tools for Your Project”A tool that knows nothing about your project gives generic answers, and the fix is configuration rather than better prompting: project-level instructions, hooks, MCP servers, and skills, all committed so every teammate’s tool behaves the same way. Set them up in the first sprint.
AI on a Team
Section titled “AI on a Team”Using AI tools as an individual is straightforward. Using them on a team requires coordination, because each person’s AI operates in its own context and has no awareness of what other team members (or their AI tools) are doing. Without shared norms, the codebase drifts toward inconsistency.
This is covered in detail in the technical design and working agreement guides:
What You Can Automate
Section titled “What You Can Automate”When you ask “what can I hand off?”, this is the index. Each entry links to the guide that owns the topic; nothing is restated here, so the owning guide stays the single source of truth.
| Automatable | Where it is covered |
|---|---|
| Test generation across the pyramid (unit, integration, end-to-end) | Testing strategy |
| Browser-driven exercising of real user flows | End-to-end tests, and Playwright MCP above |
| Accessibility auditing (axe-core, Lighthouse, lint-level rules) | Automated accessibility testing |
| Lint and format gates | Your repo’s configuration, checked in and enforced in CI |
| CI pipeline construction and gate configuration | DevOps |
| Self-audit and adversarial review passes | Run a self-audit and an architectural review pass |
| Architectural review as a distinct step | Technical design |
| Security scanning (dependency audit, secret scanning) | Security |
| Documentation and changelog generation | Documentation |
What stays human. Whether the product is actually good for the person using it. Which decisions are one-way doors. The tradeoffs your users and your project partner will feel. And whether an automated finding actually matters, which is a judgment no tool makes for you: a report with forty findings is not forty problems.
AI Coding Tools
Section titled “AI Coding Tools”The landscape changes rapidly. Rather than an exhaustive list, here are the categories of tools and some current options in each.
Chat-Based Assistants
Section titled “Chat-Based Assistants”General-purpose AI models you interact with through conversation. Useful for brainstorming, explaining concepts, drafting documentation, debugging, and exploring design alternatives.
- ChatGPT (OpenAI): strong general reasoning and code generation.
- Claude (Anthropic): strong at long-context analysis, writing, and careful reasoning.
- Gemini (Google): tightly integrated with Google’s ecosystem.
AI Code Editors and Agents
Section titled “AI Code Editors and Agents”Tools that integrate directly into your editor or terminal and can read, write, and modify your codebase. These range from autocomplete assistants to fully agentic tools that can execute multi-step tasks.
- GitHub Copilot: code completion, chat, and agent mode in VS Code and JetBrains. Free for students.
- Cursor: AI-native code editor built on VS Code with strong multi-file editing.
- Claude Code and OpenAI Codex: agentic coding tools that started in the terminal and now also run as desktop apps, web apps, and IDE extensions.
The distinction between “autocomplete” and “agent” matters. Autocomplete tools suggest the next few lines as you type. Agentic tools can plan multi-step changes, read multiple files, run commands, and modify your codebase autonomously. Agentic tools are more powerful but require more oversight, especially on a team where multiple people are using them simultaneously.
Image and Design Tools
Section titled “Image and Design Tools”Generated images are most useful for placeholder assets and mockups, where the alternative is a grey rectangle. The licensing question is the one to settle before you ship anything: terms differ by tool and by plan, and a generated asset in a public repository is a licensing decision whether or not anyone made it deliberately.
- Midjourney, Stable Diffusion, GPT Image (the model behind ChatGPT Images, which replaced DALL-E), Google Gemini image generation: image generation for mockups, assets, or diagrams. Check licenses before using generated assets in your project.
AI Search Tools
Section titled “AI Search Tools”These sit between a search engine and a chat assistant, returning prose answers with citations attached. The citations are the reason to prefer them for research and also the thing to check: a fabricated or misattributed source is the characteristic failure here, and it is invisible unless you open the link.
- Perplexity, ChatGPT Search: research and summarization with source citations. Always verify the facts and check that cited sources actually exist.
Choosing the Right Tool
Section titled “Choosing the Right Tool”Things change rapidly in the AI space. New models are released frequently, each with different strengths. Rather than chasing benchmarks, consider what matters for your workflow:
- Context window: how much of your codebase can the tool see at once? Larger context windows help with multi-file tasks.
- Speed vs. quality: faster models are better for autocomplete; slower, more capable models are better for complex reasoning and multi-step changes.
- Integration: does the tool work with your editor, terminal, and version control? The best tool is the one you actually use.
- Cost: many tools have free tiers or student pricing. GitHub Copilot Student is free with GitHub Education.
If you want to compare models, these resources track current benchmarks:
Best Practices for Using AI Tools
Section titled “Best Practices for Using AI Tools”- Write the project-level context file first. Everything a tool produces is bounded by what it knows about your repository; Set Up Your Repository’s Skills is the hour that pays for itself.
- Decide the one-way doors yourself and delegate the two-way doors freely. If you cannot tell which is which, Map Your One-Way Doors before delegating anything.
- Build the safety net before scaling delegation: tests, CI, review gates, a staging environment, a rollback path. The net is what makes a large delegation reasonable; without it, the same delegation is a gamble.
- Review a generated diff the way you would review a stranger’s pull request, because that is what it is.
- Keep the confidentiality boundary in the team charter and in the tool configuration, not in people’s memory.
- Prefer the cheapest tool that does the job. Every workflow in this guide has a free or student-tier substitute.
- When a tool misleads you, write down what happened and what caught it. That record is how your judgment improves, and it is the only evidence you will have later that it did.
Some Truths About AI Tools
Section titled “Some Truths About AI Tools”Start with the finding that should unsettle anyone confident about this, including the author of this page. METR ran a randomized controlled trial with sixteen experienced open-source maintainers working on 246 real issues in repositories they already knew well. Developers allowed to use AI tools took 19% longer to complete their issues. The part that matters more than the headline: those developers had predicted a 24% speedup beforehand, and after finishing they still believed AI had sped them up by about 20%. They were wrong in the same direction, by a similar margin, before and after the evidence.
Read that carefully before generalizing it. It is one study, on a specific population (expert maintainers in mature codebases they know intimately), with tools from early 2025, and it does not say AI tools are useless. It does say that your sense of being faster is not evidence that you are, which is a different and more durable claim. You are not in that population: you are mostly working in unfamiliar territory on new code, which is closer to where these tools demonstrably help. But the perception gap probably still applies to you, and the only defense is measuring something rather than trusting the feeling.
The security version of the same result is sharper. In Do Users Write More Insecure Code with AI Assistants?, Perry, Srivastava, Kumar, and Boneh found participants with an AI assistant wrote less secure code and were more confident it was secure. The same study found the participants who did better were the ones who distrusted the output and iterated on their prompts. Confidence is the failure mode; skepticism is the skill.
The bottleneck has moved, and this is the part that should change what you do. When most code was typed, your throughput was limited by how fast you could write correct code. When most code arrives from a model, throughput is limited by how fast you can verify it, and verification does not get faster just because generation did. A team that doubles its output and keeps the same review capacity has not doubled its velocity; it has built a queue. This is why the gates in AI project setup matter more than prompt technique.
If you cannot debug or modify code in your repository, you do not own it, and that is true whether a model wrote it or a teammate did. The difference is that a teammate can explain their reasoning next week and a model cannot reconstruct reasoning it never had. Code you accepted without understanding is a debt that comes due during your first hard bug, usually in spring, usually near a deadline.
Finally, everything specific on this page has a short shelf life. Model names, capabilities, and prices move faster than this handbook is revised, and advice tuned to a 2025 tool may be wrong for the one you use. What does not move is the shape: state intent clearly, verify what matters, build a net for the rest, and keep the ability to work without the tool.
AI Tools in Industry and Academia
Section titled “AI Tools in Industry and Academia”AI-assisted coding is the default at most software companies now. Google said on its late-2024 earnings call that more than a quarter of its new code was generated by AI and then reviewed by engineers, and the second half of that sentence is the part that matters: generated code goes through the same review and CI pipeline as anything else. Nobody serious ships what a model wrote without a net, and the companies that get value from these tools are the ones whose review culture and test coverage were already strong. That is why this course cares about the fit between delegation and safety net rather than the tool. The DORA research program has been measuring what AI adoption actually does to delivery performance across thousands of organizations, and its findings are more nuanced than either the marketing or the backlash: adoption is near-universal, the effects depend heavily on the surrounding practices, and teams with weak delivery pipelines get worse outcomes rather than better ones.
The open-source world is more divided. Several projects banned AI-generated contributions outright: Gentoo’s council policy forbids them, and NetBSD’s commit guidelines presume LLM output to be tainted code that must not be committed without prior written approval from core. Daniel Stenberg of curl has written bluntly about AI-generated security reports that consume maintainer time without containing a real bug. If your project is FOSS, read the upstream’s policy before you delegate anything, and expect a maintainer to ask what you verified.
In academia, the major publishers converged on the same rule in 2023: an AI tool cannot be an author, because authorship carries accountability a tool cannot hold, and its use must be disclosed. Nature’s policy states both halves plainly, and the ACM’s is equivalent. Research code is held to the reproducibility bar regardless of who or what wrote it. Universities differ on classroom policy, so read the one that governs you rather than assuming it matches the last course you took.
Additional Readings
Section titled “Additional Readings”The evidence on whether these tools actually help is thinner and stranger than the volume of writing about them suggests, so the first three entries are studies rather than opinion. Read at least the METR summary: it is the single most useful corrective to your own sense of how much faster you are going. The vendor documentation is here because prompting technique is genuinely tool-specific and changes with each release.
Sources and further reading
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR: the randomized trial that found a 19% slowdown alongside a perceived speedup.
- Do Users Write More Insecure Code with AI Assistants?, Perry, Srivastava, Kumar, and Boneh: less secure code, more confidence that it was secure.
- DORA research, Google Cloud: what AI adoption does to delivery performance when measured across organizations rather than anecdotes.
- Here’s how I use LLMs to help me write code, Simon Willison: the most practical working description of a verification-first habit.
- Exploring Generative AI, Thoughtworks: a long-running field report from people deploying this on real engagements.
- Prompt engineering overview, Anthropic: the techniques that actually move output quality, from the vendor.
- AI policy, Gentoo, and commit guidelines, NetBSD: two upstream projects that say no, and their reasoning.
- Artificial Intelligence editorial policy, Nature: the disclosure and authorship rule your research partner is working under.
- Stack Overflow Developer Survey: AI: what practitioners report about adoption and trust, useful as a sanity check on your own bubble.
Activities that exercise this
- Map Your One-Way Doors: decide what you will never delegate before you are tired.
- Run a Self-Audit and an Architectural Review Pass: the verification half, run on your own repository.
- Run an Acceptance Pass: checking generated work against what was actually asked for.
- Audit Your Safety Net: measure delegation against the gates that would catch it.
- Put a Browser Agent on Your Critical Flow: delegation where the failure is visible.