Integrating AI into development

AI speeds you up a lot in analysis, prototyping, and documentation. It lets you shift your cognitive focus: you can spend much less time writing code and more time thinking about which path to choose when implementing a new solution. The problem starts when we use the chat as a universal dumpster: we throw everything into the same thread, mix goals together, and then act surprised when the output degrades or doesn't match the solution we actually wanted.

AI does not replace technical thinking; it is a tool that should help amplify it. If there is no clear objective, the model fills the gaps with its statistical average, and that almost always leads to noise, overengineering, or solutions that don't fit what we really need.

Context is everything that goes into the model on each call: system instructions, history, user messages, tools, and previous results.

It's key to understand that the model doesn't "memorize" anything: it doesn't have persistent memory between turns the way humans do. On every iteration, the full conversation context is sent again.

Each iteration is a new request. The system sends the full context package again, which is why the payload grows on every turn: more tokens, more cost, and more chances for noise.

If you don't manage that load, the model doesn't "remember better" just because you chat longer: it only receives more accumulated text. In other words, it's not real memory; it's continuous rereading of history, with risk of truncation and loss of focus or key information.

In long chats, three effects show up: window overflow, anchoring to previous mistakes, and accumulated verbosity. This doesn't just reduce precision; it also makes quality unstable between runs.

Another key idea is that even if we don't hit the model's input token limit, performance usually gets dramatically worse long before that because of accumulated noise.

If the model made a wrong assumption early and we keep correcting it inside the same thread, it often stays biased by that dirty state and it's hard to recover. This hits even harder when the model already produced a solution, especially in code. What usually happens is that if the initial output wasn't the right one, instead of recreating it from scratch, the model tends to patch it rather than regenerate it properly.

The paper confirms a field intuition: when you move from a full single-turn prompt to an underspecified multi-turn interaction, average performance drops sharply. The interesting part is that most of that drop is explained by increased unreliability, not just loss of capability.

They also test recap/snowball strategies (repeating information), and they help partially, but they still don't match the clean single-turn scenario. In other words: it patches the problem, but it doesn't fix it at the root.

The most effective and cheapest improvement is to separate conversations by objective. One chat for planning, another for implementation, another for review. This reduces cross-contamination and gives you shorter, more verifiable prompts.

If the model gets lost, instead of patching endlessly in the same thread, consolidate everything into a clean prompt and restart. In practice, that usually performs better than correcting forever.

If we want to go one step further, we need to consider some other concepts. The layer that really defines consistency is the agent harness: the system of context, tools, and guardrails surrounding the model.

When I say harness, I mean it literally: an operational harness: a structure that holds, guides, and limits the agent so it doesn't drift, just like a safety harness prevents dangerous movements when working at height.

The difference between random results and repeatable results is usually not the model itself. It's usually about how much useful context you feed into each iteration and how much noise you keep out.

AGENTS.md acts as the repo's base contract: architecture, conventions, verification commands, and limits. Skills are specialized modules that the agent loads only when it touches that layer (frontend, backend, testing, etc.).

Practical result: less repetition in prompts, less style drift, and more speed to get into the task. It's documentation for humans and agents at the same time.

A solid harness combines four levers that reinforce each other. If one is missing, the system still works, but it loses stability as complexity grows.

If we still want to improve agent performance, we can use sub-agents that a main agent (the orchestrator) delegates specific tasks to.

What does that give us? Basically, we delegate tokens to a model that lives only for that iteration, letting us save those planning, implementation, and review tokens.

With an orchestrator and sub-agents, you separate roles: one analyzes and plans, another executes, another verifies. Each sub-agent is born with clean context and a narrow focus, solves its task, and then ends.

The orchestrator only knows what it asked for and the result of each sub-agent, without accumulating all the noise from the intermediate iterations.

This architecture avoids the "god" agent that accumulates everything: tickets, debates, old code, previous mistakes, and cross-cutting decisions.

The harness defines what the agent knows, but the feedback loop defines when it can call a task done. If there is no automated validation, everything depends on goodwill.

Tests, lint, typecheck, and builds are not post-processing; they are part of the agent's self-correction loop.

At scale, the challenge isn't only technical; it's consistency across stacks, versions, and legacy repos. That's why it's worth separating organizational base rules from local project rules.

Common foundation for security and quality, local layer to avoid breaking legacy contexts and each team's particular workflows.

Not all approaches behave the same. The big differences show up in scalability, consistency, and cognitive cost.

This checklist gave me the highest return when working with AI without breaking flow.

The paper itself points out simulation limitations. We shouldn't sell it as absolute truth, but as strong evidence aligned with real usage experience.

Security and responsibility still stay on the human side: no credentials in prompts and nothing goes to production without serious technical review.