Inspiration
Enterprise engineering workflows often depend on scattered data, undocumented relationships, and decisions that require engineers to manually connect the dots. We wanted to explore whether an AI system could do more than simply generate code — could it understand an engineering goal, discover the relevant enterprise context, reason over that context, and then produce and validate an implementation?
That idea became ATLAS: an autonomous engineering intelligence system designed to make enterprise metadata part of the reasoning process rather than an afterthought.
What it does
ATLAS takes a natural-language engineering goal and turns it into a traceable workflow:
- Architecture — analyses the engineering goal.
- Enterprise Metadata — discovers relevant datasets through DataHub using MCP.
- Metadata Reasoning — identifies relationships, problem type, useful features, and suitable ML strategies.
- Engineering — uses Gemini to generate an implementation artifact.
- Quality Assurance — validates the artifact for existence, syntax, dataset/schema consistency, and credential safety.
For example, when given the goal “Build a customer churn prediction pipeline,” ATLAS discovered customer_data and transactions, identified their shared customer_id relationship, recognized the task as binary classification, and recommended appropriate model families.
Importantly, ATLAS does not invent missing enterprise information. When no explicit churn target was present in the discovered metadata, it surfaced that limitation instead of pretending the target existed.
How we built it
We built ATLAS as a modular Python-based engineering kernel with separate workers for architecture, metadata discovery, documentation, engineering, and quality assurance.
The enterprise context layer is powered by DataHub, accessed through MCP for metadata discovery. A metadata reasoning layer interprets the discovered schemas and relationships before passing a constrained engineering plan to Gemini.
The system maintains a workspace and execution timeline so that each stage can be traced through individual ticks. Generated artifacts are then passed through QA checks before the workflow is considered complete.
The project also includes a web interface that exposes the workspace, execution runs, generated artifacts, enterprise data, reasoning results, QA status, and documentation in one place.
Challenges we ran into
One of the biggest challenges was making the system reliable across multiple layers: the frontend, backend kernel, DataHub integration, MCP discovery, and Gemini API all had to work together.
We also encountered issues with MCP/DataHub discovery, backend execution, project structure, and API availability. During development, Gemini's free-tier request quota was exhausted, which forced us to think more carefully about API usage and failure handling.
Another important challenge was preserving the distinction between what the enterprise metadata actually tells us and what the model might assume. We deliberately designed ATLAS to surface missing information rather than silently fabricate it.
Accomplishments that we're proud of
We are proud that ATLAS became more than a code-generation demo. It demonstrates a complete engineering loop:
Goal → Architecture → Enterprise Context → Reasoning → Engineering → Validation
The system successfully discovered real dataset relationships through DataHub/MCP, used that context to constrain its reasoning, generated a Python engineering artifact, and validated the result through a dedicated QA stage.
We are especially proud of the traceability of the workflow. Instead of simply returning an answer, ATLAS exposes how the system moved through each engineering stage.
What we learned
We learned that building an autonomous engineering system is less about making an LLM generate more code and more about giving the model the right context and constraints.
Enterprise metadata can act as a powerful boundary for AI reasoning. It can tell the system what data exists, how datasets relate, and — equally importantly — what information is missing.
We also learned that reliable AI systems need explicit validation and fallback paths. A generated artifact should not automatically be considered correct simply because an LLM produced it.
What's next for ATLAS
The current implementation is a foundation for a broader autonomous engineering platform.
Next, we want ATLAS to support more engineering goals, richer metadata reasoning, stronger artifact validation, and additional enterprise systems beyond the current DataHub integration.
We also want to improve resilience around API failures and quota limits, expand the range of generated artifacts, and make the execution trace even more useful to engineers reviewing or deploying the resulting work.
Log in or sign up for Devpost to join the conversation.