LLM-first development: What actually changes for software companies? — three part webinar recap

We recently completed a three-part webinar series on LLM-driven software development with AI Empowered Devs community. The first two sessions focused on engineering workflow and architecture. The third session shifted the conversation toward business implications.

This article is not meant to summarize the recordings in detail. Instead, I want to extract the structural changes that became visible when looking at development through an LLM-first lens.

Because tweaking and improving your prompting techniques will only get you so far. The real change runs deeper than that – it’s a fundamental shift in mindset, for both individuals and organizations.

I used our newly launched Queast service as a practical example of how to write reliable software with LLMs. Queast is a good challenge from an engineering perspective, as it combines large data, intelligent signal generation, various different LLM integrations, and much more to provide actionable buying signals for IT service companies.

The engineering shift: From writing code to shaping systems

In the first session, we walked through a practical LLM-first workflow that I use myself. The takeaway message is simple: structure matters more than model capability.

If your architecture is modular, your boundaries are explicit, and your guardrails are executable, LLMs perform well.

If your codebase is organically grown and loosely structured, you simply generate confusion faster. Over time, it becomes chaos you can no longer manage. 

This leads to a subtle but important shift. The bottleneck is no longer typing speed or API familiarity. It is:

• • How well you decompose problems
  • How clearly you define module boundaries
  • How do you enforce invariants through tests and CLI proofs
  • How precisely you define “done”

You can find the recording below or from this link

Code is becoming a commodity

The second session is targeted at software engineers quite purely. We went deeper into executable guardrails: test policies, file length constraints, documentation discipline, proof-based validation, and multi-agent orchestration. These are not cosmetic practices. They are structural enablers.

LLM-enabled developers should love clarity, boundaries, and strict tests.

One observation from the live demos surprised some participants, but felt inevitable to me:

Code is increasingly disposable.

If a feature branch becomes convoluted, it is often faster to discard it and regenerate with tighter constraints than to untangle it manually. That changes how we think about ownership and permanence.

When code production cost is nearing zero, the real value moves elsewhere:

• Domain understanding
• Product “sculpting”
• Integration discipline
• Risk assessment
• Business alignment, especially regarding communication

This does not eliminate engineering skill. It changes where that skill is applied.

Video below or from YouTube.

The business question: Margin expansion or margin collapse?

The roundtable discussion focused on the business model implications, mainly for IT service companies. The primary question was, if development time compresses significantly, what happens to companies that sell hours?

The panel was largely aligned: this is less a margin expansion and more a business model reset. If your pricing is directly tied to developer hours, increased productivity creates tension. Either you lower prices, or you justify higher margins through value-based framing.

In the new world order, selling purely time becomes structurally fragile and clearly has an expiration date.

Selling outcomes becomes structurally necessary.

This is not theoretical. It follows directly from incentive mechanics. If the market knows delivery speed has improved, tolerance for long timelines decreases. Expectations adjust quickly once visibility increases.

Organizational inertia is the real constraint

Interestingly, none of the panelists identified technology as the main blocker.

The recurring themes were:

• Middle management resistance
• Procurement structures
• Identity challenges among senior engineers
• Slow organizational redesign

The technological change happens much faster than the operating model and the capability of different organizations to adapt. 

This lag creates a temporary asymmetry. Smaller companies may move faster because they have fewer internal constraints. Larger companies retain advantages in trust, procurement relationships, and enterprise sales capability.

The outcome is unlikely to be binary. More likely, we will see specialized, smaller players collaborating with established incumbents, each compensating for the other’s weaknesses.

You can access the recording below or from here.

What changes for engineers?

There is understandable concern about roles.

My own view is that we may see short-term contraction in certain types of roles – particularly those centered around implementing well-defined code changes without broader domain ownership.

At the same time, the demand for engineers is unlikely to decrease in mid- to long-term, who:

• Understand systems holistically
• Can decompose ambiguity
• Can define guardrails
• Can reason about business trade-offs.

Personally, I believe that in  2026 and 2027, we will see a hiring slump due to wider AI adoption.

Engineers are turning into “product sculptors”, “LLM orchestrators”, or “virtual team leaders”. For some, this is not a downgrade, but it might not be considered exactly an upgrade either. We are stretching the human context window a lot with this transformation. 

A more structural view

After these three sessions, my position is clearer:

1. The engineering shift is real but manageable with discipline.
2. The current models and tooling combination already allows to shift over 90% of the code writing to LLM’s. 
3. The pricing shift is more disruptive than the tooling shift.
4. The organizational redesign challenge will outlast the hype cycle.
5. The companies that rethink incentives early will have an advantage.

In order to succeed in turning the LLM posed existential threat into an opportunity, it’s not enough to transform engineering.; Tthe business model and the entire organisation along with it need to go through a transformation, which can at times be painful.