[–] 1 point 1 day ago

The last item is really important to show the management. We vibecoded a ticket cataloguing script to show that infinite speedup in codegen will bring only x% speedup overall

As for tech debt, it has 2 components: figuring out what to do, and actually doing it. I've often found that sometimes there's no time because the proper fix would need weeks of work. LLM have helped reduce that to a few days of work, including reviewing the PRs.

If your colleagues are low tech, I really feel for you. This will make them feel really productive but essentially pile on shit

  • source
  • parent
  • context
  • [–] 2 points 2 days ago (2 children)

    Use the AI to fix technical debt. A lot of the changes needed to make codebase good were just humanly not possible (given the priority and urgency), but now you have a stochastic parrot to do the grunt work.

    Setup CI, align docs to actual code, improve interfaces, refactor for the long term and not just what the next ticket needed. Treat it like free labour for some easy but time consuming stuff aka intern.

    Using it per ticket without removing old debt will incur more debt. Once you are happy enough with the codebase that giving a ticket to a really capable but still stupid intern isn't gonna result in unmanageable shit, then you can start tackling tickets with LLM harness like: adding a MCVE or checking if a ticket has enough info.

    Outright solving tickets with AI will result in the team getting increasingly unfamiliar with their own codebase making. That will have similar effect has hiring a new senior engineer to any project with no team and only interns (LLM): lots of ideas and capabilities but almost all of the time is spent in understanding the effing codebase.

    Using random ass scripts to make certain ticket managers happy will 'help now', but it'll be really bad for a team of 10. Increasing velocity needs a large magnitude (ticket size * ticket count) as well as the right direction (based on codebase) so the mgmt strategy is bonkers.

  • source
  • parent
  • context
  • [–] 3 points 2 days ago (2 children)

    Earlier bombs were unreliable. It wasn't rare to have an entire squadron in multiple sorties to target a single bridge even in uncontested skies.

    The bad navigation and aiming equipment as well as dumb bombs resulted in COP to be in 100s of meters in best case. This was exacerbated by flaky mechanisms: better to have UXO than to accidentally grief some ground staff.

    That's mostly what we see today. Bombs in random areas because the flight lost track of position or met a cloudy patch of skies on the target and decided to drop the payload to maintain their return range.

  • source
  • parent
  • context
  • [–] 1 point 2 days ago

    Let me introduce you to your new best friend: regulatory capture. This gives you the worst of all: low cost of doing business with high deregulation similar to self-regulation but with the ability to point to the regulatory body for any high profile issues

  • source
  • parent
  • context
  • [–] 2 points 5 days ago

    It's not that simple from the manufacturers perspective.

    Setting up a new fab takes years. Usually 5 or more for a grounds up build. Less for an upgrade (1-2 years or so). Lots of in-progress fabs have been sped up and we will see more supply sooner, but not soon enough.

    Making less HBM and more DDR RAM doesn't make sense for $hareholders, so we are stuck with getting supply at a trickle such that the marginal cost for both is equal or it's a contract with a penalty larger than any profits

  • source
  • parent
  • context
  • [–] 5 points 6 days ago

    Simply lovely. There long names are for mounting since they are persistent w ross reboots.

    The short ones can change of there are no mounting options or more or fewer devices than before.

    PS: even the networking devices have this funky naming

  • source
  • parent
  • context
  • [–] 1 point 1 week ago

    Once a model knows python 3.14 there's little need to update it until 3.14 is EOL. Most professional settings pin dependencies and runtimes and only move them for security issues or planned migrations.

    Several embedded platform only support C++14 as the latest target. That's a lag of 10 or more years. This is similar to how the calculator chips are redone once a decade or so depending on new fab process giving enough benefits. Once something gets used for years, a large investment makes more sense than the current senseless frontier models every month or two.

  • source
  • parent
  • context
  • view more: next ›