What we have learned. No marketing.

Code generation is not software engineering.

Code is deterministic. Requirements are not.

A computer runs code exactly. People rarely know exactly what they want, and when they do, they can't state it precisely. AI today writes flawless code from a specification. It can't tell that the specification makes no business sense. Translating messy human reality into a deterministic structure is still the real work. Generation hasn't shortened it.

The illusion of local correctness

Every generated function is syntactically correct and passes its unit test. That guarantees nothing about the whole. A system built from thousands of “correct” pieces can collapse on unexpected interactions between them: in security, in performance, in data. Architecture isn't generated one function at a time. Someone has to hold it in their head.

What changes in the engineer's role

Writing syntax is losing its value. What remains is what the model won't do on its own:

• Understand the domain and what the client actually needs. Often something other than what they say.
• Write the boundaries: rules, test scenarios, security policies, architectural limits the agents are allowed to move within.
• Guarantee that the whole works. Not that the individual pieces passed.
• Decide what shouldn't be built at all. With AI there will be an order of magnitude more code, and every line is a future maintenance cost and a security risk.

What this means for you as a buyer

A vendor selling generation speed is selling the cheap part. Ask who holds your architecture, who writes tests against business rules, and who will tell you a feature makes no sense. We use AI to the fullest. Decisions and accountability we haven't handed to machines, and we won't.

“Humanity is not ready to absorb all the software it can generate by machine. That makes it all the more important to build only what makes sense.”

Don't buy apps without the source code. You wouldn't buy a house without the bricks.

How it usually ends

Two years into production, the buyer reads the contract and finds out the source code isn't theirs. They paid for the development of a product the vendor owns. Every change goes through the vendor, at their price, on their schedule. A framework upgrade the docs put at thirty minutes is quoted as a month-long project for three developers, a project manager, and a tester. The client is a hostage.

What truly owning software means

• An exclusive license to the code, or outright ownership. In the contract, not in a promise.
• Repository, build, infrastructure, and credentials in your hands. Not on the vendor's account.
• Code anyone new can understand: a team member, another vendor, a competitor.
• A minimum of technologies and no proprietary vendor framework without which nothing runs.
• The option to take development in-house at any time and terminate the contract.

The 2026 variant: you have the source, but nobody understands it

A new form of the same problem. You generated the app yourself, or someone generated it over a weekend. You have the source code. But nobody knows what it does, nobody vouches for it, and nobody dealt with security or compliance. Ownership without understanding is just paper. That's why, on apps we take over, we start with tests that pin down the behavior, and only then do we change anything.

How we do it

We always license the source code to our clients. We write it so anyone new can understand it. We keep the number of technologies to a minimum and pick those with a future. There is no greater joy than seeing a fellow engineer quickly grasp how a thing works, and software that runs for years.

“The vendor that matters to me is the one who thinks on my behalf, not the one trying to catch me out.”