The best time to solve personal problems with those techniques, perhaps. That is not the same as (and might be opposed to) the best time to seek employment or go into business using those techniques; there isn't going to be much of a market for things that your (employer's) potential customers could trivially do themselves.
> What I wanted was to say “hey Siri, call Claw Phone” and have the audio system in my Toyota become an IDE. So I build it.
Or just focus on driving? Why we are doing it to ourselves? It seems so toxic to fill every possible little moment with… productivity? Is it even productive?
This comment is too emotional but i just felt so sad while reading this
This is just an advertisement, it's not about being a "duct tape engineer", and the various coding agents are already great duct tape engineers, so I can't imagine someone writing a compelling blog post about it anyway.
I tend to call this sort of "I glued a bunch of external services together to make a useful tool" Software Plumbing, not Engineering.
Anyways I think what you've demonstrated that it's actually a really bad time to be a "Duct Tape Engineer" because anyone with a bit of knowhow can coax the AI to build them some pile of loose data pipes and leaky abstractions that appears useful. The market for this sort of software builder is about to get very crowded
I see this sentiment constantly. AI tooling is better than ever and its making building things easier than ever. I have respected coworkers who say that are maxing out multiple $200/month subscriptions.
But I have yet to see any results? Where is the useful stuff?
I feel as if a lot of this what Google home (or other "home like" products) could have been and they have failed miserably. As a Google home user I find it can't answer the simplest questions that would require even the hint of an integration within Google's own ecosystem.
The good times are yet to come though: when all the slop held together by spaghetti, duct tape, chewing gum and hairballs starts falling apart and someone needs to fix it. If the slop bubble doesn't start popping soon, in 10 years a handful of people will end up being better paid than COBOL developers are now cause they'd be the only one that know what a compiler is. Personally I'm not too enthusiastic about the prospect so if I'm lucky, I'll be enjoying early retirement and watching all hell break loose from a camper van near the sea somewhere.
This has been the the case all the time: most of our work are connecting pipes using glue code/duct tape so to speak. But now, we are delegating this to AI. Nothing new for me.
I get that many people are tired of too many AI posts and there's an influx of negative comments but I think this is genuinely amazing. Think about watching Star Trek in the 60s and seeing people talk to computers and them understanding and being able to communicate back. We're literally living in the future!
This week I built https://github.com/infogulch/caddy-zone-manager, "A Caddy app that performs desired-state synchronization of DNS records to a target zone using Caddy’s existing libdns DNS-provider ecosystem."
I thought that since caddy is already managing dns records anyway to pass DNS-01 ACME validations and update HTTPS records, wouldn't it be nice if I could just have it manage all of them and keep my desired DNS state checked into git?
This is exactly the duct tape scenario. There are a bunch of systems that bound the problem: Caddy's app lifecycle, the Caddyfile configuration system, libdns interfaces, DNS semantics, the Go language. Sure, there are a lot of little decisions that need to be made that fall into the "taste" category (no promises), and the sync engine itself is a new brand component, but by and large once the idea was formulated the problem domain is narrow enough for an LLM to stitch the systems together.
It was done in about two days of personal time. I read through all the code and rewrote a good portion of it manually. I probably could have written it from scratch myself with two weeks of full time effort (honestly I would have stumbled a bit on DNS recordset semantics which I was not very familiar). Instead it cost me $100. (I will reconsider my LLM usage patterns for the next project...)
17 comments
[ 4.6 ms ] story [ 39.0 ms ] threadI didn't write a blog post.
Or just focus on driving? Why we are doing it to ourselves? It seems so toxic to fill every possible little moment with… productivity? Is it even productive?
This comment is too emotional but i just felt so sad while reading this
Anyways I think what you've demonstrated that it's actually a really bad time to be a "Duct Tape Engineer" because anyone with a bit of knowhow can coax the AI to build them some pile of loose data pipes and leaky abstractions that appears useful. The market for this sort of software builder is about to get very crowded
But I have yet to see any results? Where is the useful stuff?
I thought that since caddy is already managing dns records anyway to pass DNS-01 ACME validations and update HTTPS records, wouldn't it be nice if I could just have it manage all of them and keep my desired DNS state checked into git?
This is exactly the duct tape scenario. There are a bunch of systems that bound the problem: Caddy's app lifecycle, the Caddyfile configuration system, libdns interfaces, DNS semantics, the Go language. Sure, there are a lot of little decisions that need to be made that fall into the "taste" category (no promises), and the sync engine itself is a new brand component, but by and large once the idea was formulated the problem domain is narrow enough for an LLM to stitch the systems together.
It was done in about two days of personal time. I read through all the code and rewrote a good portion of it manually. I probably could have written it from scratch myself with two weeks of full time effort (honestly I would have stumbled a bit on DNS recordset semantics which I was not very familiar). Instead it cost me $100. (I will reconsider my LLM usage patterns for the next project...)