AI & Engineering

AI is transforming software development — here is what actually changes

SRSantiago RecobaFounder & Principal Engineer
March 20268 min read

The most useful thing we can say about AI in software development is also the least exciting: it changed specific parts of our pipeline a lot, and left others untouched. The parts that changed are measurable. The rest is mostly noise with good marketing.

What genuinely changed in our delivery

Requirements stop being a game of telephone

Requirements capture used to be a chain of conversations: stakeholder to analyst, analyst to ticket, ticket to developer, and somewhere in there a constraint quietly disappeared. Now we record the conversation, structure it into candidate rules and stories with an AI pass, and review the output with the stakeholder in the same session. The transcript and the spec are one artifact, and both are searchable six months later.

First-pass review is automated, second-pass is human

Every pull request gets an AI review before a person looks at it: naming, dead paths, missing tests, dependency risk, suspicious query patterns. That does not replace human review — it removes the boring half of it, so engineers spend their attention on architecture and behavior instead of commas.

Tests and documentation keep pace with the code

Test scaffolding and documentation drafts are generated from the change itself. The result is not perfect prose — it is a first draft that a human edits, which is dramatically cheaper than a blank page. This is where most of the “AI speed” clients notice actually comes from.

Where AI quietly adds risk

  • Confident wrongness. Generated code that calls APIs that do not exist, or uses a library version from two years ago. It compiles in the demo and explodes in production.
  • Silent regressions. Refactors that look tidy and subtly change behavior in edge cases nobody wrote a test for.
  • Security blind spots. Plausible-looking authentication flows with a missing check. Draft code follows patterns, not threat models.
  • Skill atrophy. If junior engineers only ever review generated code, they never build the mental model required to catch what generation misses.

The rules we adopted

  • A human owns every architectural decision. AI proposes, engineers decide and write down why.
  • Nothing merges without a human reviewer who can explain the change out loud.
  • Prompts and agent workflows get evaluation suites like any other logic: fixed inputs, graded outputs, regression checks when we change a prompt.
  • Client data stays inside agreed boundaries. No regulated data into a model without a contractual basis and a documented path.
  • We measure cycle time, not lines of code. Velocity theater is easy to generate and hides the only number that matters: how often we ship something that survives contact with users.

What it means for the teams we hire into

Adopting AI in delivery is not a tooling purchase. It is a set of habits: writing down decisions, defining “done” precisely, keeping the boring artifacts current, and resisting the temptation to let generated output skip review because it looks plausible.

Teams that get this right do not look faster in a demo. They look faster six months later, when the codebase still reads like a decision rather than an accident.

All insights
Work with us

Have a problem that keeps sliding to the next quarter?

Bring it to a 30-minute call with a delivery lead. Worst case you leave with a clearer plan, free of charge.

Ready when you are

30-minute call, no slides, no obligation.

Book a call