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.
I've been looking for a personal finance app for a long time. I don't want a Saas that charges me monthly and can shutdown at anytime. Most other homebrewed apps are incomplete or abandoned. Of all things I ended up paying for an Excel sheet to track it all - https://cspersonalfinance.io/
This tracks all my cashflows, investments, net worth etc, and since it's in excel there's no risk of it disappearing after 10 years
This is so good. I've tried so many homebaked spreadsheet trackers and semi-complete side project sites. This one looks like it strikes a good balance between feature completeness and simplicity
Sounds like your lead engineer setup NX too soon. we made it about 5 years in to our monorepo before having to use tools like that. Once we were at a point where our codebase included multiple products, apis, frontends was when build and test times became unbearably slow and only then did we add NX to conditionally build changes and their dependants. I wouldn't recommend starting a new project with it by any means.
This is what would do it for me. I make planning and big decisions once or twice a year where having write access is needed. I'd be happy to pay $14 for it.
For the rest of the year I'm just checking in from time to time to see how I'm tracking against the plan, so a free read-only mode would be ideal.
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.