Biggest problem right now is that we have teams pushing dozen of MD files, dozend of thousands of lines of English prose as if they were specs. There’s no way we can validate so much written prose because it’s plain English: perhaps one sentence is written in a way LLMs will read between the lines; perhaps line 100 and line 1000 are contradictory in such a subtle way that LLMs may not be aware of it.
In my company we have so much english prose committed to MD files that Im starting to think it’s all just snake oil. I cannot trust an engineer that writes “no bugs , please” and can go on with their lives.
What we need is some sort of Common, business-Oriented suBset Of the english Language that can be deterministically translated into something that the machine can understand, but also be read and understood by non-technical stakeholders. Such technology is a pipe dream, but one can dream…
Sounds awful. Just filling the time with worthless stuff. You are basically a liability. Wouldn’t like to have you in my team. Less is more (nowadays more than ever)
Didn’t we learn anything from the past? Using loc or number of commits or github stars to measure success or productivity is so backwards. It seems everyone on the AI wagon is either young (and so they don’t know our history) or simply forgot about all the good practices in software engineering
That latter bit is my experience. As soon as AI enters the equation, we have to immediately ignore everything we ever learned and just type text into the prompt box, or you're not doing it right.
One difference is: to use a top notch compiler/assembler you don’t need to pay. They are open source and have a lot of support. To use the latest and greatest models (bc no one around likes to use non sota ones) you need to pay a premium price.
Multibillion dollars companies are now the gateway for every line of code you need to write. That’s dystopian. It sucks
Yes, but that's a completely different argument (that I agree with). Essentially, yes they are conceptually similar but one is bad because you have to pay rent to use it.
But business people always cared only about thr result. My PM (who speaks like a salesman) only cares about the results. My “head of” same. My ceo same. The only ones who ever cared about the process and quality were us the engineers… if we don’t have that care, well, to hell with everything
That's not true as a simple statement, many business people really do care about quality and process, and you may find you care much more about them than you think.
How often have engineers decried yet another rewrite that some project is doing? Or talked about "over-engineering" something that isn't needed, or that another person in a team has setup a full kubernetes gitops thing that's glorious to them but you just want to scp a go binary and be done with it?
I've seen truly excellent engineers hit this issue, I worked in a team years ago and people disagreed on the approach to take on a new project. So we all made a prototype and presented it, so we could pick a direction. There was a requirement that it be done in ruby since that was the language most of the developers were most fluent in. One of the engineers, remarkably smart, wrote a lisp interpreter in ruby so that technically it'd be "in ruby" but have the benefits of lisp.
He cared about the quality and process in one area. Deeply. However focussing on that would be at the detriment to the rest of the actual product we wanted to ship. If you considered the quality of the product as a whole and the process at the level of the organisation, you'd do something very different.
Now, none of this means all business people are good at this or long term vision or anything, just as it doesn't mean all engineers have a very narrow focus. But I've seen engineers focus on the quality or engineering of some component without looking at what it is you're actually trying to achieve as a business, and so push for a worse overall process and lower "quality" result. It's the same sort of disconnect that leads a lot of engineers to rail against meetings and PMs that slow them down without seeing from the other side that it's often better to build the right thing more slowly than the wrong thing more quickly.
Assuming it is accurate, the logical conclusion is that the race is over. The management can get their $result and fast. Now, whether it is good or bad, is a separate story, and only time will tell whether they will be forced to learn anything. Right now, the expectation is to push for results and management seems to ascribe current set of failures to: people not embracing AI enough.
I think that's a common experience but not universal.
Just about everyone cares about process and quality when things start falling apart. And at least with current technology, it seems like vibe coding your way into a large project will inevitably land you in that spot.
> If you're at work and they really care about getting something out of the door, do whatever you think is best.
If you don’t mind being jobless, sure do whatever you think is best. Not all of us can simply switch companies easily. Folks need to realise that AI in a company setting works for the benefit of the company, not for the individual.
But do companies really know how to use AI? I think most of it is experimentation - throwing things to the wall and seeing what sticks.
It's the practitioner who eventually figures out what really works. I see this the same way the agile movement emerged. It was initiated by people who were hands-on programmers and showed enough benefit at minimizing software waste before it took a life of its own and started getting peddled by people who didn't really understand the underlying principles.
> I think most of it is experimentation - throwing things to the wall and seeing what sticks.
This is true in macro, but I think we're specifically referring to LLM-generated /assisted code (vibe-coding). 'Getting something out the door' is not an necessarily in reference to an AI-infused product, just new code written by AI
reply