bmiselis

That's all based on the assumption that if you can build something in 10% of the time it'd take you to build the same thing without AI, then you'll spend this 90% of your new spare time to build something else next. What if you don't and you'll just use that time to spend with your family? The data won't show it.

And that definitely is one of the most severe risks of the human-assisted coding (when humans barely instruct the AI to do the heavy lifting).

I believe LLMs are definitely able to, in some vague sense, understand the code they’re working with. If they’re able to produce meaningful output from the input, especially in abstract problems, they get the gist of what’s being coded, not just the tokens. That’s what they’re storing in their inner representations: higher-level view of the text they’re processing.

Hey, author of the too long; automated blog here!

I had a problem in one of my projects recently: how to deploy my application to multiple cloud environments? The list of requirements was rather short:

--- Git flow must be a no-brainer–we don’t want to deal with multiple branches that will have to be frequently synchronized with one another.

--- Application needs to be versioned.

--- It must be possible to deploy a required version of the application to the selected deployment environment.

--- Every environment runs only one version of the application at the same time.

As I’m a data engineer and enjoy automating repetitive stuff, I added an extra one:

--- Automate manual processes to a reasonable extent.

I think (and hope) that both the end result, and the path that took me there, will be an interesting educational experience for you.

This post is the first one in a short, guided series. It’s titled “One branch to rule them all”, because, as you’ll find out, I’m going to use one long-lived branch to configure all of the deployment environments I need.

If you have any thoughts/feedback on it, I’d be humbled to hear it. Here, or directly on Substack.

Thanks a lot, and stay tuned for the upcoming posts if you enjoyed reading this one!

i love your examples, you know why @nojvek? it's because they clearly show next-level challenges in tech projects, not easily replaceable or automatable. i've always believed that as the world keeps automating, we need to climb the ladder of abstraction - that way you stay (relatively) safe :)

looks really cool, thanks for sharing!

heh, i get you that scope negotiation is outside of the scope (pun intended) of even more advanced automation techniques, same with the tradeoffs you've mentioned.

however! analyzing and understanding codebase enough to decide what to do next... this sounds tempting to dive deeper into.

can i ask what role do you have in your project/company? is it more managerial, or more technical?