Contact us

Resource Center

Clear Measure provides resources to empower software leaders and developers in software delivery, fulfilling our vision to improve and inspire software teams worldwide.
Get In Touch With Us
Filters
Create Clarity
Videos
AI

Cursor for AI-Driven Development: How To Use It For Maximum ROI

Cursor has multiple usage modes — from the VS Code fork to the agents window, the command line interface, the iOS app, and the website in a browser. Cursor also has fully functional cloud environments on demand that can be run programmatically as part of any application using the SDK. When practicing AI-driven development, merely using Cursor is not automatically going to increase your quality, your software stability, or your speed of software delivery. In this training, Jeffrey Palermo, Chief Technology Officer of Clear Measure, an AI-driven software architecture company, gives you the right architectural thinking about how Cursor fits into your existing development environment, and what architectural elements you need in order to up-level your existing DevOps environment to a fully featured AI DevOps environment. You will see ways to completely delegate some features to Cursor while choosing to develop more complex features interactively, using the different Cursor usage modes. You will learn how to measure your Cursor implementation to know if the quality of your software is increasing or decreasing, if the stability of your system in production is getting better or worse, and if your team is actually speeding up and delivering more — or silently slowing down.
And you will walk away knowing how to deliver a report that makes sense to management so that they can see the return on investment of your Cursor investment. Webinar transcript: https://clearmeasure.com/cursor-for-ai-driven-development-transcript/
Read More
Achieve Stability
Blogs
AI

AI Agent Maturity: The 5-Stage Framework Engineering Leaders Need to Know

AI Agent Maturity: The 5-Stage Framework Engineering Leaders Need to Know   Most conversations about AI agents treat them as one thing, but there are five distinct stages, each demanding a different level of trust and a different time scale, from seconds to weeks. In a recent episode of the AI DevOps Podcast, returning guest Matthew Renze, an AI researcher and consultant who has trained over half a million developers and IT professionals worldwide, laid out those stages.   For most of the past decade, Renze's predictions about AI kept sliding further into the future, always a few years away. That changed around late 2025, when he started seeing agents reliably complete around 100 steps on a task, up from the 10 to 20 steps he'd been benchmarking. Capability gains have also accelerated resulting in gains that used to double roughly every seven months are now doubling about every four.   That's the kind of pace that raises real budget questions, and podcast host Jeffrey Palermo pushed on exactly that before Renze got into specifics: an agent that runs constantly "seems incredibly expensive," he said, so what are the use cases where it's not? Renze's answer was the five-stage framework below.   The Five Stages Renze frames this as a spectrum, and most people are somewhere on it without realizing where.   Stage one is a simple assistant relationship: working with a chatbot one step at a time, answering questions, searching, drafting a document. This is where most people working with AI sit today.   Example tools: ChatGPT, Claude Chat   At stage two, you're collaborating with a coding agent or coworker agent on individual multi-step tasks. You specify what's needed, the agent runs a few steps, comes back if it needs more information, and you then review the completed task.   Example tools: GitHub Copilot, Claude Code, OpenAI Codex   Stage three moves into supervising agent workflows: non-sequential, branching processes where a sub-agent handles each node in the graph and hands its work to the next agent in the chain.   Example tools: LangChain / LangGraph, Microsoft Agent Workflows   By stage four, you're managing a goal through a fully autonomous agent, the kind that runs on its own machine, checks in through chat, and works against a task board with minimal interruption.   Example tools: OpenClaw, Hermes   Stage five, which Renze describes as highly experimental, is leading a mission through an autonomous agency: a multi-agent system organized like a company, with a manager agent delegating to agents in specific roles, all working from a shared mission and shared operating procedures.   Example tools: PaperClip AI   As you move up the stages, the unit of work you can safely hand to AI increases, and so does the time scale, from seconds at stage one to days or weeks at stages four and five.   Why the Growth Rate Matters More Than the Snapshot At Anthropic, roughly 80 to 85 percent of code is now written by AI agents rather than humans, a shift Renze says took hold within about six months of the industry recognizing that coding agents had become capable. The practical implication for engineering leaders is that whatever agent capability you're evaluating today will likely be roughly twice as capable in about four months. Renze's advice is blunt: if you are running a model that is three to six months old, replace it with the current generation and see what changes.   Calculating ROI Before You Automate Renze's approach to ROI is grounded in what a business already does, not what it could hypothetically do. Start with an existing task that already has a known cost profile, a person or team already doing it, and compare that against the cost of running an agent to do the same work. Until the agent's cost falls below that existing baseline, the automation doesn't pay for itself yet.   For early-stage or exploratory work, there often isn't a clean baseline to compare against. In that case, Renze's approach is closer to a rough estimate of anticipated cost against anticipated value, while acknowledging that some of the value, like market understanding, is real but not directly quantifiable in dollars.   The gap between what simple prompting costs and what a running coding agent costs is bigger than most people assume. Jeffrey pushed on this directly: it isn't just double the token cost, it can be a factor of 10 or 20. Renze agreed, and pointed to where the real spend shows up: his own research and production workloads can run into the billions of tokens depending on which stage of the agent is running and how many are active at once.   Token Economics: Short-Term Constraint, Long-Term Bet Renze expects token pricing to stay flat or rise in the near term, driven by GPU, fab, and data center capacity constraints that haven't caught up with demand, particularly in the United States relative to countries investing more aggressively in energy and data center infrastructure. Longer term, his expectation, shared broadly across the industry by his account, is that token costs drop close to zero as efficiency gains compound: better GPU design, new architectures, and algorithmic improvements like lower-bit-precision model weights.   That expectation is part of why some organizations keep spending heavily on tokens now rather than waiting: first-mover advantage compounds, and building a company around the assumption that tokens will eventually be as cheap and unmetered as electricity is itself a bet worth making early.   What Carries Over From Existing Practice, and What Doesn't Jeffrey framed the question in terms every engineering team will recognize: a batch job that starts up, listens for a trigger or runs on a schedule, sits behind a web API, queries a database, and once it's live gets automated tests, health checks, and IT monitoring, watching memory and uptime. How much of that carries over to an autonomous agent, and how much doesn't?   Renze described a mixed picture. Principles like high cohesion, low coupling, and a single source of truth hold up well with agents, just as they did before. Other agent behavior, like branching into multiple sub-agents mid-task and merging the results back together, has no clean equivalent in how a single person works, and Renze said he's still rethinking those cases from first principles rather than assuming an existing pattern applies.   The Takeaway The distinction that matters isn't whether your team is "using AI." It's which of these five stages a given task requires, whether the cost of running an agent at that stage has crossed below what the task already costs your team, and whether you're rebuilding practices that don't need to change or rethinking the ones that do.   If you're not sure which stage your team is ready for, that assessment, matching the task to the right stage and the right level of trust, is exactly where a lot of teams get stuck. One production support team at a digital-first commercial insurance company was losing dozens of developer hours a week to import failures, log investigation, and task refinement, the kind of repetitive work that sits squarely at stage two. Clear Measure led their Cursor rollout: training for developers, team leads, BSAs, and QA, plus dedicated sprint time to rebuild the team's workflows around the new tooling. Import failure resolution time dropped from about an hour to about 15 minutes. See how we approach AI tooling support for teams making that same jump.    Listen to the full conversation with Matthew Renze on the AI DevOps Podcast.
Read More
software engineering in the age of AI
Establish Quality
Videos
AI

