AI Learning and Integration
2025-03-174 turns7,131 charsgpt-4o
Summary
The user wants to create an ai_guidelines.md file and a ledger file to track changes, and also wants to incorporate logic from OpenAI's responses API for use with Ollama.
Messages
make this make sense and rewrite in my voice: So one thing you can do is create a ai_guidelines.md file in the root directory along with a ledger file to keep track of changes called ai_output.md so you and the ai can keep track of each other, that is you can read the logic in more detail and see the changes in a single file rather than how it edits each page and you do not really see the full context from a perspective where you can read it well.
That is the key. It is outputting a wealth of information for any person whoi loves to keep learning new things.
The key to me is to use it in a way in which you are learning from the output it generates as much as possible in order to some day be better than it. I know I know, it is easy to be better than it, but I am self taught and honestly it is much more capable than myself.
I have only been using React and TypeScript for around a year. But I like Next.JS for everything or Vite for frontend with a python backend of some sort either Flask or Django. I want to learn Rust because I have this idea of doing better local inference and try to use a local model on my computer to Vibe Code with or to test my own applications I make.
That is how I use it mostly and why I initially got into local models. I did not want to pay the API each time I wanted to test things I was making so I installed Ollama and it changed my life.
It accelerated my learning a lot. The investment I made in a new laptop was worth it in terms of how much quicker I can work seamlessly with the ai rather than being slowed down by the hardware as I was before with a 2017 model, but I really like the unified memory on the newer Macbooks for fitting larger models.
Oh shit I forgot my point.
I also made this program that acts like a whole tech company.
So there is an architecture and design agent, a backend engineering agent, a frontend engineering agent, a testing agent, a user experience and user design agent, a devops agent, a security agent, a continuous improvement continuous deployment agent and of course, an orchestrator agent.
The orchestrator agent is above the subgraph composed of the other agents with forks between each. The agents are nodes and the prompts, context, metadata, and of course ai_guidelines.md, which you write along with the Ai, it is just a good idea to monitor it for changes so you can track how the AI modifies its own ai_guidelines.md file which is necessary for it to adapt and not be so rigid.
But that can get dangerous really quickly.
This is why you read everything you vibe code.
If you don't.
Bad things could happen.
But back to my point.
You create prompts for each agent as a system prompt and then you pass the user prompt along with metadata to the model through something like how the Response API works.
Here’s a cleaned-up version of your text in your style while keeping it clear and structured:
---
One thing you can do is create an `ai_guidelines.md` file in the root directory, along with a ledger file—call it `ai_output.md`—to track changes. This way, both you and the AI can stay in sync. Instead of just seeing the AI edit each page in isolation, you get a full, readable history of what it's doing in one place. That’s key. It gives you a way to follow the logic in detail and understand the bigger picture.
For me, the main takeaway is using AI in a way that helps me *learn* from it as much as possible. The goal is to eventually surpass it—not that it’s *hard* to be better than an AI, but I’m self-taught, and honestly, it’s more capable than me in a lot of ways. I’ve only been using React and TypeScript for about a year, but I prefer Next.js for most things. If I’m doing frontend with a Python backend, I go with Vite and either Flask or Django. I also want to learn Rust because I have this idea of running better local inference—maybe setting up a local model to vibe code with or test the applications I build.
That’s actually why I got into local models in the first place. I didn’t want to keep paying for API calls every time I tested something, so I installed Ollama—and that completely changed the game for me. My learning curve shot up, and upgrading my laptop was 100% worth it. Now, I can work seamlessly without being slowed down by hardware bottlenecks. The unified memory on the newer MacBooks is great for running bigger models.
Oh, right—back to my point.
I also built this system that functions like an entire tech company. It has:
- An architecture and design agent
- A backend engineering agent
- A frontend engineering agent
- A testing agent
- A UX/UI agent
- A DevOps agent
- A security agent
- A CI/CD agent
- And, of course, an orchestrator agent
The orchestrator sits above everything, managing the subgraph of all the other agents, which interact through forks. The agents are nodes, and the prompts, context, metadata, and `ai_guidelines.md` serve as the edges connecting them. That file is critical because both you and the AI update it. You need to monitor changes closely—otherwise, the AI starts modifying its own guidelines, which is great for adaptability but *can* spiral into some weird territory if you’re not careful.
This is why you always *read* everything you vibe code.
If you don’t… bad things happen.
Anyway, back to my point:
You set up system prompts for each agent, then pass the user’s prompt along with metadata to the model—kind of like how the Response API works.
gpt-4o
rewrite as shorter but check if the part about the resposne api works, because it is really responses api from openAI for use with their agents sdk please include how I adapted the logic from that to work with ollama and include that as well incorporated into the whole of the rewrite
One way to keep AI interactions organized is by creating an `ai_guidelines.md` file to track logic and an `ai_output.md` ledger to monitor changes. This helps maintain context rather than seeing isolated edits. The key is learning from AI’s output, refining your own skills to eventually surpass it—though I’ll admit, it’s often more capable than me.
I got into local models because I didn’t want to pay for API calls every time I tested something. Installing Ollama changed everything—it sped up my workflow and made upgrading my laptop worth it, especially with the newer MacBooks' unified memory for handling larger models.
I also built a system that functions like an entire tech company, with agents handling architecture, backend, frontend, testing, UX/UI, DevOps, security, and CI/CD—all managed by an orchestrator agent. Each agent gets a system prompt, and user prompts flow through with metadata. I adapted OpenAI’s Responses API logic, which they use for their Agents SDK, to work with Ollama instead. Rather than relying on their API, I structured it locally, passing prompts, context, and `ai_guidelines.md` updates dynamically between agents.
The trick is keeping an eye on how the AI modifies its own guidelines—letting it adapt is great, but if you don’t monitor it, things can go off the rails fast. That’s why you always *read* everything you vibe code.
gpt-4o