# Code generation Compiler process that translates an intermediate representation into target machine code, assembly, or other target code. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why client SDK generation belongs in the open DevFeed: [Why client SDK generation belongs in the open]() Original publisher: [Read original article]() Author: Amir Hardon; Philipp Schmid Published: 2026-09-18T01:27:10.987787Z Content type: release Language: en Sources: [Google Developers Blog]() Topics: [Code generation](), [SDKs](), [OpenAPI Specification](), [Open Source](), [Tooling](), [Streaming]() Tags: [code-generation](), [documentation](), [mcp](), [open-source](), [openapi](), [sdk-generation](), [streaming](), [tooling]() ### AI overview Google and Speakeasy are open-sourcing an OpenAPI code generation suite under the AGPLv3 license after the shutdown of Google's previous proprietary SDK provider. The suite generates deterministic, multi-language client libraries and supports strict typing, streaming, agent-native CLIs, and documentation MCP servers. ### Source excerpt Google has partnered with Speakeasy to open-source their OpenAPI code generation suite under the AGPLv3 license, a strategic move prompted by the sudden shutdown of Google's previous proprietary SDK provider. The newly open-sourced suite equips developers with deterministic, multi-language SDK generators that natively support strict typing and SSE streaming, alongside tools for compiling agent-native CLIs and documentation MCP servers. Engineering teams can now safely integrate this robust tooling directly into their CI pipelines to automatically generate reliable client libraries for their own APIs, all while retaining complete licensing control over the output code. ## What's New in Apollo Client 4.3 DevFeed: [What's New in Apollo Client 4.3]() Original publisher: [Read original article]() Author: Jerel Miller Published: 2026-09-15T12:01:05Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [GraphQL](), [TypeScript](), [Cache](), [Code generation]() Tags: [apollo-client](), [cache](), [codegen](), [graphql](), [native](), [typescript]() ### AI overview Apollo Client 4.3 adds native custom scalar support, type-safe cache access, and improved TypeScript handling for incremental GraphQL data. The release also updates generated types and data-state narrowing for deferred fields. ### Source excerpt Apollo Client 4.3 is here: native custom scalar support, type-safe cache access, and more consistent @defer and @stream behavior. See what's new and upgrade today. ## Introducing CUDA Rust: Two Tracks for Writing GPU Kernels DevFeed: [Introducing CUDA Rust: Two Tracks for Writing GPU Kernels]() Original publisher: [Read original article]() Author: Elizabeth Goodman Published: 2026-09-08T12:00:00Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [GPU](), [Code generation](), [toolchain](), [C++]() Tags: [c-plus-plus](), [cuda](), [cuda-tile](), [data-science](), [developer-tools-techniques](), [dynamo](), [gpu](), [kernels](), [nemo-retriever](), [open-source](), [programming-languages-compilers](), [rust](), [toolchains]() ### AI overview NVIDIA introduces CUDA Rust for writing GPU kernels natively in Rust and compiling them to PTX. The article explains the SIMT and Tile programming tracks, recommends Tile as the default, and describes cuda-oxide's Rust-based code-generation path. ### Source excerpt In September 2026, NVIDIA announced it is leaning into native GPU programming in Rust. CUDA C++ and CUDA Python are mature, enterprise-grade toolchains, and... ## Test what you ship: MSTest and Native AOT DevFeed: [Test what you ship: MSTest and Native AOT]() Original publisher: [Read original article]() Author: Amaury Levé Published: 2026-09-03T18:00:00Z Content type: article Language: en Sources: [.NET Blog]() Topics: [native aot](), [trimming](), [.NET](), [Code generation](), [Deployment]() Tags: [deployment](), [generation](), [mstest](), [native-aot](), [net](), [source-generators](), [testing](), [trimming]() ### AI overview MSTest 4.4 uses source generation to let test projects run as Native AOT executables, helping teams test under the same trimming and deployment constraints as their applications. The article explains that this can reveal application issues such as reflection-dependent serialization that managed test runs may miss. ### Source excerpt MSTest source generation lets test projects use the same Native AOT and trimming deployment model as the applications they validate, while reducing reflection on the test execution path. The post Test what you ship: MSTest and Native AOT appeared first on .NET Blog. ## MSVC Build Tools Preview updates - August 2026 DevFeed: [MSVC Build Tools Preview updates - August 2026]() Original publisher: [Read original article]() Author: Eric Brumer Published: 2026-08-13T15:01:10Z Content type: article Language: en Sources: [C++ Team Blog]() Topics: [MSVC](), [C++](), [Compiler](), [toolchain](), [Code generation](), [Optimization](), [Visual Studio]() Tags: [c-plus-plus](), [code-generation](), [diagnostics](), [features](), [ide](), [msvc](), [optimization](), [release](), [tools](), [updates](), [visual-studio](), [visual-studio-2026]() ### AI overview The article summarizes August 2026 updates to the MSVC Build Tools Preview, targeting the v14.52 release. It covers compiler conformance, diagnostics, C++ modules, code generation, optimization, and ARM64 improvements. ### Source excerpt Try the latest updates to MSVC Build Tools Preview The post MSVC Build Tools Preview updates - August 2026 appeared first on C++ Team Blog. ## Practical AI in Platform Engineering: lessons from Port's latest meetup DevFeed: [Practical AI in Platform Engineering: lessons from Port's latest meetup]() Original publisher: [Read original article]() Author: Matar Peles Published: 2026-08-10T11:42:45Z Content type: article Language: en Sources: [Developer Experience & Platform Engineering Blog | Port]() Topics: [Platform Engineering](), [Artificial Intelligence](), [AI-assisted coding](), [Code review](), [sdlc](), [Code generation](), [Incident response](), [Infrastructure as code](), [Security](), [vulnerability]() Tags: [agentic](), [ai](), [ai-coding](), [engineering](), [iac](), [ide](), [incident-response](), [platform-engineering](), [review](), [sdlc](), [security](), [testing]() ### AI overview Port's Tel Aviv meetup examined how engineering organizations are adopting AI in platform engineering. Speakers discussed agentic workflows for bug triage, platform requests, and the SDLC, while an anonymous survey measured AI maturity, production deployments, evaluation practices, human oversight, and concerns about autonomy. Most teams reported having a few SDLC agents but not scaling them broadly; code review and code generation were the most common production uses, while operational applications such as infrastructure, security, and incident response lagged behind. ### Source excerpt We hosted a meetup with engineering leaders working on AI inside their orgs and ran an anonymous survey. Here's what came out of it. ## Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage DevFeed: [Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-06T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [Code generation](), [Code]() Tags: [article](), [code-generation](), [compiler](), [compilers](), [engineering](), [measurement](), [ordering](), [research](), [verification]() ### AI overview This case study examines how blocking frequency can guide the order of instruction implementation in Keleusma's compiler backend. It contrasts instruction-level coverage with whole-program compilability and describes a small measurement tool that exposed a flawed implementation plan. ### Source excerpt A compiler was 87 percent finished. It could not compile two thirds of the programs it was for. Both numbers are correct. The first counts individual instructions the compiler knew how to translate. The second counts whole programs that would actually go through. The gap between them is what this article is about, and the reason it exists is simple enough to state in one sentence. A program needs every instruction it uses, not most of them. One missing instruction out of a hundred stops the whole thing, exactly as one missing link stops a chain. That gap then destroyed a carefully reasoned plan. One working session before the measurement was taken, the author of this article had formally recommended what the next piece of work should be. The reasoning had no invalid step in it. The measurement showed the recommendation to be worth nothing at all, because the thing it would have unblocked does not occur even once in any program the compiler is meant to serve. The instrument that established this took about twenty minutes to build and two seconds to run. The article reports that, and then reports four errors made while writing it, all four of which ran in the direction of a more striking result, and one of which was committed inside the paragraph warning against the other three. What this is a case study of The setting is compiler engineering, and a reader who has never written a compiler can follow the argument, because the shape of the problem is not specific to compilers. The concrete project is Keleusma, whose compiler until now has emitted bytecode for a virtual machine, as described in the self-hosting strategy and its getting-started article. Native code generation is the step after that one, and it is where the ordering question first became expensive enough to measure. The lineage of the design sits in the stream-based compilers series and in the self-hosted silicon compiler. None of that background is needed to follow what follows, and the measurement stands ## KotlinLLM is Going Open Source DevFeed: [KotlinLLM is Going Open Source]() Original publisher: [Read original article]() Author: Anastasia Birillo Published: 2026-07-28T07:50:41Z Content type: article Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog]() Topics: [kotlinllm](), [Kotlin](), [Open Source](), [IntelliJ IDEA](), [Large Language Model](), [Code generation](), [AI-assisted coding](), [Software Engineering]() Tags: [code-completion](), [code-generation](), [engineering](), [intellij](), [intellij-idea](), [kotlin](), [kotlinllm](), [llm](), [llms](), [open-source](), [plugin](), [research](), [research-prototype](), [software](), [software-engineering]() ### AI overview KotlinLLM is an open-source research prototype and IntelliJ IDEA plugin for Kotlin/JVM projects. It introduces Smart macros whose generated Kotlin source evolves from runtime scenarios, allowing applications to delegate selected logic to an LLM without calling the model on every request or relying on a separate runtime agent. ### Source excerpt TL;DR KotlinLLM is now public. It's a research prototype for delegating runtime logic to an LLM from Kotlin code. Instead of calling an LLM on every request or running a separate agent, you can write an explicit Kotlin call. Its body is generated Kotlin source code, and that code is updated as your application hits [...] ## NVIDIA Nemotron 3 Ultra Leads Open Models on Accuracy and Efficiency in Agentic RTL Coding DevFeed: [NVIDIA Nemotron 3 Ultra Leads Open Models on Accuracy and Efficiency in Agentic RTL Coding]() Original publisher: [Read original article]() Author: Nirmal Kumar Juluru Published: 2026-07-27T00:45:00Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [coding](), [Verilog](), [AI-assisted coding](), [Nvidia](), [Artificial Intelligence](), [debugging](), [Benchmark](), [Code generation](), [Hardware](), [long-context]() Tags: [agentic](), [agentic-ai-generative-ai](), [ai](), [ai-agent](), [ai-agents](), [automation](), [benchmark](), [chip-design](), [code](), [code-generation](), [coding](), [debugging](), [developer-tools-techniques](), [efficiency](), [engineering](), [featured](), [hardware-semiconductor](), [llms](), [long-context](), [models](), [nemotron](), [nvidia](), [open](), [reasoning](), [top-stories](), [validation]() ### AI overview NVIDIA's article presents ACE-RTL and Nemotron 3 Ultra as a combined approach to agentic RTL coding. The workflow generates Verilog, runs simulations and other EDA checks, analyzes failures, and iteratively refines designs while maintaining debugging context. The CVDP benchmark evaluates accuracy and efficiency on realistic RTL generation, modification, debugging, and verification tasks. ### Source excerpt Modern chip design is increasingly limited by engineering time. Register transfer level (RTL) development and verification require specialized hardware... ## Announcing Capital One's 2026 UIUC AI Awardees DevFeed: [Announcing Capital One's 2026 UIUC AI Awardees]() Original publisher: [Read original article]() Author: Capital One Tech Published: 2026-07-21T14:45:44Z Content type: release Language: en Sources: [Capital One Tech]() Topics: [Artificial Intelligence](), [ai safety](), [Generative AI](), [Large Language Model](), [Code generation](), [Cybersecurity]() Tags: [2026](), [academic-research](), [agentic-ai](), [agents](), [ai](), [ai-research](), [ai-safety](), [code-generation](), [cybersecurity](), [generative-ai](), [large-language-models-llms](), [research](), [science]() ### AI overview Capital One announces its 2026-2027 research and fellowship awardees from the University of Illinois. The featured projects address LLM reasoning faithfulness, code reasoning, imaginative LLM agents, and agentic AI safety. ### Source excerpt Meet the University of Illinois researchers and fellows advancing Agentic AI through our academic partnership.Announcing the Center for Generative AI Safety, Knowledge Systems, and Cybersecurity (ASKS) 2026-2027 Capital One Research Awardees from the University of Illinois As we look toward the 2026-2027 academic year, we continue to partner with institutions that lead the global conversation on the future of intelligence. We are thrilled to announce this year's cohort of research and fellowship awardees from the University of Illinois, whose pioneering work addresses the most critical frontier in technology today: Agentic AI. From the way machines "think" and "imagine" to the hardware that powers them and the safety protocols that govern them, these five projects represent Capital One's holistic push toward AI that is not only powerful but also faithful, safe and creative. The 2026-2027 research awardees1. Ensuring Intellectual Honesty Advancing LLM Reasoning Faithfulness without Faithfulness Rewards Faculty: Hao Peng Professor Peng is tackling the "hallucination" problem at its core. By developing methods to ensure large language models (LLMs) follow a logical, faithful reasoning path-without relying on traditional, often biased, reward systems-this work ensures that when an AI gives an answer, the "why" behind it is actually true, a critical component for trustworthy financial applications. TrACE-Contrast: Faithful & Consistent Code Reasoning via Trace-Aware Contrastive Learning Faculty: Talia Ringer and Reyhan Jabaarvand Writing code is one thing; understanding how it executes is another. Professor Ringer's project uses contrastive learning to align a model's code generation with its actual execution "trace." This ensures that AI-generated software is verified and logically sound, which is vital for maintaining the integrity of our core technology systems. 2. Bridging the Gap: Agency & Imagination Creative LLM Agents based on Thinking with Imagination Faculty: H ## Fragments: July 21 DevFeed: [Fragments: July 21]() Original publisher: [Read original article]() Author: Martin Fowler (martin@martinfowler.com) Published: 2026-07-21T13:13:00Z Content type: article Language: en Sources: [Martin Fowler]() Topics: [Vibe coding](), [Security](), [Large Language Model](), [Artificial Intelligence](), [Machine learning](), [Code generation](), [Software Engineering]() Tags: [ai](), [code-generation](), [data-quality](), [llms](), [modernization](), [security](), [testing](), [vibe-coding]() ### AI overview The article discusses findings from a software development retreat, emphasizing that verification has become more important as code generation improves. It examines risks from LLMs and vibe coding, including security concerns, poor contextual fit, weak testing, and inadequate data-quality controls. It argues for feedback sensors, organizational safeguards, and stronger engagement between engineers and executives. ### Source excerpt With this post, I'll wrap up my notes from the second Future of Software Development Retreat. But before I do, I should note that the full Thoughtworks report on the retreat is now available. They have five headline findings: Code generation is no longer the bottleneck -- verification is. 'Harness engineering' is emerging as a distinct, ownable discipline. Organizations are colliding with a real apprenticeship crisis. The executive/engineer expectation gap is a bigger risk than any technical limitation. Legacy modernization is the clearest, most defensible near-term value pool. ❄ ❄ A session convened around the mismatch of views about using LLMs between engineers using it and the C-suite and boards that were calling for it. The concern is that boards are looking at promised productivity gains, and not concerned enough about the risks, particularly about security. This was illustrated by one tale of a company that used ML-trained software to optimize the replacement of air filters on their field equipment. They were pleased to see that they were able to change the air filters less frequently, saving them $50 million. But the problem was the ML models were trained on equipment used in the desert, while their equipment was used in the arctic. Air filters in the desert deal with dust, but in the arctic the thing to remove is mosquitoes. There's an important difference here, mosquitoes rot, and enough decaying mosquitoes is a serious fire risk. Fires from such dead mosquitoes around infrequently replaced air filters cost the company $100 billion. Now such a tale could told of many situations without AI in the mix. Plenty of human situations have gone wrong when solutions are applied in a new context (which is why context is such a key word among pattern-writers). But the tale does remind us to be wary of an AI's suggestions, and to always think of how to build sensors to provide rapid feedback. Engineers particularly worry about the risks when citizen developers start vib ## Migrating from Apollo Tooling to GraphQL Codegen at Yelp DevFeed: [Migrating from Apollo Tooling to GraphQL Codegen at Yelp]() Original publisher: [Read original article]() Author: Igor Kusakov, Software Engineer Published: 2026-07-16T00:00:00Z Content type: article Language: en Sources: [Yelp]() Topics: [GraphQL](), [Code generation](), [migration](), [Tooling](), [React](), [TypeScript](), [monorepo]() Tags: [code-generation](), [deprecated](), [graphql](), [migrate](), [monorepo](), [react](), [tooling](), [typescript]() ### AI overview Yelp describes migrating its frontend React monorepo from deprecated Apollo Tooling to GraphQL Codegen for generating TypeScript definitions from GraphQL queries and the server schema. ### Source excerpt Introduction At Yelp, we rely heavily on GraphQL and Apollo for data loading in our frontend React monorepo. When a developer writes a GraphQL query or mutation inside a React component, the shape of the response is defined by the query itself -- but TypeScript has no way to know what that shape looks like at compile time. That's where code generation (codegen) comes in. We rely on codegen to read our queries and server schema, then produce TypeScript type definitions for every operation's input variables and output data. In our codebase, this looks like: src/components/UserProfile/ ├── UserProfile.tsx <- contains... ## How ParparVM Reached Performance Parity with Warmed Java 25 DevFeed: [How ParparVM Reached Performance Parity with Warmed Java 25]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-07-10T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Java](), [Benchmark](), [Optimization](), [Code generation](), [C](), [Project Valhalla]() Tags: [benchmark](), [c](), [java](), [memory](), [optimization](), [performance](), [project-valhalla]() ### AI overview This article explains how ParparVM, an ahead-of-time virtual machine that compiles Java bytecode to C, improved from 4.21x slower than warmed Java 25 to geometric-mean parity across ten benchmarks. It describes changes involving heap layout, code generation, allocation, and collection, with correctness checked against HotSpot. ### Source excerpt ParparVM went from 4.21x slower than warmed Java 25 to geomean parity, with peak memory below the JVM's. The architecture behind it, in C terms. ## Automated Schema Evolution in Pinterest's Next-Generation DB Ingestion Framework DevFeed: [Automated Schema Evolution in Pinterest's Next-Generation DB Ingestion Framework]() Original publisher: [Read original article]() Author: Pinterest Engineering Published: 2026-06-24T18:01:01Z Content type: article Language: en Sources: [Pinterest Engineering Blog - Medium]() Topics: [schema-evolution](), [Apache Iceberg](), [Automation](), [Databases](), [Apache Spark](), [Kafka](), [Pull Request](), [Code generation](), [datasets](), [monitor](), [Provisioning]() Tags: [automation](), [code-generation](), [datasets](), [engineering](), [icebergs](), [kafka](), [monitor](), [pinterest](), [process](), [schema-evolution](), [software](), [spark](), [storage]() ### AI overview Pinterest describes an automated schema-evolution framework for its CDC-based database ingestion platform, which uses Kafka, Flink, Spark, and Iceberg. The framework propagates supported schema changes across the stack, uses pull-request-based versioning and auditing, targets SLA-based consistency between online and offline schemas, and provides recovery paths for unsupported or ambiguous changes. ### Source excerpt Yisheng Zhou | Software Engineer II Liang Mou | Sr Staff Software Engineer Gabriel Raphael Garcia Montoya | Staff Software Engineer Istvan Podor | Staff Software Engineer Introduction In the first post of this series, we introduced Pinterest's next-generation CDC-based ingestion platform built on Kafka, Flink, Spark, and Iceberg. In production, upstream schemas are constantly evolving, and in a distributed CDC pipeline, schema is not just metadata -- it is a cross-system contract spanning ingestion, transformation, storage, and historical backfill. A schema change that is not handled carefully can break Flink jobs, block Spark upserts, or create inconsistencies between online and offline representations. This post walks through how we make schema evolution safe in practice: the onboarding model it builds on, the changes we support and the tradeoffs we accept, how updates propagate across the stack, and how we monitor and recover when things go wrong. We end with where we're heading next -- zero-gap schema evolution. Background & Motivation Schema evolution was particularly challenging in our environment because our ingestion pipeline is composed of multiple tightly related stages, each of which depends on schema in a different way. A single table onboarding flow spans CDC source configuration, Kafka provisioning, Flink and Spark code generation, Iceberg CDC and base table creation, and historical bootstrap -- all driven by the same schema. Once a source schema changes, that change must be reflected across code, metadata, and storage in a controlled and auditable way. Without a unified automation framework, manual updates across these layers increase the risk of drift, failed deployments, and inconsistent datasets. We therefore needed a way to make schema evolution safe, repeatable, and scalable. Our Solution: SLA-Based Automated Schema Evolution To address this problem, we built an automated schema evolution framework on top of our CDC ingestion platform, providing: au ## Learning Software Development When AI Can Generate, Debug, and Deploy Code DevFeed: [Learning Software Development When AI Can Generate, Debug, and Deploy Code]() Original publisher: [Read original article]() Author: Kevin Naughton Jr. Published: 2026-06-14T13:45:27Z Content type: opinion Language: en Sources: [The Software Engineer Weekly]() Topics: [Artificial Intelligence](), [Development](), [Code generation](), [debug](), [deploy]() Tags: [ai](), [code-generation](), [debug](), [deploy](), [development]() ### AI overview The document discusses learning software development as code-generation models can scaffold features, debug complex stack traces, and deploy apps without requiring users to understand the underlying mechanics. ### Source excerpt We're currently living through the most radical shift in the history of software development. Code generation models have become so frictionless that you can scaffold entire features, debug complex stack traces, and deploy apps without ever truly understanding the underlying mechanics ## WebSockets, gRPC, And GraphQL In The Core DevFeed: [WebSockets, gRPC, And GraphQL In The Core]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-07T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [WebSocket](), [GraphQL](), [gRPC](), [real-time](), [API](), [Code generation]() Tags: [api](), [graphql](), [pipeline](), [real-time](), [tutorial](), [websocket]() ### AI overview A hands-on tutorial covering WebSockets, typed GraphQL clients, and typed gRPC clients in the core framework. It explains how to build a real-time chat, generate typed clients from GraphQL schemas and proto files, and use WebSocket subscriptions. ### Source excerpt A hands-on walk through the three connectivity features that landed together this week, building a live chat over the new core WebSocket API and typed clients from a GraphQL schema and a proto file. ## OpenAPI, ORM, SVG and Lottie DevFeed: [OpenAPI, ORM, SVG and Lottie]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-01T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [OpenAPI Specification](), [Code generation](), [SQLite](), [Object-relational mapping](), [JSON](), [XML](), [SVG](), [ASP.NET Core](), [FastAPI](), [Nest]() Tags: [build](), [fastapi](), [http](), [java](), [json](), [lottie](), [maven-plugin](), [net](), [openapi](), [orm](), [rest](), [spring](), [svg](), [xml]() ### AI overview A Codename One release follow-up describes a shared build-time code generation pipeline for OpenAPI client generation, a SQLite ORM, JSON and XML mappers, SVG and Lottie transcoders, and a declarative router. The pipeline emits typed Java from annotations or declarative source files without reflection. ### Source excerpt An OpenAPI client generator, a JPA-shaped SQLite ORM, JAXB-shaped JSON / XML mappers, build-time SVG / Lottie transcoders, and a declarative router with deep links. All on the same build-time codegen pipeline. ## Joining forces to modernize legacy software DevFeed: [Joining forces to modernize legacy software]() Original publisher: [Read original article]() Author: Mary Louise Stewart Published: 2026-05-14T08:00:00Z Content type: release Language: en Sources: [Federico Tomassetti]() Topics: [Software](), [Reverse Engineering](), [Refactoring](), [Code generation](), [interoperability](), [AI-assisted coding]() Tags: [code-generation](), [interoperability](), [legacy-code](), [legacy-modernization](), [migration](), [model-driven-development](), [modernization](), [parsing](), [refactoring](), [reverse-engineering](), [software](), [transpilers]() ### AI overview Strumenta and Metadev announced a collaboration to modernize legacy software. Strumenta contributes code analysis, extraction, and transformation capabilities, while Metadev contributes modeling, AI integration, and code generation. Their approach uses LionWeb models as an intermediate representation between legacy code and modernized systems. ### Source excerpt Strumenta and Metadev Join Forces to Modernize Legacy Software A collaboration combining Strumenta's expertise in code analysis, extraction, and transformation with Metadev's capabilities in modeling, artificial intelligence, and code generation from models. Torino/Seville, May 14, 2026 -- Strumenta S.r.l. and Metadev S.L. have reached a collaboration agreement to offer a joint approach to Modernizing Legacy [...] The post Joining forces to modernize legacy software appeared first on Federico Tomassetti. ## Simplex rethinks software development with Codex DevFeed: [Simplex rethinks software development with Codex]() Original publisher: [Read original article]() Published: 2026-05-07T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [Software](), [software-development](), [codex](), [ChatGPT](), [Artificial Intelligence](), [AI Development](), [code productivity](), [Generative AI](), [AI-assisted coding](), [Code generation](), [Integration testing](), [Command-line interface]() Tags: [ai](), [chatgpt](), [cli](), [code](), [code-generation](), [codex](), [coding](), [deployment](), [developers](), [development](), [generative-ai](), [integration](), [productivity](), [python](), [software-development]() ### AI overview Simplex uses ChatGPT Enterprise and Codex to improve software development productivity, reporting reduced time for design, development, and internal integration testing. ### Source excerpt Simplex boosts software development with ChatGPT Enterprise and Codex, reducing design, build, and testing time while scaling AI-driven workflows. ## Migrating from Koin DSL to Koin Annotations in a Multimodule Project: A Step-by-Step Guide DevFeed: [Migrating from Koin DSL to Koin Annotations in a Multimodule Project: A Step-by-Step Guide]() Original publisher: [Read original article]() Author: Gabriel Bronzatti Moro Published: 2026-04-24T07:18:23Z Content type: tutorial Language: en Sources: [Koin developers - Medium]() Topics: [multiplatform](), [compose-multiplatform](), [Gradle](), [Code generation]() Tags: [code-generation](), [compose](), [compose-multiplatform](), [gradle](), [guide](), [koin](), [kotlin](), [ksp](), [multi-module-project](), [tutorial]() ### AI overview A step-by-step tutorial for migrating a Compose Multiplatform multimodule project from Koin DSL to Koin Annotations. It covers adding Koin Annotations and KSP dependencies, creating a Gradle convention plugin, enabling the setup in a module, and replacing manual Koin definitions with annotation-based registration. ### Source excerpt Hey friends 👋 Today we're going to explore how to migrate a Compose Multiplatform multi-module project from Koin DSL to Koin Annotations. We'll take a hands-on approach, diving deep into a project example built by the CodandoTV community. ⚠ In this tutorial, we won't cover the new Koin compiler. It's a significant improvement that simplifies much of the complexity we currently deal with when using KSP, but it deserves its own dedicated deep dive. A person's hand fitting a piece into a puzzle -- Unplash by rosssneddonFirst step: Setup Koin Annotations dependency First thing is let's make sure we are running the latest version of Koin. For that, visit our documentation. After that, let's add our Koin Annotations dependency into the libs.versions.toml . // gradle/libs.versions.toml [versions] koin-annotations = "" ksp = "" ... [libraries] ... com-google-devtools-ksp-gradle-plugin = { module = "com.google.devtools.ksp:com.google.devtools.ksp.gradle.plugin", version.ref = "ksp" } koin-annotations = { module = "io.insert-koin:koin-annotations", version.ref = "koin-annotations" } koin-ksp-compiler = { module = "io.insert-koin:koin-ksp-compiler", version.ref = "koin-annotations" } KSP is also required, as it enables the code generation used by Koin Annotations. After adding the dependencies, run a Gradle sync to make them available to the project. Let's make sure we have the ksp plugin enabled in the root gradle project: // root/build.gradle.kts plugins { alias(libs.plugins.ksp) apply false ... } Let's head over to the build-logic folder and encapsulate all this setup inside a new Gradle convention plugin. To make this work, we need to add KSP as a library dependency: // build-logic/build.gradle.kts ... dependencies { implementation(libs.com.google.devtools.ksp.gradle.plugin) } Again, let's run Gradle sync 🐘 Second step: Create your conventional Gradle Plugin Inside of your build-logic , let's create a new custom plugin, we can call it com.st ## UIScene on by Default and iOS Performance DevFeed: [UIScene on by Default and iOS Performance]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-04-18T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [iOS](), [Optimization](), [Code generation](), [Code](), [App]() Tags: [build](), [ios](), [native](), [optimization](), [performance](), [production]() ### AI overview Codename One plans to make UIScene the default for iOS builds in an upcoming update, following testing and Apple requirements. The article also reports that Base64 performance on iOS reached parity with native code through ParparVM optimization hints, including method-level hints that can reduce generated code and suppress selected checks. ### Source excerpt Last month Imentioned an option to enable UIScene in Codename One builds. We tested that mode for the past month and with the coming update this Friday we will flip the default mode. This means that builds will implicitly set the build hintios.uiscene=true instead of the current default offalse. Ideally, this would have no impact on anyone... ## Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1 DevFeed: [Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-04-14T08:08:36Z Content type: release Language: en Sources: [Koin developers - Medium]() Topics: [koin](), [Compiler](), [Dependency injection](), [Kotlin](), [Code generation]() Tags: [compilation](), [compiler](), [dependency](), [dependency-injection](), [generation](), [koin](), [kotlin](), [kotlin-multiplatform](), [plugin](), [release](), [safety]() ### AI overview Koin announces Compiler Plugin 1.0.0-RC1 for Kotlin and KMP. The release candidate validates dependency graphs during compilation and adds constructor auto-wiring across DSL and annotations. ### Source excerpt Koin Compiler Plugin 1.0.0-RC1 -- Unlocking Compile-Safe Dependency Injection for Kotlin & KMP Hello Koin Community 👋 Compile-time safety has been one of the most requested features by the community. For years, verifying your Koin dependency graph required runtime tools with checkModules()and verify()in your test suite. They run after compilation. If something is missing, you find out in test results, not at build time. It's now time for new generation of tools for Koin. My Linkedin post for AndroidMakers Last week at Android Makers (Paris, France), we announced Koin Compiler Plugin 1.0.0-RC1! This release candidate brings compile-time safety, constructor auto-wiring, and a unified developer experience for both DSL and Annotations, all powered by a native Kotlin Compiler Plugin. Aligned with Koin 4.2.1 and Kotlin 2.3.20. Check out the roadmap and documentation to get started. Dependency graph validation is done in the Koin Compiler Plugin itself: your graph is verified as part of the build (no need to run tests). DSL, annotations, and even individual call sites are checked. The Kotlin compiler plugin ecosystem has matured, and new DI approaches are emerging. Koin's answer is straightforward: lighter Compiler codegen, an existing runtime container, and validation by design of the compilation. Koin Compiler Plugin -- 1.0.0-RC1Check the online Koin documentation for further information: https://insert-koin.io/docs/intro/koin-compiler-plugin We are also gathering some "playground apps" to showcase different scenarios of Koin Compiler Usages (https://github.com/InsertKoinIO/playground-apps) Koin Compiler Plugin Setup 🔎 Below, you will find the minimum versions of Koin & Koin Compiler Plugin that are allowed to enable compile safety (note that you need Kotlin 2.3.20): [versions] kotlin = "2.3.20" koin = "4.2.1" koin-plugin = "1.0.0-RC1" [libraries] koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" } # if using annotations koin-annotations = { module = ## How Claude Code's Source Map Was Shipped and Rebuilt by the Community DevFeed: [How Claude Code's Source Map Was Shipped and Rebuilt by the Community]() Original publisher: [Read original article]() Author: Engineer's Codex Published: 2026-04-01T06:25:24Z Content type: article Language: en Sources: [Engineer's Codex]() Topics: [Claude Code](), [anthropic](), [Code generation](), [GitHub](), [Artificial Intelligence](), [Code review]() Tags: [ai](), [anthropic](), [claude-code](), [codegen](), [github](), [leak](), [npm](), [openai](), [post-mortems]() ### AI overview The article examines how Anthropic accidentally included a sourcemap in a Claude Code npm package, how the exposed code was mirrored and ported to other languages, and the resulting copyright questions around AI-assisted clean-room rebuilding. ### Source excerpt Engineer's Codex is a publication about real-world software engineering. ## The architectural trade-offs of AI code generation DevFeed: [The architectural trade-offs of AI code generation]() Original publisher: [Read original article]() Published: 2026-03-31T00:00:00Z Content type: article Language: en Sources: [Aha! Engineering Blog]() Topics: [AI-assisted coding](), [Code generation](), [Large Language Model](), [Ruby](), [Claude Code]() Tags: [ai-assistant](), [claude-code](), [code-generation](), [memory](), [ruby]() ### AI overview The article examines architectural trade-offs in building Aha! Builder, an AI-powered product that generates database schemas, controllers, and views. It argues that frameworks and languages for LLM-generated code should account for token efficiency and context-window limits, and cites a Claude Code benchmark in which Ruby had the highest success rate across the tested languages. ### Source excerpt We recently introduced Aha! Builder, our new AI-powered product for creating prototypes and business applications. It allows you to describe the app you need, and Elle (our AI assistant) builds it for you. But Elle is not just a UI trick. When a us [Next page]()