A living document tracking my personal AI usage policy

This is a living document tracking my personal AI usage policy and guide for using it safely, effectively, and ethically. It's a moving target, and I don't expect to get it 100% right. If you think I'm missing the mark somehow, shoot me an email↗ and tell me why. I'm always open to criticism and changing my perspective.

Technology is a tool for people. It may one day get to the point where it is more than that, but it is not there yet. We must always ask "what is the impact?" This is especially true with AI.

When considering whether or not to use AI for a task, start with these questions:

If the task is enjoyable, necessary, or if you would pay someone for it, then you shouldn't use AI for it. If the task is marginal, and it wouldn't get done at all otherwise, AI may be ok for it, but it depends on the required output quality. Which brings us to the next section.

You are responsible for your AI's output. Full stop.

This includes systems that are semi- or fully-automated. For instance, if you put a coding system into production that can:

All without human interaction, that is all your responsibility, and you are accountable for the consequences, first and foremost. This includes if AI "goes rogue" and does things you didn't expect.

If you were ordered to build systems this way, then the accountability transfers partially, especially in most corporate settings where workers are not given a choice. But some amount remains at each level down to the employees building the systems. Following orders and building systems that can cause material harm is not an excuse.

All engineers should strive to build tools with the mindset that someone's life may depend on it. Because people's lives do depend on our tools. We must never forget that, and we must understand the trust that people put in us when our tools become an integral part of their lives.

As a coder, I do not think there is any ethical issue with using AI to write code (outside of environmental and societal impacts, see below). Code is purely utilitarian and a means to an end. I won't mourn the day we stop writing JavaScript any more or less than the day we stopped writing assembly and started using compilers.

However, code does need to work and be reliable. This is a very high priority ethically and pragmatically. I would not use a hammer that works 99% of the time, and the same goes for code.

Currently, AI-driven development has been shown to have subpar quality, particularly over time as the risks of decoherence compound and quality drops further and further. Until we find ways to counter this, I recommend a dual development model where:

AI-driven development is allowed only in codebases that:

This ensures that the layer can be wiped clean and restarted if needed, and generally includes the application layer (on both the client and the server) plus some extremely well tested libraries or utilities.

Every codebase that does not meet these criteria is human-driven. Agents can be used to start a rough draft or think through architecture, outline plans, develop documentation, etc. But all output needs to be manually reviewed, and humans should ultimately take it from 80% complete to 100%.

Code is aggressively abstracted from category 1 into category 2. The application layer should essentially be a configuration file with very little code. It should look like HTML, and be readable by non-coders. It should be the epitome of "code-light". And it should NOT have escape hatches wherever possible.

NEVER underestimate the complexity of an API when evaluating if a codebase fulfills 1b. Be extremely cautious, because:

Even extremely well defined specs, like the JavaScript spec↗, often have bugs and observable details in their implementations.

My own standards are essentially that 1b should only ever be invoked if the API is small enough that you can test every possible input and output in a combinatorial way, which is not most APIs.

Think of it like buying Ikea vs getting hand-made cabinets. Ikea cabinets only come in standard sizes and with standard features, but anyone can put them together and it's hard to mess up too badly.

Now, designing Ikea furniture is a much more difficult problem than designing hand-made cabinets. They work extremely hard to engineer those systems and make them so durable, despite using very light and inexpensive material. The same is true about building truly flexible design systems, routing libraries, reactivity frameworks, and so on. Many of us have taken a stab at doing these things only to find our beautiful abstractions shredded when they made contact with the real world.

But, this is the benefit of Open Source software and of building coherence. Take design systems for instance. Rather than reinventing the wheel at every company, perhaps we agree on a universal design language with a constrained theming system. Something like Material UI, but better, more flexible, more extensible.

I can feel the designers and product owners cringing through their screens right now, and to be clear, I sympathize. If you couldn't tell from looking at my site, I appreciate quality design.

But in the end, more often than not, we are building tools. We build tools for teachers, for doctors, for scientists, for construction workers, and so on. People need to use our tools to do things in their lives, to participate in society. And perhaps what is more important than having a unique, stylish, one-of-a-kind UI for a tool, is having a flexible, human-oriented UI that can be easily reconfigured and moved around and changed to meet the needs of the user.

Flexible: same parts, new colors and layouts

