It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.
Remembering and understanding aren't the same thing. Merely reciting facts doesn't automatically give you the ability to apply those facts to solve problems.
Respectfully, unless someone is really really bad at articulating what the quality standards are or works with a very niche stack that is definitely not the case anymore with SOTA models
Respectfully, the current models are all trained on everyone else's legacy code as of roughly six months ago and largely always will be. If I'm doing my job right an LLM cannot meet my personal quality bar on its own because I will always need innovation and excellence they will never see and thus cannot deliver. I also think that training these tools on my personal quality bar is more work than just writing it myself.
True innovation is doing something new that has never been seen before. Even if you are doing it in a stable language that's just a stable poetry form (rhyme and meter and formatting), the real magic is the content of the poetry, and the real beauty of code is when the poetry reads well to both audiences, the compiler and the next maintainer, on multiple levels, the literal and the metaphorical.
LLMs can't reach the metaphorical. LLMs don't know what true beauty is. I will grant you they have gotten great at the literal and the poetry forms. But it is the beauty that elevates things to my quality bar, and makes a difference between "legacy code" and "innovation" to me.
What you're describing is not innovation in the business sense but some kind of experimental art. Software engineering is not art as the name suggests - it's a craft, even though there's a self-expression component to it.
I think we have different definitions of what a craft is. My boundary between art and craft is a lot looser, for instance. The way I see it there is craft to the best art and there is art embedded in the best craft. I think you are right that companies seem to ignore both the art and craft of software engineering and long wish the process were a predictable industrial machine much more than an art or a craft. But I will absolutely disagree with you that just because companies desire it to be an industrial process doesn't mean it isn't my job to understand the art of software design and how that influences the crafting of software.
LLMs are plenty innovative and generate good quality code by default, and great quality code when directed well.
If you're not seeing this, at best you're probably unable to direct them or use them well.
FWIW, if you don't believe the above, I challenge you to put up a quick git repo, where you are unable to get the deserved quality out, and we can quickly show you how the same quality is available via SOTA agents, within a fraction of hand-coded time.
You're presuming too much about what OP's quality standards are. Can SOTA models outperform the average junior engineer? Yes, obviously. Can they match the best human engineers, if those humans were given all the time and interest in the world? Equally obviously not.
I use hundreds of millions of tokens a month, and LLMs have completely transformed the way I work. They're also, frankly, pretty mid programmers.
Yes, and? Something can be both scare and inadequate to a given task. FAANG L5s cost a pretty penny but I wouldn't trust a random one to prove a crypto library correct.
Number of people who i personally met and would entrust a crypto library to i can count on one hand. You're moving that goalpost at relativistic speeds now.
TL;DR — there’s a whole lot of craft in how you use agents
I think that’s mostly true, but also I think there is some skill to using agents well. Specifically, work with agents to get a really good product requirements document, then task it out into very narrow user stories / vertical slices (this takes some iterating—the AI really seems to want to think in horizontal layers today), then maybe walk through the code interfaces to be super sure you are aligned. At each step, I make the agent interrogate me thoroughly with every question it can think of, and even if we stop now we will have a system design and tickets that are much higher quality than me thinking alone. I could hand those off to anyone to implement, but I think having an agent TDD their way through the code is the sweet spot.
Whenever the agent is doing something I don’t like (e.g., some coding style thing), I pause and have another agent help me write a style guide that agents must read. This slows me down at first but I think it will pay off in time.
Yeah, I can't help but chuckle when people say "Well, humans make mistakes, too".
That's what we're spending 7+ TRILLION dollars, destroying ecosystems to build datacenters, and ruining society's social contract on truth and employment for? To build something that produces the average quality of a human, all while making the same types of mistakes along the way?
This is precisely why these types of articles don't make any sense to me, and strike me as case studies on human laziness. If you want good output, you'll review the output and iterate. If you want good foundations, you'll write them, and then later those foundations will prevent, to a very great degree, bad code from getting written by the LLM.
These articles frustrate me greatly. That said, the author's point about token cost is real, and a risk.
>Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write
Yeah, but in my experience, it takes the same amount of time or longer to cajole the AI to get it there. I'd rather write it myself and know how it works than insert an LLM as the middleman, especially when it isn't really proving to be any faster.
In my experience, it sure saves time. a lot of quality has significant mechanical components LLMs do great. Hey, this series of 300 functional tests are reusing the same few patterns without helper methods clarifying intent. Give me an overview of possible meaningful methods that would simplify the duplication. Ok, 2, 4 and 5 are good, but rename 2 to X, and change the order of parameters in 5. Implement across the tests, and make sure it all passes.
Still very significant savings over all that rather mechanical work. It's ultimately cheaper than doing a code review, and it's faster, because there's less need to manage the emotional state of the person whose code is being reviewed. Maybe I am a slow developer or something, but I am getting a lot of quality changes like that done that before I'd not have, solely because of time spent.
And not increasing the quality just causes problems anyway. Given the same quality, more changes mean more outages than before, just by probability. Increasing rate of change demands a similar increase in quality if you don't want your production support costs to go up. So spending at least a bit of time on quality, letting the LLM do the nagging little things that before you didn't do beause they they took too long and were not a core part of quarterly goals is basically mandatory.
IMO it still does save time generally but it’s not as much of a huge gain if you’re doing this.
I will admit there are occasional times after iterating so much I’m not sure if I’ve even saved time because going from “it works” to “it’s up to quality” takes so long
I've run a few experiments where I give it well-defined small side projects where I have a good idea of what I would do and how long it would take, and I time the process from start to finish.
So far, it's been pretty underwhelming--on par or slower, and it's definitely more frustrating lol.
Honestly, the only killer feature I found so far is overcoming ADHD activation energy lol. Getting annoyed with the idiot robot screwing up the Terraform migration is apparently a good way to get me to finish a Terraform migration.
It saves so much time! Think of the best find and replace and autocomplete and macro and every other possible super tool you use and roll everything into one. The design phase of any significant feature pales in comparison to all of the (now fully automated) tasks that you can just hand off to the agent to do nearly instantly and perfectly.
Actually ignore my comment I misunderstood the premise. I meant not vibe coding is the way to save time with production issues. Not the other way around!
If you are coding by hand like the old days you are probably not literally writing everything from scratch anyway, you are copy pasting a bunch of shit off google and stackoverflow or installing open source libraries.
I also reuse a lot of my own code. Either from libraries I built or just directly copy pasting (like boilerplate code for setting up the basics of something in my style).
reply