Five Engineering Decisions to Make Before Generating Code with AI

An engineer makes decisions either in code or before it. If the first question is handed straight to AI, the result will work, but its cost will already climb by the second release.

Vibe coding vs. engineering work

Vibe coding is a process where a person describes the desired result, asks for adjustments based on observation, and stops once the screen works. Engineering work with AI additionally accounts for the constraints of the existing system, permissible changes, failure conditions, and ways to verify the result. Code can be generated in both cases. The difference lies in which decisions were made consciously.

These aren't skill tiers — a junior developer can work the second way, and a senior one the first. What matters is experience that has turned into an understanding of dependencies. Once you've rolled back a release or untangled a race condition in a database, additional questions start showing up on their own in a new task — before the code and before the first bug.

For a prototype, a visual check might be enough. For a service with real users, a request like "add one more feature" is already changing a live system, and its cost doesn't reduce to generation time.

Five decisions to make before the first line of code

1. Integrations: define the boundary of the external contract

In a live product, this is often three separate services: A receives data from a provider, B implements the business rule, and C displays the result. If the external format has leaked into all three parts, a new provider means changing A, B, and C at once. If A converts the data into an internal contract, a new provider just means a new adapter — B and C don't change.

Example: a game catalog from two sources. The first describes a game as `{id, name}`, the second as `{code, title}`. The wrong approach is for consumers to know about both formats and pick the field based on the source type. Every new provider then adds a new branch to every function, and a year later no one can say how many places need to change. The right approach is for adapters to convert into a shared contract, `{key, title}`, so consumers know nothing about the provider. Adding a new source doesn't require regression-testing the whole system.

2. Multi-brand platform: define the boundaries of variation

Each brand on the platform was a separate product, not a copy of a template with a different logo. Each had its own licenses, markets, product teams, and release schedules. The requirement was to develop all of them on a single codebase while preserving real differences.

The initial model seemed sufficient: a base theme, overridden per brand where needed. The overrides spread beyond colors. The same task ended up solved differently in several places, local quirks piled up, and the styling lost its coherence.

The team had to move to SCSS mixins, with paths resolved in the brand's context at build time. For products already in production, that migration turned out to be more expensive than choosing the right model from the start.

3–5. Concurrent operations, topology, and delivery guarantees

A balance top-up hit by two simultaneous retries requires idempotency and clear transaction boundaries. A chat message surviving a restart requires defined storage topology and recovery. Deleting old data when a job runs late requires a defined time-to-live and safe re-execution. Shipping a release requires signals tied to the business scenario and defined stop conditions.

Experience doesn't translate into prompt length — it translates into specific questions asked during framing. A longer prompt by itself doesn't add anything. If a task is local and reversible, the framing can be short. If it touches a shared contract, a balance, or permissions, a couple of clarifying questions before implementation change the data model, the transaction, and the test scenario.