AI Coding Getting Worse With Every Edit? Skills v1.1 Reveals the Real Cause and Solution

AI Code Getting Worse With Every Edit? The Problem Isn't Intelligence, It's Memory

Many people have run into this frustrating situation: asking AI to write a Snake game goes smoothly, but the moment you drop it into a real commercial project, it starts spouting nonsense and making things worse with every edit. The vast majority of people blame the problem on insufficient model capability, and thus eagerly await the next generation of large models to solve everything.

But renowned frontend engineer and content creator Matt Pocock offers an extremely counterintuitive conclusion: The low quality of AI coding isn't because it's not smart enough—it's because AI has no memory.

This conclusion has a solid technical basis. Large Language Models (LLMs) have a fundamental limitation at the architectural level: they have no persistent memory and can only process information within a fixed-size "Context Window."

Since Google's 2017 paper "Attention Is All You Need," the Transformer architecture has become the foundational architecture for modern large language models. Its core self-attention mechanism allows the model to consider information from all other tokens in the sequence when processing each token—this is the source of its powerful language understanding, but it also creates an O(n²) computational complexity bottleneck, which is both a performance bottleneck and a cost constraint. Take GPT-4, for example: its context window is about 128K tokens, while Claude 3.5 can reach 200K tokens. Expanding the context window is not a linear cost: extending the window from 128K to 1M tokens increases computation and memory overhead by roughly 60x. This means every conversation is essentially a brand-new, stateless inference—the model cannot remember the content of the previous session, the project's decision history, or the pitfalls it once stepped into.

It's worth noting that even if future context windows expand to the million-token level, the "effective attention" problem still remains—research shows that models exhibit systematic "forgetting" of information located in the middle of the context, the so-called "Lost in the Middle" phenomenon, confirmed by a 2023 research paper from Stanford and other institutions. This is why this phenomenon is so troublesome in practice—even if it's technically possible to insert more information, the model's effective attention to the middle portion of long sequences still drops significantly. This statelessness is barely perceptible when handling small tasks, but it gets dramatically amplified in complex commercial projects: when the codebase exceeds context capacity, or when architectural consistency needs to be maintained across sessions, the model "loses its memory" and handles problems in the most generic but least suitable way for the current project. This means that simply enlarging the context window cannot fundamentally solve the quality problems of large projects—process-based context management is the real solution.

According to an interpretation by Bilibili creator "为什么叫QQ" (Why Is It Called QQ), Matt used a brilliant analogy: imagine you can summon a fleet of engineers at any time, each supremely intelligent but with only five minutes of memory. They don't know why the project uses this particular architecture, what pitfalls were stepped into last month, or that seemingly foolish naming was actually chosen to be compatible with an ancient third-party interface. If you just give casual instructions, they'll use the most standard but least context-aware approach and turn your code into a mess.

This is exactly the core pain point of AI coding today—not a capability problem, but a lack of context and process.

Skills Repository: Distilling Validated Instructions into Reusable Processes

Matt's solution isn't to deny prompt design, but rather to stop pinning hopes on a one-time "god prompt." A more effective approach is to distill validated instructions into composable, repeatable processes. This is the underlying logic of the Skills repository.

Prompt Engineering gradually became a discipline after GPT-3's release in 2020, evolving from the initial "Zero-shot Prompting" to "Few-shot Prompting," Chain-of-Thought (CoT) prompting, and other techniques. CoT was proposed by the Google Brain team in 2022; by guiding the model to reason step by step rather than giving an answer directly, it significantly improved accuracy on complex tasks. However, these methods are essentially one-time—each interaction requires rebuilding the context. The philosophy of the Skills repository is closer to the concept of a "reusable component library" in software engineering: encapsulating validated prompt patterns into structured, composable units, similar to a function library or design patterns. This aligns with the underlying logic of recently emerging AI Agents and orchestration frameworks like LangChain and LlamaIndex—embedding AI capabilities systematically into development workflows through process orchestration rather than single prompts, fundamentally solving the one-time limitation of the "god prompt" methodology.

This repository breaks down the software development lifecycle into dozens of skills of varying sizes and composability, with more than twenty located in the stable "Engineering & Productivity" directory. In V1.1, Matt polished this process to perfection.

The First Step Isn't Writing a Prompt—It's "Interrogating" Requirements

The vast majority of people's first step in using AI is writing a prompt, but Matt's first step is grill with docs (when there's a codebase) or grill me (when there's no codebase). Both skills call the shared grilling primitive, completely reversing the paradigm of human-machine communication.

The core logic is: AI relentlessly interviews you, questioning every detail of the plan one by one until both sides reach consensus. Facts are determined by the agent's queries, decisions are left to humans, questions are asked one at a time, and each comes with a recommended answer.

Why do this? Because no one knows exactly what they want. "Requirements Rot" is a long-standing chronic ailment in software engineering. Brooks pointed out long ago in "The Mythical Man-Month" (1975) that the hardest part of a software project isn't building, but figuring out what to build. Research shows that the cost of fixing defects discovered during the requirements phase is 5-10x that of the coding phase and over 100x that of the production phase (data from the IBM Systems Science Institute). You think you want an "advanced search feature," but have you considered sorting weights, empty-state UI, debounce handling, search history storage, and tokenization? If you just let AI write the code directly, it will make these decisions for you using default settings—and these are very likely not what you actually need.

