The ST had some awesome productivity programs. Tempus Word, Papyrus, Calamus...
All running on a 8 Mhz computer with 1 or 2 MB, but with feature sets that do not need to hide from today's software.
People doing DTP with Calamus on their Ataris stuck around for a long time after the systems weren't used for much else – MIDI tooling excepted, of course.
On the other hand, there you didn't have that many powerful packages on any system, besides Quark & the various Adobe tools du jour everything paled in comparison.
For word processing, being forced to use Word was/is usually worse than for DTP, though. But feature-wise, everything seemed to converge during the 90s, so "having" to use Word instead of e.g. WordPerfect was less and less of an issue.
With some exceptions of course, most famously GRRM and other people who got into things very early sticking with the first thing they learned (i.e. WordStar), or apparently some journalists being really into XyWrite.
It's not surprising that people who write professionally would learn one tool to the point it gets out of the way and then not want to change. It's not just sticking with the first thing they learned - there's a constant churn of "tools for distraction-free writing" that address some of the complaints that people that still use older word processors have about more up-to-date systems.
Once you know the pattern, every so often you'll see a piece about a writer or journalist and the funky software they use and you can just wait for it... it's going to be Wordstar, XyWrite, one of the XEDIT editors, sometimes Wordperfect for DOS. Rarely Word for DOS. Neal Stephenson uses emacs, but he's an outlier in a lot of ways. I think there was a piece linked here recently by a journalist who uses the macOS TextEdit for note-taking, which dates back to NeXSTEP. (not exactly the same thing, but consider)
Late 1990s supposedly a considerable extension on use of Macs for DTP was that Quark could get significantly automated with AppleScript, and some publishing houses had non-trivial workflows done that way to reduce time spent on preparation.
Maybe it's wishful thinking, being one of the SaaS-developing developers he describes. But I think that only the complexity required for a SaaS is increasing. You certainly can't earn millions with the kind of SaaS that used to take a week or two, and can now be done on a weekend. So I am trying the kind of SaaS that I never dared to start, knowing that it would take a year or two of my spare time. And with AI agents, I now hope to complete it in 3 or 4 months, with a lot of extra features I would never have dared to include in an MVP.
Mainly, a friendly and simple UI. Feedly looks like it hasn't gotten much love recently. Inoreader is too cluttered for my taste, though it has a feature set I can't match any time soon.
I have plenty of other ideas for what to build on top of it: offering an SDK and APIs so you can vibe-code the UI you want, a built-in podcast listener, using news from aggregated feeds to build a personalized AI feed. But the first step is to reach the Google Reader feature set minus social features.
I think you're in a tough market, but I'll agree that Feedly hasn't gotten much love, and is clearly aiming for a more enterprise market.
API access is worth chasing. There was something I wanted to do with Feedly (I've already forgotten what it was) but once I saw their APIs were hidden behind some enterprise level plan, that was the end of that. If we're in a world where everyone has a personal AI agent, giving their agent an API key to their RSS sync account... that might have some interest.
Feedly seems hostile to third-party client access (ie mobile & desktop apps), so being friendlier towards RSS clients could be of interest.
Personalized AI feed is a good idea but you don't have all the personalized year of context that my Claude does. My AI agent is (probably) going to do a better job of choosing the most relevant stuff.
And personally, less interested in podcasts in my RSS app. That's something for Pocket Casts / AntennaPod. I like my audio separate from my RSS. But that's me.
> I think you're in a tough market, but I'll agree that Feedly hasn't gotten much love, and is clearly aiming for a more enterprise market.
Yes, enterprise is certainly where the money is (Feedly's plans start at $1600/month...), but as a solo dev working on a side-project, that's not an accessible market for me anyway. So I try to create a service that's simple and cheap.
> My AI agent is (probably) going to do a better job of choosing the most relevant stuff.
The idea would be basically: the feed reader know the user's interests because of the subscriptions, and knows the last time the user logged in. So it can filter what happened since then; it can also order the posts by relevance, allowing the user to catch up.
And in a second step, an agent could even write the posts dynamically, summarizing information gathered from the user's feed, possibly even adjusted to the user's level of knowledge and offering background info where needed.
> And personally, less interested in podcasts in my RSS app. That's something for Pocket Casts / AntennaPod. I like my audio separate from my RSS.
There are some feeds that are more like a mixture of text and podcast. I usually read only the text, but sometimes it catches my interest and I want to listen to one or two posts. That's when I start hating the lack of podcast support in Feedly.
I'm using (self-hosted) Nextcloud News, what would your... service? Tool? Product? ... offer beyond what NN does? It is quite simple as well, offers an uncluttered interface, keeps my subscriptions as private as RSS subscriptions can be. I suspect you're targeting a different market from the one catered by self-hosted services like Nextcloud?
I am not familiar with Nextcloud News. In the first version, it probably won't offer much for you, besides having a catalog of feeds, the ability to search them, and subscribe with one click, which is usually not offered by non-cloud RSS readers.
For people who do not want to use self-hosted services (which generally includes me), it offers simplicity. Open the page, choose Google as auth provider, confirm, and you will get a friendly start page. Click on 'follow' on one of the feeds, and you can start reading immediately. The UI is more like Facebook or X, so basically, you just need to scroll. Either in a feed of your choice, or all your feeds. It's designed to work well on small mobile screens, tablets, and desktops, with great keyboard support on the latter. Larger screens use two or three columns.
Tough market. What’s your differentiator over Readwise? They are crushing it on the “power user feed reader”.
Best of luck though, I think this is a very promising space. (But my bet is you can do all the interesting stuff in vibe-coded thin UI + OSS pipeline.)
Simplicity. I can get you reading your first feed in under a minute. Also, I am not really thinking about monetization right now, but I am building a feed reader I want to use. I wouldn't want to spend $13 a month for it.
> thin UI + OSS pipeline
No, the UI isn't that thin. I am optimizing it to minimize my costs for operating it. Everything I can do inside the client is done inside the client. Interactions with the server are mostly limited to polling every 2 minutes for feed updates, and sending read markers after 3 seconds of inactivity. Feed data is stored on CDN, compressed.
The kind of clothes we're talking about are not regular clothes. It's the unsellable kind. When H&M is doing a big sale, order the clothes by price, lowest price first. You will find stuff so hideous that they can't even sell it for four bucks. That's what I would expect most of the disposed clothing to look like.
"Agents should work overnight, on commutes, in meetings, asynchronously."
If I read stuff like that, I wonder what the F they are doing. Agents work overnight? On what? Stuck in some loop, trying to figure out how to solve a bug by trial and error because the agent isn't capable of finding the right solution? Nothing good will come out of that. When the agent clearly isn't capable of solving an issue in a reasonable amount of time, it needs help. Quite often, a hint is enough. That, of course, requires the developer to still understand what the agent is doing. Otherwise, most likely, it will sooner or later do something stupid to "solve" the issue. And later, you need to clean up that mess.
If your prompt is good and the agent is capable of implementing it correctly, it will be done in 10 minutes or less. If not, you still need to step in.
> I wonder how our comments will age in a few years.
I don't think there will be a future where agents need to work on a limited piece of code for hours. Either they are smart enough to do it in a limited amount of time, or someone smarter needs to get involved.
> This can't be a serious project. It must be a greenfield startup that's just starting.
I rarely review UI code. Doesn't mean that I don't need to step in from time to time, but generally, I don't care enough about the UI code to review it line-by-line.
> I wonder how our comments will age in a few years.
Badly. While I wouldn't assign a task to an LLM that requires such a long running time right now (for many reasons: control, cost etc) I am fully aware that it might eventually be something I do. Especially considering how fast I went from tab completion to whole functions to having LLMs write most of the code.
My competition right now is probably the grifters and hustlers already doing this, and not the software engineers that "know better". Laughing at the inevitable security disasters and other vibe coded fiascos while back-patting each other is funny but missing the forest for the trees.
We don't have enough context here really. For simple changes, sure - 10min is plenty. But imagine you actually have a big spec ready, with graphical designs, cucumber tests, integration tests, sample data, very detailed requirements for multiple components, etc. If the tests are well integrated and the harness is solid, I don't see a reason not to let it go for a couple hours or more. At some point you just can't implement things using the agent in a few simple iterations. If it can succeed on a longer timeline without interruption, that may be actually a sign of good upfront design.
To be clear, this is not a hypothetical situation. I wrote long specs like that and had large chunks of services successfully implemented up to around 2h real-time. And that was limited by the complexity of what I needed, not by what the agent could handle.
To be fair, for major features 30m to an hour isn’t out of this world. Browser testing is critical at this point but it _really_ slows down the AI in the last 15% of the process.
I can see overnight for a prototype of a completely new project with a detailed SPEC.md and a project requirements file that it eats up as it goes.
10 minute is not the limit for current models. I can have them work for hours on a problem.
Humans are not the only thing initiating prompts either. Exceptions and crashes coming in from production trigger agentic workflows to work on fixes. These can happen autonomously over night, 24/7.
> 10 minute is not the limit for current models. I can have them work for hours on a problem.
Admittedly, I have never tried to run it that long. If 10 minutes are not enough, I check what it is doing and tell it to do what it needs to do differently, or what to look at, or offer to run it with debug logs. Recently, I have also had a case where Opus was working on an issue forever, fixing one issue and thereby introducing another, fix that, only for the original issue to disappear. Then I tried out Codex, and it fixed it at first sight. So changing models can certainly help.
But do you really get a good solution after running it for hours? To me, that sounds like it doesn't understand the issue completely.
Sometimes it doesn't work or it will give up early, but considering these run when I'm not working it is not a big deal. When it does work I would say that it has figured out that hard part of the solution. I may have to do another prompt to clean it up a bit, but it got the hard work out of the way.
>or offer to run it with debug logs.
Enabling it to add its own debug logs and use a debugger can allow it to do these loops itself and understand where it's going wrong with its current approach.
I can think of one reason for letting agents run overnight: running large models locally is incredibly slow or incredibly expensive. Even more so with he recent RAM price spikes thanks to the AI bubble. Running AI overnight can be a decent solution to solve complex prompts without being dependent on the cloud.
This approach breaks the moment you need to provide any form of feedback, of course.
> I don't know what it is, but trying to coax my goddamn tooling into doing what I want is not why I got into this field.
I can understand that, but as long as the tooling is still faster than doing it manually, that's the world we live in. Slower ways to 'craft' software are a hobby, not a profession.
(I'm glad I'm in it for building stuff, not for coding - I love the productivity gains).
Generally, my stance is that I add more value by doing whatever ridiculous thing people ask me to change than waste my time arguing about it. There are some obvious exceptions, like when the suggestions don't work or make the codebase significantly worse. But other than that, I do whatever people suggest, to save my time, their time, and deliver faster. And often, once you're done with their initial suggestions, people just approve.
This doesn't help all the time. There are those people who still keep finding things they want you to change a week after they first reviewed the code. I try to avoid including them in the code review. The alternative is to talk to your manager about making some rules, like giving reviewers only a day or two to review new code. It's easy to argue for that because those late comments really hinder productivity.
Agreed with the points in that article, but IMHO the no 1 issue is that agents only see a fraction of the code repository. They don't know whether there is a helper function they could use, so they re-implement it. When contributing to UIs, they can't check the whole UI to identify common design patterns, so they re-invent it.
The most important task for the human using the agent is to provide the right context. "Look at this file for helper functions", "do it like that implementation", "read this doc to understand how to do it"... you can get very far with agents when you provide them with the right context.
(BTW another issue is that they have problems navigating the directory structure in a large mono repo. When the agents needs to run commands like 'npm test' in a sub-directory, they almost never get it right the first time)
This is what I keep running into. Earlier this week I did a code review of about new lines of code, written using Cursor, to implement a feature from scratch, and I'd say maybe 200 of those lines were really necessary.
But, y'know what? I approved it. Because hunting down the existing functions it should have used in our utility library would have taken me all day. 5 years ago I would have taken the time because a PR like that would have been submitted by a new team member who didn't know the codebase well, and helping to onboard new team members is an important part of the job. But when it's a staff engineer using Cursor to fill our codebase with bloat because that's how management decided we should work, there's no point. The LLM won't learn anything and will just do the same thing over again next week, and the staff engineer already knows better but is being paid to pretend they don't.
>>because that's how management decided we should work, there's no point
If you are personally invested, there would be a point. At least if you plan to maintain that code for a few more years.
Let's say you have a common CSS file, where you define .warning {color: red}. If you want the LLM to put out a warning and you just tell it to make it red, without pointing out that there is the .warning class, it will likely create a new CSS def for that element (or even inline it - the latest Claude Code has a tendency to do that). That's fine and will make management happy for now.
But if later management decides that it wants all warning messages to be pink, it may be quite a challenge to catch every place without missing one.
There really wouldn't be; it would just be spitting into the wind. What am I going to do, convince every member of my team to ignore a direct instruction from the people who sign our paychecks?
I really really hate code review now. My colleagues will have their LLMs generate thousands of lines of boiler plate with every pattern and abstraction under the sun. A lazy programmer use to do the bare minimum and write not enough code. That made review easy. Error handling here, duplicate code there, descriptive naming here, and so on. Now a lazy programmer generates a crap load of code cribbed from "best practice" tutorials, much of it unnecessary and irrelevant for the actual task at hand.
> When the agents needs to run commands like 'npm test' in a sub-directory, they almost never get it right the first time)
I was running into this constantly on one project with a repo split between a Vite/React front end and .NET backend (with well documented structure). It would sometimes go into panic mode after some npm command didn’t work repeatedly and do all sorts of pointless troubleshooting over and over, sometimes veering into destructive attempts to rebuild whatever it thought was missing/broken.
I kept trying to rewrite the section in CLAUDE.md to effectively instruct it to always first check the current directory to verify it was in the correct $CLIENT or $SERVER directory. But it would still sometimes forget randomly which was aggravating.
I ended up creating some aliases like “run-dev server restart” “run-dev client npm install” for common operations on both server/client that worked in any directory. Then added the base dotnet/npm/etc commands to the deny list which forced its thinking to go “Hmm it looks like I’m not allowed to run npm, so I’ll review the project instructions. I see, I can use the ‘run-dev’ helper to do $NPM_COMMAND…”
It’s been working pretty reliably now but definitely wasted a lot of time with a lot of aggravation getting to that solution.
Large context models don't do a great job of consistently attending to the entire context, so it might not work out as well in practice as continuing to improve the context engineering parts of coding agents would.
I'd bet that most the improvement in Copilot style tools over the past year is coming from rapid progress in context engineering techniques, and the contribution of LLMs is more modest. LLMs' native ability to independently "reason" about a large slushpile of tokens just hasn't improved enough over that same time period to account for how much better the LLM coding tools have become. It's hard to see or confirm that, though, because the only direct comparison you can make is changing your LLM selection in the current version of the tool. Plugging GPT5 into the original version of Copilot from 2021 isn't an experiment most of us are able to try.
Claude can use use tools to do that, and some different code indexer MCPs work, but that depends on the LLM doing the coding to make the right searches to find the code. If you are in a project where your helper functions or shared libs are scattered everywhere it’s a lot harder.
Just like with humans it definitely works better if you follow good naming conventions and file patterns. And even then I tend to make sure to just include the important files in the context or clue the LLM in during the prompt.
It also depends on what language you use. A LOT. During the day I use LLMs with dotnet and it’s pretty rough compared to when I’m using rails on my side projects. Dotnet requires a lot more prompting and hand holding, both due to its complexity but also due to how much more verbose it is.
Well, sure, but from what I know, humans are way better at following 'implicit' instructions than LLMs. A human programmer can 'infer' most of the important basic rules from looking at the existing code, whereas all this agents.md/claude.md/whatever stuff seems necessary to even get basic performance in this regard.
Also, the agents.md website seems to mostly list README.md-style 'how do I run this instructions' in its example, not stylistic guidelines.
Furthermore, it would be nice if these agents add it themselves. With a human, you tell them "this is wrong, do it that way" and they would remember it. (Although this functionality seems to be worked on?)
These days, AI can do much more than "Cranking out boilerplate and scaffolding, Automating repetitive routines". That was last year. With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though. Like "implement this table, add these fields, look at this and this implementation for reference, don't forget to do this and consider that." Mention examples or name algorithms and design patterns it should use. And it still doesn't always do what you want on the first attempt, and you need to correct it (which is why I prefer Claude Code over Copilot, makes it easier). But AI can write pretty much all code for a developer who knows what the code should look like. And that's the point: junior developers typically don't know this, so they won't be able to get good results.
Most of the time, the only reason for typing code manually these days is that typing instructions for the LLM is sometimes more work than doing the change yourself.
> With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though.
By your own statement then this is not an "easy" task.
Software development has never been "hard" when you're given specific instructions.
Sometimes that happens:) The key is to recognize these situations and not go down that rabbit hole. But sometimes it allows me to do something in 20 minutes that used to take a whole day.
Right, and where, if I may ask, are all those business applications that write themselves? Because all I see is a clown party, massive wasted resources and disruption to society because of your lies.
I guess it turned out that coding is not the only limiting factor. Internal processes, QA, product management, coordination between teams become significant bottlenecks .
Also, they don’t help much with debugging. It’s worth a try, and I have been surprised a couple of times, but it’s mostly still manual.
BTW I never said they write themselves. My point was rather that you need a lot of knowledge, and know exactly what you want out of them, supervise them and provide detailed instruction. But then they can help you create a lot more working code in a shorter time.
At that point it seems to me that they become a distraction, a filter between you and the software you're building. Surely it must be easier to tell the computer directly what to do then to route the entire design through that mess?
I wouldn't call it a filter, unless you use it for trivial tasks ("check that the input argument is not null, throw an exception otherwise"). Sometimes it is useful for trivial tasks though, because it may do things a human dev would be to lazy to do. It also tends to be faster at finding things (as in "change the color of the submit button on the address form to #f00").
But the real value is implementing known patterns that are customized for your application. Adding a field or a new type to a CRUD application, implementing an algorithm, rendering some type of object in a UI...
reply