But as with any product team, you have limited resources and the need to balance both business and engineering objectives. So many stakeholders inform your developer experience roadmap that it can be difficult to prioritize.

Yes, you need a roadmap 

The biggest thing that distinguishes platform engineering from the top-down platforms of tech days of yore? Nobody has to use it. 

When you’re building any developer experience tooling — whether it’s an internal developer platform or portal or just a directory or better documentation — you have to build something that your engineers actually want to use. Your platform strategy — sometimes called a developer experience or DevEx strategy — should make developer lives so much easier that they need a really good reason to go off that golden path. 

Platform engineering requires a Platform-as-a-Product mindset, packed with user-centric design, prototypes and demo days. Your colleagues become your customers.

You not only need an internal product roadmap, you need to actively publish it within your organization. This way not only are you making commitments to solve your developer-customer’s problems, you are closing that feedback loop, so your platform team knows early and often if you’re building something that they even want or need.

Know your stakeholders

Perhaps even more than when you are working with external users, a platform team, as stewards of the developer experience, is beholden to many stakeholders. 

As Sergiu Petean from Allianz Direct pointed out, a common anti-pattern for platform teams is only addressing the single stakeholder of the software engineer. The larger the enterprise, the more regulated your industry, the more stakeholders you have to consider from Day One. 

At the insurance giant, his team initially highlighted eight different stakeholders that all bring different demands:

• End users
• Quality
• Security 
• Software delivery 
• Data
• Sustainability
• Incident management
• Compliance 

Later they realized the platform has the capacity to interact with even more teams. 

Work to build a relationship with each of your technical and business stakeholders. Learn what part of the software development lifecycle matters most to them. And then bring them into your feedback loops that impact your platform engineering product roadmap.

Learn to prioritize

The more stakeholders you identify, the even more feature requests you’ll receive. Yet, according to research by DX, the average team focused on developer experience is a fraction of the whole engineering org. That can seem overwhelming, but a platform engineering strategy is all about centralizing and solving frustrations at scale.

How can you possibly balance so many conflicting demands? HashiCorp’s platform engineering lead Michael Galloway recommends looking to remove the pebble in their shoe.

The biggest points of friction will be an ongoing process, but, as he said, “A lot of times, engineers have been at a place for long enough where they’ve developed workarounds or become used to problems. It’s become a known experience. So we have to look at their workflow to see what the pebbles are and then remove them.”

Successful platform teams pair program with their customers regularly. It’s an effective way to build empathy.

Another thing to prioritize is asking: Is this affecting just one or two really vocal teams or is it something systemic across the organization? You’re never going to please everyone, but your job in platform engineering is to build solutions that about 80% of your developers would be happy to adopt. 

Go for the low-hanging fruit

Another way that platform engineering differs from the behemoth legacy platforms is that it’s not a giant one-off implementation. In fact, Team Topologies has the concept of Thinnest Viable Platform. You start with something small but sturdy that you can build your platform strategy on top of.

For most companies, the biggest time-waster is finding things. Your first TVP is often either a directory of who owns what or better documentation. 

But don’t trust that instinct — ask first. Running a developer productivity survey will let you know what the biggest frustrations are for your developers. Ask targeted questions, not open-ended ones. You can get started inquiring about the 25 drivers of developer productivity — which socio-technically range from incident response and on-call experience through to requirements gathering and realistic deadlines. 

Mix this with informal conversations and pair programming with your devs to uncover big and small problems that need solutions.

As startup advisor Lenny Rachitsky suggests, you can rate each idea from 1 to 5 across the X of how impactful it’ll be to solve a problem and Y of how much effort it’ll take. Just make sure anything that shows up on that “guesstimation graph” meets the requirement that it solves a problem for a majority of your developers — because a platform team should never work for just one dev team.

Don’t forget to value quick fixes to help ease some pain. Following the agile practice of “walking the board,” prioritize features closest to Done. This allows for early wins to foster platform advocates, which can go a long way to increase adoption. 

Be open to changes

As CTO of Carta Will Larson put it, “If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.” 

Your roadmap is just that, a map — there’s always more than one way to go. You need to be ready to deviate and change your priorities. This could be a global pandemic or an urgent vulnerability patch. It could be the need to adopt a new developer technology because it will help you work with a big-name integration partner. 

Especially in a well-regulated industry, your cybersecurity and compliance stakeholders can influence a lot of change. Just because platform engineering is opt-in, doesn’t mean it can’t facilitate some mandatory changes too.

