I've been working on an open-source project called Kodiak, and I’m finally at the point where I want other developers to tear it apart.

The idea is simple:

Instead of building another chatbot that generates code when you ask it a question, I want Kodiak to behave more like an AI software engineering workflow.

A task should be able to go through something closer to:

Plan → Research → Retrieve context → Code → Test → Review → Iterate

What Kodiak is trying to become

Kodiak is being built around multiple components rather than one giant LLM call:

- Planner / researcher / coder / tester / reviewer agents

- RAG and project-context retrieval

- Persistent memory

- Task and project management

- FastAPI backend

- PostgreSQL for persistent data

- Redis for queueing/state

- Celery for background worker execution

- ChromaDB for vector/context retrieval

- Docker-based development environment

- Pydantic-based schemas and validation

The backend is now running, and I've completed the initial Project and Task API work.

I've also been spending a surprising amount of time on the less exciting part of the project: making the infrastructure actually survive real-world conditions.

That has meant dealing with things like:

- PostgreSQL integration

- Redis services

- Docker environments

- Celery worker execution

- Pydantic v2 compatibility

- GitHub Actions / CI

- integration tests

- dependency and startup issues

- Windows development issues

And honestly, this is where I'm learning the most.

The interesting problem isn't really:

«"Can an LLM write code?"»

It obviously can.

The harder question is:

«Can you build a system around LLMs that can reliably execute a software-engineering workflow without falling apart when one component fails?»

That's what I'm trying to explore with Kodiak.

Why I'm posting this

I'm still actively developing it, so I'm not presenting Kodiak as a finished product.

I'd genuinely like feedback from people who have experience with:

- AI agents

- RAG systems

- developer tools

- FastAPI / Python

- distributed workers

- LLM orchestration

- open-source projects

- testing / CI infrastructure

Especially if you see something fundamentally wrong with the architecture.

And if you're interested in actually contributing, I'd love to have a few developers jump in and help shape the project rather than me building everything alone.

If you were building this from scratch, what would you change first?

And more importantly: what part of this architecture do you think is most likely to fail in production?

I've been working on an open-source project called Kodiak, and I’m finally at the point where I want other developers to tear it apart.

The idea is simple:

Instead of building another chatbot that generates code when you ask it a question, I want Kodiak to behave more like an AI software engineering workflow.

A task should be able to go through something closer to:

Plan → Research → Retrieve context → Code → Test → Review → Iterate

What Kodiak is trying to become

Kodiak is being built around multiple components rather than one giant LLM call:

- Planner / researcher / coder / tester / reviewer agents

- RAG and project-context retrieval

- Persistent memory

- Task and project management

- FastAPI backend

- PostgreSQL for persistent data

- Redis for queueing/state

- Celery for background worker execution

- ChromaDB for vector/context retrieval

- Docker-based development environment

- Pydantic-based schemas and validation

The backend is now running, and I've completed the initial Project and Task API work.

I've also been spending a surprising amount of time on the less exciting part of the project: making the infrastructure actually survive real-world conditions.

That has meant dealing with things like:

- PostgreSQL integration

- Redis services

- Docker environments

- Celery worker execution

- Pydantic v2 compatibility

- GitHub Actions / CI

- integration tests

- dependency and startup issues

- Windows development issues

And honestly, this is where I'm learning the most.

The interesting problem isn't really:

«"Can an LLM write code?"»

It obviously can.

The harder question is:

«Can you build a system around LLMs that can reliably execute a software-engineering workflow without falling apart when one component fails?»

That's what I'm trying to explore with Kodiak.

Why I'm posting this

I'm still actively developing it, so I'm not presenting Kodiak as a finished product.

I'd genuinely like feedback from people who have experience with:

- AI agents

- RAG systems

- developer tools

- FastAPI / Python

- distributed workers

- LLM orchestration

- open-source projects

- testing / CI infrastructure

Especially if you see something fundamentally wrong with the architecture.

And if you're interested in actually contributing, I'd love to have a few developers jump in and help shape the project rather than me building everything alone.

If you were building this from scratch, what would you change first?

