From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.

IT Brew

Software Development

Caroline Nihill

itbrew.com

The White House released long-awaited AI guidance in July, and it’s a mixed bag. While the Trump administration’s “anti-woke” executive order takes aim at perceived diversity, equity, and inclusion (DEI) initiatives in the development of large language models, IT pros who spoke with IT Brew were pleasantly surprised to find a focus on open source in its separate AI action plan.

According to the EO signed by President Trump, DEI in regard to AI is considered the “suppression or distortion” of factual information about race or sex. It continues: “DEI displaces the commitment to truth in favor of preferred outcomes and, as recent history illustrates, poses an existential threat to reliable AI.” The Associated Press 

 the order as an attempt at censorship, and noted that it “still faces a study period before it gets into official procurement rules.”

Asad Ramzanali, the current director of AI and tech policy at the Vanderbilt Policy Accelerator and former official at the White House Office of Science and Technology Policy under President Biden, told IT Brew that he imagines the implementation of the “anti-woke” order may look like a government-established test for systems.

“I worry that in the hope of creating neutrality, you just mandated an ideological purity test,” Ramzanali said. “I’m allowed to have a political view, you’re allowed to have a political view, your company can have a political view. That’s really tricky to push companies ostensibly through procurement to meet some kind of neutrality.”

While experts maintain that the anti-woke EO that follows the action plan’s release is concerning, they also agree that the administration’s positioning toward open-source models is a benefit to the private sector.

Seemingly more substantive guidance on AI is outlined in the administration’s action plan, titled “Winning the Race,” which points to the government’s ability to “accelerate the maturation of a healthy financial market for compute” through collaborating with industry and using other vehicles in the federal space, like the National AI Research Resource Pilot and the National Institute of Standards and Technology, for open-source models.

The administration recommends ensuring access to “large-scale computing power for startups and academics by improving the financial market for compute. Currently, a company seeking to use large-scale compute often must sign long-term contracts with hyperscalers—far beyond the budgetary reach of most academics and many startups.”

The action plan further states that the US has “solved this problem before” through spot markets (when assets are purchased or sold immediately without a long-term commitment) and forward markets (where contracts are made to purchase or sell assets at a determined price in the future). This is in concert with the industry and government approach the administration believes can hasten the maturation of a healthy market for compute.

the action plan focuses on infrastructure and diplomacy—pointing directly toward encouraging both open-source and open-weight models.

 webpage points to releasing open-source software as a benefit from the standpoint of having more perspectives. It states that open-source work has “benevolent results” but it is not “an act of charity.” It goes on to say that having an open-source approach can yield higher returns than the initial investment.

, however, pointed to open-source software as having limited support and functionality, compatibility issues, and more. It looks to open-source security risks, as well, if the software is maintained incorrectly—specifically, vulnerabilities can allow attackers to access sensitive information or take control of a system.

Policy and industry experts, like Travis Hall, the director for state engagement at the nonprofit and nonpartisan Center for Democracy and Technology and Dhruv Patel, CEO of Syncurrent—a company that provides digital services to match local governments to grants—point to the action plan’s stance on open source as a positive for the market.

Hall highlighted the open-source and open-weight systems of the action plan as a potential positive.

“I think that this is a big deal, particularly for industry and IT professionals, because there have been debates…on whether or not open systems should be allowed, whether they can be exported, whether there should be expert controls on model weights or open-source systems,” Hall said. “It means that the tendency towards large model, proprietary systems being the only thing that is available is not going to be the case.”

Hall believes this aspect of the plan is a “pro-competitive move that will help IT professionals in particular” through having a broader set of choices than what is currently available—like those provided by Linux, WordPress, and Android. He also said that IT pros can benefit from having the ability to use open-source systems and “innovate on their own.”

“Everybody knows that open-source software is available, it is a thing,” Hall said. “It hasn’t made commercial proprietary software go away, but it does help to diversify the ecosystem and also help support a more competitive ecosystem.”

