| My personal opinions on AI and AI usage in software development have fluctuated in the past year, especially as I've used it more in my professional work. As AI becomes more deeply embedded in the tools that I use, I struggle to identify a hard line on what "Made with AI (tm)" actually means. If I'm using it for refactoring work as basically a glorified "find-and-replace" or to help me track down the cause of tricky bugs through trace files, does that make my work "made with AI"? (I think "yes it does" and would follow up with "but does it matter?") If I send an agent to complete a JIRA ticket on a system that I designed, read the diff, and approve the changes - does that invalidate my prior design and development work? (I think "no".) If I use a website builder, a 3rd party library, or one more abstraction layer past what is currently acceptable, should that change how others or I feel about that project? I'm not really sure, but since I work on business software I don't think my customers really care about how the sausage is made; they're mostly looking for results. I do, however, see a massive difference between "AI as tools" and "AI as creative director". I agree with the mindset of "I want to hear stories from humans" and "I want to experience creative expression from humans". But some of the current discussion feels like the arguments we had back in the day of whether Photoshop/digital media/video games were "real art" or not. If a human has creative vision and uses a robot stir-er to mix their paints, I don't think that should invalidate their painting. We can still judge it, though. |
| For me, the dividing line is this question: Do you know what's going on? You see people brag about how "they" "made" something, with neither the qualifications nor the vision to motivate me to care. If I wanted vibecoded slop, I could just cut out the middle man, like everybody else with a Claude subscription. But this stuff really does shine when competent people such as myself - an expert, gentleman, scholar, etc. - use it for things like exploring a new topic, rubberducking design ideas, diagnosing problems, and sometimes go the extra mile. Software projects are full of incidental, boring stuff, and it makes a meaningful difference to be able to say to Claude things like "please compare the performance of these 5 different approaches, and show me your notes". But just like a colleague, it has no clue what your actual intentions are unless you tell it, and you can't communicate those intentions if you don't know them yourself - and crucially, you can't know them if you don't have the expertise to know what you actually want. This doesn't feel like cheating at all, and I don't relate to the choir of disillusioned programmers who feel demotivated by the introduction of LLMs in their workflow. I mean, maybe their work wasn't all that interesting to begin with? I don't know. I get that it sucks to feel replaceable. |
| |
| ▲ | gchamonlive 19 hours ago | parent | next [-] | | "do you know what's going on" is shallow because I don't know what's going on when I use python. Do you? I mean exactly how the interpreter works, what each optimization is doing and such. I'd guess not in most cases and still it's perfectly acceptable to use technologies that abstract complexity away to a point where the code solution space and how it actually manifests in the hardware are two completely different disciplines. So I'd expand and say that the line should be drawn at knowing how the architecture works, but also we need a pinch of good faith, because it's not very hard to know when you cross the line of overreaching for AI, and it's usually when you hit a point where your prompts start to look like "previous implementation didn't work, try again" or "that's not what I had in mind" or "bug is still there try fixing again" | | |
| ▲ | simonask 17 hours ago | parent | next [-] | | I do know the broad strokes of how a Python interpreter works. I’ve written compilers and interpreters before. But that’s not the important part: I can trust that the people who wrote the Python interpreter understand it, and I have reasonable confidence in their ability to make good judgments within the scope of what it does. In short, they’re experts. They’ve earned a high degree of trust. I would not worry at all about their use of AI to develop Python, if that’s what they’re doing. But someone who doesn’t understand how a Python interpreter works cannot meaningfully expect me to trust their vibecoded weekend project that reimplements Python. | | |
| ▲ | gchamonlive 17 hours ago | parent [-] | | But people happily trust unknown packages in NPM. It's a matter of culture and consensus. If this vibecoded weekend project was a Google internal SWE's with 16 agents running complex architected tasks, people would look at it differently, so AI usage isn't a good proxy for quality, but you can feel when there's care in a project. | | |
| ▲ | simonask 14 hours ago | parent [-] | | > But people happily trust unknown packages in NPM. I mean... I don't, and I don't think anybody should. > It's a matter of culture and consensus. Yeah, but I do think trust, confidence, personal reliability are key factors here. Slop wasn't invented by AIs. We used to call them "script kiddies" - people who only knew how to copy and paste. > but you can feel when there's care in a project. I couldn't agree more! This is such an important point. |
|
| |
| ▲ | disillusionist 18 hours ago | parent | prev [-] | | This is a question I'm also grappling with. I undergrad I took C++ classes but my Computer Engineering / Electrical Engineering friends were taking C or assembly classes and there seemed to be a slight undertone that more abstracted languages were "lesser" because you didn't understand things at the machine level. I believe people feel that AI is different from "just another abstraction layer" because of the nondeterministic nature? | | |
| ▲ | gchamonlive 18 hours ago | parent | next [-] | | It's certainly because AI can make specific technical and aesthetical choices that the user wouldn't normally do, so it's a contextual reproduction of someone else's work being appropriated by the agent. The problem is that although we do this all the time, sometimes licenses require credits when code is reproduced, which is quite hard given the nature of LLMs and their compressed knowledge. I think we are trying to squeeze AI into a social structure of credit and reputation that's outdated and doesn't really support how technology is now developed with AI. | |
| ▲ | ryandrake 15 hours ago | parent | prev [-] | | Here's how I look at it: I think the question you and OP need to ask is: "What is the work product?" That's what you need to understand. When you write Python, the work product your name is on is the Python code. You don't necessarily need to understand what the python interpreter is doing under the hood--it's a nice bonus if you do, but you're not a lesser developer if you don't understand it. When you write C++, your work product is the C++ code. You don't necessarily need to understand assembly or machine language, but it's a nice bonus. You're committing the C++ code to source control with your name on it, so that's what you are claiming to understand. When you use an LLM to generate code, your work product is not the prompts--it's still the code (that the tool generates). So your responsibility to understand the work product you're signing your name to is to understand the code it produces. That's ultimately what you're responsible for. | | |
| ▲ | SleepyMyroslav 13 hours ago | parent [-] | | Where did you get this 'signing your name to the code' ? If your version control clearly attributes code to an agent, there is no paper trail going back to you claiming fitness for a particular purpose. I am discussing with management how do we understand projects that employ agentic approach and it is not clear at all what the source will be that developer will claim to understand. What is clear is that it cannot be all of the code. | | |
| ▲ | ryandrake 11 hours ago | parent [-] | | I'm talking figuratively signing your name. Most of us are not actually signing a physical piece of paper saying we understand our code, but when we do a commit or write a PR, we are essentially declaring "I understand and am responsible for the nature of my work." As a professional who takes his work (employment and even hobbies) seriously, I don't think this part is optional. Any human working on a project needs to be responsible for his own output. We can't just throw our hands up and say "Don't look at me, the agent did it!" just like a construction worker who cuts through a water main can't say "Don't look at me, the excavator machine did it!" |
|
|
|
| |
| ▲ | disillusionist 19 hours ago | parent | prev | next [-] | | I've worked on a couple vibe coded pet projects now. I wouldn't say that I "wrote" them but I would say that I "designed" them and might even say that I "made" them as it took quite a few back-and-forth passes before I was happy with the results. But to your point, one one of those projects I don't fully know "what's going on". Even though I could open the source and grok the code after a brief inspection that's not really the point of that exercise. On a different note, AI tools have been great at combating corporate bureaucracy! If the Big Man says that all modules need unit tests with 80% code coverage, you can give the agent that task and then move on to more interesting hard-thinks. | |
| ▲ | talmr 19 hours ago | parent | prev | next [-] | | Many have said things like “do you know what’s going on in your car while you’re driving?” IMO, this is a wrong way of looking at things if the job is software engineer. We aren’t the end user who is driving. They don’t need to know how the car works. It takes them to and from work or their kid’s sports event. The engineer does need to know how the car works. Sure, there are specializations so someone working on one part of the car might not know how another part works. But, they know how these things work together, at least at a high level. I’m noticing that without proper planning and architecture, these AIs go off the rails and introduce horrific complexities that are hard to diagnose and even harder to fix. For some small app that nobody cares about besides me, I don’t really care about the internals much. I can have the agent churn and do fixes and updates. For something larger that will have end users who rely on the software to work, I don’t think having the agents burning millions of tokens and many minutes on each task is a good way to work. The strength of AI is that it can work across many files, reading and writing magnitudes faster than any human. Their weakness is that they need direction, otherwise the result is chaos. I’ve tried various approaches and honestly, I’m back to spending time up front planning the system and doing a little bit of mixed (manual and AI assisted) coding to set the foundation. A few days or even a week or two of focused writing concise documentation, with enough foundational code that shows how the system is architected, yields tremendous results down the road. Even the AI benefits from it because it knows exactly where, what, and how to change. Every system is unique, that last 10% that separates it from the generic recipe is what matters. I am not saying that humans are perfect or that I’m some god-tier engineer. I know my limits, and as an AI enthusiast I have also realized where these tools have consistently fallen short. Unfortunately, we must realize that no system is perfect, and humans need to do boring work like planning and proper guardrails because chaos is easy. Sorry for the long write up/rant. | |
| ▲ | dataflow 19 hours ago | parent | prev | next [-] | | > If I wanted vibecoded slop, I could just cut out the middle man, like everybody else with a Claude subscription. I've been thinking about this a lot, and I've been going back and forth on it. Because I do feel similarly, but I don't think the premise is itself quite true: - It neglects that people often don't do things that they want to - and can - do, and that lowering the activation energy can in fact make a positive difference in things happening vs. not. (i.e. "You could've, but you still didn't" happens all the time.) - It neglects that tokens are, in fact, limited - especially with the best models. - It neglects that prompting itself is be a skill that can vary across people in a manner that doesn't have a 100% correlation with their ability to understand or do things manually. - It neglects that time is limited, even the smaller amounts you have to spend with AI assistance. - It neglects that sometimes the friction is elsewhere (e.g. setting up the harness and thorough testing of the change might have a lot of overhead), not in reviewing the change itself. - It neglects that the value of a single isn't binary: some person or AI having said "this looks plausible to me, though I'm not an expert" can still be a better signal than nothing, even if a weak one. The trouble is, of course, that the humans mailing these out often have a very different sense of which way the balances tip than the reviewers do, so what could be true in theory still often isn't in practice... | | |
| ▲ | disillusionist 18 hours ago | parent [-] | | I feel similarly about this. I spent time on-and-off over the course of a week "vibecoding" a project that will hopefully meet a particular need of mine. Once I've worked out the bugs, I'll probably open the repo public and if others also find the project useful then that's great! If not, move along. Could someone vibecode it yourself? Yes, go ahead- and it will probably meet their specific need better! But if you want something now, "off the shelf", that will probably do most of what what? Well, I've done that week of slop-work for you. |
| |
| ▲ | pydry 19 hours ago | parent | prev | next [-] | | >For me, the dividing line is this question: Do you know what's going on? Not a question a customer can give a clear answer to. | |
| ▲ | guhidalg 19 hours ago | parent | prev [-] | | I agree that the question we need to grapple with for the foreseeable future is "Do you understand this code?". If you write it by hand you (very probably) understand it, but if you let the LLM write it then you understand it less. If you let the LLM take over for too long, some inflection point is crossed where you understand a minority of the code base; that's when you notice the water around you is boiling, and your entire industry is fanning the flames. I don't want to doommax: AI is great, but if we allow ourselves to lose understanding of what our code is doing then we're not doing engineering anymore, we're just doing summoning spells hoping the complexity demon spirit doesn't kill us as a result. | | |
| ▲ | simonask 11 hours ago | parent [-] | | Yeah. But also, let’s zoom out: giant unmaintainable insta-legacy abominations are well within the capacity of humans to create - just look at the past many decades of software in general. The hard part never was writing the code. The hard part was always to manage complexity in a changing environment. |
|
|
