Software Engineers Excel AI

This panel explores how artificial intelligence is reshaping software development, and how software developers and engineering leaders need to become adaptable and resilient in the age of AI. This TensorBlue analysis is based on reporting and source material from InfoQ (https://www.infoq.com/articles/software-engineers-excel-AI/).

What Happened

InfoQ Homepage Articles Virtual Panel: How Software Engineers and Team Leaders Can Excel with Artificial Intelligence

Virtual Panel: How Software Engineers and Team Leaders Can Excel with Artificial Intelligence

AI impacts the way that software is being developed. We can use AI to automate repetitive coding tasks and boost productivity, while maintaining human oversight and implementing guardrails to ensure code quality.

To cope with the challenges and exploit the opportunities of artificial intelligence, we need to equip developers with foundational AI/ML knowledge, prompt engineering skills, and critical thinking skills to evaluate and manage AI-generated outputs.

Engineering leaders leverage software teams by encouraging collaboration between developers and AI tools, fostering a clean code culture, and establishing governance frameworks for responsible AI use.

Companies can promote resilience through psychological safety, open communication, transparency about AI strategies, and ongoing opportunities for upskilling.

To keep software development sustainable and ensure the mental well-being of software developers and team leaders, companies should address AI-related anxieties by positioning AI as a supportive tool, reinforcing job security, and giving developers time and space to adapt.

Artificial intelligence is now generally available and is being used by many softwar

Courtney Nash: From what we hear in the media and product pitches, AI is making development seemingly quicker and more productive (though the jury is still out on this objectively), but in doing so it is adding unforeseen complexity and the likelihood of unexpected surprises later on. This addition of complexity is in part due to our inability to peel off the top of the AI black box and see how or why it’s doing what it’s doing. We can’t inspect how an AI arrived at the code or solutions that it did, and AI tools can’t model the broader complexity of systems, with which they may interact without awareness. This knowledge is most critical when things don’t go as planned. When AI-generated software fails, how will we know where to look, or what to investigate when trying to stop the bleeding and get things back up and running and learn from what happened and feed that back into the system? When it comes to AI and automation in software systems, my research focuses mainly on our own mental models of these tools. This research tends to view AI as a way to replace human work, rather than supporting and augmenting it. These mental models create unrealistic dichotomies ("Machines are better at these tasks/Humans are better at those tasks") that don’t reflect the realities of software development for today’s modern complex systems. Research from other domains has shown that automation (and now, AI) is built on a "substitution myth", which stems from the belief that people and computers have fixed strengths and weaknesses, and therefore all we need to do is give separate tasks to each agent (computer/person) according to their strengths. As long as software development and AI designers continue to fall prey to the substitution myth, we’ll continue to develop systems and tools that, instead of supposedly making humans lives easier/better, will require unexpected new skills and interventions from humans that weren’t factored into the system/tool design (Wrong, Strong, and Silent: What Happens when Automated Systems With High Autonomy and High Authority Misbehave?, Dekker & Woods, 2024).

InfoQ

Implications for Product and Engineering Teams

For TensorBlue readers, the useful question is not just what happened, but how this changes product architecture, engineering priorities, AI delivery, observability, team workflows, or executive decision-making.

• Review whether this changes your AI roadmap, platform architecture, or engineering operating model.
• Identify the specific workflow, reliability, governance, or developer-productivity lesson that applies to your organization.
• Convert the lesson into a small production experiment with measurable quality, latency, cost, adoption, or risk metrics.
• Document source assumptions clearly so teams do not overgeneralize from incomplete public information.

TensorBlue Takeaway

The practical opportunity is to turn this signal into a concrete implementation decision: better AI systems, stronger product instrumentation, more reliable automation, and clearer technical governance. Teams that connect public technology shifts to their own delivery systems will move faster without adding unnecessary complexity.