Engineering rituals for AI teams that keep systems fast

Why faster coding can slow a product down

AI tools let small teams ship in days what used to take two weeks. The catch is that code grows faster than attention. When each developer can produce more pull requests, experiments, and quick fixes, the product changes in more places at once.

That extra code has a cost. Every new path can affect tests, startup time, database queries, logs, and build jobs. One harmless change rarely hurts. Five of them in a week can turn a clean system into a noisy one.

The slowdown usually starts in boring places. Tests take 12 minutes instead of 6. Logs fill with warnings nobody reads. Builds still pass, but deployments drag. One feature works fine while another gets a little slower. None of that looks urgent on its own. Together, it burns hours.

Developers start chasing flaky failures. Support sees odd edge cases. Releases feel riskier than they did a month earlier.

Faster coding needs a counterweight. A short design review before work starts, a quick check after a merge, and a weekly cleanup block can catch drift while it is still cheap to fix. That is how teams keep the speed without turning every Friday into repair day.

You can see the difference in AI-first operations that stay lean. Oleg Sotnikov has worked from that angle while running a global production platform with a tiny AI-augmented team and very high uptime. The lesson is simple: typing faster is not enough. Teams also need habits that protect the system.

What a design review should cover

A design review works best before anyone has a pile of code to defend. If an AI tool can generate a week of work in an afternoon, the review should happen when the idea is still cheap to change. Ten minutes early can save two days of cleanup later.

Start with the plain question: what problem does this change solve? If nobody can answer in one or two sentences, the team is not ready to build. Then ask how you will know it worked. Pick something you can check after release, such as fewer support tickets, faster page loads, or less time spent on a manual task.

Most reviews do not fail because someone missed syntax. They fail because nobody traced how the change moves through the system. Follow the data from input to storage to output. Look for places where it can get duplicated, lost, delayed, or shown to the wrong user.

A short review should answer four things: where the data starts, changes, and ends; what happens when an API, model, or queue returns bad results; how the team can turn the change off if production gets weird; and which part carries the most risk.

That last point matters. Do not read every file line by line in the meeting. Focus on the risky seam. It might be a billing rule, a background job that can run twice, or a new AI call that adds latency to a page that already feels slow.

Take a support tool that drafts customer replies with AI. The review should spend almost no time on button colors. It should ask where prompts and customer data go, what happens if the model times out, how agents fix a bad draft, and whether the team can disable the feature without breaking the inbox.

Good reviews feel small and practical. They do not slow a team down. They stop rushed code from spreading risk across the whole product.

Post-merge checks that catch trouble early

A merge is not the finish line. It is the point where small problems start showing up under real load, real data, and real timing. Teams that ship AI features feel this quickly because they merge often and touch more moving parts.

Start with a short check right after each merge. Watch build time, test failures, and error volume in the next pipeline runs. If the build suddenly takes six minutes longer, or one test starts failing every third run, treat that as a real signal.

Logs usually speak before users do. Scan for new warnings, repeated retries, and noisy fallbacks. In AI systems, one bad prompt change or one weak timeout can trigger thousands of retries, extra model calls, or slow database queries by the end of the day.

A simple check can compare four numbers with the last stable release: latency, CPU and memory use on the same path, retry and warning counts, and test or build trends across recent merges. You do not need a huge process for this. You need a clean baseline.

If latency jumps from 300 ms to 480 ms on the same endpoint, that merge needs attention even if it technically passed. If memory use climbs 20 percent for the same job, someone should look at it now, not next sprint.

Ownership matters too. Assign one person each day to clear failed checks, review noisy alerts, and decide what happens next. That person can revert a change, ask for a quick fix, or open a follow-up task. Without a named owner, teams get used to red dashboards and stop seeing them.

Fast teams do not ignore small regressions. They catch them while the change is still fresh, the author still remembers the code, and the fix takes 15 minutes instead of half a sprint.

Weekly cleanup stops slow drift

A short cleanup block every week does more than most teams expect. AI helps people ship more code, more experiments, and more tiny fixes. That speed feels great until the codebase gets harder to trust.

Drift rarely starts with one big mistake. It starts with leftovers: feature flags nobody needs, branches that never closed, prompts from old tests, helper functions that do almost the same thing under different names, and small docs gaps everyone works around.

A weekly cleanup works because the mess is still familiar. People still remember why a prompt changed, why a folder got split, or why a workaround slipped in. Wait a month and even simple cleanup turns into archaeology.

Keep the session short, usually 30 to 45 minutes. Remove stale flags, branches, and prompts that no longer run. Fix flaky tests while the failure pattern is still obvious. Patch setup notes, runbooks, and comments where people got confused. Merge or delete duplicate helpers, rename vague functions, and straighten messy folders.

Flaky tests deserve special attention. If a test fails at random for two weeks, people stop respecting red checks. Once that happens, real failures hide in the noise.

Docs matter more than teams like to admit. AI can write code fast, but humans still need clear names, clean folders, and short notes that explain odd choices. One missing sentence today can waste 20 minutes for three people next week.

