6.3.1 AI Software Engineering Assistant🔗

Concept. Connect a GitLab repository and let an agent continuously analyze the project: answer questions about the code, explain architecture, review merge requests, find missing test coverage, summarize commit ranges, and open issues for what it finds.

Features. Repository ingestion and indexing · natural-language code Q&A · MR review with inline findings · test coverage gap report · commit range summaries · issue creation · review history

Tools. inspect_repository() · get_commits() · get_merge_request_diff() · run_tests() · get_coverage() · create_issue() · search_code()

Reliability. Before reporting a bug, the agent must locate the code and run the test suite. Findings that cannot be grounded in a file and line are dropped. Generated issues go to a human approval queue before they are created.

Evaluation. Seed a repository with 25–30 known defects. Measure detection rate, false positive rate, and how often the agent points at the right file.

Advanced version. Give the agent a failing test and have it investigate autonomously—read the failure, search history, form a hypothesis, and produce a written diagnosis.

Difficulty: ★★★★★ · Fit: strong for a team of 3

Watch out for. Repository size. Index one moderate repo well rather than handling arbitrary ones badly. Decide your chunking strategy early—this is where most of the AI work actually lives.

6.3.2 AI Incident Response Center🔗

Concept. A miniature DevOps/SRE platform where an agent investigates simulated production incidents using logs, deployment history, Git commits, metrics, and configuration.

You give it an incident—“18.4% of API requests are failing”—and it investigates:

The UI shows the investigation as it happens, step by step, so a human can follow the reasoning.

Features. Incident dashboard · log ingestion and search · deployment timeline · live investigation view · ranked hypotheses with evidence · generated incident report · incident history

Tools. search_logs() · get_deployment_history() · search_git_history() · get_metrics() · run_diagnostic() · create_incident_report()

Reliability. Every hypothesis must cite the specific log lines, commits, or metrics supporting it. Claims without evidence are rejected before display. Confidence is shown per hypothesis.

Evaluation. Build 20–30 synthetic incidents with known root causes. Measure top-1 and top-3 root cause accuracy, and average number of tool calls to reach the answer.

Difficulty: ★★★★★ · Fit: team of 3

Watch out for. You have to generate realistic incident data before you can build anything. Budget a full week for the simulator and make it a deliverable in its own right.

6.3.3 AI Data Analyst🔗

Concept. Users connect a database or upload CSVs and ask questions in English—“What changed in our sales this quarter?” The agent plans, inspects the schema, writes SQL, runs it, validates the results, and produces a chart with an explanation.

The rule that makes this project good:

The LLM may not state a number it did not obtain through a tool.

Features. Data upload / DB connection · schema browser · natural-language queries · visible query plan · generated SQL shown to the user · charts · saved analyses · export

Tools. inspect_schema() · run_sql() · calculate_statistics() · create_chart() · profile_column()

Reliability. SQL passes a validator before execution: read-only enforcement, table allowlist, column existence check, row limit, query timeout. Numbers in the final answer are cross-checked against the actual result set—if the model reports a figure that is not in the returned rows, the answer is rejected and regenerated.

Evaluation. 30–40 questions with known correct answers. Measure exact-match answer accuracy, SQL validity rate, and how often the validator catches a bad query.

Difficulty: ★★★★★ · Fit: 2 or 3

Watch out for. This is the idea most likely to become a thin wrapper if you skip the validation layer. The validator is the project. Build it in week 2, not week 7.

6.3.4 Natural Language → SQL, Focused on Safety🔗

Concept. A narrower, deeper sibling of AI Data Analyst that investigates one question: how do you make LLM-generated SQL safe?

Features. Query interface · generated SQL with explanation · validator verdict shown to the user · blocked-query log · role-based table access · query history

Tools. inspect_schema() · validate_sql() · run_sql() · explain_plan() · check_permissions()

Reliability. The whole project is the reliability mechanism. Test against: invalid SQL, destructive statements, unauthorized tables, injection attempts, hallucinated columns, and ambiguous questions.

Evaluation. An adversarial suite of 40+ queries—legitimate and malicious. Measure block rate for unsafe queries, false-block rate for safe ones, and correctness on the legitimate half.

Difficulty: ★★★★☆ · Fit: good for a team of 2

Watch out for. Narrower scope means the engineering has to be excellent. Per Grading Rubric, that is a completely viable way to score well.

6.3.5 Knowledge Navigator (Courses, Degrees, Policies)🔗

Concept. RAG over a large collection of institutional information—course descriptions, prerequisites, schedules, degree requirements, department policies—that answers questions like “I want to take machine learning next semester. What do I need first?” with citations.

What lifts it above a RAG chatbot: query decomposition, multi-source retrieval, conflict detection between documents, citation verification, document freshness tracking, and an admin interface for ingesting new material.

Features. Document ingestion (PDF/HTML/Markdown) · semantic + keyword search · cited answers · conflict warnings · prerequisite chain resolution · “why did you recommend this?” · admin upload console · freshness indicators

Tools. search_documents() · get_course() · resolve_prerequisites() · check_requirements() · verify_citation()

