Hacker News Reader

Comment by thraway3837 | Hacker News Reader

We replaced a 120,000 USD/year low-code/no-code platform that was running a lot of workflows. And we have another platform that is also similar that we are on track to replace by EOY.

Both have been replaced by "vibe" coding. It works well. Everyone's happy. People are having fun with it. We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR.

We have senior engineers review the actual functionality and none of them have read any more than a few lines of code.

Every person who builds like this has the same DX (developer experience): "Wow, I've been wanting to build this thing for years now. I just never had the time to do the things I wanted to do to help me and the teams that depend on us"

Total cost of AI subscription per month: Less than $1000. Preference is Claude Opus and Codex whatever the latest model is. Effort is a personal preference since it does not seem to matter.

View on HN

This industry's complete outsourcing of its core business value on a third party proprietary subscription based tool, Claude, made by an unprofitable company, Anthropic, is very concerning. You are all lunatics, sorry.

I don't follow this line of reasoning. Would it have been meaningfully different if OP had used open-weight models like GLM or DeepSeek? Does it really matter considering we'll have superior models next quarter?

The meaningful difference is that you will not experience EOS if (when) anthropic/openai/etc fails to become profitable and is no longer subsidized by capital funding.

While "vibe-coded" apps do help lots of people who didnt have the time/money/skills to create their projects, you should be aware that currently the compute is being subsidized so that users become reliant/used to the service.

I believe vibe coding in general is a bad business strategy whether you use FOSS models or not because it means your product probably doesn't have any "secret sauce" (leaving code maintainability problems aside). By that I mean a carefully researched innovation that gives the edge to your product. Nevertheless, using FOSS models is clearly better for the reason you mentioned. I believe serious businesses will transition into using AI on-premise in a very restrictive manner (eg: AI only for tests and reviews policy, etc.). We'll once the dust is settled.

Internal business tools are not innovative products. The potential edge comes from things like being better aligned with the business process or eliminating tasks from the process.

You can inject "secret sauce" through your domain knowledge or life experience.

You could vibe code the "tedium" out of your app with little to no care about it using AI while paying close attention to the critical aspects of your product. Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want

Stricter use would remove the primary benefit while not really giving much upside so I don't think companies will move in this direction

> Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want

Also anything which isn’t kept private can quickly be cloned. I think it’s going to be hard for a SaaS to stay profitable unless there’s a real-world tie-in to keep someone from pointing a bit at your app and cloning the observable behavior with just enough changes to claim they didn’t.

The question is if your "secret sauce" will stay secret as you use Anthropic's products, considering they've been launching specialised models like Claude Legal and Design. What happened to Figma with Claude Design should be a warning sign.

You're making the mistake of assuming that just because LLMs make things easy, all of the value is in the LLM and not in the prompting and glue work.

Put on the hats of a risk manager or supply chain manager. Yes, that would have mattered. What you insource today, you can repeat tomorrow. If you know the price of an input will multiply in the near future, you should at least develop processes that can handle disruption. If you expect dirt cheap LLM’s to remain available, or even better: improve in quality, feel free to make that assumption explicit and keep using the external supply. I don’t know what the future holds, but the vibe your software organizations cannot go back to manual development once LoC has exploded. I hope firms are making these choices deliberately.

You seem to be referencing as core business value a combination of (1) the ability to maintain a (2) business criitical resource, but stating it as if catastrophizing from a hasty generalization. Can you clarify?

It's really not that simple. A lot of what's involved is fungible. Of course, the answer to "Was the greatest intelligence harnessed to make the greatest decision?" Is always no.

AIs can be swapped for one another, run locally, and implemented in ways that are less prone to loss of function. Loss of anyone who understands the working code is a type of risk, but that kind of issue tends to bounce between losing skill from lack of foresight due to economic savings, and overhiring / bringing back lost employees as consultants.

The industry is a joke.

Meta requires tens of thousands of engineers to maintain a social media site. Google even more for an ad platform.

Never have so many achieved so little and the joke is all those clowns think they are “10x engineers”. Meanwhile WhatsApp got to global scale with less than 30 people (before Meta bought it and piled on the inefficiency).

Vibe coding is many orders of magnitude more efficient than the industry standard and that’s why it’s so disruptive.

I think the comment said they were outsourcing it to "whatever".

> we ask AI to reference that ticket, code to it, and create a PR

> none of them have read any more than a few lines of code

So what do you / your team do?

You know, that question should trouble us more. But honestly we've all asked ourselves that same question and I think our collective response is too nuanced to try to type properly but I'll try.

Tools are always made out to seem like the human could be replaced. We've seen that every time some new technology comes out that some people claim will replace humans once and for all! But this does not seem to be true.

