[podgorniy]

Yeah, we again have a solution (LLMs) in search of problems.

Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z".

--

This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..

[raw_anon_1111]

This is categorically not true. For almost all of my 30 years it’s been

1. Talk to the business, solve XYProblems, deal with organization complexity, learn the business and there needs.

2. Design the architecture not just “the code”, the code has to run on something.

3. Get the design approve and agree on the holy trinity - time/cost/budget

4. Do the implementation

5. Test it for the known requirements

6. Get stakeholder approval or probably go back to #4

7. Move it into production

8. Maintenance.

Out of all those, #4 is what I always considered the necessary grunt work and for the most part even before AI especially in enterprise development where most developers work has been being commoditized in over a decade. Even in BigTech and adjacent codez real gud will keep you as a mid level developer if you can’t handle the other steps and lead larger/more impactful/more ambiguous projects.

As far as #5 much of that can and should be done with automated tests that can be written by AI and should be reviewed. Of course you need humans for UI and UX testing

The LLMs can do a lot of the grunt work now.

[zelphirkalt]

I see step 4 as interwoven with other steps. The implementation ideally takes into consideration the domain and while implementing, potentials for flexibility are potentially revealed, to be taken advantage of, "without programming ourselves into a corner". Implementation also is of course related to maintenance. Maintenance already needs to be taken into account. How easy is it to adapt the system we are building later?

This all happens while we are at the implementation stage and impacts all other aspects of the whole thing. It is a grunt work, but we need elite grunts, who see more than just the minimal requirements.

[raw_anon_1111]

I’ve been going on about this in another thread in a separate post. That’s where modularity comes in. From code I write to teams (or multiple teams back in the day). I always enforce micro services. Not always separately deployable micro service, they could be separate packages with namespace/public/private accessibility.

Even if you do have not so good developers, they can ramp up quickly on one specific isolated service and you can contain the blast radius.

This isn’t a new idea. This was the entire “API mandate” that Bezos had in 2002. s3 alone is made up of 200+ micro services