What we use it for
We have done websites for a long time and watch every pixel in them. The harder things, portals, records and integrations, we used to outsource, and the result looked different from what we designed. Today we build them ourselves, and AI is one reason that works: it took away hours of mechanical work we did not have to spare.
It helps most where the work is mechanical: turning a data model into migrations, handling error states, test data, turning a finished design into code. Those are hours that move nobody forward and still get paid for.
The difference is who goes through the result line by line.
Where we do not let it decide
Typography, spacing, button states, how a form behaves on error. A model guesses those from the average of what it has seen, and average is exactly what we want to avoid. So we tune the interface ourselves and against real content, not against placeholder text.
Three lines we hold
- Decisions about the interface stay with a person. The model may propose options, the team picks.
- The data model and permissions we review by hand and cover with tests for each role.
- We stand behind the running system. When something falls over, it does not matter which tool wrote it.
What the result goes through before you see it
This matters more than which tool wrote what. Code from a model and code from a person take the same route:
- Reading it line by line. Not for syntax errors, the compiler finds those, but for whether the code does what we meant rather than something similar.
- Tests for what must never happen: a seat sold twice, a role that can see someone else’s data, a form that submits without a required field.
- Checking against real content and real data, not sample text. One long name and one empty list reveal more than ten pretty screens.
- Decisions that cannot be undone, the data model and permissions, are drawn before the first line is written.
A model is fast at what has been done somewhere before. That makes it good at migrations, error handling or test data, and poor where the job is to choose between two sensible options based on how your company works. There it needs somebody who knows that company.
A simple rule for production
What can be verified by a test can be written by AI. What is only recognised by eye or in production we write ourselves. Interface design, the data model and security therefore stay with us; the rest is a question of speed.
We check this on our own products before offering it to a client. Walio we run and keep developing; WCRM is work in progress: sign-in and the database run, screens are being connected and the import from Scrapik is still being built. So we know which shortcuts paid off and which we paid for later.
What it means for the client
A shorter path from brief to first version and more room for detail, because mechanical work takes fewer hours. It does not narrow our responsibility: we review and test the code just as before.
What does not change is the price of thinking. Deciding how the system should work takes as long as before. That is exactly where it shows whether the result holds up.
For you, that means a faster path to a first version you can verify, not automatically a lower price. Scope, security and the result are still decided by the team.
