3,615 karma · joined September 13, 2007
> It is therefore the policy of my Administration that, to the maximum extent permitted by law, the executive branch shall use the terms “Super Intelligence” and “SI” in place of “Artificial Intelligence” and “AI” and will not acknowledge the usage of “Artificial Intelligence” and “AI” in any applicable setting.
AI will help advance the speed of progress but they won't be autonomous.
Models will continue to get more optimized and you'll be able to run what you need locally on your computer.
It's an interesting question. The thing I keep coming back to though is that every time I've tried to go more towards vibe-coding, I invariably look at the code and find things have been added that would just not be acceptable. I've also tried asking the models to see could be refactored however they still miss things that should be obvious.
I think the gap is that they're still lacking a sense of importance. As engineers working on a product, you have a sense that this feature is more important than that feature. An LLM treats your codebase at the same level of importance. So they'll spend the same amount of effort and code changes on testing and hardening something that just really isn't that important.
Also, once a bad pattern gets into the codebase, they just continue to build and extend that out rather than re-thinking about it like an engineer would.
I've tried this out. Even with relatively small applications and with spending hours reviewing the spec documents, there was always something I missed or something that wasn't quite right when seeing it live.
My issues with it as I recall:
- there's no objective definition of "productivity". Engineers were only asked how they feel about their productivity and that was used as the measure.
- the same thing with "quality". There was no objective measure. It was up to the respondents to answer how they felt about the quality of the codebase they were working on. This is clarified in the abstract:
> We find that increases in perceived code quality tend to be followed by increased perceived developer productivity, but not vice versa, providing the strongest evidence to date that code quality affects individual developer productivity.
(emphasis mine) IMO the title makes a misleading and stronger claim than what is actually found by the study.
- there were no metrics taking into account the length of time someone had worked on the codebase. My theory is that the longer someone works on a codebase, the more they'll understand the codebase. The more they understand the codebase, the more productive they'll be working with it. They will also perceive it as being higher code quality than when they started because they understand the code better and they've likely made improvements to the code over time as they've worked on it. As mentioned, unfortunately this metric was not captured during the study.
There's a difference between everything being vibe-coded where you don't look at the code and don't understand anything and using your agent like a very fast pair programmer.
It looks like Antirez did the latter. From https://antirez.com/news/164:
> In the first month I just wrote the specification document...Thanks to AI, the specification evolved a lot, via back and forth of feedback, intellectual challenges about what was the best design, what was the right compromise, what was too engineered and what not.
> You know what was the biggest realization of all that? For high quality system programming tasks you have to still be fully involved
Judgement will be required even moreso now. There will be critical parts of the system where it's important that engineers know them well. But there's a lot of work around the core that isn't that critical to know in detail. For these types of things, I've found it's just important to understand the gist to make sure things aren't going off the rails. But for the core pieces, it's important to understand the details of what's happening.
What would you do to make it more effective?
Job is posted. You apply along with hundreds of other people. The recruiter/hiring manager needs to spend some time sifting through them along with juggling all the other tasks they have going on. Let's say that this takes 1-2 weeks. Some places may let the opening sit longer to get more applicants.
Several candidates are identified as possible fits. Recruiter reaches out to them to schedule the recruiter screen. Schedules need to line up. This likely takes 1-2 weeks until the recruiter screen happens.
The recruiter needs to schedule the tech screen after a successful recruiter screen. Again, schedules need to line up. This could take another 1-2 weeks.
Feedback needs to be submitted and then the onsite round is scheduled. This could take another 1-2 weeks.
The onsite round will have multiple interviewers. This means more people to collect feedback from which likely increases delays in getting that. A debrief is normally scheduled with everyone who interviewed them. But let's say one week to gather this and make a decision.
An offer is made. It takes some time to prepare and get sign off. There will be time to discuss with the recruiter to explain the details, plus some time needed for negotiation and thinking it over. This could be another 1-2 weeks.
Additionally, some candidates may want to ask for more time during these phases in order to prepare better or align their schedules. This pushes back the process for all other candidates if the company is hiring for a specific job in order to give all candidates a fair assessment against the pool.
Adding this all up, we arrive at 6-10 weeks.
Also, Claude Code is the agentic harness with the underlying models being the anthropic ones. If it's the harness you're worried about, try out Codex or any of the open source ones like OpenCode, Pi, Goose.
This will never go away. Instead it will become more local. In the future, it's more likely that you have a model running on your computer. These companies have no moat. You don't need to worry about it going away or them charging beyond what you can pay.
You could argue that's because of the prep work people put into avoiding that. The same thing will happen here. The HF incident was a warning sign and people will put better guardrails in place as a result.
This seems like a case of "save me from my own mistakes/ambition"