I agree with this approach, but I'm a bit surprised this has to be said at all. These are basic software design principles and I imagine it's the default way any experienced programmer would approach the problem. I wonder if the people not using this approach are primarily junior developers who have never seen how real software is built, or if it's leaking into the senior levels as well.
Most people in the industry right now, even at FAANG and even among people carrying "senior" titles at these places, have little experience with "software design principles" -- tens of thousands of brilliant Ivy League graduates with surreal compensation packages have spent the last decade pulling tickets off JIRA and pasting least-change-possible patches onto existing code for about 10 hours a week while spending the other 30+ hours barely engaged at meetings.
This is maddening. I've been pulling 40/50/60 hour weeks for 21 years in the tech industry at various different companies. I haven't broken 200k base salary, though benefits are pretty great where I'm at. To think I could've memorized some leet code problems, got a job at FAANG and been making 300k base for the past 5+ years while working 10-hour weeks is - yep, maddening.
The best time to be aware of the socioeconomic class differences in tech was 20 years ago, the second best time is now. Also some folks just find it difficult to study leetcode problems purely to "prove" themselves, for various psychological reasons. If you can, it helps a lot, as does graduating from top universities with a direct pipeline into these companies. Social signalling is much more valuable nowadays than capabilities.
Sometimes the grass really is greener - company culture can be actually incredibly toxic and compensation very below market, but when surrounded by people who normalize it most folks will project that experience out to the rest.
Did you go to Stanford or a similar pedigreed college? Unless you did that or broke that 200k barrier already by getting high up in a lower tier company, just memorizing some leet code problems wasn’t going to get you into a FAANG.
They care a lot about prestige. Or at least did before AI. Don’t know what their current hiring practices look like.
Don't feel bad. It is not about skill in those job, it is about "cultural fit". You must project a personality that will fit in with FAANG culture or you won't get the job unless you're famous globally due to having starting some huge open source project.
Comfort yourself with the fact that you did not have to sell your soul, sit through endless woke sexual harassment videos where you are taught that the white man is the source of all evil, and in endless management meetings.
Why are you upset its this way elsewhere? Those kind of working conditions are much more favorable don't you think? Why would you want to work 60 hour weeks?
I think we passed the inflection point of the normal 150-500 Lear code problems, understand DSA and systems design really well. Personally, I think companies are much more selective now and have all reduced the size of their engineering orgs.
There’s always been a percentage of luck getting offers from big tech companies, but it’s way more luck than than merit it has ever been.
The majority of those who get in are able to socially signal, through affiliations with other high paying companies or paper from prestigious (read: socially exclusive) institutions.
This hurt to read but checks out in my experience. These types also tend to love tossing debt over silo'd walls and pointing the finger a lot if/when anything goes wrong.
I'm old enough now to be a protected class, so I don't want people accusing me of ageism, because that's not where this is coming from - but there's a type of person that clearly is on their last job of their career and knows it and I try to avoid them like the plague, I've seen it too many times.
Good philosophy. Don’t write code to show your own cleverness. Write code for the poor bastard who will eventually have to debug it at 2am while that outage timer ticks on and everyone keeps asking how much longer.
The code isn’t for you. It’s for them.
Of course, there’s also a chance you’ll be them. :)
The incentive structures are all fucked up. It's far more profitable for all parties involved to just slop out some barely maintainable bullshit that only just meets the product manager's criteria for external quality while completely neglecting the internal quality of the software [0].
By the time the system starts to experience strain under the weight of its technical debt two years later, the original tech lead/architect of the project has already added it to his resume as another bullet point, found a new job at 20% higher comp, and no longer has to ever look at that code, ever again.
Now it's the next asshole's problem. Good luck!
[0] Freeman & Pryce 2009 for the "internal quality" vs. "external quality" dichotomy
I think part of the problem is the original product manager has also added this as a bullet point on their resume and gotten promoted. They get to watch the dumpster fire from a safe distance.
The 30+ hours were often just goofing off/video games/porn, very few are in 30 hours of meetings. The amount of grift, non-work, fake work, etc that remote well paid tech workers get to do is absurd.
I work on my code this way, but I have no idea what my colleagues are doing, and it's impossible to review thousands of new/changed lines a week.
I just approve PRs, because I have to. I don't know what else to do. I can barely keep an eye on all my code.
Actively looking, but job market is rough in Northern Europe. I quit caring about quality in any capacity here, the company has clearly chosen its direction, against my very vocal complaints.
My last interview, with what I thought was a great company, failed when I didn't understand what NLP was when they asked me about it.
> NLP?
> Natural Language Programming, it's the future. Claude, GPT, etc.
I laughed, he didn't, looked offended and said it was a serious question. I had thought it was a joke, said "oh you mean LLMs". I tried to answer seriously, of course, but that was my third round technical interview and I didn't get a call back.
Just getting a paycheck and producing mediocre work until I get something new. (Senior engineer, 10 YOE, patents, 3 years at a unicorn).
I will be unhappy if they steal the meaning of NLP. NLP means Natural Language Processing and LLMs are only a subset of NLP. I would have concerns about anyone who claims to have technical knowledge and asserts NLP means "natural language programming." Those are the same kind of people who might suggest Lisp should add mutable objects.
Yes, but that's in psychology. Different fields have their own terms without causing too many issues. Communication breaks down when we reuse terms for different things within the same field.
They may not be related, but having a good understanding of the psychological NLP actually lends it self really well to NLP and prompt engineering. As much as a lot of people 'claim' it to be parapsychology (even within this thread), check out books like Strategies of Genius and how it breaks down a lot of the main concepts. It's very 'meta-cognition' if you will, but, the parallels are eye opening given how long the concepts have been around. If someone has never done serious mind mapping or brain storming and entity-node relationship type work with databases, it would be quite a leg up helping them understand and mentally map out concepts like that.
Same for "AI". LLM is about the only kind of AI we talk about now, so the two blended. Nothing dramatic I guess, but it bothers me when tech people, who are supposed to know the difference, confuse the two.
I'm in what I think will be my last tech job before retraining into something else. The aspects I like about the work are gone, I'm coasting at a small company that's not a great fit, has a visa cliff, and is poorly paid, and the steps it would take to become competitive in an LLM driven tech job market are less appealing to me than the steps it would take to switch over to a different career (likely in healthcare).
Good luck! I took the plunge last year and am just finishing up med school pre-requisites. I'd say at least 6/30 of my O Chem II class are former software engineers.
Thank you! I'm still in a very exploratory phase about what exactly I mean by switching into healthcare. I don't have prereqs done at all, and my current plan is to enroll in a second bachelor's next year and start working through bio and chem courses. I'm looking at a bunch of different options from nursing to PA school to medical physics, and I think I really need to start shadowing people in different professions.
Med school interests me, but I'm a woman in my late 20s who would like to have children, and if I started down the med school road now I wouldn't be done with training until my late 30s, where PA and nursing school don't have that problem. Medical physics is kind of in the middle.
Oh interesting. I was looking at bio-informatics briefly but never even considered medical physics. It's crazy just how big healthcare is and how ignorant I was to it prior to making the transition. Would agree that shadowing has a huge impact on determining what you want to do in the future. My cousin went the PA route over med school and honestly I think it's the best from an ROI and free-time perspective. In her early 30's now and every other weekend she's in a different country.
Understand completely. I'm a little older than you but the high chance of giving up a family was the first thing on the negative column when I was deciding paths.
Awesome! I'm taking prerequisite classes (probably for Physician's Assistant school) while picking up a few shifts at the local EMS station. Good luck on your journey!
literally in the same boat, gonna see if i can't use ai to build some products to make money and help people, or else i'll go into healthcare and make (significantly less) money and help people.
Yeah, I imagine it's something that needs to be enforced at the organizational level. I sympathize with anyone who takes pride in their work and needs to deal with mindless coworkers pushing slop without any accountability. I left corporate software development (before LLMs were a thing) over frustration with the general culture and I can only imagine it's gotten worse since then.
It's really bad now, yeah. :( It just really hurts that I spent well over a decade of my life learning and honing skills to engineer safe, quality software and now it's just, useless.
No one cares at best, or I'm callously told "keep up or fall behind" at worst. When that's not even the problem, it just, sucks now. There's no joy in anything I do professionally.
Can I ask where you went? I'm seriously looking for an exit, I just don't know what yet. Maybe a trade, in Scandinavia the pay is actually comparable, I just don't want to go back to school.
It just really hurts that I spent well over a decade of my life learning and honing skills to engineer safe, quality software and now it's just, useless.
It can feel that way with all the hype but I very much doubt that is really true. I see an industry that is rapidly dividing into two camps - "move fast and break things" and "this actually needs to work". Writing everything with agents and merging while barely even checking what is in the PR has become standard practice in the former but it will get you laughed out of the room in the latter.
I was fortunate and saved up enough to live frugally and just work on passion/learning projects for a while. I've been considering going back into commercial software development as a solo dev and leveraging AI, but keeping the focus on quality and craftsmanship. In my opinion there's never been a better time to start a new, ambitious project if you're passionate about quality software.
I agree, that's acutally what I'm doing right now: living frugally in a cheap country while building an ambitious high quality pruduct.
I never had a better time "professionally" (albeit no income yet!) so far in my whole life! Apparently it's truly like the best of times and the worst of times to be building software, if you have the luck and the luxury to be able to work only for yourself than it's really a great time to be alive.
Some people just can't turn off their brains and play drone for dozens of hours a week for decades. It feels existentially, aesthetically, and sometimes ethically crushing to spend a whole life doing work you can't expect yourself to respect or value, no matter how much you get paid or how little the work overtly demands of you.
Often, the lack of meaningfully challenging demands being put on you is punishing on its own. It can feel like a relief for a week or month or year, but if you catch a glimpse of that being your whole future, you can come to recognize yourself as being in a mind-eroding secular purgatory.
This anguish is especially common among on highly capable people, high achievers, and those used to some kind of ambition. And by accident of its history, there's a lot of those people in this industry and some of them are going nuts now.
Man, I have the same feeling.
A long time in your life you build the career and now it’s just feeling so empty, like you are not a engineer anymore, now everyone can use AI and without checking code they would have good results.
> now everyone can use AI and without checking code they would have good results
?!!?
No way. Are you sure? What kind of work? Here there’s still a lot of care needed to navigate the LLM work, like knowing when to make it quit, rewrite, refactor, follow your outline.
It feels magic but when I watch people who don’t know what they are doing trying to make something new (not almost a clone of an existing product), they get pretty frustrated.
I once lost out on 3 months severance and a laptop when I quit a place and they shuttered two and a half weeks later. There had been no direction from the top for over a month other than "ehh, do something useful". I was working remotely and slowly going crazy.
> This anguish is especially common among on highly capable people, high achievers, and those used to some kind of ambition. And by accident of its history, there's a lot of those people in this industry and some of them are going nuts now.
I went nuts for years, until I sold off my interest in my dream partnership.
10 years of heaven. All the benefits and none of the downsides of my internal colleagues. Then 14 years of bureaucracy aimed at predictability over progress, which was infinitely more difficult for me to dodge as an external player.
Compensation for my interest was very objectively valued, with the rate of stalled progress priced in. Which made complete sense, while also being its own madness.
I walked away from so much value, but I don't regret it for a minute.
This exact mentality is extremely toxic and is why the historical "anti-work" movements (i.e. Anarchists) have been kneecapped, often by their supposed best friends (i.e. Commies). The major disagreement circa the 2nd internationale was "is work good, but bad that you're exploited and not paid well?" (the Marxist view) vs "Work fucking sucks and we should abolish it" (The Anarchist view)
I can't believe how much mental justification needs to be made by otherwise highly intelligent people (Bertrand Russel wrote In Praise of Idleness) to defend the right to not work.
No, I fully reject any notion of life value coming from work, and those who hold your view are basically jailors to those who don't want our identity defined by work.
That's not how the world works, and I don't need this in a thread where I'm dealing with the grief of a good career. Please shove off.
I would gladly not work and learn cello and physics independently if that were a real possibility, but it's not, and it won't be within my lifetime.
I had a job in a system that required jobs to survive that genuinely didn't bother me. I actually quite enjoyed it most of the time. Now it's permanently dead and I need something else, or I am homeless and starve to death.
> No, I fully reject any notion of life value coming from work, and those who hold your view are basically jailors to those who don't want our identity defined by work.
Don't get me wrong, LLMs are way better than me at most things, but I don't think you can deny that the current generation of models makes questionable decisions sometimes. Especially on project structure, API boundaries, and code duplication. I also think they just have bad taste in general, though of course that's more subjective.
I’m not sure how to say this without sounding smug, but the last year has shown that most of those things just… don’t matter. It’s just the next level of the “variable naming PR comment battle”, so will become obsolete very soon.
Obviously there are mission critical systems where it matters, but if “your code can be A/B tested” or “slowly rolled out”, chances are, it doesn’t matter.
You'll find that design matters when token spend starts facing real accounting.
Tech debt is still tech debt, even if there exist models that can wade through, because it's going to require increasingly sophisticated models navigating increasingly large context windows and increasingly speculative workspace operations to keep making progress on it.
Vendors like Anthropic and OpenAI are laying a pit trap when they demonstrate how their models can independently code their whole platform as it becomes increasingly byzantine and inscrutable because not only do they benefit from internal/prerelease models but they have effectively unlimited spend because all that spending acts as a lure to draw you into their trap.
For everybody else, design still matters. People are just working really hard to make you forget.
Personally I think I could probably be content for the rest of my days running something like Z.ai glm-5.3-flash locally, so I'm not that worried about the token spending (and still can't understand how OAI/Anthropic/etc convinced the market they have any kind of moat to motivate those kind of evaluations, but that's another topic...)
That said, I also feel like betting on readability, maintainablility, taste, etc, being an important aspect of software, at least until code will remain some sort of human readable artifact. We'll still want to be able to understand it and perhaps occasionally add/edit by hand, make sense of it without trusting blindly what any kind of program (LLM based or not) will tell us about it, and so on.
The problem here is not the vendors.
The "problem" is that design mattered when producing code was a truly manual effort. Writing things down, aligning specs, design, contracts, all of that would mold what could come next.
Now ANY design from amazing to terrible can be regenerated and generated dozens of times over for literal single digit dollars.
Cost of tokens is NOT a problem unless you have a codebase with hundreds of person-years of effort. Not many people do.
Honestly, I keep hearing this argument, but the past 2 years have shown the opposite. OAI/Ant are not the only companies providing inference.
There are legitimate FAANG-like companies that have general guidelines about “when to use Fable/GLM/DS” and etc. to keep the costs down. And I think it’ll continue that way.
You didn't address the argument about tech debt. How do you get the greatest quantity of maintainable, high quality code within a given token budget? The answer, at least so far, seems to be human experts in the loop. We've also been hearing for years that LLMs are going to automate away software development entirely, but software job postings are steadily rising.
>How do you get the greatest quantity of maintainable, high quality code within a given token budget?
Doesn't matter as much. The cost of "maintenance" is going down, from what I can see internally, from other companies, and every story i'm reading from other organizations as well. Token budgets are changing, but model quality and effectiveness are going up as well.
> We've also been hearing for years that LLMs are going to automate away software development entirely, but software job postings are steadily rising.
I think this has been contested from day 1. SE jobs might be automated, but jobs might increase, if there's possibility of starting new companies / new investments / etc.
I'm still not clear on what you're really saying. If a human programmer's input doesn't matter at all, then anyone should be able to prompt a model until it spits out the software they want. That might work today for building fun tech demos, but I don't see it happening on projects that have a minimum bar for security/reliability and long-term maintenance. Would you say, for example, a team of 10 managers with no software experience can be as successful as a team of 10 expert programmers at building a large project like an operating system, with both teams having access to the same AI models and budget?
No, because expert programmers will not know what they’re building, and skew the prompts and ask for the right things.
The analogy would be math people with AI vs. non-math people with AI trying to solve some problems. I cannot solve the problems because I have no idea how to prompt it to go specific way. But it doesn’t matter how dirty your scratchpad was, because you got to the solution.
> I don't see it happening on projects that have a minimum bar for security/reliability and long-term maintenance
I don’t get this, because this is currently, right now, at this second, happening across huge projects. My point was that maintainability is less of an issue than before. Also, frankly, over years, I’ve seen bad code that AI wouldn’t even write. So there can be a case that the maintainability/code quality isn’t even going down as the models get better.
API design matters if anyone outside your app consumes it. Duplicate code makes changes hard and most compilers can't optimize it away. Bad file structure wastes tokens and makes off target edits more common.
These things are important even in a repo with zero human code. A project that's filled with tech debt will always be hard to work with no matter what latest frontier model you're using.
I think a lot of this can be automated with slop detectors that flag messy unreadable code and make agents rewrite it, but you can't say it doesn't matter.
I can see three likely explanations for how my personal experience with modern AI programming tools differs so much from a lot of the advocacy I see online.
1. We are working on different types of application and code.
2. I am in a bubble and no-one in it has experienced the standards and productivity that SOTA AI tools can achieve.
3. The advocates are in a bubble and no-one in it has experienced the standards and productivity that expert developers can achieve.
I hope the answer is 1. I fear the answer is 2. I suspect the answer is 3.
Well I work on writing Jax and PyTorch machine learning experiments in Python, so I doubt that I'm working on entirely different types of code from what LLMs get trained on.
You can work the way you want to work. In my experience, letting the agent make every decision leads to a big ball of mud that requires touching dozens of files to make a change. More context is needed, it burns through tokens much faster, and the agent takes shortcuts and builds technical debt. So the way I prefer to work is to have changes targeted to a single file or small set of files where I've defined the API. Maybe that will change in the future, I'm not set in stone here.
> In my experience, letting the agent make every decision leads to a big ball of mud that requires touching dozens of files to make a change
It seems too early to make any conclusion like that. We've still only been doing agentic coding for a year and capability significantly improved during that time. I don't think anybody on either side of this debate can have actual empirical evidence to support conclusions about where it lands longer term.
The main argument I see is that it probably pays to be slightly conservative because the cost of being wrong by maintaining too much oversight and shipping slightly less code is better than the cost of ending up with an entirely unmaintainable system. In some cases it will be more than "slightly less" but in almost all complex pre-existing systems, you are rate limited by a lot of other factors outside of code production, so the effective difference just isn't that high.
At agentic coding velocity, tech debt becomes obvious much more quickly. Empirical evidence is a bit of a ridiculous bar to hold for software development - we are as quantitatively blind now as we have ever been - but at least for me the anecdotal evidence is very clear. Today's agents hill-climb and their software architecture is pretty reliably bad without a human in the loop.
And it's debatable how much better they will get quickly. Verifiable rewards for maintainability of software is, I think, possible but very hard.
When I said "in my experience" I meant literally that, my experience so far. I'm not making any predictions. I'm definitely anticipating things improving at a rapid pace, which is why I think it's good to run frequent experiments. If in a month I find that an agent can one-shot a 20k line project without creating an unreadable, unmaintainable mess, that will be great.
I share that experience. To the point that I don't think I'd want to work (at least for as long as I have the luxury of having a choice) on a project where an AI has been let loose.
I also see devs, seniors as well, that have a different experience. At least that's what they say. I stay open to the possibility that I'm doing or seeing it 'wrong', but I'm far from convinced. I do like to experiment like you wrote in a later comment, things may change, and even now I do find it can be very powerful, for the right tasks.
That's why I don't rely on their design. But I also don't write the design from scratch. I use a conversation with the model to build a plan. I let it do the things it thinks is right, and I add corrections where I want to see something different. Or more accurately I "ask questions" which lead the model to making those changes itself. I don't say "use this design pattern here instead" but "Why didn't you choose to use this design pattern instead? What are the tradeoffs that you see?" When I notice a pattern in how the model deviates in how I prefer things, I add additional instructions to the prompt to try to close the gap over time and I get better first shot responses.
A friend of mine is getting into AI more than I am and seems to like doing random coding tasks to see what it can do. Like, coding a clock app in Window with NTP/PTP. Or coding a multi swarm agent that is so poorly designed it hurts my soul. I want to say the clock app came in at 300 Mb and god knows how much memory usage it was pulling. LLMs have all these different pieces but it still doesn't know the optimization that an engineer might know with experience. Because of the amount of slop being generated, we're essentially line workers that deal with automation being implemented in factories. Very much the the technology version of the 'American Factory' documentary on Netflix. Unless we're at the forefront of this SOTA hotness, we're behind in all aspects.
I've been doing this a long time and i would say since the last 3 months or so i've spent more time learning from llm code than correcting llm code. It's not bad and takes approaches and makes decisions i wouldn't have thought of. I'm not too ashamed to admit that, a model just as access wider and deeper experience with code than I do.
Its really sad that you think that an intelligence that cannot learn is better than you at everything.
The advantage I have is that I know things that are not in the training distribution. Things about our business, our product, and its internal architecture. Without this knowledge, some new features cannot be designed successfully.
Some day I expect that will change, but all the patchwork "memory" systems, all the docs etc, will never get there because at some point they just pollute context. Knowledge has to be integrated, and that is what happens during sleep for humans, during pre-training and RL for models. LLMs are terribly inefficient at learning though and degrade generally during fine-tuning.
I'm not disagreeing with you - I give agents a lot of input and spend a lot of time iterating with them before I'm happy with the result. My point was only that I don't think that I'm somehow superior in design patterns or any other general part of coding just because I happen to be human or because I have years of experience.
No one at all claimed that, certainly not the person you responded to. They're talking about how to use these tools in a way that gives you insight into what they produce. So, as an engineer, you know the shape of the output, before it's made.
Why is that so hard to believe? I don't always do this, but I do course-correct Claude on almost every big change. YOLOing it would superficially look fine, until the latent issues catch up with you.
The LLMs have been trained on all kinds of code. They often choose a hacky solution because that's what they encountered in similar situations in their training. It generally only takes a few words to guide them to a better design than what they saw in the wild, but if you don't guide them, they follow the herd.
It generally only takes a few words to guide them to a better design than what they saw in the wild, but if you don't guide them, they follow the herd.
That certainly can be true but I would challenge "generally". If you're working on something novel then it's not exactly unusual for even SOTA models to produce a first attempt that makes some very bad assumptions but then get stuck when instructed to use correct axioms instead. This looks a lot like the suduko meme - without any real insight into the problem the models end up just iterating around in circles and never finding a solution.
You probably won't see this very often if you're working on simple CRUD web applications where there are millions if not billions of lines of code in the training data set. IME you will probably see it quite frequently if you're working on - for example - software to control some kind of equipment or analyse the results of some kind of experiment where the LLM might have little if any training data about the field you're operating in.
Any time the LLM can establish a tight feedback loop it can iterate effectively enough to make good progress. But if for one reason or another that feedback loop is long, the more guidance and direction they seem to need. If they cannot correct their course based on feedback from their own output they need an outside observer to push them towards different paths. CRUD stuff is the obvious easy answer. It represents some absurd amount of software development work and is drastically overrepresented in training data. For good and bad. Lately I've been working on a diffusion model for terrain generation. The goal is to be able to recreate realistic terrain based on water flow and erosion on top of plate tectonics for much longer geological time terrain adjustments. These are much longer feedback loops. Sometimes it'll spend 6+ hours training a diffusion model on my 5090 just for the quality to degrade compared to the last experiment. So letting the model go wild trying different approaches and evaluating the results doesn't work nearly as well as when it can iterate 1000 times in those 6 hours while checking its own answers.
Any time the LLM can establish a tight feedback loop it can iterate effectively enough to make good progress.
Not any time. Your feedback loop must provide some direction so the iteration is at least heading towards an improvement. For novel applications you might not have a convenient way to do that yet.
Even with that provision there's still a possibility of incrementally updating output converging on a local maximum. That local maximum might not be a solution at all. If it is a solution then the model might still miss much better solutions that a real developer with more insight might find.
As you said yourself the models need external feedback if they don't have sufficient information to make adjustments by themselves. In some cases that feedback might be "Start again because you're hopelessly off track". Sometimes even when they start again they just get hopelessly off-track again. That can happen even if they are explicitly prompted to do something else. So even closely supervising the LLM and not using self-iterating agents isn't guaranteed to get good results for novel applications.
Maybe I'm overly pedantic, but in my mind a feedback loop involves both feedback and a loop. So by my reckoning the "feedback loop" must, by definition, guide the direction of the next step. I hold this true of feedback loops with zero LLM tooling involved. It's the same thing. The "entity" determining whether to continue the loop or not must have a good enough definition of success or improvement. Of course there is a lot of variability in how effectively the feedback is delivered. That's one of the variables the human setting up the loop is responsible for establishing in our brave new world.
You're right though that in new territory you may often have domain experts who still cannot adequately define success in an automated fashion because this is literally something that hasn't been created before. So they must be a part of the loop. They cannot necessarily put into code and descriptions what "better" or "right" is for an LLM to follow. But they can recognize it when they see it. In this case, it's still best to create the tightest feedback loop you can. If the LLM is waiting 2 days for your feedback, the loop is 2 days long.
I would say that a system with some sort of binary evaluation that indicates whether it succeeded or not is receiving feedback. It could also be some kind of sliding scale - how close did it get?
Either of those might be useful for determining a good future direction to iterate in but that would surely depend on the nature of the problem and how it's possible to search for solutions. I'd still call it a feedback loop even if the evaluation wasn't enough to point in a specific direction for a further iteration though. YMMV.
That's a great perspective. Come to think of it, I wonder about the quality of the build123d code it generated when I vibe-coded a prototype complex assembly. Now I'm curious.
I don't do this at all. I just YOLO merge after reading the change description. Senior dev, paid well at a FAANG.
I don't really care about the code being unmaintainable. Fable 6 or whatever will take care of it, just like Opus 5.5 takes care of our Opus 4.6 slop. The code working and our feature shipping is way way more important.
It seems unrealistic protect our jobs by keeping it a secret if LLMs really can do them (still a big if). Maybe if we as an industry had formed unions but it seems a bit late for that.
My job evolved long ago, I'd certainly be worthless at my job if I insisted on keeping the shape of a typical SWE. Automating YOLO merges - we're working on that, I can't wait.
I would say I am now responsible for more big-picture decisions than I was previously, with Claude taking on the role of SWE (or a team of them). Despite this, there is still way more work than people.
> I don't really care about the code being unmaintainable. Fable 6 or whatever will take care of it
> The code working and our feature shipping is way way more important.
I like that we both use AI very differently (you YOLO, I don't) but can agree that these are basically the important questions. If a company or team answers them like you do, I agree with the conclusion (YOLO). To me that's still a decision to be made though, and to be made wisely. Whether to accept the code may become unmaintainable, to forwardly rely on Fable 6 and to ship above anything (or at least a lot) else.