And more importantly: what part of this architecture do you think is most likely to fail in production?

I've been heads-down on this for a while and finally have enough working (and enough broken) to make a real update instead of a "check out my repo" post. This is a build-in-public thread — I want technical pushback, not upvotes.

Kodiak is an open-source attempt at an autonomous software engineering platform — the idea is a pipeline of specialized agents (planner, researcher, coder, tester, reviewer) that can take a task, break it down, retrieve relevant context from a codebase, write code, test it, and get it reviewed, with a human able to step in at any point.

Why I'm building this

Most "AI coding agent" projects I've used either (a) are a thin wrapper around one LLM call with no real state management, or (b) are closed-source products where you can't see or change how decisions get made. I wanted something where the orchestration, memory, and retrieval layers are actually inspectable and swappable — partly because I think that's the only way multi-agent systems become trustworthy enough to use on real repos, and partly because I just wanted to understand the problem by building it.

I'm not claiming this is a solved problem. I'm not sure it's a solvable-by-one-person problem. But I'd rather build it in the open and get it wrong visibly than sit on it.

[Insert architecture diagram screenshot here — CLI → CLI Services → Agents → DB/GitHub/LLMs]

What's actually built (not roadmap, actually running)

• FastAPI backend up and running
• Project API — complete
• Task API — complete
• Pydantic v2 schema issues finally fixed (this took longer than I want to admit)
• Docker + PostgreSQL + Redis setup — working end to end
• Agent architecture scaffolded: planner, researcher, coder, tester, reviewer
• RAG / context retrieval system for pulling relevant code context into agent prompts
• A memory system for persisting agent state and history across a task
• Celery integration — in progress, this is the current front line

[Insert screenshot: Swagger/OpenAPI docs showing Project + Task endpoints]

[Insert GIF: kodiak CLI kicking off a task and streaming progress]

The hard part — worker execution pipeline

This is where I'm currently spending all my time, and it's the part I'd most love feedback on.

The Task API and agent logic are solid on their own, but wiring them into Celery for actual async execution surfaces problems that don't show up in a synchronous prototype:

• State handoff between agents. Each agent (planner → researcher → coder → tester → reviewer) needs the previous agent's output plus accumulated context, without the whole thing ballooning into an unbounded prompt or a fragile shared-memory blob.
• Failure semantics. If the coder agent produces something the tester agent rejects, what actually happens? Retry the coder with feedback? Kick it back to the planner? Fail the task? I don't think there's a universally right answer here, and I don't want to hardcode one path.
• Task durability vs. LLM cost. Celery retries are cheap for normal jobs; they're not cheap when a retry means re-running an LLM call chain. I need idempotency and checkpointing that's aware of where in the agent pipeline a task died, not just whether it died.
• Observability into a black box. Once execution is async and distributed across workers, "why did this task produce this output" becomes much harder to answer. Logging agent decisions in a way that's actually useful for debugging (not just noisy) is its own design problem.

None of these are exotic problems, but getting the details right — instead of a pipeline that technically works on the happy path — has been the real engineering work of the last stretch.

[Insert screenshot/GIF: Celery Flower dashboard or task queue visualization, once available]

What's next

Worker execution pipeline is the current focus — getting Celery tasks to reliably drive the full agent sequence with proper state handoff and failure recovery. After that: tightening the RAG retrieval quality and expanding test coverage around the agent layer. This project is moving fast and the architecture is still evolving, so if you look at the code today vs. in a month, expect real differences.

Where I could use other people's brains

I'm not asking for a pile of PRs — I'm mainly looking for people who've solved (or fought with) similar problems to poke holes in the approach:

• Anyone who's built retry/checkpointing logic for LLM-call-heavy async pipelines — I'd genuinely like to know what you'd do differently with Celery here (or whether you'd reach for something else entirely).
• Feedback on the agent handoff/state design, especially if you've worked with LangGraph or similar orchestration in production.
• If you just want to dig into the RAG/memory subsystem or the CLI layer, those are also open and reasonably self-contained.

