AI-assisted development.

AI reliably saves time wherever the right answer is known and a human can tell in seconds whether the result is right or wrong. That is not the exciting half of the work, but it is a large part of it. Four areas carry the gain.

• Scaffolding and repetition. Forms with validation, type definitions, configuration, recurring component skeletons, connections to a documented API. All tasks with a clear pattern and clear verifiability.
• Tests. The gain lies less in the happy path than in the edge cases — empty inputs, accented characters, time zones, double submission. A model patiently proposes twenty of them; a human writes five and then stops.
• Mechanical migrations. Moving a library version across hundreds of files following the same pattern, standardising a naming convention, replacing deprecated calls. Repetitive, error-prone for people, easy to verify.
• Documentation. Deriving a first description from existing code, describing an interface, drafting a handover document. The result gets edited, but it no longer starts from nothing.

The practical effect on a project is less "everything is twice as fast" and more "the distance between a decision and a visible result gets shorter". That changes projects noticeably: you see something sooner, you change something sooner, and we discuss a running system instead of a description. On landing pages and calculators and configurators the effect is clearest, because those are the places where many variants are worth trying.

AI costs time in understanding and repairing code you did not write yourself — and it costs more time the more familiar the project and the more experienced the person. This is the half of the story that rarely appears in sales conversations, and it is better evidenced than the time saving.

The cleanest measurement so far comes from the research institute METR. In a randomised trial published in July 2025, 16 experienced open-source developers worked through 246 tasks in projects they knew well. With AI tools they took 19 per cent longer than without. The remarkable part is not the number but the perception: the same people afterwards estimated they had been 20 per cent faster. Anyone who only feels their own time saving rather than measuring it errs in a predictable direction.

The Stack Overflow Developer Survey 2025 describes the same effect from the inside: 66 per cent of respondents name solutions that are "almost right, but not quite" as their biggest day-to-day friction; 45 per cent say debugging AI-generated code takes more time. At the same time, 84 per cent use such tools or plan to. Both hold: wide adoption, restrained trust — only 3 per cent describe the accuracy as highly trustworthy.

The most expensive category is subtle bugs. A model produces code that is syntactically flawless, behaves correctly in the normal case, and only miscalculates in one specific constellation — at a daylight-saving change, on an empty list, under concurrent access. Such errors survive a quick glance, because nothing looks broken. They surface later, in production, on somebody else's watch.

Because language models are optimised to write code that works, not code that resists attack — and on the surface the difference is invisible. The evidence here has become unusually clear.

In spring 2026 Veracode tested over 150 language models on 80 typical coding tasks in Java, JavaScript, C# and Python. Without an explicit security instruction in the prompt, only 55 per cent of results passed the security check. Broken down by vulnerability type the figures vary widely: SQL injection passed at 82 per cent and cryptographic handling at 86 per cent, while cross-site scripting sat at 15 per cent and log injection at 13 per cent. By language the range runs from 62 per cent for Python down to 29 per cent for Java.

The most instructive finding is the trend over the years: syntactic accuracy rose from roughly 50 to 95 per cent since 2023, while the security rate stayed practically flat. Better models therefore write working code more reliably, but not more secure code. That gap will not close on its own, because security is rarely derivable from context — it depends on who sees the data, what an attacker wants to achieve, and which obligations apply.

In practice that means the security-relevant components here — sign-in, permissions, input handling, processing of personal data under the revised Data Protection Act — are decided by hand, implemented with established libraries and checked separately. For operations, automated checks for known vulnerability patterns and outdated dependencies come on top. AI does not make that work disappear; the larger volume of generated code makes it more important.

Our process differs from the classic one in exactly one place: AI produces drafts, but every change goes through the same four checks as hand-written code. That sounds unspectacular and is precisely the point — the tool creates the gain, the procedure creates the quality.

• 1. Architecture by hand. Data model, module boundaries, interfaces and the question of what counts as the source of truth are decided before implementation and written down. A model optimises the next file, not the whole.
• 2. Implementation with tool support. Scaffolding, tests and repetition are produced with assistance; the load-bearing parts are read, often rewritten, always understood.
• 3. Review by a human. Every change is read by a second person who is allowed to reject it. Without that check the method runs away with itself.
• 4. Measurement in production. After launch, what counts is load time, error rate and Core Web Vitals under real conditions — not the impression on a development machine.

For you as the client that comes down to three concrete commitments: the code sits in your repository and is handed over with all credentials; there is an architecture overview another agency could read; and during the project we say which parts we consider stable and which we consider provisional. How we build larger systems from this is shown under complex web solutions; the regional implementation page is web design Zurich.

You reach something visible earlier and pay less for mechanical work — but the checking work does not shrink, it grows with the volume generated. Anyone quoting you a price built essentially on "the AI does that anyway" has left out the second half.

Realistically, three things shift. First, visibility: something clickable exists after days rather than weeks, which is why we deliberately schedule the first date on which you can operate something very early. Second, the cost of change requests: trying a variant is markedly cheaper than it was two years ago, which favours early course corrections. Third, the weighting inside a quote: less effort for typing, more for concept, review and verification.

Our price anchors are unaffected by any of it, because they attach to the result rather than the tool: a prototype for idea validation starts at CHF 10,000, a website sits between CHF 3,000 and CHF 25,000 depending on scope, and ongoing SEO starts at CHF 800 per month. What a specific project costs, we say after the first conversation; for a first bearing, use our project calculator, and for how website budgets are made up in Switzerland, see web design Switzerland.

AI-assisted development is the wrong answer when the real problem is not a development problem — and that is more often the case than the market admits. We say so in the first conversation, even when it argues against the commission.

• When the requirement is unclear. Building faster does not make an unclear requirement clearer; it only produces the wrong thing sooner. The first step then belongs in a conversation, not in a repository.
• When standard software is enough. For accounting, newsletters, appointment booking or a simple shop, proven products exist. Building your own pays off only once a workflow is genuinely singular.
• When nobody wants to carry the responsibility. Without a person who reviews and is allowed to reject, you get a system with no owner. That comes back at the first staff change.
• Under very high security or regulatory requirements. There the share of hand-written, verified and documented work stays high — the time saving shrinks accordingly, and that belongs honestly in the quote.
• In large, grown legacy systems. This is exactly where METR measured the counter-effect. We use the tools there selectively and in a limited way rather than across the board.

And the fundamental caveat: AI does not replace product understanding. A model writes what gets described — it does not ask whether anyone needs it. We ask that question before the first line of code, usually together with a prototype and a validation with real users. What we have built so far is in our work.