"Get Shit Done: A Meta-Prompting Context Engineering and Spec-Driven Dev System" markets itself as a solution for productivity. The pitch is simple: automate development, accelerate learning, and enable "discussion-driven" feature implementation. Its marketing materials claim users can get "95% of the way on complex tasks," citing anecdotes of 250,000 lines of code in a month. It has also been used to build and launch SaaS products, such as an agent-first CMS named whiteboar.it. This narrative, often amplified in developer communities like Hacker News and Reddit's r/programming, promises a significant boost in development speed. However, some users have reported that the Get Shit Done system did not "get shit done" or provide measurably better results than direct Claude prompting, despite others finding it highly effective for complex tasks.
The Velocity Mirage: Unpacking the Get Shit Done System's Promise
However, unmanaged velocity without precision risks compounding errors and increasing long-term technical debt. The Get Shit Done system's core relies on "meta-prompting" and "context engineering" to guide AI agents like Claude Code. This isn't a new approach; it's an abstraction layer over existing LLM interactions, attempting to manage generative models' inherent nondeterminism. The real challenge in development has never been typing code, but defining what code to type. The Get Shit Done system tries to make the AI part of the specification process, but user reports of excessive token usage and slow convergence reveal a deeper systemic issue.
The allure of rapid code generation is powerful, especially in a competitive tech landscape. Yet, the promise of the Get Shit Done system often overlooks the critical distinction between quantity and quality. While generating vast amounts of code quickly might seem like a win, the true measure of productivity lies in delivering robust, maintainable, and secure software that precisely meets requirements. Without this precision, the initial speed boost can quickly turn into a quagmire of debugging, refactoring, and security patches, ultimately slowing down the development cycle rather than accelerating it.
The Contextual Overload and the Token Burner
The operational flow of the Get Shit Done system is an iterative feedback loop. It refines requirements and generates code through successive interactions with an underlying AI agent. This "discussion-driven" approach, while framed as collaborative, quickly consumes an inordinate amount of computational resources. The system's reliance on extensive context engineering means that each turn requires the LLM to process not just new input, but a significant portion of the *entire conversation history*. This constant re-evaluation of past interactions, while intended to maintain coherence, becomes a major bottleneck.
This "context engineering" comes at a steep price. Anecdotal reports indicate users hitting 5-hour token limits in approximately 30 minutes, and weekly limits by Tuesday. This represents a fundamental architectural flaw for any system aiming for sustained, complex development. The cost of API calls, combined with the latency of multiple turns, quickly negates any perceived productivity boost. For businesses, this translates directly into higher operational expenses and unpredictable budgeting, making the Get Shit Done system less a cost-saver and more a cost-shifter.
The frequent user observation that the system is "highly overengineered" is a direct consequence. The Get Shit Done system attempts to abstract away LLM limitations through complex prompting and state management. In doing so, it introduces its own overhead. The frequent need for multiple turns to achieve a task is a symptom of an inefficient context management strategy. It struggles to converge on a solution without exhaustive, expensive iteration. This inefficiency isn't just about cost; it's about developer frustration and a lack of predictable outcomes, undermining the very productivity it aims to enhance.
The Future of Specification: A Critical Bottleneck
By 2026, the initial hype around "AI agents that write code" may have significantly diminished. Systems like the Get Shit Done system expose a critical truth: the true bottleneck in software development lies not in code generation, but in precise specification. Writing 250,000 lines of code is meaningless if those lines don't meet requirements, contain security vulnerabilities, or are impossible to maintain. The real hurdle often proves to be clearly defining requirements, a task that demands human expertise, domain knowledge, and critical thinking.
The Get Shit Done system offers reported benefits for initial scaffolding or rapid prototyping, like a self-hosted VPN server manager. However, it ultimately shifts cognitive load rather than eliminating it. Engineers don't write less code; they spend time managing the AI. This means refining prompts and debugging the AI's output. This represents a shift in cost: the effort of precise, human-authored requirements is traded for the hidden cost of iterative AI correction and validation. This trade-off often proves to be a net loss when considering the total cost of ownership for a software project.
The Economic and Skill Erosion Costs of the Get Shit Done System
Beyond the immediate token costs, the long-term economic implications of relying heavily on systems like the Get Shit Done system are significant. Businesses must factor in not just the API expenses, but also the increased time spent on AI output validation, security audits for AI-generated code, and the potential for higher maintenance burdens due to less human-understandable or optimized code. The perceived "speed" often comes with hidden technical debt that accrues over the project's lifecycle, leading to higher costs down the line.
Furthermore, there's a subtle but profound risk of skill erosion among developers. If engineers become overly reliant on AI for core coding tasks, their fundamental problem-solving, architectural design, and debugging skills may atrophy. The ability to write efficient, elegant, and secure code from scratch is a craft honed over years. Delegating too much of this to an AI, especially one with known limitations in complex reasoning and context management, could lead to a generation of developers who are excellent AI managers but less capable as independent software architects and engineers. This represents a significant long-term risk to innovation and software quality.
Engineers should recognize AI as an augmentation tool, not a replacement. Instead of chasing new frameworks, focus on robust specification, clear architectural design, and rigorous testing. Use AI for boilerplate, refactoring suggestions, or test case generation—tasks where its nondeterminism can be contained. For critical systems, human engineers remain indispensable for ensuring high assurance and predictable behavior. The causal link between "more AI turns" and "better software" is weak; increased iteration often reflects context management issues and a struggle to converge on a correct solution. The model correlates with output volume, not quality or efficiency. The long-term maintenance burden and the potential erosion of fundamental engineering skills represent significant, often unacknowledged, costs of relying heavily on such systems.
