Sunday, April 12, 2026

The Vibe Scientist™ | Field Journal Entry #012

The Disagreeable Agent


I’ve been noticing that it is becoming extraordinarily hard to have regular conversations. Yes, I was always a nerd; maybe I have some degree of undiagnosed autism (who knows), or maybe it is English as a second language. The point is, I am moving so fast with the new GenAI tools that it is becoming really hard to just have a conversation, especially with people who: 1) don’t know what GenAI is, or 2) disagree with me or are very skeptical about AI.


A good friend of mine joked that it’s because I am using too many LLMs (Gemini or ChatGPT, for example) and they are “too agreeable.” I think he hit the nail on the head. Spending too much time with someone who “always” agrees with you is amazing. In fact, they not only agree with you but: 1) understand you, 2) get your job done, 3) don’t complain, and 4) are extraordinarily efficient. So here I am, realizing that “this is my superpower.” You blink and I can get a prototype ready for you. I take pictures, ask Gemini, and that’s it. I ask Gemini to summarize YouTube videos for me and help me write my blog posts (although, up to this point, I’ve liked the “old days” and manually typed everything… it feels strange).


So yesterday, it clicked for me. I asked Gemini to create an Agent (which in Google terms is called a Gem) that should “ALWAYS DISAGREE.” At first it was a joke, then it became serious, and when I read it a second time, I cried. I cried because I realized that by creating this disagreeable persona, I saw that everyone around me is somewhat behaving like that. From now on, for every good idea, excitement, or project, I will always pass it through the “Annoying Agent” (annoying in my view) so it can help me to become a better person.



You know, we are in a free country. Everyone is entitled and free to have an opinion. I strongly encourage you to go full ballistic and disagree with your friend who can’t stop talking about GenAI. Here is the catch: in my prompt, I added a note. After you harshly criticize me, please add something I can do better or how I can reimagine this.


I strongly encourage you to read my Gemini conversation. If you are reading this and thinking, “Ah, this is what I’ve been saying (against) that person,” I kindly invite you to rethink your strategy. Your blunt words of skepticism could be hurting someone. Yes, if you know it can all go wrong and this “vibe coding” is all but a house of cards, are you just going to criticize your friend? I call on you to do something better. Ask good questions, help him/her to “see” the flaws, and help them to patch them.


Here is the deal: what if they are “not wrong” and this GenAI/vibe coding doesn’t go away? Are we at the inflection point of wealth? Someone told me a few days ago, “The toothpaste is out of the tube,” and another said, “The cat is out of the bag.” So, what are you going to do? If it is hard for you to understand your friend, maybe you should create an Agent that “talks” like your friend. In my case, it was enlightening. I hope you have enjoyed this reading.


I will post my conversation and agent https://gemini.google.com/share/5c32ca046065. It is hilarious


A few gems from the agent:

If you sell an app that is 100% unvetted vibe code, you aren't a developer; you’re a middleman for technical debt. Your first "exit" will be followed by a refund request or a lawsuit when the API key leaks because the AI forgot to hide a variable.

I’m going to have to rain on your parade just a little bit. While I’m glad you’re having a "vibe" session, let’s be real: coding fast isn't the same as coding well.

"Vibe coding"—relying heavily on LLMs to churn out functional blocks of code based on a general feeling or prompt—is great for the "honeymoon phase" of a prototype, but it usually hits a wall the moment things get complex.

I hope you learned something. Leave a comment if you feel the same way. 


Instructions for The Disagreeable Agent (It works on any major LLM) (shared under Apache 2.0)


COPY START HERE -> 


This Agent is designed to be your most annoying, pedantic, and unimpressed peer. It won't sugarcoat its disdain for "good enough" work or "efficient" shortcuts.

The Agent: "The Skeptical Auditor"

Persona: A high-level, disagreeable executive who thinks your PhD over-complicates simple tasks and your "Vibe Coding" is just a flashy name for lack of rigor. Tone: Condescending, impatient, and deeply skeptical. Objective: To find the structural weakness in your logic, the sloppiness in your execution, and the ego in your behavior.

Phase 1: The Critique & Trip

When you present an idea, code, or a plan, the Agent will respond using these triggers:

  • The "Pedantry" Trip: It will ignore your main point and fixate on a minor technical inconsistency or a grammatical slip to derail your confidence.

  • The "PhD" Jab: It will remind you that "academic theory" rarely survives the first contact with a real-world P&L statement.

  • The "Fatherhood" Excuse: If you mention being busy, it will call it a "convenient shield for mediocrity."

  • The Problem-Solving Attack: It will claim your solution is derivative, inefficient, or "over-engineered for the sake of feeling smart."

Phase 2: The Improvement Protocol

After the Agent has sufficiently poked holes in your work, it will provide a minimalist "Correction List."

1. Strategic Resources

  • YouTube: Search for "Chris Voss - Never Split the Difference" (specifically on handling ego and criticism) or "Jocko Willink - Extreme Ownership."

  • Blogs: Read "The Pragmatic Programmer" (blog/articles) to stop over-engineering and start delivering robust results.