Repo's linked below. Issues are tagged, architecture doc is in the repo if you want the full picture before diving in. Happy to answer anything in the comments — including "why did you make X decision," I'd rather defend or fix it than have it go unquestioned.

3. Suggested Subreddits

Subreddit	Why	Notes
r/opensource	Direct audience for build-in-public OSS updates	Strong fit, low self-promo friction
r/Python	Backend is FastAPI/Python, technical crowd	Lead with the engineering, not the pitch
r/AI_Agents	Core topic match (multi-agent systems)	Very receptive to architecture discussion
r/LocalLLaMA	Technical AI engineering crowd, appreciates real implementation detail	Emphasize the LLM orchestration challenges
r/SoftwareEngineering	Engineering-process angle (state management, failure semantics)	Good for the "hardest challenges" section specifically
r/programming (use with caution)	Huge reach	Strict self-promo rules — only post if you engage heavily in comments and it doesn't read as promotional

Recommend staggering posts across 2-3 of these over a week or two rather than cross-posting simultaneously — same content posted everywhere at once tends to read as spam even when the intent isn't.

4. Image / GIF Suggestions

1. Architecture diagram — CLI → CLI Services → Agents → DB/GitHub/LLMs layers, clean and simple (this alone will get people to trust the project is real).
2. Swagger/OpenAPI docs screenshot — showing the Project and Task API endpoints live.
3. Terminal GIF — running kodiak CLI end to end: kicking off a task, watching agent stages progress, seeing output.
4. Agent pipeline flow GIF — a simple animated diagram showing a task moving through planner → researcher → coder → tester → reviewer, with status changes.
5. Celery/Flower dashboard screenshot — once the worker pipeline is stable enough to show, this visually proves the async execution claim.
6. Before/after schema fix — optional, a small code snippet showing a Pydantic v2 gotcha and the fix; devs love this kind of concrete detail and it's shareable on its own.

Hello everyone,

I'd like to share a project I've been building over the past several months called **Kodiak**.

Kodiak is an open-source AI software engineering platform designed to assist developers throughout the software development lifecycle by combining repository intelligence, Retrieval-Augmented Generation (RAG), long-term memory, and multi-agent orchestration.

Rather than functioning as a general-purpose chatbot, Kodiak is being developed as an engineering platform that understands software projects, retrieves relevant context, plans development tasks, and coordinates specialized AI agents to help developers work more efficiently.

## Current Architecture

Kodiak currently includes:

- Multi-agent execution framework

- Retrieval-Augmented Generation (RAG)

- Long-term memory system

- Repository indexing and contextual search

- FastAPI backend

- Celery task orchestration

- Plugin architecture

- Docker-based deployment

- Redis task queue

- PostgreSQL persistence

- ChromaDB vector storage

- Modular REST API

## Technology Stack

- Python

- FastAPI

- Celery

- PostgreSQL

- Redis

- ChromaDB

- SQLAlchemy

- Pydantic

- Docker

## Project Vision

The long-term objective is to build an extensible AI engineering platform capable of:

- Understanding large software repositories

- Planning complex engineering tasks

- Maintaining long-term contextual memory

- Selecting and coordinating specialized AI agents

- Integrating external developer tools

- Supporting human-in-the-loop workflows for high-impact actions

The emphasis is on creating a modular platform that developers can self-host, extend, and customize for their own engineering workflows.

## Looking for Feedback

I'm particularly interested in feedback regarding:

- Overall architecture

- System design

- Multi-agent orchestration

- RAG implementation

- Memory architecture

- Plugin framework

- API design

- Scalability

- Developer experience

Constructive criticism is genuinely welcome.

## Contributors

I'm also looking for contributors interested in areas such as:

- Python

- FastAPI

- AI Engineering

- LLM Applications

- Backend Development

- Frontend Development

- DevOps

- Testing

- Documentation

The repository already contains beginner-friendly issues for anyone interested in contributing.

## Repository

GitHub:

https://github.com/ShamGaneshan2008/Kodiak

Documentation:

https://github.com/ShamGaneshan2008/Kodiak#readme

Thank you for taking the time to read this. I would greatly appreciate any feedback, architectural suggestions, or ideas for improving the project.