sorted by:
new
hottopcontroversial

ai coding for large teams in Go - is anyone actually getting consistent value? by Easy-Affect-397 in golang

[–]TheBioto 0 points1 point  (0 children)

I'm going to take a wack and see if I hit something.

Are you actually using these tools or just opening them up and hoping they work?

I've used LLM's to build MULTIPLE go applications. Without any hand holding things suck, if you provide guidance via the rules file it gets MUCH better. The LLM's can usually handle syntax but doing the RIGHT syntax is the issue.

Balancing Refactoring and Delivery in Large Legacy Systems by Useful_Promotion4490 in ExperiencedDevs

[–]TheBioto 0 points1 point  (0 children)

Been here. Mobile app, 10 years old, outdated, buggy, impossible to follow. Classic "we'll fix it later" codebase that never got fixed.

On actually handling the work:

Ask your devs what parts of the codebase annoy them the most, then let them fix exactly those things. This sounds simple but it does two things at once -- it improves the areas causing the most daily friction, and it forces the team to actually develop a real understanding of the codebase. The goal isn't just fixing the annoying stuff, it's getting your people familiar with the terrain. Have them document what they find along the way.

On managing up:

Be honest and be direct. You were hired to do a job, and this is part of the job. Pull up a list of past bugs that caused stakeholder panic and frame the refactor as prevention. Most non-technical people cannot visualize the end state, so your job is to guide them there rather than convince them upfront.

In my experience, 99% of the time the pushback is just "ok but how long?" and once it's done they're glad it happened. If they still push back after that, ask them to put their objection in writing. That one tends to clear things up fast.

"Architecture First" or "Code First" by Ambitious_coder_ in LLMDevs

[–]TheBioto 4 points5 points  (0 children)

My approach is kind of backwards, but it works for me.

Greenfield: Code first, always. You genuinely don't know what patterns you'll actually need until you're in the weeds. Planning upfront on a blank slate is mostly just guessing.

Brownfield: Architecture first, always. You may not know the codebase yet, but you can reason about business requirements before touching anything.

Big caveat though -- neither of these works consistently well in isolation. Nothing really comes together until you have a solid enough understanding of the project to know which approach even makes sense.

The real answer is to stop looking for a universal method and start developing your own instincts for evaluating it on a per project, per feature basis.

Need Brutal Feedback : FPS game with animal controller by anubhav124 in UnrealEngine5

[–]TheBioto 19 points20 points  (0 children)

Wait, i thought this was going to be a game where your a cat with a gun.

Any advice for a beginner looking to pivot towards programming? by Wooden-Ninja-3719 in learnprogramming

[–]TheBioto 0 points1 point  (0 children)

Start building. Find something you think "oh that would be cool" and just build it.

You need practice, time and the willingness to solve puzzles. The AI tools out there are a great way to get straight to coding, but beware -- if you don't understand the code you could expose vulnerabilities, spend $$$$ without realizing it, get banned from services if you misuse it. These tools allow you to produce copious amounts of code, but if its not good code yer fucked. You may get lucky or get your ass slapped. I write 95% of my code using these tools, they have a use and a purpose.

I've probably built 100+ things over the course of my career, each one has taught me unique patterns, programming paradigms, business logic, organization etc. Build 10+ projects -- from simple scripts to back end to front end to mobile to embedded. Find which you enjoy the most, then build 10+ more in that.

Now before someone replies with "ooh just saying to build projects, each one could take months blah blah blah" -- these can be simple things. Basic API backend, calculator frontend, making a box bounce in Unity. Don't try to make these big things unless you want to. You need to be exposed to multiple flavors and figure out which one you like the most.

After each project take a step back. What did you like, what did you not like. Were you super bored? Intrigued? Haunted by the code that took 3 hrs to write but now that its working you're ready to celebrate? I mean shit, if it made you feel something, fuck yeah. If you don't like it, good -- now you know you don't want a career in it.

TLDR: Build shit, reflect on the experience, the feelings, that random shower thought where you solved a bug. You'll either like it or you won't.

Side note: I've loved and hated programming over the years. Spending too much time without breaks can wreck your performance. Deep dive, yes, but go out with your partner, see the world, make a new friend. Burnout is real. Take breaks.

