If you’re following AI trends, you’ve seen the profession of software engineering change overnight. One veteran engineer after another has been saying they haven’t written any code in months, but rather rely purely on AI to produce work (aka vibe coding). In this year alone we are already seeing pure vibe coded apps get acquired. For instance, OpenClaw, an AI assistant, was bought by OpenAI and Moltbook, a social network for AI agents, by Meta. A friend of mine described a process where he has a plethora of terminal windows open with AI working on different tasks that brought to mind internet poker set ups I had seen where players rapidly flit through dozens of games at a time with their attention darting from one hand to the next making split second choices.
This really came into focus during my first week as a fellow at Harvard’s Berkman Klein Center for Internet & Society, when fellow fellow Jim Cowie described his process for creating a website that aggregates news from first hand social media like Telegram, editorializes it, measures the editorials for bias, before synthesizing a series of opinions from a panel of “experts” moderated by an ombudsman he had manifested via AI as well. He did this all in one day. The sheer efficiency and scale of this demonstration made me realize I had to refigure my entire process of software engineering from deployment to end users. Even the concepts of how to structure code for readability are entirely moot because no human will ever be expected to read this code. It doesn’t even matter if the vibe coded application uses technology I have any personal experience with.
By 2026 the term “vibe coding” seemed diminutive and obsolete. It described a more uncertain time when the projects coming out of LLMs were more novel and only borderline useful. Today, models like Anthropic’s Opus 4.6 are creating enterprise level results and vibe coding has given way to fleshed out engineering.
With all this in mind, what does a development environment look like for AI coding? In the days of yore, an IDE (or Integrated Development Environment) was the mix of technologies an engineer would use to write code and deliver software. Typically this involved a code editor, a compiler, a debugger, a source control tool, and a deployment method. This chain of tech is mostly meaningless now. The idea that you need to create a local project with version control and deployment scheme to test and live servers seems like a quaint thought in 2026. A popular post on Twitter titled “HOW TO RAW DOG DEV ON THE SERVER” describes a method where the user installs Claude Code directly on a virtual private server (VPS) and iterates on an app live to the world. And rather than using the initialism “IDE” people are using the term “harness” to describe their software making process.
It turns out that integrating an AI tool like Claude directly on the server is the real game changing efficiency. Previously, I had been using Claude to describe things for me rather than do them. How do I set up SSL certs on my server? How do I provision an AWS ec2 server for a NodeJS app? Even that felt like magic back in 2025. But letting Claude loose on your server with sudo access is the uncut pure gains you’re looking for. Instead of letting it give instructions to tell you how to do stuff you just tell it to do the stuff and it’s done. Another outcome is that due to the cheap accessibility of VPS, if something goes wrong during your vibe coding session, it can actually be easier just to nuke the server and start over with a new VPS rather than trying to fix anything.
This is what my new process looks like:
- Chat with Claude in the browser to create a work plan in plain text that is designed to be passed off to a separate LLM instance in the VPS
- Get a server, I use Digital Ocean to spin up VPS as needed
- Install Claude Code, if you’re feeling spicy give it root access
- Provide your VPS with the work plan and ask it for any feedback, if things look good then have it create a technical roadmap
- Execute on the technical roadmap and begin iterating on the results
I will be updating and refining this process over the course of the fellowship, but I haven’t seen a need to get into things like claude.md files or skills yet. Any feedback is, of course, welcome.
When I first started experimenting with vibe coding the gains in efficiency were undeniable and I quickly became reliant on the method. But repeated long term use bred in me a sort of ickiness. The interface provided by these companies nudges you into a subordinate role to the machine and you find yourself saying things like “can you do this”, “what if we tried…”, or god forbid “please” and “thank you.” At this point there are hundreds of articles written about how to get the most out of your AI coding experience. A lot of the advice asks you to prime your project with aphorisms like “keep it simple,” “discard your ego,” or “don’t make up information” which I will never not think is an insane way to write software.
How we use language reinforces how we perceive the world, and thus makes this technology more insidious than the forbearers it is compared to, such as the calculator, spell check or even the home computer. We are being trained as much as we are training it. Even addressing the AI with pronouns doesn’t feel good and there is already a lot of concern about how language models hijack our sense of empathy.
It is impossible to think of a world where a coder not using AI could keep up with this paradigm shift. Over the following months, I will use this blog to investigate and propose some consequences this could have on software, web design, visual culture, art, and the cultural sector at large.