

An experienced developer's view of AI assisted software development, intellectual property and the decision to build, buy or integrate
A colleague recently sent me a video about ArtCraft, a set of open-source creative applications presented as alternatives to several Adobe products. The project caught my attention for an obvious reason. Its developers say the applications were written from scratch in Rust with substantial help from AI.
That is an ambitious undertaking. ArtCraft currently lists seven creative applications for image editing, vector illustration, video, photography, PDF work, motion graphics and page layout. Its website also labels some of those applications as early alpha or in development. A recent hands-on review praised the familiar concepts while reporting missing features, performance problems and bugs.
I found the story impressive. I also found the public reaction too eager to collapse several different questions into one. Can AI help create a recognizable alternative to mature commercial software? Clearly, yes. Is that alternative ready to replace a proven production tool? That requires evidence. Is it lawful to build competing software? Often, but the answer depends on how it was built, what it contains and which intellectual-property rights apply.
My own question was more practical. Even if I can build something, should I?
I enjoy vibe coding. I am also a senior systems analyst, software developer and digital marketer. AI did not give me those roles. It gave me a faster way to explore solutions, work across unfamiliar technologies and move from an idea to a testable implementation.
That history shapes how I use the tools. I still begin with the business problem. I still care about requirements, architecture, data, security, testing, maintenance and ownership. AI may generate a large share of the implementation, but somebody remains responsible for the result.
Vibe coding is a development approach. It is not a business strategy, an ethics policy or a quality standard. The same approach can produce a useful internal tool, a legitimate competitor, a fragile demonstration or an intellectual-property problem. The prompt does not make that choice for us.
I have no interest in rebuilding a commercial application simply to prove that I can. Mature software represents years of engineering, support, compatibility work, documentation and accumulated knowledge about edge cases. A familiar screen is only the visible layer.
If an existing product solves a client's problem reliably and economically, buying it can be the most responsible recommendation. I do not consider that a failure of creativity. The client is paying for a working outcome, not for my opportunity to write more code.
Custom development becomes valuable when the available products force the business to work around the software, when critical systems need to exchange information that they cannot currently share, or when a small internal workflow is too specific to attract a commercial vendor. AI has made those narrower projects more affordable. It has not made every wheel worth reinventing.
Before I open a coding assistant, I want four options on the table.
Use a proven commercial product when it already meets the important requirements at a sensible total cost. Include implementation, training, migration, support and exit terms in that cost, not only the advertised subscription.
See what a vibe coded site really costs in our Lluv & Ink case study.
Connect the systems the business already trusts when the real problem is data movement or workflow. An API, automation platform or small custom connector may solve the gap without replacing either product.
Create a custom solution when the workflow is genuinely distinctive, the benefit justifies ongoing ownership, and the business can support testing, security, documentation and maintenance.
Some irritations cost less than the solution. A good analyst is willing to recommend no project when the expected benefit does not justify the risk and lifetime cost.
This is where my systems-analysis background matters most. Faster code generation gives us more options. It does not remove the need to compare them.
Many of the solutions I develop are proprietary tools used inside a client's operation. They are not products intended for commercial resale. That narrower audience can reduce requirements such as public onboarding, broad device support, marketplace positioning and support for thousands of unknown configurations.
Internal use does not erase responsibility. The tool may still process customer data. It still needs appropriate access controls, backups, testing and documentation. Licenses still apply. Patent law can reach unauthorized use, not only sales. A confidential source or copied asset does not become acceptable because the software stays behind the company's firewall.
The distinction matters because it changes scope and exposure, not because it creates a legal or engineering exemption.
The Caveman Marketing Quiz
How much of your marketing is still hunting by hand?
Rate 15 statements and see which of five stages your marketing is in, from The Hunter to The AI-Augmented Entrepreneur.
The broad function of editing a photograph, drawing a vector shape or arranging video on a timeline is not automatically owned by the company that made the best-known product. At the same time, original code does not guarantee unrestricted freedom to reproduce every behavior.
| Protection | What it generally protects | What AI assisted development does not erase |
|---|---|---|
| Copyright | Original code, documentation, visual assets and other protected expression | Copying protected expression can still infringe even when AI performs or assists with the copying |
| Trade secret | Valuable information kept secret through reasonable measures | AI does not make stolen, leaked or improperly disclosed confidential information lawful to use |
| Patent | The invention defined by valid patent claims | Independent creation is generally not a defense to direct infringement if the product or use practices the claim |
| Trademark | Names, logos and other source identifiers | Branding or presentation that creates likely source confusion can still create risk |
Copyright protects original software expression, including copyrightable code and assets. The U.S. Copyright Office also states that copyright does not protect ideas, program logic, algorithms, systems, methods, concepts or layouts. That distinction leaves room for independently developed competition, but it does not excuse copied code, documentation, graphics or other protected expression.
Trade-secret law asks how confidential information was acquired or used. The federal definition of improper means includes theft, misrepresentation and breaches of duties to maintain secrecy. It expressly excludes reverse engineering, independent derivation and other lawful means of acquisition. Contracts, license terms, access controls and state law can add important facts, so a developer should not treat the word reverse engineering as a universal permission slip.
Patents work differently. A valid patent claim can cover a particular technical invention or method. Direct infringement under U.S. law includes unauthorized making, using, offering to sell, selling or importing the patented invention. The Supreme Court has explained that knowledge and intent are irrelevant to direct infringement. In practical terms, independently generated code can still create patent risk if the resulting product or its use practices every required element of a valid claim.
Trademarks protect source identification. A competitor should avoid names, logos and presentation that are likely to confuse customers about who produced, sponsored or approved the product. Familiar functionality and confusing branding are different issues.
ArtCraft describes its work as a clean-room reimplementation. That is the project's stated development method, not an independent legal conclusion. A sound clean-room process can help show independent development, but the label cannot resolve patent claims, trademark confusion, license restrictions or disputed facts by itself.
This article provides general educational information, not legal advice. A commercial launch or a high-risk internal deployment may warrant review by qualified intellectual-property counsel.
AI is excellent at helping a developer reach the first visible result. That success can be misleading because the demonstration is the part everyone sees. Production readiness lives in the less glamorous work that follows.
A professional application also carries years of compatibility work, customer support and operational learning. A small custom tool may not need all of that. It does need the parts that match its real risk. The correct standard comes from the consequences of failure, not from whether the source code was written by a person, an AI model or both.
I want AI-assisted development to expand what a small business can afford to solve. I do not want speed to become an excuse for copying, weak analysis or handing a client a system nobody can maintain.
My standard is straightforward. Understand the workflow before choosing the tool. Check whether a proven product already solves it. Integrate when the missing piece is a connection. Build when custom work creates a clear advantage. Verify the output as carefully as the risk requires. Keep the client's accounts, repositories, data and documentation under the client's control.
The ArtCraft story shows how quickly the visible boundary of software development is moving. It does not prove that mature applications have become easy to replace, and it does not make the rules of ownership disappear.
It does give experienced problem solvers a larger toolbox. I am happy to wear the vibe-coding hat. I just keep my systems-analyst hat within reach.
If a workflow is wasting time, trapping information or forcing your team into expensive workarounds, start with the process rather than the software. Released Solutions can help map the requirement and decide whether the sensible answer is to buy, integrate, build or leave it alone.
Last fact-check October 2026
Build the solution the business needs. Respect the work that already exists. Verify everything that matters.
Kenneth Durrum, Released Solutions
