Claude Code has the issue that sub agents inherit the thinking level. This means that to use a smarter or dumber sub agent you need a different model. That's not a particularly good reason, but that's my one use case for Sonnet.
> The second thing is that using LLMs in a useful way is a skill in itself.
I have to disagree here. People who are really into agentic coding like to say/believe this, but come on, it's not rocket science! You literally ask the agent to do something and it does it, that's it. As long as you use a recent model it will do it really well regardless of how fancy your prompt is. There's no moat here, anyone can do it. Your job will be gone and so will mine.
It very much is a skill. You wont get good results by asking it to "go do X" and walking away from the desk. You have to know how to use it as a tool to:
1) research the task
2) develop a plan the agent can follow to complete the task
3) check the plan for completeness/issues
After a (potentially long) session of investigation and planning _then_ you let it code. Even just being aware of this process is part of the skill involved (then you have to actually get used to doing it effectively).
Ask a human to "build twitter" and walk away and tell me how it goes. Vague requests will never work, no matter how intelligent the person being asked is, because they don't have enough information to give you what you want.
"No no no, when I said build twitter I meant without the character limit!"
Dealing with the situation would mean actually acting in your self interest instead of deferring to a cookie-cutter narrative to justify yourself as an essential meat proxy. Maybe stop feeding your data into the job destroying machine while paying for the privilege? Maybe come up with a better story for management than prompt wispersing, like at least writing your integration code yourself...
> You literally ask the agent to do something and it does it, that's it
Exactly, you have to know what to ask, especially on large codebase. I still have to baby sit Astra and opus 5.5 into reusing existing structures/functions, not reinventing the wheels, telling them "yes this might be a legit race condition, but you added 5000 LOC and I'm pretty sure it will never ever be a problem in production given it would require 5 distinct catastrophic failures at once to trigger it, if it ever happens log it in sentry and we'll have a look by then".
Some people are really really bad and won't even think about asking stuff like "run a memory profile and see if we can decrease our footprint", "benchmark the top 3 options for this bug and keep the one that uses the less cpu but still respond under 150ms".
You still need to have a broad understanding of what a computer is and how it works, both are skills, which a lot of dev didn't have anyways, but now they can shit out a looooot more code
My wording was bad. I've been using latest models recently and I can pretty much say build xyz feature or fix xyz bug and it will do it really well. It will ask me any clarifying questions. It will highlight things I haven't thought about. It will make suggestions on how to test and verify. And all of these things it will highlight the recommended choice I should choose.
So I stand by my assertion that anyone can do this now, it's definitely not a hard to learn/master skill, and people who say it is are naively believing there is a moat around their career.
So people who choose to not use it are not losing out on building any skills- in fact if they are focusing on hand coding and learning and keeping their brain sharp they, in my opinion, will be in a much stronger place than the AI enthusiasts whose brains are rotting.
You’re so profoundly incorrect that it’s obviously not worth the time and effort to even begin to try to realign you with reality on a site like this. I don’t know how to educate others on this topic. It’s a serious problem and the gap is continually broadening.
>You literally ask the agent to do something and it does it
It's not that simple, you have to remember at the end of the day these things are just doing next token prediction. If you don't give it the proper tokens to attend to, then your outputs won't be satisfactory.
You can get stellar outputs from LLMs, but it really is a function of how well you manage your input tokens.
that is to say, you have to be a good dev first and foremost, and no matter how much harnessing you do there is gonna be a limit to the quality of output by the user (otherwise why not just use a no-code tool instead)
(the ironic thing is tho, people starting out with just llms will probably never progress to 'good dev' in the first place...)
This is the one thing I'm curious about, what's the next generation of devs going to look like? Just a bunch of people who treat the codebase as a black box, pump out slop, and call it a day when the feature works?
I imagine there will be value in being able to understand every line of code for a while, because many (most?) things don't seem amenable to long term vibe coding. But how will that knowledge be obtained? Maybe there will be a much smaller pool of devs with the patience to actual learn bespoke software development.
Or, AI will actually get good enough that vibe coding is better in every case than mindful development. I guess the main factor is how long it takes for that to happen.
> Just a bunch of people who treat the codebase as a black box, pump out slop, and call it a day when the feature works?
my guess is yes, because that is what i am seeing today in front of me with new grads
> Or, AI will actually get good enough that vibe coding is better in every case than mindful development. I guess the main factor is how long it takes for that to happen.
i think there is a limit to this; you could train an llm to never dereference a null pointer or something like that, and you could probably minimize other security related stuff, but in the end its a token predictor, so you stuck with probabilities... i wouldn't vibe anything that had any security/legal/user related things but thats just me.
Most of us effectively function as next-token predictors, in my experience. Some of us are trained not to dereference null pointers, but there's always a non-zero probability that we do so anyway. To reduce that risk I use the same tools an LLM would, i.e. code review, automated testing and verification, etc. There isn't obviously much difference between humans and LLMs in that sense.
Like you I would not vibe code something important, but I think that's primarily because I want to have a deep understanding of a system before I accept responsibility for it. An LLM would still be useful during implementation and likely to increase the quality of the result.
It seems very likely that AIs will become capable enough that they can take complete responsibility for development, deployment and maintenance of the systems we're used to building. Further, it seems likely they'll end up much more capable than humans have been. I think that's an eventuality we need to be prepared for.
A well-utilised AI tool can probably already build a much safer and more robust security/legal/user related system than you or I can, in any given time budget. There's a question around what happens as humans are required less for the "well utilised" part, and who is responsible when humans are not really involved anymore.
>I have to disagree here. People who are really into agentic coding like to say/believe this, but come on, it's not rocket science! You literally ask the agent to do something and it does it, that's it. As long as you use a recent model it will do it really well regardless of how fancy your prompt is. There's no moat here, anyone can do it. Your job will be gone and so will mine.
As someone who's used more and more software made this way—either for hobby stuff or because I've had to for work—I just don't get it. You don't always get exactly what you ask for, and you often ask for something that is really sub-optimal in many ways.
The problem with waterfall wasn't ever solely "it takes a long time to write the code."
It's not hard to use a drill or a hammer but learning how to use them as tools to make things was always the real challenge. Using LLMs in a useful way I would argue is a much more important skill than programming as was learning how to make programming useful was always the more important skill, but it depends on if you view programming as a means to an end or the end in and of itself.
Using LLMs in a useful way I would argue is a much more important skill than programming as was
The trouble with this argument is that fundamentally this whole field has no sound theoretical foundation. It has no deterministic rules you can learn that will reliably get good results.
That also means there is no way to prove that what works well today will continue to work well tomorrow. Nor can you be sure that something you've tried and ruled out in the past because it didn't get satisfactory results won't be the new SOP next week. Any experience you gain in the field might be obsolete within hours.
An important consequence of this is that you can't train someone else to use LLM-based tools effectively either. At best you can train them to use specific tools and models that exist today effectively and hope the knowledge remains useful for a significant period of time. Even that assumes you have the knowledge yourself and aren't relying on something that worked well yesterday but could already be out of date after something new was released last night.
This looks like a fundamental problem that can never be fully solved as long as LLMs of the type that are popular today are behind the tools. People forget in all the hype and rapid change that the whole idea of agentic AI tools in mainstream development is barely a year old. We have no idea yet what the long-term consequences of so many people and organisations in the industry all but abandoning traditional programming skills in favour of AI agents will be. There already seems to be a lot of anecdotal evidence about programming skills atrophying, developers burning out, and the quality of the finished product dropping but it's probably too soon to have serious data to analyse or to draw any big conclusions about what is a good way forward from here.
Then on the other hand you have people who have doubled or tripled their real-world business by using these tools… And the folks who have developed apps that benefit their child’s development, etc.
You don’t have to look too far to see where we are going. But you do need to have your eyes open.
You don’t have to look too far to see where we are going. But you do need to have your eyes open.
As I said - we have no idea yet what the long-term consequences of the recent rapid shift towards AI and agents will be. I prefer to make decisions based on evidence, not hearsay or wishful thinking.
I have been around long enough to see a lot of hype cycles in programming. They were all going to be revolutionary. They were all going to change the nature of programming forever. They were all going to result in dramatic increases to productivity (or other similar claims).
Many of those phases did turn out to have some good - sometimes excellent - ideas. A lot of those have since been widely adopted in the industry. They also had plenty of ideas that didn't really work out. In the end we have improved some areas to a useful degree but none of those phases resulted in orders of magnitude increases in useful productivity or quality.
So far LLMs and agents are looking like a familiar story. They're proving to be useful tools for some types of work. They're now quite good at producing code to the standard of an average developer doing a well understood task - and in many cases that is all you need! But the jury is still out on whether they'll ever be able to replace good programmers or build genuinely innovative products where there aren't lots of examples of good existing implementations to train the models. Those are the parts of the industry where I do most of my own work and I hear much more scepticism about these tools from those developers than in the average online discussion.
> Using LLMs in a useful way I would argue is a much more important skill than programming as was learning how to make programming useful was always the more important skill, but it depends on if you view programming as a means to an end or the end in and of itself.
No, it's not. As evidence of intelligence atrophy, I offer up this word salad that barely makes any sense as evidence: someone barely able to write a coherent thought can apparently produce working software.
> You literally ask the agent to do something and it does it, that's it.
When was the last time you built something meaningful with it? I admit, LLMs do help and save tons of time and effort, yet building noteworthy software still remains a difficult task, with or without LLMs.
Funny, but your comment reminded me of my wife. Circa 2009, she was walking behind my back, she stopped to watch me work without me noticing. I was using Visual Studio (sluggish, temperamental mammoth, not its smaller cousin). She stared at my screen for a few minutes and suddenly exclaimed: "You're not even working, this thing is telling you what to do. I could probably do this shit too..." By "this thing" she obviously meant the intellisense completion that was giving me hints whenever I typed.
> I have to disagree here. People who are really into agentic coding like to say/believe this, but come on, it's not rocket science! You literally ask the agent to do something and it does it, that's it. As long as you use a recent model it will do it really well regardless of how fancy your prompt is. There's no moat here, anyone can do it. Your job will be gone and so will mine.
Sure, the skill of writing beautiful for loops and recursive binary search tree is basically worthless, but software is written for a purpose. That purpose is not gone. People will keep wanting POS system, accounting system, lawyers, manufacture stuff, personal assistant, etc etc
If you have watched a normie use AI and thought See?! It's not rocket science! We are all the same. then buddy, you are a normie. They are very very bad at it. (If you have not watched an average someone use AI, then I highly recommend it, if for no other reason than to understand your placement on the curve.)
> Your job will be gone and so will mine.
I mean, that's probably true, but the person you are replying to is talking about the present.
> The second thing is that using LLMs in a useful way is a skill in itself.
Not really. I don't even bother writing complete sentences as my prompts anymore. Once the LLM has enough context on my current issue, even incomplete sentences or phrases result in the same outcome quality in LLM's responses.
I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me:
- Work on small projects (< 500k lines of code).
- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.
- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.
- Set up excellent testing. Build your whole architecture around being easy to test.
- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.
The code in the end is better than a lot of the code I've seen humans write.
I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.
On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.
I think a lot of the discussions around development tools and techniques just stem from two facts:
1. Developers work on widely different projects with different management and constraints.
2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.
>> but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase.
> Work on small projects (< 500k lines of code).
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality.
You then expand on methods and processes that work for you, but I think the crucial question that you do not answer is: How long lived are any of these codebases?
All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.
If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
That's always false. It's like people want their meals delivered fast. They say they don't care about taste or how it is done. Watch when they get sick or don't like it and the drama that happens.
People don't care until they do. They don't know what to care (in this case code quality) or say that because you're not explaining it. People also "gamble" and you take the blame. Long term impacts? Nah doesn't matter. Weeks later and things break -- what did you do?
In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.
I never said. It's not about outright refuse. It's how to deliver better outcomes. It's not a win or lose situation. Don't treat it like that.
> If your boss says that he does not care about long term consequences and he want things done a certain way
As suggested in my previous comment it could be you didn't explain it well. If you say code quality they might not care. Say it will crash randomly and can't fix it then they might. There's some art to it.
> Your opinion on what you think he wants is legally irrelevant.
No it's not. So you're saying if you got told to do something illegal you'd also do it anyway? I doubt it. You need to at least cover your back and document it as such. I'd say termination is better than jail.
So, only use it for small codebases, don't use it if you value code quality or readability, and it's really good at building a CRUD app demo? I'm shocked. This is all completely new information.
>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>The code in the end is better than a lot of the code I've seen humans write.
It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
By the way, why didn't the "Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through" catch it?
Who knows how many skills you would have to have added if you actually reviewed the 400k codebase...But don't worry that's not what I am advocating. I myself would also latch onto any excuse that allows me to avoid the realization that I have to review 400k (or half that) lines of code, primary one being that I will always have a desperate paying customer that will always be grateful for anything I give them.
Which comes to your most valid advice which has nothing to do with AI (now that many devs have access to it):
> Work for business people who want fast results
This is what well oiled outsourve shops used to do and I must say it is no easy feat to be able to line up a constant stream of desperate businness people out of thin air, especially for your regular "I just want to code" engineer.
My guess is you're in the honeymoon phase with most of these people. The outsource shops that survived would fire the client that became more demanding and less grateful and move onto more freshly desperate client pastures. It is true that sales, self-promotion, and marketing are more important than ever now...
>Set up excellent testing.
Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I do not believe you read my comment in good conscience.
>>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>>The code in the end is better than a lot of the code I've seen humans write.
>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.
I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.
>>Set up excellent testing.
>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.
I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.
> There is no irony because I have seen humans do the same thing.
Your original comment started with the sentence:
> I am currently writing a lot of code that I am not reviewing anymore.
Then you give an example of catching a bad pattern the LLMs used when you actually reviewed the code, after you mentioned you had multiple agents set up to catch each others mistakes. That is the irony. You're mentioning that LLMs engage in basic bad coding patterns that are not caught by multiple agents, hence underlining the importance of human review.
> There is no irony because I have seen humans do the same thing.
Yes, but you were reviewing the humans. You're not reviewing the LLMs.
> I set up excellent testing the same way a CTO would set up excellent testing.
Knowing LLMs can make basic coding pattern mistakes (as you mention) but still unleashing them on your tests without routine human review that makes sure that test suites have not been negatively affected after each iteration seems like the polar opposite of consistantly maintaining excellent testing throughout the software development process.
how are you setting up excellent testing? using AI agents? hand writing tests? I hate talking to AI, I wish I could just write the test and the AI agent implement the fix
I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.
If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)
Thanks for the reply! So you would say that you have personally reviewed all the tests?
I’ve been thinking about how tests comunícate product function much more clearly and durably than prose, and that it maybe possible to create some sort of portable testing SDK that connects to the codebase and allows the dev to talk to the AI by just carefully writing tests, posting them to a backlog for the AI to pick up and edit the codebase until green.