Software Engineering in the Age of Artificial Intelligence: Architecture, Quality, and the Future of Development

Artificial intelligence is transforming software development, but its impact extends far beyond code generation. This session examines AI through an engineering lens, starting with the computational realities of large language models: they can answer well-formed questions and generate solutions, but they cannot reliably formulate hypotheses, determine when a task is complete, or evaluate the quality of their own output. These limitations make external validation, testing, and architectural oversight essential. The presentation explores the practical implications for software teams, including distinguishing architectural concerns from implementation details, applying risk-based code review, and redesigning build-and-test pipelines to keep pace with AI-accelerated development. It also revisits Fred Brooks’ surgical-team model, arguing that AI amplifies the effectiveness of small, highly skilled teams rather than replacing engineering judgment. Finally, it considers the economic and organizational consequences of dramatically reducing the cost of software creation and examines why software measurement techniques such as function-point analysis remain relevant. The central argument is simple: AI changes how software is built, but the fundamentals of architecture, quality assurance, and systematic validation become more important—not less. Webinar transcript: https://clearmeasure.com/ai-driven-software-engineering-transcript/  
Read More
Create Clarity
Videos
AI

Coding After AI – featuring Jeffrey Palermo

In this episode, host Jonathan “J.” Tower sat down with Jeffrey Palermo, CTO and Chairman at Clear Measure, to talk about what changes in software development once AI writes much of the code, and what doesn’t. Jeffrey argues this shift is different in kind from the web, agile, mobile, and cloud transitions that came before it, because it changes how we interact with a computer rather than just how we write code. He’s equally direct about the limits. A language model is very good at answering questions and has no way to come up with one worth asking, which is the part that still has to come from us. From there, J. and Jeffrey get into why the definition of “good” has to come from outside the model. In practice, that means automated tests as the external standard and builds fast enough to keep pace with how quickly AI now changes code. Jeffrey makes the case that the ten-minute build that felt fast in the DevOps era is too slow now, and that getting down to two minutes means running every stage in parallel instead of in sequence. They also dig into which code is structural and which is decoration (his skyscraper analogy is worth the listen), why Fred Brooks’s surgical team is relevant again, and his prediction that the separate IT department is on its way out. If you’re trying to work out what software engineering discipline looks like on the other side of AI, this episode is for you.
Read More
cost of hiring engineers
Optimize the Team
Blogs
AI

