Igor Ostrovsky

It is hard to communicate how much programming has changed due to AI in the last 2 months: not gradually and over time in the "progress as usual" way, but specifically this last December. There are a number of asterisks but imo coding agents basically didn’t work before December and basically work since - the models have significantly higher quality, long-term coherence and tenacity and they can power through large and long tasks, well past enough that it is extremely disruptive to the default programming workflow. Just to give an example, over the weekend I was building a local video analysis dashboard for the cameras of my home so I wrote: “Here is the local IP and username/password of my DGX Spark. Log in, set up ssh keys, set up vLLM, download and bench Qwen3-VL, set up a server endpoint to inference videos, a basic web ui dashboard, test everything, set it up with systemd, record memory notes for yourself and write up a markdown report for me”. The agent went off for ~30 minutes, ran into multiple issues, researched solutions online, resolved them one by one, wrote the code, tested it, debugged it, set up the services, and came back with the report and it was just done. I didn’t touch anything. All of this could easily have been a weekend project just 3 months ago but today it’s something you kick off and forget about for 30 minutes. As a result, programming is becoming unrecognizable. You’re not typing computer code into an editor like the way things were since computers were invented, that era is over. You're spinning up AI agents, giving them tasks *in English* and managing and reviewing their work in parallel. The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator Claws with all of the right tools, memory and instructions that productively manage multiple parallel Code instances for you. The leverage achievable via top tier "agentic engineering" feels very high right now. It’s not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas. It works a lot better in some scenarios than others (e.g. especially for tasks that are well-specified and where you can verify/test functionality). The key is to build intuition to decompose the task just right to hand off the parts that work and help out around the edges. But imo, this is nowhere near "business as usual" time in software.

So what would you say....you do here?

What comes after the IDE? This is our take.

Intent is our vision for what comes after the IDE. AI has changed how we build software. But, it’s also made our workflows messier. One agent is great. Two work. Past that, things fall apart fast. Prompts go stale, context lives everywhere, and you end up spending more time on the tedious work of orchestrating agents. The bottleneck isn’t writing code anymore. It’s keeping the agents aligned. That’s why we built Intent.

There's an AI coding approach that lets you run seriously long-running AI agents (hours, days) that ship code while you sleep. I've tried it, and I'm not going back. It's the Ralph Wiggum approach. Here it is in a nutshell: Run a coding agent with a clean slate, again and again until a stop condition is met. The Bash Script Running ralph involves a single bash script. 1. Set up a bash for loop that runs a set number of times, let's say 10. You choose a finite number to prevent the agent running infinitely. 2. Inside the loop, you get the coding agent (Claude Code, OpenCode, Codex etc) to work on a single feature in the repo until that single feature is done. You prompt it to say "if, after implementing, there is no further work to be done, reply with COMPLETE. 3. Check for COMPLETE inside the loop and exit early if it exists. The Stop Condition How does the LLM know when to emit COMPLETE? There are multiple approaches: - Raw Prompting: Just pass a very clear stop condition to the prompt inside the bash loop. "The job is complete when X conditions are met" - TODO list: Give the agent a TODO list to complete - PRD: My preferred approach, explained below Progress Reports In your prompt, you MUST tell the agent to commit its work, and append its progress to a local progress.txt file. Committing its work allows future agents to navigate what was done via the git history. The progress.txt is a standard long-running agent practice. Feed it in to the agent via the prompt, and use the verb 'append' to make sure it doesn't update previous entries. Keep CI Green Each commit MUST pass all tests and types. This means you have to prompt the agent to run typechecks and tests on each commit. If you don't do this, you're hamstringing future agent runs with bad code, and they'll need to bisect to find bugs. Super nasty. This means that building really healthy feedback loops is CRITICAL to Ralph's success. The PRD Two problems immediately emerge with Ralph. The first is that the agent picks tasks which are too large. They don't scope the amount of work correctly and they try things which are too ambitious. This means they run out of context window and just end up failing. The second is that the agent doesn't know when to stop. To solve this, I use a PRD-based approach that formalizes the work I want Ralph to complete in a list of user stories. It's a mix of a PRD and a TODO-list, where the PRD is a JSON file of user stories with 'passes: false'. I then prompt the agent to pick the highest priority feature, and ONLY work on that feature. It then updates the passing status of the relevant PRD item at the end. This scopes it down extremely effectively, meaning it utilizes only a small part of its context window, and thus isn't swamped by context rot. Summary - Bash script - JSON-based PRD - progress.txt - Keep CI green - Feedback loops You'll have an AI coding setup that can ship while you kip.