A year of working with AI in the studio, without the hype

What entered the process and stayed, what we dropped after two weeks, what surprised us.

We made the decision without a proper meeting and without a presentation. At some point everyone was simply tired of arguing about it.

"We had two months of corridor conversations," says Michal Schatz, who founded the studio in 2010 and has run it since. "Some people were convinced it was going to replace us, some were convinced it was a toy. Both sides spoke with total confidence, and neither had seriously tried it on real work for more than a week."

What we settled on was simple. Before we sell a client a new way of working, we run it here, on our own projects, on our own time. If it works we will know why. If it fails we would rather it fail on us.

This is the piece about what came out of that. It was not written to convince anyone, and some of what is in it we would have been happy not to find out.

What went in and stayed

The first thing that genuinely took hold was early research. Every project has a stage where you need to understand a field you did not know before. What actually happens during a garage visit, how an insurance claim is structured, which terms people in the field really use.

That stage used to take one to two weeks of reading. Today it takes a few days, and more importantly it starts from a higher baseline. Which means the first conversation with a domain expert is no longer spent on fundamentals.

The second was writing the code nobody enjoys writing. Integrations with existing systems, format conversions, one off scripts. The work a good developer does with a quarter of their attention and all of their time.

The third, and the least expected, was the number of variations in early design. "We used to show three directions because three was what we could get done," says Michal. "Today we can show eight, and that changed what we show. When another direction costs almost nothing, you can put the strange one on the table too, the one we always dropped because it was not worth an evening."

What we threw out after two weeks

We tried automatic meeting summaries. On paper that sounds like an obvious win. In practice it produced long, accurate documents nobody read. The problem is that a meeting summary is not a transcript of what was said. It is somebody's decision about what mattered and who needs to hear it.

We tried generating product copy. The results were always acceptable and never right. Good product copy sounds like the product, and that voice does not exist anywhere except in the heads of the team that built it.

And on one project we let code generation run too far without review. We got something that worked, that nobody understood deeply, and that we had to rewrite a week later. That was the most expensive mistake we made that year, and also the most instructive.

What surprised us

We expected the saving to be in time. The real saving was somewhere else.

"The thing that changed most is not how fast we work," says Michal. "It is how early we find out we were wrong. A bad idea used to survive two weeks because we had already invested in it. Now it dies on the second day, because you can build something out of it and see that it does not work before you fall in love with it."

The second surprise was less pleasant. As execution got cheaper, deciding what to execute got heavier. With eight directions on the table someone has to choose, and there is no shortcut for choosing. Hours saved in production came back, almost entirely, as conversations about what the right thing to do is.

What did not change

Research with real users did not change at all. You can prepare an interview faster and review the material faster, but sitting across from a person trying to use something and failing is still where you learn the things that cannot be learned any other way.

The large decisions did not change. What this product is, who it is for, and what we are willing to give up. Those stayed exactly where they were, in long conversations between people who take responsibility for them.

And the responsibility itself did not move. If something in the code does not work, it is ours. How it was written is interesting to us, and it is not interesting to the client, quite rightly.

Closing

If we had to sum the year up in one sentence, it would not be about tools.

"These tools lower the cost of doing," says Michal. "They do not lower the cost of being wrong about direction. If anything they raise it, because now you can be wrong much faster and in many more places at once. That is why we spend more time on decisions today, not less."

We would like to hear

Tell us what's stuck

One line is enough. You get an opinion back, not a generic quote.