❌

Reading view

How to keep AI-generated code aligned with your standards

One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.

Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?

“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”

One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.

Document like a construction specification

A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them. 

“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”

Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.  

Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”

Encode non-functional requirements as automated tests

The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.

“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”

An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.

Requirements for stakeholders and AI

Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.

“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”

Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”

The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators. 

Build governance into the specs

How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.

Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.

Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.  

“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”

Observability and testing first

When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.

Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”

Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”

Package and evolve the standards

Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:

  • Enforce standards in continuous integration so violations block merges.
  • Give the AI persistent context, such as CLAUDE.md, style guides, and architecture docs.
  • Keep changes small and reviewable.
  • Require human review of every pull request because AI-generated code must get the same scrutiny as any contributor’s. No exceptions.
  • Back this approach with solid test coverage to catch regressions.
  • Periodically audit for drift as your standards evolve.

It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”

As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.

  •  

Java 27 grows up, makes better choices

If one sign of maturity is making better choices, then Java has grown up a fair bit in its version 27 release Tuesday. “JDK 27 is the release where Java stops asking you to opt in to good defaults and simply turns them on,” wrote backend engineer Arvind Kumar, on his education site Codefarm. Better default settings may not be groundbreaking, but they do make life easier for developers because they mean coders have fewer things to change. Nor should users have to grapple with new features, particularly if they are not of interest. Java 27 succeeds on both counts. Built from the now-completed Java 27 specification, JDK 27 is a short‑term release that won't get long-term support. It includes four new features, or JEPs (JDK Enhancement Proposals) that are ready for production, none of which, Kumar points out, require any immediate changes in developers' code. The release includes another five new features offered as previews for further incubation. Headers get compact In Java 27, compact headers are now available by default (JEP 534). Up until now, the developer had to set them with a flag. Now, no additional action is required. Traditionally, a Java object header takes up 96 bits in a memory heap, much of which is rarely used. With Java 27, the default is a 64-bit header. Turns out the header had too much empty space. Four bytes doesn’t sound like a change to worry over, but across millions of live objects it can lead to considerable memory savings. A run on the SPECjbb2015 Java benchmark standard found that toggling to a 64-bit header resulted in 22% less heap space and 8% less CPU time. The smaller headers appear to work in production. Amazon already runs hundreds of production services with the diminutive compact object headers. SAP has already switched to compact object headers as the default for the company’s OpenJDK fork, SapMachine. Even in its smaller size, this new layout reserves some space for future projects, such as 4 bits for Project Valhalla which aims to bring value objects to Java. Java's overseers don’t want to toss the 96-bit header layout, at least for the time being. But now developers must raise a flag if they want to use it. Quantum-proofing cryptography Looking ahead to the arrival of quantum computing, Java maintainers have implemented “post-quantum hybrid key exchange,” based on TLS 1.3 (JEP 527). Java now offers three new “hybrid” ways of exchanging keys between Java clients, servers and external TLS-compliant endpoints. Each of these approaches, which are options alongside the existing key exchange protocols, combines a traditional Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE) algorithm with the NIST ML-KEM post‑quantum key exchange algorithm. The idea is to prepare now for future quantum attacks when the keys to traditional key exchanges could be easily cracked with quantum computing. Malicious attackers are already saving encrypted sessions with a "harvest now, decrypt later" mindset. Taking out the trash, in a good way JDK 27 also tidies up its garbage collectors, the tools that quietly identify and reclaim unused memory. It switched out the default trash bin for constrained environments – Serial – to the overall default garbage collector, called Garbage-First or G1. Garbage collectors relieve developers from manually performing this task and potentially messing it up (usually). But it comes with a cost. Aggressive memory management adds overhead. So different garbage collectors have been built to meet different performance requirements regarding throughput, latency, footprint, and startup time. Recent performance improvements in G1 effectively rendered Serial GC unnecessary, Java's bosses argue. Serial was a single-threaded app built to run on a single CPU, making it well-suited to embedded and other resource-limited environs (especially with clients with less than 1792MB of memory). Thanks to optimization over the years, “G1's performance is now sufficient to replace Serial in all situations in which the JVM would previously have selected Serial,” the maintainers write in JEP 523. With this change, embedded developers will no longer have to add explicit flags to the command line during startup. Even better, it will correct cases where G1 should have been assigned in the first place, such as for containerized apps. “A chunk of containerized Java apps has been running on [Serial] all this time, even though no one consciously made that decision,” wrote PVS-Studio technical author Egor Pishii in a post. The switchover will also help unify telemetry data collection a bit more. Preparing Java 28 The remaining production-ready feature is in-process data redaction (JEP 536), in which Java’s Flight Recorder removes all sensitive details before the recording is finalized. The previews that come with this release include lazy constants (JEP 531), pattern primitive types (JEP 532), structured concurrency (JEP 533), and a set of cryptographic objects (JEP 538). There’s also a vector API (JEP 537) still in the incubation stage. We’ll see all of these again, hopefully in a more polished form, in a later release. Work is already underway for Java 28, due in March 2027: Expect a simple JSON API as an incubating project as well as a revised Shenandoah garbage collector. ®

  •  

