AI is here to stay, and the ways that developers make applications are forever changing. There is no return to human-only coding. Moving forward, I’m convinced that the vast majority of code will be generated and not written. This transition is happening sooner than most people think. Developers, your workflow is about to change whether you want it to or not.
Over the last several weeks, I started talking to Google Gemini with entire codebases attached to my prompts. This has been a huge unlock. In a matter of a few weeks, I’ve been able to build a 100% bash CLI version of my WordPress toolkit. This experience has reshaped how I’m able to get things built and gives me a glimpse into how coding might look within the next year or two.
Why Google Gemini?
- Very capable coder – Understands git diffs and is very good at outputting just the sections of code that have changed.
- Very affordable – Starts with a free plan, then $20/month. The $20/month also replaces a $10/month plan I was already paying for personally for the upgraded 1TB of Google storage.
- Larger context window – Can easily take in 2MBs to 3MBs of TXT.
Google Gemini is the first affordable model that is really good at coding. Using the standard chat interface is a great way for developers to begin to see what’s possible.
Concatenating a codebase into a single file with _do.
Part of my workflow relies on the _do CLI. You can get that working by running the alias _do='bash <(curl -sL https://captaincore.io/do)' in your terminal. See here for more info on _do.
To get started, you don’t need to figure out any fancy AI tools or AI agents. Pick any WordPress plugin, WordPress theme, or any code project, and smash all of the code together using a bash script. Then talk to Google Gemini. Here is an outline of my current workflow.
Step 1) Take any project and generate a dump.txt for all relevant code. For a WordPress plugin, we can target all PHP files by running _do dump “*.php”. The idea is to generate a file less than 3MBs. We can pass one or more exclusion arguments to lower that size if needed -x "<pattern>".
_do to compile a dump.txt of the _do project itself and excluding it’s compiled version meant for distribution.
_do to package up a WordPress plugin excluding unnecessary parts for code generation.Step 2) Drag and drop into Google Gemini: https://gemini.google.com and detail what you want to do. For development purposes, I keep it focused on one thing or one area at a time. The more modular your application architecture, the more helpful Google Gemini can be.
Step 3) Make code changes yourself. At least for now, I find it best to take generated code and adapt and modify it as I’d like. As a developer, there are lots of minor tweaks I can do which doesn’t require a conversation with Google Gemini
Step 4) Repeat. Conversations with Google Gemini can be quick, but some go deep. At some point, it’s better to start with a fresh chat window and a fresh compiled version of your application. This is especially true when you want to shift focus to a different problem or a different area of the codebase.
Use the context window to your advantage.
Knowing the limits of the context window for your model is key for getting usable output. Every model has a limit on how much data it can take in and how much data it can output. Whether or not there is an actual set limit isn’t the point. All models can only take in so much and output so much before the output is no longer useful for anything. With Google Gemini 2.5, here is a look at its limits.
| Input | Output |
|---|---|
| 1 million tokens | 64k tokens |
| ~2-3 MBs | ~244 KBs |
Knowing this, I would not feed it a 2MB codebase and ask it to refactor and output all 2MBs back to me. It’s simply asking for too much. Instead, I would happily send it 2MB and have it generate a very specific feature or modify with a request that it only outputs the new code changes. Put more in and ask for less out.
What’s next for developers?
I know some folks might be sad about these changes. I mean, if developers aren’t coding, what’s the point of it? Coding is and has always been about building stuff. Regardless if a developer is writing code or generating code, we’re still doing the same thing. We’re building things. That doesn’t change. How we get there might, but I do think we’ll look back and say “Remember when you used to code that by hand?”. Code generation will just become the norm, and we’ll keep on making awesome things.
If you’re a developer, I highly encourage you to jump in and start experimenting with new AI workflows. Developers who generate code will start to stand out from the developers who don’t. The world is changing, and so will workflows, mine included. Who knows, maybe by next year, I’ll simply be running background AI agents, building various applications. If you’d like to keep up on everything that’s possible today, I highly recommend listening to the following conversations on the Changelog podcast.
Changelog & Friends – Episode #99
Let’s build something phoenix.new
Changelog Interviews – Episode #647
When vibe coding goes viral
Changelog Interviews – Episode #647
Adventures in babysitting coding agents
