A question posted to Hacker News this week cuts to the heart of a practical AI capability that gets less attention than code generation or mathematical reasoning: can large language models port software between platforms? The post, which asks how close we are to making "porting X software to Y platform" a matter of token costs, frames the issue in concrete terms by citing the long-standing demand for Adobe applications on Linux.
Why Software Porting Is Harder Than Code Generation
Generating new code from a prompt and translating existing code between platforms are fundamentally different problems. Code generation asks a model to produce something from a specification. Porting asks a model to understand a large, interconnected codebase that relies on platform-specific APIs, system calls, memory management conventions, build toolchains, and third-party dependencies, then reproduce equivalent behavior on a different target. The specification is the existing software itself, and it is implicit across millions of lines of code.
Adobe's Linux absence illustrates the complexity. The Creative Cloud suite depends on Windows and macOS APIs for graphics rendering, font management, file system behavior, hardware acceleration, copy protection, and plugin ecosystems. Porting Photoshop to Linux would not just mean rewriting UI code. It would mean replacing or reimplementing deep system dependencies that assume a specific operating system architecture. An LLM can generate a function that opens a file on Linux instead of Windows. It cannot, on its own, audit ten thousand interdependent modules and determine which ones contain platform assumptions and what the correct Linux equivalent behavior should be.
What LLMs Actually Do Well in Porting Workflows
That said, LLMs are genuinely useful for parts of the porting process. They can translate individual functions or small modules from one language to another with reasonable accuracy. They can identify common API patterns and suggest replacements, such as swapping Windows registry calls for Linux configuration file reads. They can generate build system configurations for CMake or Meson when given the right context. They can write migration scripts that handle repetitive transformations across a codebase.
The pattern that emerges in practice is that LLMs accelerate the mechanical parts of porting while leaving the architectural decisions to humans. A developer porting a cross-platform application might use an LLM to translate hundreds of small utility functions, then manually redesign the rendering pipeline or the plugin system themselves. The time savings are real but unevenly distributed. The boring, repetitive translation work gets faster. The hard design decisions stay hard.
The Scale Problem
The Hacker News question specifically asks about porting entire applications, not individual functions. This is where current LLM capabilities hit a practical ceiling. Porting a large application requires maintaining context across an enormous codebase. LLM context windows, while growing, are still far too small to hold a project like Photoshop in memory. Even with retrieval-augmented generation approaches that feed relevant code snippets to the model, the interdependencies between distant parts of a codebase are exactly the kind of thing that retrieval systems miss.
There is also the verification problem. After an LLM transforms code, someone needs to test whether the result works. For a ported application, that means running it on the target platform, testing every feature, and identifying regressions. This testing step does not get cheaper just because the code transformation was automated. In some cases it gets more expensive, because the automated transformation may introduce subtle bugs that manual porting would have avoided through developer judgment at each step.
Where the Industry Actually Stands
Companies doing real porting work today use LLMs as assistants within a human-driven workflow. The typical approach involves a developer who understands both the source and target platforms, uses LLM tools to accelerate specific translation tasks, and makes architectural decisions based on deep knowledge of both codebases. The LLM replaces Stack Overflow searches and boilerplate generation, not the porting engineer.
For the specific example of Adobe on Linux, the barrier is not primarily a code translation problem. Adobe has business reasons for not supporting Linux, including market size, support costs, and the economics of developing for a platform with a small desktop user base. Even if an LLM could perfectly translate the entire Creative Cloud suite to Linux tomorrow, Adobe would still need to commit to ongoing maintenance, testing, and support on that platform. The technical challenge is real but it is not the binding constraint.
What Would Need to Change
For "porting X to Y" to become a token-cost question, several things would need to improve. Context windows would need to be large enough to hold an entire codebase, or retrieval systems would need to become reliable enough to reconstruct cross-module dependencies on demand. Models would need to develop genuine understanding of platform-specific behavior patterns, not just surface-level API translation. And automated testing infrastructure would need to advance to the point where ported code could be validated without extensive manual QA.
None of these are impossible, but none are solved problems today. The realistic timeline for LLMs handling small-to-medium porting projects with minimal human oversight is probably years, not months. Full application suites with deep platform dependencies will remain human-driven work for longer still. The question on Hacker News is the right one to ask, but the answer in 2026 is that LLMs are a porting accelerator, not a porting replacement.