DZone Spotlight

Hey, folks. I’m an AI geek who’s spent years wrestling with large language models (LLMs) like GPT-4. They’re incredible — chatting, coding, reasoning like champs — but they’ve got a flaw: they’re trained on the wild web, soaking up biases like gender stereotypes or racial skews. Picture an LLM skipping a top-notch female data scientist because it’s hung up on “tech = male.” That’s a real danger in hiring or healthcare apps, and it’s why I’ve poured my energy into Knowledge Graph-Augmented Training (KGAT). In this tutorial, I’ll share my approach. Straight from my work, like Detecting and Mitigating Bias in LLMs through Knowledge Graph-Augmented Training (Zenodo) with code and steps to try it yourself! The Bias Mess: Why I Dug In LLMs feast on internet chaos — tweets, blogs, the works — and inherit our messy biases. Feed one resumes, and it might favor “Mike” over “Maya” for a coding gig, echoing old patterns. My experiments with Bias in Bios showed this isn’t just talk — gender and racial skews pop up fast. Old fixes like data tweaks or fairness rules? They’re quick patches that don’t tackle the root or keep the model’s spark alive. That’s why I turned to knowledge graphs (KGs) — my game-changer. KGAT: My Fix for Better AI Imagine a knowledge graph as a fact-web — nodes like “engineer” or “woman” linked by edges like “works as.” My KGAT method, detailed in my enterprise intelligence paper, pairs this structured map with LLMs to cut bias and boost smarts. Here’s my playbook: Pick an LLM: I start with a beast like GPT-4.Add a KG: I hook it to a factual graph (Wikidata or custom) full of real connections.Train smart: Fine-tune it to cross-check text guesses with KG facts. This isn’t just about ethics — my enterprise pilots hit a 20% productivity spike! It’s in my Detecting and Mitigating Bias in LLMs talk at AIII 2025 (schedule). KGAT’s a business turbocharger, too. Hands-On: Build It With Me Let’s code up my KGAT pipeline. Here’s how I roll: 1. Prep the Data I use datasets like these to test bias and brains: Bias in Bios: Resumes with job/gender tags (source).FairFace: Faces with race/gender labels (source).COMPAS: Recidivism data for fairness (source). Clean lowercase text, ditch noise, and link entities (e.g., “data scientist”) to Wikidata. I keep it basic with simple entity matching for starters. 2. Wire Up the KG I lean on graph neural networks (GNNs) to turn KGs into vectors that LLMs can digest. My setup: Python import torch from torch_geometric.nn import GCNConv from transformers import GPT2Tokenizer, GPT2Model # Load LLM (GPT-2 for this demo) tokenizer = GPT2Tokenizer.from_pretrained('gpt2') model = GPT2Model.from_pretrained('gpt2') # My GNN layer (KG—swap in yours) gcn = GCNConv(in_channels=128, out_channels=768) # Match LLM dims kg_nodes = torch.rand(10, 128) # 10 nodes, 128-dim features kg_edges = torch.tensor([[0, 1], [1, 2], [2, 0]]) # Simple edges kg_emb = gcn(kg_nodes, kg_edges) # KG vectors ready 3. Blend and Train I merge LLM and KG embeddings with my formula: E_integrated = E_LLM ⊕ E_KG (just glue ‘em together). Training kickoff: Python # text embeddings (use your tokenized data) text_emb = torch.rand(32, 768) # Batch of 32, 768-dim integrated_emb = torch.cat([text_emb, kg_emb[:32]], dim=1) # Match sizes # Fine-tune (super simplified) outputs = model(inputs_embeds=integrated_emb) loss = outputs.loss # Add a real loss later loss.backward() # Optimize with Adam soon print("KGAT’s rolling!") For real runs, I use Adam (learning rate 3e-5, batch size 32, 10 epochs) — my go-to from the bias work. 4. Hunt Down Bias I track bias with metrics I swear by: Demographic parity: Equal positives across groups.Equal opportunity: Fair true-positive rates. Quick test: Python from sklearn.metrics import confusion_matrix # Dummy preds vs. truth y_true = [0, 1, 0, 1] y_pred = [0, 1, 1, 0] tn, fp, fn, tp = confusion_matrix(y_true, y_pred).ravel() equal_opp = tp / (tp + fn) print(f"Equal Opportunity: {equal_opp:.2f}") My results? Bias in Bios parity up 15%, COMPAS fairness up 10% — huge for trust in real apps. Why This Fires Me Up (and Should You) KGAT’s my passion because: Fairness counts: Biased AI can tank your app or harm users — I’m here to stop that.Scales big: My framework flexes with Wikidata or your own KG — enterprise-ready.Smarter AI: That 20% productivity lift? It’s KGs making LLMs brilliant, not just nice. Picture a hiring bot without KGAT; it skips “Priya” for “Pete.” With my method, it sees “data scientist” isn’t gendered and picks the best. Watch Out: My Hard-Earned Tips KGAT’s not perfect — I’ve hit snags: KG quality: A weak graph (e.g., outdated roles) can flop. I vet mine hard.Compute load: GNNs and LLMs need power — I lean on GPUs or the cloud.Big data: Millions of records? I chunk it or go parallel. Try It Out: My Challenge to You Start small with my approach: Grab Bias in Bios and a Wikidata slice.Use torch-geometric for GNNs and transformers for GPT-2 (or GPT-4 if you can).Tweak my code. Add real embeddings and a loss like cross-entropy. My pilots and bias talks show these scales — your next project could rock with it. My Take: Let’s Build Better AI KGAT’s my ticket to LLMs that don’t just dazzle but deliver — fair, smart, and ready to roll. It’s not just research; it’s hands-on and proven in my work. Fire up that code, test a dataset, and share your wins below. I’m stoked to see what you do with it! Dig deeper? Check my presentation on Zenodo or join me at DZone!

Hey, DZone Community! We have an exciting year of research ahead for our beloved Trend Reports. And once again, we are asking for your insights and expertise (anonymously if you choose) — readers just like you drive the content we cover in our Trend Reports. Check out the details for our research survey below. Comic by Daniel Stori API Management Research APIs already do a great job ensuring secure and seamless connections within systems, sure — but can they do even better? At DZone, we're untangling trends like API-first development and democratization to learn how they empower development teams to implement APIs progressively. Take our short research survey ( ~10 minutes) to contribute to our latest findings. We're exploring key topics, including: Streamlining API integrationAI for APIsAPI security, performance, and observabilityMessaging infrastructure Join the API Management Research Over the coming month, we will compile and analyze data from hundreds of respondents; results and observations will be featured in the "Key Research Findings" of our Trend Reports. Your responses help inform the narrative of our Trend Reports, so we truly cannot do this without you. Stay tuned for each report's launch and see how your insights align with the larger DZone Community. We thank you in advance for your help! —The DZone Content and Community team

