Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

What we changed about how we build in 2026

A short account of the three habits we kept from last year, the two we dropped, and the one we are still arguing about internally.

Category
Process
Reading time
5 min
Published
01 Jan 2026
Topics
Process, Delivery, AI

The turn of the year is a bad time to make promises and a good time to write down what actually changed. Here is the honest version for our studio.

Kept: a written scope before any code

Every engagement still starts with paid discovery and ends with a document that says what is in and — more usefully — what is out. Nothing we adopted in the last twelve months, including coding agents, removed the need for that document. If anything, it made it more valuable: a model works far better against a specification than against a conversation.

Kept: demos on a fixed day

Sprint demos happen on the day they were scheduled, working or not. A demo that shows a broken flow is information. A demo postponed to look better is a delay you find out about in month three.

Kept: cost per operation as a design number

Any feature that calls a model has a per-operation cost, and it goes on the same page as the acceptance criteria. Teams that discover this number after launch tend to rip the feature out.

Dropped: unstructured model output in product surfaces

We no longer let a model return free prose into anything a user reads as fact. Output goes through a schema, the schema is validated, and anything that fails validation is retried or shown as unresolved. This is dull and it is the difference between a feature that survives real users and a demo.

The interesting engineering in AI features is almost never the prompt. It is what happens on the failure path.

Dropped: the "AI sprint"

Treating AI work as a separate track produced features nobody owned. Model-backed work is now scoped, estimated and tested by the same team that owns the surrounding feature, using the same definition of done.

Still arguing: how much of the first draft should be generated

Some of us start every non-trivial module by hand and use a model to review. Others generate a first pass against a written spec and rewrite the parts that matter. Both groups ship at a similar pace, and the defect numbers are close enough that we have not called it.

What we agree on is the guardrail: nothing reaches review without a test the author can explain, and nothing merges because it looked plausible.

What this year is for

Three things: shorter discovery without losing its output, better instrumentation on model-backed features, and a testing practice that keeps up with how fast code now arrives. We will write up each of them as we go.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.