The conflict between wanting the result versus wanting to program. The result tends to win out. Instant gratification, in short.
If I want something enough to not lose interest when programming it myself, I usually want it enough to forego programming it myself in favour of having it earlier.
It sounds like you just don't want to write code by hand then. You prefer instant gratification over writing code yourself. You said you miss programming without AI, my read here is that you do not have a strong desire to program without AI. Both things can be true, there's no dichotomy here.
Not exactly, that's more due to the projects. Let's say I want a music player with scrolling lyrics, I have a greater desire to have and use that music player than I do to build it. If there was a music player that already did exactly what I wanted I would use that. I think that might be a good way to put it: What I may be looking for is a project that I would build even if it already existed.
It's fine if people don't want to use AI for anything, and honestly I don't even believe you need to justify it. The justification given here is interesting and I think shows misunderstanding.
At one point the author writes
> AI is a tool that can only produce software liabilities
which I would argue is completely caused by misuse of AI. Sure, you can have AI write a ton of code that often comes with subtle bugs. But using AI doesn't mean that it has to write any code for you at all. I've been using LLM often for security analysis and the results are quite good. Vulnerabilities that we had collectively missed were shown and we could fix them ourselves.
In this case, instead of creating liabilities, we were able to use LLM to get more information about our code. It's completely possible we could have deduced this information on our own, but we didn't and LLM is capable of doing it much more quickly than humans.
I suspect people with opinions like the author’s haven’t been in a project where people use LLMs responsibly. We had a senior dev basically just prompt and push, with very little overseeing and minimal instructions, causing so many bad PRs and even prod bugs. That made me a sceptic for many months about agents.
Then we started to have (myself included) people actual plan out the tasks for the bot: give good specs, good ac, file context, better self-review, better ”agentic practices” (i.e. asking it to review it own work can sometimes help), and suddenly I noticed you really can use agents in a real world 1mil LOC project. If you do it well and responsibly (also meaning you still retain some sense of ownership and actually review the shit)
Nope. My point is not about the quality of the generated code, it's the fact that it was generated. No matter how good it is it will always be a liability without the accompanying asset which is the understanding produced by undertaking the effort of writing the code. Generated code is exclusively cognitive debt. It is also, by definition, legacy code since no one wrote it.
Look I hate AI "prose" and "art" with a deep passion, and i refuse to let an LLM touch my documentation, but this idea that you can't use an LLM to write decent code that you genuinely comprehend is outdated. Many developers choose not to, but that doesn't mean it's not possible.
I have coworkers who use an LLM who can explain and defend every line of every PR. I also have coworkers who just prompt and pray. Only one camp is producing genuine liabilities.
I have experience in migrating large DBs with replication and the article not discussing write blocks made my ears perk up as well.
Aside from the blocking you mentioned during the initial snapshot, you'd need to block writes to the old DB before the cutover as well. There's no way to guarantee in-flight writes to the old DB aren't lost when promoting the replica to a primary otherwise. I'm surprised the author didn't go into more detail here. Maybe it was fine given their workload, but the key issue I see is that they promoted the new DB to a primary before stopping the old application. During that gap, any data written to the old DB would be lost.
Yep, the Chevy Volt ran for almost 10 years up until 2019. In 2011 it was Motor Trend's Car of the Year. More than 150,000 were sold over the entire production, which isn't hugely successful for a GM vehicle but they were well liked by owners.
Framing EREVs as a new kind of hybrid that the US hasn't seen before is just incorrect.
In this case, I honestly wonder if the piece was actually written first from the perspective of being an ad for the new Dodge Ram EREV. It sure feels that way with the omission of the Volt, or other actually useful information on the topic, such as the success of EREVs in China or the viability of gas and oil alternatives that are not EVs.
The author says, regarding EREV trucks, "these trucks are likely to be still burning fossil fuels deep into the 2040s," which just completely ignores possible shifts to biofuels, which are already used in ICE cars today with no modifications whatsoever. See https://sustain-fuels.com/education/what-are-sustainable-fue...
I don't normally engage with comments like this as I assume there's no hope for someone who may be so willfully blind to the facts. My comment is more for those who might read what you wrote and accept it as truth.
I believe the previous commenter was referring to Musk's emails with Epstein, many of which were released by the DOJ Jan. 30th earlier this year.
On Nov 25, 2012, Musk asked Epstein "What day/night will be the wildest party on your island?" Source: https://www.justice.gov/epstein/files/DataSet%2010/EFTA01977...
So I think it would be fair to say he had more involvement with Epstein than a dinner. Epstein was a convicted sex offender since 2008, so it's not like people around Epstein didn't know who they were dealing with.
Ignoring your incredibly obnoxious (and a smidge smug) "You're too far gone!" routine, I've read the E-Mails. Epstein and Co. didn't like him so much they awkwardly lied about winding the "operation" down when he asked about visiting once - I highly doubt they'd let him into "those" parts of the parties even if he begged on his knees.
Cliniko | Full stack developer, React developer | https://www.cliniko.com/ | Remote | Full Time (30 hour week, full time pay)
Cliniko is practice management software that makes life easy for allied health professionals by handling appointment scheduling, storing treatment notes, managing invoices and payments, running video consultations, and much more. The software is used globally by 100,000+ people every day.
It’s a web application built using Ruby on Rails in the back end and we’re in the process of transitioning the front end to React.
Cliniko is made up of a team of 63 considerate and friendly people, spread around the world. We work completely remotely, although our base is in Melbourne, Australia. We care much more about finding the best person for the job, rather than looking for someone that lives nearby.
We don't have managers, we don't have meetings, there are no time-sheets to complete. We're responsible, autonomous, creative, and proactive in doing our best for our customers.
We're focused on making great software and providing great support. We take pride in doing our best work, and enjoy bettering ourselves and each other. We strive to make the world a bit better, both personally and through our work.
Right. Which is why I don't fully believe my late grandfather. However, it would be nice to know if the strain I have has a direct lineage of the hemp grown during the Colony days.
The paper mentions that the Colonies first started growing European hemp varieties but by the mid 1800s had largely switched to (more recently) Chinese origin hemp varieties. I hope your grandfather's seeds are original Colony day seeds and you get to find out some day for a low cost but based on this paper, chances are that it isn't :(.
What's stopping you from programming without AI?
reply