Patel told IT Brew that those who adopt open-source models will be impacted, but said he doesn’t know if it’s “for the better or for the worse.”

“Right now, I lean more good than bad, particularly because of the emphasis on supporting open source and supporting open models, as opposed to not,” Patel said.

He continued: “For tech businesses, for tech startups, it’s incredibly important that we have robust open-source models. But even more so for nutritional IT tech-enabled businesses, businesses that don’t directly have a fingerprint in tech but they’re tech-enabled.”

Trump administration’s AI plan takes aim at ‘anti-woke’ large language models

The action plan, released at the end of July, also contains language in support of ensuring access to open models for startups and academics.

Billy Hurley

Software engineer Joshua McKenty had worked on enough open-source projects by 2010 to know that the Global Earthquake Model (GEM) was not on a path to being open source.

With stints at NASA, Netscape, and a consultancy leveraging open-source tech, McKenty had experience designing publicly collaborative code, using a shared, continuous-release philosophy known as 

He and the earthquake scientists knew their teams could use a little Agility.

Helen Crowley, former researcher and GEM’s secretary general, said scientists at the time only 

“For us, it meant maybe you would make your software available somewhere at the end, once it was ready for other people to look at. But I think what Josh really explained to us is that it had to be 

McKenty shared how he helped to turn GEM—and develop its software engine OpenQuake— into an open-source, community-driven initiative, literally bringing together two teams that hadn’t always shared the same spaces: developers and scientists. The process involved a lot of Agile, which in theory meant iterative development and in practice meant offsites in the mountains and paired programming at desks.

“I focused a lot more on cultural transformation, rather than just, ‘Let’s produce software and feel proud of ourselves,’” he told us.

In 2010, McKenty was asked to review the then-in-progress Global Earthquake Model, which at the time was on year two of a five-year grant.

The GEM team wanted to create an open-source model to estimate earthquake-related impact and calculate human or economic losses for a collection of assets—the kind of tool that could help everyone from city planners to insurance providers.

“You need to have a first release now, not at the end of five years, so that you build a community around the software,” he remembers. That meant changing development practices.

McKenty took a six-month contract as interim secretary for IT—moving to Italy and occasionally commuting to the GEM office in Switzerland.

The definition of software, McKenty says, is it will be wrong—often because of a communication problem between the person with the problem and the engineer building the solution.

And that lack of cooperation exists at a wide range of organizations, not just the ones making earthquake models.

A global survey of 3,500 developers, published in July by Atlassian, found 55% of knowledge workers had difficulty tracking down information despite knowing a lot of people at their job,” and 56% said their companies “plan and track in different ways, which makes it hard to collaborate.”

Principles in the Agile manifesto, created in 2001, include tenets like delivering working software frequently, collaborating with business and developers, and reflecting regularly.

McKenty saw an occasional lack of agility (there’s that word again) in the methods of scientists, who often need their software to work just once in a lab, McKenty said. An 

, however, had to work constantly for a world of contributors.

In those six months, McKenty shook up the team, focusing on collaboration. It was not uncommon for a scientist and programmer to pair up on a task like simulating the shaking of the Earth. With this setup, no one had to wait for an email about which of a library’s many algorithms best resembled earthquake movement.

“You understand the science and I understand the software, and let’s make that work minute by minute, instead of month by month, or requirement by requirement,” he told us.

With McKenty at the helm, GEM’s team of coders and scientists produced a new feature or version every two weeks—what Agility proponents often call “sprints.”

Crowley remembers an offsite code sprint in Switzerland—“a weekend featuring lots of couches and pizza and just a good atmosphere.”

During McKenty’s tenure, the team had 20 or 30 releases, McKenty said, that culminated in OpenQuake 1.0’s release in 2013.

The GEM Foundation’s OpenQuake has been used in recent years to determine risk profiles for public schools in Peru, roads in Solomon Islands, and buildings in San Francisco. In December 2018, GEM “

 with a total of 30 national and regional seismic hazard models.”

