Agents write more of the code now. I help teams decide what ships.

Hello, I'm Kamil Skrzypiński. The interesting question about AI agents in a company is no longer whether they can write code. It's what happens to everything around the code. That was always the difference between a product and a pile of code, and four things decide it: the code itself, the people, the process and the business. I've worked on all four for two decades, the last ten of them leading technology, from early-stage start-ups to public-sector bodies. I can speak CFO and review a pull request in the same conversation.

Agents have started to change how organisations build things, and it shows first in where the effort goes. Writing code used to be the expensive step; with an agent in the loop, the expensive steps become describing the work well enough to be done, checking the result, and deciding whether it belongs in the product at all. Roles blur: a product manager, a designer or a junior engineer can reach a working version sooner than before, and the questions that follow are organisational, not technical. Who answers for what an agent produced? What may it touch? How do we know it helped? Some companies treat all this as a tool purchase and are surprised when little changes. Others treat it as a change in how work is organised, and that is where my mix of backgrounds is useful.

I came to it through code: backend, frontend, mobile and embedded, with security CTFs in between. I like looking at a system through the eyes of someone who wants to break it, which turns out to be handy the day an agent gets access to your repository. The people side came from hiring engineers, running HR processes and teaching programming in and outside companies. It taught me that teams get built deliberately, not as a side effect of filling the next backlog.

Process is the part I set up and ran myself, DevOps and on-call rotations included, because a product is the process that keeps it alive, not the release date. And business is where I found clients, bid in public tenders and followed projects from the first conversation through build and rollout to years of warranty support, answering for it with my own name. That is where I learned that code you have to maintain for years is written differently from code that only has to survive a demo.

Language models joined all this in 2022, and I've worked with them ever since: as product features and as small, purpose-trained classifiers. So I know how much a well-fitted small model can carry and where a large commercial one earns its cost. The workload drives the choice, not the hype cycle. Today agentic coding tools are part of my daily workflow, and the rule I apply to them is the one I'd apply to any new colleague with commit rights:

An agent earns autonomy only after its sandbox shows where the boundaries are.

Helping a team set those boundaries, and then work comfortably inside them, is most of what I do with agents.

What agents can do for a team, or for a whole company, is easy to oversell, so a word about numbers. I won't claim a tenfold speed-up. I have no such figure, and I distrust anyone who quotes one before looking at the whole operation: the code, the people working on it, the process around it and what it earns. I look at it from both ends: from the desk of the person doing the work to the C-level deciding where the money goes, because a gain at one level can quietly disappear, or turn into a cost, at another. So we establish a baseline across all four, try the new way on one slice of the product and compare: how long work takes, how often it breaks, how the team copes with it and what it costs. A negative result is a result too.