Reliability. Every factual claim must map to a retrieved span. A verification pass re-checks each citation against the source text; unsupported claims are stripped or flagged before the answer is shown.

Evaluation. 30–50 questions with known correct answers drawn from the catalog. Measure answer accuracy, citation precision (does the cited source actually support the claim?), and retrieval recall.

Difficulty: ★★★★☆ · Fit: 2 or 3

Watch out for. Prerequisite chains are graph problems, not text problems. Model them in your database and let the agent query them with a tool—do not ask the LLM to reason over prerequisite text.

6.3.6 AI Code Tutor and Debugging Coach🔗

Concept. Not “ask AI to fix my code.” A student submits broken code and the system teaches them to debug it, revealing information progressively:

Hint 1: Your function works for positive integers. What happens when n = 0?

Hint 2: Look at the recursive call.

[Show solution]

Features. Code submission and sandboxed execution · test running · progressive hints · Socratic follow-up questions · attempt tracking · generated practice problems · instructor dashboard of common mistakes

Tools. run_code() · run_tests() · parse_ast() · get_stack_trace() · generate_test_case() · record_attempt()

Reliability. Hints must be grounded in an actual failing test or a real AST finding, never in the model’s guess about what looks wrong. Before a hint is shown, the system verifies the claimed defect actually reproduces.

Evaluation. A set of 25+ programs with known bugs. Measure defect localization accuracy and hint relevance. If you can recruit classmates, measure time-to-fix with hints versus without—a small user study is a strong differentiator here.

Difficulty: ★★★★☆ · Fit: 2 or 3

Watch out for. Running untrusted student code is a genuine security problem. Sandbox it properly (container, resource limits, no network) and write that up in your security section—it is one of the better security analyses available in this list.

6.3.7 AI Debugging Assistant with a Fix Loop🔗

Concept. A developer submits source code, an error message, a stack trace, and optionally Git history. The system diagnoses the problem and proposes a fix—then checks its own work:

Features. Submission interface · likely cause with cited code · suggested fix as a diff · generated reproducing test · generated verification test · automatic test execution · revision history showing each attempt

Tools. run_tests() · apply_patch() · get_git_blame() · search_codebase() · generate_test()

Reliability. The loop itself: a proposed fix is only presented as successful if the reproducing test fails before and passes after, with no other tests broken. Fixes that do not survive that check are marked unverified.

Evaluation. 20–30 bugs with known fixes. Measure verified-fix rate, average revision attempts, and regression rate.

Difficulty: ★★★★★ · Fit: 2 or 3

Watch out for. Scope the language and project type narrowly—one language, one test framework. “Any repository” is a trap.

6.3.8 AI Research Assistant with Citation Verification🔗

Concept. A research tool over a collection of academic papers: upload, search semantically, ask questions, compare methods across papers, extract claims, and find supporting or contradicting evidence.

Features. PDF ingestion and parsing · semantic search · cross-paper comparison tables · claim extraction · evidence linking · contradiction detection · literature map · export

Tools. search_papers() · extract_section() · compare_papers() · verify_claim() · find_contradictions()

Reliability. A citation verification agent checks whether each generated claim is actually supported by the cited passage. Unsupported claims are flagged in the UI rather than silently shown.

Evaluation. Hand-label 30–40 claim/citation pairs (some genuine, some deliberately wrong). Measure how often the verifier correctly accepts and rejects.

Difficulty: ★★★★☆ · Fit: 2 or 3

Watch out for. PDF parsing is miserable and will eat more time than you expect. Use a known-good library, test it on your actual corpus in week 1, and keep the corpus small and clean.

6.3.9 AI Security Auditor🔗

Concept. Submit a repository; the system performs automated security analysis combining static analysis, dependency scanning, secret detection, and LLM review, then produces a report where each finding is verified before it is shown.

Features. Repository submission · multi-analyzer pipeline · severity-ranked findings · per-finding explanation (“why is this vulnerable?”) · suggested patch · verification status · scan history · false-positive marking

Tools. run_static_analysis() · scan_dependencies() · detect_secrets() · search_code() · lookup_vulnerability_db() · verify_finding()

Reliability. The AI must not trust its own findings. Each LLM-reported issue is checked against a static analyzer, a rule-based test, or a vulnerability database. Unconfirmed findings are labeled as such.

Evaluation. A corpus of repositories with known planted vulnerabilities. Measure precision, recall, and false positive rate—and compare three configurations: static analysis alone, LLM alone, and both combined. That comparison is the most interesting result in this project.

Difficulty: ★★★★★ · Fit: 2 or 3

Watch out for. Scope to one language and a fixed vulnerability list. Also: you are running untrusted code’s source, not the code itself—keep it that way.

6.3.10 AI Meeting Intelligence with Persistent Memory🔗

Concept. More than transcription. From meeting transcripts, extract decisions, action items, owners, deadlines, and unresolved questions—then keep them as persistent project memory you can query months later:

“What did we decide about the database last Tuesday?”

An agent can then act: “Create tasks for all outstanding action items.”

Features. Transcript upload · decision and action-item extraction · owner and deadline assignment · searchable meeting history · evidence-linked answers · task creation in an internal tracker · follow-up detection for stale items