Data migration is like moving house — every data engineer has faced this headache: a pile of SQL statements that need rewriting, as if you have to disassemble and reassemble all the furniture. Different systems' SQL syntax is like different dialects. Although they all speak the SQL language, each has its own "accent" and habits. "If only there were a 'translator'!" This is probably the wish of every engineer who has experienced system migration. Today, I want to introduce a magical "translator" — Apache Doris's SQL dialect conversion feature. It can understand more than ten SQL dialects, including Presto, Trino, Hive, ClickHouse, and Oracle, and can automatically complete the conversion for you! Doris SQL Dialect Compatibility: Smooth Data Migration Like Silk "Facing system migration, SQL rewriting is like playing Tetris — one wrong move and you're in trouble." This sentence voices the sentiment of many data engineers. As data scales grow and businesses evolve, companies often need to migrate data from one system to another. The most painful part of this process is undoubtedly the compatibility of SQL syntax. Each data system has its unique SQL dialect, just like each place has its own dialect. Although they all speak SQL, each has its own "accent." When you need to migrate data from Presto/Trino, ClickHouse, or Hive to Doris, hundreds or even thousands of SQL statements need to be rewritten, which is undoubtedly a huge project. Apache Doris understands this pain. In version 2.1, Doris introduced the SQL dialect compatibility feature, supporting more than ten mainstream SQL dialects, including Presto, Trino, Hive, ClickHouse, and Oracle. Users only need to set a simple session variable to let Doris directly understand and execute the SQL syntax of other systems. Compatibility tests show that in some users' actual business scenarios, Doris' compatibility with Presto SQL reaches as high as 99.6%, and with the ClickHouse dialect, it reaches 98%. This means that the vast majority of SQL statements can run directly in Doris without modification. For data engineers, it is like holding a universal translator. No matter which SQL "dialect" it is, it can be automatically converted into a language that Doris can understand. System migration no longer requires manually rewriting a large number of SQL statements, greatly reducing the cost and risk of migration. From "Dialect Dilemma" to "Language Master" Zhang Gong is an experienced data engineer who recently received a challenging task — to migrate the company's data analysis platform from ClickHouse to Apache Doris. Faced with hundreds of SQL statements, he couldn't help but rub his temples. "If only there were a tool to directly convert ClickHouse SQL to Doris," Zhang Gong muttered to himself. It was then that he discovered Doris' SQL dialect compatibility feature. Let's follow Zhang Gong's steps to see how he solved this problem: First, download the latest version of the SQL dialect conversion tool. On any FE node, start the service with the following commands: Shell # config port vim apiserver/conf/config.conf # start SQL Converter for Apache Doris sh apiserver/bin/start.sh # webserver vim webserver/conf/config.conf # webserver start sh webserver/bin/start.sh Start the Doris cluster (version 2.1 or higher), and after the service is started, set the SQL conversion service address in Doris: SQL set global sql_converter_service_url = "http://127.0.0.1:5001/api/v1/convert" Then, switch the SQL dialect with just one command: SQL set sql_dialect=clickhouse; That's it! Zhang Gong found that SQL statements that originally needed to be manually rewritten could now be executed directly in Doris: SQL mysql> select toString(start_time) as col1, arrayCompact(arr_int) as col2, arrayFilter(x -> x like '%World%',arr_str)as col3, toDate(value) as col4, toYear(start_time)as col5, addMonths(start_time, 1)as col6, extractAll(value, '-.')as col7, JSONExtractString('{"id": "33"}' , 'id')as col8, arrayElement(arr_int, 1) as col9, date_trunc('day',start_time) as col10 FROM test_sqlconvert where date_trunc('day',start_time)= '2024-05-20 00:00:00' order by id; +---------------------+-----------+-----------+------------+------+---------------------+-------------+------+------+---------------------+ | col1 | col2 | col3 | col4 | col5 | col6 | col7 | col8 | col9 | col10 | +---------------------+-----------+-----------+------------+------+---------------------+-------------+------+------+---------------------+ | 2024-05-20 13:14:52 | [1, 2, 3] | ["World"] | 2024-01-14 | 2024 | 2024-06-20 13:14:52 | ['-0','-1'] | "33" | 1 | 2024-05-20 00:00:00 | +---------------------+-----------+-----------+------------+------+---------------------+-------------+------+------+---------------------+ 1 row in set (0.02 sec) "This is simply amazing!" Zhang Gong was pleasantly surprised to find that this seemingly complex ClickHouse SQL statement was perfectly executed. Not only that, but he also discovered that Doris provides a visual interface that supports both text input and file upload modes. For a single SQL statement, users can directly input text in the web interface. If there are a large number of existing SQL statements, you can upload files for one-click batch conversion of multiple SQL statements: Through the visual interface, Zhang Gong can upload SQL files in batches and complete the conversion with one click. "This is like having a universal translator that can seamlessly switch between ClickHouse and other SQL dialects," Zhang Gong exclaimed. What's more, he was delighted to find that the accuracy of this "translator" is quite high. In actual testing, the compatibility with Presto SQL reaches 99.6%, and with ClickHouse, it reaches 98%. This means that the vast majority of SQL statements can be used directly, greatly improving migration efficiency. The pressure of the data migration project was greatly reduced, and Zhang Gong could finally get a good night's sleep. However, he still had a small concern: "What if there are unsupported syntaxes?" At this point, he found that Doris' development team values user feedback highly. Through communities, Ask forums, GitHub Issues, or mailing lists, users can provide feedback anytime to promote the continuous optimization and improvement of the SQL dialect conversion feature. This open and user feedback-oriented attitude gives Zhang Gong great confidence for the future. "Next time I encounter a data migration project, I know which 'magic tool' to use!" Stay tuned for more interesting, useful, and valuable content in the next issue!

In my last post, I wrote about how quick and easy it is to turn an idea into reality. I built a Spring Boot API service using Gradle as my build management tool and then deployed it to Heroku. But what about my readers who have Maven in their toolchain? In this post, I’ll walk through the same project, but we'll look at how to accomplish the same result with Maven. And we'll see how Heroku makes deploying your Java apps and services seamless, regardless of the build tool you use. The Motivational Quotes API In my prior article, I sent the following request to ChatGPT: With some minor tweaks, I settled on the following OpenAPI specification in YAML format (saved as openapi.yaml): YAML openapi: 3.0.0 info: title: Motivational Quotes API description: An API that provides motivational quotes. version: 1.0.0 servers: - url: https://api.example.com description: Production server paths: /quotes: get: summary: Get all motivational quotes operationId: getAllQuotes responses: '200': description: A list of motivational quotes content: application/json: schema: type: array items: $ref: '#/components/schemas/Quote' /quotes/random: get: summary: Get a random motivational quote operationId: getRandomQuote responses: '200': description: A random motivational quote content: application/json: schema: $ref: '#/components/schemas/Quote' /quotes/{id}: get: summary: Get a motivational quote by ID operationId: getQuoteById parameters: - name: id in: path required: true schema: type: integer responses: '200': description: A motivational quote content: application/json: schema: $ref: '#/components/schemas/Quote' '404': description: Quote not found components: schemas: Quote: type: object required: - id - quote properties: id: type: integer quote: type: string Assumptions Like last time, we’re going to keep things simple. We’ll use Java 17 and Spring Boot 3 to create a RESTful API. This time, we’ll use Maven for our build automation. Like before, we won’t worry about adding a persistence layer, and we’ll continue to allow anonymous access to the API. Building the Spring Boot Service Using API-First Again, I’ll use the Spring Boot CLI to create a new project. Here’s how you can install the CLI using Homebrew: Shell $ brew tap spring-io/tap $ brew install spring-boot Create a new Spring Boot Service Using Maven We’ll call our new project quotes-maven and create it with the following command: Shell $ spring init --build=maven \ --package-name=com.example.quotes \ --dependencies=web,validation quotes-maven Notice how we specify the use of Maven for the build system instead of the default, Gradle. I also specify the com.example.quotes package name so that I can simply copy and paste the business code from the Gradle-based service to this service. Here are the contents of the quotes-maven folder: Shell $ cd quotes-maven && ls -la total 72 drwxr-xr-x 10 johnvester 320 Mar 15 10:49 . drwxrwxrwx 89 root 2848 Mar 15 10:49 .. -rw-r--r-- 1 johnvester 38 Mar 15 10:49 .gitattributes -rw-r--r-- 1 johnvester 395 Mar 15 10:49 .gitignore drwxr-xr-x 3 johnvester 96 Mar 15 10:49 .mvn -rw-r--r-- 1 johnvester 1601 Mar 15 10:49 HELP.md -rwxr-xr-x 1 johnvester 10665 Mar 15 10:49 mvnw -rw-r--r-- 1 johnvester 6912 Mar 15 10:49 mvnw.cmd -rw-r--r-- 1 johnvester 1535 Mar 15 10:49 pom.xml drwxr-xr-x 4 johnvester 128 Mar 15 10:49 src Next, we edit the pom.xml file to adopt the API-First approach. The resulting file looks like this: XML <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.4.3</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.example</groupId> <artifactId>quotes-maven</artifactId> <version>0.0.1-SNAPSHOT</version> <name>demo</name> <description>Demo project for Spring Boot</description> <url/> <licenses> <license/> </licenses> <developers> <developer/> </developers> <scm> <connection/> <developerConnection/> <tag/> <url/> </scm> <properties> <java.version>17</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>org.springdoc</groupId> <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId> <version>2.8.5</version> </dependency> <dependency> <groupId>org.openapitools</groupId> <artifactId>jackson-databind-nullable</artifactId> <version>0.2.6</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.openapitools</groupId> <artifactId>openapi-generator-maven-plugin</artifactId> <version>7.12.0</version> <!-- Use the latest version --> <executions> <execution> <goals> <goal>generate</goal> </goals> </execution> </executions> <configuration> <inputSpec>${project.basedir}/src/main/resources/static/openapi.yaml</inputSpec> <output>${project.build.directory}/generated-sources/openapi</output> <generatorName>spring</generatorName> <apiPackage>com.example.api</apiPackage> <modelPackage>com.example.model</modelPackage> <invokerPackage>com.example.invoker</invokerPackage> <configOptions> <dateLibrary>java8</dateLibrary> <interfaceOnly>true</interfaceOnly> <useSpringBoot3>true</useSpringBoot3> <useBeanValidation>true</useBeanValidation> <skipDefaultInterface>true</skipDefaultInterface> </configOptions> </configuration> </plugin> </plugins> </build> </project> Then, we place openapi.yaml into the resources/static folder and create a file called application.yaml, placing it in the resources folder: YAML server: port: ${PORT:8080} spring: application: name: demo springdoc: swagger-ui: path: /swagger-docs url: openapi.yaml Finally, we create the following banner.txt file and place it into the resources folder: Shell ${AnsiColor.BLUE} _ __ _ _ _ ___ | |_ ___ ___ / _` | | | |/ _ \| __/ _ \/ __| | (_| | |_| | (_) | || __/\__ \ \__, |\__,_|\___/ \__\___||___/ |_| ${AnsiColor.DEFAULT} :: Running Spring Boot ${AnsiColor.BLUE}${spring-boot.version}${AnsiColor.DEFAULT} :: Port #${AnsiColor.BLUE}${server.port}${AnsiColor.DEFAULT} :: We can start the Spring Boot service to ensure everything works as expected. Looks good! Add the Business Logic With the base service ready and already adhering to our OpenAPI contract, we add the business logic to the service. To avoid repeating myself, you can refer to my last article for implementation details. Clone the quotes repository, then copy and paste the controllers, repositories, and services packages into this project. Since we matched the package name from the original project, there should not be any updates required. We have a fully functional Motivational Quotes API with a small collection of responses. Now, let’s see how quickly we can deploy our service. Using Heroku to Finish the Journey Since Heroku is a great fit for deploying Spring Boot services, I wanted to demonstrate how using the Maven build system is just as easy as using Gradle. Going with Heroku allows me to deploy my services quickly without losing time dealing with infrastructure concerns. To match the Java version we’re using, we create a system.properties file in the root folder of the project. The file has one line: Properties files java.runtime.version = 17 Then, I create a Procfile in the same location for customizing the deployment behavior. This file also has one line: Shell web: java -jar target/quotes-maven-0.0.1-SNAPSHOT.jar It’s time to deploy. With the Heroku CLI, I can deploy the service using a few simple commands. First, I authenticate the CLI and then create a new Heroku app. Shell $ heroku login $ heroku create Creating app... done, polar-caverns-69037 https://polar-caverns-69037-f51c2cc7ef79.herokuapp.com/ | https://git.heroku.com/polar-caverns-69037.git My Heroku app instance is named polar-caverns-69037, so my service will run at https://polar-caverns-69037-f51c2cc7ef79.herokuapp.com/. One last thing to do … push the code to Heroku, which deploys the service: Shell $ git push heroku master Once this command is complete, we can validate a successful deployment via the Heroku dashboard: We’re up and running. It’s time to test. Motivational Quotes in Action With our service running on Heroku, we can send some curl requests to make sure everything works as expected. First, we retrieve the list of quotes: Shell $ curl \ --location \ 'https://polar-caverns-69037-f51c2cc7ef79.herokuapp.com/quotes' JSON [ { "id":1, "quote":"The greatest glory in living lies not in never falling, but in rising every time we fall." }, { "id":2, "quote":"The way to get started is to quit talking and begin doing." }, { "id":3, "quote":"Your time is limited, so don't waste it living someone else's life." }, { "id":4, "quote":"If life were predictable it would cease to be life, and be without flavor." }, { "id":5, "quote":"If you set your goals ridiculously high and it's a failure, you will fail above everyone else's success." } ] We can retrieve a single quote by its ID: Shell $ curl \ --location \ 'https://polar-caverns-69037-f51c2cc7ef79.herokuapp.com/quotes/3' JSON { "id":3, "quote":"Your time is limited, so don't waste it living someone else's life." } We can retrieve a random motivational quote: Shell $ curl --location \ 'https://polar-caverns-69037-f51c2cc7ef79.herokuapp.com/quotes/random' JSON { "id":4, "quote":"If life were predictable it would cease to be life, and be without flavor." } We can even browse the Swagger Docs too: Returning to the Heroku dashboard, we see some activity on our new service: Gradle Versus Maven Using either Gradle or Maven, we quickly established a brand new RESTful API and deployed it to Heroku. But which one should you use? Which is a better fit for your project? To answer this question, I asked ChatGPT again. Just like when I asked for an OpenAPI specification, I received a pretty impressive summary: Gradle is great for fast builds, flexibility, and managing multi-projects or polyglot environments. It's ideal for modern workflows and when you need high customization.Maven is better for standardized builds, simplicity, and when you need stable, long-term support with strong dependency management. I found this article from Better Projects Faster, which was published in early 2024 and focused on Java build tools with respect to job descriptions, Google searches, and Stack Overflow postings. While this information is a bit dated, it shows users continue to prefer (worldwide) Maven over Gradle: Over my career, I’ve been fortunate to use both build management tools, and this has helped minimize the learning curve associated with a new project. Even now, I find my team at Marqeta using both Gradle and Maven (nearly a 50/50 split) in our GitHub organization. Conclusion My readers may recall my personal mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester In this article, we saw how Spring Boot handled everything required to implement a RESTful API using the Maven build management tool. Once our code was ready, we realized our idea quickly by deploying to Heroku with just a few CLI commands. Spring Boot, Maven, and Heroku provided the frameworks and services so that I could remain focused on realizing my idea, not distracted by infrastructure and setup. Having chosen the right tools, I could deliver my idea quickly. If you’re interested, the source code for this article can be found on GitLab. Have a really great day!

By John Vester CORE

