A year of AI assistants in our studio: what got faster and what didn't
A year ago, AI was an autocomplete toy for us. Now no project starts without it. Here's an honest account of what we gained, where we got burned, and the rules we wrote afterwards.
Azamat AbduyaminovFounder, lead engineer
Last autumn I added up how much time we spend on translation files. An average three-language site means 400–600 lines of JSON per language. Shajara ended up with four: Uzbek in Latin script, Uzbek in Cyrillic, Russian and English, roughly 1,300 lines each. That used to be a week of tedious work for a frontend developer, plus a couple of days of fixes once the client read the copy. Now the first draft of all four files takes an evening.
That's the most visible saving. The overall picture is messier, and I want to write it down while I still remember the details.
Where we started
There are five of us: me, our designer Murodjon, frontend developer Shahzodjon, backend developer Mirodil, and Samandar on mobile. Copilot in the editor came first, somewhere around 2023. It was good at finishing lines and bad at understanding the project as a whole. Then part of the team moved to Cursor, and since last year our main tool has been Claude Code in the terminal: it reads the repository, runs tests and migrations, and can open docker-compose itself to see why a container won't start.
Nobody decided this as a team. It spread more like a cold. One person showed how an agent wrote serializers plus tests in ten minutes, and a month later everyone worked that way.
Where AI actually saves hours
I spent a long time trying to put numbers on this. We don't have precise measurements, so what follows is my impression from a year of our own projects, not a study.
Boilerplate
A Django model, a serializer, a viewset, admin registration, permission tests. We've written all of this hundreds of times, slightly differently each time. Show the agent an example and it produces the same thing evenly, in the style of the neighbouring files. On Xonadosh we put the Django 6 and DRF backend together noticeably faster than similar projects in 2024.
Migrations and data transfer
A script that moves an old database into a new structure usually gets written once and thrown away. Spending a whole day on it hurts. AI writes it in half an hour, and we spend another half hour checking it against a copy of the database. We never skip that check.
Translations
I've mentioned these already. One important caveat: Uzbek text from a model can't go live without a human. Models mix up o‘ and the Cyrillic о, sometimes produce word-for-word calques from Russian, and in the Cyrillic version can suddenly switch to Latin script in the middle of a sentence. The draft is good. A native speaker still reads the final version.
Where AI gets in the way
Now the unpleasant part.
Architecture
An agent will happily propose an architecture, and it will look convincing. The problem is that it doesn't know the client has no DevOps person, that the server sits in Tashkent on a flaky connection, or that in six months one person will be maintaining the project. When we picked Fastify and Drizzle for Shajara instead of our usual Django, people around a table made that call, not a model. AI then helped us build it quickly, and that's a sensible division of labour.
Subtle bugs
The most annoying story of the year happened on Xonadosh. After the first round of fixes, a guard appeared on the route for joining a shared household. It required an invite token and, without one, sent the user back to the "you have no household" screen. It looked tidy. Except the "you have no household" screen opened the join page precisely without a token, and the paste-your-link form inside already handled that case fine. So the "Join" button simply did nothing.
Backend tests were green: the join POST honestly returned 201. What broke was the user's path, not the API. AI creates bugs like this easily, because each change makes sense on its own.
“The agent fixes exactly what you described. If you described the symptom instead of the cause, it fixes the symptom and breaks the scenario next door.”
Security
We had one incident here that made me stop treating AI as "just a speed-up".
The second case is recent. The image proxy on our own site turned out to have an SSRF hole: it would forward requests to arbitrary addresses. I still don't know for sure whether a person or an agent wrote it. That's probably the real lesson: in a repository, AI code and human code look the same, so everything gets checked. AI doesn't think about an attacker unless you explicitly ask it to.
The rules we ended up with
After all this we wrote down a few rules. They're simple, which is exactly why people follow them.
- Agents get no access to production servers or live
.envfiles. Ever. - A human reads every diff, even when "it's only translations".
- A task for an agent is written like a spec: what to do, what not to touch, how to check it.
- Before merging, we walk through the user flow by hand, not just the tests.
- Any secret that lands in a file under git gets reissued immediately.
- We make architecture decisions ourselves and record them in the repository.
The spec rule turned out to be the most useful. For one recent site, the spec we wrote for the agent was longer than any brief we ever wrote for people. It had everything: which sections, which fonts, which Lighthouse numbers count as acceptance, and a separate checklist titled "the site must not look like an AI template". Funny, but it works. Shahzodjon covers this in more detail in his piece on sites an AI built in five minutes.
What changed for clients
Clients don't care who wrote the serializer. They care about the deadline, the price, and the site not breaking.
- +We ship small fixes faster, often the same day
- +Three languages stopped being an expensive add-on
- +More tests, because writing them is no longer a chore
- +We can show a prototype for discussion within a couple of days
- −Timelines on big projects shrank less than everyone expected
- −Review got heavier: more code, longer to read
- −Mistakes became more plausible, and so more dangerous
- −Conversations with the client take as long as they always did
A word on timelines. On Enlawyer we built a Next.js and React 19 site with a Django backend, three languages and a serious SEO setup: sitemaps, structured data, tables of contents in articles. AI sped up the layout work and translations. But most of the time went into structuring practices and industries, agreeing copy with the lawyers, and working out how enquiries should land in Telegram. That's work with people, and no assistant shortened it.

We didn't cut our prices to zero either, and I'll be straight about why. We now do more for the same money: tests, a third language, small improvements there used to be no budget for. A landing page still starts at $800 and a corporate site at $2,000. Details are on our web development page.
What I still don't know
I'm not sure we're teaching juniors the right way. A junior who works with an agent from day one writes working code faster than I did at that stage. But when the agent is wrong, they don't always see where. Our answer for now: AI-written code is reviewed by someone who could have written it themselves. Whether that scales, I don't know.
I'm also unsure about parallel agents. On Xonadosh we tried running several at once: one built the mini app screens, another the API, a third the bot. It was fast, but the round of fixes afterwards took nearly as long as the build itself. Maybe we just split the tasks badly.
If we were starting over
I'd introduce the rules on secrets and review from day one, not after an incident. I wouldn't hand an agent architecture decisions even "just to try", because afterwards it's painful to throw away code that works. And I'd start with the dullest jobs: translations, tests, migrations. The payoff there is huge and the risk is close to zero.
AI made us roughly a third faster at writing code and exactly zero faster at talking to clients. I'm fine with that split.





