Gen AI is what happens when you ship something about 8 years too early and hope it doesn't catch up with you.
Oct 26, 2025 · 10:52 AM UTC
Disagree. This mindset is how startups fail to launch. You ship MVP. First movers see value and then tell you what to fix first.
Honestly this is my problem with the AI crowd. The tech doesn't mean shit if it's not reliable.
Why're we expected to believe in the potential of the tech?
Potential means shit in business. I can't go tell my boss that I have the potential to make him a billion dollars. I'd need to back it up w proof and an actual roadmap
I completely agree that LLMs, any of them hallucinate way too much. You can't rely on them and there are a lot of technologies now that are quickly sent to be sold asap, many which don't work and are garbage
But I also believe that this is only the beginning. If accountability is practiced, big companies holding big tech accountable for their shitty garbage, if not sue them. then they will improve over time and perfect itself.
But if we leave it in this state and pile up new technologies day by day, then we won't have anything that works, but a pile of beautiful, but broken toys
You build the infrastructure first, then call on LLM’s for specific queries but the prompt is customised for the user based on the task and the user preferences. Using multiple LLM’s to argue it out. I see this as an ability to ‘polish’, only.
You DO NOT use LLM’s to navigate or become the infrastructure itself. When we say ‘AI’ we are talking about LLM’s for the most part. There’s still a boat load of tech waiting to be used that technically isn’t even ‘AI’ but you throw in minimal use of an LLM and put ‘AI’ into the branding and you do have something that seems like ‘AI’ when technically it’s not, its just clever automated tech. Just like how LLM’s aren't really true AI to begin with. As such, for many builders out there, I just don’t see this post as being relevant to them if they understand some of these fundamental truths. If you’re integrating GPT into nearly every process of your business then yeah, count on multiple problems.
Automate and roboticise everything, you can do that with anything (without ‘AI’). You just polish a few things using LLM’s so it doesn’t feel like a soulless entity. Amazon as a business is peak robot. They nailed it before ‘AI’ right? And guess what, most businesses are still leagues behind the genius of Amazon Operations and they think they can jump to ‘AI’ with high accuracy? When inaccuracies within multiple processes stack? You have to learn to walk before you can run.
Which is why we need regulation and compliance!
cc @compliantvc
"... AI-augmented workflows as "vibe coding" misrepresents the skill and rigor involved. .. it creates the false and risky impression that one can simply prompt their way to a viable product without understanding the underlying engineering fundamentals."
Vibe-coding is not the same as AI-Assisted engineering.
A recent Reddit post described how a FAANG team uses AI and it sparked an important conversation about semantics: "vibe coding" and professional "AI-assisted engineering". While the post was framed as an example of the former, the process it detailed - complete with technical design documents, stringent code reviews, and test-driven development - is a clear example of the latter imo.
This distinction is critical because conflating the two risks both devaluing the discipline of engineering and giving newcomers a dangerously incomplete picture of what it takes to build robust, production-ready software.
As a reminder: "vibe coding" is about fully giving in to the creative flow with an AI (high-level prompting), essentially forgetting the code exists. It involves accepting AI suggestions without deep review and focusing on rapid, iterative experimentation, making it ideal for prototypes, MVPs, learning, and what Karpathy calls "throwaway weekend projects." This approach is a powerful way for developers to build intuition and for beginners to flatten the steep learning curve of programming. It prioritizes speed and exploration over the correctness and maintainability required for professional applications.
There is a spectrum between vibe coding and doing it with a little more planning, spec-driven development, including enough context etc and what is AI-assisted engineering across the software development lifecycle.
In stark contrast to the post, the process described in the Reddit post is a methodical integration of AI into a mature software development lifecycle. This is "AI-assisted engineering," where AI acts as a powerful collaborator, not a replacement for engineering principles. In this model, developers use AI as a "force multiplier" to handle tasks like generating boilerplate code or writing initial test cases, but always within a structured framework.
Crucially, the big difference here is the human engineer remains firmly in control, responsible for the architecture, reviewing and understanding every line of AI-generated code, and ensuring the final product is secure, scalable, and maintainable. The 30% increase in development speed mentioned in the post is a result of augmenting a solid process, not abandoning it.
For engineers, labeling disciplined, AI-augmented workflows as "vibe coding" misrepresents the skill and rigor involved. For those new to the field, it creates the false and risky impression that one can simply prompt their way to a viable product without understanding the underlying code or engineering fundamentals.
If you're looking to do this right, start with a solid design, subject everything to rigorous human review, and treat AI as an incredibly powerful tool in your engineering toolkit - not as a magic wand that replaces the craft itself.
What most teams are calling “AI products” right now are really just ungoverned reasoning sandboxes. There’s no consistency, no auditability, no shared intent.
I think this is where what we do at Null Lens helps. It translates messy human requests into deterministic Motive / Scope / Priority contracts before inference. Making intent standardised and governable upstream.