In 2023, a generative AI-powered chatbot for a financial firm mistakenly gave investment advice that violated compliance regulations, triggering regulatory scrutiny. Around the same time, an AI-powered medical summary tool misrepresented patient conditions, raising serious ethical concerns. As businesses rapidly adopt generative AI (GenAI), these incidents highlight a critical question: Can AI-generated content be trusted without human oversight? Generative AI is reshaping industries like retail, healthcare, and finance, with 65% of organizations already using it in at least one critical function, according to a 2024 McKinsey report (McKinsey, 2024). The speed and scale of AI-driven content generation are unprecedented, but with this power comes risk. AI-generated content can be misleading, biased, or factually incorrect, leading to reputational, legal, and ethical consequences if left unchecked. While it might be tempting to let large language models (LLMs) like GPT-4 operate autonomously, research highlights significant performance variability. A study testing GPT-4 across 27 real-world annotation tasks found that while the model performed well in structured settings, achieving precision and recall rates above 0.7, its performance dropped significantly in complex, context-dependent scenarios, sometimes falling below 0.5 (Pangakis & Wolken, 2024). In one-third of the tasks, GPT-4’s errors were substantial enough to introduce biases and inaccuracies, an unacceptable risk in high-stakes domains like healthcare, finance, and regulatory compliance. Key results from automated annotation performance using GPT-4 across 27 tasks (Pangakis & Wolken, 2024) Think of GPT-4 as an incredibly efficient research assistant, it rapidly gathers information (high recall) but lacks the precision or contextual awareness to ensure its outputs always meet the required standard. For instance, an AI writing tool for a skincare brand might generate an enticing but misleading product description: "Erases wrinkles in just 24 hours!". Such overpromising can violate advertising laws, mislead consumers, and damage brand credibility. Why Human Oversight Matters AI-generated content is reshaping how businesses communicate, advertise, and engage with customers, offering unparalleled efficiency at scale. However, without human oversight, AI-driven mistakes can lead to serious consequences, eroding trust, damaging reputations, or even triggering legal issues. According to Accenture’s Life Trends 2025 report, 59.9% of consumers now doubt the authenticity of online content due to the rapid influx of AI-generated material (Accenture, 2024). This growing skepticism raises a critical question: How can businesses ensure that AI-generated content remains credible and trustworthy? Meta has introduced AI-generated content labels across Facebook, Instagram, and Threads to help users distinguish AI-created images, signaling a growing recognition of the need for transparency in AI-generated content. But transparency alone isn’t enough — companies must go beyond AI disclaimers and actively build safeguards that ensure AI-generated content meets quality, ethical, and legal standards. Human oversight plays a defining role in mitigating these risks. AI may generate content at scale, but it lacks real-world context, ethical reasoning, and the ability to understand regulatory nuances. Without human review, AI-generated errors can mislead customers, compromise accuracy in high-stakes areas, and introduce ethical concerns, such as AI-generated medical content suggesting treatments without considering patient history. These risks aren’t theoretical; businesses across industries are already grappling with the challenge of balancing AI efficiency with trust. This is where Trust Calibration comes in, a structured approach to ensuring AI-generated content is reliable while maintaining the speed and scale that businesses need. Trust Calibration: When to Trust AI and When to Step In AI oversight shouldn’t slow down innovation; it should enable responsible progress. The key is determining when and how much human intervention is needed, based on the risk level, audience impact, and reliability of the AI model. Organizations can implement Trust Calibration by categorizing AI-generated content based on its risk profile and defining oversight strategies accordingly: High-risk content (medical guidance, financial projections, legal analysis) requires detailed human review before publication.Moderate-risk content (marketing campaigns, AI-driven recommendations) benefits from automated checks with human validation for anomalies.Low-risk content (social media captions, images, alt text) can largely run on AI with periodic human audits. Fine-tuning AI parameters, such as prompt engineering or temperature adjustments, modifying how deterministic or creative the AI's responses are by adjusting the probability distribution of generated words, can refine outputs, but research confirms these tweaks alone can’t eliminate fundamental AI limitations. AI models, especially those handling critical decision-making, must always have human oversight mechanisms in place. However, knowing that oversight is needed isn’t enough, organizations must ensure practical implementation to prevent getting stuck in analysis paralysis, where excessive review slows down decision-making. Many organizations are therefore adopting AI monitoring dashboards to track precision, recall, and confidence scores in production, helping ensure AI reliability over time. Use Cases: Areas Where AI Needs a Second Opinion Understanding when and how to apply oversight is just as important as recognizing why it’s needed. The right approach depends on the specific AI application and its risk level. Here are four major areas where AI oversight is essential, along with strategies for effective implementation. 1. Content Moderation and Compliance AI is widely used to filter inappropriate content on digital platforms, from social media to customer reviews. However, AI often misinterprets context, flagging harmless content as harmful or failing to catch actual violations. How to build oversight: Use confidence scoring to classify content as low, medium, or high risk, escalating borderline cases to human moderators.Implement reinforcement learning feedback loops, allowing human corrections to continuously improve AI accuracy. 2. AI-Generated Product and Marketing Content AI-powered tools generate product descriptions, ad copy, and branding materials, but they can overpromise or misrepresent features, leading to consumer trust issues and regulatory risks. How to build oversight: Use fact-checking automation to flag exaggerated claims that don’t align with verified product specifications.Set confidence thresholds, requiring human review for AI-generated content making strong performance claims.Implement "guardrails" in the prompt design or model training to prevent unverifiable claims like "instant results," "guaranteed cure," or "proven to double sales." 3. AI-Powered Customer Support and Sentiment Analysis Chatbots and sentiment analysis tools enhance customer interactions, but they can misinterpret tone, intent, or urgency, leading to poor user experiences. How to build oversight: Implement escalation workflows, where the AI hands off low-confidence responses to human agents.Train AI models on annotated customer interactions, ensuring they learn from flagged conversations to improve future accuracy. 4. AI in Regulated Industries (Healthcare, Finance, Legal) AI is increasingly used in medical diagnostics, financial risk assessments, and legal research, but errors in these domains can have serious real-world consequences. How to build oversight: Require explainability tools so human reviewers can trace AI decision-making before acting on it.Maintain audit logs to track AI recommendations and human interventions.Set strict human-in-the-loop policies, ensuring AI assists but does not finalize high-risk decisions. Before You Deploy AI, Check These Six Things While Trust Calibration determines the level of oversight, organizations still need a structured AI evaluation process to ensure reliability before deployment. #Stepkey actionimplementation strategy 1 Define the objective and risks Identify AI’s purpose and impact What is the task? What happens if AI gets it wrong? 2 Select the right model Match AI capabilities to the task Generative models for broad tasks, fine-tuned models for factual accuracy. 3 Establish a human validation set Create a strong benchmark Use expert-labeled data to measure AI performance. 4 Test performance Evaluate AI with real-world data Check precision, recall, and F1 score across varied scenarios. 5 Implement oversight mechanisms Ensure reliability & transparency Use confidence scoring, explainability tools, and escalation workflows. 6 Set deployment criteria Define go-live thresholds Establish minimum accuracy benchmarks and human oversight triggers. By embedding structured evaluation and oversight into AI deployment, organizations move beyond trial and error, ensuring AI is both efficient and trustworthy. Final Thoughts The question isn’t just “Can we trust AI?” It’s “How can we build AI that deserves our trust?” AI should be a partner in decision-making, not an unchecked authority. Organizations that design AI oversight frameworks today will lead the industry in responsible AI adoption, ensuring innovation doesn’t come at the cost of accuracy, ethics, or consumer trust. In the race toward AI-driven transformation, success won’t come from how fast we deploy AI; it will come from how responsibly we do it.