“I am more proud of OpenQuake than anything else I’ve ever worked on, because I spent six months and I got the community in this sort of shape, and I let it go,” he said.

McKenty is currently CEO at fraud prevention company Polyguard.

Agile, as a practice, is hanging in there, even as the idea of paired programming these days might involve a vibe coder and their LLM.

 from this year polled global pros with knowledge of their company’s Agile practices and found that 61% of respondents have been using Agile practices for over five years, and 24% have deployed them within the last three years.

The ability to work in agile, cross-functional teams is increasingly important to IT pros, according to McKenty, who sees the source of good, working software as a collaboration between human teams talking to each other, sharing spaces, and trying to close up a gap that’s always open.

“I think that’s the definition of every software project; usually the product owners or the customer have an understanding of what they want, but not how to make it happen, and the software team has an understanding of how to make it happen, but not actually what they want. And so building good software is about being able to communicate across that divide.”

How to build an earthquake model: Bring scientists and software engineers together (literally)

 Joshua McKenty shares his Agile approach with Global Earthquake Model (GEM).

The link between music and math has been long known; musical notes are the representation of vibrations and frequencies, which math quantifies. The art of music—the way it makes us feel—is how our brains recognize and translate patterns and then translates them into feeling and emotion.

Adam Ribaudo, an artist and IT professional, said that he’s always felt an intuitive link between math and music, specifically when it comes to intuition and harmonies.

“There needs to be some sort of intuition and some mental map of how notes relate to each other,” Ribaudo said. “That mental map can then be transferred more easily to mathematical or some technical concepts where you’re searching in your brain for those harmonic registries.”

Technology, says composer, musician, and technologist Chester Jankowski, is about turning abstractions into patterns. So it’s not all too surprising, then, that musicians frequently make great technologists, coders, and IT professionals, according to 

. Each organization points to how musical artists think and problem solve logically and mathematically.

Jankowski and Ribaudo, along with other musicians who work in IT, say that the overlaps between logic and creativity assist them in both composing code and music. In order to improvise in music, for example, you have to know the foundation of music—how notes and keys work, etc. The same holds true in IT: In order to fix a system, you have to know the infrastructure.

When Wolfgang Wedemeyer, a ServiceNow senior staff software engineer and musician, is in the midst of working or composing, he doesn’t always see the connection between his expertise in music and software until later. Once he’s reflected on an experience, he can begin to connect the two.

“I get into a very similar flow state when I’m working creatively on music and when I’m also working on solving some of the harder software problems,” Wedemeyer said. “When it comes to theory and rules and patterns and all that sort of stuff, I find there’s similarities between doing parallel programming and working on harmonies, where you have to keep multiple things that are happening simultaneously in your head and make them work together in a logical way.”

Jankowski pointed back to the intuition for problem-solving, and said that musicians are often skilled at seeing the “bigger picture.”

“If something’s broken…you could either just go through a checklist and check everything in order, or sometimes you just have this flash of insight,” Jankowski said. “You’re able to go there and retrace your steps.”

Director of software engineering management at ServiceNow,Yaron Guez, told IT Brew that the translation of skills is more subtle. He believes that programming languages and music theory are the same in that both require certain rules to be followed.

“I haven’t had a moment where, because I know this circle of fifths or the way music modes work…that’s going to help me specifically on this programming challenge,” Guez said. “It’s just the same type of problem-solving, or rather, the same type of understanding another language.”

Guez said that in encountering different technologists who are also musicians, he finds that those individuals are often the ones where “this isn’t just math to them.”

“Not to say that math doesn’t have creative elements to it—of course, when it comes to proofs and whatnot—but still, they’re not just following a set of instructions and relying on their knowledge and expertise to do it,” Guez said. “They’re using creative problem-solving to figure it out.”

A close-up of a person's hands playing electric guitar chords with AI data patterns overlaid.

