If AI keeps getting better at prediction, our biggest risk isn’t hallucinations — it’s sameness. And sycophancy.
In my previous post, I shared how I addressed drift, hallucinations, and context limits when working with AI. Those problems are real, but they’re solvable — and the models are improving.
The harder problem is this: AI is built on everything humans have already done. It can remix the past, but it cannot originate. It will confidently agree with your worst ideas. And it has no stake in whether you succeed or fail.
I’ve been using AI since ChatGPT launched. For quick questions, any model works fine. But when I tried using it for bigger projects — building training programs, complex software, multi-week deliverables — I kept hitting the same three walls:
I got frustrated. Really frustrated. So I did something different.
A friend recently came to me with a common frustration: “The organization has way too many meetings.” If this sounds familiar, you’re not alone. Many professionals find themselves drowning in back-to-back meetings, struggling to keep track of action items, and feeling like their actual work is getting sidelined.
Meetings are essential for collaboration, but they become a problem when they lack structure, clear takeaways, or efficient follow-ups. Simply reducing the number of meetings isn’t always the answer — what’s needed is a smarter way to manage and track them. That’s where AI comes in — not to replace your judgment, but to augment it.
In the ever-evolving landscape of Application Security (AppSec), the term “shift left” has become somewhat of a mantra. This concept implies that the onus of writing secure code is progressively shifting towards software engineers. Consequently, a myriad of AppSec tools are being integrated into the engineers’ build processes, subtly altering the way they construct their code.
But what if we could take a slightly divergent approach to this “shift left” movement? What if we could mitigate its impact on the daily lives of software engineers?
Your number one priority in building a new application? Getting it into the hands of potential customers as fast as possible. Understood, but what are the risks of this practice? Your Application Security (AppSec) is an afterthought, and the risk exposure of your company is unknown. Now, I am not here to judge this approach, but rather applaud you to want to address the issue. This article provides you with a method to determine how much time (=$$) is needed to address potential vulnerabilities in your application.
Albert Einstein once said, “Order is for the stupid, only the genius rules the chaos”. But, if you are like me, jumping from one meeting to the next, you might lose track of where you have written down what.
As a result, you have to search through piles of documents to look for that particular piece of information. Anything really, but I think of email address, phone number, DOB, etc. Regardless of what you’re looking for, the search eats up lots of your valuable time.
In my previous article, I discussed an AppSec Program and why you should have one. In this article, I will focus on the minimum number of components an AppSec Program should consist of and an easy method to measure its maturity level.
During my 14+ years working in the AppSec industry, I have helped numerous fortune 500 companies build and mature their AppSec Programs. When looking at all these programs, there are 20 common components they all share. I like to refer to the collection, or combination, of these 20 components as the Minimum AppSec Program (MAP).
Reducing the risk exposure of your company comes down to one key thing: increasing the security posture of your application portfolio. To accomplish this, you need a proper application security (AppSec) program. But what, exactly, is an AppSec program and what are its major components? To help you get started, or to mature the program you already have in place, read on for some helpful clarification and directions.
First, let’s address your AppSec policy, since this is what every well-designed AppSec program is based on. This policy covers the do’s and don’ts of increasing your overall security posture. In short, it addresses the “what” of making your applications more secure. The “how” is addressed in your AppSec program.
As we can read in various research papers, exploitable vulnerabilities in applications remain a top cause of external breaches. Due to the pandemic, applications often became the only way to engage with customers, which has exacerbated the problem.
To increase the security posture of your application portfolio you should have a robust Application Security (AppSec) program in place. Making sure everybody in your organization knows what needs to be done, the basis of your AppSec Program should be an easy-to-understand and accessible AppSec Policy.