101–110 of 1001 posts
[flagged]
Translation: They'd love to lay off all the engineers.
Earlier quoted context omitted.
The elitism of programmers who think the boilerplate code they write for 25% of the job, that's already been written before by 1000 other people before, is in fact a valuable use of company time to write by hand again. IMO it's only really an issue if a competent human wasn't involved in the process, basically a person who could have written it if needed, then they do the work connecting it to the useful stuff, and h…
If 25% of your code is boilerplate, you have a serious architectural problem. That said, I've seen even higher ratios. But never in any place that survived for long.
Not the developer who has written the same effective stanza 10 times before.
Earlier quoted context omitted.
Not really technical debt when you will be able to regenerate 20K lines of code in a minute then QA and deploy it automatically.
Assuming, of course: - You know which 20K lines need changing - You have perfect QA - Nothing ever goes wrong in deployment. I think there's a tendency in our industry to only take the hypotenuse of curves at the steepest point
Hi, I lead the teams responsible for our internal developer tools, including AI features. We work very closely with Google DeepMind to adapt Gemini models for Google-scale coding and other Software Engineering usecases. Google has a unique, massive monorepo which poses a lot of fun challenges when it comes to deploying AI capabilities at scale. 1. We take a lot of care to make sure the AI recommendations are safe and…
To me the most interesting part of this is the claim that you can accurately and meaningfully measure software engineering productivity.
None of this works to evaluate individuals or even teams. But it can be effective at evaluating tools.
Hi, I lead the teams responsible for our internal developer tools, including AI features. We work very closely with Google DeepMind to adapt Gemini models for Google-scale coding and other Software Engineering usecases. Google has a unique, massive monorepo which poses a lot of fun challenges when it comes to deploying AI capabilities at scale. 1. We take a lot of care to make sure the AI recommendations are safe and…
I'm continually surprised by the amount of negativity that accompanies these sort of statements. The direction of travel is very clear - LLM based systems will be writing more and more code at all companies. I don't think this is a bad thing - if this can be accompanied by an increase in software quality, which is possible. Right now its very hit and miss and everyone has examples of LLMs producing buggy or ridiculou…
That’s a huge “if”, and by your own admission not what’s happening now.
> other LLM agents reviewing code, feeding in compile errors, letting other LLM agents interact with the produced code, etc.
What a stupid future. Machines which make errors being “corrected” by machines which make errors in a death spiral. An unbelievable waste of figurative and literal energy.
> Then we will definitely start seeing more and more code produced by LLMs.
We’re already there. And there’s a lot of bad code being pumped out. Which will in turn be fed back to the LLMs.
> Don't look at the state of the art not, look at the direction of travel.
That’s what leads to the eternal “in five years” which eventually sinks everyone’s trust.
i would be may more impressed if LLMs could do code compression. more code == more things that can break, and when llms can generate boatloads of it with a click you can imagine what might happen
I agree. It seems like counting lines of generated code is like counting bytes/instructions of compiled code - who cares? If “code” becomes prompts, then AI should lead to much smaller code than before. I’m aware that the difference is that AI-generated code can be read and modified by humans. But that quantity is bad because humans have to understand it to read or modify it.
What’s the point of shorter code if you can’t trust it to do what it’s supposed to?
I’ll take 20 lines of code that do what they should consistently over 1 line that may or may not do the task depending on the direction of the wind.
if the golden rule is that code is a liability, what does this headline imply?
The code would be getting written anyways, its an invariant. The difference is less time wasted typing keys (albeit small amount of time) and more importantly (in my experience) it helps A LOT for discoverability. With g3's immense amount of context, LLMs can vastly help you discover how other people are using existing libraries.
in regards to how others are using libraries, that’s where the technology will excel— re-writing code. once it has a stable AST to work with, the mathematical equation it is solving is a refactor.
until it has that AST that solves the business need, the game is just prompt spaghetti until it hits altitude to be able to refactor.
Earlier quoted context omitted.
To me the most interesting part of this is the claim that you can accurately and meaningfully measure software engineering productivity.
You can - but not on the level of a single developer and you cannot use those measures to manage productivity of a specific dev. For teams you can measure meaningful outcomes and improve team metrics. You shouldn’t really compare teams but it also is possible if you know what teams are doing. If you are some disconnected manager that thinks he can make decisions or improvements reducing things to single numbers - yea…
How? Which metrics?
Hi, I lead the teams responsible for our internal developer tools, including AI features. We work very closely with Google DeepMind to adapt Gemini models for Google-scale coding and other Software Engineering usecases. Google has a unique, massive monorepo which poses a lot of fun challenges when it comes to deploying AI capabilities at scale. 1. We take a lot of care to make sure the AI recommendations are safe and…
Will AI be able to detect bugs and back doors that require multiple pieces of code working together rather than being in a single piece of code? Humans have a hard time with this.
- Hypothetical Example: Authentication bugs in sshd that requires a flaw in systemd which then requires a flaw in udev or nss or PAM or some underlying library ... but looking at each individual library or daemon there are no bugs that a professional penetration testing organization such as the NCC group or Google's Project Zero would find. In other words, will AI soon be able to find more complex bugs in a year than Tavis has found in his career and will they start to compete with one another and start finding all the state sponsored complex bugs and then ultimately be able to create a map that suggests a common set of developers that may need to be notified? Will there be a table that logs where AI found things that professional human penetration testers could not?