What music and coding have in common: Math

“It’s just the same type of problem-solving, or rather, the same type of understanding another language.”

Brianna Monsanto

The AI tools industry execs say that can make you more productive may actually be holding you up.

 by AI research nonprofit METR, which found that experienced developers who used AI tools in their workflow took 19% more time to complete assigned tasks.

 The researchers conducted a randomized controlled trial among 16 seasoned developers. Between February and June, the developers completed 246 tasks on popular open-source repositories that they were regular contributors to, such as the Mirror of the Glasgow Haskell Compiler and Hugging Face Transformers library. Participants were able to use any AI tool of choice and were compensated for their time.

Researchers recorded the screens of participants as they completed their assigned tasks. They then used the screen captures, as well as “rich statistics from source-code management systems” and interviews and surveys with participants to better understand the results. Some of the factors researchers attributed to the longer work time included participants overusing AI tools, believing they would improve productivity; existing familiarity with repositories, rendering AI tools less useful; and unsatisfactory outputs, leading participants to spend extra time trying different prompts or tinkering with AI-generated code.

Prior to starting the study, the developers predicted that AI would speed up their completion time by 24%. Their confidence in how much the tools would reduce their workflow fell slightly (20%) after participating in the study.

 The researchers of the study state that the factors they alleged contributed to the discovered slowdown are study-specific, and it should not be assumed that AI tools do not have practical real-world applications.

“These results do not imply that current AI systems are not useful in many realistic, economically relevant settings,” the study’s authors wrote. “Furthermore, these results do not imply that future models will not speed up developers in this exact setting.”

” continues to gain popularity in the industry and developers embrace generative AI and LLMs in their workflows. A 

 found that more than three-fourths (76%) of developers used or planned to use AI tools in the development process last year.

Michael Armstrong, CTO at Authenticx, told IT Brew that the nonprofit’s discovery on AI tools tacking on time for some developers was unsurprising. He said he has personally seen occasional productivity losses when AI tools are introduced due to a variety of reasons, including learning curves, substandard quality, and distractions created by these tools.

“What I’ve observed is you can have a really, really good coder, but if they don’t really understand what they’re trying to solve for…the results are not ideal,” Armstrong said.

Meanwhile, David Murray, CEO of talent platform Confirm, said the study validated what he and his team had experienced in their own workflow slowdowns, citing 

 and developers tinkering with AI-generated code. He said it has influenced how he advises his team to work with AI tools.

“The guidance that we’ve kind of given each other is basically [to] be mindful and give very specific instructions and focus on specific use cases.”

a clock split into three different pieces, like a pie chart

AI coding tools might actually be slowing you down

METR found that seasoned developers took 19% longer to complete tasks when using AI tools.

Anthropic and Meta both won landmark cases concerning copyright infringement in two Northern California district courts in late June, signalling the beginning of the fight on fair use between AI companies and creators.

The law firm McDermott Will & Emery wrote 

 that both companies showed the use of copyrighted materials in LLM training is highly transformative. The decision in the case against Meta also signified a new battleground surrounding market-harm evidence, as the authors were not able to show data that tied the company’s AI, Llama, to a loss in book sales or licensing value.

The post said appeals for the cases are “virtually certain,” and concluded that while companies wait on clearer appellate laws, they should “assume that training on text obtained from dubious sources remains a high-risk activity and that a lack of market-harm evidence may be only a temporary shield.”

Anthropic’s case included the use of pirated material to create its central library, which will be subject to another trial, according to the judge’s decision.

Three authors (Andrea Bartz, Charles Graeber, and Kirk Wallace Johnson) had their work copied by Anthropic through both pirated and purchased sources, according to the filing.

The company used the unauthorized copies to train LLMs and kept library copies in place as a permanent and general-purpose resource, “even after deciding it would not use certain copies to train LLMs or would never use them again to do so.”

