Hacker Newsnew | past | comments | ask | show | jobs | submit | nathanielks's commentslogin

If the previous commenter won't say that, I will

Is 10 hours a short amount of time for designing a PCB?

I'd honestly love to see the PCB. Using an LLM for a mostly geometric task like PCB layout feels like using a hammer to cook a chicken, unless KiCAD has some kind of text-based description language i'm not aware of that gets around having to specify coordinates.

KiCad schematic and board files are all text based with a fairly strict grammar, so you would be able to feed it directly into an LLM. Not that that means the LLM could actually make sense of it. Never tried though XD

Faster than some, slower than some.

PCBs come in all different levels of complexity.


> The engineers who've adopted these tools effectively get heard more often, get their proposals taken seriously more often, and shape direction more than those who haven't.

I want to point out if the organizational model or your team's engineers are resistant to change, it doesn't matter how good of an engineer you are, or how good at proposal writing you are. With or without AI.


> Instead there’ll be a much stronger focus on teams of generalists, or combined teams of specialists from different fields, working on a feature or product end to end.

> Coordination has in my experience always been the big bottleneck in getting anything done

I work at a large enterprise you've heard of. They're currently re-organizing the product area to remove currently-static two pizza teams into an amorphous blob of feature-oriented teams. Once the feature is complete, the team is dissolved and the engineers re-enter the pool, tasked with new features.

All that to say, I think you're right on the money with your assessment.


Where does the feature go for long term ownership? That throws you build it you own it out the window. We are going to get more time for documentation and handover right, right? Engineers are famous for generating good documentation.

There’s going to be lots of documentation. It will be AI generated and no human will ever read it. But there will be a lot of it.

Some places I've worked in the past had a rotating support team who were tasked with dealing with bugs/small feature requests/incidents for a period. I'm not sure that's the right answer because nobody wants to be on the team that's just doing scutwork even if its just for a month or two but it is an option.

All fantastic questions I wish we had an answer for

Fly.io (AFAIK) still has a relatively good track record?


This is a great strategy idea, I like it. I'm not good at thinking out the curse of the monkey's paw, so I'm curious if folks can think of any downsides.


> Open Source and the OSI are an industry plant. Look at who sponsors it.

This is ignorant to the history of Open Source software. Software has been open long before it was subsidized by large corporations.

"Computer software was created in the early half of the 20th century.[2][3][4] In the 1950s and into the 1960s, almost all softwares were produced by academics and corporate researchers working in collaboration,[5] often shared as public-domain software." https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...


You're talking about a different thing to OP. OP is talking about the OSI and the specific incarnation of 'open-source' that came with it, you are talking about the more general social pattern of open collaboration.


> Software has been open long before it was subsidized by large corporations.

Software then was also rather different from software now. It's not a government-funded research project these days.


Unfortunately that's not the case. There are many senior and above level engineers out there who are unskilled communicators but very technically skilled.


In which case maybe they're best suited to not leading a team.


100%! Just pointing out how the reality of things doesn't match our desires.


I think you need to read the studies linked in the footnotes. This is a well-studied issued.


Yeah, their statement just isn't true. With enough instruction, I've been able to get great output from models. I think that's the key: with detailed, pointed instructions, the output will match.


how do you know it matches? You did read it then?


Indeed, I'm not using LLM output without thorough review.

After reading a bunch of other comments, it sounds like people are referring to letting agents go wild and code whatever off a limited prompt. I'm not using LLMs like that; I'm generally interacting only via conversations with pretty detailed initial prompts. My interactions with the chat after that are corrections/guiding prompts to keep it on point and edit the prompt output from time to time.


Which defeats the purpose of using a LLM in the first place. Same as writing by hand but with a bill for tokens.


This is a fun new position to move the goalposts too, I suppose, but it doesn’t make much sense to me. If I can use AI to plan, implement, test, document, refine, release, and maintain a feature, with review, in 20% of the time it would take me without AI, how exactly does it “defeat the purpose” of using an LLM? My purpose for using the LLM is to solve problems faster, and it does that. What’s yours?


Exactly this. So far it's helped identify blind spots in my thinking, as well as educate me further on the techniques and frameworks I'm already using. It's been tremendously helpful at developing very well thought out _and tested_ software.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: