AI in development and automation

AI in development is usually written about in two modes: a demo where everything assembles in five minutes, or scepticism where nothing works. Neither helps you decide, because neither states the conditions under which the result repeats.

What is collected here has been tested on our own products and on client projects. Agents in daily work and the rule by which we accept their output. The calculation that replaced a paid image processing service with an open model and changed the product's economics. A knowledge base maintained by the model itself, with a linter and rules against drift. And a brief for automating bookkeeping routine that shows where AI helps and where a person with signing authority is required.

One thing runs through all of it: the gain appears where the result can be verified quickly, and disappears where verification costs more than the work.

September 18, 2026 AI agents in software development: what they speed up and where they get in the way Agents pay off on work a machine can verify: routine code, migrations, tests, exploring an unfamiliar codebase, first drafts of documents. They cost time where verification is expensive: architecture, undocumented integrations, unclear requirements. The rule is simple: output you cannot verify in minutes is output you cannot accept. September 18, 2026 Automating routine work with AI: six bookkeeping tasks and the line where AI stops helping AI removes routine where the task repeats, the data is machine readable and the cost of an error is low given human review. The formulation that works with clients: the system prepares a draft, a human makes the decision. Tasks that need judgement and accountability are automated only in part, and admitting that upfront is cheaper than discovering it after rollout. September 18, 2026 A knowledge base for an LLM: three layers, a linter and a rule against drift Plain retrieval accumulates nothing: the model re reads the same documents every time. A working setup has three layers: immutable sources, a wiki layer the model builds and maintains, and a schema file with the rules. Such a base only pays off when it has an outlet: someone writes, decides or answers questions from it. September 18, 2026 Open models or a paid API: the calculation that decides it The choice is settled by one calculation: how many operations one user triggers and how much that user brings in. At roughly 20 cents per image and fifty images per user, processing costs more than a year of revenue from that user, while the same work on your own server costs fractions of a cent against a fixed monthly rental.

FAQ

Where should a company start with AI

With one process that has a measurable frequency and a verifiable result. Rolling out across every process at once usually ends as a pilot nobody uses.

Do we need our own model

Almost never. Solved problems such as recognition and image processing are covered by open models, and what should be yours is the part nobody sells, usually the logic on top.

How do we measure the benefit

In the same units as the cost: how often the process repeats per period and how long it takes now. Without those two numbers, two months later nobody can tell whether it improved or merely changed.

← All articles