State of AI-Assisted Software Engineering

How 23 software engineers across 11 organizations are using AI to build production software

Gun.io Research | October 2026

Executive Summary

Artificial intelligence is changing how software is developed, but much of the public discussion still focuses on model benchmarks and speculative predictions about the future of engineering employment and what it could mean for productivity, in particular.

We wanted to understand what engineers are actually doing.

We examined the working practices of 23 software engineers with an average of around 20 years of experience across 11 organizations in Gun.io’s network, from early-stage ventures to established, leading enterprises. These organizations operate across healthcare, pharmaceuticals, aerospace, energy, manufacturing, enterprise software, workforce technology, and other industries.

The engineers perform full-stack development, backend engineering, frontend development, application architecture, platform engineering, and DevSecOps. We examined the AI tools they reported using, how they incorporate them into their workflows, and how they approach implementation and verification.

Three findings emerged.

1. The AI-native software engineer is already here. All 23 engineers reported using AI development tools, although their working practices differ substantially. Some use AI for research, boilerplate, and pair programming. Others use it to coordinate multiple agents executing development tasks concurrently.

2. The enterprise AI race is not the frontier model race. Claude is particularly prominent in our sample, but engineers also use OpenAI models, Grok, Gemini, and combinations of providers. Model selection reflects more than benchmark performance, including developer preferences, organizational policies, integration requirements, and available infrastructure.

3. The next engineering bottleneck may be verification. AI is expanding the amount of code engineers can generate and supervise, but organizations still need to establish that software is correct, secure, maintainable, and suitable for production.

These findings suggest that the relationship between engineering headcount and productive capacity may be changing. The relevant question is increasingly not simply how much code an engineer can write, but how much functioning, compliant software an engineer can responsibly deliver.

1. The AI-Native Software Engineer Is Already Here

All 23 engineers in our sample reported using AI in their development workflow. The more interesting finding, however, is how differently they use it.

Some engineers use AI primarily as a pair programmer, helping with implementation, research, and debugging. Others rely on AI for planning, code generation, testing, and review. A smaller number have begun orchestrating multiple agents to execute work concurrently.

One engineer has developed tooling to run Claude in isolated cloud sandboxes, allowing multiple development tickets to proceed in parallel, including overnight. Another uses a multi-agent system to coordinate implementation, testing, and code audits across several model providers.

These approaches represent different relationships between the engineer and the software development process.

In the first, AI accelerates work the engineer would otherwise perform directly. In the second, the engineer increasingly specifies, delegates, supervises, and validates work AI systems perform.

These differences are interesting because engineering productivity has historically been understood largely through headcount, experience, specialization, and available working hours. AI introduces another measure: how much work an engineer can effectively delegate while maintaining responsibility for the outcome.

We have not measured whether engineers using more autonomous workflows are more productive than their peers. But variation in working practices raises an important question for engineering organizations: should AI proficiency become an explicit dimension of technical evaluation?

2. The Enterprise AI Race Is Not the Frontier Model Race

The competition among AI companies is frequently framed around which provider offers the most capable model. Yet the engineers in our sample do not select their tools exclusively on that basis.

Claude is widely used, including through Claude Code, Cursor, and enterprise-provisioned environments. Other engineers use OpenAI models, Grok, Gemini, and combinations of providers. Some use different models for different tasks. Others work within company-approved development environments or use tools provisioned by their clients.

This suggests that model intelligence is only one component of enterprise adoption.

Organizations must also consider security, data governance, integration, procurement, reliability, and cost. Engineers themselves develop preferences based on how particular tools fit their working practices.

The result may be a market in which multiple model providers coexist, with organizations choosing among them according to workload and operating requirements, rather than standardizing exclusively on the highest-ranked frontier model. As models improve and their capabilities overlap, this will be a key point to remember: models should be selected based on the right tool for the job, the roles they play in a workflow, and their ability to adhere to standards and practices.

For enterprises, the objective is not necessarily to procure the most intelligent model available. It is to procure intelligence and best practices that can be used productively within the organization’s technical and economic constraints.

3. The Next Engineering Bottleneck May Be Verification

AI is making software easier to generate, but generating code and delivering reliable software are different activities.

If AI reduces the effort required to implement functionality, engineering organizations may find that a larger share of their work involves specifying what to build, verifying its behavior, integrating it with existing systems, and maintaining it over time.

Several engineers in our sample described explicit verification practices. These included mandatory human code reviews, manual testing of AI-assisted implementations, automated code audits, security scanning, and production validation.

This shift in where engineers add the most value and how efficiently they work has several possible economic consequences.

As software becomes cheaper to produce, organizations may choose to build more of it. Applications that previously could not justify their implementation costs may become economically attractive, creating additional requirements for maintenance, integration, and oversight.

The total demand for engineering work therefore cannot be inferred from the declining cost of code generation alone. AI may reduce the labor associated with some implementation tasks while increasing the value of engineers who can exercise architectural judgment and take responsibility for complex systems.

4. Implications for Engineering Organizations

Taken together, our observations suggest that engineering organizations should reconsider how they evaluate technical talent, select development tools, and measure productive capacity.

• An engineer’s ability to write code remains relevant, but so does their ability to structure problems, supervise AI-generated work, recognize defects, and deliver functioning systems.
• Model selection should be treated as an engineering and organizational decision, not a simple comparison of benchmark rankings.
• Investment in testing, review, security, and production reliability must keep pace with improvements in implementation speed.

None of these observations establishes that organizations need fewer engineers or that particular categories of engineering work will disappear. The sample does not contain the productivity measurements necessary to support those conclusions. It does suggest that traditional assumptions about engineering capacity deserve renewed scrutiny.

Conclusion

The AI-assisted software engineer is no longer hypothetical.

Across the engagements we examined, engineers are already using AI to research, implement, review, and coordinate software development. The extent of that delegation varies, as do the models and tools involved. What remains less clear is how these changes will affect engineering productivity, organizational structure, and the economics of software development.

The most consequential shift may not be the declining cost of writing code, but the changing relationship between engineers and the software they are responsible for delivering. As AI expands the amount of work an individual can perform or supervise, the ability to exercise technical judgment and establish the correctness of that work may become increasingly important.

The question is no longer whether AI will become part of software engineering. For all of the engineers we examined, it already has. The question is what happens next.

Methodology

This report is based on qualitative descriptions of AI development practices provided by 23 engineers working across 11 Gun.io client organizations in October 2026. This represents a small fraction of work done by Gun.io engineers across our client base.

The participating engineers work across multiple industries and technical disciplines. Their reported tools include Claude, OpenAI models, Grok, Gemini, Cursor, GitHub Copilot, and internally developed agent orchestration systems.

The sample was not randomly selected and is not statistically representative of the broader software engineering workforce. Participants self-reported tool usage and working practices. We did not independently measure productivity, code quality, or financial outcomes.

Organizations range from early-stage ventures to established, leading enterprises. We have not independently established individual experience ranges for the full cohort, but we estimate a minimum of approximately 20 years of professional software development experience.

Examples have been anonymized to avoid disclosing client-specific technical practices.