Draft article not currently submitted for review. This is a draft Articles for creation (AfC) submission. It is not currently pending review. While there are no deadlines, abandoned drafts may be deleted after six months. To edit or make changes to this draft, simply click on the "Edit" tab at the top of the window. To be accepted, a draft should: Show the subject qualifies for a Wikipedia article by using multiple sources that meet four criteria. The sources should be (1) reliable (2) secondary (3) independent of the subject (4) talk about the subject in some depth. For some topics, there are alternative criteria. Be written from a neutral point of view Respect copyright and do not plagiarize. Do not copy-paste. It is strongly discouraged to write about either yourself or your business or employer. If you do so, you must declare it. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Last edited by Citation bot (talk | contribs) 4 months ago. (Update) Submit the draft for review!

Language as Code (LaC) is a post-code development paradigm where natural language is the primary programming medium and no code is written manually.

Language as Code is a way of programming that requires the programmer to write only natural language specifications of the software to build, leaving the translation to a programming language to an AI coding tool. It may be viewed as an extreme interpretation of Spec Driven Programming or AI assisted coding.

The developer is not supposed to even look at the generated code, the same way developers nowadays are not looking into bytecode or compiled machine language.

Natural Language is threated as a programming language, is kept under version control, branched, merged and in generally managed as code.

Chen et al. described “promptware engineering” as a software-engineering approach for prompt-enabled systems.^[1]

Liu et al. surveyed “prompting frameworks” for large language models, defining them as systems for managing and structuring interactions with LLMs and classifying them by their role in the prompting lifecycle.^[2]

A 2024 preprint by Xu et al. described CoRE as a system in which a large language model interprets structured natural-language instructions, with the aim of providing a common representation for natural-language programming, pseudocode, and flow programming in AI agents.^[3]

An MIT CSAIL news article reported that researchers developed three neurosymbolic frameworks showing how natural language can provide abstractions that improve LLM performance in code synthesis, AI planning, and robotics tasks.^[4]

The article says these methods use everyday language as a source of high-level representations, helping models handle more complex reasoning problems than they otherwise could. ^[4]

Martin Fowler argued that large language models could change software development as significantly as the transition from assembly language to high-level programming languages, while also introducing the challenge of working with non-deterministic tools.^[5]

The article also describes software development as a history of increasing abstraction through languages and frameworks, and suggests that LLMs alter not only the level of abstraction but also the nature of programming itself.^[5]

Liang, Lin, Rao, and Myers argued in Prompts Are Programs Too! Understanding How Developers Build Software Containing Prompts (2025) that some prompts function as programs and that their creation constitutes a distinct form of software development they call "prompt programming". Based on interviews with 20 developers, the paper described prompt programming as a process shaped by experimentation with foundation models rather than by stable mental models of program behavior. It identified 15 observations about current practice, including the fragility of prompts, the difficulty of fault localization, and the importance of dataset curation and multi-scope testing. The authors concluded that prompt programming differs in important ways from traditional software engineering and called for tools and processes tailored to prompt development.^[6]

Microsoft's Best practices for using AI in VS Code is an official Visual Studio Code documentation page that provides guidance on using AI-assisted features effectively in software development. It recommends configuring projects for AI, choosing the appropriate tool or model for each task, and writing specific prompts with relevant context to improve results. The guide also advises separating planning from implementation for complex changes and supplying tests or expected outputs so AI-generated work can be verified. It further emphasizes reviewing AI-generated code for bugs, security issues, and logic errors, and managing conversation context to avoid degraded responses.^[7]

Microsoft's Use custom instructions in VS Code is an official Visual Studio Code documentation page describing how users can define persistent instructions that automatically shape AI-assisted coding and other development tasks. It explains that these instructions can be applied to all chat requests, attached manually to individual prompts, or limited to particular files and tasks through Markdown-based instruction files. The guide describes repository-wide files such as .github/copilot-instructions.md, file-specific *.instructions.md files, and organization-level instructions shared across teams. It also notes that file-based instructions are the recommended approach for code and test generation, while settings-based instructions for those uses were deprecated in VS Code 1.102.^[8]

Microsoft's Use prompt files in VS Code is an official Visual Studio Code documentation page describing prompt files as a way to define reusable, lightweight prompts for specific development tasks. It explains that prompt files are Markdown files with the .prompt.md extension, can be stored at the workspace or user level, and may include YAML front matter to configure behavior such as tools and agent settings. The guide also states that prompt files can be created manually or generated from task descriptions and existing chat conversations, then invoked in chat as slash commands or run directly from the editor. It further distinguishes prompt files from custom agents and agent skills, presenting them as suitable for single-task prompts rather than persistent personas or multi-file capabilities.^[9]

Microsoft's Set up a context engineering flow in VS Code is an official Visual Studio Code guide that describes context engineering as a systematic method for providing AI agents with targeted project information to improve the quality and accuracy of generated code. It outlines a three-step workflow consisting of curating project-wide context with custom instructions, generating an implementation plan with a planning agent, and producing implementation code that follows project guidelines. The guide presents custom instructions, custom agents, and prompt files as the main mechanisms for maintaining relevant context and structuring AI-assisted development workflows. It also states that successful context engineering should reduce back-and-forth corrections, improve consistency, speed implementation, and help align generated solutions with project goals and architectural constraints.^[10]

Microsoft's Diving Into Spec-Driven Development With GitHub Spec Kit is a 2025 blog post by Den Delimarsky that presents spec-driven development (SDD) as an AI-oriented software workflow centered on explicit, reviewable, and evolving specifications rather than ad hoc code generation. It argues that SDD is intended to capture shared context and technical reasoning before implementation, particularly in projects that use AI agents to generate code. The post introduces GitHub Spec Kit as a toolkit for applying this approach through a Python-based CLI, reusable templates, helper scripts, and agent-specific prompts. It describes a sequential workflow built around the slash commands /specify, /plan, and /tasks, which respectively define project requirements, technical plans, and implementation tasks. The article presents this process as a way to improve alignment, maintainability, and experimentation by separating specification from implementation and treating specifications as living project artifacts.^[11]

In a 2025 article on Martin Fowler's website, Birgitta Böckeler described spec-driven development (SDD) as an emerging and still fluid term for AI-assisted software development in which specifications are written before code and serve as a shared source of truth for humans and AI systems. She proposed three observed levels of the approach—spec-first, spec-anchored, and spec-as-source—distinguishing between workflows that merely begin with a specification and those in which specifications remain the primary maintained artifact over time. The article also defined a "spec" as a structured, behavior-oriented natural-language artifact that guides AI coding agents, and distinguished such task-specific specifications from broader project context or "memory bank" documents. Böckeler examined three tools associated with the approach—Kiro, GitHub's spec-kit, and the Tessl Framework—and argued that they reflect different interpretations and implementation depths of SDD. She concluded that the concept remains unsettled in practice and that its long-term usefulness, especially in existing codebases, still requires further real-world evaluation.^[12]