Judge William Alsup, who oversaw the case against Anthropic, said that the evidence provided did not prove any non-transformative use of the work through its model, Claude.

“Yes, Claude could help less capable writers create works as well-written as [the plaintiffs’] and competing in the same categories,” Alsup wrote. “But Claude created no exact copy, nor any substantial knock-off. Nothing traceable to [the plaintiffs’] works.”

Alsup said that the use of the books to train Claude was “exceedingly transformative” and was fair use under the Copyright Act.

Judge Vince Chhabria, who oversaw the Meta case, also pointed out that the tech giant’s use of 13 authors’ works was transformative. He 

 that while a company is more likely to be protected by fair use doctrine, there isn’t a rule saying that this “inoculates you from a claim of copyright infringement.”

Chhabria continued that under the fair-use doctrine, the market harm for copyrighted work is “more important than the purpose for which the copies are made.” He continued in the conclusion that Meta’s use of the authors’ works presented no meaningful evidence on market dilution “at all.”

The plaintiffs in this case contended that Llama is capable of reproducing snippets of text from their books and that Meta’s use of their works for training without permission diminished their ability to license work for training LLMs.

“Both of these arguments are clear losers,” Chhabria wrote. “Llama is not capable of generating enough text from the plaintiffs’ books to matter, and the plaintiffs are not entitled to the market for licensing their works as AI training data.”

Anthropic and Meta both win landmark fair-use cases surrounding LLM training

Authors took the companies to court concerning the use of copyrighted materials in LLM training—judges agreed that the tech’s final product was “transformative.” 

Back in the ’90s, Rob Brown, 48, now director of foundation engineering at employee-experience platform Workleap, wasn’t bagging groceries. He was coding them.

The teenage software engineer in training was working part-time for a supermarket in Ontario, Canada, when he created an inventory management system. Brown used a programming language called Turing, a general-purpose language developed in 1982, to bring his “little pet project” to life.

“That was almost a commercial application in my young imagination,” Brown told us.

If he had to do that kind of app today, he said, he might use a 

, backed by a cloud service, and then integrate a large language model (LLM) to help managers or customers with questions.

On his desk today, Brown keeps a Mac mini for running LLMs locally. With loaded tools like Transformer Lab, he is experimenting with using Workleap’s post-mortem transcript calls as training data for determining the root causes of customer-impacting incidents. Whether digitally organizing grocery ingredients or client headaches, Brown remains curious and wants to apply his skills to the technology of the moment.

“That passion to actually keep up and reapply those skills and to continually reinvent ourselves is important,” Brown said.

Being a veteran software engineer doesn’t mean you can’t vibe with the 

. Programmers who began their coding careers decades ago shared how they’re embracing coding changes and actively experimenting with AI—because that’s what developers do. They keep up.

“When you get into being a programmer or engineer, you have to sign up for change,” John Pettit, 47, CTO at Promevo, told us. “It’s not, ‘I learned one time and I’m done.’”

Pettit began his engineering career in the ’90s Windows NT era, he said, building simple apps for companies like insurance offices and automotive shops, using early text editors and compilers. Since then, he’s seen coding evolve with the arrival of integrated development environments, intermediate languages, dynamic web pages, mobile apps, and now agentic AI.

Pettit recently participated in a hackathon to use Google’s Gemini model to 

 that delivers commentary for specific Major League Baseball games. The project combined a front-end of well-known HTML, CSS, and JavaScript with newer components like Google’s text-to-speech API.

 found 76% of just under 61,000 global respondents are using or plan to use AI tools in their development process, an increase from previous year’s percentage of 70%.

Rather than run from AI, Stephen Bennett, 42, director of Soliant Consulting’s cloud-native applications practice, encourages his team of seven coders—all with at least a decade of experience, he said—to integrate AI into their build practices.

Bennett, who started his software engineering career in 2005, and the Soliant software crew began experimenting with LLMs in October 2024. Now they use tools like StackBlitz’s Bolt to quickly generate front-end designs, with “caution,” he noted, emphasizing the importance of reviewing output and securing client data.

