http://x.com/i/article/2014236287847575552

deepcoding

there's no formal definition for vibecoding that i know of, but i largely classify it as a style of using AI where you have some rough idea of an end-state, and little to no mention on the implementation and all the middle bits. those details are only provided later. to vibecode, the only prerequisite you need is a sketch of what the end-state looks like. many people (even experienced, senior engineers) who express frustration with the poor quality of AI code prompt this way.

writing code this way is perfect for cooking up quick prototypes. it's great for serendipitous exploration. but if you've ever vibecoded your way to production, you've probably experienced an Agony Pyramid™ like this. you start out cheerfully with a quick prompt, but by the end of it, you're annoyed with the agent and beginning to believe that AI coding is sheer hype.

with enough course correction and good taste, you can still get to a good result. but there's a better way to ship code, especially when you work on massive codebases where there can be significant amounts of noise.

inverting the pyramid

if you've been writing code with agents for a while now, this is probably intuitive to you. i don't know if there's a common name for this technique, but i've taken to calling it "deepcoding".

deepcoding is about inverting the usual flow. you start with context and guidance first, before the agent starts coding. i think of it as frontloading the context it needs to execute the task the way it should, rather than providing it after the code is written. it's almost like importing the knowledge at the top of the file and then telling the agent to use it.

this works so much better because LLMs generate tokens based on what's already in the context window. by frontloading the right context, we keep the conversation high signal, and we stop the agent from picking up on noise. this is precisely why using Planning mode before coding is so effective: it helps frontload all this context and allows you to review the plan before it starts coding.

providing relevant context up front also helps reduce the amount of greps the agent needs to do. if the agent has to search a bunch of files, it pulls that content into your context window and potentially brings in low quality context (e.g. tech debt, bad patterns). in the context of React for example, if the agent reads a bunch of components that abuse useEffect, you're going to get more of the same slop in new code.

managing this context window and knowing where and how to provide just the right amount of high signal context to the agent is one of the most underrated yet important skills that i think we'll be working on for some time.

isn't this still painful?

yes. prompting an agent this way can feel unnatural and requires you to have strong opinions on how code should be written. i've written a Claude Code plugin that packages up this workflow to interactively build up a spec (or just optimize a prompt) containing high signal context, so it's not quite as painful as plain prompting in this style. if there's interest, i can try and see if i'm able to share an open source version.

there are many plugins and workflows that provide this "spec driven" flow, (or you can just Plan mode) but i've put a good amount of effort into designing a good UX for this skill that i hope to see others copy. the plugin makes extensive use of custom subagents to isolate context while performing searches for relevant files and directories (focusing on internal docs, posts, diffs, etc), and also makes heavy use of AskUserQuestion and TodoWrite. i think it "feels" almost like a built-in skill.

but whether you use this plugin or even make one of your own, i hope this inspires you to invert the pyramid and start with context first. this is a style of AI coding that i believe works extremely well for experienced engineers who have great taste. start by pulling out that signal into context first, whether it's supplied by you or found by the model.