The state of the tech industry in 2026 - LDX3 New York

Gergely Orosz frames this talk around visits and conversations inside AI labs, large technology companies and startups. He organizes the material into what changed, what remained, what broke and what may come next.

That framing matters. A pattern visible in frontier organizations is useful evidence about possible directions, but it is not a representative survey of every software team. Product names, adoption figures and migration timelines belong to the talk’s recording period; the article treats them as attributed observations rather than a live market inventory.

Orosz describes engineers increasingly prompting, checking and coordinating several agents instead of spending all their time typing one implementation. Some interviewees run multiple worktrees and sessions, so local keyboard activity is no longer the only limit on concurrent work.

He also sees interfaces shifting from heavyweight IDEs toward agent-oriented workspaces and chat entry points. This is not proof that every IDE has disappeared or that every engineer should copy a five-to-ten-session setup. More parallel execution creates a new coordination and attention problem, which the talk returns to later.

The talk lists many organizations building internal harnesses or extending existing tools. The recurring reason is access to company-specific data, environments and workflows. A request in Slack can become a coding task because the agent is connected to the systems that make the request meaningful.

Orosz describes software-factory loops where production observations or other agent outputs can lead to a pull request. He explicitly says these systems are not fully automated, with human review still relevant for critical or wide-impact changes. The useful distinction is between a closed loop with checks and the much stronger claim of unattended production ownership.

Several examples concern language or test-framework migrations that teams reportedly completed faster with AI assistance. These are substantial changes, not merely swapping a package name, but their scopes and starting conditions differ.

Orosz includes an important qualification in the Asana example: the short final migration followed years of prior effort. A final execution window cannot stand in for the entire cost of preparation, validation and rollout. The examples suggest that some previously deferred work has become more feasible; they do not establish a universal conversion rate from years to weeks.

Vendor and platform data in the talk show growth in agent-created tickets, pull requests and skill usage. Those measurements describe particular systems and cohorts. They say something about activity, but do not by themselves measure correctness, customer outcomes or the share of the entire industry using the same workflow.

The cost discussion has a similar distinction. Routing and open-model investment may reduce unit costs or help contain spending, while rising usage can still change the total bill. The organizational question is what useful work a system delivers for its cost, not simply how many generated artifacts it produces.

Orosz sees individuals crossing former technical specialties and handling projects with fewer people. Yet he separately emphasizes that teams still own software, on-call duties, quality standards and continuity when someone is away.

These statements are compatible: a one-person implementation project does not replace the enduring team responsible for a service. The talk’s claim that non-engineers are not independently shipping production code also needs its scope: asking a bot to open a change differs from approving and operating a release. Company anecdotes should not become a universal statement about every organization.

13:05View full image

Complex infrastructure still needs planning, team alignment and customer communication. Building the wrong thing faster remains waste. Orosz also stresses tests and other validation methods as ways to earn trust in generated code.

He notes renewed interest in older engineering ideas such as tracer bullets and deep modules. Their value is not that a phrase magically fixes a model, but that the idea supplies a useful structure for implementation and judgment. Faster generation changes how work is performed, without settling whether the result is correct or worth maintaining.

Orosz warns about review theater: the appearance of approval when the volume of changes makes careful review difficult. He also reports software-quality problems and infrastructure-capacity pressures, including CPU availability in some settings.

These observations are not a controlled demonstration that AI caused every outage or that every cloud region has the same shortage. Nor do they justify abandoning review wholesale. They point to the need for validation and review effort matched to risk, alongside realistic capacity planning and attention budgets.

One engineer in the talk describes the initial excitement of completing tasks faster, followed by parallel work becoming the new baseline expectation. An agent waiting for a response can repeatedly interrupt focus even while other work continues.

Orosz’s conversations with engineering leaders add several pressures: unrealistic expectations, business uncertainty, changing team sizes and burnout. This is a selected set of interviews, not a diagnosis of every leader or a forecast of every job. The operational lesson is to count coordination and recovery costs alongside generated output.

Looking ahead, Orosz expects more cloud harnesses, evaluations in delivery pipelines and agents involved in operations. He contrasts isolated personal automations with systems that reduce handoffs and friction at team or company level, starting from a business outcome.

These remain predictions and recommendations, not blanket permission to deploy unread code or treat migrations as risk-free. His closing emphasis is hands-on learning and domain judgment: knowing what matters and helping others act can become more valuable as implementation gets cheaper. The talk invites experimentation without proving any career is future-proof.

26:10View full image