This is more attainable than it has ever been, but we may need to let go of our apps' individuality in the process. Not entirely, we would certainly still have theming capabilities for branding purposes, options for some uniqueness in UIs, and ways to extend and build that very-special-component that nobody needs except you. But we may need to accept that maybe there are just 3-4 types of buttons, maybe there's only so many ways to do a form, and maybe having components that fit into a well defined system in general is better than getting everything to be just so.

Personally, I think this is an area where I would care much less about losing that personal touch, compared to, say, the furniture and cabinets in a home. I don't think the two are the same, really.

It's more like, do you want to get the red drill or the blue one?

And one final note here: Building systems this way will necessarily reduce token costs, because you'll be doing more with less. Less code to maintain means less code for your AI to parse and write, and less complexity for it to handle means less ways it can go wrong. Local models may be even more effective in such streamlined environments. So, it's a cost saving way of working as well as ensuring higher quality.

I don't feel like I need to expand on all of the reasons why. Do not do it.

The line between art and not-art is blurry. There are some types of illustrations that are fairly utilitarian and that would generally not be done otherwise. Examples include:

I want to immediately acknowledge that this trends very close to "everybody's use of AI is bad except mine" territory, and I'm open to debate on this topic more than others. My reasoning is that these are marginal use cases where the creators often do not have budget to hire illustrators (myself included), and likely would either make less polished illustrations or simply not make them at all.

But, this is a fraught line, so I want to also add some strict guardrails here:

The furthest I have pushed this line personally is probably with illustrations like the Maze in my Decoherence essay:

One could argue that the point of this image is ultimately artistic - it is to evoke an emotional response from the reader. This is true. I still believe that it falls within the bounds of utility, though, because the point of that emotion was to get readers to understand the depth of what the worker feels on a day-to-day basis. I wrote the words, but the words alone did not convey the immensity of that weight, the exhaustion in one's bones as they prepared to embark on the next task.

I also intentionally limited the AI to producing an SVG, with simple gradients, lines, and patterns. The illustration is one that I could have made on my own time, and likely would have with a script if I wasn't using AI. So I was otherwise following the spirit of the guardrails.

If someone is not an artist (like myself), and is not making money selling this moment as art, is simply trying to persuade or to educate, then I don't think there is something wrong with using a tool that helps. But I could be convinced otherwise. If you'd like to challenge me on this, send me an email↗ and we can discuss.

An idea I have in this space is a sort of "Legos for informative illustrations" tool. The concept is a simple, tile-based editor with basic shapes and simple layering. You wouldn't be able to make super detailed illustrations, but you could create more simplified ones that are close. Think like the way that Lego sets used to be relatively simple, and now we have things like the Notre Dame that use basic pieces really creatively.

Ideally, the editor would be open and accessible, and allow people to share their creations with others, with the primary goal of enabling quick illustration for informative and educational content that is throw-away in nature and doesn't need to be perfect. This would help make the look of these designs generic, and leave the space for designing more unique and detailed work for humans.

Also, like I mentioned in the code section above, this would make illustrations much more token efficient, and allow you to work with smaller models.

Feel free to take this idea and run with it! If not, I'll probably get to it one day. It's on the backlog!

As tempting as it might be to have the word generating machine do your writing for you, I highly recommend that you do not, for a few reasons:

Ultimately, your words will stand out more if they come from you, even if they're a little rougher at first, or you make mistakes, or things don't come out the right way. As a neurodiverse person, I've struggled a lot in my life with communication. I've been told I was blunt or abrasive at times, and I had to do a lot of self reflection and work to understand why.

But in doing that work, I've found that I'm now a more understanding and empathetic person overall, and that has made my life more rich in many dimensions, not just writing. So find your words, the way you would say them, not the way a chatbot would.

Search in general is one of the things that AI is genuinely very good at, especially in the post-enshittification-Google era. However, it should always be treated as just "better Google".

When you used Google before and found search results on a forum or a random enthusiast site, you would generally weigh a lot of factors before deciding whether or not to trust the information:

The context in which you are using AI matters, just like using Google. If it is low effort, low risk, low impact, then it's probably fine to just accept the answer and move on. Otherwise, be sure to verify your sources and double check.

In general, AI can be a great tool for finding things that you didn't know about, but you have to treat it like your very smart friend who knows a little about a lot of things, and also goes with the flow a bit too much. It's happy to please you, it can give you a surface level answer about almost anything, and if you dig in it might even be able to go quite deep on a subject and stay accurate.

But sometimes it'll just be dead wrong, confident