as you become more ambitious with coding agents, delegation becomes increasingly important the new "suggested task" feature in @openclaw gives your agent a tool to do this for you if the agent identifies a sufficiently well-scoped piece of work, it will recommend kicking off a new session to work on it

China published the most uncomfortable paper on vibe coding. ETH Zurich tested 100 developers in a controlled, commercial-grade vibe coding environment to see who actually succeeds. The findings are brutal. The researchers tracked computer science achievement, written communication skills, and general cognitive reasoning. They wanted to see what actually predicts vibe coding proficiency when you never touch a line of source code yourself. Two major predictors emerged. Written communication proficiency mattered. The ability to structure thoughts and articulate intent unambiguously in text directly impacts what the AI builds. But that wasn't even the main takeaway. Computer science achievement was a massive, dominant predictor of success. Even when researchers controlled for general intelligence and reasoning skills, CS background still heavily dictated who built working software and who completely crashed. In fact, CS knowledge contributed roughly twice the unique predictive variance of writing skills alone. Why? Because vibe coding isn't about writing code. It’s about debugging logic. When an AI agent builds a complex application and quietly breaks an edge case under the hood, a non-technical user looks at the glowing UI and assumes it works. They don't know what questions to ask. They don't know what logic to challenge. They lack the mental models to recognize architectural catastrophe. You can prompt your way past syntax. You cannot prompt your way past a fundamental lack of engineering intuition. The hype told us that learning to code is dead because language is all you need. The data just proved the opposite. To truly master the vibe, you still need to understand how the machine thinks.

I don't think "AI employees" are a particularly useful abstraction for agents. A lot of agent products right now basically ask you to recreate a company inside the software. You make a "Steve", tell Steve that he is in marketing, give him a personality and a job description and some tools, and then Steve talks to your sales agent and your research agent and eventually you have a little org chart of bots coordinating with each other. And tbf it makes intuitive sense. Companies are made of people, agents can increasingly do things people do, so the obvious thing is to model agents as people. Right? But tbh I think this might be exactly the wrong abstraction over longer time horizons. The weird thing about an employee is that most of what makes them useful isn't actually contained in the employee definition. You don't onboard someone by giving them a 4,000 token system prompt describing their personality and responsibilities. They become useful because they exist inside an environment. They are in the right Slack channels, have access to certain files, know who is working on what, accumulate history with people, can use certain tools, understand what happened last week etc etc. So why explicitly define the agent at all? If the computer is basically the company, and the filesystem contains the conversations, artifacts, people, permissions and tools of that company, then the environment itself can define the agent implicitly. An AI acting inside /marketing should already have the context of marketing, know the people involved, have access to the relevant tools and understand the work that happened there. The same underlying intelligence acting inside /finance should behave differently, not because somebody created a second character called "Sarah from finance", but because it is operating in a different context with different permissions, history and tools. There are obviously cases where you want persistent agents with explicit instructions (and probably names too). But I think some people take the human metaphor much further than necessary and end up recreating all the coordination overhead of a human organization in software, including agents talking to agents to figure out who should do what. Maybe in this case the more interesting primitive isn't the agent at all, but maybe it's just the environment in which intelligence acts (org-level harness?)...