No matter what the reason, it’s important that you communicate any fluctuations to your internal customers, explaining why the roadmap priorities have changed.

Continuously measure

Engineering is a science, so we know you can’t improve what you don’t measure. This “metrics-backed intuition” as Diogo Correia, developer experience product manager at Pipedrive, calls it, fosters continuous improvement, not just for your platform strategy but for your developers too.

His team uses DX for quarterly developer surveys. Then it developed and open sourced a one-hour developer experience workshop to help dev teams not only surface their own struggles but to set individual team focus areas for the next Q. 

“It has an immediate impact in terms of the sentiment and priorities that they report in the next quarter,” he said. For example, a lot of developers complain about technical debt, but almost no devs want to spend time fixing it. This knowledge has fed into Pipedrive’s rotation of teams focusing on paying down that debt versus releasing new features.

“The workshops help by identifying the concrete services or libraries that any given team owns that most developers in the team are feeling pain with,” Correia continued. This helps the team prioritize and plan to refactor, “instead of suffering through it for years on end, as before.”

In the end, the most important measurement of any developer experience strategy is if your internal dev customers are adopting and using it. Work to tighten that internal feedback loop to make sure you are building what they want. Only then will you achieve measurable, long-term success.

The post Prioritizing your developer experience roadmap appeared first on SD Times.

Yes, tooling is important; You can’t secure the software supply chain with secure coding practices alone. But you’ll need to combine those best practices with things like software bills of materials (SBOMs), software composition analysis, exploit prediction scoring systems (EPSS), and more.  

Before we can begin to think about what tooling can help, step one in this fight is to get the fundamentals down, explained Rob Cuddy, global application security evangelist at HCLSoftware. “There’s a lot of places now that are wanting to do security better, but they want to jump to steps four, five, and six, and they forget about steps one, two, and three,” he said. 

See also: A guide to supply chain security tools

He explained that even with new types of threats and vulnerabilities that are emerging, it’s still important to take a step back and make sure your security foundation is strong before you start getting into advanced tooling. 

“Having the basics done really, really well gets you a long way towards being safe in that space,” he said. 

According to Janet Worthington, senior analyst at Forrester, the first step is to ask if you’re following secure development practices when actually writing software.

“Are we secure by design when we’re building these applications? Are we doing threat modeling? Are we thinking about where this is going to be installed? About how people are going to use it? What are some of the attack vectors that we have to worry about?” 

These are some of the basics that companies need to get down before they even start looking at where tooling can help. But of course, tooling does still play a crucial role in the fight, once those pieces are in place, and Cuddy believes it is crucial that any tool you use supports the fundamentals.

The bare minimum for software supply chain security is to have an SBOM, which is a list of all of the components in an application. But an SBOM is just an ingredient list, and doesn’t provide information about those ingredients or where they came from, Worthington explained. 

Kristofer Duer, software architect team lead at HCLSoftware, added, “you need to know what goes into it, but you also need to know where it’s built and who has access to the code and a whole list of things.”

According to Worthington, this is where things like software composition analysis tools come in, which can analyze SBOMs for security risks, license compliance issues, and the operational risk of using a component. 

“An example of an operational risk would be this component is only maintained by one person, and that single contributor might just abandon the software or they might go do something else and no longer be maintaining that application,” she said. 

According to Colin Bell, AppScan CTO at HCLSoftware, EPSS — a measure of the likelihood that a vulnerability actually gets exploited — is another emerging tool to improve supply chain security by smartly prioritizing remediation efforts.

“Just because you have something in your supply chain doesn’t necessarily mean that it’s being used,” he explained. 

Bell said that he believes a lot of organizations struggle with the fact that they perceive every vulnerability to be a risk. But in reality, some vulnerabilities might never be exploited and he thinks companies are starting to recognize that, especially some of the larger ones. 

By focusing first on fixing the vulnerabilities that are most at risk of getting exploited, developers and security teams can effectively prioritize their remediation strategy. 

Worthington added that integrating secure by design foundations with some of these tools can also cut down on release delays that are caused by scanning tools finding security issues at the last moment, right before deployment, which might prevent deployments from going out until the issues are resolved. This is needed as companies are under more and more pressure to release software faster than ever. 

