upvote

points

by ctkhn1 days ago |
comments
upvoteby toast01 days ago|
next
[-]
What really seems to make a difference is how well the project and the organization are at being split into indepedent groups.

I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others.

The more your group can work without needing a meeting with other groups, the more things can progress in parallel.

Some projects won't work well with that constraint though. And some organizations won't either.

reply
upvoteby dwattttt1 days ago|
parent|
next
[-]
I've heard that project architecture has a strong enough impact on feature completion rate that you can infer how tightly coupled vs loosely plugin based it is just from graphs of feature release.
reply
upvoteby LtdJorge1 days ago|
parent|
prev|
[-]
It’s like distributed transactions, or cache-coherency protocols for CPUs.

Edit: aaaand I hadn’t read the article

reply
upvoteby reinitctxoffset1 days ago|
prev|
[-]
I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session?

But it's secondary.

The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint.

That is where one competent senior hacker tops out today. The agents are yielding to a CI that gets 35% per-vCPU occupancy.

The wall right now is skill or build, depending on your skill.

reply
upvoteby trollbridge1 days ago|
parent|
[-]
What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.
reply
upvoteby reinitctxoffset1 days ago|
parent|
[-]
There are low-insensity regimes where it's all Python or whatever, and if you're in one, great.

When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build.

Fable can't print a Tauri faux-native app without dragging in half of LLVM.

reply
upvoteby trollbridge13 hours ago|
parent|
[-]
For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to get stuff done since we have all that, to the point I can leave Qwen 3.6 running in 24/7 loops accomplishing things.)

If your build is bloated and slow, it would seem prudent to go and fix that, possibly converting a codebase from some other language or build system to something that can be built and tested very quickly. Slow builds and slow unit tests are a choice.

reply
upvoteby reinitctxoffset10 hours ago|
parent|
[-]
I'll contend that any Rust build involving Cargo is bloated and slow. `rustc` is impressively slow on a translation unit basis, and Cargo is basically a build recursion bingo card. Throw in about 900 micro point releases in flight at any given time?

If you're not running an elite `bazel` or `buck2` RBE with `nativelink`? You're not even playing.

reply
upvoteby trollbridge9 hours ago|
parent|
[-]
I make sure projects are split into much smaller units so we don’t need some gargantuan bazel based build.

Having a bloated, barely-maintainable codebase and a build that takes hours and needs 100GB of storage is not a badge of honour.

reply