Vibe Architects: Agentic Vibe Coders - NN/G

Introducing NN/G Membership | Access all self-paced courses for $249 per year | Join by Jan. 26, 2027 |
Find the training option that fits your learning style.
June 19, 2026 2026-06-19
Generative AI lets people's technical capability outpace their technical knowledge in ways that no previous technology has. We've seen this in vibe coding for some time.
Now, however, vibe coding is expanding into something broader, messier, and more impactful. This shift is tied to the rise of agentic AI and Claude Cowork, a flexible agentic system targeted at general information workers rather than engineers.
In our recent study, we learned how people manage to architect systems and transform workflows for themselves and their teams — without knowing much about exactly how they’re doing it. We call these people “vibe architects.”
The primary goal of our study was to understand how people who are not professional developers use agentic AI. The study was inspired by Claude Cowork's explicit focus on noncoders. We wanted to know how well Cowork serves that population.
For the study, we'd hoped to recruit people who were not developers, didn't work in our field (digital design, product, or UX), and used open-ended agentic tools like Claude Cowork or Claude Code. We managed to find 7 nontechnical people but struggled to find people outside of our industry (which may hint at how rare these people are).
Our participants included:
All these individuals were building complex agentic systems using Claude (alongside other AI tools) for a wide array of personal and professional purposes — without having a technical background.
Vibe architects build complex, proactive agentic systems using AI tools, sometimes with little technical knowledge or understanding of how these systems work.
Some of the systems that our participants created had traditional interfaces (e.g., vibe-coded dashboards or websites), but others lived purely in Markdown text files or in the LLM’s chat. One participant showed us a dashboard he’d built, then mentioned he didn’t really look at it — he worked primarily in his code environment and the chat. The traditional UI was an afterthought.
These people were applying vibe coding to design how information flows across systems, how AI agents coordinate, and how work gets done — sometimes for entire teams.
As vibe architects build increasingly complex systems, they aren't learning about the technical functionality under the hood. Instead, they are developing something more amorphous — a semi-instinctual set of behaviors, preferences, and tendencies, shaped by hours spent experimenting, watching YouTube videos, and reading blogs.
These instincts aren't always accurate or useful. They reflect hazy mental models that sometimes produce real results and sometimes lead nowhere.
One participant, for example, developed a habit of resetting her Claude Cowork chats by importing the entire conversation into the prompt of a fresh conversation. She assumed that this practice saved tokens. While longer conversations do use more tokens, so does including the context in a long prompt.
Thus, while vibe architects can improve their and their teams’ workflows, the resulting systems aren’t always the most efficient or reliable. And, predictably, they report maintenance headaches: The systems decay. Connections expire, context drifts, and single sources of truth fall out of sync, so keeping everything running becomes a recurring tax on the architect’s time.
The participant who had moved his team’s primary communication into Claude said that his system would hold up “for a few weeks, and then the decay hits and we have to […] set up the process [again].”
Another participant described the same problem as drift: “As I develop my own stuff, [it] can start to drift, and managing that is […] harder.”
The latest-frontier models are extremely good at interpreting ambiguous prompts. So much so that many of our participants reported that they don’t prompt engineer at all — they deliver stream-of-consciousness instructions to their AI systems, often using dictation apps like Wispr Flow.
There is still some “engineering” happening, however. It’s less about choosing words in the prompt, and more about selecting tools, techniques, and approaches to get what they want. That process often involves asking Claude itself for help.
For example, one participant reported that he would always ask Claude, “What would make this world-class?” He said Claude often would respond with improvement suggestions, and he’d almost always accept them.
This was a common theme across our sample — our participants often delegated the decision making, as well as the execution, to Claude. They exercised minimal oversight on what Claude was up to.
During one session, a participant screenshared her Visual Studio Code window, where she primarily interacted with Claude Code. During the session, Claude was working on building something for her team and kept asking for permission to take various action. While speaking with us, she repeatedly clicked Accept without reading the requests. When we asked whether this was how she usually handled permission approvals, and she said yes.
“Yes, because I don't want to give it dangerously accept permissions [level of access]. Most of the time I will just click ‘yes’ for things that [it] asks me, even if I don't understand what it means, because it only has […] the context of this folder. So, I don't really need to worry about it accessing other things.”
(Dangerously accept permissions was the label that Claude’s designers chose to prevent people from allowing the LLM to make unrestricted choices. Apparently, it was quite an effective label.)
Another participant told us he’s developed carpal tunnel from repeatedly accepting permission requests.
(As an aside, Anthropic released Auto mode in Claude Code shortly after we’d wrapped up our last session. This new option autoapproves requests that are not destructive or risky, selectivel