AI in a well-organised workshop: how our engineers use AI every day

Clients now regularly ask us whether AI makes software faster and cheaper to build. Our honest answer is: it can, but only in a team that already works in an orderly way. AI amplifies whatever process it lands in. In a well-organised workshop it takes routine off people and leaves more time for the hard parts. In a chaotic one it produces more code that nobody has properly checked.

So this post is less about tools and more about where they sit in our process. It describes how we work in June 2025, knowing that the tools change every few months.

Order first, tools second

Before any assistant is useful, a few things have to be in place. None of them are new, but AI makes them more important, not less:

• Clear tasks. In our projects every pull request is tied to a ticket with a goal. A vague task produces vague code, whoever writes it.
• Code review as standard. A change is merged only after another engineer has looked at it, whether it was typed by hand or suggested by a tool.
• Automated checks. Tests and continuous integration catch the plausible-looking mistakes that assistants are good at producing. In some projects the pipeline also posts a test coverage report on every pull request.
• Consistent code. An assistant follows the patterns it sees in the codebase. If the codebase is consistent, so are the suggestions.

With this in place, anything an assistant produces goes through exactly the same pipeline as any other code. That is what makes it safe to use.

What AI does in our pipeline today

A summary of every pull request. Since December 2024 an AI review bot, CodeRabbit, has been connected to our GitHub organisation. When a developer opens a pull request, within a minute or two the bot posts a short summary of the change, a file-by-file walkthrough and, where it helps, a sequence diagram of the new flow. It writes in Polish, the working language of the teams concerned. In the first weeks we also tried its line-by-line comments; today we rely mainly on the summaries. The bot does not approve anything: the reviewer starts from a clear map of the change, and approval and merge stay with a colleague.

Assistants in the editor. The JetBrains IDEs our company licenses now come with a built-in AI assistant. In spring 2025 access to it became an organisation-level setting, which is exactly where such a decision belongs: whether and how AI is used in a project is decided by the company and the contract, not by each developer alone. Since December 2024 the company has also paid for Cursor, an editor built around AI; by spring 2025 several of our developers and our software architect were working in it on company-paid seats. The typical uses are the same everywhere: boilerplate and repetitive changes, data mappings, first drafts of well-understood components and tests, and explanations of unfamiliar code before we touch it.

Chat assistants around the code. The company has paid for ChatGPT since June 2023, and since early 2025 an AI note-taker has recorded and summarised our meetings. We use them for the work that surrounds programming: going through long specifications, listing open questions, drafting documentation and descriptions of changes. The output is a draft for a person to check, never a final answer.

AI helps less where the problem is genuinely new: architecture decisions, subtle concurrency, and low-level code for specific hardware, where public examples are scarce and a wrong guess is expensive. In our embedded and IoT work we treat suggestions with extra caution.

The rules we work by

1. The engineer owns the code. Whatever the assistant suggested, the person who commits the change is responsible for it, must understand it and must be able to explain it in review.
2. Client code and data only where the client agreed. Code goes into an AI tool only where the contract and the client's policy allow it and the tool's terms fit. Personal data, credentials and secrets are never pasted into a prompt.
3. Contracts come first. Some clients welcome AI assistance, some restrict it, some exclude it. What the contract says is what we do.
4. People need to know how the tools fail. Since February 2025 the EU AI Act requires organisations that use AI systems to take measures to ensure a sufficient level of AI literacy among their staff. For a software team this is practical knowledge: invented functions, outdated libraries, confident but wrong answers, and what may and may not be shared with a tool.
5. A tool stays because it helps. Not because it is fashionable.

How to judge whether it really helps

Productivity claims about AI are easy to make and hard to verify, so we avoid quoting a single percentage. The signals worth watching are the ones that matter in any project: how long a task takes from start to merge, how much rework comes back from review, how many defects appear after release. And the engineers themselves, because they notice quickly where a tool saves time and where it only creates cleanup work.

Our working assumption is simple: the gains are largest on routine, well-defined work and smallest on hard, novel problems. That tells us where to rely on assistants and where to keep them out of the way.

What comes next

The tools are changing quickly. Assistants that once completed a line of code are starting to carry out several steps on their own: change several files, run the tests, propose a complete change. We are following this closely, and the same principles will apply: clear tasks, tests, review, and a human who is responsible for the result.

There is also a lesson here for our clients. The same thing that makes AI work in a software team makes it work in any business process: first put the process in order, then choose the tool. It is the same approach we take when we check an AI idea before building it.

AI is another tool in a well-organised workshop: powerful, but only as good as the process around it. If you would like to talk about how AI could support your team or your product, see what we do in AI or get in touch with us.