I started using Emacs 30 years ago. Used it as my main code editor for 15 years, and as my note-taking editor a little longer. I did write my share of elisp code, had a lot of fun with it, posted on gnu.emacs.sources back in the day, and shared a lot.
Emacs is still my main editor over ssh, so I happen to use it on a regular basis, and the commands are all imprinted on my fingers' muscle memory, so that's quite the comfort zone.
My SO works in legal and regulatory compliance, she needed a small app (worflow with a form and a validation process), CTO said they could not do it, too complicated, would cost 15 days for a freelance and rejected it.
She called it BS, and the next day she spent the morning with ChatGPT using their internal Microsoft-based tooling, and the app was done.
She was hyped for the day, with a feeling of accomplishment and is already thinking of another project.
And I'm hearing similar stories every week.
So yes, LLM have positive impacts in many business domains, but seeing people happy and enpowered with their home-made little apps, I think it's the best.
We've heard of "Shadow IT" now we have "Shadow SWE" and "Shadow CI/CD".
It used to be that someone wanted unfettered Internet access, and they were disgruntled with the company's firewall or proxy policy, and so they brought in a modem, and hooked it up to their desktop PC, and started dialing out on some analog line that the company didn't even know they had. Then it's all fine for 3 years until some malware gets discovered, and then IT discovers who-all had unauthorized lines that weren't being scanned or filtered at the company firewall. Same thing happens with WiFi APs today, of course.
I was working for a company that really offered no in-house software or tools to run. But my new supervisor was asking me to closely track my time. So I signed up for some SaaS that would let me log activities and track my timeslices, so I could show a graph or table later on and see what I was doing. I used it for a few weeks. It was real effective. But what I realized down the line, was that all the notes I was typing into this 3rd-party SaaS, were revealing company confidential information. And ultimately, I felt very uncomfortable about revealing what I was doing, on an unannounced and private project, and without authorization or even notifying my employer's IT department. So I shut it all down, and I had to do it with pen and paper, but that felt secure enough.
So if people are going to feel empowered by vibe coding their own bespoke apps, I hope their IT department comes down like a ton of bricks, and tells them to knock it off. Because it is not worth the tech debt, support costs, and ultimately the massive security problems and infoleaks. If your employer won't give you what you need in these terms, then maybe it's just not important to them in the first place.
For most businesses, it’s going to be business as usual. By the time businesses see the benefits of AI, their competitors that actually leveraged AI will have pulled too far ahead.
If the original company has distribution, they can likely catch up, but the gap we see between AI-first companies and the companies not utilizing AI will broaden exponentially in the coming years.
And I'm sure the business logic has been validated and tested, the hosting and execution medium has been secured, and hooking up to a curated and vetted internal package manager mirror so as not to get hit with 0-days during a shai hulud-esque attack, and of course the executable is being scanned for vulnerabilities, and as the app needs to evolve in the future it will be able to do so with no problems whatsoever.
If her company has any brains, they'll tell her to stick to her job and not waste time on untested software developed by somebody who has no clue what they are doing.
I’ve had two separate similar experiences. The most impressive was my little sister publishing an app on both Google and Apple AppStore’s with subscription payment support. She didn’t even know what an Apple developer account was. I gave her a three line prompt to get started and then she took it from there. She built an LMS for HS students that gets them in shape for college admissions. She has a supabase backend, AI generated videos, quizzes, more content, and all the usual mobile app bells and whistles, she made it through all the paperwork of App Store submission/review/publishing on both platforms including inviting some beta testers. Her workflow was telling ChatGPT what she wanted and then asking that model to talk to claudecode. It doesn’t sound like much but keep in mind she has absolutely zero code or tech experience. I told her she did about a $75k project on her own in maybe 1/5 the time and it blew her away.
It may be a success or maybe not who knows but she did it. I think she has 4 or 5 paying customers.
hey - supabase ceo/cofounder here. Please tell your little sister that I’m happy supabase could be a small part of her builder journey, and good luck with her app. My email is in my bio if she has any product feedback
Yes maybe the long term impact will be there won’t be a technology sector (at least not so dominant as it is now). Instead companies in other industries will have larger technology functions with teams of agents.
I really love these stories - as a contractor who fixes the badly implemented shadow IT crap
aaaand let me guess? have they assessed whether this tool needs backups? monitoring? resilience? patching? obviously in 5 years time the author would have left leaving NO documentation on a mission critical 'small' app - likely hosted with a shit ton of other mission critical crap
It's MS Access all over again, my future rates are looking good
> have they assessed whether this tool needs backups? monitoring? resilience? patching? obviously in 5 years time the author would have left leaving NO documentation on a mission critical 'small' app - likely hosted with a shit ton of other mission critical crap
Or, hear me out, it's not actually "mission critical" and none of this stuff matters. They made their job easier in a small way, good for them.
> It's MS Access all over again
In that it's a convenient tool that a lot of people find useful?
Yup. So many bozos giving those of us that know our asses from our heads job security far into the future. Yeah it's gonna suck to actually do the work a lot of the time, but the irresponsible generating insane amounts of tech debt that people that know what to do is a tale as old as the outsourcing craze and codeless tools, and frankly, probably COBOL.
If "70% of Canadian exports are to the US", that's probably why the US has so much leverage, and I can see why the Canadian government would like a change.
Hence the need for a rebalancing of trade partnerships.
I'd like to take a closer look at what exactly Canada is exporting to the US, and what exactly the EU is importing from elsewhere, to see if there's a match. I'd rather buy from Canada than from Russia. Or China. Or the US.
You know how despite climate change being very real, in day to day discussions with other level headed people, they still very regularly say stuff like
"We ran the numbers for an EV, and right now gas is still cheaper, so we are holding off on the switch until it makes financial sense"
Canadian oil would need to be shipped halfway around the world. It would be more expensive. Price is always the top factor for everyone.
Fair point. What we really need of course is more renewables, and that is happening, but not fast enough, so we still need oil. And I'd rather get our oil in a way that doesn't fuel the Russian war machine, even if it does cost a bit more.
The politically-important Alberta oil mostly goes to the mountain states down here. Coincidentally, those same states rely heaviest on coal for electricity. So, the choice is recharge an EV on coal (think arsenic and mercury accumulating somewhere nearby) or good ol gasoline (which is piped from Canada).
I think what you’re wondering is: can residential electricity schedules promote off-peak rates for EV charging. I’ve seen that and I think it takes the edge off.
But we’re in a drought right now. I think hydro is down at least 20%. Wyoming wind power alone totally makes up for that.
I’m sure China would, too. I wonder what’s harder: diverting that oil to the northwest passage, or diverting Persian Gulf oil around the strait of Hormuz?
Right… so why do you think the US imposed tariffs? Germany is already seeing gigantic problems via declining exports because of China. Are they going to stop exports to the United States too?
The EU can’t add any more “trade bazooka” than it already has. Canada doesn’t change anything in that dynamic.
I mainly use them as macros. Not even an advanced and smart macro system, just plain basic macros to avoid copy-pasting recurrent prompts. Is there more to them?
I basically create a skill when I'm tired of always writing the same prompts, and then I adapt it over time.
I have like 3 skills, and so far so good, most of my recent changes have been asking Claude to please stop using metaphors and creative figures of speech that make the documents so much harder to read and understand (maybe it's only annoying to non-native speakers, I don't know)
«It uses an architecture where everything is a plugin»
Ok, that's enough for me. I have developped over the year a plugin fatigue.
Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, deprecated, incompatible plugins, with no consistency and no governance.
I understand how attractive it can be to companies to think, hey, let's make a very small product and rely on other people to make features, and I hope it works, but I'm personally staying away from that.
This works pretty well for these coding harnesses though (see Pi). I like the model where the harness ships with minimal tools and you can spin up plugins for extra functionality. You can usually have the model/harness you're using just create the plugin that you need for you. The advantage of this is that these harnesses aren't optimized for their frontier models like claude/codex are so you can fine tune your environment and burn less tokens... having said all that, I haven't tried this one yet.
> Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare
Eclipse has been thriving since 2002 mostly by virtue of being able to coordinate developers via plugin's and a business-friendly license.
They did need to upgrade early plugins into OSGI, and most of the new plugin designs benefit from copying OSGI, et al. The key is SAT solvers for dependencies and namespace separation, not forcing clients into the same dependency version.
But as you suggest, relying on the community is a moral hazard. In Eclipse there were big players willing to fund key use-cases for their own purposes; elsewhere I've seen sufficient monetization of plugins to offer incentives and stability.
I would add that VSCode plugins follow a different development model. While any OSGI/Eclipse plugin can provide an interface, I believe in VSCode you're limited to the API's they give you (and they make a mess of them, so there's more inconsistencies e.g., in LSP support that anyone can enumerate).
Everyone thinks their workflow is a special snowflake.
Truth is that useful dev workflows and tooling probably coalesces in a tight band. There's really no point in re-inventing the wheel over and over again at this level (the raw tooling).
I don't really like about 98% wheels other people made. Usually they do almost what I want and their UX is horrible. And people asked about how could I get the missing parts gleefully respond that I shouldn't want that. And when I'm bothered by UI they say it's fine and it doesn't matter. I'm not completely unique but being cut to size hurts.
Everything about harness design is still experimental and janky. Throw everything in a pit and let the fittest survive. Large opinionated software is unlikely to survive and more likely to give you a migration fatigue
These types of projects can have a happy ending, but only if the product is popular enough and the plugins are essential to the core functionality. Plugins usually die off because the sole maintainer loses interest, but popularity and necessary can bring new maintainers to carry the torch.
Most vendors that create a plugin-based system end up creating a large library of plugins to kickstart the ecosystem, which many users end up trusting those more because they're "official", so they essentially created an mono-vendor ecosystem with extra steps.
Many of the libraries and executables in Linux are cross-compilable with other ecosystems. It's the difference between opening the door to an existing ecosystem and birthing one.
For a lot of code, I switched to generating code rather than using 3rd party libraries.
Things like PEG parsers, path finding algorithms, string sanitizers, data type conversion, etc are very conveniently generated by LLMs. It's fast, reduces dependencies, and feels safer to me.
Lol. My most recent comment before this one is here: https://news.ycombinator.com/item?id=47583593. You judge if AI threatens my identity. But hey, don't let the facts get in the way of a slick narrative.
Or find the best third party library and copy the code from a widely used version that has been out long enough to have been well tested into your source tree.
The problem is not third party libraries. It is updating third party libraries when the version you have still works fine for your needs.
Don't do this. Use a package manager that let's you specify a specific version to pin against. Vendoring side steps most automated tooling that can warn you about vulnerabilities. Vendoring is a signal that your tooling is insufficient, 99% of the time.
Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages.
If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.
This is only true if you aren’t internally mirroring those packages.
Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.
And this is exactly why we see noise on HN/Reddit when a supply-chain cyberattack breaks out, but no breach is ever reported. Enterprises are protected by internal mirroring.
> Is there any package manager incapable of working offline?
I think you've identified the problem here: package management and package distribution are two different problems. Both tools have possibilities for exploits, but if they are separate tools then the surface area is smaller.
I'm thinking that the package distribution tool maintains a local system cache of packages, using keys/webrings/whatever to verify provenance, while the package management tool allows pinning, minver/maxver, etc.
reply