In the previous article, we spoke about hunting bugs. But a time will come when your hunters’ ‘trophy collection’ grows to a scary size. More and more ‘targets’ will be coming as if it were a zombie apocalypse. There will be red lamps flashing across your metrics dashboard. If (or rather when) that happens, it would mean it’s time for a bigger change than just routine debugging and streamlining your codebase. Today, I am going to talk you into refactoring, which is basically digging into and altering the very foundations of your project. Don’t take anything for granted, check everything yourself and think twice before diving into this work. It’s just as easy as swapping an engine in a flying airplane. But that’s exactly what you will have to do. Let’s get started! Monsters Beneath the Surface In the troubleshooting guide, I already mentioned how important it was to create and closely watch the metrics of your project. System metrics — like response time, memory consumption, etc. — and product metrics — like user acquisitions and engagement — are equally important (you watch and log your metrics, right?). It may happen that the problems you see with these instruments keep mounting up. Solving them consumes more and more time and resources, and you become short of both for growth and development. This is the worst symptom that your project needs refactoring. Ideally, you should be alert before skyfall gets at your doorstep. But for a lot of people, "If it ain't broke, don't fix it" is a motto for stability. Well, it doesn’t really work that way. You will actually save more if you start refactoring your project before real trouble hits you. The main point to keep in mind is that refactoring is an investment, not an expense. Companies that ignore it often face a snowball effect of problems: bug fixes take longer, teams lose motivation, and users lose trust in the product. True enough, it takes time to analyze, modify, rewrite, and test your code. But postponing changes can cost you even more. As technical debt accumulates, developing new features becomes increasingly difficult, and the costs of maintaining an aging system grow. Over time, even a tiny bug in poorly maintained code can lead to huge losses, sometimes far exceeding the investment needed to improve it. Another popular misconception is that refactoring is something like mature age skincare: young projects don’t need it. First, even young projects can suffer from the acne of technical debt, especially if they were developed in a hurry or without proper architectural planning. Second, refactoring is not related to the age of your code. Just think of the tools and libraries that your code employs. Trace their origin right to the roots and you will be surprised if not shocked. According to statistics based on over 7 million open-source projects, around 70% of open-source tools and libraries that modern software relies on are either unsupported or in poor condition. And the situation in closed-source software is unlikely to be much better. This is the clearest illustration of what happens when the "If it works, don’t touch it" mindset is taken to the extreme. Refactoring isn’t just about fixing past mistakes, it's also a way to build a better future. It helps adapt a system to new requirements, improve performance, and make maintenance easier. Important "Don’ts" Before You Start So far, I may have sounded like a refactoring ambassador without any second thought. Of course, that is not true. The first and most important ‘don’t’ is: don’t do refactoring if it brings more harm than good. Be careful about refactoring if one or more points in this checklist are true: The project is nearing completion or is already scheduled to transition to a new system. If you plan to replace an outdated CRM system in six months, it makes more sense to focus on building the new one rather than trying to "patch up" something that will soon become obsolete.Users and stakeholders are fully satisfied with the current functionality. No future changes are planned, so there’s no need to work with outdated code.The system is isolated and not integrated with other systems, meaning it’s not affected by external changes or errors.The risks of making changes outweigh the potential benefits. If your case has passed this brief test, there are a couple more refactoring taboos you should be aware of. There is always a rather idealistic temptation to rewrite everything from scratch to get things right, tidy, and perfect. Well, first, there is no such thing as perfection. Rewriting almost always leads to losing critical details, missing deadlines, and introducing new, unexpected bugs. And let’s be honest, such ambitious projects rarely get completed. Your legacy system is not just code. It’s accumulated experience, bug fixes, and an understanding of real user needs. Refactoring allows you to improve the system without losing its core functionality. This evolutionary approach enables gradual improvements without breaking the foundation or increasing risks. Another temptation is to kill two birds with one stone and combine refactoring with adding new features. Believe me, that is a no-no. First, refactoring and business tasks are completely different targets. It is simply not possible to keep an equal focus on both at the same time. At best, you will only hit one of them. But in most cases, you are going to miss both. Also, you will multiply confusion, delays, and you will have even more bugs as business logic gets entangled with refactored code. So please keep refactoring and business tasks separate. This way, you can track how much time is spent on business features versus technical improvements. And your code reviewers will really, really appreciate it. Step #1: Be Discreet, Think About Code Quality Do not rush to refactor every piece of old code indiscriminately. Typically, a project is developed by different people with varying levels of experience over time, and in some cases, what appears to be "bad" code from your perspective may not actually be that bad. Also, do not try to cover the entire project at once: break refactoring into small, independent tasks that can be completed sequentially. It is best to start with the most problematic parts of the code (so-called hot spots) that most frequently cause failures or hinder development. Remember the Pareto principle? It works pretty well here: refactoring 20% of simple code will give you an 80% improvement in the codebase. There are many tools capable of automatically assessing the quality of the codebase. For example, SonarQube is an open-source platform for continuous analysis and measurement of code quality. It supports all popular programming languages, from Python, JS, and PHP to Swift, Java, and C. This project has excellent documentation and can even be used with popular IDEs. Another popular solution is Qodana from JetBrains. It also supports all major programming languages and integrates with various development environments and CI/CD pipelines. Qodana can check dependency license compatibility according to specified policies and aggregate reports from other analyzers. Overall, it is a powerful tool, though the free version has limited functionality. However, the paid version costs only $5 per month per developer in the Ultimate edition, making it a very reasonable choice, especially if you are using JetBrains IDEs. There are also many simpler alternatives. For example, you can use open-source static code analyzers: for PHP, a good choice would be PHPStan or Psalm; for Python, pylint or flake8; and for Golang, in addition to the built-in solution, staticcheck could be used. All these solutions are configured via configuration files, allowing you to scan only specific parts of a project rather than the entire codebase. This way, you can gradually identify problematic areas for refactoring, step by step. Tools such as PHPMD (PHP Mess Detector) for PHP or PMD (Programming Mistake Detector) for Java, JavaScript, Kotlin, Swift, and other languages can also highlight the need for refactoring. These tools analyze code to identify excessive complexity, duplication, outdated constructs, and potential errors. They help pinpoint problem areas that require attention and provide recommendations for improvement. Determine the general style and rules for writing new code in advance. Try to follow widely accepted standards. For example, in PHP, apply PSR; in Go, adhere to the standard gofmt and golangci-lint; and in Python, follow PEP8. Be sure to discuss the chosen standards with the team in advance so that everyone has a unified understanding. To ensure that the new code always complies with these standards, add linters to the build process. For example, configure automatic checks before pushing or PR. Git hooks (if you use Git) can help with this. For instance, you can create a pre-commit hook that automatically runs static analysis before committing changes and blocks the commit if something goes wrong. The new code should already comply with the new rules to avoid increasing the amount of code that requires refactoring in the future. Once the new code meets the standards, gradually extend the checks to small old sections of the project. Try to start with the least complex parts. Do not hesitate to use automated refactoring tools like PHPRector, Rope, or gopatch (such a tool can be easily found for any programming language). These tools will easily help bring the code to the expected state, you just need to configure them correctly. Step #2: Testing and Refactoring Tests In addition to code quality, it is crucial to monitor test coverage in your project. Actually, a lack of tests is also an indication that refactoring and addressing technical debt are necessary. To assess test coverage, you can use tools such as php-code-coverage for PHP, Coverage.py for Python, or Istanbul Code Coverage for JavaScript. Similar tools exist for every popular language. These tools generate reports showing which parts of the code are already covered by tests and which still require attention, which will certainly help improve the quality of your project's testing. Notably, SonarQube and Qodana can also analyze code test coverage. In short, choose the most suitable tool for your needs; the selection is really extensive. Please mind that there is a difference between tests that push us toward the very idea of refactoring and tests that should accompany its implementation. We are trying to improve code that has existed for quite some time. Therefore, it is most likely deeply embedded in the business logic, and modifications can break the project in the most unexpected places. That is why good testing is indispensable here. Of course, during refactoring, some old tests may break or become obsolete due to significant functional changes, but high-level and mid-level tests will provide safety. Nevertheless, do not forget to refactor the tests themselves; they are also an important part of your project. Step #3: Tiny Bits That Make a Huge Difference Remember how I told you about how vulnerable you may be to third-party tools and libraries that become obsolete? Refactoring is a perfect time to address that issue. In a modern environment, being dependent on ready-made libraries and frameworks is inevitable. You should actually minimize the number of ‘reinvented wheels’ in your project by choosing proven solutions developed and approved by the community. But of course you should choose them wisely. Before integrating a solution, make sure that the library is actively maintained, its license suits your project, and its version is locked in the dependency manager. By the way, it is a good idea to keep forks of these libraries: this way, if something happens to the original versions, your project will not suffer. Also, regularly update dependencies, but test the changes beforehand to avoid unexpected problems. Speaking of third-party solutions, it is always a good idea to update them. This applies not only to libraries but also to servers, databases, and operating systems. Outdated software can be vulnerable or unstable. Before updating, be sure to test it in an isolated environment. Add checks for vulnerabilities and secrets in the code. There are many tools for this, such as Trivy, Snyk, or Bandit. These checks can also be integrated into the CI/CD pipeline to detect issues early. If secrets are stored in the code, that is definitely something that should be refactored as soon as possible. Where should they be stored? Check solutions like HashiCorp Vault, AWS Secrets Manager, or GitHub secrets. Last but definitely not least, do not forget to update old documentation! Yes, documentation is also a part of your project and should never be neglected. If refactoring only breaks the documentation, its benefits are significantly reduced: by fixing one problem, you are merely creating another for yourself in the future. Step #4: Product Is King Your codebase is important, but its value is always determined by the problems it solves. Code is a tool for achieving project goals, and we must not forget about end users and their needs. So it is crucial to continue keeping an eye on your metrics as your refactoring progresses. Metrics were the first to signal there were problems, but now the focus is different, although the metrics themselves remain mostly the same. During refactoring, it is essential to track both system metrics (such as system response time, resource usage, and error count) and product metrics (such as conversions and retention rates). These data points will help you understand whether the system is actually improving from the user’s perspective and where bottlenecks still remain. If you ignored the advice from both this and the previous chapter and still do not have any metrics, at least set up system data collection before making any changes and wait for a sufficient amount of data to accumulate. Conclusion I hope I made myself clear that refactoring is not just change for the sake of change, but a strategic tool that helps keep your project alive, efficient, and maintainable. If, of course, you had any doubts about that before. Fortunately, there are now a vast number of tools and methods for analyzing and automatically improving code, allowing developers to do it in a quick and (almost!) painless way. I have tried to mention some of these tools, but it is impossible to cover them all. Progress does not stand still, and new, smarter AI-driven refactoring solutions based on LLMs are already being actively developed and implemented. Perhaps in the future, all we will need to do is press a single button to make our code cleaner and more understandable. But until that button exists, don’t forget to refactor manually. Without regular code improvements, your system risks becoming as much of a cumbersome legacy as a CRT monitor: new features will take longer to implement, fixing bugs will become increasingly difficult, and developers will lose motivation before they even start working. May refactoring be with you, and may it bring you only benefits!

