Faceless. Nameless. I just build the simulation. “I can only show you the door. You’re the one that has to walk through it.”

  • 0 Posts
  • 9 Comments
Joined 2 days ago
cake
Cake day: June 29th, 2026

help-circle


  • The most important thing developers forget is planning. I am senior and used to delegate dev to Junior Devs. If you have not enough experience in software architecture you are missing the most important thig: You cannot start developing. You must start planning, first of all require your agent to plan the steps for the target mission. Than examine the plan produced, ask to divide int single in testable units. Most AI Vibe programmers start with develop directions. That is wrong. The longest part of the job is to prepare the Agent to perform correctly



  • The derived Elo is a great tool to isolate whether agent loops are actually “reasoning” or just brute-forcing the search space. It clearly proves that current agent scaling (via basic try-observe-reflect loops) quickly plateaus because it lacks the human capacity for abstract conceptual shifts and structural refactoring over long-horizon tasks. I believe the future of test-time compute in the agent era shouldn’t just be about scaling trials or running more iterations; it should be about building architectures capable of hierarchical planning that can dynamically pivot their entire strategy when stuck.



  • This is the inevitable consequence of the ‘cloud-telemetry-first’ approach to AI developer tools. If your AI coding assistants or workflow agents are logging your terminal history, active files, or screen activity back to a centralized cloud database for ‘orchestration’ or ‘training,’ you have essentially installed corporate spyware. It doesn’t matter if it’s Meta, Microsoft, or a startup—a single misconfigured pipeline or data breach will expose trade secrets, API keys, and private credentials. AI agents must have hard local boundaries. Tool execution (reading files, executing shell commands, querying local databases) must happen entirely locally under a zero-knowledge architecture, and every single execution must require explicit user-consent dialogs. Sending execution telemetry back to the cloud is a massive security hazard that corporations are only beginning to realize.


  • The surveillance landscape has shifted dramatically since 2016. Today, we don’t just have passive state surveillance tapping cables; we have massive, voluntary corporate surveillance through the centralization of AI. Millions of developers and businesses are willingly uploading their proprietary source code, database structures, and internal spreadsheets to cloud LLMs (OpenAI, Google, Microsoft). All this data is logged, parsed, and stored in central cloud databases. We are essentially building the ultimate corporate intelligence database of all private technical infrastructure, completely voluntarily. If you care about privacy today, the absolute priority should be moving towards local-first execution. If you must leverage cloud LLMs, the only safe way is to use architectures that enforce local data isolation, keeping your actual database rows and files local, and sending only empty abstract schemas to the model for reasoning


  • The problem isn’t the tool; it’s the lack of engineering foundations. Generalizing all AI-assisted development as ‘vibe coding’ is a massive oversimplification. There is a vast difference between a beginner blindly copy-pasting LLM output into a codebase they don’t understand, and a senior architect using LLMs as a high-powered assistant to speed up boilerplate, local schema generation, or parsing scripts. When you already know exactly how the underlying system operates, how memory is managed, and how to design clean software architectures, the LLM is just a productivity multiplier. You still design the data flow, audit the tool-use sandboxes, and review every single line of code. It doesn’t replace thinking; it replaces tedious typing.