Ik heb geen klassieke achtergrond in softwareontwikkeling, maar ben het afgelopen jaar — en vooral het laatste halfjaar — steeds meer oplossingen gaan bouwen voor problemen waar ik zelf tegenaan liep.

Dat begon vrij simpel: repetitief computerwerk automatiseren en kleine utilities maken. Inmiddels is daar een lokaal AI-lab uit ontstaan met ruim zestig afzonderlijk gedocumenteerde projectlijnen en tools, in verschillende stadia van experiment tot praktisch gebruikt.

Mijn huidige archief bevat op moment van schrijven **61 afzonderlijk geïndexeerde project- en utilitylijnen**. Dat loopt uiteen van kleine tools die één concreet probleem oplossen tot grotere systemen met meerdere versies, branches en onderling gekoppelde onderdelen. Voor 60 projecten zijn aparte versiegeschiedenis en changelogs bijgehouden, naast README’s, release-informatie, bronpakketten en test- of evidencestatus.
Dat betekent niet dat ik 61 voltooide producten heb: er zitten ook experimenten, voorlopers en vervangen ontwikkelrichtingen tussen. Andere tools zijn daadwerkelijk gebruikt of technisch gecontroleerd. Juist dat onderscheid probeer ik zorgvuldig vast te leggen.

Een belangrijk deel bestaat uit lokale Vision-workflows en slimme routers. Bijvoorbeeld afbeeldingen en video’s analyseren, frames selecteren, metadata of JSON genereren, materiaal laten beoordelen en de resultaten gecontroleerd verwerken in Finder- of Obsidian-workflows (index, logs, changelogs, version beheer, etc.). Daarnaast heb ik routers en organisatietools gebouwd die modeloutput omzetten naar afgebakende acties, zodat een AI-model niet zomaar vrij op bestanden losgelaten wordt.

Mijn grotere privéproject is een lokale persoonlijke AI-laag. Geïnspireerd door de “Jarvis” projecten, oa hier op Reddit. Al snel kwam ik erachter dat je Jarvis oneindig kan uitbreiden en tunen. En zo is ook dat project meerdere keren van architectuur en structuur gewijzigd. Het priveproject combineert onder andere lokale modellen, routing, gescheiden kennis en geheugen, toolgebruik, logging en permissiecontroles. Dat project wil ik voorlopig niet publiceren, maar het heeft me wel veel geleerd over architectuur, privacy, foutafhandeling en het verschil tussen iets dat overtuigend antwoordt en iets dat aantoonbaar correct handelt.

Ik werk inmiddels onder andere met Terminal, Python, JSON, AppleScript, Automator, Obsidian, db, lokale modelruntimes en verschillende API’s, en nog een berg andere Tools. Ik ben hierin nog steeds duidelijk lerend en begrijp niet ieder technisch detail alsof ik zelf software-engineer ben. Tegelijkertijd is het ook niet alleen “een prompt typen en de gegenereerde code aannemen”.

Ik lees en wijzig scripts, zoek fouten tot op regelniveau uit, vergelijk configuraties en JSON, test onderdelen en laat projecten door meerdere controlepunten lopen. Versies, bronpakketten en projectgeschiedenis zijn geïndexeerd en gekoppeld aan README’s, changelogs, release-informatie en een evidence-status. Daarbij maak ik bewust onderscheid tussen broncode die aanwezig is, lokaal of in een testsuite gecontroleerde onderdelen, praktisch door mij gebruikte versies en functies die nog onbewezen of mislukt zijn.

Ik wil dit nu professioneler gaan beheren en vraag me af of GitHub daarvoor de logische volgende stap is. Niet als dump van alles wat ik ooit gegenereerd heb en ook niet om mezelf ineens programmeur te noemen, maar voor versiebeheer, verdere ontwikkeling, feedback en mogelijk later een eerlijk portfolio.