What AI coding allows us to do is get rid of just 1 or 2 parts of the job: coding and debugging. The rest of our knowledge based job is still there. AI just speeds things up because I can now ask it to code something while I go help plan or design something with a colleague. Most of us at this workplace also have a very good eye for UI design and system design patterns, so when we prompt/query the AI, we can understand what is happening. That isn't a replacement, that's more like getting a team of engineers who can do different things all in service of a larger goal.

Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used. And to be perfectly honest, and I know that this will rub some in the wrong way, a lot of development since the 90s have been around object and graph management. For the 1000th time, I just do not (and most engineers I work with) care how an object is serialized and deserialized. Just display it on a table for me, why are we spending weeks coding a list, adapter, transformer, JSON/XML/whatever, networking calls, networking nuances, etc. etc. when I just want to get our customers seeing that list and move on?

I don't know if I did a good job covering the nuance, AMA!

> Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used.

Not to be too snide, but if that's your reductionist view of the work of software development, I'm not surprised you're comfortable vibecoding without a human in the loop.

Thank you for the thorough reply! I also appreciate that you recognized my question as good faith (and my apologies, based on other replies I should have been less brief to avoid misinterpretation.)

It seems my definition of "vibe coding" was wrong after all, at least in this case, and that you're still doing design. My initial read was that this was fully AI-powered, and while that sounded interesting, it did leave me wondering what the humans did :)

No worries at all, I took your question in good faith :)

I also responded below re: Vibe coding.

This is absolutely my experience. And I'm commenting on HN a lot more now too - but in between, I'm doing competitive analysis, trying out a fix I implemented or a feature I added, marketing, talking to friends about their bug reports...

writing code is the actual fun part of the job though.

it’s a shame we automated that instead of the boring system design shit.

I disagree. Shipping has always been the fun part for me. I have been a DEEP engineer, and I love figuring out creative and deep optimizations, but writing them was never fun, designing them was. Writing the code has always been the least enjoyable part for me.

This is the conflict we've entered. There is a good portion of the engineering population that considers coding fun.

The other side considers shipping as a feature.

I can both sympathize and empathize with this conflict.

I love coding, or rather I love what coding allows me to do which is build and ship. That’s not be saying we abdicate any responsibility and yolo all our code but coding was _always_ a means to an end.

See also debates between high/low level languages.

You might as well say “real men/women only write Asm”.

All those things (coding / distributing / design / whatever) WAS fan to you / us. It was. "The thrill is gone ..."

>writing code is the actual fun part of the job though.

You mean typing the actual code into the editor is the fun part for you? For me, the fun part has always been "cause computer to do novel things", and actually typing/compiling/debugging the code is just a speed bump on the way to something fun.

It's like doing a jigsaw puzzle. The fun part is the doing. I don't really care what the final picture is, and once it's assembled the fun is over.

That's an interesting choice of analogy because I despise doing jigsaw puzzles. I don't see where the entertainment is supposed to be.

i mean solving a problem with code that came from my own brain.

the act of typing is trivial and second nature, like breathing. but going e2e from brain to keyboard to editor to working product..that’s the thrill. and it’s dead.

To me the system design shit is fun as well, different strokes for different folks!

> AMA!

I think I missed where you posted what business you work at

- What you do at Initech is you take the specifications from the customer and bring them down to the prompt engineers?

- Yes, yes that's right.

- Well then I just have to ask why can't the customers take them directly to the vibe coding software people?

- Well, I'll tell you why... because... engineers are not good at dealing with customers...

- So you physically take the specs from the customer?

- Well... No. My secretary does that... or they're faxed.

- So then you must physically bring them to the software people?

- Well... No. ah sometimes.

- What would you say you do here?

- Look I already told you, I deal with the @#$% customers so the prompt engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!

Mostly post on hacker news.

Haha, I actually laughed out loud, thank you for that :)

Living the dream! Son of Anton provides.

My guess is design (features/functionality, not code). When you don't have to write every line of code and you can quickly iterate on features, you have a lot of freedom to dial in what you really want out of an app.

To be clear, I didn't mean this as an anti-AI gotcha. They also said:

> We get feature requests, improvements, ideas, feedback

So maybe I misunderstood, but it sounded like the design was external (and based on an existing product to begin with).

Also, my understanding was that "vibe coding" meant more of "make it do X" as opposed to "here's a design for X, implement it."

Sorry, I was trying to be glib by putting "vibe" in quotes, because I think that term is used for people who have zero experience in software engineering, but when used by senior engineers, it's something else. But, I don't know if some populations would still call it vibe coding.

The design is external in that the requirements come from external customers or internal customers (since these applications) are used by both. We're not trying to duplicate or replicate any existing system, but I can't confidently say that I'm not drawing from any prior art.

Hope that makes sense.

As a senior eng, I use "vibe coding" as a http://www.catb.org/jargon/html/H/ha-ha-only-serious.html

