Pauliina: Vesa, we’re hearing a lot about agentic data engineering. Some see it as just “extra hands” for a team but you seem to be talking about something much more structural. Is this just about making the “black box” of data work a bit faster?
Vesa: It’s a lot more than just adding “extra hands,” Pauliina. Earlier, we were just using LLMs as a better autocomplete, basically “LLM-enhanced” coding. But we’ve moved past that. We aren’t just using AI to explain or enhance the “black box”, we’re using agents to build the box, fundamentally changing how we design and deploy data platforms.
Instead of asking an agent to write a single SQL function, we’re saying: “Here is a raw API, here is our target Medallion architecture and here are our security standards. Now, build the end-to-end pipeline and the Infrastructure as Code (IaC) to support it.” The agent doesn’t just copy-paste, it reasons through the architecture, ensuring integrity and compliance from the start. The human isn’t the one digging anymore, they are the site foreman, strategically overseeing the work and ensuring everything goes according to the broader plan.
Pauliina: That “site foreman” analogy is interesting. But does it actually scale? Competitors often mention something like “15-20% productivity gains,” but you’ve mentioned much higher numbers. Is that realistic, or is it mostly manual cleanup in the end after the agent is “ready”?
Vesa: When you go fully agentic, some parts of the work become almost trivial or disappear altogether, and in certain cases we’re seeing 10–20x speed‑ups in well‑defined tasks. For example, in one real project a defined set of sprint tasks was completed about 17x faster than the team’s usual baseline. Take a senior engineer setting up infrastructure: that could have been two weeks of Terraform debugging, but now an agent can handle the boilerplate and environment configuration in an afternoon.
The agent takes care of the toil, the repetitive integration logic and unit tests, allowing the engineer to focus on the high‑level logic. The same applies to creating a data model, building a user‑facing dashboard or front‑end, or automating parts of project and product management, like issue tracking and refinement workflows, so there are fewer handoffs and less coordination overhead.
Pauliina: What about migrations? People talk about using AI to compare old and new tables to find differences. Is that the limit of what agents can do for legacy tech debt?
Vesa: Comparison is the easy part. Where it gets interesting is Agentic Migration. We’re running projects where the agent doesn’t just compare results, it translates the logic. It ingests messy legacy stored procedures and ETL scripts, builds a picture of the dependencies and business rules, and then proposes a modern, modular design in the target platform. From there it generates the new code, plus the validation tests needed to prove the behaviour matches. We’re essentially enabling autonomous agentic exploration. Not just an enhanced chatty friend, but a sparring partner that can propose real solutions. We’re turning what used to take years of painful manual work into a more predictable, faster migration.
Pauliina: When you say the agent “translates the logic”, what does that actually look like day-to-day? Are engineers still rewriting code, or are they mostly reviewing?
Vesa: In a good agentic migration, the agent owns the grunt work and the engineer owns the judgement calls. The agent proposes a target design and generates the code. The engineer reviews that proposal: Does the structure make sense? Are we carrying over bad patterns? Are there security concerns? When a test fails, the agent iterates on its own code until it passes the quality gates. Instead of spending months on line‑by‑line porting, the team spends its time deciding where to stay compatible and where to deliberately improve the design.
Pauliina: This sounds like we have a Ferrari of an engineering engine. But I still see organisations struggling to get products into production. Why is there a gap between engineering speed and business value?
Vesa: That is the systemic inertia problem. We’ve built a Ferrari, but the rest of the organisation is still running on a horse‑and‑buggy process. We’ve paid down the technical debt, but we’ve uncovered process debt: reviews, approvals and ways of working that were “good enough” before, but now limit collective velocity. You can generate a new dashboard or microservice in a day, but if sprint reviews only happen every second week, business requirements are vague, or UAT is mostly manual, the work just waits in a queue.
Pauliina: So, how do we fix the “horse and buggy” side? How do we modernise the process to match the engineering speed?
Vesa: At Solita, we’ve seen that unlocking this collective velocity means looking at the whole data value chain, not just developer tools. It’s not just about acquiring more AI licenses it’s about addressing fundamental questions like:
- How to bake “guardrails as code” into the agents. Compliance shouldn’t be a meeting, it should be a real-time check integrated into the agentic workflow ensuring regulatory adherence at speed.
- How to move from “Project” thinking (milestones and big reveals) to “Product” thinking (continuous, rapid iteration), so teams can ship value faster.
- How to integrate AI agents as “developers” to continuous development workflows and act as independent engineers that suggest improvements on their own for the given business context through test passing and human reviewed and/or finalised pull requests.
- How to keep design and business requirements at least one sprint ahead of development, so teams aren’t waiting for clarity and changes can be absorbed continuously instead of in big, slow review cycles.
To really kill process debt, we need to move the “builders” closer to the “mission.” We’re moving toward a model where engineers are less back-office builders, they are forward-deployed, working directly inside business units to identify problems and deploy agentic solutions when needed. This eliminates the “translation lag” that usually slows down data development.
Pauliina: It sounds like the message is: don’t just look at the tools your developers are using, look at the hurdles the organisation has placed in their way.
Vesa: Exactly. If your governance and feedback loops aren’t as agile as your engineering team, your productivity gain will just turn into more time spent in meetings. Identify your bottlenecks, automate what is possible and get ready to move at the speed your engineering teams are already capable of.
Is your organisation ready for the agentic shift?
While the technical barriers have been broken, the persistent challenge of “process debt” remains across the entire end-to-end flow, from use case discovery and business requirements through design, development, project management, testing/UAT and operations.
If you’re ready to move beyond talking about AI to actually getting more products into production, connect with our experts today. We can help you identify and dismantle these bottlenecks, modernising your data value chain so work moves at the same speed as your tools.
