It wouldn't keep them from equipping _new_ models with additional sensors, spinning a story around how this helps them train the camera-only AI, or whatever.
It’s vaporware and it’s dollars and cents. Tesla EVs are already too expensive. He has no margin to include thousands more on sensors, alternative being the lawsuits that would follow if he admits it was all vaporware.
Fairly cynical indeed. Though I must admit that Anthropic's software - not the models, the software they build - seems to be generally plagued by quality issues. Even the dashboard is _somehow_ broken most of the time, at least whenever I try to do something.
> Anyway, it's not related to CoPilot, but because Notepad makes links clickable now...
True, not related to CoPilot, but if I understand your conclusion right (which I'm not sure about), it's not _just_ that links are clickable now, it's because Notepad actually does something with the links. Otherwise it'd be a browser vulnerability, and Notepad couldn't seriously be blamed.
It's in fact the opposite. Browsers show a popup that asks if you really intended to click a link with a non http/https handler, notepad does not.
The actual RCE here would be in some other application that registers a URL handler. Java used to ship one that was literally designed to run arbitrary code.
I think most of us - if not _all_ of us - don't know how to use these things well yet. And that's OK. It's an entirely new paradigm. We've honed our skills and intuition based on humans building software. Humans make mistakes, sure, but humans have a degree and style of learning and failure patterns we are very familiar with. Humans understand the systems they build to a high degree, this knowledge helps them predict outcomes, and even helps them achieve the goals of their organisation _outside_ writing software.
I kinda keep saying this, but in my experience:
1. You trade the time you'd take to understand the system for time spent testing it.
2. You trade the time you'd take to think about simplifying the system (so you have less code to type) into execution (so you build more in less time).
I really don't know if these are _good_ tradeoffs yet, but it's what I observe. I think it'll take a few years until we truly understand the net effects. The feedback cycles for decisions in software development and business can be really long, several years.
I think the net effects will be positive, not negative. I also think they won't be 10x. But that's just me believing stuff, and it is relatively pointless to argue about beliefs.
What kills me personally is that I'm constantly 80% there, but the remaining 20% can be just insurmountable. It's really like gambling: Just one more round and it'll be useful, OK, not quite, just one more, for hours.
Do you mean in terms of adding one more feature or in terms of how a feature you're adding almost works but not quite right?
I find the latter a lot more challenging to cut my losses when it's on a good run (and often even when I know I could just write this by hand), especially because there's as much if not more intrigue about whether the tool can accomplish it or not. These are the moments where my mind has drifted to think about it the exact way you describe it here.
And let's get real: AI companies will not be satisfied with you paying $20 or even $200 month if you can actually develop your product in a few days with their agents. They are either going to charge a lot more or string you along chasing that 20%.
That's an interesting business model actually : "Oh hey there, I see you're almost finished your project and ready to launch, watch theses adverts and participate in this survey to get the last 10% of your app completed"
No I kind of see this too, but the 80% is very much the more simple stuff. AI genuinely saves me some time, but I always notice that if I try to "finish" a relatively complex task that's a bit unique in some regards, when a bit more complex work is necessary, something slightly domain-related maybe, I start prompting and prompting and banging my head against the terminal window to make it try to understand the issue, but somehow it still doesn't turn out well at all, and I end up throwing out most of the work done from that point on.
Sometimes it looks like some of that comes from AI generally being very very sure of its initial idea "The issue is actually very simple, it's because..." and then it starts running around in circles once it tries and fails, you can pull it out with a bit more prompting, but it's tough. The thing is, it is sometimes actually right, from the very beginning, but if it isn't...
This is just my own perspective after working with these agents for some time, I've definitely heard of people having different experiences.
Previously, I'd have an idea, sit on it for a while. In most cases, conclude it's not a good idea worth investing in. If I decided to invest, I'd think of a proper strategy to approach it.
With agentic development, I have an idea, waste a few hours chasing it, then switch to other work, often abandoning the thing entirely.
I still need to figure out how to deal with that, for now I just time box these sessions.
But I feel I'm trading thinking time for execution time, and understanding time for testing time. I'm not yet convinced I like those tradeoffs.
Edit: Just a clarification: I currently work in two modes, depending on the project. In some, I use agentic development. In most, I still do it "old school". That's what makes the side effects I'm noticing so surprising. Agentic development pulls me down rabbit holes and makes me loose the plot and focus. Traditional development doesn't, its side effects apparently keep me focused and in control.
That's weird, I'm the opposite. Previously I would start coding immediately, because writing the code helps me figure out the what and the how, and because I'd end up with modular/reusable bits that will be helpful later anyway.
Now I sit on an idea for a long time, writing documentation/specs/requirements because I know that the code generation side of things is automated and effortlessly follows from exhaustive requirements.
I used to do this, but found scoping my agent usage down to smaller chunks got better results than trying to do it all from the get go. And looking back it makes sense - code is the most expressive form we have to tell the computer what to do, not English.
The size of the chunk varies heavily on what I’m doing ofc.
How to do that for a complex greenfield project? Do you scope out just one module and let the agent code only that, with the intention of reusing that module later in the full project?
>With agentic development, I have an idea, waste a few hours chasing it, then switch to other work, often abandoning the thing entirely.
How much of this is because you don't trust the result?
I've found this same pattern in myself, and I think the lack of faith that the output is worth asking others to believe in is why it's a throwaway for me. Just yesterday someone mentioned a project underway in a meeting that I had ostensibly solved six months ago, but I didn't even demo it because I didn't have any real confidence in it.
I do find that's changing for myself. I actually did demo something last week that I 'orchestrated into existence' with these tools. In part because the goal of the demo was to share a vision of a target state rather than the product itself. But also because I'm much more confident in the output. In part because the tools are better, but also because I've started to take a more active role in understanding how it works.
Even if the LLMs come to a standstill in their ability to generate code, I think the practice of software development with them will continue to mature to a point where many (including myself) will start to have more confidence in the products.
If you do not know what you want to build, how to ask the AI what you want and are unable to tell what the correct requirements are; then it becomes a waste of time and money.
More importantly, As the problem becomes more complex, it then matters more if you know where the AI falls short.
Case study: Security researchers were having a great time finding vulnerabilities and security holes in Openclaw.
The Openclaw creators had a very limited background in security even when the AI entirely built Openclaw and the authors had to collaborate with the security experts to secure the whole project.
That describes the majority of cases actually worth working on as a programmer in the traditional sense of the word. You build something to begin to discover the correct requirements and to picture the real problem domain in question.
> You build something to begin to discover the correct requirements and to picture the real problem domain in question.
That's one way, another way is to keep the idea in your head (both actively and "in the background) for days/weeks, and then eventually you sit down and write a document, and you'll get 99% of the requirements down perfectly. Then implementation can start.
Personally I prefer this hammock-style development and to me it seems better at building software that makes sense and solves real problems. Meanwhile "build something to discover" usually is best when you're working with people who need to be able to see something to believe there is progress, but the results are often worse and less well-thought out.
It's better to have a solid concrete idea written down of the entire system that you know you want to build which has ironed out the limitations, requirements and the constraints first before jumping into the code implementation or getting the agent to write it for you.
The build-something-to-discover approach is not for building robust solutions in the long run. By starting with the code first without knowing what it is you are solving or just getting the AI to generate something half-working but breaks easily and changing it once again for it to become even more complicated just wastes more time and tokens.
Someone still has to read the code and understand why the project was built on a horrible foundation and needs to know how to untangle the AI vibe-coded mess.
> You build something to begin to discover the correct requirements and to picture the real problem domain in question.
You lose that if the agent builds it for you, though; there is no iteration cycle for you, only for the agent. This means you are missing out on a bunch of learning that you would previously had gotten from actually writing something.
Prior to agents, more than once a week I'd be writing some code and use some new trick/technique/similar. I expect if you feel that there is no programming skills and tricks left for you to learn, then sure, you aren't missing out on anything.
OTOH, I've been doing this a long time, and I still learn new things (for implementation, not design) on each new non-trivial project.
it might depend how you word it, i specifically asked about a caldav and a firefox sync solution, explaining how much difficulty-adverse i was, and i have been berated both times
Sitting on an idea doesn’t have to mean literally sitting and staring at the ceiling, thinking about it. It means you have an idea and let it stew for a while, your mind coming back to it on its own while you’re taking a shower, doing the dishes, going for a walk… The idea which never comes back is the one you abandon and would’ve been a waste of time to pursue. The idea which continues to be interesting and popping into your head is the worthwhile one.
When you jump straight into execution because it’s easy to do so, you lose the distinction.
Sitting on an idea doesn't necessarily mean being inactive. You can think at the same time as doing something else. "Shower thoughts" are often born of that process.
I know, and letting an agent/LLM "think" about some ideas does not waste your time either. Yes, it "wastes" energy and you need to read and think about the results after, we don't have neural interfaces to computer, so the inner thinking feedback loop will always be faster. But I keep thinking GP comment was unfair: you can just have your idea in the background to check whether it is good or not exactly the same, and after that time "discuss" it with an LLM, or ask it to implement the idea because you think it's solid enough. It's a false dichotomy.
I understand you, and I felt the same for a few days: the dopamine rush was hitting hard. You just need to control it (with a very big "just"), like any other dopamine rush.
with agentic development, I've finally considered doing open source work for no reason aside from a utility existing
before, I would narrow things down to only the most potentially economically viable, and laugh at ideas guys that were married to the one single idea in their life as if it was their only chance, seemingly not realizing they were competing with people that get multiple ideas a day
back to the aforementioned epiphany, it reminds me of the world of Star Trek where everything was developed for its curiosity and utility instead of money
> Ads do not influence the answers ChatGPT gives you.
I wonder if this is a don't-break-product-value thing, or just compliance (ads need to be clearly labeled, but OpenAI seems like it has the risk appetite to ignore that kind of thing).
OpenAI has to do this if it wants to get big advertisers.
Ads need to be clearly marked as per FTC.
> According to guidelines from the Federal Trade Commission (FTC) in the U.S. and similar regulatory bodies worldwide, online advertisements—including sponsored content, native advertising, and influencer posts—must be readily identifiable as paid content to prevent deceiving consumers.
(1) is not something the typical employee can do, in my experience. They're expected to work eight hours a day. Though I suppose the breaks could be replaced with low effort / brain power work to implement a version of that.
Work for a smaller company with more reasonable expectations of a knowledge worker.
You're an engineer, not a manager, or a chef, or anything else. Nothing you do needs to be done Monday-Friday between the hours of 8 and 5 (except for meetings). Sometimes it's better if you don't do that, actually. If your work doesn't understand that, they suck and you should leave.
I suppose ultimately, the external behaviour of the system is what matters. You can see the LLM as the system, on a low level, or even the entire organisation of e.g. OpenAI at a high level.
If it's the former: Yeah, I'd argue they don't "learn" much (!) past inference. I'd find it hard to argue context isn't learning at all. It's just pretty limited in how much can be learned post inference.
If you look at the entire organisation, there's clearly learning, even if relatively slow with humans in the loop. They test, they analyse usage data, and they retrain based on that. That's not a system that works without humans, but it's a system that I would argue genuinely learns. Can we build a version of that that "learns" faster and without any human input? Not sure, but doesn't seem entirely impossible.
Do either of these systems "learn like a human"? Dunno, probably not really. Artificial neural networks aren't all that much like our brains, they're just inspired by them. Does it really matter beyond philosophical discussions?
I don't find it too valuable to get obsessed with the terms. Borrowed terminology is always a bit off. Doesn't mean it's not meaningful in the right context.
I can't speak for parent, but I use gptel, and it sounds like they do as well. It has a number of features, but primarily it just gives you a chat buffer you can freely edit at any time. That gives you 100% control over the context, you just quickly remove the parts of the conversation where the LLM went off the rails and keep it clean. You can replace or compress the context so far any way you like.
While I also use LLMs in other ways, this is my core workflow. I quickly get frustrated when I can't _quickly_ modify the context.
If you have some mastery over your editor, you can just run commands and post relevant output and make suggested changes to get an agent like experience, at a speed not too different from having the agent call tools. But you retain 100% control over the context, and use a tiny fraction of the tokens OpenCode and other agents systems would use.
It's not the only or best way to use LLMs, but I find it incredibly powerful, and it certainly has it's place.
A very nice positive effect I noticed personally is that as opposed to using agents, I actually retain an understanding of the code automatically, I don't have to go in and review the work, I review and adjust on the fly.
reply