Imagine that every time you went to make breakfast, you made everything from scratch. To make just eggs and toast, you would need to raise your own chickens, buy the materials for an enclosure, build the enclosure, raise the animals, and then you would get eggs. To make toast you would need to grow wheat, harvest it, turn it into flour, build a toaster from scratch, and then finally you would have toast. Not only would this be an insane amount of work to build things which already exist, but how do you know the toaster you built won't burn your house down, or that the eggs your chicken laid are safe to eat? I do not have the expertise to build breakfast from scratch, and I don't have the patience to build a bunch of things when a better version already exists. It would be ridiculous to do this for breakfast, so why do we take this approach when building with Artificial Intelligence (AI)?
With AI becoming more powerful, non-technical and non-expert individuals like me have suddenly become able to build projects with no experience or expertise. I went to a liberal arts college, got a degree in philosophy. I took maybe four STEM classes in undergrad, and now I could build you a website or app in a day. I built my own knowledge base for work from scratch, a real system with account context, call prep, and my own frameworks written down, and it runs my working week. I am one of many who have learned that with AI, I can build things far beyond my current expertise.
While this advancement is amazing, I have realized that many are using this technology too often to reinvent the wheel. They are creating worse versions of things that already exist, and not knowing a field is costing them twice. They do not know what it actually takes to build the thing well, and they do not know what already exists that they could have bought instead. Those are not two problems, they are the same gap showing up in two places, and closing both halves is exactly what you pay an expert for. Not knowing how to code used to be an accidental safeguard. It stopped you from building the bad thing at all. AI removed the barrier to building. It left the barrier to knowing what building actually takes.
I hear stories all the time from people building the same way I build, who believe too optimistically in the power of AI. They decide to build their entire accounting, legal, marketing, and sales stack internally, vibe coding these systems into existence. This saves them plenty of money in the short term and can be looked at as a proof point for the beauty of democratized coding, yet the issue still remains that these people don't actually know what they are coding. They don't have the ability to review the code, or the comprehensive knowledge of systems to know if their architecture is actually what they want it to be. As a consequence, the back-end is a mess, their systems have bugs everywhere, and security features are virtually non-existent. The team then ends up spending more time, money, tokens, and compute maintaining and fixing their DIY systems.
Some may argue against me, saying that existing software is often too bloated, overpriced, or doesn't yet do the thing that we might want it to do. That is fair and it is sometimes true. I think that in these situations, building on your own is only advisable when you can verify the output yourself and when mistakes are cheap to catch. It comes down to whether your mistakes show themselves or stay hidden. My knowledge base is the visible kind. If it formats a brief badly or files a note in the wrong place, I see it the same day and it costs me ten minutes. Payroll is the hidden kind. If it gets withholding wrong, nothing looks broken, the error compounds quietly for a year, and the person who eventually catches it does so on behalf of the IRS. It is not worth building where mistakes don't show themselves and could lead to compromised security.
So what now? Do we stop building?
Recently I came across a skill called ponytail. You install it as a plugin, and from then on, before Claude writes anything, it runs down a ladder of questions. Does this need to exist at all? Is it already in the codebase? Does the standard library do it? Is there a native platform feature? Is it already an installed dependency? Can it be one line? Only after all of that does it write something new, and then only the minimum.
It is worth installing. But notice where the ladder stops. The highest rung is an installed dependency. Ponytail is very good at stopping you from rewriting something you already have within arm's reach, and it has no opinion whatsoever on whether you should be building this system at all instead of buying it or hiring someone who already knows how. That judgment is not a code problem, and no tool is going to make it for you.
Which means we have to make it ourselves. Before we even open a Claude Code session, the question is not can I build this. The answer is almost always yes now, and that is exactly what makes it a bad question. The real question is whether this is a thing I should be building. We should not be building our own accounting stack when there is good legal reason to outsource to a real accountant who understands tax structure, rather than hand it to an intern armed with a $200 Claude Max subscription. What you are paying that accountant for is both halves at once. They know the tax code, and they know which tools out there already solve your problem.
So here is the thing to actually do differently. Before the next thing you build, spend twenty minutes finding out whether it already exists and what it costs, or meet with a company's rep to understand what's out there and how it works. If it exists and it is cheap, buy it. If it exists and it is genuinely wrong for you, now you know why, and you will build a better version than you would have going in blind. And if you cannot tell whether the thing you built is any good, that is not a reason to ship it. That is the signal to go find somebody who can tell.
You can build almost anything now. Some things you make, some things you buy, and some things you hand to a person who actually knows what they are doing. Knowing which is which is the whole skill, and it is the one AI did not hand you.