“Organizations that release frequently with high confidence do so by embedding security early in the Software Development Life Cycle (SDLC),” said Worthington. “Automating security testing, such as Software Composition Analysis and Static Application Security Testing, provides feedback to developers while they are writing code in the IDE or when they receive code review comments on a pull request. This approach gives developers the opportunity to review and respond to security findings in the flow of work.”

She also said that identifying issues before they are added to the codebase can actually save time in the long run by preventing things from needing to be reworked. “Security testing tools that automate the remediation process improve product velocity by allowing developers to focus on writing business logic without having to become security experts,” she said. 

XZ Utils backdoor highlights importance of people in protecting the software supply chain

However, as mentioned at the top, tools are only one component in the fight, and secure practices are also needed to deal with more advanced threats. A recent example of where the above-mentioned tools wouldn’t have done much to help on their own is when in March, it was announced that a backdoor had been introduced into the open-source Linux tool XZ Utils. 

The person who had placed the backdoor had been contributing to the project for three years while gaining the trust of the maintainers and ultimately was able to rise to a level at which they could sign off on releases and introduce the backdoor in an official release. If it hadn’t been detected when it was and had been adopted by more people, attackers could have gained access to SSH sessions around the world and really caused some damage. 

According to Duer, the vulnerability didn’t even show up in code changes because the attacker put the backdoor in a .gitignore file. “When you downloaded the source to do a build locally, that’s when the attack actually got realized,” he said.

He went on to explain that this goes to show that developers can no longer just “get the source and run a build and call it a day. You have to do so much more than that … They have the SHA-256 hash mark on the bins, but how many people run those commands to see if the thing that they downloaded is that hash? Does anybody look in the CVE for this particular package to see if there’s a problem? Where do you rely on scanners to do that work for you? It’s interesting because a lot of the problems could be avoided with another couple of extra steps. It doesn’t even take that much time. You just have to do them,” Duer said. 

Worthington added that it’s really important that the people actually pulling components into their applications are able to assess quality before bringing something into their system or application. Is this something maintained by the Linux Foundation with a vibrant community behind it or is it a simple piece of code where nobody is maintaining it and it might reach end of life? 

“A very sophisticated attacker played the long game with a maintainer and basically wore that poor maintainer down through social engineering to get their updates into XZ Utils. I think we’re finding that you need to have a really robust community. And so I think SBOM is only going to get you so far,” said Worthington.

While this may seem like an extreme example, the Open Source Security Foundation (OpenSSF) and the OpenJS Foundation put out an alert following the incident and implied that it might not be an isolated incident, citing similar suspicious patterns in two other popular JavaScript projects. 

In the post, they gave tips for recognizing social engineering attacks in open source projects, such as:

• Aggressive, but friendly, pursuit of maintainers by unknown community members
• Requests from new community members to be elevated to maintainer status
• Endorsement of new community members coming from other unknown members
• PRs containing blobs as artifacts
• Intentionally difficult to understand source code
• Gradually escalating security issues
• Deviation from typical project compile, build, and deployment practices
• A false sense of urgency to get a maintainer to bypass reviews or controls

AI will make things worse and better

AI will also exacerbate the number of threats that people have to deal with because as much as AI can add useful features to security tools to help security teams be more effective, AI also helps the attackers. 

Having AI in applications complicates the software supply chain, Worthington explained. “There’s a whole ecosystem around it,” she said. “What about all the APIs that are calling the LLMs? Now you have to worry about API security. And there’s gonna be a bunch of new types of development tools in order to build these applications and in order to deploy these applications.”

Worthington says that attackers are going to recognize that this is an area that people haven’t really wrapped their heads around in terms of how to secure it, and they’re going to exploit that, and that’s what worries her most about the advances in AI as it relates to supply chain security. 

However, it’s not all bad; in many ways, supply chain security can benefit from AI assistance. For instance, there are now software composition analysis tools that are using generative AI to explain vulnerabilities to developers and offer recommendations on how to fix it, Worthington explained. 

“I think AI will help the attackers but I think the first wave is actually helping defenders at this point,” she said. 

Bell was in agreement, adding “if you’re defending, it’s going to improve the threat detection, it’s going to help with incident response, and it’s going to help with detecting whether vulnerabilities are real.”

The government is starting to play a role in securing supply chains

In 2021, President Biden signed an executive order addressing the need to have stronger software supply chain security in government. In it, Biden explained that bold change is needed over incremental improvements, and stated that this would be a top priority for the administration. 