Apple iPhone Duo makes developers think in folds

The October 23 ship date of Apple’s iPhone Duo grows nigh, so developers wanting to optimize their iPhone apps for the foldable will need to get to grips with its new display behaviors and form factor. “A fold is a UI event with backend consequences,” Atharva Deosthale, Appwrite developer advocate, wrote in an introductory blog post. “Folding and unfolding is part of normal device use, so apps need to preserve state and respond cleanly when the display changes.” The iPhone Duo, which Apple introduced last week, is a smartphone with two screens: a squat 5.4-inch (diagonal) outer display on top of the case and the larger 7.6-inch inner display within. The display’s contents automatically (and stylishly) move to the visible screen when the device is opened or snapped shut. Apple has published a repository of technical documentation to help devs prepare for the new form factor. Time to study up. An ever-shifting canvas The foldable fondleslab will run iOS 27.1, and will run unaltered iPhone apps, but in the same way regular iPhone apps run on the iPad: awkwardly. Devs need to learn some new moves to style their apps to truly make Apple’s mobile device look good. The foldable form factor means that the user may start work on an app on the top screen, and when the device opens, the app should appear seamlessly on the larger display (the display ratio remains the same across both screens). The phone doesn’t have to lie flat for the inner screen to be fully used; it can also fold into a “tabletop posture,” where half the screen is flat and the other half sits upright, like a little laptop. Or it could be fashioned into a partially opened “book posture,” with the fold running vertically. Maybe for privacy? Who knows what other ways people, with their endless ingenuity, will interact with these gadgets. Both screens have a 120 Hz adaptive refresh rate, thanks to Apple’s ProMotion technology. So any transitions within the app, and resizing of the app itself, need to be almost Walt Disney animation-level smooth - while maintaining state. The device can accommodate two apps simultaneously running on the screen, through “Split View,” so apps will also have to learn to share the screen nicely. To address this new topology, Apple is updating its Xcode IDE; the 27.1 beta will be available later this month. The backend will need some love too The iPhone Duo screen is a different world for a number of reasons. Size is no longer a value, but a dynamic range, Deosthale noted. An app’s available size needs to be read at layout time and adjusted through the app’s lifetime as its screen allocation changes. Some apps will work better in this environment than others, Deosthale noted. Apps with fixed layouts and hardcoded dimensions, or that use view controllers that reload on size change, can appear stretchy. “Those need work,” he wrote. Compared with the iPhone Pro Max, the Duo offers a bit more space, with a 7.6-inch inner display versus 6.9 inches. It’s wide enough that a single column stretching across the entire display won’t impress anyone. Now’s the chance to add in a detail pane or sidebar, side-by-side presenter and viewer modes, Deosthale suggested. And don’t let the app just disappear features, data or other miscellanea when the user switches screens. That will just come off as cheesy. Snapping the unit shut mid-task means the app needs to preserve its state, along with the user’s session identity, as the interface moves to the outer display. Try not to move components around too much when the display switches, leaving the user seeking some option anew. In the technical docs, Apple calls this keeping a “consistent experience.” Contrary to the traditional iPhone layout, some of the device’s system controls have moved from the bottom toward the side of the display, which, in landscape mode, is a sensible change that leaves more, albeit asymmetrical, vertical space. However, it is up to developers to ensure their apps aren’t covered by system controls. While this may not directly relate to the form factor itself, the device runs an A20 Pro system-on-a-chip, built at 2-nanometer scale, with a 6-core CPU, a 7-core GPU wired for matrix math, and a dual 16-core neural engine for ML work. All this horsepower means you can run local ML inference on the device itself. Perhaps add a button to destroy humanity? It’d be the perfect antidote for a rough day at work. If Apple developers have any questions about working with foldable displays, they can ask their Android brethren who have been wrangling foldables for almost a decade now.®

  •  