Matt introduced the concept of design as an act from "The Design of Design": design is making choices at branches of a decision tree. The "grill me" mechanism essentially introduces Socratic Questioning into AI interaction—forcing the requirement initiator to make implicit assumptions explicit through structured counter-questions. This is actually automating the "Requirements Elicitation" technique from requirements engineering—work traditionally done by business analysts or product managers through structured interviews is now handled by an AI agent. Through this process, you're not just giving AI instructions—you're actually brainstorming with a smart architect. According to the video, Matt was once grilled by AI with 16 consecutive questions, and complex features were even "interrogated" for half an hour, answering thirty to fifty questions.

In V1.1, Matt added a confirmation gate: absolutely never begin implementing the plan before consensus is confirmed. Acting too early is the biggest disaster in AI coding. In his words—code should be a byproduct of consensus; consensus is the goal.

From Spec to Tickets: Breaking Big Goals into Verifiable Minimal Slices

For multi-phase projects, after reaching consensus, first use 2spec to define the specification, then use 2tickets to decompose tasks.

V1.1 has two important renames and merges: renaming 2PRD to 2spec, because the generated document has long exceeded the scope of a traditional PRD; and merging 2plan and 2issues into 2tickets, using Ticket to uniformly represent work units in both local plans and real trackers.

The Spec contains a problem statement, solution, user stories, implementation decisions, test decisions, and scope boundaries.

Vertical Slicing: Making Each Ticket Independently Verifiable

Here's a key engineering concept—vertical slicing vs. horizontal slicing. Vertical Slicing is an important task-decomposition principle in modern agile development, first systematically articulated by people like Jim Shore and Gojko Adzic, and later widely adopted by methodologies like SAFe (Scaled Agile Framework) and Shape Up. Unlike horizontal slicing, which divides by technical layer, vertical slicing requires each work unit to span the entire tech stack from database to UI and deliver demonstrable, verifiable business value. The core advantage of this approach is avoiding the "70 out of 80 problem"—where all layers are 80% complete but the overall functionality doesn't work at all. The traditional approach advances layer by layer through database, interface, and UI (horizontal slicing); vertical slicing lets each Ticket span all layers involved in the current feature, forming an independently verifiable minimal functional unit.

In the context of AI-assisted coding, vertical slicing has additional value: each independently verifiable minimal functional unit naturally fits within LLM context limits, keeping the scope of a single agent session controllable while also making parallel multi-agent work possible. This approach essentially uses software engineering methodology to compensate for AI's architectural flaws.

For example: first fully complete the chain of "register with email and password and return a success status," rather than building all the database tables first.

2tickets also forces AI to declare a blocking boundary for each Ticket: if the tracker supports native dependency relationships, write it as a native blocking link; otherwise, record it as text. As long as the prerequisite task is completed, the Ticket enters the "frontline." This way you can spin up multiple AI agents simultaneously to complete mutually non-blocking tasks in parallel.

Implement Phase: Guarding Code Quality With TDD and Dual-Axis Review

Once you have a Ticket and enter the implementation phase, Skills constrains code quality through TDD and continuous validation. Test-Driven Development (TDD) was systematically proposed by Kent Beck in 2002, with its core being the famous "Red-Green-Refactor" three-stage cycle: first write a test that must fail (Red), then use minimal code to make the test pass (Green), and finally refactor the code under test protection (Refactor). The essence of this methodology lies in separating "design" from "implementation"—the test itself is an executable specification of the requirements. On the pre-confirmed Spec, each round writes one failing test, then makes one minimal implementation, running Type Check and relevant tests periodically along the way, and finally running the full test suite.

Interestingly, V1.1 redefined /tdd as the Red-Green cycle, with Refactor no longer belonging to this cycle but instead being proposed as a refactoring suggestion during the Code Review phase. Matt's goal is to reduce the number of concerns handled simultaneously during the implementation phase—immediate refactoring can easily break the logic that just started working. There's a deep cognitive-science basis behind this adjustment: both human and AI working memory are limited, and simultaneously bearing the two goals of "making code run" and "making code more elegant" actually violates Kent Beck's original intent—maintaining a "working rhythm," doing only one thing at a time, and getting fast feedback through tests, rather than solving both correctness and elegance dimensions in a single cycle.

Dual-Axis Parallel Code Review Mechanism

Code Review starts two parallel sub-agents:

• Spec axis: checks whether the requirements have been faithfully implemented;
• Standards axis: checks project standards and "Code Smells."

The two review lines are independent of each other, avoiding one dimension masking the problems of another. The Standards axis injects Martin Fowler's list of code smells. The concept of "code smells" was proposed by Kent Beck and systematically organized and popularized by Martin Fowler in his 1999 classic "Refactoring: Improving the Design of Existing Code," which summarized 22 common code smells, including Duplicated Code, Feature Envy (where a method is more interested in another class's data than its own class's data), Data Clumps (groups of data that always appear together), and Speculative Generality (over-designing for requirements that may never appear). The complete list is displayed on screen.

