AI tooling has become one of the biggest parts of my technical workflow, but the thing is, the useful part is not really the chat window. The interesting part starts when the model can interact with the rest of the environment.
A model that can inspect a repository, read documentation, compare architecture, call tools, modify files, run tests & review the result can remove a lot of repetitive work. It can also make a mistake much faster than I can.
So this project is really about both sides of that equation: how much useful leverage can I get from AI & how do I keep the workflow understandable enough that I still know what happened?
Use AI as technical leverage without turning the model into an invisible authority over the system.
1. The problem I am trying to solve
I work across code, game systems, Linux, web development, documentation, research & infrastructure. A lot of the expensive time is not typing. It is moving context between those things.
I may need to inspect an error, find the relevant code, understand the architecture around it, compare that with an earlier decision, make a change, validate the change & document what we learned.
AI is good at helping connect those steps when it has the right context. That is much more useful to me than generating random snippets in isolation.
2. Why I experiment with local models
Local LLMs, or Large Language Models running on my own machine, give me a controlled environment for understanding the model layer itself. I can change models, prompts, context, tool schemas & runtime settings without every experiment depending on a remote service.
There are tradeoffs. A local model may be less capable than a larger hosted model. Hardware matters. Context limits matter. Tool support can be inconsistent.
But those limitations are educational because they make the infrastructure visible. If a tool schema breaks, I have to understand whether the problem is the model, the template, the runtime or my own integration.
3. Agents are useful because they can continue the workflow
The word agent gets used very loosely. For my purposes, the useful distinction is simple: instead of only returning text, the AI can take actions through tools.
That might mean searching a repository, reading a file, checking GitHub, running a test or writing a controlled change.
That is powerful because it reduces the amount of manual context transfer. It is also where the security model changes. A model with a shell is not the same thing as a model in a chat box.
4. Tool access is authority
I think this is the most important design principle in the project. Every tool I expose to an AI is authority I am giving it.
Read access to a repository is authority to inspect that repository. Write access is authority to change it. Shell access can be authority over a huge part of the machine depending on the user running the process. A GitHub connection may be able to alter code that later deploys somewhere else.
So I prefer scoped tools where possible. If the task only requires GitHub, I do not automatically need to give the model unrestricted access to my entire filesystem. If it only needs to read something, write access should not be assumed.
Convenience is not a reason to give a tool more authority than the job requires.
5. Git makes AI experimentation much safer
Version control is probably one of the best companions to AI-assisted development. If a model changes ten files, I want to know which ten files changed & exactly what changed inside them.
Git gives me history, diffs & rollback. That changes AI from "something edited my project" into a reviewable technical event.
I also like using branches for larger work because it creates another boundary. The model can work on the proposed change without the change automatically becoming the version I trust.
6. The model is not the validation layer
This sounds obvious, but it is easy to forget when a model gives a very confident explanation.
If AI writes code, the code should still compile or run. If it claims a test passed, I want the test output. If it changes a website, I want to look at the website. If it modifies an architecture, I want to understand what assumptions changed.
The model can help perform validation, but "the AI said it worked" is not validation.
7. Failures are part of the workflow
I keep running into cases where the failure teaches more than the successful generation. Models can misunderstand schemas, invent functions, use outdated APIs or make a locally reasonable change that conflicts with a larger project decision.
When that happens I do not want to just patch the immediate error & move on. If the failure reveals a repeatable pattern, I want it in lessons learned, tests, project instructions or documentation so the next attempt starts with better information.
That is one of the areas where AI can actually improve over time without the model itself changing: improve the environment around it.
8. Keep the human responsible for the architecture
I am comfortable letting AI do more implementation when the boundaries are clear. I am much less interested in letting it silently decide what the project should become.
The human should still own the intent. What are we building? Which tradeoff matters? Which behavior is correct? What should be preserved? What is safe to remove?
AI can give me alternatives I did not consider & it can absolutely catch things I missed. That is useful. But the final system still needs somebody who understands why those pieces are there.
9. Where I want to take this
I want more repeatable local-agent workflows, better tool isolation, clearer permission boundaries, stronger automated validation & better ways of carrying lessons between projects.
I also want to document the failures, not only the impressive demos. The useful question is not whether an AI can produce a cool result once. It is whether the workflow remains reliable enough to become part of real technical work.
AI should increase capability, not hide the system
The best AI workflow I have found so far is not one where I disappear from the process. It is one where the model removes mechanical work while making it easier for me to spend time on architecture, investigation & decisions.
If using AI means I no longer understand my own environment, I have probably traded too much away for speed.
If it lets me build faster while preserving Git history, tests, documentation, boundaries & human review, then it becomes exactly what I want it to be: leverage.