The executive order requires that any company selling software to the government provide an SBOM and set up a pilot program to create an “energy star” type program for software so that the government can easily see if software was developed securely. 

“Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit,” the White House explained. “This is a long-standing, well-known problem, but for too long we have kicked the can down the road. We need to use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.” 

Worthington said: “I think the Biden administration has done a really good job of trying to help software suppliers understand sort of like what the minimum requirements they’re going to be held to are, and I think those are probably the best place to start.”

Cuddy agreed and added that the industry is starting to catch up to the requirements. “Not only do you need to generate a bill of materials, but you have to be able to validate across it, you have to prove that you’ve been testing against it, that you’ve authorized those components … So much of it started with the executive order that was issued a few years ago from President Biden, and you’ve now seen the commercial side starting to catch up with some of those things, and really demanding it more,” he said.

The post Companies still need to work on security fundamentals to win in the supply chain security fight appeared first on SD Times.

They talk about how it will remove menial, repetitive tasks to free up developers to work on higher value projects. They talk about LLMs, and model training, and GenAI, and trust.

Our view from the cheap seats is seeing how AI touches just about every piece in the software development and delivery life cycle. It’s seen in code, where it helps developers avoid creating errors and adhere to governance, and spotting fixes before the code is deployed. It’s in test automation, where low-code tools and AI are creating tests and recommending fixes to where tests fail. It’s in CI/CD pipelines, where it manages code changes, catching errors early and predicting what tasks need to be done. And it’s in security, where it can detect bad actors targeting your applications, locate vulnerabilities and offer remediation guidance.

In this year’s SD Times 100, we’ve included an AI category, listing the companies that have led the way to this point, and include in other categories companies that have built AI into their offerings already.

Change is inevitable, but seldom has the uptake of new technology advanced so rapidly to change an entire industry – and, in fact, it will continue to change all industries.

We salute the 2024 SD Times 100 honorees.

• AI 2024
• APIs and Integrations 2024
• Data and Database Management 2024
• Developer Experience 2024
• Development Tools 2024
• DevOps 2024
• Low-Code/No-Code 2024
• Observability 2024
• Security 2024
• Testing 2024
• Value Stream Management 2024

The post SD Times 100 appeared first on SD Times.

In a recent survey, the research firm Forrester asked security decision makers in which phase of the application lifecycle did they plan to adopt the following technologies.  Static application security testing (SAST) was at 34%, software composition analysis (SCA) was 37%, dynamic application security testing (DAST) was 50% and interactive application security testing (IAST) was at 40%. Janet Worthington, a senior analyst at Forrester advising security and risk professionals, said the number of people planning to adopt SAST was low because it’s already well-known and people have already implemented the practice and tools.

One of the drivers for that adoption was the awakening created by the log4j vulnerability, where, she said, developers using open source understand direct dependencies but might not consider dependencies of dependencies.

Open source and SCA

According to Forrester research, 53% of breaches from external attacks are attributed to the application and the application layer. Worthington explained that while organizations are implementing SAST, DAST and SCA, they are not implementing it for all of their applications. “When we look at the different tools like SAST and SCA, for example, we’re seeing more people actually running software composition analysis on their customer-facing applications,” she said. “And SAST is getting there as well, but almost 75% of the respondents who we asked are running SCA on all of their external-facing applications, and that, if you can believe it, is much larger than web application firewalls, and WAFs are actually there to protect all your customer-facing applications. Less than 40% of the respondents will say they cover all their applications.”

Worthington went on to say that more organizations are seeing the need for software composition analysis because of those breaches, but added that a problem with security testing today is that some of the older tools make it harder to integrate early on in the development life cycle. That is when developers are writing their code, committing code in the CI/CD pipeline, and on merge requests. “The reason we’re seeing more SCA and SAST tools there is because developers get that immediate feedback of, hey, there’s something up with the code that you just checked in. It’s still going to be in the context of what they’re thinking about before they move on to the next sprint. And it’s the best place to kind of give them that feedback.”

RELATED CONTENT: A guide to security testing tools

The best tools, she said, are not only doing that, but they’re providing very good remediation guidance. “What I mean by that is, they’re providing code examples, to say, ‘Hey, somebody found something similar to what you’re trying to do. Want to fix it this way?'”

