Forty years ago, while working for a tiny subsidiary of a gigantic telco, I stumbled through pre-Git source code management and tried to avoid explosively devolving into a mess of conflicts after every merge. Thankfully, modern practices make it possible to work in massive, distributed teams, swarming around a codebase, working independently toward a collective goal.

That sounds a lot like what we're heading toward with agents, and here it touches a nerve: nearly everyone in software engineering feels a deep terror as an invasion of agentic systems sweep all before them.

Now that Stack Overflow has gone agent-first, what's left for us meatsacks? Shoulder-to-shoulder with the flesh-based cohort most immediately under the pump at a conference called AI Engineer Melbourne, I heard conversations about the future of software engineering working their way through denial, anger, bargaining, and depression, to ... coupon clipping?

Now that organisations have been weaned off earlier 'all you can eat' subscription plans and onto 'pay-as-you-go' metered token consumption, they're all in various stages of sticker shock. Several talks at the conference discussed managing token costs, such as AJ Fisher's exploration of 'diffusion' models. Analogous to the diffusers used to generate images, they generate text at lighting speed, making them cheaper to operate while also being less accurate than the pricey and slower “autoregressive” frontier models.

Fisher's solution? Use a low-quality model and make it iterate on a problem (that new classic, the Ralph Wiggum loop) until it gets a satisfactory solution. This approach delivers the same result as a full-fat model, for anywhere from one half to one tenth the spend. Google released its DiffusionGemma mode, which produces text at prodigious speed, just days after Fisher's talk, giving everyone the ability to try this approach.

But some engineers reject AI in 'all the things'. Annie Vella, author of the seminal essay "The Software Engineering Identity Crisis" shared what she's learned about the feelings of grief experienced by a cohort of software engineers, provoked by AI tooling. We've seen the field divide into 'all in' and 'never ever' camps (even in the pages of El Reg), with a broad middle cautiously getting their feet wet. That divide has roots in two styles of work: those who look for outcomes, and those who look for learning, for whom the journey into understanding is the whole point of the exercise. Short circuiting that journey with AI tools makes folks for whom the journey is the reward feel cheated. How do we breach the divide? Annie suggests sensitivity, listening, and openness to change on both sides - highlighting human qualities in the machine age.

Kaggle and fast.ai alum Jeremy Howard took a different tack, reminding the audience of the importance of critical thinking - really, a plea to just keep thinking, a refrain we'll be hearing a lot as we struggle to avoid nodding off in the warm bath of machine thoughts. He followed up with a demo of SolveIT, his still-in-beta tool combining some of the best aspects of Python notebooks, Mathematica, Wikipedia, and a chatbot, offering up a counterexample of an environment designed for swimming in the sea of knowledge, rather than floating off into mindless oblivion.

Finally, Daniel Rodgers-Pryor's "Fully Automated Luxury Gay Space Engineering" blew my mind with a practical, working vision for AI in the engineering department. Rodgers-Pryor's entire CI/CD pipeline feeds all of its metrics, messages, logs and user feedback into a set of AI agents that quickly identify issues, find the underlying problems, fix them, integrate solutions into the codebase, test them, and push them out to users.

What sounds like a recipe for disaster turns out to be a formula for a self-healing, 'anti-fragile' system that improves as the pressure on it increases. More users? Good. More metrics? Great! More messages and logs? Even better. Agents eat all of that data and use it to improve the performance of the overall system. Rodgers-Pryor's "closed feedback loop" reminds me of a 20th century production line worker dipping into the stream of bonbons (or widgets) eyeing a few for quality, then tossing them back into the stream. "This is your job now," he concludes. "How can you can make those feedback loops shorter and tighter?"

Software engineers have been forced to absorb more change in the last three years than in the previous thirty, and have every right to be a aggrieved about that. Yet as AJ Fisher, Annie Vella, Jeremy Howard and Daniel Rodgers-Pryor all portrayed in their own ways, adopting AI looks less like rolling over before the dictates of the machine, and more like exploring a whole new world. Like any journey into a new realm, perils and hardships await. Who's to say that's not the price of admission for a once-in-a-lifetime opportunity? ®

 The author attended AI Engineer Melbourne as a guest of the conference.