By Filipp Shcherbanich CORE

DZone events bring together industry leaders, innovators, and peers to explore the latest trends, share insights, and tackle industry challenges. From Virtual Roundtables to Fireside Chats, our events cover a wide range of topics, each tailored to provide you, our DZone audience, with practical knowledge, meaningful discussions, and support for your professional growth. DZone Events Happening Soon Below, you’ll find upcoming events that you won't want to miss. Best Practices for Building Secure Data Pipelines with Apache Airflow® Date: April 15, 2025Time: 1:00 PM ET Register for Free! Security is a critical but often overlooked aspect of data pipelines. Effective security controls help teams protect sensitive data, meet compliance requirements with confidence, and ensure smooth, secure operations. Managing credentials, enforcing access controls, and ensuring data integrity across systems can become overwhelming—especially while trying to keep Airflow environments up–to-date and operations running smoothly. Whether you're working to improve access management, protect sensitive data, or build more resilient pipelines, this webinar will provide the knowledge and best practices to enhance security in Apache Airflow. Generative AI: The Democratization of Intelligent Systemsive Date: April 16, 2025Time: 1:00 PM ET Register for Free! Join DZone, alongside industry experts from Cisco and Vertesia, for an exclusive virtual roundtable exploring the latest trends in GenAI. This discussion will dive into key insights from DZone's 2025 Generative AI Trend Report, focusing on advancements in GenAI models and algorithms, their impact on code generation, and the evolving role of AI in software development. We’ll examine AI adoption maturity, intelligent search capabilities, and how organizations can optimize their AI strategies for 2025 and beyond. Measuring CI/CD Transformations with Engineering Intelligence Date: April 23, 2025Time: 1:00 PM ET Register for Free! Ready to Measure the Real Impact of Your CI/CD Pipeline? CI/CD pipelines are essential, but how do you know they’re delivering the results your team needs? Join our upcoming webinar: Measuring CICD Transformations with Engineering Intelligence. We’ll be breaking down key metrics for speed, stability, and efficiency—and showing you how to take raw CI/CD data and turn it into real insights that power better decisions. What's Next? DZone has more in store! Stay tuned for announcements about upcoming Webinars, Virtual Roundtables, Fireside Chats, and other developer-focused events. Whether you’re looking to sharpen your skills, explore new tools, or connect with industry leaders, there’s always something exciting on the horizon. Don’t miss out — save this article and check back often for updates!

After nearly a decade of managing our on-premise database infrastructure, our team finally took the plunge into cloud database services with AWS RDS. The migration journey came with its share of surprises — both pleasant and challenging. Here's what I discovered during our transition to AWS RDS managed services, along with key insights that might help your organization make informed decisions about your own database strategy. I still remember the morning my boss walked into our weekly team meeting and dropped the bomb: "We're finally moving our databases to the cloud." After years of babysitting our on-premise Database infrastructure — the 2 AM alerts, the sweaty backup restoration drills, and those nerve-wracking version upgrades — I had mixed feelings. Part excitement, part dread, and a healthy dose of skepticism. It's been 14 months since we completed our migration to AWS RDS, and boy, do I have stories to tell. If you're considering a similar move, grab a coffee. This might save you some headaches. The cloud migration journey is often described in broad, theoretical terms, but nothing prepares you like firsthand experience. Having recently migrated an on-premises Oracle database to AWS RDS (Relational Database Service), I encountered a mix of cost savings, operational advantages, limitations, and unexpected challenges. This article is not just a technical rundown but an interactive guide based on real-world scenarios, providing insights into savings, ease of management, automation, restrictions, and more. If you’re considering a similar move, this breakdown will help you navigate the transition effectively. Cost Savings: Reality vs. Expectations Expectation Moving to AWS RDS will significantly reduce infrastructure and maintenance costs, as we no longer need to manage hardware, networking, or patching manually. Reality Compute and storage savings. We saved a lot by right-sizing the instances instead of over-provisioning hardware like in on-prem setups. AWS’s pay-as-you-go model allowed us to scale down when needed.Licensing costs. If you use AWS RDS for Oracle with the "License Included" option, you avoid hefty upfront Oracle licensing costs. However, if you go with "Bring Your Own License (BYOL)," the savings might not be as significant.Networking and data transfer costs. Data egress charges were higher than expected, especially for frequent inter-region data transfers.Storage autoscaling. AWS RDS allows auto-scaling storage, reducing the risk of unexpected downtime due to insufficient disk space. However, increased storage means increased costs. Lesson Learned Savings depend on usage patterns, licensing choices, and data transfer needs. Make sure to right-size instances, monitor storage growth, and optimize data transfers to avoid cost surprises. Performance: Tuning for the Cloud vs. On-Prem Expectation Cloud databases should perform as well as or better than on-prem setups due to AWS’s optimized infrastructure. Reality I/O performance considerations. Unlike on-prem setups where we controlled disk configurations, AWS RDS relies on EBS volumes. Selecting the right IOPS (Provisioned IOPS vs. General Purpose SSD) was crucial.Network latency. Applications relying on low-latency on-prem database connections experienced increased query response times initially. AWS Direct Connect or VPN Peering helped mitigate some of this.Parameter tuning restrictions. Some Oracle init.ora parameters are not customizable in RDS, limiting deep performance tuning compared to on-prem environments. Lesson Learned To maintain performance, choose the right storage type, optimize queries for cloud latency, and adjust memory settings within AWS RDS limitations. Ease of Management: The Hands-Off Advantage Expectation Cloud-managed services will eliminate the operational overhead of routine database management. Reality Automated backups and snapshots. AWS RDS automates daily backups and point-in-time recovery, which eliminated manual backup scheduling.Automated patching. AWS RDS applies patches automatically, reducing maintenance efforts. However, patching schedules must be planned carefully to avoid downtime.Instance reboots and failover. While failover to a standby instance in a multi-AZ deployment was seamless, it still introduced a few seconds of downtime for active connections.User management restrictions. We no longer had SYSDBA access, meaning certain advanced administrative tasks had to be handled through AWS support or workarounds. Lesson Learned AWS RDS significantly reduces operational overhead, but the trade-off is limited direct control over certain DBA functions. Automation: A Game Changer for Scaling Expectation AWS RDS will enable easy automation for scaling, backups, and maintenance. Reality Scaling compute and storage. With RDS, we could scale up instance sizes or enable storage auto-scaling without downtime (except for compute scaling, which required a reboot).Infrastructure as Code. Using AWS CloudFormation and Terraform, we could automate database provisioning and deployments, making it easy to spin up test environments in minutes.Database snapshots and cloning. Creating a new database from a snapshot was much faster than on-prem restores, making it a game-changer for Dev/Test environments. Lesson Learned Automating database provisioning, scaling, and backups through AWS services and scripts simplifies cloud database management, reducing manual intervention. Patching and Upgrades: A Double-Edged Sword Expectation Cloud patching should be seamless and less disruptive than manual patching on-prem. Reality Automatic patch application. While AWS RDS handles Oracle patching, the exact timing and details of patches aren’t always transparent.Major version upgrades. AWS does not support major upgrades in place. We had to create a new instance and migrate the data, which required additional downtime planning.Downtime considerations. While minor patches had minimal impact, major version upgrades required significant preparation and testing. Lesson Learned Patching is easier, but plan for major version upgrades as a migration, not an in-place update. Security and Compliance: A Shared Responsibility Expectation AWS will handle database security, reducing compliance risks. Reality Encryption at rest and in transit. AWS RDS enables default encryption with KMS for storage, backups, and snapshots.Access control. IAM authentication simplified credential management, but we had to carefully configure Security Groups and VPC settings to ensure secure access.Auditing and compliance. AWS provides logs, but advanced auditing features (e.g., Oracle FGA) required additional setup and CloudWatch integration. Lesson Learned While AWS offers built-in security, DBA responsibility doesn’t disappear — careful access control, logging, and compliance checks are still necessary. Final Thoughts: Is Moving to AWS RDS Worth It? Absolutely — if planned correctly. Migrating an on-prem Oracle database to AWS RDS delivers significant cost savings, automation, and ease of management. However, performance tuning, licensing choices, network costs, and security configurations require careful consideration. Would I do it again? Yes. But I’d fine-tune instance selection, plan upgrades better, and optimize network costs more proactively. Thinking of migrating? What’s your biggest concern about moving to the cloud? Drop your thoughts below!