Obviously I'm not just shipping whatever it spits out, but the frontier models and harnesses are getting so good that I'm definitely not checking everything it does or all of its reasoning

Makes sense! My mistake for assuming it was the former definition, lesson learned.

Hopefully soon our industry will align on some standard terms. I feel like "AI-assisted", "agentic coding", "vibe coding", etc each have a few different meanings already.

YES!!! Very well said and captures what I was trying to convey.

There's also certain features of an application that most of us engineers know how it works or how to do it, but it is just so painful to do it by hand. Or other features that you've always wanted because you saw another app do it and it was beautifully done and you can just "have" that feature in your app too.

The joy is in seeing the feature come alive, not so much in fighting the computer.

> So what do you / your team do?

This is so funny to me, because I know it's asked in earnest but seems so obvious to me:

They get actual work done.

Programming isn't work. That's just a means to an end. A tool to get the actual job done.

At least in most orgs. Obviously there are exceptions - but the vast economy is not a bunch of software companies. It's companies doing things to build a physical product, and software is a relatively new annoying side quest/cost center.

It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!

That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.

Eh it's nothing new. Outsourcing comes from the same spirit.

Perversely I find myself increasingly blaming the growth of product management divorced from engineering as the source of some of this.

Everyone wants to be the next Jobs, but somehow they missed that it was the marriage of high quality design and high quality engineering that got Apple where they are today.

Rather, the lesson they learned is that PMF and UX and yadda yadda yadda are all that matter and coding is just a means to an end.

It'll be interesting to see how many companies discover that you can't achieve those ends if you build on a broken foundation.

> annoying side quest

Face it - it's because developers are annoying princesses. Just read your comment again.

My entitled friend was whining AI will start monitoring his work and he won't be able to slack as much as he does now. Basically he'll have to work like everyone else. FFS.

Everyone except management knows that management is a distraction, including the shareholders and board when the org is getting too bloated and the numbers aren't looking good.

Which is a perfect parallel to coders who don't realize that coding is a distraction. When your job depends on you not understanding something, etc

I think programming is work, but I get your point :). And yes, of course - I'm mostly just curious how peoples roles at various companies are evolving as they hand off more and more to AI.

Fair, work was the wrong word to use.

I meant - create useful work product. For most companies software is a means to an end. The programmer writing code isn’t useful, it’s the end result. A lot of small to midsize companies employ a couple software guys out of necessity, and the results are usually middling at best. It’s a problem IT in general has really failed to solve very well.

I say this as someone who has picked up and put down “programming” as I needed it. It’s never been something I’ve gotten any satisfaction out of by doing, but I get huge satisfaction out of the resulting product or workflow automation or whatnot.

For my uses, if I could replace my programming and IT time with a robot I would - since me being in that role just slows down delivery to the end user. One of my first hires as a small startup was a programmer - specifically because I knew I rather sucked at it and what a pro could get done in a day took me a week. This is why AI for the low value/less complicated automation tasks is extremely compelling to me.

I’d immediately have 20 other things to work on to soak up the time savings!

It's really quite interesting how there are always posts on HN with people talking about how AI made their life great, did it cheaply, made a great product, and saved the day. But whenever someone asks for specifics, the questions are always dodged or answered very vaguely. It's rare that anyone ever even says what their product does.

To be fair, thraway3837 posted a reply on a sibling comment and offered "AMA" :).

That said, I do see a lot of those posts you're talking about, and I think a lot of AI development is way overhyped. But I also think internal tools like this can be a good use case.

Personally "none of them have read any more than a few lines of code" makes me wary, but if it works for them, then so be it!

I have Claude work on web app testing scripts written in java using JUnit and selenium. The scripts test a vibe maintained flight booking app for an airline I can't mention without doing myself. The app is maintained using copilot by another vender. Claude was given to our team by our employer. We aren't even employees of the airline just contractors under a vendor. Before Claude was adopted everyone secretly used whatever chatbot they preferred. I used opencode with Deepseek v4.

I had a product where I was doing accountancy ratios and it’s not that simple since you have lots of different source data to use and it was such a nightmare to combine everything in the right way. Ai did that easily. Also writing code to extract unstructured data was a few hours vs weeks of work.

I'm happy to provide specifics, within reason, of course. Ask away. I've since responded to comments with more detail, but if I missed something there, let me know!

You keep saying you'll provide specifics, but I haven't seen anything. Instead of saying you'll provide them, actually provide them! Be forthcoming.

This conversation feels like the "disturbance in the kitchen" scene from Curb Your Enthusiasm: https://www.youtube.com/watch?v=vjaHrp6JtyY

They read hacker news

Manage and oversee the engineering

You forgot a "vision". /s

Yeah if one wanted to include vision as part of how you setup gps on how to drive it could probably help a lot.

>"So what do you / your team do?"

