Put @prompt<\/strong> in the source file instead of @file<\/strong> in the prompt dialog.<\/p>\n\n\n\n
That is the simple premise behind inline prompting, so that interacting with AI integrates with rather than disrupts my existing workflows. In most applications AI feels bolted on. Awkward. Intrusive.<\/p>\n\n\n\n
I\u2019m old school, my \u201cIDE\u201d is emacs in one half of a split screen terminal window and bash in the other. That is the most productive development environment for me. Anything that pulls me away from the keyboard and looking at the code slows me down, whether it is navigating to a separate app, picking a menu item, or typing text in a dialog box. Inline prompting allows me to write prompts for the coding agent inside the work product itself and stay in flow, then execute all inline prompts with a single command or keystroke.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\/\/ - inline prompts looks like the following:\n\/\/\n\/\/ @codex\n\/\/ - implement this method to reverse the elements of a vector\nvector<string> &Foo::reverse(vector<string> &in) {\n \/\/ - the coding agent fills in the body of the method, not shown here\n}<\/pre>\n\n\n\n
Given that I live in emacs<\/strong> and bash<\/strong>, shell scripts were the natural choice to implement processing of inline prompts. I can execute from the bash<\/strong> terminal, or bind to a expression in emacs, and bind the expression to a key sequence.<\/p>\n\n\n\n
<\/div>\n\n\n\n
#!\/usr\/bin\/bash\n\nset -euo pipefail\n\n# - omitted for brevity, other shell commands could be executed here and\n# results used in constructing the prompt below\n# - ditto for command line arguments, especially useful for passing context\n# from the IDE\n\ncodex exec -m gpt-5-codex --sandbox workspace-write <<'EOF'\n- find source files in this repository with the tag @codex in comments\n- the comments following the @codex tags are instructions for you\n- instructions end with the comment block or tag @end\n- generate a session timestamp at the beginning of each session in the form\n YYYY-MM-DD HH:mm\n- after you make modifications related to a particular @codex tag,\n add the session timestamp after the @codex tag\n- only update for @codex tags without revision timestamps; those with\n revision timestamps are from previous sessions\n- record the revision timestamp in the comment block marked @revision\n with one revision per line with a brief summary of the revisions\n- comment code copiously for human review, in particular any block\n larger than a dozen lines\n- mark your changes with a @review tag with the session timestamp\n- src\/template.h and src\/template.c are provided as style guides and should be followed\n especially when adding new source files, classes, methods, functions, or\n variables; these templates should also be used in refactoring when\n moving methods etc.\nEOF<\/pre>\n\n\n\n
While I edit code in emacs, I do love the visual debuggers in IDEs over gdb<\/strong> and lldb<\/strong> and use CLion for its cross platform support. I can\u2019t speak to all IDEs, but CLion allows easy integration of shell scripts as External Tools<\/strong> with macros like $FilePath$<\/strong> to pass IDE context to the shell script. Many of the other apps and IDEs I peeked at supported customizations, but felt klunky and bolted on and less powerful, flexible, and portable than simple shell scripts.<\/p>\n\n\n\n
\nIntegrating shell scripts in CLion IDE is straightforward.<\/figcaption><\/figure>\n<\/div>\n\n\n\n
Inline prompting leverages existing models for this interaction, using @mentions<\/strong> to mark prompts (and I used several in addition to @codex<\/strong>: for instance, @doxy<\/strong>, @review<\/strong> and @refactor<\/strong>), and can leverage #hashtags<\/strong> or other markup as prompting shorthand (for example, there could be #hashtags<\/strong> for common @refactor<\/strong>ing tasks like #rename<\/strong>). Inline prompting also follows tools like doxygen<\/strong> by putting all the meta text in code comments. It\u2019s old wine in new bottles, having coding agents adopt existing patterns rather than inventing.<\/p>\n\n\n\n
The way AI and coding agents are implemented in some user interfaces is so intrusive that it becomes a distraction and I turn off AI features wholesale. I want a relationship modelled after the one an author might have with an editor \u2014 instead of hovering annoyingly <\/em>over my shoulder during the creative process, interrupting me every few minutes with yet another unwelcome suggestion, let\u2019s communicate via mark up text in the \u201cmargins\u201d of the document. Without going into detail, I also believe inline prompting is a superior model for other disciplines \u2014 think of how interaction with a human reviewer would be structured, and model AI interaction after that<\/em><\/p>\n\n\n\n
REPL Coding<\/h2>\n\n\n\n
At scale software engineering is an iterative process, and the majority of the work is iterative refinement of existing code<\/em> to modify, extend, or correct existing functionality. Iterations have become progressively tighter from the era of waterfall, through the age of Agile, to Continuous Delivery and Deployment (CI\/CD), and onto today\u2019s coding agents. In essence, a software engineer is iterating in what is classically termed a read-eval-print-loop (REPL) with a coding agent as a pair programming bot.<\/p>\n\n\n\n
Inline prompting streamlines REPL and permits precision control, targeting, and scoping by colocating coding agent prompts with code. It better supports co-mingling hand crafted and generated code. The prompts can also remain as artifacts in the code and solve a common question and complaint, what prompts were used to generate this code? As a matter of housekeeping I do clean up older inline prompts knowing I can always find them again in revision history. I also prompt the coding agent to add a @revision<\/strong> tag with a timestamp and brief comment on change to a source file.<\/p>\n\n\n\n
Over time the set of scripts will become fine tuned for the most common tasks, customized and optimized for specific workflows, with prompting compacted into specialized @tags<\/strong> and markup elements, making for efficient interaction with a coding agent as a pair programming bot.<\/p>\n\n\n\n
In Conclusion<\/h2>\n\n\n\n
It\u2019s a pretty simple idea. Put prompts inline with the source code. Use a shell script to process the inline prompts. Integrate the shell scripts with your editor or IDE. Or just run from a shell. It was born of frustration with the friction of interacting with coding agents and wanting to keep my workflow streamlined.<\/p>\n\n\n\n
![\"\"](\"https:\/\/pyyk.ai\/wp-content\/uploads\/2026\/03\/CLion-REPL-Code-1-1024x844.png\")