This feels very similar to what great marketers are going through with the AI-generated content mess. Vibe Coding has definitely lowered the barriers to getting projects off the ground and is great for building early conviction around an idea. But as you point out, once you move into large codebases, LLMs behave like few-shot thinkers - they loop, lose context, and what lands in production is often a vibe-coded mess that someone else has to undo.
I have cleaned up three such features recently where the model lacked “contextual” understanding of the application. Going forward, LLM architectures will improve, but the “hammock thinking” you describe is ultimately a human responsibility. I love software and problem solving, and I want LLMs to accelerate - not derail - my productivity. Yet right now, many of the “hard problems” are actually cleaning up vibe-coded messes, forcing us to add rules, guardrails, and design specifications just to keep projects on track.
It may take a few years before we codify new design patterns for AI-assisted development - patterns that reduce extraneous code, prevent subtle security risks, and sustain long-term maintainability. For now, AI coding tools are only as useful as any other productivity aid. The short-term mindset driving vibe coding encourages a “use and throw” culture in software development, and that’s a problem we’ll need to solve. The lost art of "Deep Thinking" resonates alongside The lost art of "Deep Listening" to formulate a problem statement/hypothesis as both of them are subtly converging to art of "Deep Learning" ?
Love this perspective. Hickey’s framing still holds up. In my world, the problem is not vibe coding itself. It is unbounded context. Chats tempt us to trade thinking for throughput, then context drift hardens into code.
We treat vibe coding like sketching. Useful for finding the edges, not for pouring concrete. The fix is a context contract that lives outside the chat and gets versioned like code.
In practice:
1. Research - Use the AI to map the problem space, surface constraints, and document assumptions. Capture the raw material as artifacts, not scattered prompts.
2. Plan - Freeze the approach as a plain-language spec with file paths, functions, and interaction patterns. Review this before a single change is made.
3. Implement - Point the agent at the spec, not the evolving chat. Generate deltas against approved modules only. Fail builds that entangle concerns or regress quality.
Two habits make this work: first, feeding the agent structured context upfront so it builds with intention instead of improvising. Second, keeping context portable, packaged in external files, repos, or tools instead of buried in a transcript.
Hammock time belongs on the critical path. Chats are a whiteboard, not a system of record. Done this way, vibe coding stops being chaos and starts being a fast on-ramp to simpler, more maintainable systems.
Also helps to have deep knowledge in the codebase that you're working within. 😄
I focused more on the practical process of prototyping with AI to do research and experimentation but it's ultimately trying to achieve the same thing.
AI is a very double edged sword. If you offload your thinking to it you'll never improve and erode your existing skill, but it's also a very great information retrieval and thinking tool. I've been able to use it to plan and prototype solutions that require a deeper understanding of the problem, and I never would have had the time to dive as deeply and experiment with as many approaches before AI.
I think you would enjoy this paper
* https://pages.cs.wisc.edu/~remzi/Naur.pdf
It's Peter Naur's classic paper on programming as an exercise in building a theory, which he wrote 40 years ago and seems more relevant than ever.
Thanks for sharing! I've never seen that one before. I'll give it a read.
This feels very similar to what great marketers are going through with the AI-generated content mess. Vibe Coding has definitely lowered the barriers to getting projects off the ground and is great for building early conviction around an idea. But as you point out, once you move into large codebases, LLMs behave like few-shot thinkers - they loop, lose context, and what lands in production is often a vibe-coded mess that someone else has to undo.
I have cleaned up three such features recently where the model lacked “contextual” understanding of the application. Going forward, LLM architectures will improve, but the “hammock thinking” you describe is ultimately a human responsibility. I love software and problem solving, and I want LLMs to accelerate - not derail - my productivity. Yet right now, many of the “hard problems” are actually cleaning up vibe-coded messes, forcing us to add rules, guardrails, and design specifications just to keep projects on track.
It may take a few years before we codify new design patterns for AI-assisted development - patterns that reduce extraneous code, prevent subtle security risks, and sustain long-term maintainability. For now, AI coding tools are only as useful as any other productivity aid. The short-term mindset driving vibe coding encourages a “use and throw” culture in software development, and that’s a problem we’ll need to solve. The lost art of "Deep Thinking" resonates alongside The lost art of "Deep Listening" to formulate a problem statement/hypothesis as both of them are subtly converging to art of "Deep Learning" ?
Love this perspective. Hickey’s framing still holds up. In my world, the problem is not vibe coding itself. It is unbounded context. Chats tempt us to trade thinking for throughput, then context drift hardens into code.
We treat vibe coding like sketching. Useful for finding the edges, not for pouring concrete. The fix is a context contract that lives outside the chat and gets versioned like code.
In practice:
1. Research - Use the AI to map the problem space, surface constraints, and document assumptions. Capture the raw material as artifacts, not scattered prompts.
2. Plan - Freeze the approach as a plain-language spec with file paths, functions, and interaction patterns. Review this before a single change is made.
3. Implement - Point the agent at the spec, not the evolving chat. Generate deltas against approved modules only. Fail builds that entangle concerns or regress quality.
Two habits make this work: first, feeding the agent structured context upfront so it builds with intention instead of improvising. Second, keeping context portable, packaged in external files, repos, or tools instead of buried in a transcript.
Hammock time belongs on the critical path. Chats are a whiteboard, not a system of record. Done this way, vibe coding stops being chaos and starts being a fast on-ramp to simpler, more maintainable systems.
Also helps to have deep knowledge in the codebase that you're working within. 😄
Good read! I came to very similar conclusions but via the lens of doing layers of prototyping which is to achieve the same goal of research and understanding: https://www.timetler.com/2025/04/08/prototyping-the-right-way-with-ai/
I focused more on the practical process of prototyping with AI to do research and experimentation but it's ultimately trying to achieve the same thing.
AI is a very double edged sword. If you offload your thinking to it you'll never improve and erode your existing skill, but it's also a very great information retrieval and thinking tool. I've been able to use it to plan and prototype solutions that require a deeper understanding of the problem, and I never would have had the time to dive as deeply and experiment with as many approaches before AI.