Random thoughts I’m having as it relates to AI because it’s the topic dujor anywhere you go.

A thing I’m observing in AI discourse is a divergence how engineers vs non engineers think about and use these tools. That is ok! There is no one “right way” to think about it.

Inherently, engineers are ahead of the power curve because the frontier of these tools have poor UX. If you’re not willing to touch a command line, you will be using less efficient tools. Have no fear, anything the engineers are using today will be usable in some form 3 months later for everyone with a good UX. A perfect example is Claude cowork, not a full feature parity, but close enough!

The application of these tools have different margins of error if you’re using it for linguistics vs code. It’s much easier to “slop cannon” (h/t
Zack Shapiro) if you’re in a word document vs a code editor, because code is deterministic and is less tolerant of fluff or outright wrong statements.

Engineers are familiar with code review as a concept, now non engineers need to introduce code review into documents they generate with these tools.

The dopamine hits of seeing “completed” documents on a screen is intoxicating, but you need to ride that high and comprehend and edit the output.

Recursively putting an output into more LLMs is not review, if anything it’ll compound the slop. In code, we’d call this tech debt. For the first time, non engineers are now incurring their own tech debt.

Non engineers are having a 0 to 1 moment. A year from now, it’ll be hard to find someone who *isn’t* an engineer in some form.

Previously non engineers had to plead a case to developers to make something, now non engineers who are highly motivated and have deep understanding of their needs can become junior engineers.

We are already seeing this at AnchorWatch, where Chris on our team spent 2 days and built maybe half of a software suite we could leverage internally. Chris has never written a line of code in his life, but it’s an impressive proof of concept. As is we’d never ship it, but working with our engineering team, it can get to 100% quickly.

This is a natural evolution as the roles start to blend across an org. Chris was the main person who knew the pain points of current processes, and was in a strong position to build a product requirement doc and build something that will save him weeks of work across the year.

Speaking for AnchorWatch, we are SOC-2 which requires a higher duty of care for managing data. So our existing engineering team will be in the loop (maybe that changes in a year, we will see).

Strong engineering teams are able to act as scaffolding to support non engineers write code that has high impact to the organization. Further, our engineers are now better able to have a deeper appreciation for how our marketing, operations, and compliance works outside of what lives in their GitHub repository today.

This extends to even me. These tools are giving me more time to focus on parts of our business outside of custody infrastructure.

We don’t use LLMs for our custody software. The nuances are too mission critical to outsource the execution. AI is very helpful for prototypes and battle testing product specs, I’m often finding I’ll get deeper appreciation of edge cases I had not considered when using AI for proofs of concept, but that code then goes into the garbage to be written by hand with an increased learning.

A word of caution: non engineers are less likely to understand permissions management. I can almost guarantee that if you’ve been playing around with all of these tools, it’s very likely you connected a tool to resources (like email/shared drives/local file storage), and it has way more access than you realize. This is critically important to understand for security and compliance.

In 90 days, we will see a whole turnover and the meta will change again. Having high agency and metacognition will be how you can compound an edge.

Finally, have fun shipping!