Chapter 9: General Trends in AI-Driven Development
AI-Driven Development: Landscape Overview
┌────────────────────────────────────────────────────────────────────────────┐ │ CURRENT AI CAPABILITIES │ │ │ ├──────────────────────────────────────┬─────────────────────────────────────┤ │ AI IS GOOD AT │ AI IS NOT GOOD AT │ │ │ │ ├──────────────────────────────────────┼─────────────────────────────────────┤ │ │ │ │ Implementation (writing code) │ Determining WHAT to build │ │ │ │ │ CRUD functionality │ Understanding business context │ │ │ │ │ Design from brand kits │ Complex third-party integrations │ │ │ │ │ Sweeping design changes │ Maintaining long-run context │ │ │ │ │ Rapid prototyping │ Enterprise compliance / security │ │ │ │ │ Code organization │ Novel problem solving │ │ │ │ │ 75-85% of project spec │ The remaining 15-25% │ │ │ │ └──────────────────────────────────────┴─────────────────────────────────────┘Key Trends:
| Trend | What’s Changing | Impact |
|---|---|---|
| Design collapse | Design → Code gap eliminated | Developers need design skills |
| Rise of prototypes | 75-85% of spec built rapidly | Client alignment accelerated |
| Write-then-revise | Build first, audit after | Mental load reduced |
| Parallel agents | Multiple agents, pick the winner | Hallucination combated by volume |
| Agentic looping | Iterate until criteria met | Hallucination combated by iteration |
| Context management | Performance drops after 50% context | Fresh sessions per spec |
| Agent tooling | AI gets more computer access | Capabilities expanding fast |
I’m just going to reiterate that AI has established itself as an implementor of software, not a thinker. Assuming that this is true, a couple key trends have emerged recently. First, the landscape of design has grossly changed. A suite of tools specifically aimed at the implementation gap between translating design to code rose to prominence in the pre-AI era. Figma is probably the largest player in this space. Now, Figma does a lot more than simply exist as a middle layer between design and code, but that is fundamentally one of its core functions. Translating design into code was so burdensome, that entire roles were allocated to solve this problem alone. Namely designers focused on design and the frontend developers would focus on implementation. Entire component libraries were internally created at companies to ease this transition process and maintain design consistency across products. However, now with AI, most of that implementation layer has collapsed [29]. Design is still important, yes, but as implementation labor has collapsed, design can be implemented directly into code from the start of the project. You can essentially design while building rather than design then build. Of course, there’s a separate suite of skills that a designer has that a developer has not specialized in, but this trend will, in my opinion, mandate developers to pick up these skills and become a requirement for many roles in the near future. Expanding on this, sweeping design changes can be implemented as well. If you have an existing product with 100 screens, assuming the project is set up correctly, providing AI with a general brand kit to follow, will allow an entire application’s design to be changed in hours, rather than months in the pre-AI era. Another aspect of this that we are seeing is that the implement first, revise later, loop holds when it comes to design. In many cases, it’s faster to just give a general brand kit to follow for sweeping design implementations or updates, and then revise each screen after a product wide sweep, than it is to spend a lot of time planning each specific screen.
Another emergence in relation to design is the rise of the prototype. Prototypes are the first step in Benmore’s development process as it allows clients to materially experience, roughly, what their project is going to look like and how it’s going to function. Beyond the client benefits, it essentially is the representation of the min/max of AI development efficiency. Specifically, and we’ll touch more on this later, but AI implementation of software is really good at building simpler aspects of the project and the simpler the feature, the less human intervention needed. Most of the time, this boils down to being about 75-85% of the project. This 75-85% of the project is… a prototype. A representation of the project that can be built efficiently to show direction, while forgoing complex aspects of the project for development efficiency. Using the Spec Tree to rapidly build a prototype does wonders for implementation phase project alignment and the trust process. Additionally, so long as the prototype stays within the efficiency bounds of AI coding tools, changes can also rapidly be updated and so can the Spec Tree. Which, in turn, can be used to update all other project definition assets and determine changes from scope. Looping this back to design though, a prototype has been extremely effective for us and we don’t use Figma anymore - it just serves the purpose of the design phase better, in our opinion. This doesn’t diminish the importance of design, it just changes the medium and methods in which designs are created and revised.
Another trend that we’re seeing is the write then revise loop of software. Specifically, when it comes to implementing a feature (not in a prototype) previously, comprehensive understanding of the dependencies and entry points for the new feature were needed. What code was going to be affected, what files needed to be changed, etc. Now, even in solo, small projects this was needed. An example: when implementing a login screen for a to-do list, as a developer without AI, you would have to know what location of the codebase to write the frontend in, what location of the codebase to write the middleware in, what location of the codebase to write the business logic, and, lastly, what location of the codebase communicated with the database. Whether you knew where these things were instantaneously because you wrote the project from the ground up, doesn’t matter, by definition, in order to implement a login, you had to know where these things were. Now, with AI, you just don’t. It’s helpful for sure to know these things to effectively guide AI, but by no means is it needed now. This compounds, and the more complex a feature and the more files that it needs to modify, the less it makes sense to holistically understand the implications a feature will have on a codebase before directing AI to write it. Now, after the feature is implemented, auditing the changes is important, but the focus has started to trend towards implement first, review and revise after. This means code can be written faster, and also reduces the mental load on the developer. It has also paved the way for some interesting methodologies in the space. Namely, parallel coding and test-driven continual agentic loops.
Parallel agentic coding, in our definition, is determining a feature to implement and then deploying multiple agents to implement the feature at the same time. Whichever agent successfully completes the feature or implements the best version of the feature is kept while the changes of the others are discarded. Agentic looping, is defining a suite of acceptance criteria in relation to a feature, and then perpetually implementing and refining the feature in a loop until it meets the criteria or spec. Currently, both of these trends offer a solution to the agentic hallucination problem. When AI encounters a robust feature to implement, many times, it will complete 85% of the feature and maybe add in additional components that were not in spec. Parallelization combats this issue with volume, looping combats this with iteration. In my opinion, the effectiveness of the base model itself will get so good that neither of these tactics will be necessary - or one of these methods of combat will be natively integrated into a core model. But the larger point here is that systems are currently being built to try and solve the “one-shot” problem: can you go from spec to code in one autonomous agentic run.
We touched on this earlier, but another trend that is emerging is the mental load of coding on the developer. These agentic runs can take minutes to complete and in that time, focus can be shifted to other coding projects or tasks in general. At Benmore, it’s not uncommon to see one of our forward deployed developers concurrently working on multiple projects at the same time as a true orchestrator. The dopamine cycle has also proved itself to be addictive and similar to one of a slot machine. You have an outcome that you want in relation to software success criteria, and you are deploying a non-deterministic system to provide you with that outcome. It’s like a slot machine. There’s a 10% chance the feature will be completed, and if you hit big and the feature is correct, you get a dopamine rush. If the feature is not completed you send off another prompt to chase the rush (you spin again). I’m slightly exaggerating here but the similarities between prompting and gambling should be acknowledged.
Another aspect that is emerging is the importance of setting bounds on the agents due to the feature spawns that they may produce. We talked about utilizing user flows and the spec tree to ensure that agents stay within project bounds during agentic runs, and this has been effective. These models have a tendency to want to overstep their directive, so ensuring that guardrails are in place early on is important.
The Write-Then-Revise Loop
PRE-AI WORKFLOW AI-ERA WORKFLOW ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ │ │ │ Understand ALL │ │ Define the spec │ │ dependencies │ │ │ │ │ │ │ └────────────┬─────────────┘ └────────────┬─────────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ │ │ │ Plan ALL file changes │ │ Direct AI to implement │ │ │ │ │ └────────────┬─────────────┘ └────────────┬─────────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ │ │ │ Write code manually │ │ Review & audit │ │ │ │ AI's changes │ │ │ │ │ └────────────┬─────────────┘ └────────────┬─────────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ │ │ │ Test & debug │ │ Revise & iterate │ │ │ │ │ └──────────────────────────┘ └──────────────────────────┘ Focus shifted from "know everything before writing" to "implement first, review and revise after"
Context and usage management has also risen to extreme prominence recently. These tools are so valuable, that their usage caps must be protected and, when using them, ensuring that they are being used as effectively as possible is key. Many agentic models greatly decrease in performance on long running conversations, and the optimal usage of these models is when 0-50% of their set context limit has been exhausted - performance tends to decrease after this benchmark resulting in more hallucinations, lower remembrance, and worse performance in general.
AI Context Window Performance Curve
Performance Quality │ 100%│ ██ │ ████ 80%│ ██████ │ ████████ 60%│ ██████████ ██ │ ████████████ ████ 40%│ ██████████████ ██████ │ ████████████████ ████████ 20%│ ██████████████████████████████████████████████████████████ │ ██████████████████████████████████████████████████████████ └──────────────────────────────────────────────────────────── 0% 10% 20% 30% 40% 50% 60% 100% Context Window Used ◄─── OPTIMAL ZONE ───►◄────── DANGER ZONE ──────────────────► (0-50% used) (50%+ — hallucinations ↑, remembrance ↓) U-Shaped Curve: Info at the BEGINNING and END is remembered; middle content is often LOST [30].Practical Rules:
Research has confirmed this — a landmark 2024 study published in the Transactions of the Association for Computational Linguistics found that language model performance degrades by over 30% when relevant information is positioned in the middle of long contexts, exhibiting a U-shaped performance curve where only information at the very beginning or end is reliably utilized [30]. Methodologies are currently being developed to combat this, but, in my opinion this issue will get solved as more powerful and efficient models are rolled out.
Lastly, agent tooling and access has recently established itself as a vastly underestimated component of model development. Essentially, training and giving these agents more control over computer navigation, web navigation, external system navigation etc. is a major initiative. Spawned by the effectiveness of Claude Code, which essentially gave AI access to navigate around the folder structure of a computer, many companies are rushing to build a layer of tools that are purposely built in a way to provide ease of use with agentic models.
My future prediction is that most of these issues are going to resolve themselves, I do think that we will get to a point where we can go from a general spec and light success criteria, and have an entire application built. We can then document the application, understand its limitations, and then instruct revisions based on future success criteria until the entire application meets our needs. Essentially, what is happening in terms of build then review at the feature level of development, will travel up to the entire application layer. As of now, though, processes need to be built to make what the capabilities of the models are now, as productive as possible.