6 ms·
Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself. It's not about typing speed, it's t
by notnullorvoid 5mo ago
Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself. It's not about typing speed, it's that when you know something really really well the solution/code is already known to you or the very act of thinking about the problem makes the solution known to you in full. When that happens it's less text to write that solution than it is to write a sufficient description of the solution to AI (not even counting the back and forth required of reviewing the AI output and correcting it).
- bulbar 5mo agoGiving a precise description of what the computer is supposed to do is exactly what programming is. The more specific your requirements the closer you get to natural language not being useful anymore.
- kyykky 5mo agoI code mostly in APL and J. It’s much faster to type the code than explain everything to AI.
- satvikpendem 5mo agoThe exceptions that prove the rule. When your programming language is built up of singular Unicode characters with specific meanings, of course that's faster than typing out in English what you want. What do you use them for? For most AI users it's usually CRUD and I've never seen a web server or frontend in APL like languages.
- noosphr 5mo agoThe exception is the rule. The reason why programming is hard is because most languages force you to use a hammer when you need a screw driver. LLMs are very good at misusing hammers and most people find them useful for that reason. If you use a sane dsl instead the natural language description of a problem is always more complex and much longer than the equivalent description in a dsl. It's also usually wrong to boot. This is what algebra used to look like before variables: https://en.wikipedia.org/wiki/Archimedes%27s_cattle_problem#Problem https://en.wikipedia.org/wiki/Archimedes%27s_cattle_problem#... I don't think you will find anyone who can do better than an LLM at one shotting the prose version of the problem. Both will of course be wrong. But I also don't think you will find an LLM that can solve the problem faster than a human with Prolog when you have to use the prose description of the problem.
- stingraycharles 5mo agoUsing esoteric programming languages doesn’t suddenly make it true for the majority of development, which is web apps, CRUD stuff, some data science, etc.
- noosphr 5mo agoSQL and algebra are not esoteric languages.
- satvikpendem 5mo agoFor most devs, they are.
- satvikpendem 5mo agoWho is using APL and J these days? I guarantee 90+% of Claude users are developing CRUD web apps, or something similar. Your point about algebra is a non sequitur to what people are actually developing for these days.
- gspr 5mo agoThis is actually my biggest gripe with vibecoding. The single best feature of any programming language is that it is precise. And that is what we throw out?! I favor of natural language, of all things?! We're insane!
- timschmidt 5mo agoIt turns out an awful lot of precision (plenty for many things) lives in library and web APIs, documentation, header files and dependency manifests. Language can literally just point at it without repeating it all. Avoidance of mistake through elimination of manual copying in things like actuarial and ballistics tables was what the original computers were built for.
- stingraycharles 5mo agoCustom written code can also point at those APIs and libraries without repeating it all? Or am I missing your point?
- theshrike79 5mo agoAPI Glue is the easy and boring part in programming. Nobody really enjoys wiring API A to API B, combining the results and using API C to push it forwards. Any semi-competent AI Agent can do that with a plan you've written in 5 minutes.
- skydhash 5mo agoI would love to see an AI try to make sense of GTK API. I may be wrong, but it seems when people are talking about easy glue code, they’re talking about web services API, not OS API, not graphics or sound API, not file formats libraries,…
- theshrike79 5mo agoI used Sonnet 3.5 over a year ago to decrypt a notoriously shitty local government API to get data out of meetings, votes and discussions. I know it's a piece of shit API done in the worst possible way on purpose (they don't want openness, but had to fulfill a law that mandates "openness") because I had previously tried to do it manually - twice. I ran out of whisky before I got anything done. Sonnet _3.5_ almost one-shotted it with just the API "documentation" they had and access to Python and curl. People have also hooked stuff into proprietary APIs on "smart" devices with zero documentation, just by having an Agent tirelessly run through thousands of permutations to figure it out.
- deleted 5mo ago[deleted]
- lmeyerov 5mo agoMaybe a failure to automate? The volume of people successfully adopting agentic engineering practices suggests this stuff isn't rocket science, but it is a learned skill and takes setup. A year later into heavy AI coding, my experience is what you're describing should aid in being able to run 5+ agents simultaneously on a project because you know what you're doing, you set it up right, and you know how to tell agents to leverage that properly.
- necovek 5mo agoYou seem to have missed OP's point: some things are only encoded in our brains when you are sufficiently experienced. Translating that into code can happen directly by you, or into prompt iterations that need to result in the same/similar coded representation. In other words, when it matters how something works and it is full of intricate details, you do not need to specify it, you just do it (eg. as an example which is probably not the best is you knowing how to avoid N+1 query performance issue — you do not need a ticket or spec to be explicit, you can just do it at no extra effort — models are probably OK at this as it is such a pervasive gotcha, but there are so many more).
- timschmidt 5mo agoI think there's a level above that where the words to describe such structure are familiar and readily available and hey guess what? The model understands those too. Just about every pattern has a name. Or a shape. Or an analog or metaphor in other languages or codebases. All work as descriptors.
- necovek 5mo agoThis presumes that most of this stays encoded as words in our brains: the effort to translate some of these into words might be similar to translating it into code (still words, just very precise). It's like talking legalese vs plain English; or formal logic vs English. Some people have the formal stuff come more naturally, and then spitting code out is not a burden.
- larodi 5mo agoCare to explain which particular intimate knowledge allowed you in the last 6-9 months to be faster than AI in certain area? Honestly, I'm still faster than AI cooking scrambled eggs, but definitely not faster than neither AI (or compiler) in translating stuff into code.
- tdeck 5mo agoNot the parent but I've had this happen when debugging for sure. Sometimes I ask Claude Code to help me debug something and it makes a wrong assumption and just churns in circles burning tokens. While it's doing that I realize the problem and fix it.
- murkt 5mo agoSometimes debuggind is faster indeed, and making small very focused changes too. But during feature development? Not possible. And I consider myself a very fast developer
- tdeck 5mo agoDon't you find that debugging takes place as part of feature development though?
- murkt 5mo agoWhat I meant is that only sometimes I am faster than Claude with debugging. When it's a standalone problem, a report in Sentry, and I just know immediately where I need to go to fix it. Then it's faster to do myself, than telling Claude what's the problem and where to look and wait. Bugs happen during feature development, as you say, but then Claude is in the context, and I don't need to tell it where to go, it sees the bug with failing tests, or smth similar. BTW. One thing that helps my Claude with debugging harder problems is that I tell it to apply scientific method to debugging. Generate hypotheses, gather pros/cons evidence, write to a journal file debug-<problem>.md, design minimal experiments to debunk hypotheses. You can add that as a skill, and sometimes it will pick it up automatically, but it works wonders just as a single sentence in the input.
- Fr0styMatt88 5mo agoYeah it’s when you go off the happy path that it gets difficult. Like there’s a weird behaviour in your vibe-coded app that you don’t quite know how to describe succinctly and you end up in some back-and-forth. But man AI is phenomenal for getting stuff out of your head and working quick.
- threethirtytwo 5mo agoI don't believe this. Either you're lying, or you just haven't caught on with how to use Agentic AI. Everything I do to interact with my computer is through an agent now.
- hatefulheart 5mo agoI don't believe this. Either you're lying, or you just haven't caught on how to use a computer. Everything I do to interact with my computer is still the same. See how boring you are?
- threethirtytwo 5mo agoOk sorry about that. I seriously don't believe him. The Agent is so fast there's literally no way you can be faster. Telling the agent your high level plan that you are extremely familiar with and then having the agent execute on 2000 lines of code is FASTER then having you execute on that 2000 lines of code. There is no reality where that can be physically beaten by even someone who's typing really quickly with zero pause. Physically impossible. Less boring or not? Another way to put it... although my answer is boring, I think I'm right. He is either a liar or like many other people lacks skill in using AI... because the transition to AI is happening so fast... not many people are fully utilizing AI to it's maximum potential. Many still use IDEs, many still interact with terminal. Many people still don't use it to configure infrastructure, do database administration, deploy code... etc.
- dzjkb 5mo agoAI can write 2000 lines faster than you, but you can write the 2000 lines correctly first shot faster than having AI do 10 iterations on these 2000 lines with your guidance to finally get it right I know that a better plan could mean fewer iterations, but again that extends the time you need to spend on that plan => the total time of the AI solution
- threethirtytwo 5mo ago
- squidbeak 5mo ago> Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself. You speak as if AI development is frozen, and you ignore the poster's point: > that gap will only increase as LLMs get more intelligent
- Tuna-Fish 5mo agoThat doesn't matter. The statement wasn't "faster than AI right now", it was "will always be faster than AI". And that's just nonsense. Current AI systems are extremely serial, in that very little of the inherent parallelism of the problem is utilized. Current-gen AI systems run at most a few hundreds of thousands of operations in parallel, while for frontier models, billions of operations could be run in parallel. Or in other words, what currently takes AI 8 hours will take it barely long enough for you to perceive the delay after you release the enter key. For a demo, play around with https://chatjimmy.ai/ https://chatjimmy.ai/ , the AI chatbot of Taalas, where they etched the model into silicon in a distributed way, instead of saving it in RAM and sucking it to execution units by a straw. It's a 8B parameter model, so it's unsuitable for complex problems, but the techniques used for it will work for larger models too, and they are working to get there. And even Taalas is very far from the limits. Modern better quality LLM chatbots operate at ~40 tokens per second. The Taalas chatbot operates at 17000 tokens/s. If you took full advantage of parallelism, you should be able to have a latency of low hundreds of clock cycles per token, or single request throughput of tens of millions of tokens per second. (With a fully pipelined model able to serve one token per clock cycle, from low hundreds of requests.) Why doesn't everyone do it like that right now? Because to do this, you need to etch your model into silicon, which on modern leading edge manufacturing is a very involved process that costs hundreds of millions+ in development and mask costs (we are not talking about single chips here, you can barely fit that 8B model into one), and will take around a year. So long as the models keep improving so much that a year-old model is considered too old to pay back the capital costs, the investment is not justified. But when it will be done, it will not just make AI faster, it will also make it much more energy-efficient per token. Most of the energy costs are caused by moving data around and loading/storing it in memory. And I want to stress that none of the above is dependent on any kind of new developments or inventions. We know how to do it, it's held back only by the pace of model improvement and economics. When models reach a state of truly "good enough", it will happen. It feels perverse to me that people are treating this situation as "there was a per-AI period that worked like X, now we are in a post-AI period and we have figured out that it will work like Y". No. We are at the very bottom of a very steep curve, and everything will be very different when it's over.
- u8 5mo ago
- lukan 5mo agoYes, there are still many areas where skilled humans are faster than AI (meaning faster coding yourself, than providing so much context and guidance that the AI can do it on its "own"). But in general the statement is really not true anymore, generic projects/problems have a pretty good chance that the AI can one shot a working solution from a lazily typed vague prompt.