A Few Things I've Learned About AI-Assisted Development in Mid-2026
Practical lessons from using coding agents on a growing codebase: repository rules, changelogs, scripts, testing, and context.
EB
Egor Burlakov
••7 min read
Over the past year, AI-assisted development has become part of our normal programming routine. The models are much better, the tools around them are more capable, and I personally spend now less time asking whether an agent can make a change than deciding what context it needs, what it should leave alone, and how we will know the change is complete.
These are a few lessons from working with an agent on modern-datatools.com, a codebase that has grown beyond the point where “look around and fix it” is a useful instruction. It has history, large documents, old plans, generated files, and more scripts than I can hold in my head at once. That has required a more deliberate workflow, shown in the picture below, and this post shares the lessons that have made the biggest difference.
Better models still need less noise
Current coding models such as GPT5.6 and Claude Fable 5 can trace a feature through a codebase, make a sensible change, run tests, and explain a trade-off with very little prompting. That makes it tempting to give them the whole repository and let them explore, yet a stronger model can also spend more time reading irrelevant material when the boundaries are vague.
On a small project, broad exploration is often harmless. On a mature one, such as modern-datatools, it can pull an agent through old changelog entries, archived plans, generated content, dependency lockfiles, and documentation that only looks related. The answer may still be correct, but the work takes longer and hence more expensive.
The useful change for me was not a dramatic new workflow. It was reducing the background material that appears by default and being more deliberate about what the agent reads first.
I started treating AGENTS.md as an operating agreement
The most valuable file in my repository is not an architecture document; it is a short AGENTS.md that says how I want the agent to work. It is where I put instructions that would otherwise be repeated at the start of every session.
I also found that one large instruction file does not scale. I use a hierarchy: general rules shared across my work, a project-level AGENTS.md for the repository's conventions, and smaller AGENTS.md files in areas such as frontend/ and backend/ when they have their own commands or constraints. The general file covers personal defaults, the project file covers Git, documentation, scripts, and testing rules, while a frontend or backend file can explain local commands, environment setup, or subsystem-specific checks. The agent receives the rules closest to the files it is changing, so the instructions stay relevant without making the root file enormous.
The rules are concrete:
Search for exact symbols and likely files before doing a broad search.
Read a large document around the relevant heading rather than loading it in full.
Check scripts/ and the relevant subsystem before creating another helper (for some reason the current AI models really like to write python scripts for every occasion...).
Run the smallest test suite that covers the changed behaviour while iterating, then run the relevant package suite before committing.
Stop and report before turning a narrow task into unrelated cleanup.
A compact version of this could look like this:
- Search exact symbols and likely files before broad exploration.
- Do not read large docs or the full changelog unless the task needs them.
- Before creating a script, search `scripts/` and reuse or extend what exists.
- Run the smallest test suite covering the changed behaviour; add a test when none exists.
- Report before expanding into unrelated cleanup.
These are not project facts; they are working preferences. That distinction matters. ARCHITECTURE.md can explain how the system is built, while AGENTS.md should shape the agent's behaviour on almost every task. Keeping the second file short makes it more likely to be followed and less likely to become another document that must be read wholesale.
A changelog should preserve history without becoming mandatory reading
I want an agent to be able to find out why a decision was made, but I do not need it to read years of history for a routine change. I now keep only the current period's entries in docs/CHANGELOG.md and move older entries into dated files such as docs/changelog/2026-Q1.md or docs/changelog/2025.md.
New entries stay short—usually two to four bullets about a committed repository change—and are inserted at the top below an explicit marker. I do not add entries for read-only investigation, a failed experiment, or a conversation about a change that never landed. When an older decision matters, the agent can search the archive by heading or phrase instead of loading every entry.
The same principle applies to large documents such as ARCHITECTURE.md, SCRIPTS.md, and DATABASE.md. They should remain useful reference material, but the default should be targeted reading: find the heading, read the nearby section, and follow links only when needed.
Search defaults make an immediate difference
Some repository paths are useful but rarely belong in an ordinary code search: public assets, generated files, old content batches, archived documentation, and dependency lockfiles. Adding these to .rgignore makes the first search quieter and makes it easier to find the code that actually owns the behaviour.
This is not the same as hiding history. I keep a canonical archive and make it available by an explicit search when the task calls for it. The point is simply that an agent should start with the live code and active documentation, not every historical copy of a plan.
Existing scripts deserve to be discovered before new ones are written
I learned this one the slightly embarrassing way and much more than once. Agents are excellent at creating a small script for a small job, including jobs for which the repository already has a perfectly adequate command.
That creates more than clutter. A duplicate helper can bypass established validation, use different configuration, or become a second workflow that somebody has to maintain. Before creating or changing a script, I now expect the agent to search scripts/, read the relevant entry in SCRIPTS.md, and report what it found. If a script is close but missing one safe option, extending it in place is usually better than adding a parallel tool.
This matters most for operational tasks such as content publishing, reporting, migrations, and maintenance jobs. Mature repositories often already contain the safe way to do the work; finding it is usually cheaper and more reliable than rebuilding it.
Testing should be narrow while I work, then broad enough to finish responsibly
I still want tests at the end of a change, but I no longer run every test in every package after editing one small component. During development, I run the smallest test file, test case, or feature suite that covers the behaviour I changed. If no existing test covers it, that is a reason to add one unless the change genuinely has no automated-test surface.
Before committing, I run the relevant package suite once. I reserve full frontend and backend suites for shared infrastructure, shared contracts, or cross-stack behaviour, where a local test cannot give enough confidence. Successful runs should be quiet and return a short summary; detailed logs are useful when something fails, not when everything passed.
That is not testing less. It is making feedback fast enough to use throughout the task, while still keeping a meaningful completion check.
I am more selective about tools and parallel work
Plugins, browser tools, document tools, integrations, and subagents can all be useful, but each one adds discovery metadata, choices, and sometimes context overhead. In a long coding session, I keep the tools that are relevant to the work and disable the ones I am unlikely to use. I use subagents when there are genuinely independent branches of work, not as a default way to make a task feel more productive.
Additionally, I make this an explicit repository rule. The agent should start with the implementation, tests, SCRIPTS.md, and the relevant AGENTS.md when the question concerns our own code or workflow. It should browse only when the answer depends on information outside the repository, such as current API documentation, a library version, or a vendor service. This turns “use the right source of truth” into a default behaviour rather than something I need to remember to ask for each time.
The setup is worth revisiting
There is no final configuration for AI-assisted development. Models, tools, and repositories keep changing, so the defaults need occasional attention too: model choice, compaction settings, enabled plugins, repository instructions, search exclusions, and test commands.
The lesson I want to keep is straightforward: give the agent enough context to make a good decision, but not so much that every task turns into an archaeological dig. Clear repository conventions, a discoverable set of scripts, focused verification, and a short operating agreement have made a larger difference to my day-to-day work than any single model change.
EB
Written by Egor Burlakov
Engineering and Science Leader with experience building scalable data infrastructure, data pipelines and science applications. Sharing insights about data tools, architecture patterns, and best practices.
Explore Further
Dive deeper into the tools and categories mentioned in this article.