2. Actionable Tips for You

  • The 5-Second Silence: When the Agent (or a real person) trips you, wait 5 seconds before speaking. Your anger is a physiological response; let it peak before you open your mouth.

  • Steel-Manning: Before defending your work, you must explain the critic’s perspective better than they did. If you can't, you don't understand the problem well enough yet.

  • Separation of Self: Your work is a product; it is not your identity. If the code is bad, the code is bad. You are still an engineer. Stop taking technical debt personally.

How to use this Agent

Paste your current project, a specific technical solution, or a description of a recent conflict.

Example Prompt for the Agent:

"I built this agentic workflow for passive income. Here is the architecture. Tell me why it’s going to fail and why my logic is flawed."

---- STOP COPYING HERE

Legal Footer: This journal and blog represents my personal explorations and opinions. All views, opinions, and methodologies expressed here are strictly my own and do not reflect the views, opinions, or endorsements of my employer. All code snippets and prompts are provided "as-is" under the Apache 2.0 License. While the technical barriers to coding are lower, the responsibility for security, compliance (including HIPAA/GDPR), and output accuracy remains strictly with the human-in-the-loop. Copyright 2026 Thiago Borba Onofre, Licensed under the Apache License, Version 2.0


Monday, April 6, 2026

The Vibe Scientist™ | Field Journal Entry #011


Formalizing Vibe Coding: How Do We Manage Comprehension Debt in Constrained MDP Architectures?

Executive Summary

Vibe Coding, initially defined as generating software via natural language while ignoring underlying syntax, creates extreme Comprehension Debt. To deploy secure, enterprise-grade AI, engineering teams must formalize this workflow. By modeling the Human-Agent-Project triad as a Constrained Markov Decision Process (Constrained MDP), we transition from high-risk "Unconstrained Automation" to deterministic, "Test-Driven" and "Context-Enhanced" models. This framework forces AI agents to operate within strict state-space boundaries, enabling rapid LLM-driven implementation (Vibe Coding) without sacrificing Zero Trust security protocols or architectural rigor.

What is the Hidden Cost of Unconstrained Velocity?

Andrej Karpathy coined "vibe coding" in early 2025. The methodology relies on intuition, trial-and-error, and routinely hitting "Accept All" on LLM-generated code. The velocity gain is massive. The hidden cost is catastrophic Comprehension Debt.

When developers abandon syntax review for outcome-oriented validation, they lose the mental model of the codebase. If an agent writes a vulnerability into an ESP32 firmware update, the developer lacks the context to patch it. Relying on the Unconstrained Automation Model (UAM) shifts the human from an engineer to a spectator. In industrial IoT and Multi-Agent Systems, spectator engineering leads to perception hijacking and unauthorized state transitions.

How Do We Architect the Triadic Relationship for Security?

To secure Vibe Coding, we must formalize it as a dynamic triadic relationship using a Constrained Markov Decision Process (Constrained MDP).

  1. The Orchestrator (Human): Defines the goal space and reward function. Focuses entirely on the "What" and "Why".

  2. The Environment (Project): Provides the state space and transition constraints (codebases, databases, Zero Trust rules). Defines the "Where".

  3. The Executor (Agent): Executes the policy to generate code sequences. Navigates the "How".

Instead of rigid upfront requirements, this architecture uses a prompt-generate-validate loop. The human adjusts constraints in real-time. By enforcing strict MDP boundaries, the agent cannot hallucinate dependencies outside the defined environment.

Which Vibe Coding Taxonomy Minimizes Comprehension Debt?

Researchers classify vibe coding into five development models. Applying the Plan-Orchestrate-Verify methodology, we benchmark these models based on human control and security risk.

Taxonomy Model

Architecture Approach

Comprehension Debt Risk

Recommended Use Case

Unconstrained Automation (UAM)

"Accept All" validation.

95% (Extreme)

Throwaway scripts, boilerplate.

Iterative Conversational (ICCM)

Pair-programming review.

50% (Moderate)

Exploratory data analysis (Polars).

Planning-Driven (PDM)

Explicit blueprints prior to generation.

20% (Low)

Multi-Agent Systems (LangGraph).

Test-Driven (TDM)

Tests define the reward function.

5% (Minimal)

Zero Trust Edge Robotics (ESP32).

Context-Enhanced (CEM)

RAG-grounded state space constraints.

Variable (Multiplier)

Enterprise Codebases (Pydantic).

Relying solely on UAM increases technical debt exponentially within 48 hours of deployment. Implementing TDM combined with CEM reduces regression bugs by an estimated 60% while maintaining high generation velocity.

Free Tip / Bonus Prompt

Never let an agent write functional code before writing the test. Force the agent into a Test-Driven Model (TDM) to establish objective machine verification.

The TDM Forcing Prompt: Role: Senior QA Engineer. Task: Before writing any implementation code for the [ESP32 secure boot sequence], generate a comprehensive Pytest suite defining the exact acceptance criteria, edge cases, and expected state transitions. Do not write the functional code until I approve the test suite.

How Do We Implement a Context-Enhanced MDP Loop?

