You wanted this feature for years. You understood the problem, but the amount of time that it would have taken to properly implement and test it held you back from doing it. Obviously, anyone else who wanted this feature came to the same conclusion.
This new tool reduced the amount of time that it would take. So you used the tool. You used the tool to bring the feature into existence, checked the tests, and took enough time to ensure that it was good. You didn't lie about your contribution in the PR, and the maintainer deemed it acceptable. And now everyone has this feature!
When you eat a strawberry do you feel like an impostor for not growing it yourself?
As a woodworker who owns both hand tools and power tools, I don't feel bad when I spend most of a project cutting the repetitive pieces with a motorized saw. I also don't feel like a snob because I prefer certain hand saws under certain circumstances.
To me, the metaphor is pretty solid for coding LLMs. A motorized saw, to anyone that's used them, takes away all the pain and complexity of using a hand saw for the same work, but it also introduces its own complexity and pain. There's also things that stay consistent: I still find myself transferring or measuring certain ways, I still have to brace the piece, I still need jigs (albeit different ones).
> No, but if I asked an intern to eat it for me, I wouldn't feel like I did anything at all.
That's a poor analogy.
If I asked an intern to implement a function, I know I did the instruction and that I worked through them. The intern did work, but I did fancy high level work and killed several birds with one stone.
Even better analogy: if I'm a film director, I'm working through a lot of people. The DP, the cast, the crew, the AD (though they're my boss, telling me what I can/can't budget for)...
The best analogy for AI is the "film director" analogy.
There are good directors and bad directors, good films and bad films. No director works alone (unless it's some kind of avant-garde film school project).
You wouldn't say a film director isn't doing work. That they can't be uniquely felt through their work. That what they're doing isn't hard, doesn't require talent/taste, and doesn't get better over time.
So yeah, our job that we were all interested in has transformed into a different thing (directing), which some people are also interested in, and some aren't.
There's no substantive difference between directing an intern and directing people on a movie, by the way, except the number of people. If you never aspired to direct people, it's all kind of the same, and if you actively dislike it, I imagine directing more people would probably be worse!
Directors do work, but a different kind of work. Not really what most people would consider hands-on filmmaking. They're more like managers--telling others what to do, how to light this, how to shoot that, where the characters should be. It's work but it's not "making." If I want to make a film, I'm going to grab a camera and point it at something. If I wanted to tell other people to make a film, I'd become a director.
That's the major difference I feel between writing code and having an LLM do it. We're all being asked to become directors when we just want to make movies.
Making movies is hard. Ai basically made the smaller personal sized things easy, but substantial projects are still out of reach. There isn't anything for an individual to feel good about.
We grew tomatoes last summer. Over the last 2 years, something about tomatoes (and BLTs in particular) really clicked for me; we'd grown tomatoes many previous summers, and I could give a shit, but last summer I cared a lot about our home-grown tomatoes.
And I totally did feel less good about BLTs I made with supermarket heirloom tomatoes!
It was irrational, but I did feel that way. I get where people are coming from.
It's not irrational at all! The act of doing something yourself brings inherent pleasure and satisfaction, whether that thing is "growing tomatoes" or "coding a feature". It makes us feel useful.
Cherokee Purple.
Black Krim
Black from Tula.
Brandywine
heck, Almost any black tomato is a richer flavor than traditional hybrids.
Heirloom tomatoes are also fantastic for flavors, but they are difficult to grow. Consistent watering, pruning lower leaves to keep disease away, proactive treatment of fungus and bacteria. It's a lot of work, but the results you get when it all comes together, yeah, it makes a fantastic tomato soup, sauce, Caprese salad.
I'm starting seedlings this week. I'm probably going to have more tomato seedlings than I know what to do with. Of course, as problems go, I could have worse ones. The problem I'd like to have is growing too many mini watermelons. For some reason, I just can't get any yield, and the squirrels/mice gnaw on them as soon as they are vaguely ripe.
My partner is not going to be happy when I rip up most of the lawn in the backyard. She'll probably buy me overalls and a straw hat.
"*A BLT is a tomato sandwich, seasoned with bacon.*
It wasn't until I tasted my first great tomato, at the vine-ripe old age of 22, that I finally understood the true nature of the BLT (and, by extension, why I'd never enjoyed tomatoes on my sandwiches or in my salads). Here we go: A BLT is not a well-dressed bacon sandwich. A BLT is a tomato sandwich, seasoned with bacon. From this basic premise, all else follows."
If you buy the variety most often found in American grocery stores (usually labeled as Roma tomatoes), they're terrible. Try the variety labeled as "tomatoes on the vine" (four-digit produce code 4664, which I know from memory, having punched it in to so many self-checkout scanners over the years). They're actually juicy and tasty the way tomatoes should be. Avoid Roma tomatoes, they're cardboard masquerading as a tomato.
"Globe" tomatoes are much, much more common as generics in American supermarkets. Sometimes also "Beefsteak" variety. Roma tomatoes are almost exclusively used in making sauce.
What are they called, then? Since I took a job overseas over ten years ago, I haven't been in American grocery stores much. What's the "normal" variety called? I distinctly remember Roma being the cheapest, and also worst-tasting, variety, and learned to buy the "on the vine" style instead, but those are the only two that stuck in my memory. What is the one I'm forgetting about?
I mean, I'm not much of a gardener, but Erin sure is, and I had a direct basis for comparison. Our tomatoes were better, but the supermarket heirlooms were perfectly cromulent.
I think the key is just to make sure you're buying them in season, and that they didn't travel far.
Yes. I didn't know or understand why I felt meh about run-of-the-mill raw tomatoes this until the Kenji article.
"Using mealy, off-season tomatoes is the primary unforgivable sin, but when it comes to BLT crimes, that's just the tip of the iceberg lettuce.
...
Off-season tomatoes are grown in warmer climates, picked when underripe, then treated with ethylene gas (a gas that is naturally produced by plants to trigger ripening in fruits) to produce their red color before they hit supermarket shelves. The result is tomatoes that are as bland as they are ruby-red.
Truly great tomatoes must be fully ripened on the vine, where they'll continue to develop flavor and sweetness. Look for plump tomatoes, with the heft and give of a water balloon. If you have a choice, look for substantial and meaty heirloom varieties with balanced sweetness and acidity, like Cherokee Purple or Brandywine.
Avoid tomatoes that feel light for their size, which means they have more air pockets inside and are typically better for saucing or salads."
> When you eat a strawberry do you feel like an impostor for not growing it yourself?
I don’t think this is the right question. What you posit is a consumption dilemma. It’s a valid question, but it focuses on what values we might arbitrarily ascribe to how we source what we consume.
The OPs dilemma is more akin to giving a cutting board for Christmas that you bought vs handmade. Or some other. I think these cases of how we present what it appears we created is the dilemma OP is facing.
Except, calling it a "tool" is exactly why OP feels bad. Simply phrasing it another way, I.E. "OP paid for a service to implement a feature he wanted," would completely remove the guilt and be more technically accurate.
IMO, the way we talk about using AI leads to a lot of confusion and needs to change.
if you cant lift something because its heavy, but have an exo suit that will let you lift it... does that make you feel like a fraud?
AI is like that its a tool. you;re still responsible for the use of it and the output of it. you need to understand that if you use that exo suit to hurt someone or use it poorly and damage something/someone.. thats entirely on you. just like a knife in your hand is a tool to prep food or to attack someone. your actions with it are on you.
Last year I got two coworkers. My first in terms of coding. First I looked at everyone code request, but it soone overwhelmed me. We got a third and there was no way I could oversee everything and since I got a team of three management gave me other responsibilities on top.
I have no idea what they code and how they code it. I only go over the specs with them. Everything got quicker but the quality went down. I had to step in and we now have e2e-Test for everything. Maybe it's too much, but bugs got squashed and catched before we shipped.
So that's a win. Before I could test everything by hand. I worked more on things like creating a working release cycle and what tools we should use.
With or without AI the situation would have been similar.
I became a manager. We move the needle. I don't really get to code anymore and I don't see much of the code. It's strange.
My perspective on this is that my first real job in 1999 was a DBA. I was an intern and then junior focused on the Oracle and Informix database and optimization of the systems and storage. Basically the Unix sysadmin who grokked database.
We had 8 people on that team. The entire scope of what we did for a living was replaced, mostly by 2010 or so. My role was made redundant by improving storage performance and capacity. We had a few TB and lots of blob data. I cared about where data was stored from a disk geometry perspective. Today, I could smoke that infrastructure with my MacBook.
The other DBA roles also mostly moved on. ORMs automated a lot of schema work. Engine optimizations eliminated a lot of the operational tuning work that went on. Most of the other stuff moved into adjacent developer roles.
Most places have very few DBAs today. That startup today would have had zero.
I think the author is being way too hard on himself. He defined a problem, worked with the computer to “scratch the itch” presumably QA’d the result and sent it upstream. That’s valid and useful. The method is different. But the work is solving the problems - and just like crazy kids solved problems with VisualBasic and the real men wielding C++ shook their heads, the AI tools are going to produce alot of shit, but also solve alot of problems.
A good mental model for what we do in the IT industry ever since it came into existence is automating things that feel repetitive and uncreative. Drudgery is a thing where for whatever reason technology falls short and you have to do tedious manual work.
AI tools remove drudgery at an unprecedented rate. My favorite new way of creating new projects is 1) create empty directory. 2) point codex at it and give it some example git repos (on disk or by url) and tell it use that repo as a template, copy some features/skills from that repo over there, and then build me an X.
That completely wipes out the drudgery of setting up a new project, fiddling with whatever to get it just right and doing a bunch of work to get some basic mvp in place. You kind of hit the ground running 5 minutes into this. Same with debugging. "CI failed, check what happened and fix it". Or "Follow the release skill and cut a new release". I have a skill dialed in to do a lot of checks around that; it also follows CI to ensure things go ahead as planned. All stuff I used to do manually.
LLMs have changed completely the time economics of coding. Things that in the past you would never touch because they would not worth the time investment of yours, today can be almost be done in one shot by LLMs.
I built a TV OS slideshow app for both photos and videos (as far as I know all the apps just go through photos).
I have no experience in Apple OSes development and in the past it would had taken me at least a week to just read enough documentation to get started.
Now? It took me 3 hours of iterating with an LLM to start from scratch developing and publish the app.
I feel similarly to the author, and I appreciate the links to other authors with similar sentiments - "hirirng a taskrabbit to solve a puzzle" or "feeling nothing about the results". I don't enjoy using LLMs, and I'm sad that it feels like we are a shrinking minority of programmers. It feels like a growing gulf that I increasingly don't want to try and reach across - I do not have fun with this tool, and I don't really want to hang around somewhere people are frequently pedaling it.
At the very least the change has made me reduce the amount of time I spend here. But I'm still a bit bummed about it.
Farming is a funny example to use, given that it's one of the best examples of an industry that's continually revolutionized by evolving technology. Farming today is about owning the best tractor.
It's the difference between lovingly crafting heirloom tomatoes in small batches vs producing a consistent multi-ton quantity of tomatoes at an industrial scale.
There are uses for both, but job/compensation wise the heirloom grower isn't in the majority.
chefs use produce to create dishes of food; chefs do not generally grow their own food. the point they were making is that the code is actually the means to the end, not the end in itself. to wit: i do not write assembly.
I am learning more than before. It helps me build things faster. You can still make it robust, efficient, crafty, etc. You have to improve your AI-assisted coding knowledge to achieve all those things.
It seems like the author feels like a fraud because they successfully made a contribution without learning anything.
The quality of a contribution is not a function of how much you learned or grew while you made it. Learning and growth are part of your compensation for making the contribution. The author is not a fraud for not learning anything. If anything, it seems like they should feel short-changed!
When voluntarily making contributions to open-source projects, everyone should of course feel free not to use AI tools if they want. However, I would argue that using AI tools is a valuable skill itself, and worth practicing.
I am not sure why the title got truncated from 'I Created My First AI-assisted Pull Request and I Feel Like a Fraud', which conveys a very different impression, and makes more sense when browsing the comments here.
Part of why I originally picked programming as a profession is because it felt like a way to get paid to be more of an artisan craftsman. Ultimately, I don't think it was ever quite that, even before ai.
But now post LLM coding agents, its not at all that. Nothing about programming for money resembles artisanship.
It might be time to try sewing wallets or something...
At the end of the day, the shareholders care about delivering features, gaining customers, and making money. They don’t care how software is built.
They absolutely do care how software is built. They just don't weight the factors the same way you do.
Product companies exist to convert software into money by providing utility to users. There's really no part of the transaction that meaningfully involves how much fun you're personally having building it.
By every account I’ve seen, Steve Jobs cared that the users of the product were having fun. He did not care at all how much fun the people building the product had.
They care about outcomes. I don't know that you're going to be able to draw an especially compelling line to programmer excitement and fulfillment and any of those outcome factors, though.
I love the description of the PR. This type of honest statement is the right thing to do - be transparent, be respectful of the time of the reviewer.
> This PR adds support for embedded Ruby (ERB) which is commonly used in Ruby on Rails projects. Note that I used heavy assistance from Claude Code and tried to ensure it didn't generate slop to the best of my abilities. All tests are passing and I also visually verified the end result which looks solid to me.
> Here's a screenshot that was generated by building the Chroma CLI with the ERB lexer and running it against the test data file with chroma --lexer=erb --style=monokai --html lexers/testdata/erb.actual
> I didn’t learn anything. I felt like I was flinging slop over the wall to an open-source maintainer.
Well I’m sorry you feel that way, impostor syndrome is tough to deal with already without AI.
You seem to be driven by understanding and you have a great tool to learn from here if you make an effort over time to grasp the “slop” you’re throwing to the wall. Be curious, ask why several times and explore guilt free over time when you are in the right mindset.
I’m glad you got something useful out of it this time and also not everything you do with AI has to be useful or a final “deliverable”, it can also be a great toy and window into more understanding.
my advice for anyone in this situation - as the next step. work with claude to understand the context surrounding the change, and how it fits into the existing project. do a deeper dive into whether the change causes a performance regression, see if it's stylistically consistent with similar code, probe whether there is code duplication that you could clean up by pulling out a function. claude can absolutely help with all of this! and at the end of all that, read through the generated code with a fresh understanding of it, and see if you agree with how it was done or whether you might prefer anything to be changed.
you will get a proper sense of ownership and of at least having put some work into not delivering slop, though of course there might still be subtle issues that only the people familiar with the codebase would catch.
When I read stuff like this, I get concerned about how big the knowledge gaps for some people really are. How crazy is the time pressure that reviewing the code is a big deal? What is there to "learn"? That's not what code review is about.
As long as you understand it before committing, you own your version of it now. There's no way in hell I'd waste time playing the slot machine. I am perfectly capable of writing the exact missing parts I need to integrate and move on quickly. How is this any different from SO copypasta a decade ago? Just like that wasn't always the right tool for the job, neither is "AI".
This sounds like a completely different problem than AI usage itself. My time is most valuable making decisions for the project. Yes, the vast majority of those decisions involve the code for the implementation details, but I just need clean simple code that does the job and that anyone or anything can easily change later. The AI doesn't always give that to me, and sometimes neither do other humans. That's why I'm employed. That's what it really means to be a maintainer and contribute.
Programming will become like knitting. You buy most of your cloth of the shelf, but there is a quality to a hand made pullover, well you wouldn't want to wear it, but you love to make it.
> I have never felt like a bigger fraud in this field
I'm the most senior software developer in my company and I sit in the middle of the room with my screens open to everyone, and I use 10x the average tokens. I've felt like an imposter when I was barely measuring up against the intellectual giants in my first jobs. It's a feeling, and it has nothing to do with you, your work, or your automation tools.
Secrecy leads to bad patterns of practice. AI doesn't make good programmers bad, or bad programmers good.
Addressing the lack of fun:
> I’m privileged that I get to have fun at all in my line of work
> this has sucked out all of the fun
Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code.
This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
There are aspects to your style of craftsmanship that the AI hasn't encoded yet.
I choose to embed those in templates and agent skills, but you can also just keep writing that code yourself.
Addressing productivity:
> I would not have the mental capacity or skill to create a pull request like that without AI tooling
> Now that using AI is a normal expectation at work and how I’m evaluated in performance reviews, I suspect that this fraud feeling will only grow
I think that's why using it is so unavoidable: It does increase productivity and lowers cognitive strain, at the cost of yolo.
I don't know if "fraud feeling" is referring to your impostor syndrome, and you want to get rid of this: deal with the feeling, it's just part of your growth as a person. Or if you're using fraud as a loaded term to devalue AI use in programming for ideological reasons: Can't help here, I don't have a problem with it.
Addressing craftsmanship:
> no matter how big the impact, I feel empty
> I still contributed something of value
> I perhaps tied my identity too much to my career
> I’m not the greatest engineer, but I’ve always worked hard
> I care about the craftsmanship of my code
Your interest in the details of your craft will disappear eventually.
Keep it up as long as you care, it's fun.
When you're ready to see yourself as something else, it will naturally fade.
I've been an aspiring team lead without a team for a long time. Now I have a team of robots (and incidentally a team of people), and it feels natural. I still code in my spare time, but not for productivity, only when I have to or when I want to have fun.
For me, I've slowly switched to wanting things to exist rather than wanting to make them. That helps swallowing that I don't code as much any more. (I mean, I still recreatively code 2-3 hours per day, but it's far from the 8-16 hours that have been the norm in my life.)
If it helps: It is probably good for your physical well-being that you don't have to sit hunched over as much.
> Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code.
> This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
Use AI-assisted coding to MVP or vertical slice or however you want to call it. Prove that it works and is doable. Now you have baseline to start editing from, rewrite every single line, even the ones with just a single { if that's how you roll.
Or read it and ship it as is. Maybe adjust the agent's instructions and the project linters/formatters to match your specific style better.
This is the wrong way to think about tool use.
You wanted this feature for years. You understood the problem, but the amount of time that it would have taken to properly implement and test it held you back from doing it. Obviously, anyone else who wanted this feature came to the same conclusion.
This new tool reduced the amount of time that it would take. So you used the tool. You used the tool to bring the feature into existence, checked the tests, and took enough time to ensure that it was good. You didn't lie about your contribution in the PR, and the maintainer deemed it acceptable. And now everyone has this feature!
When you eat a strawberry do you feel like an impostor for not growing it yourself?
I'd like to adjust your metaphor.
As a woodworker who owns both hand tools and power tools, I don't feel bad when I spend most of a project cutting the repetitive pieces with a motorized saw. I also don't feel like a snob because I prefer certain hand saws under certain circumstances.
To me, the metaphor is pretty solid for coding LLMs. A motorized saw, to anyone that's used them, takes away all the pain and complexity of using a hand saw for the same work, but it also introduces its own complexity and pain. There's also things that stay consistent: I still find myself transferring or measuring certain ways, I still have to brace the piece, I still need jigs (albeit different ones).
> When you eat a strawberry do you feel like an impostor for not growing it yourself?
No, but if I asked an intern to eat it for me, I wouldn't feel like I did anything or experienced anything at all.
That's what LLM coding feels like--like I'm not doing anything meaningful. It's like hiring someone to love my kid for me.
> No, but if I asked an intern to eat it for me, I wouldn't feel like I did anything at all.
That's a poor analogy.
If I asked an intern to implement a function, I know I did the instruction and that I worked through them. The intern did work, but I did fancy high level work and killed several birds with one stone.
Even better analogy: if I'm a film director, I'm working through a lot of people. The DP, the cast, the crew, the AD (though they're my boss, telling me what I can/can't budget for)...
The best analogy for AI is the "film director" analogy.
There are good directors and bad directors, good films and bad films. No director works alone (unless it's some kind of avant-garde film school project).
You wouldn't say a film director isn't doing work. That they can't be uniquely felt through their work. That what they're doing isn't hard, doesn't require talent/taste, and doesn't get better over time.
We're all basically becoming film directors.
So yeah, our job that we were all interested in has transformed into a different thing (directing), which some people are also interested in, and some aren't.
There's no substantive difference between directing an intern and directing people on a movie, by the way, except the number of people. If you never aspired to direct people, it's all kind of the same, and if you actively dislike it, I imagine directing more people would probably be worse!
Directors do work, but a different kind of work. Not really what most people would consider hands-on filmmaking. They're more like managers--telling others what to do, how to light this, how to shoot that, where the characters should be. It's work but it's not "making." If I want to make a film, I'm going to grab a camera and point it at something. If I wanted to tell other people to make a film, I'd become a director.
That's the major difference I feel between writing code and having an LLM do it. We're all being asked to become directors when we just want to make movies.
Making movies is hard. Ai basically made the smaller personal sized things easy, but substantial projects are still out of reach. There isn't anything for an individual to feel good about.
We grew tomatoes last summer. Over the last 2 years, something about tomatoes (and BLTs in particular) really clicked for me; we'd grown tomatoes many previous summers, and I could give a shit, but last summer I cared a lot about our home-grown tomatoes.
And I totally did feel less good about BLTs I made with supermarket heirloom tomatoes!
It was irrational, but I did feel that way. I get where people are coming from.
It's not irrational at all! The act of doing something yourself brings inherent pleasure and satisfaction, whether that thing is "growing tomatoes" or "coding a feature". It makes us feel useful.
try these varities
Cherokee Purple. Black Krim Black from Tula. Brandywine heck, Almost any black tomato is a richer flavor than traditional hybrids.
Heirloom tomatoes are also fantastic for flavors, but they are difficult to grow. Consistent watering, pruning lower leaves to keep disease away, proactive treatment of fungus and bacteria. It's a lot of work, but the results you get when it all comes together, yeah, it makes a fantastic tomato soup, sauce, Caprese salad.
I'm starting seedlings this week. I'm probably going to have more tomato seedlings than I know what to do with. Of course, as problems go, I could have worse ones. The problem I'd like to have is growing too many mini watermelons. For some reason, I just can't get any yield, and the squirrels/mice gnaw on them as soon as they are vaguely ripe.
My partner is not going to be happy when I rip up most of the lawn in the backyard. She'll probably buy me overalls and a straw hat.
We did Cherokee Purples (like everyone else), Buffalo Suns, and Indigo Roses.
The Buffalo Suns were great, by the way.
Hot take: We mostly eat garbage tomatoes.
"*A BLT is a tomato sandwich, seasoned with bacon.*
It wasn't until I tasted my first great tomato, at the vine-ripe old age of 22, that I finally understood the true nature of the BLT (and, by extension, why I'd never enjoyed tomatoes on my sandwiches or in my salads). Here we go: A BLT is not a well-dressed bacon sandwich. A BLT is a tomato sandwich, seasoned with bacon. From this basic premise, all else follows."
https://www.seriouseats.com/ultimate-blt-sandwich-bacon-lett...
yes, American tomatoes are generally terrible
source, am Romanian.
If you buy the variety most often found in American grocery stores (usually labeled as Roma tomatoes), they're terrible. Try the variety labeled as "tomatoes on the vine" (four-digit produce code 4664, which I know from memory, having punched it in to so many self-checkout scanners over the years). They're actually juicy and tasty the way tomatoes should be. Avoid Roma tomatoes, they're cardboard masquerading as a tomato.
"Globe" tomatoes are much, much more common as generics in American supermarkets. Sometimes also "Beefsteak" variety. Roma tomatoes are almost exclusively used in making sauce.
Roma are not the “normal” tomatoes sold fresh in American grocery stores.
What are they called, then? Since I took a job overseas over ten years ago, I haven't been in American grocery stores much. What's the "normal" variety called? I distinctly remember Roma being the cheapest, and also worst-tasting, variety, and learned to buy the "on the vine" style instead, but those are the only two that stuck in my memory. What is the one I'm forgetting about?
"Beefsteak" tomatoes are perhaps the most common (and the worst).
Roma have...some flavor. Campari (the ones on the vine) and cherry/grape tomatoes are better, but still mediocre.
With my preferred ratios, I always considered a BLT to be a mayo sandwich seasoned with bacon and some added veggies to pretend to be healthy :)
I mean, I'm not much of a gardener, but Erin sure is, and I had a direct basis for comparison. Our tomatoes were better, but the supermarket heirlooms were perfectly cromulent.
I think the key is just to make sure you're buying them in season, and that they didn't travel far.
I won't lie, came here expecting to hate on AI, stayed for the awesome discussion on tomatoes.
Believe me, I came here expecting to dunk on AI-haters, not talk tomato talk.
Yes. I didn't know or understand why I felt meh about run-of-the-mill raw tomatoes this until the Kenji article.
"Using mealy, off-season tomatoes is the primary unforgivable sin, but when it comes to BLT crimes, that's just the tip of the iceberg lettuce.
...
Off-season tomatoes are grown in warmer climates, picked when underripe, then treated with ethylene gas (a gas that is naturally produced by plants to trigger ripening in fruits) to produce their red color before they hit supermarket shelves. The result is tomatoes that are as bland as they are ruby-red.
Truly great tomatoes must be fully ripened on the vine, where they'll continue to develop flavor and sweetness. Look for plump tomatoes, with the heft and give of a water balloon. If you have a choice, look for substantial and meaty heirloom varieties with balanced sweetness and acidity, like Cherokee Purple or Brandywine.
Avoid tomatoes that feel light for their size, which means they have more air pockets inside and are typically better for saucing or salads."
> When you eat a strawberry do you feel like an impostor for not growing it yourself?
I don’t think this is the right question. What you posit is a consumption dilemma. It’s a valid question, but it focuses on what values we might arbitrarily ascribe to how we source what we consume.
The OPs dilemma is more akin to giving a cutting board for Christmas that you bought vs handmade. Or some other. I think these cases of how we present what it appears we created is the dilemma OP is facing.
Except, calling it a "tool" is exactly why OP feels bad. Simply phrasing it another way, I.E. "OP paid for a service to implement a feature he wanted," would completely remove the guilt and be more technically accurate.
IMO, the way we talk about using AI leads to a lot of confusion and needs to change.
Have you tried just not feeling depressed?
If I picked it up from someone else's garden without permission then yeah.
i like the exosuit analogy..
if you cant lift something because its heavy, but have an exo suit that will let you lift it... does that make you feel like a fraud?
AI is like that its a tool. you;re still responsible for the use of it and the output of it. you need to understand that if you use that exo suit to hurt someone or use it poorly and damage something/someone.. thats entirely on you. just like a knife in your hand is a tool to prep food or to attack someone. your actions with it are on you.
No need to invent a fictional exosuit. We already have real machines that augment our physical abilities like cars and excavators and such
Anyways, you ever seen the average excavator pilot? They're often very physically unhealthy
I predict the average LLM pilot will be similarly mentally unhealthy
The blog post discusses this point directly. Did you read it?
What makes you think they didn't read it? The comment is a direct response to the blog post. They just think the post is wrong.
Disagreement != Lack of understanding.
Yeah I mean, now you know how managers feel? :)
spend all day talking to people (except it's LLMs) and not sure if you accomplished anything, but people seem happy
The plus side is for your personal things like this you don't have to use it of course!
Last year I got two coworkers. My first in terms of coding. First I looked at everyone code request, but it soone overwhelmed me. We got a third and there was no way I could oversee everything and since I got a team of three management gave me other responsibilities on top.
I have no idea what they code and how they code it. I only go over the specs with them. Everything got quicker but the quality went down. I had to step in and we now have e2e-Test for everything. Maybe it's too much, but bugs got squashed and catched before we shipped.
So that's a win. Before I could test everything by hand. I worked more on things like creating a working release cycle and what tools we should use.
With or without AI the situation would have been similar.
I became a manager. We move the needle. I don't really get to code anymore and I don't see much of the code. It's strange.
Article addresses that.
Author says he does enjoy managing people, challenging them, and seeing them grow and accomplish things they couldn’t before.
None of that accompanies “managing” an LLM.
My perspective on this is that my first real job in 1999 was a DBA. I was an intern and then junior focused on the Oracle and Informix database and optimization of the systems and storage. Basically the Unix sysadmin who grokked database.
We had 8 people on that team. The entire scope of what we did for a living was replaced, mostly by 2010 or so. My role was made redundant by improving storage performance and capacity. We had a few TB and lots of blob data. I cared about where data was stored from a disk geometry perspective. Today, I could smoke that infrastructure with my MacBook.
The other DBA roles also mostly moved on. ORMs automated a lot of schema work. Engine optimizations eliminated a lot of the operational tuning work that went on. Most of the other stuff moved into adjacent developer roles.
Most places have very few DBAs today. That startup today would have had zero.
I think the author is being way too hard on himself. He defined a problem, worked with the computer to “scratch the itch” presumably QA’d the result and sent it upstream. That’s valid and useful. The method is different. But the work is solving the problems - and just like crazy kids solved problems with VisualBasic and the real men wielding C++ shook their heads, the AI tools are going to produce alot of shit, but also solve alot of problems.
A good mental model for what we do in the IT industry ever since it came into existence is automating things that feel repetitive and uncreative. Drudgery is a thing where for whatever reason technology falls short and you have to do tedious manual work.
AI tools remove drudgery at an unprecedented rate. My favorite new way of creating new projects is 1) create empty directory. 2) point codex at it and give it some example git repos (on disk or by url) and tell it use that repo as a template, copy some features/skills from that repo over there, and then build me an X.
That completely wipes out the drudgery of setting up a new project, fiddling with whatever to get it just right and doing a bunch of work to get some basic mvp in place. You kind of hit the ground running 5 minutes into this. Same with debugging. "CI failed, check what happened and fix it". Or "Follow the release skill and cut a new release". I have a skill dialed in to do a lot of checks around that; it also follows CI to ensure things go ahead as planned. All stuff I used to do manually.
LLMs have changed completely the time economics of coding. Things that in the past you would never touch because they would not worth the time investment of yours, today can be almost be done in one shot by LLMs.
I built a TV OS slideshow app for both photos and videos (as far as I know all the apps just go through photos).
I have no experience in Apple OSes development and in the past it would had taken me at least a week to just read enough documentation to get started.
Now? It took me 3 hours of iterating with an LLM to start from scratch developing and publish the app.
I feel similarly to the author, and I appreciate the links to other authors with similar sentiments - "hirirng a taskrabbit to solve a puzzle" or "feeling nothing about the results". I don't enjoy using LLMs, and I'm sad that it feels like we are a shrinking minority of programmers. It feels like a growing gulf that I increasingly don't want to try and reach across - I do not have fun with this tool, and I don't really want to hang around somewhere people are frequently pedaling it.
At the very least the change has made me reduce the amount of time I spend here. But I'm still a bit bummed about it.
I hear you. If you find any other places to hang out that aren't busy hyping AI constantly, let me know please?
When you realize that being a great "programmer", isn't about writing the most code, but getting the job done...
AI will click as another tool in the toolbox.
In much the same way that buying produce makes you a great farmer.
Farming is a funny example to use, given that it's one of the best examples of an industry that's continually revolutionized by evolving technology. Farming today is about owning the best tractor.
It's the difference between lovingly crafting heirloom tomatoes in small batches vs producing a consistent multi-ton quantity of tomatoes at an industrial scale.
There are uses for both, but job/compensation wise the heirloom grower isn't in the majority.
no, it makes you a great chef
I believe you reinforced the point.
I think you missed the point.
produce : chef :: code : programmer
chefs use produce to create dishes of food; chefs do not generally grow their own food. the point they were making is that the code is actually the means to the end, not the end in itself. to wit: i do not write assembly.
This may be more correct than you know. Chefs actually don't cook food customers eat. They plan the menu and manage the operations. The cooks cook.
They know how to cook and can if needed, but usually don't bother as they have 15 other restaurants to manage.
No, I understand the point, it means that people drawing the analogies don't understand the original intent was production, not consumption.
I think being a great "software engineer" at a company is about getting the job done. A great "programmer" is about designing and writing great code.
Its hard for me to disagree more, being a great programmer is completely orthogonal to how fast you "get the job done."
I am learning more than before. It helps me build things faster. You can still make it robust, efficient, crafty, etc. You have to improve your AI-assisted coding knowledge to achieve all those things.
It seems like the author feels like a fraud because they successfully made a contribution without learning anything.
The quality of a contribution is not a function of how much you learned or grew while you made it. Learning and growth are part of your compensation for making the contribution. The author is not a fraud for not learning anything. If anything, it seems like they should feel short-changed!
When voluntarily making contributions to open-source projects, everyone should of course feel free not to use AI tools if they want. However, I would argue that using AI tools is a valuable skill itself, and worth practicing.
I learn a lot from code I read, but don’t write. Did the author not read the code and simply threw it over the fence?
I am not sure why the title got truncated from 'I Created My First AI-assisted Pull Request and I Feel Like a Fraud', which conveys a very different impression, and makes more sense when browsing the comments here.
Part of why I originally picked programming as a profession is because it felt like a way to get paid to be more of an artisan craftsman. Ultimately, I don't think it was ever quite that, even before ai.
But now post LLM coding agents, its not at all that. Nothing about programming for money resembles artisanship.
It might be time to try sewing wallets or something...
At the end of the day, the shareholders care about delivering features, gaining customers, and making money. They don’t care how software is built.
They absolutely do care how software is built. They just don't weight the factors the same way you do.
Product companies exist to convert software into money by providing utility to users. There's really no part of the transaction that meaningfully involves how much fun you're personally having building it.
"There's really no part of the transaction that meaningfully involves how much fun you're personally having building it."
Funny. Steve Jobs was all about fun. Seems to have worked out well given Apple has maintained much of the culture Steve left behind.
> Steve Jobs was all about fun
By every account I’ve seen, Steve Jobs cared that the users of the product were having fun. He did not care at all how much fun the people building the product had.
It's well documented that people enjoyed working at Apple under Steve - pain and pleasure come together when working on stuff that's insanely great.
If your idea of fun is doing no work then you're delusional.
Now that we're here, it should also be noted Steve did not make decisions based on 'maximizing shareholder wealth'.
Rather doing the right things on the top line (creating great products and telling people about them), the bottom line would follow.
Thats the difference between a visionary CEO and a bozo-CEO (enter Zuckerberg, Nadella et al).
I think you may be caught in the distortion field.
Well they also care to a certain extent because how something is built has a direct impact on the output as well.
They care about outcomes. I don't know that you're going to be able to draw an especially compelling line to programmer excitement and fulfillment and any of those outcome factors, though.
I'm agreeing with the other person that they do care about how it's built, not that they care about how much fun the programmers are having...
I love the description of the PR. This type of honest statement is the right thing to do - be transparent, be respectful of the time of the reviewer.
> This PR adds support for embedded Ruby (ERB) which is commonly used in Ruby on Rails projects. Note that I used heavy assistance from Claude Code and tried to ensure it didn't generate slop to the best of my abilities. All tests are passing and I also visually verified the end result which looks solid to me.
> Here's a screenshot that was generated by building the Chroma CLI with the ERB lexer and running it against the test data file with chroma --lexer=erb --style=monokai --html lexers/testdata/erb.actual
> I didn’t learn anything. I felt like I was flinging slop over the wall to an open-source maintainer.
Well I’m sorry you feel that way, impostor syndrome is tough to deal with already without AI.
You seem to be driven by understanding and you have a great tool to learn from here if you make an effort over time to grasp the “slop” you’re throwing to the wall. Be curious, ask why several times and explore guilt free over time when you are in the right mindset.
I’m glad you got something useful out of it this time and also not everything you do with AI has to be useful or a final “deliverable”, it can also be a great toy and window into more understanding.
my advice for anyone in this situation - as the next step. work with claude to understand the context surrounding the change, and how it fits into the existing project. do a deeper dive into whether the change causes a performance regression, see if it's stylistically consistent with similar code, probe whether there is code duplication that you could clean up by pulling out a function. claude can absolutely help with all of this! and at the end of all that, read through the generated code with a fresh understanding of it, and see if you agree with how it was done or whether you might prefer anything to be changed.
you will get a proper sense of ownership and of at least having put some work into not delivering slop, though of course there might still be subtle issues that only the people familiar with the codebase would catch.
When I read stuff like this, I get concerned about how big the knowledge gaps for some people really are. How crazy is the time pressure that reviewing the code is a big deal? What is there to "learn"? That's not what code review is about.
As long as you understand it before committing, you own your version of it now. There's no way in hell I'd waste time playing the slot machine. I am perfectly capable of writing the exact missing parts I need to integrate and move on quickly. How is this any different from SO copypasta a decade ago? Just like that wasn't always the right tool for the job, neither is "AI".
This sounds like a completely different problem than AI usage itself. My time is most valuable making decisions for the project. Yes, the vast majority of those decisions involve the code for the implementation details, but I just need clean simple code that does the job and that anyone or anything can easily change later. The AI doesn't always give that to me, and sometimes neither do other humans. That's why I'm employed. That's what it really means to be a maintainer and contribute.
I feel like I need to build a rocket ship or something something to feel like I programmed something cool and feel good about it.
Programming will become like knitting. You buy most of your cloth of the shelf, but there is a quality to a hand made pullover, well you wouldn't want to wear it, but you love to make it.
Wait till you hit your 1000th. And its not just "assisted" but lock stock and barelled!
Addressing the self-deprecation:
> I felt like I was flinging slop over the wall
> my impostor syndrome got worse
> thanks for dealing with my slop, Alec
> I have never felt like a bigger fraud in this field
I'm the most senior software developer in my company and I sit in the middle of the room with my screens open to everyone, and I use 10x the average tokens. I've felt like an imposter when I was barely measuring up against the intellectual giants in my first jobs. It's a feeling, and it has nothing to do with you, your work, or your automation tools.
Secrecy leads to bad patterns of practice. AI doesn't make good programmers bad, or bad programmers good.
Addressing the lack of fun:
> I’m privileged that I get to have fun at all in my line of work
> this has sucked out all of the fun
Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code.
This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
There are aspects to your style of craftsmanship that the AI hasn't encoded yet.
I choose to embed those in templates and agent skills, but you can also just keep writing that code yourself.
Addressing productivity:
> I would not have the mental capacity or skill to create a pull request like that without AI tooling
> Now that using AI is a normal expectation at work and how I’m evaluated in performance reviews, I suspect that this fraud feeling will only grow
I think that's why using it is so unavoidable: It does increase productivity and lowers cognitive strain, at the cost of yolo.
I don't know if "fraud feeling" is referring to your impostor syndrome, and you want to get rid of this: deal with the feeling, it's just part of your growth as a person. Or if you're using fraud as a loaded term to devalue AI use in programming for ideological reasons: Can't help here, I don't have a problem with it.
Addressing craftsmanship:
> no matter how big the impact, I feel empty
> I still contributed something of value
> I perhaps tied my identity too much to my career
> I’m not the greatest engineer, but I’ve always worked hard
> I care about the craftsmanship of my code
Your interest in the details of your craft will disappear eventually.
Keep it up as long as you care, it's fun.
When you're ready to see yourself as something else, it will naturally fade.
I've been an aspiring team lead without a team for a long time. Now I have a team of robots (and incidentally a team of people), and it feels natural. I still code in my spare time, but not for productivity, only when I have to or when I want to have fun.
For me, I've slowly switched to wanting things to exist rather than wanting to make them. That helps swallowing that I don't code as much any more. (I mean, I still recreatively code 2-3 hours per day, but it's far from the 8-16 hours that have been the norm in my life.)
If it helps: It is probably good for your physical well-being that you don't have to sit hunched over as much.
> Split your coding in two: The part that gets done quick, and the part where you personally care about every line of code. > This was always a problem with commercial programming for me: Employer only cares that it gets done, I care that it's good. The tension is necessary.
Use AI-assisted coding to MVP or vertical slice or however you want to call it. Prove that it works and is doable. Now you have baseline to start editing from, rewrite every single line, even the ones with just a single { if that's how you roll.
Or read it and ship it as is. Maybe adjust the agent's instructions and the project linters/formatters to match your specific style better.
Ya its a shitty feeling
[dead]
[dead]
[dead]
I just typed this in and hit send. I feel like a fraud.