DevPilot — AI-Powered Engineering Intelligence Platform
An AI-powered engineering intelligence platform that transforms fragmented software development data into actionable engineering insights, risk detection, root-cause analysis, and intelligent recommendations.
- Overview DevPilot is an AI-powered Engineering Intelligence Platform designed to help software development teams monitor, understand, and improve the health of their engineering projects. Modern software projects generate a large amount of engineering data every day. Every issue created, pull request opened, commit pushed, code review performed, build executed, deployment completed, and document written produces a signal about the health of a software project. However, this information is usually distributed across multiple tools and systems:
GitHub / GitLab
├── Commits
├── Pull Requests
├── Code Reviews
├── Issues
└── Repository Activity
Jira / Project Management
├── Tasks
├── Bugs
├── Sprints
└── Project Progress
CI/CD Platforms
├── Build Results
├── Test Failures
├── Deployment Results
└── Pipeline Metrics
Documentation Systems
├── Architecture
├── API Documentation
├── Technical Decisions
└── Project Knowledge
Team Communication
├── Discussions
├── Engineering Decisions
├── Incident Information
└── Operational Context
Each system provides useful information, but the information is often isolated. A project manager may know that a project has 42 open issues. A developer may know that 8 pull requests are waiting for review. A DevOps engineer may know that the CI pipeline has failed several times. A technical lead may know that a particular service has been modified repeatedly during the past week. The problem is that these signals may never be interpreted together. DevPilot aims to create a unified Engineering Intelligence Layer that combines these signals and converts them into meaningful engineering insights. Instead of simply showing:
42 Open Issues DevPilot aims to answer: Why are open issues increasing? Which part of the project is creating the bottleneck? Is the project likely to be delayed? Which engineering activity is behaving abnormally? What is the most important problem the team should investigate right now? What action could reduce the current risk? The goal is to move from data visibility to engineering understanding and decision support.
- The Problem 2.1 Engineering Data Fragmentation Modern software projects rarely operate inside a single system. Instead, engineering information is distributed across several tools.
SOFTWARE PROJECT
|
+------------------+------------------+
| | |
v v v
GitHub Jira CI/CD
| | |
Commits Tasks Build Results
PRs Bugs Test Failures
Reviews Sprints Deployments
Issues Progress Pipeline Data
| | |
+------------------+------------------+
|
v
Documentation
|
v
Team Activity
Each system answers a different question. GitHub may answer:
"What code changed?" Jira may answer: "What tasks are still open?" CI/CD may answer: "Which builds or deployments failed?" Documentation may answer: "How is the system supposed to work?" Team communication may answer: "Why was a particular engineering decision made?" But the engineering team ultimately needs to answer a much harder question: "What is the actual health of the project, and what should we do next?" Answering this requires combining information across systems instead of inspecting each source independently. 2.2 Information Overload As projects grow, the amount of engineering information increases rapidly. A medium-sized software project can contain:
500+ Issues
300+ Pull Requests
Thousands of Commits
Hundreds of Code Reviews
Multiple CI/CD pipelines
Dozens of Deployments
Hundreds of Documentation pages
Multiple Engineering Teams
At this scale, manually monitoring everything becomes difficult. Important signals can easily be missed. For example:
Open Issues increased
+
PR review time increased
+
CI failures increased
+
Deployment failures increased
+
Large number of changes in one service
Each signal by itself may appear manageable. Together, they may indicate:
The project is entering a high-risk state. Traditional dashboards may display these metrics separately, but they often do not explain the relationship between them. 2.3 The Context Problem Engineering metrics cannot always be interpreted in isolation. For example:
50 Open Issues
does not automatically mean that the project is unhealthy. Those issues might be low-priority feature requests, old backlog items, documentation tasks, or minor UI improvements. Similarly:
10 CI failures
does not automatically mean that the project is unstable. The failures might be caused by a known flaky test, infrastructure problems, or a temporary dependency outage. Meaningful engineering analysis requires:
Metric
+
Context
+
Historical behavior
+
Relationships between events
2.4 The Reactive Development Problem Most software development workflows are reactive:
Problem occurs
↓
Developer notices it
↓
Developer investigates
↓
Team discusses it
↓
Action is taken
For example:
Deployment fails
↓
Someone notices
↓
Someone investigates logs
↓
Root cause is identified
↓
Team fixes the problem
This process depends heavily on humans continuously monitoring several systems. DevPilot aims to make this workflow more proactive:
Engineering activity
↓
Continuous analysis
↓
Potential anomaly/risk detected
↓
Relevant context gathered
↓
Root cause analyzed
↓
Team informed
↓
Recommended action
The goal is not to replace engineers. The goal is to reduce the amount of repetitive monitoring and initial investigation they have to perform manually. 2.5 The Decision-Making Problem Engineering teams do not only need information. They need to make decisions. Consider a project with:
42 Open Issues
12 Pending PRs
8 CI Failures
3 Recent Deployment Failures
4.7 Day Average PR Review Time
A traditional dashboard might display those numbers. But an engineering lead needs to know:
Which problem matters most?
What is causing the slowdown?
What is likely to happen next?
Which issue should be prioritized?
Which component is creating the bottleneck?
What action should be taken?
DevPilot aims to bridge this gap:
OBSERVATION
↓
ANALYSIS
↓
EXPLANATION
↓
RECOMMENDATION
2.6 Root Cause vs. Symptom A major idea behind DevPilot is distinguishing between symptoms and underlying causes. Example:
Symptom:
Project progress is decreasing.
That alone does not explain why. DevPilot can investigate related signals:
Project progress ↓
|
+── Open issues ↑
|
+── PR review time ↑
|
+── CI failures ↑
|
+── Deployment failures ↑
The primary bottleneck might actually be CI instability, code-review bottlenecks, a specific service, a problematic dependency, or a large cluster of blocked issues. This is more useful than simply reporting:
"Project progress is decreasing." 2.7 Example: Detecting a High-Risk Project Consider an authentication migration project:
Project Progress:
42%
Open Issues:
27
Pending Pull Requests:
8
CI Failures:
6
Average PR Review Time:
4.2 days
Recent Deployment Failures:
3
Authentication-related Issues:
+63% this week
DevPilot can combine these signals and generate an engineering insight. Example:
HIGH RISK
The authentication migration is showing
multiple indicators of engineering instability.
Primary signals:
• Authentication-related issues increased significantly
• Pull-request review time is increasing
• Multiple CI failures are occurring
• Recent deployments have failed
• Project progress remains below the expected trajectory
The system can then provide a possible explanation:
Potential Bottleneck:
The authentication service is experiencing
increased development and review friction.
Potential contributing factors:
1. High number of concurrent changes
2. Increasing review backlog
3. Repeated CI failures
4. Deployment instability
And then:
Recommended Actions:
1. Investigate failing authentication tests
2. Review high-impact pending pull requests
3. Prioritize blocked authentication issues
4. Investigate recent deployment failures
The exact recommendations will eventually be generated from actual project data and implemented analytics/AI logic.
- Proposed Solution DevPilot introduces an Engineering Intelligence Layer between raw development data and engineering decision-making.
Engineering Systems
|
+----------------+----------------+
| | |
GitHub Jira CI/CD
| | |
+----------------+----------------+
|
Documentation
|
Team Activity
|
v
+----------------------+
| Data Integration |
| & Normalization |
+----------+-----------+
|
v
+----------------------+
| Engineering |
| Analytics |
+----------+-----------+
|
+-------------+-------------+
| |
v v
Machine Learning AI / LLM
& Anomaly Detection & LangGraph
| |
+-------------+-------------+
|
v
+----------------------+
| Engineering |
| Intelligence |
+----------+-----------+
|
+-------------+-------------+
| |
v v
Insights / Risks Recommendations
| |
+-------------+-------------+
|
v
DevPilot UI
The objective is to move from:
"Something is wrong." To: "Something may be wrong, these signals suggest why, this is the current risk, and these are the next things the engineering team should investigate."
- What DevPilot Actually Is DevPilot should not be thought of simply as:
"A dashboard with AI." The dashboard is only the presentation layer. The actual product is an engineering intelligence system. The long-term system combines:
Engineering Data
↓
Data Processing
↓
Engineering Analytics
↓
Machine Learning
↓
AI Reasoning
↓
Insights
↓
Recommendations
↓
Engineering Action
- Core Product Capabilities 5.1 Engineering Dashboard The dashboard provides a high-level view of engineering health. Example metrics: Active Projects Open Issues Completed Work Blocked Work Project Health Risk Levels AI Insights Current Work Engineering Activity The goal is not simply to show numbers, but to provide context around them. 5.2 Project Management Each project can contain:
Project
├── Name
├── Description
├── Status
├── Progress
├── Risk
├── Team Members
├── Open Issues
├── Pull Requests
├── Commits
├── Deployments
├── Documentation
└── AI Insights
5.3 Issue Intelligence DevPilot can analyze issues using: Priority Severity Frequency Status Project Historical trends Related development activity Dependencies 5.4 Pull Request Analysis Potential PR metrics include: Review time Number of changes Number of reviewers Merge time Rework frequency Related issues CI failures 5.5 Project Risk Detection DevPilot can calculate a project risk score using multiple engineering signals:
Issue velocity
PR review time
Commit frequency
CI failures
Deployment failures
Bug frequency
Project progress
Blocked tasks
Developer activity
Example:
Project Risk: HIGH
Risk Score: 82/100
- AI Engineering Assistant One of the main features of DevPilot is an AI Engineering Assistant. A developer can ask questions such as:
Why is this project high risk?
What caused the recent increase in issues?
Which project needs attention first?
Why are our builds failing?
Which PRs are causing bottlenecks?
Summarize the current engineering health.
What should the team investigate today?
Explain the authentication architecture.
Find related issues.
Create an implementation plan for this feature.
The assistant should answer using relevant project context and application data rather than relying only on generic LLM knowledge.
- Why LangGraph? Some engineering questions require multiple steps.
User Question
↓
Understand Intent
↓
Retrieve Project Context
↓
Retrieve Issues
↓
Retrieve PRs
↓
Retrieve Documentation
↓
Analyze Signals
↓
Generate Recommendation
↓
Validate Response
↓
Return Answer
This is a workflow rather than a simple:
Question → LLM → Answer
LangGraph can be used to implement stateful, multi-step AI workflows. A future workflow could contain:
Question Analyzer
↓
Project Data Retriever
↓
Issue Analyzer
↓
Pull Request Analyzer
↓
Commit Analyzer
↓
Risk Analyzer
↓
Recommendation Generator
↓
Response Generator
The purpose is not to use LangGraph simply because it is an AI technology. It is intended to be used where a multi-step stateful workflow provides real value.
- Machine Learning / Deep Learning DevPilot can complement LLM reasoning with traditional machine learning and, where justified, deep learning. 8.1 Project Delay Prediction Use historical engineering signals to estimate the probability that a project will miss an expected deadline.
Project: Authentication Migration
Delay Probability: 81%
Risk Level: HIGH
8.2 Anomaly Detection Detect unusual engineering activity.
Normal CI failures:
1–2 per week
Current CI failures:
9 this week
Anomaly detected.
8.3 Engineering Risk Prediction Potential features:
Issue velocity
PR review time
Commit frequency
CI failure rate
Deployment frequency
Bug rate
Project progress
- Two Complementary Intelligence Layers LLM / LangGraph Layer Used for: Natural-language engineering questions Explanations Root-cause analysis Recommendations Summarization Documentation analysis AI engineering assistance Multi-step engineering workflows ML / Deep Learning Layer Used for: Risk prediction Delay prediction Anomaly detection Trend analysis Engineering activity prediction Together:
DevPilot Intelligence
|
+----------+----------+
| |
ML / DL LangGraph
| |
Prediction Reasoning
Anomalies Analysis
Risk Workflows
Trends Recommendations
| |
+----------+----------+
|
v
Engineering Intelligence
- System Architecture
DEVpilot
|
+--------------+--------------+
| |
FRONTEND BACKEND
React FastAPI
| |
React Router REST APIs
TypeScript Validation
Tailwind Business Logic
| |
| +----------+----------+
| | |
| v v
| SQLAlchemy AI Layer
| | |
| v +------+------+
| PostgreSQL | |
| v v
| LangGraph ML / DL
| | |
| +------+------+
| |
+------------------- API ------------------+
|
v
User
- Frontend Architecture The frontend is being developed as a real React application rather than a collection of standalone Stitch HTML pages. The Stitch-generated screens are treated as the visual/design source of truth. React is responsible for: Component architecture Routing UI state Forms User interactions API communication Loading states Error states Responsive behavior Planned structure:
frontend/
└── src/
├── components/
│ ├── layout/
│ ├── dashboard/
│ ├── projects/
│ ├── issues/
│ ├── kanban/
│ ├── analytics/
│ ├── ai/
│ └── team/
├── pages/
├── layouts/
├── routes/
├── services/
├── types/
├── hooks/
├── data/
└── lib/
React Architecture Concepts
Page: A complete destination with a URL, such as /dashboard or /projects.
Route: Maps a URL to a page, such as /projects/:projectId → ProjectOverview.
Layout: Shared application structure such as Sidebar, Navbar, and the page outlet.
Component: A reusable UI/behavior unit such as ProjectCard, SummaryCard, IssueCard, or StatusBadge.
Data: The information rendered by components, such as projects, issues, users, and analytics.
State: Information that can change during UI usage, such as search text, filters, selected tabs, modal visibility, and drag state.
- Data vs. State Data Examples:
Project
Issue
User
Comment
Document
Pull Request
Analytics
Example:
{
"id": "123",
"name": "Core API V3",
"progress": 92,
"risk": "LOW"
}State Examples:
Search text
Selected filter
Open modal
Selected project
Current tab
Kanban position
Authentication state
Example:
const [search, setSearch] = useState("");- What Will Eventually Come From the Backend? Persistent or shared application information should eventually come from the backend:
Project name
Project description
Project status
Project progress
Issues
Comments
Users
Team members
Pull Requests
Analytics
Notifications
Documents
Risk scores
AI insights
Future flow:
PostgreSQL
↓
SQLAlchemy
↓
FastAPI
↓
JSON API Response
↓
React
↓
UI
Pure presentation concerns stay in the frontend:
Sidebar width
Colors
Typography
Spacing
Hover styles
Modal open/closed state
- Backend Architecture The backend will be built using Python and FastAPI. Responsibilities: REST APIs Authentication Authorization Project management Issue management Analytics Data validation Business logic AI integration
React
|
| HTTP
v
FastAPI
|
+---- Authentication
|
+---- Projects
|
+---- Issues
|
+---- Analytics
|
+---- AI
|
v
SQLAlchemy
|
v
PostgreSQL
- PostgreSQL Potential entities include:
users
workspaces
projects
project_members
issues
issue_comments
pull_requests
commits
deployments
activities
documents
notifications
ai_insights
risk_predictions
Example:
Project
|
+---- Issues
|
+---- Pull Requests
|
+---- Members
|
+---- Commits
|
+---- Deployments
|
+---- Documentation
|
+---- Analytics
- SQLAlchemy SQLAlchemy will act as the ORM between FastAPI and PostgreSQL. Example model:
class Project(Base):
__tablename__ = "projects"
id = Column(UUID, primary_key=True)
name = Column(String)
description = Column(Text)
status = Column(String)Relationships can be represented using SQLAlchemy relationships.
class Project(Base):
issues = relationship("Issue")- API Design Planned examples:
GET /api/projects
POST /api/projects
GET /api/projects/{project_id}
PUT /api/projects/{project_id}
DELETE /api/projects/{project_id}
GET /api/issues
POST /api/issues
GET /api/issues/{issue_id}
PUT /api/issues/{issue_id}
DELETE /api/issues/{issue_id}
AI-related examples:
POST /api/ai/chat
POST /api/ai/analyze
POST /api/ai/search
POST /api/ai/plan
POST /api/ai/actions/approve
POST /api/ai/actions/reject
- Example End-to-End Data Flow Suppose a user opens the Projects page:
User
↓
React /projects
↓
Projects page
↓
projectApi.getProjects()
↓
GET /api/projects
↓
FastAPI
↓
Service Layer
↓
SQLAlchemy
↓
PostgreSQL
↓
Project records
↓
FastAPI JSON response
↓
React
↓
projects.map(...)
↓
ProjectCard
↓
User
- Example AI Risk Analysis Flow
User
|
| "Why is this project high risk?"
v
React
|
| POST /api/ai/analyze
v
FastAPI
|
v
LangGraph Workflow
|
+--> Retrieve project data
|
+--> Retrieve issues
|
+--> Retrieve PRs
|
+--> Retrieve commits
|
+--> Retrieve documentation
|
+--> Retrieve analytics
|
v
Risk Analysis
|
v
LLM Reasoning
|
v
Validated Explanation
|
v
FastAPI
|
v
React
|
v
AI Insight
- Why DevPilot Is Different from Traditional Project Management Traditional project-management tools primarily answer:
"What tasks exist and what is their status?" DevPilot aims to answer: "What is happening across the engineering system, what looks risky or abnormal, why is it happening, and what should we do next?" Traditional dashboard
Issue #1042
Status: In Progress
Priority: High
DevPilot
Authentication Risk Detected
Why?
- 7 authentication-related issues opened this week
- PR review time increased
- Multiple CI failures involve auth-service
- Recent commits modified token refresh logic
Likely contributing factor:
Authentication changes are creating instability.
Recommended action:
Review the recent authentication changes
and investigate the failing integration tests.
- End-to-End Product Vision A developer should be able to open DevPilot and immediately understand:
What is happening?
↓
What is going wrong?
↓
Why is it happening?
↓
How serious is it?
↓
What should we do next?
Core philosophy:
RAW ENGINEERING DATA
↓
CONTEXT
↓
ANALYSIS
↓
EXPLANATION
↓
RECOMMENDATION
↓
ACTION
- Development Roadmap Phase 1 — Frontend Foundation React + TypeScript Vite Tailwind CSS Stitch design-system integration Shared application layout Sidebar Navbar Dashboard Projects Project cards Project overview Routing Reusable components Phase 2 — Frontend Functionality React state Forms Search Filtering Sorting Modals Project creation Project editing Dynamic routes Loading states Error states Phase 3 — Backend FastAPI REST API architecture Pydantic schemas Dependency injection Authentication Authorization Error handling Service layer Phase 4 — Database PostgreSQL SQLAlchemy Relationships Alembic Indexing Transactions Phase 5 — Frontend + Backend Integration Replace mock frontend data with real API data:
React
↓
FastAPI
↓
SQLAlchemy
↓
PostgreSQL
Phase 6 — AI LLM integration LangGraph Project context retrieval AI engineering assistant Risk analysis Issue analysis Root-cause analysis Recommendations Phase 7 — Machine Learning Feature engineering Historical data analysis Risk prediction Delay prediction Anomaly detection Model evaluation Phase 8 — Production Docker Environment variables CI/CD Logging Monitoring Security Cloud deployment Production database
- Development Philosophy DevPilot is being developed both as a portfolio project and as a practical full-stack learning project. The development process is:
Understand
↓
Design
↓
Implement
↓
Debug
↓
Refactor
↓
Test
↓
Document
↓
Deploy
AI development tools may assist development, but important architectural decisions and core concepts should be understood before they are accepted. The objective is not simply to generate a large amount of code. The objective is to understand how the system works end-to-end.
- Current Development Stage The project is currently in the frontend architecture and implementation phase. Current work focuses on:
Google Stitch Design
↓
React Components
↓
Shared Layout
↓
Pages
↓
Routing
↓
Frontend Interactions
Mock data is intentionally used during the initial frontend phase. For example:
src/data/projects.ts
contains temporary project data. This will later be replaced by:
React
↓
GET /api/projects
↓
FastAPI
↓
SQLAlchemy
↓
PostgreSQL
- Technology Stack Frontend React TypeScript Vite Tailwind CSS v4 React Router Material Symbols TanStack Query (planned) Axios / API client (planned) Backend Python FastAPI Pydantic SQLAlchemy Alembic Uvicorn Database PostgreSQL AI LangGraph LLM APIs / local LLMs where appropriate RAG / retrieval Embeddings / vector search where justified ML / DL Python ML ecosystem Scikit-learn where appropriate PyTorch where justified DevOps Git GitHub Docker Docker Compose CI/CD Cloud deployment
- Learning Objectives By completing DevPilot, the project should demonstrate practical understanding of: Frontend React component architecture TypeScript Props State Routing Dynamic routes Forms Validation API integration Error handling Responsive design Backend FastAPI REST API design Pydantic Dependency injection Service architecture Authentication Authorization Database PostgreSQL SQL Relational modeling Foreign keys Indexes Transactions SQLAlchemy Alembic migrations AI LLM integration LangGraph Stateful workflows Tool usage Retrieval RAG Embeddings AI evaluation Machine Learning Feature engineering Model training Evaluation Anomaly detection Risk prediction Production Docker Environment management Testing CI/CD Logging Monitoring Deployment
- One-Sentence Definition
DevPilot is an AI-powered engineering intelligence platform that connects fragmented software development data, analyzes engineering health using analytics and machine learning, reasons over that context using AI workflows, and helps engineering teams understand risks and decide what to do next.
- Final Summary DevPilot is built around a simple progression:
Raw Engineering Data
↓
Context
↓
Analytics
↓
ML / Anomaly Detection
↓
AI Reasoning
↓
Insights
↓
Recommendations
↓
Engineer
↓
Action
The ultimate objective is to transform software development from a workflow where engineers must continuously search for, interpret, and connect fragmented signals into a workflow where the system proactively surfaces useful engineering intelligence. DevPilot is therefore intended to become more than a project-management application. It is a developer-focused engineering intelligence and decision-support platform. Product Link:https://devpilot33.netlify.app/dashboard
The previously used Render-hosted backend is retired. The repository does not identify a replacement production backend or database, so no production API endpoint is configured here.
For local development, configure and start the FastAPI backend from backend
using the local settings in backend/.env.example, then start the frontend
from frontend with npm run dev. The frontend API base URL defaults to
http://127.0.0.1:8000/api/v1 in frontend/src/config/api.ts.
To use a future backend, set VITE_API_URL to its API base URL in the frontend
build environment. netlify.toml configures the Netlify frontend build and SPA
routing only; any production API setting must be checked in Netlify's site
environment and point to an available backend.