6 ms·

> 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?

jvilalta 3mo ago
They read hacker news
kevin42 3mo ago
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.
- blanched 3mo ago
  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."
  - thraway3837 3mo ago
    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.
    - blanched 3mo ago
      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.
    - Ferret7446 3mo ago
      As a senior eng, I use "vibe coding" as a http://www.catb.org/jargon/html/H/ha-ha-only-serious.html 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
- thraway3837 3mo ago
  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.
nvr219 3mo ago
Mostly post on hacker news.
- ch4s3 3mo ago
  Living the dream! Son of Anton provides.
- thraway3837 3mo ago
  Haha, I actually laughed out loud, thank you for that :)
ramesh31 3mo ago
>"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.
- blanched 3mo ago
  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.
  - thraway3837 3mo ago
    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"
- alanwreath 3mo ago
  “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.
thraway3837 3mo ago
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!
- Schiendelman 3mo ago
  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...
- blanched 3mo ago
  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 :)
j45 3mo ago
Manage and oversee the engineering
- pbgcp2026 3mo ago
  You forgot a "vision". /s
  - j45 3mo ago
    Yeah if one wanted to include vision as part of how you setup gps on how to drive it could probably help a lot.
kdheiwns 3mo ago
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.
- blanched 3mo ago
  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!
- alightsoul 3mo ago
  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.
- thraway3837 3mo ago
  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!
  - otterley 3mo ago
    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 https://www.youtube.com/watch?v=vjaHrp6JtyY
phil21 3mo ago
> 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.
- blanched 3mo ago
  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.
  - phil21 3mo ago
    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!
- tikhonj 3mo ago
  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.
nullsanity 3mo ago
[dead]

jvilalta 3mo ago

They read hacker news

kevin42 3mo ago

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.

blanched 3mo ago
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."
- thraway3837 3mo ago
  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.
  - blanched 3mo ago
    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.
  - Ferret7446 3mo ago
    As a senior eng, I use "vibe coding" as a http://www.catb.org/jargon/html/H/ha-ha-only-serious.html 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
thraway3837 3mo ago
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.

nvr219 3mo ago

Mostly post on hacker news.

ch4s3 3mo ago
Living the dream! Son of Anton provides.
thraway3837 3mo ago
Haha, I actually laughed out loud, thank you for that :)

ramesh31 3mo ago

>"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.

blanched 3mo ago
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.
- thraway3837 3mo ago
  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"
alanwreath 3mo ago
“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.

thraway3837 3mo ago

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!

Schiendelman 3mo ago
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...
blanched 3mo ago
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 :)

j45 3mo ago

Manage and oversee the engineering

pbgcp2026 3mo ago
You forgot a "vision". /s
- j45 3mo ago
  Yeah if one wanted to include vision as part of how you setup gps on how to drive it could probably help a lot.

kdheiwns 3mo ago

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.

blanched 3mo ago
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!
alightsoul 3mo ago
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.
thraway3837 3mo ago
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!
- otterley 3mo ago
  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 https://www.youtube.com/watch?v=vjaHrp6JtyY

phil21 3mo ago

> 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.

blanched 3mo ago
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.
- phil21 3mo ago
  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!
tikhonj 3mo ago
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.

nullsanity 3mo ago

[dead]