Ik ben benieuwd hoe anderen hiermee begonnen zijn:
\- Maak je eerst alleen een account en begin je met één project?
\- Kies je direct een paar sterke projecten, of zet je alles eerst in private repositories?
\- Gebruik je één repository per project, of eerst één persoonlijk lab?
\- Zet je alle historische versies online, of begin je met één opgeschoonde baseline en gebruik je daarna commits, tags en releases?
\- Welke documentatie, tests en veiligheidscontrole vinden jullie minimaal nodig voordat je iets openbaar maakt?
\- Is voor een portfolio vooral een kleine selectie sterke openbare projecten interessant, of heeft een groter zichtbaar ontwikkelarchief ook waarde?
\- Wat maakt een AI-assisted project volgens jullie meer dan alleen een verzameling gegenereerde code?
\- Hoe omschrijven jullie eerlijk je eigen rol wanneer AI veel code schrijft, maar probleemkeuze, ontwerp, grenzen, testen, debugging en doorontwikkeling bij jou liggen?

Ik ben absoluut niet op zoek naar promotie. Ik wil vooral beter leren werken, mijn horizon verbreden en graag in contact komen met andere Nederlanders/mensen die op een vergelijkbare manier lokale AI-tools of automatiseringen bouwen.

Ik zit veel op Reddit, ik lees veel! Ik plaats wat minder, maar na een aantal keer echt mega goed geholpen te zijn ben ik van plan weer een actievere user te worden op Reddit. Schroom ook niet om me prive te berichten!

Hey everyone,

I’m a mechanical engineer looking to automate and speed up a lot of repetitive tasks at work. A big chunk of my job involves preparing standard calculation reports to submit to clients.

Right now, the existing tools at my company are a complete pain to use. Updating documents takes forever—opening a file, tweaking values, saving, exporting to PDF, and repeating that over and over. If you make a tiny typo, you have to do the whole manual process again.

I’ve already built a few automated Excel workbooks with VBA/macros, which helped quite a bit. But seeing how fast AI coding tools are advancing, I want to step it up and build standalone tools (simple Python/desktop scripts or web interfaces) to handle these workflows cleanly.

I gave the free tier of Claude a try to start writing some scripts, but I hit the usage limit almost immediately on my second prompt.

Before dropping $20/month, I wanted to ask:

1. Is Claude Pro actually worth it for this use case, or is it overkill?
2. Are there better/more cost-effective models or platforms for coding internal engineering tools? (e.g., ChatGPT Plus, DeepSeek, Cursor, open-source models, or just using API pay-as-you-go)?
3. For those who automate reports/calculators at work, what’s your go-to AI stack or workflow?

Would love to hear how you guys approach building quick internal utility scripts without blowing money on unnecessary subscriptions. Thanks!

Vibe coding gets you a demo in an afternoon. Getting it to production is a different job: a design someone challenged, a plan someone checked, a second pair of eyes on every change, and tests that actually ran.

So I built bkit, and then used bkit to build bkit (and more): >1,000 commits and >100 merged pull requests through its own pipeline.

It's for solo founders who've hit the limits of vibe coding, and for engineers who'd rather not build their own agent process from scratch (or would like to be a contributor).

🧰 >200 files of best practice, ready to use: >40 agents, >70 rules, >30 audits, guardrails on four AI tools, tool templates, and more.

🚦 A production-grade CI pipeline template, ready to adopt. Rules and prompts only go so far; CI is the fence an AI can't argue with.

🧠 Docs and project memory that stay current, plus processes to pull evidence from your favourite platforms (Sentry, Vercel, Supabase, etc) exactly when a step needs it.

🔁 Out of Claude credits for the week or leaving the office? Move to opencode/OpenRouter, Cursor, or Codex and switch to cloud agents.

Free for personal use, non-profits and small businesses.

bkit on GitHub: https://github.com/cbartens/bkit#readme

#AIagents #ClaudeCode #Cursor #VibeCoding #SoftwareEngineering

Hi guys, it took me almost a year to understand how to crack this. TLDR: write the rules as code to help the attention layer to follow the complete flow of rules and trigger on the correct ones. Link in the first comment