Keep this cleanup boring. Do not turn it into a deep refactor or a style debate. The point is to trim obvious waste so the system stays easy to read, test, and change.

A simple weekly rhythm

These habits work best when they follow a simple rhythm instead of turning into more process.

• Monday: review the risky changes planned for the week, such as schema updates, new background jobs, model switches, or prompt logic tied to billing and support.
• Before larger work: do a short design review with one owner and one clear decision.
• After each merge: check tests, logs, response time, and spend while the change is still fresh.
• End of week: reserve one block for cleanup and write down the small problems the team kept working around.

That schedule fits on one shared note. Keep it in one place that everyone can find and update. Start the next week by reading it for five minutes. Repeated problems become obvious quickly, and that makes the next round of fixes much easier.

A small team example

Picture a team of five adding AI summaries to a customer dashboard. Two engineers handle the backend, one builds the frontend, one tests, and the product manager writes the first summary goals. The feature looks small on paper. It can still create support issues if the model stalls, the queue backs up, or summaries fail without a fallback.

Before they ship anything, they do a short design review. They map the prompt flow from user action to saved result. Then they check three practical points first: how many model calls one summary needs, what happens when the provider limits requests, and what the user sees if generation fails. They choose to cache repeated requests for 10 minutes and show plain text fallback instead of an empty dashboard card.

The review takes about 25 minutes and saves much more time later. One engineer notices that retries could pile up if the queue slows down. Another sees that the prompt asks for extra detail nobody needs, which would add cost and latency.

They merge the feature the next day. The checks after the merge catch trouble early. Queue time jumps from a few seconds to almost a minute during a test batch. The logs also show noisy retries. Nothing has failed yet, but the system is drifting in the wrong direction.

On Friday, they fix it before the problem turns into a weekly headache. They remove a duplicate retry path that fires once in the worker and again in the API client. Then they rewrite the alert rules so the team gets one clear warning for queue delay instead of a flood of near identical alerts.

The next week, summaries stay fast under normal load and support gets no complaints. That is what these routines buy you. The team does not wait for a big outage. It catches small signs early, fixes them while the code is fresh, and keeps a useful feature from slowly becoming a slow one.

Mistakes that make these routines fail

These habits help only when they stay small, clear, and boring in a good way. Teams usually break them by turning a simple check into a long meeting where nobody decides anything. People talk, raise concerns, and leave with "we should revisit this," then the code ships anyway.

Design reviews go off track when the team argues about naming, folder layout, or personal taste for twenty minutes and skips the parts that hurt later. Error paths, retries, logging, rollback, and cost need more attention than style. In AI heavy code, that mistake gets expensive fast because teams produce more code in less time.

Cleanup is often the next thing to die. When a sprint gets busy, teams promise to tidy things up later. Later rarely comes. Dead feature flags, duplicate helpers, stale prompts, skipped tests, and old config stay in place, and each one adds a little friction. After a month, nobody feels fast anymore.

Checks after a merge fail in a quieter way. A test flakes once, then twice, then everyone starts rerunning the pipeline until it passes. After that, the pipeline stops meaning anything. If a check fails for random reasons, the team should fix it fast or remove it. Living with flaky checks teaches people to ignore real problems.

Another common mistake is putting all review work on one senior engineer or the CTO. That person becomes the queue, the judge, and the bottleneck. Small teams do this by habit, especially when one person knows the system best, but it does not last. Shared checklists and rotating reviewers spread context and keep the pace steady.

A routine is in trouble when it has no owner, no clear pass or fail, and no follow-up. If that describes one of your team habits, change it this week. Small fixes beat heroic catch-up work every time.

How to start without slowing the team

Most teams fail with process for a simple reason: they add too much at once. If you want these routines to stick, start small enough that nobody needs a meeting to explain them.

Pick one rule for design reviews, one check after each merge, and one cleanup block each week. That is enough to catch a surprising number of problems without turning daily work into paperwork.

A good starting set is simple. In design reviews, require one short note on performance risk before work starts. After each merge, check build time, error rate, or one other signal your team already watches. Reserve 30 minutes a week to remove dead code, stale prompts, unused scripts, or noisy alerts.

Run that routine for two weeks and keep notes short. One sentence on what the team checked, one sentence on what it found, and one sentence on whether the step helped or wasted time. The notes matter because teams often keep habits that feel serious but catch nothing. If a step creates noise, drop it. If one small check catches broken caching, duplicate API calls, or a test suite that quietly doubled in time, keep it.

A lighter approach works better than forms, approvals, and more dashboards. Test one rule, watch the result, then keep only the parts that save real time or prevent real messes. A small team can do this with almost no overhead. One engineer writes a short design note, the reviewer asks one speed question, and the person who merged watches the app for ten minutes after release.

If a team wants an outside view, Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor for companies that need help with product architecture, infrastructure, and practical AI adoption. The useful version of outside help is simple: trim the routine to what the team will actually keep doing when the week gets busy.