My Mother Was Vibe-Coding Before Vibe Coding Existed

Before “vibe coding” had a name, my mother built software for nonprofits from library research, punch cards, and pure determination.

She eventually had more than 100 clients. Then they all started asking for changes.

When I was 11, I went with my mom to the Philadelphia Public Library. We emerged with 3 enormous bound books in her hands, the lists of all the foundations locally and nationally, foundation addresses and which programs each foundation supported. My mom said she was going to build software for non-profits, develop annual giving programs for them and funnels for funding.

———————————————————————————————————

This was on a Saturday. During the week, my mom worked at a software company where she typed in punch cards. Her attitude: these software coders aren’t that much smarter than me.

I viewed her the same way you humor anyone with a preposterous idea you already know will fail but don’t have the authority or heart to tell them - you just have to let them fail on their own. It’s your mother, and you don’t get to choose your family. Plus my mother was not someone you could easily tell anything, especially no.

Her company name: Data Development Services, Inc.

A couple of years later, my mother had over 100 clients. She had developed desktop software in a world of Fortran mainframes: it maintained email distribution lists, lists of the foundations, the dates various proposals were sent, contact details, due dates, the references to the underlying foundation requests, tracked the incoming funds, tracked the use of the funds against that budgeted amount, and tracked the non-profits’ programs and some details about the services provided.

A year after that, she wrote a fork.

———————————————————————————————————-

A few years after that, she stopped developing and distributing her software altogether, to focus on writing the grants.

Why? She said the clients kept asking for changes. 😂😂😂😂

————————————————————————————————————

Years later, after I finished my Bachelor's in Economics and landed a job in a logistics company in Philadelphia, I gravitated to software myself, and learned what we and every software company knows: the software is the equivalent of the printer, the professional services and customizations are the equivalent of the printer ink. One you practically give away, the other is where the real lucrative value is derived from: if every piece of software were suitable to solve all businesses’ needs out of the box, there is no business model nor competitive advantage. Many functional areas are similar, the differences are in their support for business functions in which they compete with other market players. It is the engine for customizations that then lock software customers into certain software, true enmeshment, and into services and support for those customizations that support upgrade paths and future enhancements.

Thus, my mother had abandoned parts of her business at the very moment it likely could have justified scaling up.

Those who have vibe-coded something would do well to learn about what happens after you ship your initial software. Vibe coding something sitting on a server, with some static pages or implementations and some UX forms or dashboards, connecting to a distributed server to fetch, store, process, and present feels miles ahead of desktop databases processing database files, modest form interfaces, and processing and tracking email campaigns, but the lessons my mother learned may serve some well today.

———————————————————————————————————

Lessons for Today’s Vibe Coders

1. Distribution and Migration

When you change the software, how will you distribute the new version? Will customers receive updates automatically, or will each installation need to be upgraded?

Will existing data need to be migrated to support new functionality or changed data structures? How will you test the migration, and what happens if it fails?

2. Integration

How will the software integrate with the other systems, services, and workflows used by your customers?

A useful application rarely exists in isolation. It may need to exchange data with accounting systems, identity providers, payment services, email platforms, CRMs, reporting tools, or internal databases. Each integration creates another dependency to design, test, monitor, and maintain.

3. Software Development Lifecycle and Change Management

How will you manage change within your own development process?

For example:

• How will you separate development, testing, staging, and production?

• How will you manage multiple versions?

• How will you handle features that are in development while the current version remains live?

• How will you roll back a release that causes problems?

• How will you know which version a customer is running?

The first version may be simple. Maintaining several versions in different states is where complexity begins.

4. Support and Enhancement Requests

Who will respond when customers have questions, report bugs, request enhancements, or need help understanding the software?

Support becomes part of the product. You need a way to:

• Capture requests

• Reproduce problems

• Prioritize enhancements

• Communicate status

• Distinguish bugs from feature requests

• Decide what belongs in the core product and what becomes customization

My mother discovered this part firsthand: once people depend on software, every “small change” becomes a product decision.

5. Tool, Vendor, and Version Dependencies

What parts of your application depend on a specific tool, vendor, software version, model, API, or AI capability?

Consider both development-time and runtime dependencies:

• What happens when a vendor changes an API?

• What happens when a software version is deprecated?

• Can you replace the component without rebuilding the application?

• Are your agentic or workflow functions dependent on a particular model?

• How stable are the vendor’s pricing and usage limits?

• What happens if the cost of an API call increases substantially?

• Do you have monitoring, fallback behavior, and an exit strategy?

A prototype can appear inexpensive because the underlying tools are free, discounted, or in beta. The economics may look very different once customers depend on the application and usage grows.

Nobody Reads Anyone Else's Code — And Now Nobody Reads AI's Either

Cheryl Dopp

• You

In a world of AI, having a unique voice and clear, personal vision will be the differentiator.

16m •