By arvind toorpu CORE

API security is crucial, as it directly impacts your business's success and safety. How well you secure your APIs can make or mar your product, and it is of utmost importance to spend time thinking about security. I have seen developers work in Postman without properly securing their credentials, often leaving API keys exposed in shared environments or logging sensitive data in the console. For example, some developers unknowingly expose credentials when they make their workspaces public, allowing anyone to access sensitive API keys and tokens that are not properly stored. In this post, I want to share some tips on how you can protect your data and API in Postman. General Tips for Securing Your APIs in Postman When working with APIs in Postman, taking proactive security measures is essential to prevent data leaks and unauthorized access. Implementing best practices ensures your credentials, tokens, and sensitive data remain protected. 1. The Secret Scanner Is Your Friend The Postman Secret Scanner is every developer's knight. It constantly scans your public workspaces and documentation for any exposed secrets; checks your variables and environments, schemas, etc., for exposed secrets; and notifies all Team and Workspace admins via emails and in-app notifications. Admins are given a link to view all exposed secrets in a dashboard and an option to immediately replace them with a placeholder using a single button click. This helps mitigate security risks faster. If you do not replace exposed secrets in a timeframe specified in the email, the secret scanner will automatically replace this data with a placeholder for you. For example, authorization secrets can be replaced with {{vault:authorization-secret}, or <AUTHORIZATION_SECRET>. Pro Tip 1 Whenever you want to show an example of some sensitive data, always use placeholder data before making your Workspace public. Maintain a private fork of your collection that you can continue to work in even after making your base collection public. There’s a lot more you can do with the secret scanner in Postman. You can mark alerts as ‘false positives,’ ‘won’t fix,’ etc. Pro Tip 2 Don’t ever ignore the secret scanner. While there may be false positives, always check to ensure you’re not exposing anything and staying safe. Learn more about the secret scanner here. 2. Avoid Secret Keys in Test Scripts, Headers, and Params When working with test scripts, depending on your workflow, some developers often prefer to make HTTP calls from pre-request scripts. Some HTTP calls require auth credentials, and these auth credentials can be easily exposed if you’re logging data to the console, passing data to a template for visualization, etc. If you need to use sensitive data in your PM scripts, always store it in a vault, environment, or collection variable first, then programmatically access it from storage. In some cases, Postman actively checks for sensitive data in your scripts and truncates it before logging in to prevent exposure. You should also be very careful when adding request headers, query/path parameters, etc. These are places where we’ve observed many secrets being exposed. Our variable helpers make it easy to store data in these places into the vault or collection/environment variables. Simply highlight the value, and you will see a pop-up that helps you store the data more securely. Here’s a list of places to take note of when making a workspace public: Request headerCollection/Environment/Global variablesQuery and path parametersAuthorization helpers (API Key, Basic, OAuth, etc)Pre-request and post-response scriptsRequest bodyURL barPostman console 3. Keep Your Credentials Local With Postman Vault Some users worry about storing their credentials in Postman environments and variables because it could potentially sync with Postman cloud depending on how it is stored. While the Postman cloud is safe and secure, we always encourage everyone to store their API secrets in the Postman Vault. Postman Vault is a local encrypted storage that only you can access. Data stored in the Postman vault are not synced with the Postman cloud and can only be accessed using a vault key. Your vault key can be stored in your system’s password manager or securely elsewhere. If you intend to share credentials with your team, you can limit vault secrets to specific API domains and link them to external password managers like Hashicorp, Azure Vault, 1Password, etc. Vault credentials can be programmatically accessed in Postman scripts, similar to how you would access environments and collection variables. Pro tip: When working with authorization helpers in Postman. Always use the Postman Vault. Learn more about Postman Vault here. 4. Help Your API Consumers Stay Secure With Guided Auth Guided Auth helps you onboard consumers to your public APIs faster and more efficiently. When you set up Guided Auth for your public APIs in Postman, your API consumers get a step-by-step guide on how they can make their first successful API call as soon as they start typing your domain name in the URL bar. They can easily set up different kinds of authentication (OAuth 2.0, Client Credentials, PKCE, etc.) depending on how your guided auth is configured. Learn how to set up Guided Auth here. Once you have guided auth set up, you can help your API consumers stay secure by choosing to store their credentials after a guided authentication step in Postman Vault. Vault secrets added using Guided Auth are inside double curly braces ({{ }). The prefix vault: is appended to the vault secret's name, and a suffix is automatically appended with the authentication type. {{vault:postman-api-key:value} 5. Current Values vs. Initial Values When using variables in Postman, it’s important to understand the difference between initial values and current values. Initial values are synced to the Postman cloud. If you share your collections, your variables become visible to your team and anyone who has access to that workspace.Current values are only stored locally on your machine and are not shared with others. This makes them ideal for storing sensitive API keys, tokens, or credentials. Pro tip: Always ensure that sensitive data is stored as a current value to prevent accidental exposure. Use initial values to show examples of what the variable value could look like. 6. Authorization Helpers Are There to Help Postman provides authorization helpers that let you handle authentication securely without manually adding tokens or credentials in your request headers. Instead of manually copying access tokens, use the OAuth 2.0 helper to automatically fetch and refresh tokens.When using API keys, configure them in the authorization tab rather than adding them directly to request URLs. 7. Stop Ignoring the Warnings Postman does a great job at providing several warnings at different places when it suspects that something may be wrong. This warning can come as a UI popup, a push notification, an email, or status indicators on the UI depending on what it is you are trying to do. Always make sure you pay attention to these warnings and never ignore them. It never hurts to double-check to be sure you are not exposing any sensitive information. Remember, your data will only be public if you make it public. Pro tip: When creating a new Workspace, always start with a Private or Team Workspace. Once you’re done making changes, review your work and then make it public. Ensure you always check thoroughly before changing a Workspace visibility to “Public.” 8. Enforce the Principle of Lease Privilege (POLP) Workspaces and Teams in Postman have role-based access control (RBAC) integrated. We encourage teams collaborating in Postman to always give access and certain privileges only to those who need them. In a Postman Team, only individuals with super admin and community manager roles are allowed to manage all public elements. Therefore, we encourage you to only assign these roles to necessary people and have a standard review process in place for when Workspaces are being published to the public. Learn more about managing public elements in Postman here. Final Thoughts Securing your APIs is crucial, and Postman provides various tools to help you keep your secrets safe. By leveraging features like Postman Vault, the Secret Scanner, Guided Auth, and Authorization Helpers, you can significantly reduce the risk of exposing sensitive data. Make sure you implement these best practices and regularly audit your Postman workspaces to ensure that your API security remains strong. Got questions? Found any of this helpful? Let me know in the comments! Happy coding, and stay secure! Cheers! Note: This was originally posted on the Postman Community Forum.

Automation has become the cornerstone of modern IT operations, enabling organizations to streamline processes, reduce manual errors, and improve efficiency. However, as automation grows in complexity and scale, security risks also increase. Misconfigured infrastructure, untested playbooks, and vulnerabilities in automation workflows can expose organizations to significant threats. After my article on using SonarQube for Ansible code scanning and quality checks, this article covers additional tools and frameworks required for secured automation. Ansible, one of the most widely used tools for configuration management and deployment, offers immense power and flexibility. But without proper safeguards, it can inadvertently introduce security risks. To address this challenge, organizations must adopt a security-first approach to automation by leveraging specialized tools for testing, validation, and compliance enforcement. This guide explores key tools that help secure Ansible implementations, covering both open-source solutions and commercial offerings. Whether your organization is managing small-scale projects or enterprise-level deployments, these tools will enable you to automate confidently while maintaining robust security standards. Essential Security and Testing Tools for Ansible 1. Molecule: Role Testing Framework Molecule is a powerful framework designed specifically for testing Ansible roles. It enables developers to validate roles in isolated environments before deploying them to production systems. By simulating different scenarios and environments, Molecule ensures that roles behave predictably across various configurations. Key Capabilities Creates isolated test environments using Docker, Podman, or VagrantSupports multi-scenario testing across different operating systemsIntegrates seamlessly with continuous integration pipelines for automated testingProvides detailed feedback on role functionality and compatibility Installation Shell pip install molecule Molecule is ideal for teams looking to enforce rigorous testing standards during role development. By identifying issues early in the development lifecycle, it reduces the risk of deployment failures and security vulnerabilities. To create a new Ansible collection and a role with Molecule, check the documentation here. Add Molecule on an Existing Ansible Role 1. To add Molecule to an existing role, run the below command to generate the required molecule directory and file structure Shell molecule init scenario Molecule directory structure For the complete directory structure, check the GitHub repository with Ansible YAML snippets. 2. Edit the meta/main.yml file in your role and add role_name and namespace under galaxy_info: YAML galaxy_info: author: vidyasagarMachupalli description: A file management role company: your company (optional) role_name: file_management namespace: vidyasagar_machupalli 3. Now, run the Molecule test on the Ansible role. Shell molecule test 2. Ansible Lint: Playbook Validation Tool Ansible Lint is a lightweight yet powerful tool for validating playbooks, roles, and collections. It scans Ansible content for common issues such as syntax errors, deprecated modules, and security misconfigurations. By enforcing best practices during development, Ansible Lint helps teams create reliable and secure automation workflows. Critical Functions Identifies security misconfigurations in playbook developmentDetects deprecated modules and anti-patterns that may introduce risksSupports custom rule configuration to align with organizational policiesProvides actionable feedback to improve playbook quality Installation Shell pip install ansible-lint Ansible Lint is particularly useful for teams adopting DevSecOps practices, as it integrates easily into CI/CD pipelines to ensure playbooks meet security standards before deployment. 3. KICS: Infrastructure as Code Security Scanner KICS (Keeping Infrastructure as Code Secure) is an open-source tool designed to scan Infrastructure as Code (IaC) files for misconfigurations and vulnerabilities. It supports a wide range of IaC formats, including Ansible playbooks, Terraform configurations, Kubernetes manifests, and more. KICS helps organizations identify issues before deployment, reducing the risk of exposing infrastructure to security threats. Security Features Analyzes Ansible playbooks alongside other IaC formats such as Terraform and Kubernetes configurationsIncludes over 2,000 predefined security policies tailored for cloud environments (AWS, GCP, Azure)Provides pre-deployment misconfiguration detection to prevent security breachesOffers detailed reports on vulnerabilities with remediation guidance Deployment Shell docker pull checkmarx/kics:latest KICS is ideal for organizations managing hybrid or multi-cloud environments where IaC plays a critical role in provisioning resources securely. 4. Steampunk Spotter: Enterprise Playbook Analysis Steampunk Spotter is a commercial tool designed for enterprise-grade analysis of Ansible playbooks. It leverages advanced algorithms to optimize playbooks while ensuring compliance with security standards. Steampunk Spotter provides detailed insights into playbook performance and potential vulnerabilities, making it an excellent choice for large-scale deployments. Enterprise-Grade Capabilities Advanced playbook optimization features to improve efficiency and reliabilityComprehensive security and compliance scanning tailored for enterprise requirementsIntegration with CI/CD pipelines for automated validation workflowsDetailed reporting capabilities for audits and governance purposes Steampunk Spotter is particularly valuable for organizations requiring deep insights into their automation workflows and needing tools that scale effectively with complex infrastructures. 5. Ansible Development Tools: Red Hat's Integrated Solution Red Hat’s Ansible Development Tools provide a comprehensive suite of utilities designed to enhance the creation, testing, and validation of Ansible content. These tools are part of the Red Hat Ansible Automation Platform and are ideal for teams seeking enterprise-grade solutions with official support from Red Hat. Toolkit Components ansible-builder: Creates secure execution environments tailored to specific requirementsansible-navigator: Provides an intuitive interface for debugging playbooks during developmentansible-sign: Digitally signs content to verify authenticity and integritypytest-ansible: Enables unit testing of roles and collections within Python-based test frameworks You can find the curated list of tools here installed as part of the Ansible Development Tools. RHEL Installation Shell sudo dnf install ansible-dev-tools This suite of tools is particularly useful for organizations already invested in Red Hat’s ecosystem or those seeking enterprise support for their automation initiatives. Recommended Security Practices To maximize the effectiveness of these tools, organizations should adopt the following best practices: Test roles in isolated environments. Use Molecule to validate role functionality across different configurations before deploying them in production systems.Enforce linting during development. Integrate Ansible Lint into your CI/CD pipelines to catch errors early in the development process.Conduct comprehensive IaC scanning. Use KICS to identify misconfigurations across all infrastructure code formats before deployment.Implement robust secret management. Leverage tools like HashiCorp Vault or a Cloud Secrets Manager to securely manage sensitive credentials used in automation workflows.Evaluate commercial solutions. For enterprise-scale deployments or advanced requirements such as compliance auditing, consider tools like Steampunk Spotter or Red Hat’s offerings. Conclusion Security must be an integral part of every automation strategy — not an afterthought added during audits or post-deployment reviews. By leveraging the tools outlined in this guide — ranging from open-source solutions like Molecule and KICS to enterprise-grade offerings like Steampunk Spotter — organizations can build a secure foundation for their automation workflows. For small-scale projects or teams just beginning their DevSecOps journey, open-source tools provide robust functionality at no cost while enabling rapid adoption of best practices. Enterprises managing complex infrastructures can benefit from commercial solutions that offer deeper insights into performance optimization and compliance enforcement. Ultimately, secure automation is not just about protecting infrastructure — it’s about enabling innovation with confidence while maintaining operational resilience against evolving threats. Organizations should begin implementing these tools today to ensure their automation workflows remain secure, compliant, and efficient as they scale toward future growth objectives.

By Vidyasagar (Sarath Chandra) Machupalli FBCS CORE