Tines The single, secure environment for agents, apps, and automations.
AutoCoder.dev
Fully Autonomous Coding
7 followers
Fully Autonomous Coding
7 followers
A multi-agent team of specialized AI engineers that collaborate in parallel to research, plan, code, verify, and review your tasks — fully private and local. Bring your own API key and ship features while you sleep.
How does the "fully private and local" setup actually work if I'm using my own API key for the agents, does that mean the orchestration runs on my machine or somewhere else?
@elanurkeysan Yes orchestration runs on your machine. The "fully private and local" setup for AutoCoder.dev, when using your own API key, implies that the orchestration and execution of the AI agents run on your local machine. This ensures that your data and API keys remain within your environment, enhancing privacy and security. The platform is designed to leverage your local resources for processing and agent coordination.
Tried it on a backend refactor and the parallel agents caught a couple of edge cases I would have missed solo. The local-only setup with my own key is exactly what I wanted.
@duyguerayaa60h That's fantastic to hear! It's great that the parallel agents were able to identify those edge cases during your backend refactor. The local-only setup with your own key is indeed a crucial feature for many.
Happy coding!
How does the parallel agent setup actually coordinate without stepping on each other's code changes, especially when they're all touching the same repo at the same time?
@akat_ekin51208 This is a great question about managing concurrent agent operations within a shared repository. The coordination primarily relies on a combination of robust version control strategies and well-defined agent workflows.
Here's how it typically works:
1. Branching Strategy: Each agent, or a group of related agents, usually operates on its own dedicated feature branch. This isolates their work from the main codebase and from other agents' ongoing tasks.
2. Atomic Commits and Pull Requests: Agents are designed to make small, atomic commits that represent a single, logical change. Once a set of changes is complete and tested, it's submitted as a Pull Request (PR).
3. Code Reviews and CI/CD: All PRs go through automated checks (CI/CD pipelines) for linting, testing, and security vulnerabilities. Crucially, they also undergo human code review before being merged into the main branch. This is a critical step for identifying and resolving potential conflicts or overlaps.
4. Conflict Resolution Mechanisms: If conflicts do arise during the merging process (e.g., two agents modified the same lines of code), Git's built-in conflict resolution tools are used. The review process often involves developers manually resolving these conflicts, ensuring that the integrated code is coherent.
5. Agent Communication and State Management: For more complex interactions, agents might communicate their intentions or current status through shared databases, message queues, or dedicated state management systems. This allows agents to be aware of what others are working on, reducing the likelihood of direct interference.
6. Idempotency: Designing agent tasks to be idempotent (meaning running them multiple times has the same effect as running them once) can also help mitigate issues if tasks are accidentally triggered concurrently or re-run.
In essence, it's a layered approach: isolation through branching, structured work through task management, validation via CI/CD and code reviews, and explicit conflict resolution when needed. This ensures that even with multiple agents working, the integrity of the codebase is maintained.
Love that this stays local and works in parallel, the multi-agent approach feels way more useful than a single assistant. One thing I'd love is a way to give the team a persistent project memory or knowledge base so it stops rediscovering the same codebase conventions every session. That would make handoffs between the planning and verification agents feel much smoother and save a ton of tokens on repeat tasks.
@kemalcakandg84 That's a great point! A persistent project memory or knowledge base for the multi-agent system would indeed be highly beneficial. It could significantly improve efficiency by:
* Reducing Redundancy: Agents wouldn't need to re-analyze codebase conventions or project-specific logic in every session.
* Smoother Handoffs: Planning and verification agents could access a shared, consistent understanding of the project, leading to more coherent interactions.
* Token Efficiency: Storing and retrieving common information would likely be more token-efficient than re-explaining it repeatedly.
This feature would make the multi-agent approach even more powerful for complex projects. Thanks for the valuable feedback!
being able to schedule recurring jobs would be huge, like every morning at 8am have it review overnight error logs or refactor a file on a set cadence. right now it feels like you have to manually kick off every run, which kind of breaks the "ship features while you sleep" promise for me
@ezgiimq3 That's a great point! You're absolutely right, the ability to schedule recurring jobs would significantly enhance the "ship features while you sleep" promise. Automating tasks like daily error log reviews or regular file refactoring would be a game-changer.
I'll definitely take this feedback into consideration as we continue to develop and improve the system. Thanks for highlighting this important feature request!