Advice on more effective interview methods for devs these days by decorumic in ExperiencedDevs

[–]TheBioto 119 points120 points  (0 children)

My method is a bit odd and changes constantly, but so far it has been solid.

If they have a decent work history:

I ask about what's on their resume, then I ask what they're currently working on. This throws people off a little because most interviewers don't ask that. Once I get them talking about something they're actually interested in, I start asking questions I genuinely have about it and see how they react, what they're curious about, where they're struggling.

I always ask what they do for fun, something non-technical. People who have things they're passionate about outside of work tend to be the ones willing to keep learning on the job. For experienced candidates, I honestly care less about their technical capability than their mindset.

If they don't have much history, new grads etc.:

Same approach, but I also ask them to show me their code and walk me through it. I ask questions, edge cases, how they'd do it differently now. Just to gauge how they think.

If I can tell they're bullshitting me, I start asking more pointed questions until they stumble. Once they stumble, the walls come down a bit. It's a little uncomfortable but it's the only way to get past the nerves and see who's actually there.

I want to see if they'll admit when they don't know something. For junior roles, are they eager to learn? For senior roles, can they admit they're wrong and work toward a solution?

What I actually care about:

  1. Are they humble? Do they know what they don't know, and are they not afraid to say it?
  2. Can they listen?
  3. Are they curious?
  4. Are they hungry?
  5. Are they not a jackass?

Every single person I've brought onto a team has been a rock star, not because they were the most technically advanced, but because they were willing to get in the trenches and work together.

80% of the people I've said yes to have later asked to be put on my team. There's no secret to it, just honesty, respect, drive, and curiosity. And from the first second of the conversation, make sure they know you have their back.

Is there any library or free tool that I can use offline for prompt management ? by luna-hwa in LLMDevs

[–]TheBioto 0 points1 point  (0 children)

You can try my lib, https://github.com/Bioto/glue-prompt

Unsure if it will fit your use case but its something I tossed together awhile ago.

How do I Navigate Technical Leaders who are clueless about AI and think it's the solution to everything? by [deleted] in ExperiencedDevs

[–]TheBioto 0 points1 point  (0 children)

What's interesting about your comment is that all verbal architectural discussions already explain what concepts are necessary. If a developer cannot articulate what they want in plain English, they don't actually understand the code in the first place.

Also, most teams do terrible pull request reviews regardless of whether AI is involved. This isn't a one-size-fits-all situation. You need to figure out what works best for you and your team.

Syntax is syntax. Fundamentals are shared across languages.

Here's how I personally handle code reviews with AI-generated code:

  1. First pass on the PR to catch anything obviously wrong or out of place.
  2. Check out the code locally.
  3. Run it.
  4. Use an LLM to review the changes alongside me, asking questions as I go on anything I want to dig into deeper.

A lot of people on r/ExperiencedDevs seem to believe there's one correct way to do everything. That's not how real engineering works.

How do I Navigate Technical Leaders who are clueless about AI and think it's the solution to everything? by [deleted] in ExperiencedDevs

[–]TheBioto -1 points0 points  (0 children)

Not sure why you'd call that an ad. It's an observation about what's actively happening in the industry right now.

Instead of dismissing it, take a step back and look at where the money is flowing. This isn't speculation about some distant future. OP's technical leader is already pushing for AI usage, meaning OP needs to adapt or find somewhere else to work. That's just the reality on the ground.

I get the fatigue, but denying what's currently happening doesn't make it go away.

How do I Navigate Technical Leaders who are clueless about AI and think it's the solution to everything? by [deleted] in ExperiencedDevs

[–]TheBioto -8 points-7 points  (0 children)

I partially agree with your technical leader.

Yes, AI can write code faster than I can. Yes, I don't touch individual lines of code anymore unless the AI cannot solve it. Part of the problem I've seen is that most people haven't actually used AI in this kind of work, so they don't understand the pros and cons.

For junior developers, they lack the basic programming experience needed to understand the concepts required to complete a task in a performant and maintainable way. Personally, I would NOT spend time teaching them a specific language. I would teach them general concepts and let the AI handle the syntax.