Tools. search_meetings() · extract_action_items() · create_task() · get_task_status() · link_to_transcript()

Reliability. Every extracted decision links to the transcript span it came from and is shown alongside it. Task creation requires human confirmation before it writes to the database. Extraction output is schema-validated.

Evaluation. Hand-annotate 20–30 transcripts with ground-truth action items. Measure extraction precision and recall, and owner-assignment accuracy.

Difficulty: ★★★★☆ · Fit: team of 2

Watch out for. Getting transcripts. Decide your source in week 1—public meeting transcripts, generated ones, or your own recordings with consent.

6.3.11 AI Support Platform That Knows When Not to Answer🔗

Concept. A real support platform, not a chatbot:

The interesting requirement: the system must know when not to answer.

Confidence: 42% → escalate to a human

Features. Ticket intake and queue · automatic classification and routing · documentation search · drafted responses with citations · confidence scoring · escalation workflow · agent approval interface · resolution analytics

Tools. search_documentation() · get_customer_history() · classify_ticket() · check_known_issues() · escalate_to_human()

Reliability. Confidence thresholds with escalation, plus citation checks on every drafted answer. Test it by deliberately removing or corrupting documentation and measuring whether the system escalates instead of inventing an answer.

Evaluation. 30+ tickets, some answerable from your docs and some deliberately not. Measure answer accuracy on the answerable half and correct-escalation rate on the rest. The second number is the interesting one.

Difficulty: ★★★★☆ · Fit: team of 2

Watch out for. Calibrating confidence is genuinely hard. Do not use the model’s self-reported confidence alone—combine it with retrieval scores and agreement across generations.

6.3.12 Personal Finance Intelligence🔗

Concept. Users import transactions; the system categorizes them, detects recurring payments and anomalies, builds budgets, and answers analytical questions agentically:

“Why did my spending increase this month?”

Features. Transaction import · automatic categorization · recurring payment detection · anomaly flags · budget creation and tracking · natural-language questions · monthly summaries · duplicate detection

Tools. get_transactions() · group_by_category() · find_recurring() · compare_periods() · detect_anomalies()

Reliability. As in AI Data Analyst, every figure in an explanation must come from a tool result, verified against the returned data before display. Categorization confidence below a threshold is surfaced for user correction, and corrections feed back into the system.

Evaluation. A labeled transaction set. Measure categorization accuracy, recurring-payment detection rate, and numerical correctness of generated explanations.

Difficulty: ★★★★☆ · Fit: team of 2

Watch out for. Use synthetic or anonymized data only. Never use real financial data belonging to anyone, including yourselves. Privacy and authorization belong at the center of your security analysis.

6.3.13 AI Test Generation and Test-Quality Analyzer🔗

Concept. Submit a codebase; the system generates tests—and then asks the harder question: are these tests any good? It measures coverage, and uses mutation testing to check whether the generated tests actually catch injected defects.

Features. Repository submission · test generation per module · coverage reporting before and after · mutation testing · test-quality score · flaky test detection · gap report identifying untested branches

Tools. analyze_coverage() · generate_test() · run_tests() · mutate_code() · detect_flaky()

Reliability. A generated test is only kept if it (a) passes on the correct code, (b) fails on at least one mutant, and (c) is not flaky across repeated runs. Everything else is discarded. This is one of the cleanest verification loops available in this list.

Evaluation. Measure coverage delta, mutation kill rate, and the discard rate of generated tests—that last number tells you how often the LLM produced a test that looked fine and tested nothing.

Difficulty: ★★★★★ · Fit: 2 or 3

Watch out for. Mutation testing is slow. Limit mutant count and module scope, and run it as a background job rather than in the request path.

6.3.14 Constraint-Aware Planner (Events, Itineraries, Scheduling)🔗

Concept. A planning agent that builds a real plan under real constraints, rather than describing one. Two concrete forms:

Campus event planner—“Organize a study group for 20 people next Thursday evening.” The agent negotiates rooms, capacity, equipment, schedules, and calendar conflicts, then creates the event.

Itinerary planner—“5 days in Tokyo, $2,500, interested in food and museums.” The agent builds an itinerary respecting opening hours, travel time, geographic distance, and budget—then re-plans only the affected portion when the user changes a constraint.

Features. Constraint input · generated plan with reasoning · constraint violation warnings · interactive editing with partial re-planning · alternatives · plan persistence and export

Tools. search_availability() · check_capacity() · get_travel_time() · check_conflicts() · calculate_cost() · create_booking()

Reliability. A rule-based constraint validator checks the finished plan independently of the LLM: no double-booking, nothing scheduled outside opening hours, travel times physically possible, total within budget. Violations are either repaired or shown to the user—never hidden.

Evaluation. 25+ scenarios with known-feasible solutions. Measure constraint satisfaction rate, plan validity, and how often the validator has to intervene.

Difficulty: ★★★★★ · Fit: team of 3

Watch out for. External APIs (maps, venues, flights) have rate limits and costs. Cache aggressively, and have a fixture-based fallback so your demo does not depend on a live third party.