There is a moment in every major technology shift when the conversation changes. The demo phase ends, the conference stage phase ends, and suddenly you are in delivery plans, architecture boards, cost reports, security reviews and team rituals.
That is where AI-assisted engineering is today. And if you are running an engineering organization right now, you know exactly what I mean.
At CROZ, we stopped asking whether AI will change software engineering about a year ago. We are asking the harder questions: how much productivity can we realistically gain, at what cost, with which tools, with what governance, and with what effect on the way our teams think and work? This is not theoretical for us, we are living it.
The real shift started when we moved from ad-hoc assistance to spec-driven, agentic development. Instead of asking an assistant to complete a line, we started giving agents enough context to work on complete pieces of functionality: requirements, architecture decisions, design documents, tests, constraints. When the context is good enough, the agent becomes part of the delivery system, not just a faster keyboard.
Every codebase is developing two layers now:
- The application layer: source code, APIs, infrastructure — is what we have always built.
- The agentic layer: prompts, specs, templates, hooks, orchestration logic – this part teaches AI agents how to operate on it.
This second layer is not a toy. It is becoming real engineering infrastructure, going through a transition similar to early CI/CD: from “useful addition” to “part of what professional engineering actually is.”
The efficiency gains are real, but so are the costs.
Token costs, infrastructure costs, model availability, security hardening – these are first-class engineering concerns now, not afterthoughts.
We run a hybrid setup: Jarvis, our internal AI platform built on self-hosted open-weight models, extended by frontier models from Anthropic and OpenAI when we need additional capacity or capabilities that open models cannot yet match. Part self-hosted, part external, always constrained by economics, security and pragmatism. From what we hear, many of our enterprise customers are converging on exactly the same reality.
This creates a new engineering habit: model choice becomes part of the work. The question is never “which model is best?” It is “which model is good enough for this task, at this point in the workflow?” Use your strongest models for shaping problems and designing plans. Use more cost-effective models for executing well-defined tasks. Use humans where judgment and accountability matter most. Cost, quality, latency and privacy are engineering parameters, not someone else’s problem.
The recent events around Anthropic’s Fable 5 (and possibly other similar frontier models in the near future) are a good reminder of why this matters. A single model should never become a single point of strategic dependency. These events confirm that hybrid setups, model diversity and workload-by-workload routing are in fact resilience patterns, and not just cost optimization techniques. In that sense, we could probably call it a good event in disguise: uncomfortable in the short term, but useful if it pushes us toward more sovereign and antifragile AI architectures.
Talk with the teams, share openly.
From a CTO’s seat, keeping the organization close together is more important now than it has been in years. The signals that matter – where teams are gaining real leverage, where they are burning time, where AI helps them think more clearly and where it helps them confidently go in the wrong direction – are not visible in dashboards. They live in code reviews, refinement meetings, and conversations on the shop floor.
It’s tempting to keep your AI experiments to yourself. I understand it. But in this phase of the market, the edge is not in having AI – everyone has AI. The edge is in learning faster, separating hype from value, and building engineering habits that actually scale. Sharing forces clarity, exposes weak assumptions, and brings back signals from people facing the same problems in different contexts.
That is one of the reasons for this newsletter.
The winners will not be the organizations that buy the most tools or generate the most code. They will be the ones that learn to combine human engineering judgment with AI leverage in a disciplined, economically sustainable way.
Build the system that builds the system.
Feel free to hit a reply on this e-mail and write your thoughts, concerns and small (and big!) wins. I’ll gladly connect and share our experiences.
The whole mechanism of trial & error is undervalued, by Nassim Nicholas Taleb
One of the highlights of QED 2026 was our conversation with Nassim Nicholas Taleb. In this special Walk your Talk episode, Taleb explores antifragility, tradition, risk, and why exposing ourselves to challenges is often more valuable than avoiding them. A thought-provoking discussion on how to thrive in an unpredictable world.
Implementing the Forward Deployed Engineer (FDE) concept
0800-DEVOPS by Ivan Krnić
Deployed Engineer (FDE) concept and what it takes to make it work in practice. Drawing on the BizTech mindset and inspired by recent thinking from Marty Cagan, our Director of Engineering Ivan Krnić shares why successful product organizations need people who can bridge technology, business, and customer needs.
Read the full blog post here.