Rob Cuddy, customer experience executive at HCL Software, said the company is seeing an uptick in remediation. Engineers, he said, say, “’I can find stuff really well, but I don’t know how to fix it. So help me do that.’ Auto remediation, I think, is going to be something that continues to grow.”

Securing APIs

When asked what the respondents were planning to use during the development phase, Worthington said, 50% said they are planning to implement DAST in development. “Five years ago you wouldn’t have seen that, and what this really calls attention to is API security,” Worthington said. “[That is] something everyone is trying to get a handle on in terms of what APIs they have, the inventory, what APIs are governed, and what APIs are secured in production.”

And now, she added, people are putting more emphasis on trying to understand what APIs they have, and what vulnerabilities may exist in them, during the pre-release phase or prior to production. DAST in development signals an API security approach, she said, because “as you’re developing, you develop the APIs first before you develop your web application.” Forrester, she said, is seeing that as an indicator of companies embracing DevSecOps, and that they are looking to test those APIs early in the development cycle.

API security also has a part in software supply chain security, with IAST playing a growing role, and encompassing parts of SCA as well, according to Colin Bell, AppScan CTO at HCL Software. “Supply chain is more a process than it is necessarily any feature of a product,” Bell said. “Products feed into that. So SAST and DAST and IAST all feed into the software supply chain, but bringing that together is something that we’re working on, and maybe even looking at partners to help.”

Forrester’s Worthington explained that DAST really is black box testing, meaning it doesn’t have any insights into the application. “You typically have to have a running version of your web application up, and it’s sending HTTP requests to try and simulate an attacker,” she said. “Now we’re seeing more developer-focused test tools that don’t actually need to hit the web application, they can hit the APIs. And that’s now where you’re going to secure things – at the API level.”

The way this works, she said, is you use your own functional tests that you use for QA, like smoke tests and automated functional tests. And what IAST does is it watches everything that the application is doing and tries to figure out if there are any vulnerable code paths.

Introducing AI into security

Cuddy and Bell both said they are seeing more organizations building AI and machine learning into their offerings, particularly in the areas of cloud security, governance and risk management.

Historically, organizations have operated with a level of what is acceptable risk and what is not, and have understood their threshold. Yet cybersecurity has changed that dramatically, such as when a zero-day event occurs but organizations haven’t been able to assess that risk before. 

“The best example we’ve had recently of this is what happened with the log4j scenario, where all of a sudden, something that people had been using for a decade, that was completely benign, we found one use case that suddenly means we can get remote code execution and take over,” Cuddy said. “So how do you assess that kind of risk? If you’re primarily basing risk on an insurance threshold or a cost metric, you may be in a little bit of trouble, because things that today are under that threshold that you think are not a problem could suddenly turn into one a year later.”

That, he said, is where machine learning and AI come in, with the ability to run thousands – if not millions – of scenarios to see if something within the application can be exploited in a particular fashion. And Cuddy pointed out that as most organizations are using AI to prevent attacks, there are unethical people using AI to find vulnerabilities to exploit. 

He predicted that five or 10 years down the road, you will ask AI to generate an application according to the data input and prompts it is given.  And the AI will write code, but it’ll be the most efficient, machine-to-machine code that humans might not even understand, he noted. 

That will turn around the need for developers. But it comes back to the question of how far out is that going to happen. “Then,” Bell said, “it becomes much more important to worry about, and testing now becomes more important. And we’ll probably move more towards the traditional testing of the finished product and black box testing, as opposed to testing the code, because what’s the point of testing the code when we can’t read the code? It becomes a very different approach.”

Governance, risk and compliance

Cuddy said HCL is seeing the roles of governance, risk and compliance coming together, where in a lot of organizations, those tend to be three different disciplines. And there’s a push for having them work together and connect seamlessly. “And we see that showing up in the regulations themselves,” he said. 

“Things like NYDFS [New York Department of Financial Services] regulation is one of my favorite examples of this,” he continued. “Years ago, they would say things like you have to have a robust application security program, and we’d all scratch our heads trying to figure out what robust meant. Now, when you go and look, you have a very detailed listing of all of the different aspects that you now have to comply with. And those are audited every year. And you have to have people dedicated to that responsibility. So we’re seeing the regulations are now catching up with that, and making the specificity drive the conversation forward.”

The cost of cybersecurity

The cost of cybersecurity attacks continues to climb as organizations fail to implement safeguards necessary to defend against ransomware attacks. Cuddy discussed the costs of implementing security versus the cost of paying a ransom.

