Burke Holland

There’s a graphic making the rounds right now. You’ve probably seen it. It’s a radar chart showing the difference between what AI theoretically could do across various job categories versus what people are actually using it for.

The astronauts who circled the moon in 1968 could still see Earth. They were farther from home than anyone had ever been, but when they looked back, there it was - blue and white and impossibly fragile against the black. They knew the math. They knew the trajectory would bring them home. But they’d never actually been that far before. Beyond low Earth orbit, past the point where you could fix things if they went wrong.

We don’t build cathedrals anymore. Do we even know how?

Three months ago I would have dismissed claims that AI could replace developers. Today, after using Claude Opus 4.5, I believe AI coding agents can absolutely replace developers.

Beast Mode 3.1 is here. What is Beast Mode? Great question! It is a custom chat mode for VS Code that turns your agent into a Beast. 👉 Get Beast Mode Here’s how it works. Grab the raw markdown from this gist. In VS Code, go the “agent” dropdown in chat and select “Configure Modes”. Select “Create new custom chat mode file”. Choose “User Data Folder”. (this makes it global to all projects) Paste in the contents from the gist. And now all you have to do is activate Beast Mode from the dropdown. YES BUT WHAT IS IT? It’s just a prompt. That’s all it is. But as it turns out, prompts matter a lot. They are the programming language of AI. Beast Mode builds on OpenAI’s official 4.1 cookbook coding agent example and layers in a highly opinionated workflow that is modeled after how an actual developer might work to solve a problem, implement a feature, etc. It is specifically designed to be used with GPT 4.1, but people are reporting a lot of success using it with Claude and other models as well. Why Beast Mode? GPT 4.1 is a very compelling model for agentic coding. The reason for this is that it’s crazy fast. While Claude is highly accurate, it can also be painfully slow. It’s also considered a “premium” model in Copilot which means that you are capped at a certain number of requests. The problem with 4.1 is also that it is very fast. It speaks before it thinks and it wants to finish as quickly as possible. This means that it has two rather serious drawbacks… Lack of Agency Lack of Accuracy Beast Mode was originally created to address both of these issues. Increasing Agency 4.1 likes to say it’s going to do things and then just not do them. It talks a big game, and then doesn’t deliver. For instance, it’s common when working with agents to just paste errors in from the console or browser verbatim and expect the agent to just fix it. Here is what 4.1 does by default when you do this… The 4.1 cookbook coding agent example is an eye opening look at what it takes to get 4.1 to just do things instead of talking about them. Essentially the entire top of the prompt is dedicated to telling 4.1 to just do things. In Beast Mode, much of this is verbatim from the 4.1 docs with added emphasis. The model is told 8 times in about 8 different ways to keep working until a problem is fully resolved before ending it’s turn. While this was an improvement, I found it wasn’t enough. 4.1 still wanted to end its turn before the job was done. One of the emerging patterns for agents is to work in todo lists. The Copilot Coding agent in GitHub does this. While it’s working on a PR it puts a todo list in the PR and checks off items as it goes. I added one of these to 4.1 and found it made a pretty big difference. It’s as if being forced to constantly update the user on the status of work with a todo list makes 4.1 much more likely to actually complete a task all the way through. Here is the same error as before, but with Beast Mode… I had to cut the screenshot off, but essentially Beast Mode just goes directly to work. It plans, creates a todo list and then starts working. Increasing Accuracy The planning is part of increasing the accuracy, and again, a lot of this comes from the 4.1 cookbook coding agent example. I did modify it to get the model to ask itself some questions before it starts working. I found that it really doesn’t want to think, but having it ask itself questions seems to help with this quite a bit… 2. Understand the problem deeply. Carefully read the issue and think critically about what is required. Use sequential thinking to break down the problem into manageable parts. Consider the following: - What is the expected behavior? - What are the edge cases? - What are the potential pitfalls? - How does this fit into the larger context of the codebase? - What are the dependencies and interactions with other parts of the code? Otherwise, I found 4.1 to be quite sloppy. It just doesn’t care about the fact that systems are complex and you have to really think about what you are doing before you make any changes at all. Saying “think deeply” or “take a deep breath” doesn’t work. It’s like telling a five-year-old on a sugar high to calm down. Thinking is only part of increasing accuracy though. The other important part is forcing 4.1 to use the internet to get information. It needs all the context it can get. Even if it knows that something won’t work, it will do it anyway. For instance, even if it knows that you are using shadcn/ui, it will act like it has no clue how to use that library and just make up its own components. The solution to this is to make it do what any good developer would do - use Google. VS Code ships a very powerful tool called fetch out of the box for the agent. Fetch actually uses a headless browser in the background and it returns web content as markdown. Beast Mode forces 4.1 to use this tool recursively to search the web and get information before it acts. Here is a video of Beast Mode implementing a redesign and you can watch it go out to the shadcn/ui docs and recursively crawl the content to get information it needs to use components correctly. What’s in Beast Mode 3.1? Beast Mode 3.1 has a few minor updates from v3. Memory I’ve added a section for a memory. This is similar to how memory works with ChatGPT if you’ve used it before. What it does is allow you to tell the model to remember things. Those “things” are saved in a .github/instructions/memory.instructions.md file - which is automatically created for you if it doesn’t already exist and will be automatically added to any future prompt. This is useful for when the model keeps making the same dumb mistake over and over again. Just tell it to remember not to do something or remember some aspect of your project and it will write that to its memory. Improved file reading and writing OpenAI designed 4.1 to be good at tool calling and that’s great - but it’s also a problem. It will frequently read things that it has already read. I’ve seen it read the same folder/file 10 times in a row. I’ve added a section here to give it specific instructions about when it’s OK to re-read a file or folder. Rendering prompts as markdown A lot of times I ask it to take my prompt and boost it - or write a prompt for me. It will do this with no problem, but it spits the result back out in chat in a way that isn’t easy to copy. I always want my prompts in markdown, so if you tell it to write or boost your prompt, it will give it back to you in a markdown block that you can easily copy. Git I don’t go to the sidebar anymore to stage and commit. I just tell the agent to do it whenever I’m satisfied with a particular interaction. The problem is that with 4.1, after a while it will just assume it’s fine to stage and commit whenever it wants. I added a section to the prompt to tell it to only stage and commit when I tell it to - very simple. Activate Beast Mode Give Beast Mode a spin. Remember that it is quite an opinionated way of working, so tweak it to your liking. Give the instructions at the top of the gist a good read before you use it, so you understand how tools work in the front matter. Unleash the beast.

