AI and ML
Fear and even sadness are natural reactions to the machines that do our work. The next reactions, acceptance and innovation, are more useful
Forty years ago, when I worked for a small subsidiary of a large telecommunications company, I stumbled through pre-Git source code management, trying to avoid the explosion of chaos that would occur with every merge. Thankfully, modern techniques make it possible to work in large distributed teams, huddled around a codebase and working independently toward a collective goal.
This is very similar to what we’re heading towards with agents, but here it hits a nerve. Almost everyone in software engineering feels a deep sense of fear as agent system intrusions sweep across our faces.
Now that Stack Overflow is agent-first, what are we left with? At a conference called AI Engineers Melbourne, I sat shoulder-to-shoulder with real people, right under the pump, and listened to a conversation about the future of software engineering, navigating through denial, anger, bargaining, and depression.
Organizations are now retiring their previous “all-you-can-eat” subscription plans and moving toward “pay-as-you-go” pay-as-you-go token consumption, facing sticker shock at every step. Several talks at the conference discussed managing token costs, including AJ Fisher’s exploration of “diffusion” models. Similar to the diffuser used to generate images, it generates text at the speed of light, making it cheaper to operate, but less accurate than expensive and slow “autoregressive” frontier models.
Fisher’s Solution?Use a low-quality model and iterate the problem (a new classic Ralph Wiggum loop) until a satisfactory solution is obtained. This approach gives you the same results as a full-fat model for half to one-tenth the expense. Just a few days after Fisher’s talk, Google released DiffusionGemma mode, which generates text at lightning speed, allowing anyone to try this approach.
However, some engineers reject AI in “everything”. Annie Vera, author of the seminal essay “Software Engineering’s Identity Crisis,” shared what she learned about the feelings of sadness experienced by a population of software engineers caused by AI tools. We’ve seen the field split into “all in” and “never” camps (even in the pages of El Reg), with a broad middle class treading cautiously. This gulf is rooted in two work styles. People who want results and people who want to learn, and the journey to understanding is the point of practice. Using AI tools to shorten that journey makes it important for everyone teeth The reward feels cheated. How can we break out of the gap? Annie suggests sensitivity, listening, and openness to change on both sides, emphasizing human qualities in the machine age.
Kaggle and fast.ai alumnus Jeremy Howard took a different approach and reminded the audience of the importance of critical thinking. Just keep thinking, This phrase we often hear when we struggle to avoid nodding off in the warm bath of mechanical thinking. He then demoed SolveIT, a still-in-beta tool that combines some of the best things about Python notebooks, Mathematica, Wikipedia, and chatbots, offering a counterexample of an environment designed to swim in an ocean of knowledge rather than mindlessly drifting into oblivion.
Finally, Daniel Rogers Pryor’s “Fully automated high-end gay space engineering” blew my mind. practical, working A vision of AI in the engineering sector. Rodgers-Pryor’s entire CI/CD pipeline feeds all metrics, messages, logs, and user feedback into a set of AI agents to quickly identify issues, find and fix root issues, integrate solutions into the codebase, test them, and push them to users.
What sounded like a recipe for disaster turned out to be a formula for a self-healing “vulnerable” system. Improves as pressure increases. Increase in users? Good. More indicators? Great! Need more messages and logs? Even better. The agent uses all that data and uses it to improve overall system performance. Rogers Pryor’s “Closed Feedback Loop” is reminiscent of 20th century production line workers who immersed themselves in a stream of bonbons (or widgets), noted the quality of some bonbons (or widgets), and then threw them back into the stream. “This is your job now,” he concluded. “How can we make these feedback loops shorter and tighter?”
Software engineers have been forced to absorb more change in the past three years than in the past three decades, and it’s natural to feel frustrated about it. But as AJ Fisher, Annie Vera, Jeremy Howard, and Daniel Rogers Pryor have each illustrated in their own unique ways, deploying AI is less like bending over backwards at the behest of a machine and more like exploring an entirely new world. As with any journey into new territory, dangers and challenges await. Who’s to say this isn’t the price of admission for a once-in-a-lifetime opportunity? ®
The author attended the AI Engineer Melbourne conference as a guest.