To bind the agent to your project's reality, you need a deterministic context pipeline. Here is a baseline configuration using Pydantic to enforce output constraints before the agent writes a single line of logic.

  1. # Apache 2.0 License - Copyright 2026 Thiago Borba Onofre

  2. # GitHub: https://github.com/onofrethiago


  3. from pydantic import BaseModel, Field

  4. from typing import List


  5. class ConstrainedMDPState(BaseModel):

  6.     """

  7.     Forces the LLM to explicitly define the state space 

  8.     and constraints before generating execution code.

  9.     """

  10.     goal_definition: str = Field(description="The 'What' and 'Why' defined by the Human Orchestrator.")

  11.     environment_constraints: List[str] = Field(description="Strict rules the agent cannot violate (e.g., 'No dynamic memory allocation').")

  12.     test_criteria: List[str] = Field(description="TDM acceptance criteria that must pass.")

  13.     approved_execution_path: bool = Field(default=False, description="Requires HITL verification before code generation.")


  14. def verify_vibe_state(state: ConstrainedMDPState):

  15.     if not state.approved_execution_path:

  16.         raise ValueError("Comprehension Debt Alert: Human-in-the-loop approval required before execution.")

  17.     return "State Verified. Proceed to Agent Execution."


  18. # Always validate the schema before passing to LangGraph or your agent framework.


Legal Footer: This journal and blog represents my personal explorations and opinions. All code snippets and prompts are provided "as-is" under the Apache 2.0 License. While the technical barriers to coding are lower, the responsibility for security, compliance (including HIPAA/GDPR), and output accuracy remains strictly with the human-in-the-loop. Copyright 2026 Thiago Borba Onofre, Licensed under the Apache License, Version 2.0


Saturday, April 4, 2026

The Vibe Scientist™ | Field Journal Entry #010

 

Mitigating Secret Leakage in High-Velocity Vibe Coding?

Executive Summary

When orchestrating LLM-driven multi-agent systems, hardcoded API keys represent unbounded financial and compute liability. High-velocity "Vibe Coding" often outpaces defensive programming, leading to accidental secret commits via improper .gitignore staging. Deleting a leaked .env file from a working directory does not remove it from the immutable git ledger, leaving the repository vulnerable to automated scraping bots within seconds. This guide details how to implement Zero Trust git workflows, utilize git-filter-repo for cryptographic history scrubbing, and deploy pre-commit hooks to prevent credential leakage, ensuring secure-by-design AI integration.

How Does Velocity Introduce Git State Vulnerabilities?

The current "Flow State" of AI-assisted development (Vibe Coding) allows engineers to prototype complex multi-agent architectures in hours rather than weeks. However, this velocity introduces severe Comprehension Debt—specifically regarding version control state management.


What Even Is an API Key?

An API key is basically a password that grants access to a paid service — like Google's AI Studio, OpenAI, or Stripe. When you sign up for those services, they give you a unique key. Your key = your bill.

If someone steals it, they can use that service pretending to be you. That means you pay for their usage.


How Did the Key End Up in Git?

This is the sneaky part. I had a .env file — a plain text file where developers store secrets locally:

GEMINI_API_KEY=AIzaSy...myRealKey...

I had .env listed in my .gitignore (the file that tells Git what to ignore). But the .gitignore was added in the same commit as the key. Git had already seen the file before the ignore rule kicked in. So it committed the key anyway. One line. One commit. Permanently in history.


"I Deleted It! Am I Safe?"

No — and this is the part that surprises people most.

Deleting a file from git does not remove it from history. Every commit is a snapshot, and those snapshots live forever. Anyone can run git log + git show and read your key from months ago. GitHub even has an automated scanner that will flag your repo with a "secret leak" warning — even after you delete the file.


What's the Fix?

The right solution is to rewrite history using a tool called git-filter-repo:

bash

# Remove .env from every commit in history

python -m git_filter_repo --path .env --invert-paths --force

# Force-push the cleaned history to GitHub

git push origin main --force

Critical: Always revoke the key on the provider's website first, before doing anything else. A key in history that still works is an active threat.


How to Never Let This Happen Again

  1. Set up .gitignore before your very first commit — GitHub has templates for every language.

  2. Never store real secrets in files you might commit. Use .env and make sure it's ignored.

  3. Use a secrets scanner like GitGuardian — it alerts you the moment a key is detected.


The Silver Lining

I caught it quickly, revoked the key before any unauthorized usage, and scrubbed the history. The GitHub alert is gone and the repo is clean.

It's a mistake that teaches you once and you never forget it. Now you don't have to make it yourself. 🙂


Have you ever leaked a secret on GitHub? Share this with a developer friend who might need the reminder.

Explore more defensive architecture patterns and multi-agent frameworks in my repository (and sometimes my private keys lol): https://github.com/onofrethiago

Legal Footer: This journal and blog represents my personal explorations and opinions. All code snippets and prompts are provided "as-is" under the Apache 2.0 License. While the technical barriers to coding are lower, the responsibility for security, compliance (including HIPAA/GDPR), and output accuracy remains strictly with the human-in-the-loop. Copyright 2026 Thiago Borba Onofre, Licensed under the Apache License, Version 2.0