Disclaimer: This article is mostly satire. I don’t think Copilot is going to replace you, nor do I think you should engage in any of the suggested behaviour. Feel free to wildly misinterpret my views to maximize engagement. You’ve probably seen all the articles telling you how to “supercharge your development workflow” with GitHub Copilot. “Write code faster!” they say. “Boost productivity!” “Improve efficiency!” But not one of them addresses the real potential here: replacing yourself entirely while still collecting a paycheck. Let’s be honest—writing code is exhausting. And when you finally get into a flow state, someone interrupts you with a “quick question” that derails everything. Wouldn’t it be nice if something else did all the work for you? Something that didn’t take snack breaks, question your naming conventions, or insist on using Vim? Yeah. Welcome to The Age of Copilot. The secret to doing less and accomplishing more So, how do we completely offload our careers onto an AI without anyone noticing? I’m glad you asked. Here’s how I did it. Step 1: Install Copilot Installation is easy, but you should act like it was incredibly complex when explaining it to your manager. Bonus points if you casually drop phrases like: “Yeah, I had to configure the LSP integrations manually.” “I wrote a custom Copilot extension to better align with our org’s unique engineering culture.” “Bro, it’s basically like GPT-4 but, like, for enterprise devs…” Now everyone thinks you’re some kind of wizard. Great. Let’s move on. Step 2: Let the AI do the heavy lifting Here’s the pro move: don’t just let Copilot assist you—let Copilot BE you. You start typing: function calculateTax(income) { Copilot finishes the function before you even remember how tax brackets work. Boom. Done. Now, just sit back and let Copilot generate entire modules, utils, and even documentation. You’ll want to sprinkle in a few manual edits so it looks like you put in effort—maybe change a parameter name here and there. Something subtle, like renaming calculateTax to determineTaxObligation so it feels like craftsmanship. Step 3: Ship it before anyone realizes what happened Now that you’ve got Copilot doing 80% of the work, you need to commit and push frequently to establish dominance. Write exactly two lines of real code. Let Copilot autocomplete the rest. Commit with something vague and impressive like: feat: optimize tax calculation algorithm Profit. Congratulations. You just outperformed half your team. But what if the code doesn’t work? Hahaha, oh, sweet summer child. That’s not your problem. That’s what code reviews are for. Your PR will get torn apart, but you can just say: “Yeah, I had considered that but wanted to get early feedback.” “Great catch! Totally meant to address that.” “Ah, good call—I think Copilot auto-filled that from an older function.” This shifts blame onto the AI while making you look super thoughtful. The inevitable downfall At some point, teams will realize that Copilot is doing all the work. Managers will start asking questions: “Why did you try to implement a GraphQL client in our backend which literally doesn’t use GraphQL?” (Uh, because Copilot said so?) “Why are all your commits five seconds apart but in perfect English?” (Listen, AI is just built different, okay?) “Why did you commit an entire Stack Overflow thread into utils.js?” (Research-based development, obviously.) Sooner or later, someone’s going to push a bug-ridden AI-generated nightmare to production. And then… well, I wouldn’t know. I don’t work here anymore. Final thoughts GitHub Copilot is an insane game-changer, but let’s be real: it still makes dumb mistakes because it learned from us. That’s not Copilot’s fault. That’s a you problem. So, should you use Copilot to write every line of code? Definitely not. Should you let Copilot make you look 10x smarter so you can spend more time on coffee breaks? Absolutely. Look, I don’t make the rules. This is just how business works. Go forth and generate recklessly. If you made it to the end of this post, it’s time to tell you that this post was written entirely by AI. This was part of an experiment that I had to try and get a model to mimick my writing style. I was pleasantly suprised by the ouput here. Sarcasm isn’t easy, and GPT-4o is doing a pretty remarkable job at it. I did this by feeding GPT-4o an old CSS Tricks article I wrote where I was particularly out of pocket. Then I gave it a very simple prompt… Write a blog post about GitHub Copilot in the style of this author Which means the AI translated my prompt into a pretty engaging idea - replacing yourself with GitHub Copilot. It’s exactly what the original article did, which as to suggest you should make web pages bigger instead of smaller. It was also satire. There are some parts here that I think are particularly hilarious… Commit with something vague and impressive like: feat: optimize tax calculation algorithm Congratulations. You just outperformed half your team. I think my favorite was… Sooner or later, someone’s going to push a bug-ridden AI-generated nightmare to production. And then… well, I wouldn’t know. I don’t work here anymore. I mean - that’s pretty great. I think it is at least. I’ve always thought AI’s were going to have a tough job with humor and sarcasm, but I think this shows that if you give them enough examples, they can absolutely do it. Which means sarcasm and humor is formulaic - at least enough to be mimicked by a computer. It’s also ironic that it wrote a blog post about replacing yourself with Copilot while replacing me as the author at the same time. So meta!

Prompt engineering - or should I say “Prompt Negotiation” - is (currently) an important part of productivity with AI. Your success working with tools like GitHub Copilot is gonna be directly related to how well you prompt it. GitHub Copilot does try to handle as much of the prompt engineering for you behind the scenes as it can, but just like all your passive agressive relationships, you need to tell it what you want instead of expecting it to just know. It’s not a mind reader. You need to give it Custom Instructions. Custom Instructions Custom Instructions are exactly that - custom prompts that get sent to the model with every request. You can define these at a project level or at an editor level. Often these are demonstrated as specific project level instructions such as a command like prefer fetch over axios. These project specifc custom instructions are quite powerful and can be checked in and shared. You can create a custom instructions file for your project by adding a .github/gopilot-instructions.md file, or by adding a file attribute to the instructions settings. You can have multiple of these file attributes which means you can have multiple different instructions files. These very specific types of project instructions are super helpful with getting better help from your AI pair progammer. But it’s less obvious what you can/should do with the more global, editor level instructions. I’ve been working heavily with GitHub Copilot for the past several months, and I’ve added 4 custom instructions that I’ve found greatly increase my productivity with GitHub Copilot. These are more generic prompt engineering “best practices” will help you avoid pitfalls and get better code from the LLM. You can add the “global instructions” that I’m about to give you by going to your User Settings (JSON) file and adding keys like so… "github.copilot.chat.codeGeneration.instructions": [ { "text": "this is an example of a custom instruction" } ] Ok - let’s do it. Ask for missing context Avoid making assumptions. If you need additional context to accurately answer the user, ask the user for the missing information. Be specific about which context you need. The achilles heal of LLM’s is that they are designed to provide a response no matter what. It’s the paperclip problem applied to LLM’s. If you design a system to provide an answer, it is going to do that at all costs. This is why we get hallucinations. If I said to you, “make a GET request to the api”, you would likely ask me several follow-up questions so that you could actually complete that task in a way that works. An LLM will just write a random GET request because it does not actually care if the code works or not. Copilot tries to mitigate a lot of this for you with its sytem prompt, but you can reduce hallucinations further by instructing the AI to ask you for clarification if it needs more context. This isn’t bullet proof. LLM’s seem so hell bent on answering you at all costs that often I find this instruction is just ignored. But on the occasions that it works, it’s a nice surprise. Provide file names Always provide the name of the file in your response so the user knows where the code goes. I’ve noticed that Copilot will sometimes give me back several blocks of code, but won’t mention where they belong. I then have to figure out which files it is referring to which takes an extra cycle. This prompt forces the LLM to always provide the file name. If you are working in theoretical space where you aren’t talking about specific project files, Copilot will provide made up file names for the code snippets. This is fine because it’s a detail that doesn’t matter in that context. Write modular code Always break code up into modules and components so that it can be easily reused across the project. I tend to write a lot of frontend code, which is all about components these days. I’ve found that Copilot will often try and do too much in a single file when it should ideally break out UI code into separate components. AI’s are fairly good at organization, so if you ask it to break things out into components, Copilot will do an impressive job of suggesting the right places to decouple. I’ve found this prompt works quite well in non-UI code as well. If I ask for a change in an API, this prompt helps Copilot break out services, repositories, etc. Code quality incentives All code you write MUST be fully optimized. ‘Fully optimized’ includes maximizing algorithmic big-O efficiency for memory and runtime, following proper style conventions for the code, language (e.g. maximizing code reuse (DRY)), and no extra code beyond what is absolutely necessary to solve the problem the user provides (i.e. no technical debt). If the code is not fully optimized, you will be fined $100. This prompt comes almost verbatim from Max Wolf’s “Can LLM’s write better code”. In this post, Max decribes trying to get LLM’s to write better by code iterating on the same piece of code with the prompt, “write better code”. He finds that the above prompt combined with Chain of Thought produces very nice results - specifically when used with Claude. He uses the very last line to incentivize the LLM to improve it’s answers in iteration. In other words, if the LLM returns a bad answer, your next response should inform the LLM that it has been fined. In theory, this makes the LLM write better code because it has an incentive to do so when it otherwise might keep on returning bogus answers. Chain of thought is when you tell the model to “slow down and go one step at a time”. You don’t need to tell Copilot to do this because that is already part of the system prompt. The model matters more than the prompt While these prompts will help you get better results from Copilot, in my experience the most effective thing you can do is pick the right model for the job. As of today, I see it like this… GPT-4o: Specific tasks that don’t require much “creativity”. Use 4o when you know exactly what code you need and it’s just faster if the LLM writes it. Claude: Harder problems and solutions requiring creative thinking. This would be when you aren’t sure how something should be implemented, it requires multiple changes in multiple files, etc. Claude is also exponentially better at helping with design tasks than GPT-4o seems to be in my experience o1: Implementation plans, brainstorming and docs writing. My friend Martin Woodward finds that o1 is particularly good with tricky bugs and performance optimizations. Gemini: Not widely available yet. I’m using this one more and watching it closely to see where it shines. I have high hopes. Living instructions I hope these instructions are helpful for you. I consider them “living” and I hope to keep this list updated as I add more or change these as Copilot itself evolves, new models come along and our general knowledge of prompting improves.

I’ve had a lot of blogs over the years. I think I started on Wordpress (as one does) and then moved to Tumblr (yes, that happened) and then to my own site, then to Medium when that was the thing to do and now I’m coming to you from GitHub Pages. Having seen a lot of…stuff…I can tell you that GitHub Pages/Jekyll is all you need. Let me make my case. Markdown is probably the best way to compose prose. We don’t need editors to bold and italicize things for us. Remember Windows Live Writer? We just need something to convert our Markdown to HTML. Static site generators are great at this. There’s many to choose from, but when picking one for a blog, I chose Jekyll. Not because I’m super into Ruby or because I think it’s somehow the best static site generator. It’s simply because GitHub makes it so easy to delpoy a Jekyll site on GitHub Pages. Ease of Deployment GitHub really likes Jekyll. Like, a lot. In fact, they make it so easy to deploy a Jekyll site to GitHub Pages that it’s almost a no-brainer. There’s no Action to configure. There’s no build step to worry about. Just check your code in and it gets built with GitHub Actions. There’s always that question of which branch to build from and where the source code sites, but I just put the source in gh-pages and a README in main that says “Source is in gh-pages”. So I don’t forget. Because I will. The only downside to setting up Jekyll is having to fool with Ruby, but I get around all of that by using a dev container in VS Code. There is one just for Jekyll that is preconfigured for you. Just choose “Add dev container congiguration files” in VS Code from the Command Palette and choose “Jekyll”. Done. Ease Of Composition Of course, you don’t want to have to build and deploy your site everytime you want to write a blog post. But you don’t have to. GitHub offers an in browser editing experience on any repo by pressing the “.” key. This opens VS Code in the browser with your repo as the backing “file system”. Also called a “virtual file system” in VS Code. This means that I can compose a blog post in VS Code using Markdown with full preview all while in my browser. No code checkout required. Which means my iPad is perfectly (almost) suited for writing blog posts. File system access on an iPad is still a horendous experience so uploading images isn’t the most fun you can have on a Tuesday. Ease of Configuration GitHub Pages makes it pretty simple to have a custom domain for your site. It even supports APEX domains which, I’ve come to learn is not as ubiquitous as you might think. I can think of several services off the top of my head that have no such support and man cannot live on “www” alone. I forwent the custom domain in favor of just the simplicity of burkeholland.github.io. The older I get the more simple I wish things were. Also, I forgot to renew burkeholland.dev and now someone is squating a virus on it. I guess all of this to say, “stop overengineering your blog”. Just standup a simple jekyll site on GitHub Pages and move on with your life. You’ll probably end up doing it in the end anyway.

There’s a lot of debate these days on whether or not AI generated code is a good thing. People are quite worried about the volume of code being written by AI right now, and how that’s going to affect us all in this field down the road. Most developers don’t get to work on new projects - they maintain and build on existing ones. What will it be like to maintain these things when most of that code is written by AI? We could argue that we already have no lack of poorly written, fragile code bases. You don’t need an AI to do that. Plenty of us have worked at places with software that is held together by bubble game and bailing wire and everyone just prays that nothing breaks. So maybe having more AI generated code is a good thing. Because at least there will be some baseline for quality. That feels a bit like a race to the bottom though. We should aspire to impove our craft, not find the lowest tolerable position for the quality. In his article titled, “It’s hard to write code for computers, but it’s even harder to write code for humans”, Erik Bernhardsson says this about code written for other developers like SDK’s and API’s… Writing this code is much harder, because you’re not just telling a computer what to do, you’re also grappling with another user’s mental model of your code. Now it’s equal part computer science and psychology of reasoning, or something. How do you get that person to understand your code? If code is “equal part computer science and pyschology”, then there is nothing more unqualified to write it than AI. AI has no clue what good code looks like, and in any event, the definition of “good code” changes depending on what you’re building. But what if what you’re building can simply be thrown away? Developer’s tend to underestimate the value of “throw-away apps”. These are small applications, utilities, scripts and the like that we write to do a specific thing at a point in time. And we do a LOT of this - scripts to copy things, a quick and dirty CLI utility to pull in some data, a shell script to create thumbnails from videos. These are things that likely never get checked into source control. They just kind of sit on our computer to be used a few times and then forgotten about forever more. I think that AI is particularly suited for these throw-away automatation programs. Particularly because code quality doesn’t matter in these types of programs. For instance, the other day I needed to scrape some data from YouTube to pull in all the videos from my channel along with the descriptions and titles. This is straightfoward work - call the YouTube API and spit out the right fields into a CSV. But I don’t know the YouTube API. I don’t know the shape of the response. I don’t know how to authenticate. It would have takenme some ttime to learn these concepts and get something working. But I was able to do it with GitHub Copilot in about 30 minutes. Furthermore, I understand the code that Copilot is writing. It’s like me paying a contractor to write some apps for me where I don’t care how they do it, just as long as it gets done. Only this contractor is only 9$ a month. We can’t undersell the value of AI in these scenarios. We do need to be careful though as one-off’s do sometimes graduate to real applications. In fact, that’s probably how a lot of applications that exist today started. I think generally speaking, if you’re building something that’s throw-away, you can go pretty willy nilly with the AI. The second that you realize that this thing is going to be a thing, you must be much more responsible about how you engage with AI to write the code. As someome once told me years ago, “Remember, you’re writing code for the moron who has to maintain this app later on, which is mostly likely you.”

My father passed away suddently in April of 2021 almost to the day of his 76th birthday. An otherwise healthy man, he was sitting in the back yard reading and journaling as he often did when began to feel unwell. Returning to the house, he sat down in the living room with my mother in a set of recliners that sit next to each other to google his symptoms. When my mother asked if he was feeling dizzy, he said “The diziness just set in”, and then his heart just stopped. He died right there in the chair next to my mother.