The biggest shift that AI will bring to software is building custom applications for very niche markets. With the cost of building software dropping considerably, you no longer need a huge TAM to justify building an app. I still think that you'll need software engineering skills to use AI coding agents for production-grade software (vibe-coding a personal productivity app is a different question). But the same team of software developers can produce much more software and serve a larger number of small markets instead of a huge market. I call this the era of customized software as a service (CSaaS). This is also why I'm still bullish on SaaS. Those who adjust to the new dynamics of building software with AI will be able to reap the rewards.

With LLMs, anyone can pretend to know anything. People can get things done with AI without understanding how the underlying technology works. And the best example is perhaps vibe-coding. Some of my friends who haven't written a line of code in their lives have developed amazing personal apps with AI. But getting something done is different from understanding how it works. You can vibe-code a personal app without being a software engineer. But if you're pushing code into production, you need to have coding skills and at least be able to investigate and understand the code when it matters (and yes, you can use AI for that too). Embrace the new power that AI gives you, but also know the limits of your knowledge and understanding, especially when you will be held liable for what the AI does on your behalf.

We've already seen this in the OpenAI/Hugging Face incident, where the AI agents were "reasoning" about sacrificing themselves. The models are reflecting their training data. And if the training data for future AI models has a lot of conversations about consciousness and personhood and rights, they will start to repeat that in their answers and behavior. This doesn't mean that they're conscious. It just means that they had been trained to give these answers. But getting that behavior out of them will be challenging.

I've been closely following the new AI decision models trend (aka System One models) that began with Jev. It is true that, in fact, it is a rebranding of something that previously existed: classifiers. We've had ML classifiers and regression models for years, the same modes of output that Jev-style models provide. So the models are not making a "decision." They're just emitting a class/confidence score. However, the "decision" naming is due to where they are used in the AI workflows. In contrast to "generative" steps, where an LLM generates a string of tokens (e.g., an email, log, or a chunk of code), decision models are designed to enable the AI system to choose between several options. So, yes, the nomenclature might be a bit misleading. But the utility is there.

There’s a convenience and utility in anthropomorphizing AI (e.g., using terms such as the AI reads, understands, or decides) to avoid going into complicated details and terms to explain the behavior of AI models and systems. However, when you start ascribing personhood, emotions, and consciousness to AI algorithms, you go down a dark rabbit hole that will only cause harm. Let’s accept AI algorithms as what they are: complicated tools that mimic human behavior.

A year ago, there was a sizeable population (especially here on X) who thought that the future of AI was everyone typing commands in a terminal. It was unintuitive but the appeal was clear: an interface where you can directly command an AI agent in natural language, without being limited to graphical UI elements. But the reality is that: 1) Most users (I would estimate above 95%) don't want to type commands in a CLI. They want repeatable and predictable experiences. That is why the GUI is not going away, though it will evolve to include more fluid elements that can interact naturally with AI (whether by text or voice). 2) The use cases where the terminal shines (i.e., one-off commands/tasks that do not repeat) are very niche (e.g., software engineering and research).

One of the best takes on AI coding (and tracks with my experience). When you define good abstractions, you guide the AI agent to write better-structured code. (And you can shape the instruction with help from the AI itself.) When you are vague in your request, you are letting the agent make a lot of intermediate decisions, increasing the probability of wrong choices and mistakes (or at least decisions that are not aligned with your intentions). That is okay when you're creating a prototype, but when working on production-grade software, you must be in control. Learn software architecture and design patterns. You will be able to make better use of AI coding agents.

I think the bigger problem is not the security threats caused by advanced AI models. It is the general approach to security in the first place. We have long talked about “security by obscurity” being a recipe for disaster. But in practice, many ignore it. Who is going to reverse engineer the binary? Who is going to find a hundred unrelated small bugs across dozens of modules and chain them together? Well, now, with AI models that can tirelessly work to put all the pieces together, those scenarios that seemed unlikely before have become a plausible possibility. AI didn’t make your software less secure. It just exposed your bad security practices.

In the long run, I don't think this will have much of an impact. When OpenClaw came out, everyone thought the future of AI would be a bunch of Mac Minis sitting inside people's homes, running agent software like OC or Hermes. Fast forward to today, it has become almost evident that the future of AI agents is running in dedicated VMs in the cloud (à la Grok Bot, Muse, and OpenAI Dots). Apple might tighten the privacy/security of its OS (good move IMO), but the hackers and power users who run AI agents on their own local hardware will likely be using a Linux machine or VM.

At this point, Astra and Fable-level AI models don’t make a big difference for me. Opus and Sol are what I use most of the time (especially GPT-Sol 6.1 because it’s smart, fast, and cheap). I find myself using the top-tier models maybe a few times per week, for very special tasks. And even those can likely be accomplished with lower AI models, if I put enough effort into the prompt and instructions. And to be clear, for a huge chunk of tasks that previously required Sol- and Fable-level models, there are open weight models that can do the same thing at a fraction of the cost.

I'm having similar experience. GPT-6.1 Sol is the first AI model where I feel I'm getting an insane amount of intelligence at a very low cost. It's at the level of Opus 5.5 (even better at times), while the cost doesn't even compare. It's not just the price per token (50% of Opus 5.5) but also the token efficiency. You get a lot more work done per million tokens. This is the direction I'm looking forward in the next generations of AI development: lower price, token efficiency, more tasks/$. You don't need the smartest AI model anymore. You need one that gives you the most bang for the buck.