A maximum severity GitLab flaw could turn your CI/CD server into an attacker’s treasure trove

Yet another security vulnerability has been discovered in GitLab infrastructure, this one a perfect 10 in severity.

CVE-2026-85706, the second flaw GitLab has disclosed in just a month, is a maximum-severity vulnerability that allows attackers to read arbitrary files in a single HTTP request. The path traversal flaw results from improper confinement and lack of authentication enforcement in GitLab’s repository commits API, the company reported.

Threat actors could exploit it “under certain conditions” and read arbitrary files (credentials, secrets, and other sensitive data) on vulnerable GitLab servers.

The company has fixed the vulnerability, which impacts GitLab Community Edition (CE) and Enterprise Edition (EE), and has advised customers with public-facing self-hosted GitLab instances to patch their servers immediately, or remove public access.

Experts say the flaw is alarming because GitLab’s DevSecOps platform is used by roughly 50% of the Fortune 100 and has more than 50 million estimated registered users.

“GitLab is not simply a source-code repository,” noted Safayat Moahamad, advisory director at Info-Tech Research Group. In many enterprises, it is connected to build pipelines, deployment processes, application security workflows, and other trusted systems.

As a result, unauthorized access to configuration files, secrets, or credentials on the GitLab server could “create consequences well beyond the affected instance,” he said.

Don’t wait for the normal patch cycle

GitLab has been a favorite hacker target of late: In January, it patched a high-severity flaw that allowed attackers possessing a target’s account ID to bypass two-factor authentication, and in August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even completely delete them with a single HTTP request.

The current maximum severity bug, CVE-2026-85706, was reported through GitLab’s HackerOne bug bounty program. It affected CE and EE versions 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.

The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, noting that this type of vulnerability is a frequent attack vector for malicious cyber actors, and particularly poses significant risks to the federal enterprise; watchTowr Intel has reported that it is already observing “in-the-wild probes.” “Based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away,” it warned.

This is not a vulnerability that organizations should leave for the normal patch cycle, Moahamad emphasized. “It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows,” he said.

Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, he advised.

Beyond patching, the watchTowr Intel team said defenders should try to identify exploitation attempts by hunting through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters.

CI/CD platforms are critical trust infrastructure 

Organizations running affected self-managed GitLab CE or EE instances should be most concerned, Moahamad noted. Risk increases where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes.

The information and/or access that attackers could obtain depends on what the GitLab service can read and what organizations store on the server, he explained. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure

“The flaw directly creates an unauthorized file access risk,” he said. Credential theft, lateral movement, source code exposure, and supply chain compromise are possible follow-on scenarios.

Source code and CI/CD platforms must be governed as “critical trust infrastructure,” he said. While patching remains essential, resilience will depend on knowing where platforms can be exposed, limiting what they can access, detecting abnormal API behavior, and having a tested process for investigating and rotating credentials.

David Shipley of Beauceron Security described two factors colliding to generate “maximum pain” for GitLab users.

First is the vulnerability. “It’s a 10 for a reason: Unauthenticated read access to GitLab client source code,” he said.

Second, this especially hurts because developers still have bad habits: way too much code continues to ship or is in production with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said.

“So for attackers, you’ve got the classics,” he noted: Data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the stealing of AI tokens and infrastructure to enable other criminal activity.

“This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number,” Shipley said. “It opens up a world of criminal data shopping.”

The bottom line: “Get those secrets out of production code and adopt modern coding authentication best practices,” he advised.

This article originally appeared on CSOonline.

  •  
❌