The Cost of Hiring a Software Engineer vs. Bringing In a Team

Every engineering leader eventually hits the same fork in the road. A system is unstable, a project is behind schedule, or a team is missing a skill it needs right now. The instinct is to hire. But the cost of hiring a software engineer runs higher, and takes longer to pay off, than most budgets account for, and hiring alone doesn't guarantee the underlying problem actually gets fixed. The Cost of Hiring a Software Engineer or Architect The median annual wage for a software developer in the United States was $133,080 as of May 2024, according to the Bureau of Labor Statistics. That figure is base salary only. It doesn't include benefits, payroll taxes, or the rest of the overhead that comes with a full-time employee. Employer benefit costs currently add roughly 30 percent on top of wages for private industry workers, according to BLS data from March 2026. Applied to a $133,080 salary, that works out to a little under $40,000 a year in additional cost, on top of wages, before the person has written a single line of code. That $40,000 figure is our own calculation based on the two cited BLS numbers, not a separate published statistic, but the math is straightforward: salary times the benefits-load percentage. Then there's the timeline. SHRM's 2025 recruiting benchmarking data puts average time-to-fill at about a month and a half. For specialized or senior technical roles, that number tends to stretch further, since the pool of qualified candidates is smaller and interview cycles run longer. The same data shows executive-level cost-per-hire is up 113 percent since 2017 and 21 percent since 2022 alone. Third-party analyses of SHRM's benchmarking data put average cost-per-hire somewhere in the $4,700 to $5,500 range for non-executive roles. SHRM's own full dollar figure sits behind member access, so treat that specific range as directional rather than an exact SHRM-published number. The Costs Nobody Budgets For None of the numbers above account for ramp-up. A new hire, even a strong one, needs weeks or months to understand an existing codebase: its architecture, its quirks, and the reasoning behind decisions made years before they joined. During that stretch, the problem that triggered the hire in the first place is still unresolved. And if that person eventually leaves, so does everything they learned along the way. Institutional knowledge about why a system works the way it does doesn't always transfer well before someone's last day. Whoever comes next often ends up rebuilding that same context, on roughly the same timeline, at roughly the same cost. Long-Term Hire vs. Specialized Team: A Side-by-Side Look Long-term hire Specialized engagement team Median annual wage $133,080 (BLS, May 2024 data) Scoped to the engagement, not an ongoing salary Benefits and payroll overhead Adds roughly 30% on top of wages (BLS, March 2026) Not applicable Average time to fill the role About six weeks (SHRM 2025 benchmarking) Engagement can typically begin in days Recruiting cost Commonly cited in the $4,700 to $5,500 range per hire (SHRM-based industry benchmarking) None Ramp-up to full productivity Weeks to months, even after the offer is signed Existing methodology and tooling shorten ramp time What's left behind if the person leaves Institutional knowledge often leaves with them Documented practices and a trained team remain Why Fixing the Problem Isn't Enough A team that comes in, patches the immediate issue, and leaves solves today's problem. It doesn't always prevent tomorrow's version of the same problem. That cost usually doesn't show up on the invoice. It shows up months later, when the same class of issue resurfaces because nobody on the internal team understands why the original fix worked, or how to extend it as the system changes. That's a different failure mode than a bad hire or a slow recruiting cycle, but it can be just as expensive over time. The alternative is an engagement built around transfer, not just repair: fix the issue, and leave the internal team able to maintain and extend that fix on their own after the engagement ends. That's the idea behind Optimize the Team, one of the five pillars in Clear Measure's own delivery methodology. What That Trade-off Looks Like in Practice This pattern shows up across Clear Measure's own case studies. At Alphapoint, increasing utilization of Octopus Deploy's automation features from 10 percent to 80 percent raised productivity by more than 84 percent. A jump like that doesn't come from a single fix. It comes from a team using more of the tooling it already owns, correctly, which takes someone who understands both the tool and the client's environment well enough to teach the difference. Solera is the clearest example of fixing and teaching together. The company had been dealing with old deployment software and failed builds and releases. Clear Measure modernized its TeamCity and Octopus Deploy pipelines, and the engagement didn't stop at eliminating the errors. It included team training on the updated tools, so Solera's own team could run the new pipeline without depending on outside help once the engagement wrapped. Clear Measure builds that into its Octopus Deploy services directly, including a structured, multi-hour training session led by a Clear Measure architect covering build server integration, release strategies, and best practices. Other engagements show a similar pattern with different details. One eLearning platform client automated server provisioning and configuration, cutting build times by 85 percent and stabilizing its AWS environments. S3, a line resolution and claims administration provider, had reached the point where its original system, built on LightSwitch under earlier budget constraints, had become unmaintainable: changes slowed the whole application down, invalid data was causing runtime errors, and support ticket volume was climbing. Clear Measure rebuilt the system using .NET and N-tier architecture, then kept rolling out new features without the delays that had plagued the old system, at a lower cost of service delivery. S3's CEO described it less as a software delivery and more as a shift in how the company thought about improving its own operations. Marlette Funding is a longer-view example. After Clear Measure helped build a business-critical, message-based system with strong reliability guarantees, Marlette grew from a startup to closing more than $1 billion in loans within four years. Hardy Food Delivery saw a more immediate return: streamlined deployment timing decreased the average cost of implementing new features by more than 75 percent. In each case, the client's own team came out of the engagement able to do more than it could going in. Weighing the Trade-off None of this means hiring is the wrong move. Every engineering organization needs full-time people who know its systems cold, and no engagement replaces that. But when the goal is solving a specific, urgent problem and making sure it doesn't come back, the math looks different than a standard hiring decision. Cost per hour and time to start both matter, but so does what the internal team can still do on its own once the work is finished. That calculation is shifting further in the client's favor. AI-assisted development lets Clear Measure deliver on engagements like these more efficiently than in the past, which shortens the time it takes for the investment to pay off. If that's the problem in front of you right now, request a conversation with Clear Measure to talk through what fixing it, and leaving your team stronger for it, could look like. Sources referenced in this post:  
Read More
Achieve Stability
Videos
AI