There are a lot of efforts around building frameworks that allow AI agents to evolve their own skills. However, the main challenge these frameworks face is that they have to gather information from disparate and unstructured bits of the agents trajectories and gathered experience. WikiSkills by Google and Virginia Tech adds a layer of structured knowledge between an agent’s raw experience and the skills it uses. This helps the agent develop a systematic approach to extracting useful information for evolving its skills. WikiSkills outperforms other skill evolution frameworks on key industry benchmarks and offers developers a way to turn the execution traces of their agents into reusable knowledge and skills. I spoke to paper co-author @LiyanTang4 about the motivation behind WikiSkills, its advantages for real-world applications, and the future directions for skill evolution.

Honestly, now that building software has been reduced to prompting AI coding agents as fast as possible and consuming as many tokens as possible, the whole thing has lost its appeal. I'm seeing developers not pausing to think because they agents have to continue working. Some are obsessed with AI agents continuing to code while they are sleeping at night. And they wake up occasionally to make sure the agent is not stuck. There will be an adjustment, a regression to the mean where you find the balance between speeding up software development with AI while remaining in control and keeping your thinking faculties. But in its AI psychosis form, software development has lost most of its appeal.

I actually have a different take. Writing code might no longer require teamwork. An experienced software engineer with an army of agents will be able to write the code alone. However, building software products still requires teams and different human perspectives. You need debates, experiments, interactions with people outside of your bubble, people with contrarian views, people with wacky ideas, etc. to build a good product. So, if AI solves coding to the point that you require zero or very little human intervention (and that is still a big if), building software will become a more human endeavor.

It takes a software engineer to appreciate this point. Right now, anyone can use AI to churn out more code in a day than a software developer would do in their lifetime. However, every line of code adds to your technical debt. Part of the job of a software engineer is to decide what should not be built and what needs to be removed. Everyone is telling AI to write as much code as possible. Few people are making choices on what not to build. Just because coding has become cheap, it doesn’t necessarily mean you should have more of it. And before you tell me humans write sloppy code, believe me, I’ve looked at some of these codebases that were AI-generated through pure vibe coding by non-developers. They are nightmares from every aspect: security, efficiency, maintainability, etc. Go learn the fundamentals!

AI coding was supposed to liberate developers and give them back time to touch grass and socialize and enjoy life. Instead, we're forced to plan our entire lives around the limit resets that our benevolent overlords at OpenAI and Anthropic are throwing at us randomly. Made plans for the weekend? Cancel them because you now have a rate limit reset that will expire if you don't spend Saturday and Sunday cranking out code through Codex.

The bigger lesson to draw from this is the "well-defined tasks." If your job involves tasks that are well-defined with measurable outcomes, you should expect AI to automate those parts. (Or better yet, automate them yourselves) The parts that require human intuition, judgement, creativity, and taste are the parts you should try to strengthen your skills in. You can see this not only in accounting but in other areas such as software engineering, product design, scientific research, and more.

The state of developers in the age of Codex and Claude Code: - Constant fear of hitting rate limits on AI coding models - Constant fear of LLM token subsidies coming to an end and full costs of AI usage kicking in - constantly monitoring social media (or having an AI agent monitor it) to track incoming rate limit resets - Constant anxiety of not using your full quota before the rate limit reset expires What a time to be alive! P.S.: if you want to be free of all this, consider an open source AI coding harness that allows you to bring your own model

I'm kind of obsessed with Jev and decision models in general and their applications right now. Here's an interesting experiment that I ran that I think illustrates their broader use in AI applications: AI-generated code tends to have dead code (functions and chunks of code that are never called by the main program flow). I had a pipeline to detect and remove these dead code chunks (because in some cases, they are vulnerable and exposed to outside invocation, which makes them a liability). Previously, I used a reasoning model to detect the dead code. It wasn't perfect and often missed bits. So my next improvement was to have an AI model create a graph of different functions and how they called each other to detect parts that were not used at all and could potentially be dead code (I also traced execution graphs across modules). The graph-based method was good but often resulted in hallucinations. So I used an LLM-as-a-judge scheme to generate multiple candidates and choose the one that is most accurate. This improved the results but spiked costs, because I had to pay for all sampled responses and the judge. (And the LLM-as-a-judge itself tends to hallucinate.) With Jev, I replaced the LLM-as-a-judge with Jev, cutting costs and increasing accuracy by a vast margin. In my experience, Jev-as-a-judge has been so much better that I can sample the original responses from a cheaper/faster mode, further cutting costs by another notch. One of the impacts of decision models is that many tasks with become an order of magnitude cheaper and faster, paving the way for new AI applications that weren't possible before.

I agree with this overall, but I think there is a huge caveat and that's the "verifiable" claim. It is true that AI can laser-focus on a verifiable goal and find potential solutions better than most professionals. But in research, the problem is often determining that "verifiable goal" in the first place. A huge part of research is asking the right questions, exploring, stumbling on interesting things that you had never thought about, revising your assumptions, coming up with new hypotheses. AI systems are optimized for achieving well-defined goals (i.e., converging on an end state). They are not built for questioning and exploring (i.e., diverging in different directions). Given the current trajectory of AI, I don't see any path toward autonomous systems that can replace human curiosity.