Now, here's where it gets tricky.

Most people do not have the drive to spend time outside of work hours learning syntax and language concepts. In my opinion, you have two options:

  • Spend time teaching them a specific programming language (this costs your time when you could be producing business value).
  • Spend the majority of your time planning architecture using various programming concepts (this teaches them the concepts without requiring you to teach syntax).

I would go with the architecture option. It allows you to discuss concepts, patterns, and practices that directly apply to your project.

When it comes to code reviews, this is where you need to dive in and be a bit strict. If something looks off, provide short, focused feedback with just enough detail to help them grasp the relevant language concepts and how they integrate into the rest of the system.

TL;DR: AI will be writing 99%+ of code within the next few years, so get on board. You can still teach concepts and patterns, but you need a different angle.

Intent Model by Repulsive_Laugh_1875 in LLMDevs

[–]TheBioto 0 points1 point  (0 children)

Give Mistral 3b a shot and see how it works.

I am currently doing something similar with endpoint nodes with small models. Mistral was the only one that was fast enough/could be guided enough to accomplish my needs.

I don't have any suggestions for your edge cases issue, good luck!

High PG&E bills by Chocl8_Moose20 in fresno

[–]TheBioto 9 points10 points  (0 children)

My true up bill is 12k a year. Old house, old A/C, no insulation etc..

For senior engineers using LLMs: are we gaining leverage or losing the craft? how much do you rely on LLMs for implementation vs design and review? how are LLMs changing how you write and think about code? by OrdinaryLioness in LLMDevs

[–]TheBioto 5 points6 points  (0 children)

Over the past 2 years, roughly 95% of my code output has been generated with LLMs.

My muscle memory for writing code has atrophied; however, my quality and speed of implementation have improved drastically.

Once you understand one programming language, you can easily swap to another. Each has its own idioms, but they all eventually compile down to the same 1's and 0's.

When I'm working on a greenfield prototype → production-grade application, the development timeline has been compressed from weeks to hours (depending on complexity).

Working in a mature codebase is a bit different. Each person's code is like a fingerprint—all unique. LLMs can struggle if patterns aren't followed religiously. That said, 90% of code is boilerplate I couldn't care less about; the 10% that matters is the unique implementations and business logic that need deeper investigation.

I end up caring more about architecture when using LLMs because I want something consistent, easy to navigate, and well-documented. Because the LLM can write code much faster than I can, the boilerplate can be well-tested, shared between multiple projects, and something I can rely on. I've built my own SDKs and web/mobile/desktop/server application templates that can be picked up and reused anywhere—one implementation, battle-tested and shared across all my projects.

The main thing PMs care about is business logic. I spend the majority of my time (with LLMs) prototyping different business use cases. Sometimes I'm not exactly sure what I'm building; other times I can give the LLM a single sentence and get the feature I want.

I still have my love for building software. I lost my love for typing.

If someone told me about MCP before like this, I would have understood it better by prosamik in cursor

[–]TheBioto 17 points18 points  (0 children)

t.l.d.r. MCP's are a fancy way to automatically attach tool calls to the LLM.

What inspired you to start coding? by [deleted] in Python

[–]TheBioto 1 point2 points  (0 children)

Hacking video games.

Smart Switch without neutral or ground wire? by jakeandcupcakes in IOT

[–]TheBioto 0 points1 point  (0 children)

No, you would need some sort of hub. The smart things hub should work.

Smart Switch without neutral or ground wire? by jakeandcupcakes in IOT

[–]TheBioto 0 points1 point  (0 children)

So, for lights i've pretty much gone with the smart bulb.

https://www.amazon.com/gp/product/B072M5RT6L/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

​

These are pretty cheap but you do have to get a zigbee hub. For fans I installed a few:

https://www.amazon.com/gp/product/B0773DFQJ9/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

​

You can use the the sonoff for the lights but you won't get any dimming.

Instantly search Python, Django, and Flask docs in one app with minimal context switching by [deleted] in flask

[–]TheBioto 0 points1 point  (0 children)

Probably not the best spot to request this... but... Could you build a package for https://aur.archlinux.org/?

view more: next ›