Matt cut right to the point: large models' training data is already deeply imprinted with these engineering concepts—you just need to add ten lines of guidance to the prompt to awaken its "engineering memory." There's an important technical logic behind this: these software engineering concepts appear extensively in hundreds of millions of lines of open-source code and technical documentation, and have long been a core component of LLM training data. Decades of best practices accumulated by engineers have been "distilled" into the model weights—the right prompt can precisely summon these latent engineering instincts, without needing to re-teach the AI these concepts. At the same time, he emphasized that code smells are heuristic judgments, not hard violations, and your project's own coding standards have higher priority. Therefore, Code Review is only responsible for identifying and proposing refactoring suggestions—whether to implement them is ultimately your decision.

WebFinder: Using "Fog of War" to Tackle Large, Ambiguous Projects

If a project is huge and full of unknowns, a single AI session may exceed the effective inference range or even hit the context ceiling. This is when WebFinder enters—it's the "upstream entry point" for facing large, ambiguous projects that a single session can't digest.

WebFinder introduces the concept of the "fog of war" from games. This metaphor comes from a concept proposed by the Prussian military theorist Carl von Clausewitz in "On War" (1832), referring to uncertainty on the battlefield caused by incomplete information. In game design, strategy games like "StarCraft" implement it as a core mechanic, where players can only see the real-time state of explored areas while unexplored areas remain dark. Introducing this metaphor into large software project management has deep engineering justification: "premature optimization" and "over-planning" in complex systems are common sources of resource waste, and the Agile Manifesto explicitly advocates "responding to change over following a plan." WebFinder's design philosophy shares common ground with "problem space exploration" in Domain-Driven Design (DDD) and the "Build-Measure-Learn" loop in Lean Startup—all being pragmatic strategies that acknowledge complete information cannot be obtained in a project's early stages and choose incremental exploration over one-time global planning. Don't try to see the whole picture at once; only plan for things within your line of sight—those clear problems that can be solved with a single agent session.

It builds a shared map on the project-configured issue tracker, supporting GitHub, GitLab, and local Markdown, and can also be configured for Linear and Jira (defaulting to local Markdown when not configured). The map only plans visible Tickets; beyond that is the foggy area not yet clarified. You don't forcibly cut through the fog—you just roughly note it down; as the Tickets in front of you are solved one by one, the fog ahead clears and new Tickets are generated accordingly.

In WebFinder, each Ticket has a type label: Research (a background agent researches and generates a summary), Prototype (creates cheap artifacts to improve discussion precision), Grilling (dialogue with humans to progressively deepen understanding), and Task (such as provisioning services, migrating data, configuring permissions).

By default, WebFinder only plans and doesn't implement—Task is the only exception—it performs necessary operations to unblock subsequent decisions. The final output isn't a deliverable, but a roadmap to the destination.

Prototypes are "disposable code" used to answer design questions: logic prototypes test behavior, and UI prototypes can be embedded in real application pages using real read-only data. Once a solution is confirmed, extract the key decisions and delete or absorb the prototype code—the reducers and state machines in logic prototypes may be extracted, while the winning UI solution should be rewritten to production standards.

Software Engineering Isn't Dead—It's More Important Than Ever

The repository also has a skill called improve code base architecture. Matt says: If your codebase is bad, AI will only produce bad code within it. When a codebase is full of tightly coupled modules with unclear responsibilities, AI simply doesn't know where to write tests or how to modify logic. Only by refactoring shallow modules into deep modules and drawing clear boundaries can AI navigate through it elegantly.

Faced with the panic that "programmers will be unemployed in the AI era, software engineering is dead," Matt's practice offers the most powerful answer: No, software engineering isn't dead—it's more important than ever.

The claim that "software engineering is dead" is not a new topic. Every technological revolution—from high-level languages replacing assembly, to RAD tools, to low-code platforms, to today's AI-assisted coding—has triggered similar professional anxiety. Historical experience shows that advances in tools usually improve overall productivity while pushing engineers' focus to higher levels of abstraction, rather than simply eliminating the profession. The "Software 3.0" concept proposed by Andrej Karpathy (former Tesla AI director and OpenAI co-founder) holds that natural language is becoming the new programming language, but the value of architectural design, systems thinking, and problem definition is further amplified rather than diminished—this actually places higher, not lower, demands on software engineers' systems-thinking abilities.

AI reduces the cost of generating code, not the value of software engineering. Module boundaries, domain language, test feedback, and problem definition are what determine whether an agent can work stably. Module Design, Domain Modeling, and clear system boundaries determine whether AI can perform stably within a codebase. The more valuable engineers of the future aren't necessarily the ones who write code fastest, but those best at defining problems and designing system boundaries.

Treat AI as a collaborator with no memory but tireless energy, guide them with rigorous processes, and accommodate them with clear architecture—this is the ultimate secret of programming in the AI era. If you still understand AI coding as searching for a one-time "god prompt," you may only be using its shallowest layer. The real future belongs to engineers who know how to tame AI through rigorous processes.

Key Takeaways

Key Takeaways