AI Software Factory: Measure and Forecast Software Delivery While Increasing Automation

Many organizations are investing in AI tools, but few are seeing measurable improvements in software delivery. In this webinar, Jeffrey Palermo introduces the AI Software Factory—an orchestration pattern that helps software leaders improve throughput by combining AI automation with quality, stability, and end-to-end visibility.

Through live demonstrations, you'll learn how AI can automate repetitive work, enrich planning and testing, streamline production incident response, and provide the metrics needed to measure delivery performance and AI ROI. The session also explores why quality and stability are essential before scaling AI and shares practical guidance for implementing AI in a way that supports long-term software delivery success.

Read More
austin .net
Create Clarity
Videos
AI

The AI Software Factory Pattern: An Executive-Level Guide to Software Delivery

Jeffrey Palermo, CTO & Chairman of Clear Measure, walks through the AI Software Factory pattern in this Austin .NET User Group presentation, an executive-level framework for orchestrating how software moves through an organization to increase throughput while keeping quality high.

The session makes the case that AI builds on top of good software delivery fundamentals, not around them. Teams still struggling with escaped defects, production instability, or an incomplete DevOps environment will not benefit from AI until those are solved.

Live demos cover automated production incident resolution, a software delivery scorecard with forecasting, and auto-generated architecture documentation pulled from source code. The core takeaway is that AI works best on easy, well-defined work. Start there, measure the impact, and let human judgment handle the rest.

Read More
ai software factory
Establish Quality
Blogs
AI

What the AI Software Factory Actually Produces

There is a version of AI adoption that most engineering organizations are living right now: tools get approved, some gains show up, gains plateau, and the conversation shifts to which tools to try next.  Then there is a different version. A project scoped for 26 weeks completes in 6. A labor budget of $875,000 delivers for $202,000. Defect prevention reaches 99%. ROI is realized within 21 weeks of go-live.  The difference between these two outcomes is not which tools the team used. It is what the delivery environment was built to do. Not sure what an AI Software Factory actually looks like in practice? Watch Jeffrey break it down in under two minutes.

Coding Is No Longer the Constraint 

Since Clear Measure's founding, the approach has been to front-load automation that drives quality and stability. The goal has always been to make the computer do all the work that it can.  With today's AI capabilities, even more work can be delegated safely to machines. Tasks that once took significant time no longer do. Coding is no longer the primary constraint.  That puts the focus where it belongs: architecture, strategy, and judgment.  AI isn't the strategy. It's a force multiplier when paired with discipline.  The teams still treating AI as a coding accelerator are missing the larger shift. When coding is largely automated, the constraint moves upstream to architecture and design. Teams can focus more on doing the right things for the customer market rather than on the mechanics of producing code.   