“A year ago, there were probably a lot more of the hey, you know, look at the level, pay the ransom, it’s easier,” he said. But, even if organizations pay the ransom, Cuddy said “there’s no guarantee that if we pay the ransom, we’re going to get a key that actually works, that’s going to decrypt everything.”

But cyber insurance companies have been paying out huge sums and are now requiring organizations to do their own due diligence, and are raising the bar on what you need to do to remain insured. “They have gotten smart and they’ve realized ‘Hey, we’re paying out an awful lot in these ransomware things. So you better have some due diligence.’ And so what’s happening now is they are raising the bar on what’s going to happen to you to stay insured.”

“MGM could tell you their horror stories of being down and literally having everything down – every slot machine, every ATM machine, every cash register,” Cuddy said. And again, there’s no guarantee that if you pay off the ransom, that you’re going to be fine. “In fact,” he added, “I would argue you’re likely to be attacked again, by the same group. Because now they’ll just go somewhere else and ransom something else. So I think the cost of not doing it is worse than the cost of implementing good security practices and good measures to be able to deal with that.” 

When applications are used in unexpected ways

Software testers repeatedly say it’s impossible to test for ways people might use an application that is not intended. How can you defend against something that you haven’t even thought of?

Rob Cuddy, customer experience executive at HCL Software, tells of how he learned of the log4j vulnerability.

“Honestly, I found out about it through Minecraft, that my son was playing Minecraft that day. And I immediately ran up into his room, and I’m like, ‘Hey, are you seeing any bizarre things coming through in the chat here that look like weird textures that don’t make any sense?’ So who would have anticipated that?”

Cuddy also related a story from earlier in his career about unintended use and how it was dealt with and how organizations harden against that.

“There is always going to be that edge case that your average developer didn’t think about,” he began. “Earlier in my career, doing finite element modeling, I was using a three-dimensional tool, and I was playing around in it one day, and you could make a join of two planes together with a fillet. And I had asked for a radius on that. Well, I didn’t know any better. So I started using just typical numbers, right? 0, 180, 90, whatever. One of them, I believe it was 90 degrees, caused the software to crash, the window just completely disappeared, everything died.

“So I filed a ticket on it, thinking our software shouldn’t do that. Couple of days later, I get a much more senior gentleman running into my office going, ‘Did you file this? What the heck is wrong with you? Like this is a mathematical impossibility. There’s no such thing as a 90-degree fillet radius.’ But my argument to him was it shouldn’t crash. Long story short, I talk with his manager, and it’s basically yes, software shouldn’t crash, we need to go fix this. So that senior guy never thought that a young, inexperienced, just fresh out of college guy would come in and misuse the software in a way that was mathematically impossible. So he never accounted for it. So there was nothing to fix. But one day, it happened, right. That’s what’s going on in security, somebody’s going to attack in a way that we have no idea of, and it’s going to happen. And can we respond at that point?”  

The post <span class="sdt-premium">premium</span> The importance of security testing appeared first on SD Times.

Register for Improve: Testing here

Hear from 8 testing experts, including:

• Jason English, director and principal analyst at Intellyx
• Arthur Hicken, evangelist at Parasoft
• Peter McKee, head of developer relations and community at Sonar

Across the 8 total sessions, you’ll hear from our invited experts about a range of topics, including the new phenomenon of “hidden” software testing, what metrics to use to improve your testing practice, and how QA can be used to build trust and connection in software development.

The event is now available to watch on demand.

The post Watch Improve: Testing appeared first on SD Times.

One software category that is particularly well-suited to being boosted by AI is low code, as that is already a market that has a goal of making things easier on developers. 

Just as low code lowered the bar to entry for development, generative AI will have a similar impact because of such things as code completion and workflow automation. But Kyle Davis, VP analyst at Gartner,  believes that the two technologies will interact in more of a collaborative effort than a competitive way, at least for citizen developers. “Even though you could use generative AI to generate code, if you don’t understand what the code is doing, there’s no way to validate that it’s correct,” he said. “Using low code, it’s declarative, so you can look at what’s there on the screen and say, ‘does that make sense?’”

RELATED CONTENT: A guide to low-code vendors that incorporate generative AI capabilities

However, Davis also says it’s really too new of a market to make any real predictions. “We’ve seen a lot of failure, we’ve seen a lot of success, because it’s so early days that, at best, you’re kind of experimenting with this now. But the hope is that it can offer a lot of potential,” he explained. 

