What Does It Mean to Be an Engineer in the Age of AI?
Published by
Jimmy Headdon
on
Let's be honest. When the first wave of AI coding assistants hit, if you're anything like me – a software engineer with a couple of decades under your belt, and your fair share of battle scars to boot – your initial reaction probably ranged from mild curiosity to outright scepticism - "That's not going to work", or "That’s not engineering". It felt like a direct challenge to years of hard-won experience, and the underwhelming quality of outputs from those early tools only reinforced the idea that GenAI and LLMs couldn’t handle the real-world complexity of engineering robust software.
Over the past few weeks, however, I have reflected on what it really means to create software within the sprawling, complex beast that is the modern software delivery lifecycle, and I think I might have misunderstood what I was doing (and why) - hear me out.
We engineers often view coding as an art form, and in many ways, the creative act of crafting elegant solutions is artistic. But perhaps we need to untangle the 'art' from the 'science'. Many of us take genuine joy in the process, the intricate problem-solving, and the flow state of writing code. And in many contexts, particularly hobbyist or open-source contributions driven by passion, that intrinsic joy and dopamine hit when your code finally compiles, or you squash a niggling bug, is a remarkably validating and rewarding feeling (I’m looking at you, ‘vibe’ coders!).
However, when coding in a professional environment, we are ultimately offering a service. Whether it’s writing code or engineering robust software solutions, our purpose isn’t to be artistic, it's to deliver value – functional, reliable, high-quality software – for our customers or our company. So, while finding joy in the process is fantastic and encouraged, the fundamental question remains: Where do humans add the most value in delivering software?
The answer lies in our innate human strengths. The capacity for true creativity – essential for problem-solving and novel design – and the power of critical thinking, vital for deep analysis, strategic decision-making, and navigating the nuances AI can miss.
It will mean different things to each of us, but consider this - is building a new feature toggle framework, or writing Terraform files from scratch, truly an artistic endeavour, every single time? If so, should it be? What if we can use AI tools to generate, say, 80% of the boilerplate efficiently, leaving the human artistry for the truly unique, domain-specific challenges where our creativity and critical thinking add the most value (and differentiates us)? This isn't to say we abandon intellectual challenges – far from it. Just this week, I found myself iterating on the O(n) complexity for an algorithm I was writing; a mentally stimulating challenge for sure, but it took me hours, and was it truly the best application of my expertise? I’m not convinced.
The challenge is discerning where and when the joy of the process aligns with delivering maximum value, and when it might be a distraction from applying our skills where they're most impactful for the service we provide.
This will divide opinion, but I’d go as far as to argue this isn’t even a question of what we use AI tools for, or whether these tools are reducing our profession to a joyless exercise - it’s deeper than that; it’s a reflection of software development still being early on the maturity curve, compared to other engineering disciplines (civil, aerospace, etc.). Outside of medical, aviation and other safety-critical software industries, our profession lacks well-defined standards and repeatable (componentised) patterns, and is therefore more weighted towards the ‘art’ than the established ‘science’ found in fields like electrical engineering or automotive manufacturing. In those mature disciplines, established science and rigorous standards mean bespoke, 'artistic' solutions aren't needed for common problems. This is the trajectory software is now on, and in maturing ourselves and our community into ‘engineering’ ways of working, we’re naturally going to dilute the scope for creativity.
And herein lies the core of the shift. The AI tools we have today make mistakes, hallucinate, and have a whiff of sycophancy. But here's the thing – they are the worst they will ever be. Think about that for a second. We are at the very beginning of this technology's maturity curve - the size and gradient of that curve are uncertain, but we are very much in the infancy of the curve, and the momentum is undeniable (and is accelerating).
So, let me pose a question, directed squarely at those of us building and leading software teams: What would even a 10% improvement in your project's delivery efficiency look like, assuming quality and learning aren’t compromised?
We are a long way from reaching maturity in objectively measuring the end-to-end performance of our development lifecycle, but 10%, imagine the impact:
- A faster time to market for products and services.
- More capacity for team training and innovation.
- Reduced developer burnout from repetitive, mundane tasks.
That's not trivial; that's transformational!
Yet, the current narrative around AI is hellbent on augmenting the single-engineer workflow; the localised challenges of an engineer working on a discrete problem, i.e. "How can AI help me write this code faster?". While valuable, I can’t help but feel we’re constraining the tools to fit our conventional ways of working, forcing a square peg (AI tooling) into a round hole (our traditional, single-threaded ways of working). I’d argue that the real power, the genuine revolution, comes from applying AI across the entire team and reimagining the end-to-end software development lifecycle.
The question then… Are we thinking big enough?
Thinking big enough means confronting this core challenge - the single-threaded model. For most people, the SDLC (applied agile or otherwise) remains a largely siloed flow with localised ways of working and varying measures of success within the phases or cycles.
Right now, AI tools are focused on augmenting an engineer in their traditional coding flow, the development phase of the SDLC. There are potentially significant gains to come from augmenting these specific activities, but consider this. What if, instead of an engineer spending two weeks coding a feature and using AI tools to passively assist, that engineer spent the first week channelling their expertise, their experience and opinion into the AI tools, then spent the second week using the tools to generate robust acceptance criteria, to write tests, and assist implementing the code? Would that yield better/worse results, compared to two weeks of purely passive assistance? Would the investment from that first week be compounding, accelerating and improving the quality of all subsequent work?
If we armed ourselves with the best tools and the mandate to use them in unconventional ways, how fast could we go? How much space could we create for other streams of value and creativity? Can we go ‘AI-First’ and what would that look like in practical terms? We're already seeing glimpses.
I recently read about Airbnb’s creative use of LLMs to accelerate (and largely automate) the migration of their React tests to a new testing framework, and to my earlier point, it had me wondering about my place in software delivery. Your mileage may vary, but I’d attribute a large proportion of my career to interpreting, extending and refactoring existing codebases, with comparatively few excursions into truly greenfield projects. I’ve lost track of how many months I’ve spent upgrading language, library and framework versions; in itself, not a particularly creative or rewarding task. To the Airbnb example above, would my time have been better spent training a model to do the legwork for the team’s future benefit, or finessing my experience into robust prompts that expedited the upgrade?
Yes, we can argue what prompting and model training mean to our profession, but this is a wider discussion than just our coding ways of working. There is a significant gulf in today’s messaging between the potential of these tools and the practical realities of delivering complex software projects (not simply writing code) in the real world. This void presents a tremendous opportunity, an opportunity for us to inject clarity, provide practical guidance, and yes, create genuine excitement about the future of software delivery.
- How can we leverage AI to not just write regression tests, but fundamentally change how we approach a shift-left of functional and non-functional testing? Is it possible to have ‘self-healing’ tests that review recent commits and automatically iterate to suggest potential fixes?
- Could we take a domain-specific ‘Definition of Ready’ and have AI elaborate requirements to produce robust acceptance criteria, reducing the waste of rework and scope creep caused by changing, low-quality requirements?
- Are we able to automate the instrumentation of code with observability patterns (logs, performance metrics, correlation IDs) across a distributed microservice architecture?
- Can we analyse feature usage data and highlight low-value features or code that could be deprecated to reduce complexity and vulnerabilities?
- Could a custom-trained model contribute to architectural design Request for Comments (RFC) with constructive feedback and recommendations, the equivalent to static analysis checks in code reviews?
- And to the Airbnb example, can we extend dependency management tools like Dependabot, to not just upgrade our language, library and framework versions, but the code and configuration, too?
So, where do we go from here? As technology leaders, there are some practical questions you need to ask yourselves:
- Are you investing solely in tools for individual contributors, or are you exploring how AI can transform your fundamental ways of working? Whether that’s to augment pair programming, pull request reviews, architectural discussions, code maintenance, or wider cross-functional collaboration.
- How will your team’s structure need to adapt when AI can handle significant portions of the 'science', to create space for contributions unique to the creativity of humans?
At Daemon, we're kicking off an exploration to define what our AI-first ways of working could look like. This means challenging the shackles of traditional approaches, embracing an experimental mindset, and fostering collaborative, cross-functional teams where AI acts as a force multiplier to augment and accelerate value creation and human ingenuity.
This isn't just about writing code faster, and it certainly isn’t about losing our identity as engineers. The real story is the acceleration of our journey into engineering maturity, and us fundamentally rethinking our unique human contributions to designing, building, testing, deploying, operating and maintaining software as a team, and how we can truly expedite the value that software brings to the world. All the AI tools are doing is accelerating that journey.
I don't profess to have all the answers, and I’m realistic enough to understand this won’t suit every scenario, or align with what every engineers wants from life, but I’m starting to reflect on my career and consider what my contribution was, and what I would have done differently, armed with the knowledge and tools of today.
We owe it to ourselves, as engineers and leaders shaping the future of technology, to challenge the status quo. By focusing on how AI agents and tools can accelerate delivery, augment the entire team, and elevate where humans spend their most valuable, creative energy, I believe we can unlock unprecedented levels of productivity, quality, and innovation.
In this fast-evolving landscape, one thing is clear: the future of software engineering isn’t about us being replaced by AI, but it will be fundamentally, excitingly different. The question is, are you ready to explore what that future looks like, and what it means to you?
If you're interested in exploring the potential of an AI-first approach and reimagining software delivery within your own organisation, I'd welcome the opportunity to discuss how Daemon could support you on that journey.