The Pattern Behind Every Major Engineering Shift 

Over time, Agile adoption led us to work in smaller batches. DevOps led us to automate the complete flow from software builds to the customer.  The AI Software Factory is the next step in that progression. It pulls automation from builds and deployments into every activity of software delivery and extends telemetry to the full process as well.  An AI Software Factory is a system that increases software delivery throughput while maintaining very high quality. It is an executive-level architecture pattern that empowers business executives to oversee software organizations. It enforces quality, stability, and speed while leveraging AI to automate repetitive work. It produces metric-based project scorecards daily and weekly so that executives know what is happening and can tune the organization.  This ensures software is delivered consistently to production in a visible way. Automation, scorecards, and guardrails provide clarity on quality, stability, and progress, so AI accelerates delivery instead of increasing risk.   

What AI Software Factory Produces 

The outcomes from a properly implemented AI Software Factory are specific and measurable:  77% reduction in project delivery timeline. A project scoped for 26 weeks completes in 6. The same scope, the same requirements, a fraction of the calendar time.  99% defect prevention rate. Up from the 95% industry baseline. Defects are caught automatically before they reach production rather than being discovered by users after the fact.  100% ROI within 21 weeks of go-live. A project that would have required $875,000 in labor delivers for $202,000, approximately $673,000 in savings. Measured against a typical implementation investment, those savings produce a full return within 21 weeks.  These are not projections. They come from building the delivery environment correctly: quality automation, repeatable deployment, architectural discipline, and AI-embedded throughout rather than bolted onto the end.   

Higher Throughput Without Higher Risk 

AI-driven development builds on Agile, DevOps, and test-driven development. It enhances and accelerates the software engineer’s workflow and inner loop.  AI tools can generate code, run private builds, and execute full test suites, but only inside disciplined guardrails and environments designed for it. AI agents don't bypass quality gates or push code unless everything passes.  That is what separates using AI tools from practicing AI-driven development: higher throughput without higher risk.  AI-driven development is the practice of modern software engineering to produce sustainable results. It separates the engineers from the vibe coders.  We don't lead with tools. We lead with outcomes. AI becomes part of how the team works, with discipline, not improvisation.   

What This Means for Your Team 

AI is a tremendous automation tool for software-enabled companies. It is not a tool designed to reduce or eliminate software engineering jobs.  Adopting AI does not immediately shrink engineering teams. What it does is enable companies to compete more aggressively. With AI, software teams can get more done, faster, and with higher quality. You can deliver more value, respond to the market more quickly, and grow.  As organizations grow, each software team member gets more leverage. You are able to accomplish far more per person than before. Over time, labor decreases when measured as a percentage of total revenue. But that is not because jobs were eliminated. It is because growth was enabled.  AI expands what your teams are capable of. It empowers engineers instead of replacing them.  Concerned about what AI means for your engineering team? Jeffrey addresses it directly.  

See It in Motion 

If you want to see the AI Software Factory working end-to-end before evaluating whether it is relevant to your organization, Clear Measure recently hosted a live demonstration. Real work items, real automation, real delivery metrics updating in real time. Watch the recording here.  For a walkthrough tailored to your specific stack and starting point, live demo sessions are available and kept small for actual conversation.   

The Starting Point 

The fastest way to understand where your organization stands relative to this architecture is the Clear Measure AI DevOps Inspection, a structured evaluation of your current delivery environment across every dimension that determines AI adoption readiness.  It produces a concrete roadmap: what is already working, what gaps exist, and what to address first to unlock the outcomes the AI Software Factory makes possible.   

In Summary 

The direction the industry is heading is clear. Business software will increasingly be designed by engineers and architects, with AI handling the construction. The organizations building those disciplines now will be the ones leading when it becomes the standard.   
Read More
Create Clarity
Videos
AI

AI Software Factory: Measure and Forecast Software Delivery While Increasing Automation

This builds on our AI Software Factory demonstrations that we have already done. For implementing the AI Software Factory pattern in your organization, the first objective is Clarity. That starts with measurement. If we believe that AI automation will help software delivery, we need measurements in place to give us visibility into the success of the AI implementation. Join us to learn how to start measuring and reporting on software delivery throughput, as well as DORA metrics and others.
Read More

Filters

The Five Pillars
The Five Pillars
Show more
Content Type
Content Type
Show more
Category
Category
Show more