Probably the hard part; figuring out what the heck to actually build, talking to customers, and figuring out whether it's actually working for people.

Nobody cares that your codebase is Clean and SOLID, or uses $whatever_framework of the day with 100% test coverage.

“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:

- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix) - development cadence (if implementation of feature X took N days, a comparable feature Y should take N days) - sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)

SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).

What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.

Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).

And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?

Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.

Interesting times.

Yes, I'm familiar with these talking points. I didn't mention clean code or solid or frameworks or anything like that.

However, the poster explicitly said they don't do what you said (EDIT: I misinterpreted some of these):

RE "talking to customers"

> We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR

RE "figuring out whether it's actually working for people"

> have senior engineers review the actual functionality and none of them have read any more than a few lines of code

RE "figuring out what the heck to actually build"

> replaced by "vibe" coding

Maybe my definition of vibe coding is wrong?

In any case, I don't have some ulterior anti- or pro-AI motive. I'm genuinely curious why and how a project run this way has humans in the loop at all.

Sorry for the confusion, we talk to customers both internal and external that drive these feature requests.

We ultimately decided that paying for low code/no code platforms was pointless because that's what AI coding is. 90% of the time, we don't even have VS Code open and just gloss over the diffs in the PR.

I honestly don't know what the trajectory of those low code/no code platforms are going to look like. Are their senior strategists looking at the landscape in the last year and going "oh. no. What is the point of our product anymore because what's the point of people dragging and dropping no-code connectors to build an application when they can get 100% portability and transparency by having code generated by AI"

So wait are you saying you replaced an online tool with a local vibe coded app?

Is it a web app with vibe ops?

What's running all of the workflows now? Are you vibe provisioning new cloud instances? Or does everything run on local machines now?

I used CF Wrkers because I wanted to try serverless(1) - I just needed a tiny https proxy for one of my personal scripts and.... It turned out to be super fun.

And no surprise bills.

(1) after my earlier experience with AWS lambda - almost no traffic (few requests per day), on free trier and YET I had to pay for the add-on they automatically added (and it took me almost 2 hours to find all the rhizomes that were proudly anticipating another few £ for pretty much zero traffic).

We did at my work. We were paying too much for low code orchestration software. Replaced it with vibe coded workflows. Still have some infra costs but it's fantastic, cheaper, more velocity, and everybody is happy.

I highly recommend Workers for Platforms for anyone wanting to deploy vibecoded apps: https://developers.cloudflare.com/cloudflare-for-platforms/w...

I have always felt that AI will be much like how we all now have a calculator in our pockets (despite our math teachers telling us that would never happen lol). For math yes one could sit and do long division and multiplication and so on but having a calculator as a tool obviously makes things so much faster. But you still need to have the knowledge of how math works like the order of operations for it to be correct in the end.

I picture AI coding being the same. Ya someone with no coding knowledge can probably vibe code a small project and have it work. But more complex projects I picture AI like the calculator speeding up the work but in the end one must still understand programing and be able to ensure that the code is correct for the goal.

The main difference is (simple) calculators are deterministic and monotonic. Meaning it executes a set of instructions in a predetermined way to produce its output. Bringing LLMs to that level is a whole another ball game. But we'll see, perhaps the arithmetic nature of algorithms will be replaced by a whole lot of tensors in the near future.

Press y to doubt that 1k/m using opus… that cannot be true.

It's easy to believe if it's 5x $200 subscriptions.

Paying by the token is insanely expensive. Only the 5̵ ̵R̵i̵c̵h̵e̵s̵t̵ ̵K̵i̵n̵g̵s̵ ̵o̵f̵ ̵E̵u̵r̵o̵p̵e̵ Biggest Tech Co's can afford that.

But the subscriptions are cheap honestly. Yeah they say it's not for enterprise usage but ok whatever. Not paying $10k when $200 gets you the same value (seriously)

>Yeah they say it's not for enterprise usage but ok whatever.

For now, it's clear that they will likely begin restricting the subs or severely cut back their token allowance.

I could also see Claude looking at source code/repos to try and figure out if it's closed source. If true, demand token payment.

> We have senior engineers review the actual functionality and none of them have read any more than a few lines of code.

A senior engineer should be able to efficiently read thousands of lines of code per day. Maybe this is what you meant by "a few"?

Alas no:

https://smartbear.com/lean/code-review/best-practices-for-pe...

> A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.

...

> SmartBear research shows a significant drop in defect density at rates faster than 500 LOC per hour. Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review.

I doubt the thousands of lines per day claim unless the lines are trivial. It’s quite fatiguing to read hundreds.

No, I really meant that we don't even read the code anymore. In another comment I wrote: we just CMD+Q VS Code and it's not even in the recents/pin to dock, since what's the point? We can see the diffs in the PR and quickly gloss over it and query/prompt/ask clarifications.

Reply on news.ycombinator.com