Most engineering teams carry a short list of recurring annoyances that never quite justify a full project: the pull request that needs a second look nobody has time for, the repository new hires can't navigate, the log dump nobody wants to read during an incident. For a long time, the standard response was to file a ticket, wait for a platform team, or evaluate a vendor tool. That default is shifting toward something more direct: build it yourself, scoped narrowly, with an AI coding agent doing the first draft.
Why "build it yourself" became the default answer
The shift shows up in the numbers. McKinsey's State of AI 2026 research found that roughly a third of organizations are now opting out of buying off-the-shelf software altogether, choosing instead to build their own tools using agentic coding agents, an instinct that's strongest among teams already seeing measurable returns elsewhere in their AI adoption (source).
That's worth sitting with for a second. Internal tooling used to compete for backlog space against actual product work, so most friction just got absorbed as background cost. Once a working first version can be produced in an afternoon instead of a sprint, the calculation flips, the annoying task becomes worth automating, even at small scale, even for a single team.
Building isn't automatically the safer path
The same research includes a counterweight worth taking seriously before getting excited. Citing MIT NANDA analysis, it notes that internally built systems succeed at roughly a one-in-three rate, compared with about two-thirds for tools purchased from an outside vendor (source).
The gap isn't an argument against building, it's an argument against building big. Sprawling internal platforms fail for the same reasons they always have: unclear ownership, scope creep, and no clean definition of "done." A narrow tool with one job, one defined output, and a human reviewing the result is a fundamentally different bet than an ambitious internal platform, regardless of how the code got written.
Filtering for a good first project
Before picking anything, it's worth checking a project against a short list of criteria:
It solves a task the team repeats often enough to notice.
The inputs already exist and are accessible, GitHub, logs, documentation, deployment data.
The output is immediately actionable, not just informative.
A first version can be scoped in days.
A human stays in the loop to review and approve the result.
Five projects consistently pass that filter across practical agentic-coding project lists. Each is deliberately unglamorous.
1. Pull request risk checker
Reads a diff from GitHub or GitLab, flags changes touching authentication, database migrations, dependencies, or infrastructure, and returns a structured report with severity tags and a reviewer checklist. It should be equally comfortable returning "no obvious risk found" as it is flagging something real, a tool that always finds something to flag isn't trustworthy.
Structured AI-assisted review checklists are a reliable category because they can consistently catch missing tests, security gaps, and documentation omissions without needing subtlety, the diff either touches a sensitive area or it doesn't (related roundup). What it teaches: GitHub API integration, diff parsing, structured output design, and severity classification that a reviewer can actually act on.
2. Codebase documentation assistant
Indexes a repository, generates an architecture overview, and answers plain-language questions with file-level citations instead of generic explanations. The requirement that makes this useful rather than confidently wrong: every answer needs to point back to the actual repository, not to general knowledge about the language or framework (related overview).
A working first version needs a repository connection, a generated repository map, a cited question-and-answer interface, and a documentation-gap report with draft suggestions for human review. What it teaches: retrieval grounded in a specific source, citation as a design requirement rather than a nice-to-have, and access control for a tool reading potentially sensitive code.
3. Log search and incident summarizer
Ingests logs from a file or observability API, groups repeated errors, and compresses a wall of entries into a concise incident summary, affected service, error frequency, first- and last-seen timestamps, related deployment changes, and a link back to the raw log lines.
The non-negotiable design rule: every AI-generated hypothesis gets labeled as unverified, and the underlying evidence is always shown alongside the summary. The tool's job is to compress noise for a human to verify, not to make a root-cause claim on its own authority. What it teaches: log ingestion and filtering, time-series aggregation, and summarization designed to be checked rather than trusted outright.
4. Release notes generator
Pulls merged pull requests between two tags or dates, categorizes them into features, fixes, and breaking changes, and generates separate drafts for internal teams and customers with ticket IDs and implementation jargon stripped from the customer-facing version. A release manager reviews and edits before anything publishes.
This is one of the more shippable projects on this list because the input, output, and review gate are all cleanly defined from the start. What it teaches: audience-specific content transformation and treating human approval as a core feature rather than an afterthought.
5. Deployment readiness checker
Collects PR metadata, CI status, migration files, and environment variable changes, then produces a go/no-go checklist marking each item as passed, needs review, or blocked. A rollback plan is required before anything gets marked ready.
DevOps- and SRE-focused agent projects tend to work well because the inputs and outputs are already operationally defined, deployment checks and incident response both have a repeatable shape a narrow tool can support without needing to be clever about it (related roundup). What it teaches: CI/CD integration, policy checks expressed as structured output, and audit-friendly approval logging.
Comparing the five
| Tool | Best first user | Core input | Core output |
|---|---|---|---|
| PR Risk Checker | Developers and reviewers | Pull request diff | Risk report and checklist |
| Documentation Assistant | New team members | Repository files | Codebase map with cited answers |
| Log Search & Incident Summarizer | On-call engineers | Logs and deployment events | Evidence-backed incident summary |
| Release Notes Generator | Release managers | Merged pull requests | Reviewed internal/customer notes |
| Deployment Readiness Checker | Engineering and DevOps teams | PR, CI, deployment data | Go/no-go checklist |
Matching the project to what you already have
The most reliable way to choose is to look at existing data, not ambition. Active pull requests point toward the risk checker. A repository nobody fully understands points toward the documentation assistant. Noisy production logs point toward the incident summarizer. Frequent releases point toward the notes generator. A history of deployment surprises points toward the readiness checker.
How teams get there technically varies quite a bit. Some assemble a solution around an in-editor assistant like GitHub Copilot or Claude Code and wire the rest by hand. Others reach for orchestration frameworks like LangGraph or CrewAI to coordinate multi-step agent work. A separate group is starting from a natural-language specification and letting a platform produce the architecture, system requirements, service boundaries, database schema before any code is generated, which is the approach spec-first builders like 8080.ai, Replit, and Lovable are built around. The right entry point depends on whether a team wants to assemble the pieces themselves or start from a generated structure and adjust it.
What all five projects share isn't the underlying tooling. It's that each one converts a specific, recurring source of friction into a workflow with visible evidence and a human still making the final call. That's a smaller pitch than "AI builds your next platform" and it's the version of this that tends to actually stay in production once the novelty wears off.
Top comments (0)