According to Davis, there are three main ways AI is being incorporated into low-code platforms. 

First, there are generative AI capabilities that are designed to improve the developer experience.

Second, there are generative AI capabilities targeting the end users of the application created using low code. “So embedding like a Copilot or ChatGPT type control within the application. That way the user of the application can ask questions about the app’s data, as an example,” Davis said. 

Third, there are features related to process improvement. “When you’re creating workflows or automation, there’s usually a lot of steps that are very human-centric, when it comes to generating data or categorizing data or whatnot,” Davis said. “And so we’ve seen a lot of those steps being not displaced by a generative AI step, but rather kind of preceded by a generative AI step.”

He gave the example of a workflow that is designed to help hiring managers create requirements for a job position. Usually the hiring manager has to go in and manually add information, like the name of the position, the description, and other requirements. But, Davis said, “If generative AI were to step in first and do a draft of that, it allows the hiring manager to come in and just make refinements.” 

Davis believes that a major challenge experienced by these low-code vendors is the added work placed on them to enable this integration to work. Low code is very declarative and abstracted away, and the constructs that make up a low-code application are proprietary to the platform it belongs to, which requires the vendors to either have their own LLM or be able to take user prompts and create all the constructs within their platform to represent what was asked. 

“There’s a lot they can leverage from existing LLMs and, and generative AI vendors, but there’s still pieces that they have to do themselves,” he said. 

Using generative AI in testing is another promising area

Combining generative AI and testing is also a promising mashup, according to Arthur Hicken, chief evangelist at testing software company Parasoft. “We’re still at a relatively early stage, so it’ll be interesting to see how much of it is real and how much of it pans out,” he said. “It certainly shows a lot of promise in the ability to generate code, but perhaps more so in the ability to generate tests … I don’t believe we’re there yet, but we are seeing some pretty interesting capabilities that, you know, didn’t exist a year or two ago.”

The field of prompt engineering — phrasing generative AI requests in a way that will provide optimal results — is also an emerging practice, which will be crucial to how successful one is at getting good results from combining things like testing or low-code with AI, Hicken said.

He explained that those who have been working with tests for years will probably have a good chance of being a good prompt engineer. “That ability to look at something and break it into small component steps is what’s going to let the AI be most effective for you … You can’t go to one of these systems and say, ‘Hey, give me a bunch of tests for my application.’ It’s not going to work. You’ve got to be very, very detailed, and like working with a djinn or a genie, you can mess yourself up if you’re not very careful about what you ask for,” he said.

He likened this to how we see people interacting with search engines today. Some people claim they can find whatever they want in a search engine, because they know the queries to ask, while others will say they looked all over and couldn’t find what they were looking for. 

“It’s that ability to speak in a way that the AI can understand you, and the better you are at that the better answer you get back … The fact that you can just talk and ask for what you want is cool, but at the moment you better be pretty smart about what you’re asking because with these AIs the emphasis is on the A – the intelligence is very artificial,” said Hicken.

 This is why testing the outputs of these systems is crucial. Hicken said that he has spoken with folks who say they are going to use generative AI to generate both code and tests. “That’s really scary, right? Now we’ve got code a human didn’t review being checked by tests that weren’t reviewed by humans, like, are we going to compound the error?”

He advises against putting too much trust in these systems just yet.  “We’re already starting to see people jump back, they’re being bitten, because they’re trusting the system too early,” he said. “So I would encourage people not to blindly trust the system. It’s like hiring somebody and just letting them write your most important code without seeing first what they’re doing.”

The post <span class="sdt-premium">premium</span> The promise of generative AI in low-code, testing appeared first on SD Times.

The post <span class="sdt-premium">premium</span> AI-Powered Testing Tools: A Guide for Buyers appeared first on SD Times.

1. APIs and Integrations
2. Data and Database Management
3. Value Stream Management
4. Development Tools
5. DevOps Tools
6. Security
7. Performance Monitoring
8. Testing
9. Innovation Leaders
10. Low Code and Digital Transformation

The list is determined by SD Times editors, based on the observations we have made over the last year.

The post 2023 SD Times 100 appeared first on SD Times.

The post <span class="sdt-premium">premium</span> SD Times May 2023 appeared first on SD Times.

The post <span class="sdt-premium">premium</span> SD Times April 2023 appeared first on SD Times.