> I almost never write code directly (it's always Claude)
Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.
> If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code
I think about this on the regular -- I know the answer is currently "you own the code, so you have to understand it", but to unlock the true productivity multiplier, in the future, the answer has to be "no one really".
I think about it using the concepts from my job (academia) -- to actually have PhD student-level intelligence means that you have to trust that it does a good enough job that you can focus on other stuff. Professors often bring the correct ideas or intuitions, but they have to trust the PhD student to write the code and/or fill in the gaps in the proofs -- they can advise them on the high-level issues during a consultation, but that's about it.
I am pretty bad at working in the current LLM workflow -- it is tough for me to focus on reading a TCS paper for review, keeping all the details and invariants in my head, but every 5-10 minutes go to my PC, completely switch contexts/projects, read the code and think about the LLM's comments, suggest the next step, and then go back to reading.
I do, with different tools and most of the time at a higher level of abstraction. The same way we understood the machine code 2 years ago, even though we didn't write it directly. Just another layer, nothing more.
I don't think you can really understand assembler without writing it and since compilers are fairly deterministic and get constant attention most of us using them haven't truly had to fight with what turned out to be a compiler bug.
Whereas LLMS regularly produce shit. One can excuse them for not understanding one's turn of phrase or whatever but it amounts to the same problem in the end - you have to understand the output language a lot better than most people ever had to understand assembler.
I see a lot of people trying to run away from Anthropic "window of doom" affair lately, me myself included. What has stopped me so far is the lack of real alternative to Opus. Not even gpt5.4 comes close
I'm experience, that doesn't work if you main clients are big corporations. The average corporate drone mistrusts and disregards small companies. Not out of arrogance, I believe, but out of fear: a generalized version of the old "no one was fired for buying IBM" trope. Small companies are seen as higher risk.
Yes, I agree. I was honest with a large customer about how small we were and although _he_ was willing to take a chance on us, he said we absolutely needed look bigger to gain other customers.
> The average corporate drone mistrusts and disregards small companies.
"Garageware" is what we called that type of software. Because it truly was, often built using old protocols, outmoded security mindset, etc.
It did the job our staff required (and may have been the only piece of software to do so) but it wasn't our favorite to deal with from a technology perspective.
In many markets, there are different kinds of customers. If you're the innovative upstart, you perhaps attract more innovative and open-minded customers as well. From there, when you've delivered value, it's then quite a lot easier to work with the more conservative ones.
I mean, small companies are higher risk. When you're small, is it better to find customers who are explicitly accepting the real degree of risk, or customers who are underestimating it because of how you presented yourselves to them?
Agreed, but being a small company can still work for some big-company customers, depending on how you approach it, and mostly how lucky you are.
Our super-lucky big first customer, it probably helped that we spun out of an established small engineering firm that did notable R&D work for huge companies, and also that we partnered with a huge hardware tech company, who had an evangelist who put in a good word for us at times.
And after a successful launch for a prestigious big company, we could point to that, to increase our credibility with other big companies (especially those in the same and similar markets).
For some co-design work leading to pilot we landed (intending to lead to a pilot), we worked together with their in-house product design team, on big brand-involved technology changes to their non-computers-tech advanced products, and also planned out the manufacturing and distribution logistics integration. (I think this one probably would've gotten to a pilot, after some delays, but we'd stretched our runway until it snapped, and there were various reasons we didn't get a bridge and didn't raise.)
For some prospects, we got access to CEOs or other execs, and the message came downwards to work with us. (Which seemed to nevertheless often have people below thinking in the usual CYA ways. But our foot was in the door, and our size had at least a provisional OK. Though some of those devolved into too many stakeholders being roped into meetings, which meant more use cases to be satisfied, including by people who were half-hearted about it, and this probably wasn't on their KPIs.)
Other prospects included smaller companies in some categories (e.g., a founder grew a sustainable business designing and making a high-quality physical luxury product). I think those were probably fine with us being small, and that they liked the direct access and our willingness to work with them and adapt to what they needed. The challenge there might've been finding PMF with a customer who understood every aspect of their company, who feels every dollar, and who didn't get where they are by introducing costs and complexity they weren't sure they had to. (By contrast with large companies as customers, anyone who's had to use some of the products of enterprise SaaS purchases knows that large companies aren't always that discerning in what they spend money on or what complexity they introduce.)
Bigger companies were also easier for one of our sales tactics, because their products had the popularity and volume to show up significantly in some bespoke data acquisition stuff from osint that we developed, which we used to prepare reports for cold call prospects that showed a money-losing problem they had, which maybe they didn't know about.
It feels like a total waste of time and I wonder if other feel the same.
One of the consequences of the LLM tsunami might be the freezing of research and development in programming languages.
Maybe we'll be stuck with J's and python forever...
reply