“My approach is that it’s not going anywhere. We need to learn,” Bennett told us.

In addition to highlighting an increased usage of AI tools, the 2024 Stack Overflow study revealed plenty of rookie engineers. One-third of developers surveyed have coded for four years or less. Just over one-quarter of respondents had 15-plus years of professional coding experience.

Scott Petry, partner at PwC in cloud engineering consulting services, says it’s actually the junior engineers who are struggling to gain the benefits of AI coding assistants.

A crew of seasoned coders who know their way around evolving code environments can help bring pet projects to production.

“When you want to build a production-grade app, you still need to have a group of deep engineers who understand the facets of building a good application, getting the architecture right, getting the overall system put together the right way,” he said.

Coding workspace with dual monitors and laptop featuring programming and development tools. (Credit: ATHVisions/Getty Images)

How curious veteran coders keep up (and reinvent themselves) with AI

Experienced programmers know a thing or two about adapting.

was a young programmer for a pager company, he learned a valuable lesson that many veteran coders have likely learned, too:

If the weekend is almost here, don’t touch anything.

“If you really want to anger the gods of software, deploy new software on a Friday afternoon,” Thomas, now SVP of engineering at KnowBe4, told us, recalling how a well-meaning colleague at the time had wanted to optimize a database by changing indexes, but did not change all of the code that 

Software at that pager company connected a customer relationship management (CRM) network to a network of pagers. The changes accidentally took down the CRM system, Thomas said, and there was the risk that two million customers could not manage their devices.

“It was what we call a potential extinction-level event. I mean, it was that type of bug,” he told us, remembering working the weekend to solve the problem.

Veteran coders like Thomas spoke with us about the coding bugs that can ruin a Friday or a whole weekend—and what mechanisms (like emergency rollbacks) should be in place before everyone heads to happy hour.

A bug—“the bane of every developer’s existence,” according to Clinton Walker, associate director of delivery at Presidio—generally refers to code that doesn’t work as intended.

A bug can lead to unexpected consequences, ranging from error messages to downed CRMs.

Recent research from digital infrastructure advisory organization Uptime Institute found that 40% of 397 global data center operators and vendors experienced a “significant, serious, or severe IT service outage” caused by human error over the past three years. Top reasons reported by the IT practitioners included failure to follow correct procedure.

Also, according to Uptime: Sixty-one percent of a surveyed 207 respondents said a “software or configuration” error within the same time period led to an outage caused by a problem with a third-party IT service provider.

Bugs happen—even to the Mars Climate Orbiter, which burned up following a failure to use metric measurement in the coding of a software file, according to 

Walker recommends many practices to prevent bugs, including 

 tools followed by manual review from a senior engineer.

Dave Laskowski, director, application development and engineering at Protiviti, suggests modern 

 pipeline tools like Azure DevOps and plenty of 

, or short pieces of code written to run the main functional code and verify its output. “A good developer will write multiple unit tests with different inputs to thoroughly validate critical functions,” he wrote in an email to IT Brew.

KnowBe4 deploys strict access controls for code tweakers, no matter the rank.

“Even I, as the SVP of engineering here at KnowBe4, don’t have permission to make a code change, merge that code change to our production branch, and ship that,” Thomas told us. “There are probably about four or five different software systems in between that would block me from doing something so reckless.”

After the call, he shared in an email other measures the company implements, including built-in automation blocks for production changes unless a certain number of engineers have reviewed and approved the modifications, as well as tools that can roll back disruptive code updates.

And, of course, there’s engineering policy to make sure everyone has a good weekend.

“Every engineer is fully aware that it is a violation of company policy to deploy changes after a certain time on a Friday,” Thomas wrote.

A hand dropping a laptop with code on the screen falling out of it. (Credit: Illustration: Anna Kim, Photos: Adobe Stock)