Abel Soares
Head of Engineering
Tools & Workflows
Technology
Updates & Culture
Reading time: ~8 min
Every week there's a new post about AI transforming software development. Teams shipping 10x faster. Engineers replaced by agents. Development costs collapsing overnight.
I've been running engineering at Untile for a while now. We're 37 people and we've been building digital products for 17 years. In the last twelve months we went through a real transition, and I want to describe what that actually looked like. Including what it cost. Including what we got wrong.
If you're a founder or CTO thinking about this right now, the honest version is more useful than the polished one.
The decision we faced
When AI tools started producing genuinely useful output in software development, we had a choice I think most engineering leaders are facing right now: move fast and risk the quality standards that took years to build, or move slow and fall behind a market that isn't waiting.
We chose to move. But we had a constraint we weren't willing to give up, we had to be proud of what we shipped. Not proud in a vague cultural sense. Proud in the sense that we'd stand behind the code, the architecture, the decisions. That constraint shaped everything.
The first thing it forced us to confront: AI tools are only as reliable as the structure around them. Which meant the transition was never really about the tools.
The real investment
The most common mistake I see in how people talk about AI in engineering is treating it as a tooling decision. Buy the right subscriptions, give engineers access, watch productivity go up.
That's not what happened for us. I doubt it's what happens for most teams that end up with something durable.
The real investment is in documentation and standards. Specifically, building the kind of precise, structured specifications that AI-assisted development needs to produce reliable output. That's a higher bar than what most teams are used to writing.
Before this transition, our requirements process was lean by design. A few pages of context, some product discussions, and we'd start building. It worked because the understanding lived in conversations between experienced people who knew the codebase.
AI can't work from that. It needs the understanding written down, in detail, in a format it can actually reason about. We went from two-page briefs to thousands of lines of structured specifications: PRDs, architecture decision records, API contracts, detailed component specs. That documentation became the foundation everything is built on now.
Building that capability took longer than integrating any of the tools. Writing specs that are precise enough to produce reliable AI output, without being so rigid they slow everything down, is a skill that develops through a lot of iteration. We're still improving at it.
The cost that doesn't appear in a budget
Product managers now write more extensively and more precisely. Engineers spend more time reviewing and less time implementing from scratch. The nature of the work shifted.
One of our developers described it as going from spending 80% of his time programming to spending 80% of his time reviewing what AI produces and thinking about architecture. That's not a worse job. But it is a different job. And the transition period — while everyone is still adjusting — is slower than either the old way or the new way you're heading toward.
That cost is real. It's worth planning for, because it doesn't show up as a line item.
On tooling
The AI tooling landscape changes fast enough that committing to specific tools at the organisational level is a liability. What's the leading option today might be deprecated or superseded in three months. We made a deliberate decision not to impose tools top-down.
Engineers use what works. Claude Code, Copilot, Cursor, various frameworks. Whatever produces reliable results in practice. Our job as a leadership team isn't to pick the tools, it's to build the rails that let any tool produce output that meets our quality bar.
Those rails are the specs, the standards, and the quality controls. When they're solid, the tool choice becomes almost secondary. When they're not solid, no tool fixes the problem.
What we kept, and what we had to build
Everything we had before is still in place. Linting, code reviews, integration tests, infrastructure as code, security guardrails. The instinct to relax controls because AI is doing more of the work is wrong. If anything, controls matter more when more of the code is generated rather than written by the engineer who's accountable for it.
But new controls also had to be built: hooks, validation frameworks, custom standards to make sure AI output integrates cleanly into our pipeline. That infrastructure is ongoing. It's where a significant portion of our engineering investment is going right now, and it's not glamorous work.
What we got wrong
I want to be specific here, because the version where every decision was right isn't useful to anyone thinking about doing this themselves.
Early on, we produced documentation that was structured for LLMs but hard for engineers to actually use. Dense, technical, written to feed a model rather than communicate intent. We caught it because the engineers pushed back, which is the right outcome, but it meant time we hadn't planned for. We iterated until we had specs that work for both: readable by people, structured enough for models.
We also underestimated how much the shift in daily work would require active support for some engineers. Moving from implementation-focused work to specification and review work is significant. Most of our team made the transition well. For some it took longer, and in the interim their output was slower rather than faster. A transition plan that accounts for that is worth building before you need it. We built it after.
What this means if you're deciding now
Buying tool access is fast. Building the specification standards that make those tools reliable takes months. The teams that invest in the standards first end up with something durable. The teams that invest in the tools first often end up with inconsistent output and a quality problem that's harder to fix once momentum has built around the new way of working.
This is also not a project with an end date. The AI landscape will keep changing. The tooling will keep evolving. What doesn't change is the need for precise documentation, reliable quality gates, and engineers who understand what they're responsible for, regardless of what generated the code they're reviewing. Build for that, and the specific tool choices become much less consequential.
Where we're heading
Our goal for 2026 is to push more of the mechanical parts of the pipeline further toward automation. Faster feedback loops. Guardrails that are consistent enough that reviewing AI output becomes a routine check rather than a deep review. A pipeline that moves from specification to production with less friction at every stage.
We're not replacing engineers. We're changing what engineering work means. More architecture, more structural judgment, less repetitive implementation.
Whether the industry lands on that as the right model will become clearer over the next few years. What I'm confident about: the clients who are thinking seriously about who they work with on software development are already asking whether their partners build this way. That question is only going to get more common.
Being able to answer it honestly, with specifics, and with an acknowledgment of what's still being figured out, is worth more than a polished story that hasn't actually played out.