In a landscape flooded with AI hype – from low-code shortcuts to intelligent copilots -there’s growing pressure on engineering teams to move faster than ever. But what if we’re accelerating the wrong thing?
Sasha Slankamenac, principal engineer at Dariel, believes that while AI-augmented engineering has its place, it cannot replace the hard, often uncomfortable discipline of thinking. “If you’re not careful, AI becomes a very efficient way of producing the wrong thing,” he says. “And in engineering, doing the wrong thing faster is not a win.”
It’s not about what AI can do
For Slankamenac, tools like GitHub Copilot or ChatGPT are “force multipliers” – but they don’t fundamentally change the nature of good software design. “You can absolutely generate a lot of code quickly, but the question is: do you know what you’re solving? Do you understand the trade-offs? That’s where engineering still lives.”He’s quick to point out that speed alone is not
velocity. “Velocity without direction is chaos. If your requirements are vague or your domain isn’t well defined, AI can’t save you from that.”
The real work happens before the tools kick in
The root of this philosophy lies in what Dariel calls “staying in the problem space longer.” It’s a concept echoed across the company’s engineering culture: resist the instinct to jump straight into solutions. Pause. Define. Think.
This pause matters. “The discipline to stay in the problem space results in a much better refinement of the actual problem. In turn, the solution options become clearer, more robust and better aligned with the business need.”
Cognitive load is real, Slankamenac says, and the pressure to move fast is constant. But slowing down is what makes better decisions possible – and avoids the kind of over-engineering that plagues rushed development.
The trade-off mindset defines engineering
Software engineering is about constraints and choices. Slankamenac puts it plainly: “The best engineers are hired to think and solve the problem, not just code.”
That’s why Dariel focuses on architectural clarity before tooling up. Good engineering, Slankamenac explains, is the result of being deliberate about trade-offs – not chasing efficiency for its own sake.
AI-assisted does not equal AI-led
One of the more controversial points Slankamenac raises is this: “AI doesn’t actually understand anything. It doesn’t know your context, your constraints or what matters to your business. You do.”
This is why Dariel sees AI as an assistant, not an architect. “We’re not interested in AI replacing thinking. We’re interested in AI supporting better engineering decisions,” he explains. “It can scaffold out boilerplate, highlight potential bugs, or speed up certain grunt work – but the decisions still rest with us.”
In Dariel’s view, the value of AI is unlocked when it’s paired with clear business alignment, deep domain understanding, and well-scoped engineering work. “If you’ve done the hard thinking upfront, AI can absolutely help accelerate delivery. But it’s not a shortcut for that thinking.”
Why we’ll never catch up
Slankamenac reflects on the perpetual chase: “AI and software generation have always outpaced our ability to fully grasp them. Since the 60s, we’ve been in a cycle where tech speeds up and we scramble to catch up. That’s not new.”
Today’s tools are just the latest layer in that cycle. But that’s why grounding in fundamentals matters. Slankamenac warns that treating software purely as a cost line -something to automate away – is short-sighted. “You can’t eliminate thinking with tooling. You can only hide the complexity – and that doesn’t make it go away.”
Culture is the constraint – and the opportunity
So what’s the biggest bottleneck to delivering AI-augmented software at scale? It’s not tools. It’s mindset.
“Engineering culture needs to catch up with the tools,” says Slankamenac. “We have to train engineers to question more, not code faster. That means pushing back on ambiguous requirements, challenging solution bias and creating room for better conversations.”
The bottom line
AI can’t replace engineering. It can only augment the people who already do it well. And the ones who do it well? They’re not rushing to ship code – they’re slowing down to get it right.
“If the domain is clear, if the thinking is sound, if the architecture has been well-considered – then yes, AI can help you go faster,” Slankamenac says. “But that’s a big if. And it starts with staying in the problem space just a little bit longer than feels comfortable.”