I enjoyed reading the post by Andreas Horn yesterday, and I just want to point out how many of the comments were developers stating that they aren't even reading the code before shipping it lol.

That dovetails with another comment I made about how developers and project teams are reluctant to re-leverage what has been built, and to refactor or extend existing codebases. In practical terms, I've almost never witnessed a developer reuse another developer's or team's code.

The argument is always about risk (risk of dependencies intra-project) and cost (it takes time to read another's code). They'd always rather write it from scratch, even if it is largely replicating existing functionality in another set of code.

This introduces the same problem that duplicated data produces: different and contradictory logic in different places and the overhead of resolving discrepancies between the codebases or data stores.

And the cost of pulling the casino lever to regenerate something new seems cheap, at the beginning.

I don't think these two problems get any better when AI is writing the code, and am reminded of it after reading the comments.

Do you?

Why 95% of Enterprise AI Pilots Never Reach Production

Roughly 95% of enterprise AI pilots never reach production. That number gets thrown around at conferences like a warning, but it's rarely examined. So let's examine it.

The failure is almost never the model.

The model works fine in the notebook. It works fine in the sandbox. It works fine in the demo. What breaks is everything around the model — the last mile inside a messy enterprise. Data readiness. Eval coverage. Legacy system integration. Change management. Inference cost at scale. Regulatory explainability. The organization's tolerance for technical debt. The cultural willingness to expose bad data rather than hide it.

That is why the frontier labs — OpenAI, Anthropic, Palantir, Google, Databricks — have all quietly started shipping engineers along with their models. Forward Deployed Engineers, Applied AI Engineers, Deployment Engineers — different names, same job. Comp packages at the top of the market. The labs figured out that the bottleneck isn't in the lab. It's in your enterprise.

But hiring a Forward Deployed Engineer from a frontier lab doesn't fix the underlying issue. That engineer is a specialist in making a specific model survive contact with your reality. They are not going to redesign your data governance. They are not going to renegotiate your relationship with the vendor whose data you can't actually trust. They are not going to fix the semantic drift between the way finance defines a customer and the way marketing does.

The real last mile is the data foundation. AI doesn't fail because the model is wrong. It fails because it was built on data nobody vouched for, in systems nobody documented, governed by definitions nobody agreed on.

That is the work. It's less glamorous than the model. It's slower than a proof-of-concept. And it is what separates the 5% of pilots that reach production from the 95% that die there.

Why We Built AI NOW: The Case for a Firm, Not a Freelancer

Enterprise AI isn't a one-person job. Here's what my co-founder Cheryl Dopp and I set out to build — and why we did it together.

When Cheryl Dopp and I started AI NOW, we made a deliberate choice: this would be a firm, not a solo practice.

That distinction matters more than it sounds. The market is flooded with individual AI consultants — many of them talented, some of them excellent. But enterprise AI is not a one-person problem. It sits at the intersection of data architecture, governance, cloud infrastructure, business strategy, regulatory context, and organizational change management. No single practitioner covers all of that credibly. And when the engagement stakes involve Fortune 500 data and regulated industries, the gap between "consultant" and "firm" becomes existential.

The problem we kept seeing

Cheryl has spent nearly three decades inside the data layers of banks, insurers, healthcare systems, federal agencies, and media companies. What she kept observing — and what became the founding thesis of AI NOW — is that enterprise AI initiatives almost never fail at the model. They fail at the data foundation beneath the model. Roughly 95% of enterprise AI pilots never reach production, and the reasons are almost always the same: fragmented definitions, weak governance, master data chaos, architectural debt, and organizational misalignment about what "AI-ready" actually means.

Meanwhile, the market response has been to hire more data scientists and buy more AI platforms. Both help. Neither addresses the underlying problem.

Why a firm, not a freelancer

We built AI NOW as a small, deliberate firm because the work requires two things simultaneously:

Depth of enterprise data experience — the kind that only comes from having built and stabilized data platforms inside dozens of Fortune 500 environments. That's Cheryl's core.

Modern platform, delivery, and operating-model expertise — cloud-native architectures, semantic layers, vector infrastructure, and the operational discipline to actually ship. That's where I come in.

Together, we can walk into an AI readiness engagement and cover the full stack: strategy, architecture, governance, platform selection, and delivery — without handing the client off between three vendors, four consultants, and a systems integrator.

What we're building

AI NOW is intentionally small and senior. We're not scaling into a body-shop consultancy. We're building a firm that can be trusted with the most sensitive parts of an enterprise's data foundation — the parts that determine whether an AI initiative becomes a production system or a very expensive slide deck.

If you're a Chief Data Officer, VP of Data, or Head of AI at a mid-to-large enterprise wrestling with the gap between AI ambition and data reality — that's exactly the conversation we're built for.

More thinking to come.

— Nikita Khlopchatnikov
Co-Founder, AI NOW