I sometimes wonder if I'm in a different universe to other devs. Anytime AI coding is brought up, comments are overwhelmingly negative and often point out correctness, quality, slop, etc.
There's also the 'more stuff is being delivered, but it's not right, full of holes and papercuts'.
I'm 22 years into development and couldn't think of going back to non AI programming now. Not only has it sped up velocity by an order of magnitude, it's also helped me unlock side projects that I would never even begin in the past as I knew I didn't have that time.
It's just like any tool though, and I've found enormous differences in outcome depending on how you drive it. Launching into 'build this' and expecting it to output code that you would manually write would not get you there; and I feel this is where most developers stall out.
Getting the right outcomes takes a lot of harness set up - the same as if you wanted to hire new devs and get them productive without peering with them. You would set up linting, good test coverage and approaches, thorough documentation about what your project is, the domain, the architecture etc. This at least gets good code consistency for the most part.
For how to build, https://github.com/bmad-code-org/BMAD-METHOD is really good and I've onboarded a few Saas projects into it now. Tech speccing and multiple cycles of elicitation are what deal with all the edge cases that you normally only encounter during coding. It does front-load all of the planning brainwork; but condensing that into a couple days of solid speccing is far more productive than spreading it out over months.
It's taken a while to get to this point, and most agents aren't good for substantial work out of the box. Most of the time what the agent does will be a product of its environment.
When I saw Jensen's talk about how Openclaw surpassed React and Linux in terms of GitHub stars within a few months, I knew the whole thing was manufactured bot hype.
No one can tell me a compelling use case. The whole thing seems designed around getting people to burn more tokens.
I agree in general, but there will always be certain requirements and team structures where stuff like this makes sense.
For me, I work in a small team of 6 devs on an ever growing app and feature set. I 100% will leverage managed services where cost and complexity allow. SQS is one of the most stable and cheapest AWS service, and the ability to just use it and not have to sysops it means we can spend more time building features.
I highly recommend strength training. To anyone. But especially us developers.
Big compound lifts like squats, deadlifts, rows etc all hit a lot of muscle and posterior groups and have made my back bullet proof.
It doesn't take a lot of equipment - any commercial gym with a power rack, or BYO home gym with a rack and barbell will do. Start with a simple program like Starting Strength and then pivot to something more intermediate friendly when you get there like 531. You can run these programs for decades.
I didn't quite understand why this was made. We create our local test environments using docker-compose, and so I read:
> Creating reliable and fully-initialized service dependencies using raw Docker commands or using Docker Compose requires good knowledge of Docker internals and how to best run specific technologies in a container
This sounds like a <your programming language> abstraction over docker-compose, which lets you define your docker environment without learning the syntax of docker-compose itself. But then
> port conflicts, containers not being fully initialized or ready for interactions when the tests start, etc.
means you'd still need a good understanding of docker networking, dependencies, healthchecks to know if your test environment is ready to be used.
Am I missing something? Is this basically change what's starting your docker test containers?
I paid for the UI kit early last year and think it's good value. The amount of time its saved me has more than paid for itself, and it's just nice to have something that isn't a subscription model, or licensed per project.
There's also the 'more stuff is being delivered, but it's not right, full of holes and papercuts'.
I'm 22 years into development and couldn't think of going back to non AI programming now. Not only has it sped up velocity by an order of magnitude, it's also helped me unlock side projects that I would never even begin in the past as I knew I didn't have that time.
It's just like any tool though, and I've found enormous differences in outcome depending on how you drive it. Launching into 'build this' and expecting it to output code that you would manually write would not get you there; and I feel this is where most developers stall out.
Getting the right outcomes takes a lot of harness set up - the same as if you wanted to hire new devs and get them productive without peering with them. You would set up linting, good test coverage and approaches, thorough documentation about what your project is, the domain, the architecture etc. This at least gets good code consistency for the most part.
For how to build, https://github.com/bmad-code-org/BMAD-METHOD is really good and I've onboarded a few Saas projects into it now. Tech speccing and multiple cycles of elicitation are what deal with all the edge cases that you normally only encounter during coding. It does front-load all of the planning brainwork; but condensing that into a couple days of solid speccing is far more productive than spreading it out over months.
It's taken a while to get to this point, and most agents aren't good for substantial work out of the box. Most of the time what the agent does will be a product of its environment.