A Different Way to Think About the Repository Landing Page

I’ve been spending a lot of time thinking about developer tooling lately, and one question keeps coming back to me: in the age of AI-assisted coding, what should a repository landing page actually look like?

This is my current thinking. It’s opinionated, it’s still evolving, and I’d love to hear what others think.

Where I’m Starting From

The repository landing page most of us use today has a familiar structure:

• Top bar— navigation, search, actions
• Content area— file list on the left, meta info on the right (description, tags, releases)
• Below the file list — the README, rendered as a document

It’s a solid reading experience. It’s designed to answer: ”What is this project?”

That question is still valid. But I find myself wondering if it’s the only question worth designing for.

My Hypothesis

When I think about how I actually interact with a repository today, I don’t read the README top to bottom anymore. I ask AI to brief me — key points, project structure, how to get started. It’s still reading, just AI-assisted reading. The whole README is there, but I’m consuming it through a conversation rather than scrolling through a document.

That shift made me think: if the interaction is already centered around AI chat, why isn’t the landing page designed around it? In my view, AI chat should be the primary surface — the thing the layout is built around. Everything else supports it.

The other thing I noticed is that CI/CD information is usually buried. It lives in a separate tab, or you have to know where to look. But build status is genuinely useful context when you’re working on a repository. So rather than hiding it, I wanted to bring it to the surface — not as a primary focus, but as a visible companion to the coding experience.

The Layout I’ve Been Thinking About: 1 : 2 : 1

My idea is to divide the content area into three vertical panels in a 1 : 2 : 1 ratio:

┌─────────────────────────────────────────────────────┐
│                      Top Bar                        │
├──────────────┬──────────────────────┬───────────────┤
│              │                      │               │
│  File Tree   │      AI Chat         │  Build Log    │
│              │  (message list)      │               │
│    (1)       │                      │     (1)       │
│              │   [  input box  ]    │               │
└──────────────┴──────────────────────┴───────────────┘

Three panels, three responsibilities:

┌───────────────────────┬──────────────────────┬────────────────────┐
│         Panel         │      Represents      │    Role in SDLC    │
├───────────────────────│──────────────────────│────────────────────┤
│    File Tree (left)   │     The codebase     │   Version Control  │
│───────────────────────│──────────────────────│────────────────────│
│    AI Chat (center)   │   The conversation   │        Coding      │
│───────────────────────│──────────────────────│────────────────────│
│    Build Log (right)  │     The pipeline     │        CI/CD       │
└───────────────────────┴──────────────────────┴────────────────────┘

What I like about this structure is that it maps to the full software development lifecycle — version control, coding, CI/CD — left to right, in the natural order of work. When someone lands on this page, the layout itself communicates: here’s where we build things.

A First Look

The screenshots below are from Cloud Native Build (CNB), a platform I’ve been building this on. The data shown is real.

The reason I chose this platform is that it features a built-in build system and a rich ecosystem. Is has International and China version,

Login Scene

Landing Scene

Repository File Content Preview

How Each Panel Works in My Head

🗂️ File Tree — A Map, Not an Editor

In my thinking, the left panel is read and navigate only, at least for now. I want it to feel like a map of the codebase, not an editor. The AI handles write operations through the chat.

When the AI writes a change and the user accepts it, the file tree updates in real time. That visual feedback feels important — it’s the moment the conversation becomes something concrete.

💬 AI Chat — Where the Work Happens

The center panel is the heart of the experience.

⚠️ The design decisions below are still under construction — they represent where I want to take this, not what’s built today. They’ll come together in later versions.

Keeping initial context lightweight. I only load the README into the AI’s context by default. It’s enough to get started, and it keeps things fast. If the user wants the AI to understand a specific file, they can include it — either by right-clicking in the file tree, or by typing @relative/path in the input box, which triggers a fuzzy file picker. I like that this serves both mouse-first and keyboard-first users naturally.

A trust model for code changes. When the AI suggests a change, it shows up as an inline diff block in the chat — unified diff format, to fit the width. Each block is collapsible (showing a +12 -3 summary by default), and the user accepts or rejects per file. I think per-file acceptance is the right granularity — it’s atomic, it’s deliberate, and it maps to how developers already think about staging changes.

The user stays in control of side effects. The AI can suggest triggering a build, but it never does it on its own. It asks first. I feel strongly about this boundary — code changes are one thing, but triggering a pipeline that might deploy something is a different category of action.

🔧 Build Log — Always Telling You Something

The right panel shows a live, streaming build log. A status badge at the top — green, red, or yellow — gives a quick read on repository health.

When there’s no active build running, the panel defaults to showing the latest build result. I didn’t want it to feel empty or cold when nothing is happening. The repository’s current health should always be visible.

Build triggers are wrapped as OpenAPI tools available to the AI. This means the pipeline ID comes back directly into the conversation context — no extra wiring, no separate UI state to manage.

What a Session Might Look Like

Here’s how I imagine a typical flow playing out:

1. Land on the repository. File tree on the left, AI chat in the center, latest build status on the right.
2. Type: ”Add rate limiting to the authentication endpoint.”
3. AI — working from the README — asks a clarifying question, then suggests including auth.js. Type @auth.js.
4. AI proposes changes. Inline diff appears in chat. Review, accept per file.
5. File tree updates. AI asks: ”Want me to trigger a build?” Confirm.
6. Build log panel comes alive. Status badge turns yellow.
7. Build fails. Badge turns red. Ask: ”What went wrong?”
8. AI calls the build status tool with the pipeline ID already in its context. Reads the error. Suggests a fix.
9. Keep going until the badge turns green.

The three panels aren’t just sitting next to each other — they’re participating in the same story.

Why I Think Replacing the Old Layout Makes Sense

One thing I kept asking myself is: do I need to keep the README and meta info panel? My current answer is no, and here’s my reasoning.

AI chat is a superset of what those panels offer. Anything a visitor might want to know — project summary, setup instructions, recent changes — they can just ask. The README becomes the AI’s starting context rather than a static document on the page.

I’m aware this is a strong position. Some visitors aren’t there to build — they’re evaluating, browsing, reading. But I think the chat handles that too, just in a more interactive way.

One Conversation, One Unit of Work

One principle I’ve settled on that shapes a lot of the design: one conversation should correspond to one feature or one bug fix.

It keeps the AI’s context coherent. It keeps pipeline IDs meaningful — the latest one is always the relevant one. And it keeps the user focused on one thing at a time, which maps naturally to one branch, one PR, one ticket.

Something I didn’t anticipate when I started thinking this way: if a conversation captures one unit of work — the AI suggestions, the file changes, the build results — it starts to look a lot like a lightweight dev journal. An audit trail of decisions that git log never really gave us. I haven’t designed for that yet, but it’s something I want to explore in a future version.

This is Still v0.1 Thinking

I want to be clear that this is a work in progress. What I’m focused on right now is getting the core interaction model right — the layout, the chat flow, the build feedback loop. There’s a lot I haven’t figured out yet.

But the core idea feels right to me: a repository landing page that’s designed around AI chat, with the full SDLC visible and within reach. A layout that invites you to start a conversation and see where it takes you.

I’m curious whether this resonates with others, or whether I’m solving a problem that doesn’t exist for most people. Either way, I’d love to hear your thoughts.

If you’re building something in this space or have opinions on developer tooling UX, feel free to reach out. ocleo1/cnb-repo-buddy