Coder Legion - Recent posts tagged developer-productivity

Mistaking Code Production for Engineering Progress - AI Productivity Myths #1

Thu, 17 Sep 2026 12:52:48 +0000

AI Productivity Myths: Lessons from the Real World #1

Why lines of code generated is almost meaningless as a measure of AI-assisted development.

A few months ago, one of our teams celebrated a milestone in their quarterly review. AI adoption was up. The productivity dashboard showed that developers were generating on average 40% more code per sprint. The tech lead showed this as a major win.

Three weeks later I was on a call for a production issue. The challenge was that errors were coming in three different formats depending on which endpoint you hit. The alerting was blind to a category of failure it had always caught before.

We had a centralised exception handler. It logged context, mapped it to the right HTTP status, and pushed these alerts to our observability stack. When we investigated, we found that recent AI-assisted PRs had started introducing their own try-catch blocks inline. Each one caught exceptions locally, logged in a slightly different format, returned a slightly different error shape. Some swallowed the exception instead of letting it propagate up to the handler that would have alerted us.

Each one of those PRs was correct. Every one passed review, including the reviews I did myself. We were all checking for correctness, and consistency isn't the kind of thing that shows up in a git diff.

Cleaning it up took most of a sprint. And that productivity dashboard? It counted the original generation and the cleanup as output. Twice the code, twice the "productivity", for a net loss of engineering time. The dashboard was going up while the system got worse underneath it. That's the mistake I keep seeing where teams confuse code generation with engineering progress.

The LOC Trap, Reloaded

Fred Brooks called this out in The Mythical Man-Month decades ago. He explicitly mentioned that measuring programming productivity by lines of code is nonsensical. Everyone agreed and then somehow forgot. So why did we rebuild the exact same dashboard the moment AI arrived?

We are using the same flawed metric with AI branding on it and presenting that to boards. When a team lead reports that AI tools helped produce 40% more code, the follow-up I want to hear is "Did we actually need 40% more code?" Usually the answer is no. What we needed was the same outcomes with less effort, and effort in software lives overwhelmingly outside the act of typing. I'll come back to that.

There is a difference this time and it is worth naming. Teams aren't defending line counts out loud any more. The dashboards have moved on to merged pull requests, agent tasks completed and suggestions accepted. It is the same instinct in a unit that sounds more respectable in front of a board, counting the artefacts of work and reporting the count as progress.

Why Senior Engineers Delete Code

Here's a pattern you'll recognise if you have led engineering teams for any length of time. Your best engineers often produce fewer lines of code than anyone else on the team. Some of their most impactful weeks come out to negative line counts.

That's expertise rather than laziness. I haven't fully worked out why the instinct for deletion over addition takes years to develop, but it does.

GitClear has been measuring this rather than speculating about it. Their 2026 analysis covers 623 million changes from 2023 to 2026, and the figure that stopped me had nothing to do with volume. Moved code, their proxy for refactoring, dropped from 21% of all changes in 2022 to 3.8% by the middle of this year. Duplicated blocks are up 81% across the same window. Cross-file function calls, which is roughly what reuse looks like in a diff, are down 35%.

Those three together describe a codebase that has stopped being rearranged when work goes in, and very little gets moved, or deleted. When someone takes 2,000 lines of tangled logic and replaces it with 200 clean ones, that looks like a loss on any volume metric. It is an enormous win for the system, and it is exactly the activity that has gone quiet.

One correction I owe, since I quoted the earlier version of this research at people for the better part of a year. GitClear's 2024 report predicted two-week code churn would double in the AI era. It didn't double. It went up 15%. The headline projection was too aggressive, and the part almost nobody quoted, refactoring falling off a cliff, turned out worse than predicted.

Senior engineers get this intuitively. Every line of code is a liability, because every line has to be read, understood, tested, and maintained. So the best solution often makes code disappear, and that takes different forms like a well-chosen abstraction that kills duplication or a config change that removes a custom implementation. Sometimes it's just a conversation with PO that drops the requirement entirely.

Now think about what AI coding metrics would say about this. An engineer spends a day understanding a system, realises three services can collapse into one, and deletes 4,000 lines. By every AI productivity metric in use today, that engineer had a terrible day. In reality, they may have saved the organisation months of future pain.

Gergely Orosz tells a revealing story about what happens when you optimise for the wrong signal. When Uber introduced diff-count metrics, engineers started creating more, smaller changes to look productive. They flooded CI systems, driving up costs. The metric improved and engineering got worse. We are setting ourselves up for the same trap with AI-generated LOC.

AI's Tendency Toward Verbose Implementations

This gets worse when you look at what AI coding tools actually excel at, which is producing plausible code quickly. That skill carries a built-in bias toward verbosity.

Sometimes more code is genuinely the right call. Explicit beats implicit. A verbose but readable implementation can be better than a clever one-liner that nobody understands at 3am when production is on fire. I'm not arguing for code golf.

But AI-generated verbosity is a specific kind of bad, because it is default verbosity from ignorance of context rather than chosen verbosity for clarity. This distinction matters a lot more than I initially thought. Ask an AI assistant to implement a feature and you'll get a complete, working solution, longer than what an experienced developer would write, because it optimises for correctness and completeness in isolation. It may not pick up the utility you wrote last month to do exactly this. It doesn't realise the framework provides a one-liner if you structure the problem slightly differently. It can't tell the difference between "I should be explicit here for readability" and "I am reinventing something that already exists three directories over."

The handler drift I opened with is the cleanest example I have of it. The AI did exactly what it was asked, every single time. Each PR added code, each one passed review on its own terms, and nothing was wrong inside any of them. What we lost lived across them. One handler gave us one error shape, and one error shape gave our alerting something to fire on. No single diff broke that, and all of them together did.

GitClear tracks error-masking constructs, which is the failure mode buried in there, and they are up 47% since 2023. Our inline handlers were exactly that. I'd like to think we were an unlucky outlier, and the data says we were ordinary. I'm still not sure how you review for a property that isn't visible in the file in front of you.

Complexity as the Hidden Cost

Code volume isn't a perfect proxy for system complexity, and I acknowledged that above. But it is a directional one, and in aggregate it holds. When your codebase grows by 30-40% in a quarter without a corresponding growth in functionality, complexity is almost certainly growing with it. And system complexity is the single biggest thing determining how fast your team can move over time. I haven't found a way around that in eighteen years.

Every line of code carries ongoing costs that nobody puts on a dashboard:

Cognitive load for anyone working nearby
Test coverage, without which it becomes a ticking risk
Review time on every future change to it
Dependencies it drags in that need constant updating
Migration effort during every platform change

When AI tools grow your code volume by 30-40%, each of these costs grows. The productivity gain at the moment of writing is real and I'm not denying that. But it can be entirely eaten up by the downstream cost of maintaining a bigger, more complex system.

Then there is the study I keep coming back to, and the update to it that I nearly missed. In mid-2025, METR found that experienced developers using AI coding tools took 19% longer on real-world tasks. The setup was specific. It had 16 open-source contributors working in their own repositories, code they'd lived in for years, 246 real issues averaging about two hours each, with Cursor Pro and Claude.

In February 2026, METR published an update that takes a fair amount of it back. They are redesigning the experiment, and the reasons aren't flattering to the original. Developers who would no longer work without AI declined to take part at all. Somewhere between 30% and 50% of participants avoided submitting exactly the tasks where they expected to want AI. The pay rate for the follow-up work dropped from $150 an hour to $50, which made recruitment worse again. Their own summary is that the newer data amounts to very weak evidence in either direction, and that developers are probably more sped up now, in early 2026, than the early-2025 estimate suggested.

So the 19% was never a fact about AI-assisted development. It was a measurement of sixteen people in one setting, and the people who ran it now think it read low.

What survives is the part that makes me think harder. Those developers believed they were 20% faster. Whatever the true effect was, it wasn't the effect they perceived, and not one of them could feel the gap while it was happening. Reviewing, and integrating suggestions consumed time none of them accounted for. Selection bias moved the headline number around, but it does not explain away a room full of experienced engineers being wrong about their own week.

I could never square that finding with my own experience, because I do feel faster on certain tasks. The update moves me off the fence, slightly. Maybe I wasn't fooling myself. I would still put no weight at all on my own estimate of how much faster I am, and that's close to the only thing here I am confident about. None of that is an argument against the tools, only against measuring them by how much code they produce.

The Strongest Number Against Me

If you want to argue the other side, the best evidence available today is Microsoft's. Early in 2026 they rolled Claude Code and GitHub Copilot CLI out across the organisation and studied what happened. Tens of thousands of engineers, four months, and the ones who adopted merged roughly 24% more pull requests than the counterfactual said they would have. That is not a lab, and it is not a small group of volunteers. It's the largest measurement of agentic coding tools anyone has published, the effect is large, and it points the right way. I take it seriously. I also notice what the unit is.

The authors get there ahead of any critic. Their paper says a merged PR isn't the same as the value it delivers, which is the argument of this entire post, conceded inside the study that is supposed to answer it. Twenty-four percent more merged pull requests is consistent with 24% more delivered value. It is equally consistent with the same work arriving in smaller slices, which is what happened at Uber the moment diff count landed on a dashboard.

There are narrower caveats and I won't pretend I have chased all of them. The comparison is against engineers who already had AI in their IDE, so what it measures is the increment from adding an agent rather than the effect of AI from zero. Four months is not long enough for maintenance cost to turn up. And engineers chose for themselves whether to adopt.

None of that makes the study wrong. It is a good measurement of pull request volume, and pull request volume behaves the way lines of code always did. It is easy to report and showcase, if somebody decides that moving it matters. Blind to what the system underneath is doing.

What This Actually Means If You Are Leading a Team

If you're six months into your AI investment and your main evidence of ROI is that the output counter went up, whether that counter says lines or pull requests or tasks completed, that should worry you more than it reassures you. You might be measuring the accumulation of future cost and calling it present-day value.

Here is what I would look at instead.

Cycle time as value reaching production sooner, not just code getting written faster? Those two come apart more often than anyone expects.

Rework rate counts if you are fixing more bugs in AI-assisted code? If generated code carries a higher defect rate, your productivity gain is a mirage.

Cognitive complexity trend is when your application getting harder to understand? Tools like SonarQube measure this. If complexity is climbing faster than it did before AI adoption, you've got a compounding problem.

Developer effort distribution is where the time actually going? If writing dropped from 20% to 10% of developer time while code review grew from 15% to 30%, you have moved the burden rather than reduced it.

None of that is exotic, and it is not just my read. DORA's 2026 work on the ROI of AI-assisted development arrives somewhere similar from a different direction. The return on these tools tracks the strength of the engineering system around them rather than the tools themselves. The things that decide it are unglamorous. Whether code review has any slack left in it. Whether people trust the test suite enough to act on a red build, which is the one I have never seen anybody audit. How much sits between a merge and production. Where those are weak, faster generation fills a queue and waits there, and the measurement science is still catching up to the tooling.

The Uncomfortable Question

Here is what I would ask any engineering leader who reports AI productivity gains based on code output:

"If your best engineer spent last week deleting 3,000 lines of AI-generated code and replacing them with 300 lines that do the same thing better, would your dashboard show that as a win or a loss?"

On a line count that week is a catastrophe. On a PR count it is one merged pull request, which is what a typo fix is worth too. Neither number has any way of seeing what actually happened. If your dashboard shows a loss, you are measuring the wrong thing, and you are rewarding your team for building a larger, slower, more fragile system in exchange for a chart that goes up and to the right. The goal was never more code. It was better systems that delivers business value and maintained cheaply.

Next in this series: Optimising Benchmark Tasks Instead of Real Delivery Work, on why the fact that coding is not the bottleneck makes most AI productivity claims irrelevant to actual delivery speed.

Series: AI Productivity Myths, Lessons from the Real World
A series examining how engineering leaders misjudge AI coding productivity, based on industry research and real-world enterprise adoption patterns.

References

GitClear, The Maintainability Gap: 2026 AI Code Quality Research — 623M changes, 2023–2026; moved code down from 21% to 3.8%, duplicated blocks up 81%, cross-file calls down 35%, error-masking constructs up 47%
GitClear, Coding on Copilot: Data Shows AI's Downward Pressure on Code Quality — the earlier 153M-line report, including the churn-doubling projection that came in at 15%
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — the 19% slowdown finding, and the perception gap that outlived it
METR, We are Changing our Developer Productivity Experiment Design (February 2026) — the selection-bias problems, and their own view that the early-2025 estimate read low
Microsoft Research, Adoption and Impact of Command-Line AI Coding Agents — tens of thousands of engineers, roughly 24% more merged PRs, plus the authors' own caveat on PR count as a proxy
DORA, The ROI of AI-Assisted Software Development (2026) — why returns track engineering foundations rather than tooling
Gergely Orosz, Measuring Developer Productivity — why output metrics corrupt engineering behaviour
Fred Brooks, The Mythical Man-Month — the original argument against LOC as a productivity metric

The Pendulum: How to Use AI Without Losing Your Edge

Thu, 30 Jul 2026 23:04:47 +0000

I used AI more last year than in any year of my career. And I got quietly worse at my job.

Not slower at everything. Slower exactly where it counted: reading unfamiliar code, catching an answer that was almost right, holding a system in my head during an incident when it’s down right now and no chat window moves fast enough.

That’s the thing about skill atrophy. It’s quiet. The AI fills the gap, the code ships, the PR merges, and you feel productive. You only notice when something breaks.

Last year something broke. I reached for the mental model I’d spent years building, the one that used to tell me where to look first, and found mist.

The pendulum

So here’s the strange place I’ve landed. I use AI more than ever, and I write code by hand more than ever. Both at once, on purpose.

That’s not a contradiction, it’s the method. A pendulum only works if it swings both ways. Let it stick to one side and it stops being a pendulum. It’s just a weight on a string.

Swinging to AI is the baseline now, not the question. The part people skip is swinging back.

It isn’t just me

Stack Overflow’s 2025 Developer Survey found trust in AI accuracy fell to 29%, down eleven points in a single year, while usage kept climbing past 80%. Sit with that shape for a second: the people using these tools the most are trusting them the least.

And the top frustration wasn’t AI being wrong. It was AI being almost right. That’s the hardest kind of wrong to catch. It compiles, it looks fine, it survives the shallow read. Catching it is exactly the muscle that goes soft first when you stop reading carefully.

The three habits

Write the first implementation by hand. Not the whole thing, just the first one in any new domain. You can’t review what you’ve never built.
One hour a week with the autocomplete off. It’s not about what you build in that hour. It’s about what the hour keeps working.
Read before you ask. Read the code yourself before a model explains it, especially when that’s slower. The friction is the rep.

Flat ground

The person who finally made me understand this isn’t an engineer at all. He’s a pro skater, and his channel is almost entirely him landing the plainest tricks there are, the ones you learn in your first month, over and over, on camera. Flat ground isn’t where you go backward. It’s where you keep the feel that makes the hard stuff possible.

Writing code by hand is flat ground for engineers. You’re not going back. You’re protecting what carries you forward.

The engineers who’ll matter in five years aren’t the ones who used AI the most. They’re the ones who used it while staying sharp.

Swing to AI. Swing back. Keep the pendulum moving, both directions.

This is part three of a trilogy. Part one, AI Didn’t Take Your Job – It Revealed It, on what your job actually is. Part two, I Delegated My Thinking to AI. Now I’m Taking It Back., on flipping who leads.

The post The Pendulum: How to Use AI Without Losing Your Edge appeared first on sudoish.

Gen AI Isn't Solving the Problem Most Development Teams Actually Have

Tue, 16 Jun 2026 11:26:48 +0000

It was an afternoon when one of our reconciliation flows started throwing NullPointerExceptions in production. The fix, once we found it, was two lines. Finding those two lines took nearly six hours. Three engineers and endless log grepping. Tracing through an integration application with JSF UI that predates most of the libraries we take for granted today. No modern APIs exposed. No clean service boundary to isolate the problem. Just a chain of legacy integration points that required someone to hold the full mental map of the system in their head to understand what was breaking where.

Six months into using Gen AI extensively in software delivery, I keep coming back to those production bugs. They still feel like the norm, not the exception.

The Conference Demo vs Your Monday Morning

The keynote demos are genuinely impressive. The presenter opens a laptop, talks to an AI assistant, and a fully functional web service materialises. The crowd cheers. It looks like the future.

And it is — for some problems. But most of the development work I do, the work I actually live in, does not look like spinning up a new service. It looks like debugging a reconciliation failure buried inside a legacy integration platform. It looks like a cron batch job that failed silently and left no useful trace. It looks like a data transformation bug hidden four systems deep in a component last documented sometime around 2018 by somebody who no longer works for the organisation. There are still systems working with XMLs.

The demos are not wrong. They just solve a problem that I rarely have.

The Productivity Paradox

After six months with Gen AI tools, I have landed on something that feels uncomfortably true:

Developers were never slow at writing code. They were slow at figuring out where to write it.

Think about the last bug you fixed. How long did the actual code change take once you understood the problem? Five minutes? Ten? The hours were spent elsewhere. Reading unfamiliar code. Tracing execution paths. Building a mental model of the system. Validating assumptions. Eliminating false leads. The bottleneck was understanding - cognitive overhead. Not typing.

Gen AI has undeniably accelerated code generation. Boilerplate code, unit tests, documentation drafts, simple feature implementations — all of these can now be produced significantly faster than before. I've seen feature development accelerate in my own team. But the dominant bottleneck in most enterprise systems was never code generation. It was comprehension. The hidden dependencies. The opaque patterns that only become visible after somebody has spent enough time on a codebase to develop intuition about it. That part stayed exactly where it was.

We got dramatically faster at the part that was already manageable.

A Real Example: When Context Lives Outside the Code

Recently, I investigated a reconciliation issue where transactions appeared incorrect on the UI. The AI was genuinely useful at first. It quickly highlighted suspicious code paths within the application and suggested plausible root causes.

None of them were entirely correct. After several hours we eventually traced the issue through an integration database, a legacy transformation component, and an upstream system that communicated through this legacy integration layer. The component predated modern API standards and I could not write any MCP or connect to its database in any way.

The final code change took minutes. Understanding the path the data had taken through the system consumed most of the day. The interesting lesson was not that the AI failed. The interesting lesson was that the AI only had visibility into part of the problem. The knowledge required to solve the issue lived across multiple systems, integration layers, historical design decisions, and several teams.
The real challenge here was reconstructing context.

Gen AI Amplifies What Already Exists

One thing surprised me during the last six months. Gen AI amplifies whatever it touches. Not just the good parts.

If your applications are well documented, integration contracts are clear, and operational practices are mature, AI can deliver meaningful productivity gains. The model has enough context to reason effectively.

If your environment contains technical debt, unclear ownership boundaries, fragile deployment processes, or institutional knowledge locked inside a handful of experienced engineers, AI surfaces those weaknesses just as effectively. I've seen AI-generated changes pass every unit test and then fail immediately when they hit an integration layer. The problem wasn't the generated code. The problem was that the integration contract existed only in somebody's head. That issue existed long before Gen AI arrived. AI simply made it impossible to ignore.

Gen AI has become a forcing function for problems that were always there. Pipeline complexity, team silos, missing runbooks — they did not appear with AI. In many ways, Gen AI acts like an amplifier. Good engineering practices become more valuable. Weak engineering practices become more visible. If you were already carrying process debt, Gen AI lands in that environment and makes the debt harder to defer.

This observation aligns closely with findings from the DORA research programme. The report has increasingly highlighted that AI's impact is heavily influenced by the surrounding engineering system rather than the tooling itself.

Maybe We've Been Measuring The Wrong Thing

Most AI productivity discussions focus on output.

Lines of code written.

Features completed.

Pull requests merged.

Like someone was telling me that they have written a service while they were on a train journey. But enterprise software rarely fails because developers could not type quickly enough. It fails because knowledge is fragmented. Teams cannot trace dependencies. Integration contracts are undocumented. Critical operational knowledge exists only inside someone's head.

If Gen AI is teaching us anything, it may be that software engineering productivity has always been a knowledge-management problem disguised as a coding problem. The more I work with AI, the more I suspect that this distinction matters.

The Real Unlock: Context, Not Code

I have been trying to articulate where productivity genuinely improves. The best answer I have today is simple:

Productivity is fewer hours spent chasing failures you cannot explain.

The contained problems — bugs where the scope is clear and the relevant context is available — are noticeably faster to solve. Describe the issue, provide the relevant code and prompt right. The AI often gets you surprisingly close to the answer.

The difficult problems are different. A failure appears in one system but originates three hops upstream. The relevant context is spread across source code, operational dashboards, integration platforms, databases, support tickets, and undocumented assumptions accumulated over years. AI cannot reason about information it cannot access.
The real opportunity is not generating more code. It is about It is helping developers navigate complexity and reducing the search space. Surfacing hidden patterns. Making system behaviour more understandable.

That is fundamentally a context problem. Not a coding problem.

The Bottleneck Simply Moves

Another pattern I've observed is that AI often shifts bottlenecks rather than eliminating them. Feature development that previously took several days may now take hours.

But deployment approvals, compliance reviews, security assessments, testing processes, release windows, and governance controls have not accelerated at the same pace. The queue simply moves downstream. Code gets generated faster. Organisational throughput does not necessarily improve.

In highly regulated environments, the distance between "code written" and "code deployed" often remains the dominant constraint. If anything, AI has made that gap more visible. The development teams can move faster. The surrounding delivery system frequently cannot.

It is not uncommon that releases are moved because of end of month activities or business peak activities.

The Next Enterprise Problem: Agent Sprawl

Another challenge is already emerging. For years, organisations struggled with tool sprawl. Now we are creating agent sprawl.

One team uses GitHub Copilot. Another uses Claude and someone using cursor. Someone else is experimenting with MCP servers, vector databases, and workflow orchestration platforms.

Teams are building custom internal agents to help the platform. Every agent develops its own context boundary, permissions model, knowledge source, and operational behaviour. Over time this begins to look familiar. We have seen similar patterns before with microservices, cloud platforms, and integration technologies. Multiple solutions for same problem with slight variations.

Without standardisation, governance, and ownership, complexity grows faster than value. Access to AI is no longer the limiting factor. Integration and consistency increasingly are.

What This Means For Engineering Teams

The AI story is becoming less about individual tools and more about organisational architecture. The teams that will benefit most from Gen AI are unlikely to be the teams with the most sophisticated prompts.

They will be the teams that can feed AI enough and have invested in:

Strong observability
Well-defined integration contracts
Discoverable architectural knowledge
Consistent engineering practices

In other words, the foundations that good engineering organisations have always needed.

The uncomfortable reality is that AI cannot compensate for missing context. It can only amplify whatever context already exists. And I do not have a clean answer for how you achieve that in a large organisation. I am not sure anyone does yet.

Final Thoughts

I still believe Gen AI represents a genuine shift in software engineering. I am faster than I was a year ago. My team is faster than it was a year ago. Many activities that once felt repetitive now take a fraction of the time.That is real progress.

But I still think about that production issue. Six hours searching for two lines of code. Three engineers on a call. A JSF application none of us originally designed. A chain of integration points that only became understandable after piecing together knowledge from multiple systems and multiple people.

Gen AI did not change that day. It could not. The dominant problem was never code generation. The problem was that the knowledge required to understand the system was fragmented and largely invisible.

The biggest productivity gains over the next few years may not come from better models. They may come from making systems more legible. Better observability. Clearer integration contracts. Architectural decisions that live somewhere other than inside somebody's head. Gen AI did not create the need for those things. It simply made it much harder to pretend they were optional.

Have you seen a similar pattern in your organisation? Where AI works brilliantly for contained problems but struggles at integration boundaries? I'd be interested to hear what has worked — and what hasn't — in your teams.

References

Developer Productivity in the Age of AI: Why Your Past Predicts Your Future

Mon, 01 Jun 2026 19:24:56 +0000

You're looking at a list of things you'd love to do, and you're looking at AI coding tools as a way to boost your way down that list. You might not have the relationships mapped out, but you can see there is some route to value if you spend on LLMs that speed up code.

You're now in the developer productivity game.

The idea behind developer productivity

The roots of developer productivity are straightforward. Some smart engineering managers figured out that a small team of developers with the best machines, screens, and development tools could generate value at a rate and quality that far exceeded their "head count". You could also supply all these upgrades to developers at a cost way below the fully loaded cost of 1 more developer.

The return on investment for this approach was incredible, but traditional engineering managers didn't understand it. They thought developers were asking for more screens because it made them look more important. This emerged from organizations that rewarded managers for empire-building by granting them larger offices with better views.

I'm a big fan of Ron Westrum's Typology of Organizational Cultures. For this post, though, we'll keep things simple and refer to traditional thinking (keep equipment costs low) and modern thinking (provide high-quality tools).

We have never shaken off this traditional-versus-modern divide over developer productivity. And now, the subject has returned to the spotlight due to AI and, more specifically, LLM-based coding tools. Your organization's past approach to developer productivity will determine whether you can successfully integrate AI tools into your development teams.

Let's look at why.

A tale of two cities

Traditional organizations operate through control. Managers dictate how work is done, choosing the processes and tools workers must use. Instructions flow downward, and managers define efficiency. Workers are evaluated individually against the manager's prescribed methods, rather than by outcomes.

Modern organizations operate through trust. Teams choose how to work, selecting from available options or proposing new tools when needs emerge. Authority flows to those closest to the work. Performance is a team sport measured by outcomes.

Traditional	Modern
Operates through control	Operates through trust
Efficiency is manager directed	Productivity is worker-led
Finds the cheapest tools	Chooses the best tools for each job
Prefers expanding teams	Prefers small teams
Tooling is a cost	Tooling increases value
Performance is individual	Value flows from collaboration

As we experiment with AI coding tools, we are gaining crucial insights. We are developing a better understanding of how much human oversight is needed to successfully and sustainably deliver high-quality software to users. A strong guiding hand is crucial in directing and correcting the output of these tools.

The value of any software you build, by hand or with assistance, comes from the flow of information. That means listening to software users and collaborating internally. While the code is what gets left behind by the process, it's only an artifact of a more fundamental learning process. The ability to learn and share knowledge will also benefit teams as they discover how to apply AI coding tools to this process.

It's also clear that Continuous Delivery and automation remain paramount. In the past, automated linting, security scanning, and tests gave us confidence in the code teams wrote; now, they can provide us with confidence in code generated by LLMs. DORA's AI Capabilities Model includes 7 capabilities essential to successful AI adoption, including user-centric focus, strong version control practices, and working in small batches.

For organizations that haven't adopted Continuous Delivery, rocky shores lie ahead when they unleash AI tools on their codebases.

Return on an unspecified investment

Now here's the fascinating conundrum for anyone trying to calculate a return on investment for AI coding tools. The commercial tools indeed remove many tasks that, as a developer, I don't want to do, though they also introduce new ones. I see why people would like to use them to remove much of the noise and focus on the essential details in the software. The problem is, you run out of credits fast, so if you want to use these tools full-time, you'll need subscription levels that support that.

Credit exhaustion is the first friction point where traditional organizations will come unstuck. Developers who rely heavily on AI coding tools will slow drastically when credits run out. This will likely become a significant problem over time as developers become more dependent on working at the high level of abstraction that prompting offers.

Imagine if coding languages had similar limits. You'd run out of Python hours and have to continue your work using assembly language.

Organizations with a cost focus will challenge developers who want a higher budget for these tools. Any manager who has previously denied more screen real estate is likely to reject higher subscription costs for AI coding tools. Their view in both cases is that the promised productivity isn't real.

The second hurdle for these commercial tools is the uncertain future pricing. We know some AI companies are burning through investment cash, which means the price we pay is subsidized by their desire for growth. There must be a pivot point at which they begin the search for profitability. This will once again trigger problems in cost-focused organizations.

Some developers are already thinking ahead and looking for open-source models they can run locally to reduce cost uncertainty, but, as always, you pay one way or another. The time spent assessing, updating, and managing these models is a direct loss of the productivity you're trying to gain.

One solution may be for commercial vendors to offer fixed-price, unlimited use through local models. The challenger to this solution will come from Platform Engineering or DevEx teams, who could supply a packaged open-source local solution for developers to reduce the overhead of selection and maintenance.

The nature of problems changes

Traditional and modern organizations face the same challenges, but you can see that culture fundamentally shapes how they are addressed.

Modern organizations will judge their return on investment by the value they deliver. Their past investments in Continuous Delivery will provide a solid foundation for them to experiment with new tools, and they'll creatively address the cost issues associated with AI coding tools.

Traditional organizations will seek to minimize costs, avoid investing in automated pipelines, and demand higher developer output with no real basis for expecting it.

The set of capabilities a modern organization applies to high-throughput, high-quality software delivery is surrounded by subtle, interconnected relationships. For the traditional organizations that just want to "buy AI", the benefits are unlikely to arrive.

Happy deployments!

From Single Files to Full Systems: Agentic Coding for Complete Repositories

Sat, 02 May 2026 15:15:10 +0000

Introduction

In earlier experiments, we explored a simple but powerful idea:

An agent can generate code, run it, observe failures, and iteratively fix itself.

That approach worked well for single-file applications across Python, Go, and TypeScript.

But real systems are not single files.

They are:

structured
layered
multi-module
opinionated

This raises a deeper question:

Can agents generate complete repositories — — not just code?

In this article, we push agentic coding one step further:

generating a Clean Architecture notes application
as a multi-file Python project
verified with unit tests (pytest)

The Shift: From Code to Systems
system = structure + boundaries + contracts + code

Target Architecture

project_agent_coded_python_clean_arch/
domain/

models.py

application/

services.py

infrastructure/

db.py

api/

main.py

tests/

test_notes.py

The Agent Evolution

generate → run → validate → test → fix

Running the Agent

python agent_coder_python_clean_arch.py

The agent will:

generate the full project structure
install dependencies
start the API
execute tests
fix issues iteratively

Generated Project

project_agent_coded_python_clean_arch/

Run Generated API

cd project_agent_coded_python_clean_arch
python api/main.py

Run Tests

cd project_agent_coded_python_clean_arch
pytest

Generated Unit Tests

from fastapi.testclient import TestClient
from api.main import app
client = TestClient(app)
def test_create_note():
    response = client.post("/notes", json={"content": "test"})
    assert response.status_code in (200, 201)
    data = response.json()
    assert "id" in data
    assert data["content"] == "test"
def test_get_notes():
    response = client.get("/notes")
    assert response.status_code == 200
    assert isinstance(response.json(), list)

Why This Matters

From: code generation
To: verified system construction

Appendix A — — FULL AGENT CODE

import os
import subprocess
import time
import json
import sys
from openai import OpenAI
client = OpenAI()
WORKDIR = "project_agent_coded_python_clean_arch"
os.makedirs(WORKDIR, exist_ok=True)


GOAL = """
Build a Clean Architecture notes REST API in Python.

Structure:
- domain/models.py
- application/services.py
- infrastructure/db.py
- api/main.py
- tests/test_notes.py

Requirements:
- Use FastAPI
- Use SQLite
- POST /notes
- GET /notes
- Include pytest tests
- Must run with: python api/main.py
"""


def generate_repo(goal, error=None):
    """
    Generate a full multi-file repository using the LLM.
The model must return a JSON object mapping file paths → file contents.
Args:
        goal (str): High-level system description
        error (str | None): Feedback from previous attempt
Returns:
        str: Raw JSON string (must be parsed)
    """
prompt = f"""
You are an autonomous coding agent.
Goal:
{goal}
Return ONLY valid JSON mapping file paths to contents.
Rules:
- No markdown
- All files must be included
- Tests must use pytest
- Code must run without modification
Previous error:
{error}
"""
response = client.responses.create(
        model="gpt-4.1-mini",
        input=prompt
    )
return response.output_text


def write_files(file_map):
    """
    Write generated files to disk.
Creates directories as needed.
Args:
        file_map (dict): { path: content }
    """
    for path, content in file_map.items():
        full_path = os.path.join(WORKDIR, path)
os.makedirs(os.path.dirname(full_path), exist_ok=True)
with open(full_path, "w") as f:
            f.write(content)



def run_app():
    """
    Start the generated API.
Returns:
        (success, process, error)
Success means the server started and did not crash immediately.
    """
process = subprocess.Popen(
        [sys.executable, "api/main.py"],
        cwd=WORKDIR,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True
    )
# Give the server time to start
    time.sleep(3)
# If still running → success
    if process.poll() is None:
        return True, process, ""
# Otherwise, capture failure
    stdout, stderr = process.communicate()
    return False, None, stderr
def stop_app(process):
    """
    Stop the running API process.
    """
    if process:
        process.terminate()



def run_tests():
    """
    Execute pytest inside the generated project.
This is the PRIMARY validation mechanism.
Returns:
        (bool, str):
            - success flag
            - error output (if any)
    """
result = subprocess.run(
        [sys.executable, "-m", "pytest"],
        cwd=WORKDIR,
        capture_output=True,
        text=True
    )
if result.returncode == 0:
        return True, ""
return False, result.stdout + result.stderr



def install_missing(error):
    """
    Attempt to auto-install missing dependencies.
The agent inspects error messages and installs packages dynamically.
Returns:
        bool: whether a fix attempt was made
    """
if not error:
        return False
if "No module named" in error:
        pkg = error.split("'")[1]
        subprocess.run([sys.executable, "-m", "pip", "install", pkg])
        return True
if "pytest" in error:
        subprocess.run([sys.executable, "-m", "pip", "install", "pytest"])
        return True
return False


def clean_port():
    """
    Kill any process using port 8000.
Prevents conflicts between agent iterations.
    """
    subprocess.run(
        "lsof -ti :8000 | xargs kill -9",
        shell=True,
        stdout=subprocess.DEVNULL,
        stderr=subprocess.DEVNULL
    )

"""
AUTONOMOUS AGENT LOOP
This loop implements a full self-healing coding cycle:
    1. Generate repository from goal
    2. Write files to disk
    3. Run the generated API
    4. Validate using pytest
    5. Feed errors back into the model
    6. Repeat until success
IMPORTANT DESIGN DECISIONS:
- pytest is the PRIMARY validation mechanism
- HTTP validation (Appendix B) is optional and NOT used here
- The agent stops ONLY when tests pass

"""
clean_port()
error = None
for attempt in range(5):
print(f"\n--- Attempt {attempt+1} ---")
# --------------------------------------------------------
    # STEP 1: GENERATE CODE
    # --------------------------------------------------------
    raw = generate_repo(GOAL, error)
try:
        file_map = json.loads(raw)
    except Exception:
        error = "Invalid JSON output"
        continue
# --------------------------------------------------------
    # STEP 2: WRITE FILES
    # --------------------------------------------------------
    write_files(file_map)
# --------------------------------------------------------
    # STEP 3: RUN APPLICATION
    # --------------------------------------------------------
    success, process, err = run_app()
if not success:
        # Try to fix missing dependencies
        if install_missing(err):
            error = err
            continue
error = err
        continue
# --------------------------------------------------------
    # STEP 4: VALIDATE USING PYTEST
    # --------------------------------------------------------
    test_ok, test_error = run_tests()
# Stop API before continuing
    stop_app(process)
if test_ok:
        print("\nSUCCESS: All tests passed. System is valid.")
        break
# --------------------------------------------------------
    # STEP 5: SELF-HEALING LOOP
    # --------------------------------------------------------
    if install_missing(test_error):
        error = test_error
        continue
# Feed test failures back into next generation
    error = test_error

Appendix B — — Optional API Validation

import requests
def validate_api():
    try:
        r = requests.get("http://localhost:8000/notes")
        if r.status_code != 200:
            return False, r.text
        return True, ""
    except Exception as e:
        return False, str(e)

Conclusion
This is no longer code generation.

This is autonomous system construction with verification.

Full Modular Agent Code Example
https://github.com/mmmattos/agentic-coding-python-clean-arch

Becoming a More Effective Software Engineer: A Practical Guide

Fri, 06 Mar 2026 09:26:34 +0000

“Effective” engineering isn’t about typing faster or knowing every framework. It’s about consistently delivering the right outcomes – reliably, collaboratively and with maintainable code – while improving the system and yourself over time.

This article is a playbook of habits and tactics you can start applying immediately, whether you’re a junior dev leveling up or a senior engineer refining your craft.

1) Start With Outcomes, Not Code

Many engineers default to implementation mode too early. Effective engineers clarify the goal first.

Before writing code, ask:

What problem are we solving and for whom?
What does “success” look like (metrics, latency, revenue, UX, reliability)?
What constraints matter (time, cost, compliance, backward compatibility)?
What’s the simplest solution that meets requirements?

Useful habit: Write a short “engineering intent” note (even in a Slack message):

Context
Requirements and non-requirements
Proposed approach
Risks and open questions

This prevents thrash later and makes alignment easier.

2) Communicate Like It’s Part of the Job (Because It Is)

Your code doesn’t ship itself. Effective engineering is heavily about communication.

High-leverage communication behaviors:

Narrate progress: Post concise updates when plans change or risks appear.
Surface tradeoffs: “Option A is faster, Option B is safer; I recommend B because…”
Ask clear questions: Include context, what you tried and what you need.
Document decisions: A lightweight ADR (Architecture Decision Record) can save months of confusion.

Rule of thumb: If a decision will matter in 3 months, write it down somewhere searchable.

3) Get Really Good at Reading Code

Writing code is only part of the work. Debugging, reviewing, maintaining and extending existing systems is where time goes.

How to level up quickly:

When joining a new codebase, identify “core flows” (e.g., request lifecycle, job processing path).
Learn to trace data: where it’s created, transformed, validated, stored and returned.
Build a mental map of module boundaries and responsibilities.

Practice idea: Once a week, pick a feature you didn’t build and trace it end-to-end. Write a short summary and share it with your team.

4) Write Code for the Next Engineer (Often: Future You)

Effective engineers optimize for maintainability without over-engineering.

Traits of maintainable code:

Clear naming (functions, variables, files)
Small units with single responsibilities
Explicit boundaries (interfaces, modules)
Consistent style and patterns
Comments that explain why, not what

A helpful litmus test:
If someone unfamiliar with the code reads it for 2 minutes, do they know:

what it does,
where to change it,
how to test it?

5) Use Testing as a Design Tool, Not Just a Safety Net

Testing isn’t only about catching bugs. It forces clarity.

A practical testing pyramid (not dogma):

Unit tests for business logic and edge cases
Integration tests for boundaries (DB, services, queues)
End-to-end tests sparingly for critical user flows

Make tests effective by ensuring they are:

Deterministic (no flaky timing, random data, unstable dependencies)
Fast enough to run frequently
Focused on behavior, not implementation details

Bonus habit: When fixing a bug, first write a test that fails for the bug. Then fix it.

6) Improve Your Debugging System (Not Just Your Debugging Skills)

Debugging becomes dramatically easier when your systems are observable.

Effective engineers invest in:

Structured logging with useful fields (request ID, user ID, job ID)
Metrics (latency, error rate, throughput, saturation)
Tracing for distributed systems
Alerts that are actionable (symptom + likely cause + runbook link)

Debugging checklist:

Can I reproduce it reliably?
What changed recently?
What do logs/metrics say around the failure window?
Is it data-dependent (specific users/regions/inputs)?
Is it load-related (concurrency, rate limits, timeouts)?

7) Master the Art of Scoping and Shipping

Many engineers get stuck polishing or expanding scope. Effective engineers ship iteratively.

Strategies:

Break work into small vertical slices (UI + API + data + tests for one thin feature).
Prefer “narrow and complete” over “broad and partial.”
Define what you’re not doing this iteration.

A powerful framing:
“What is the smallest change we can ship that provides real value and teaches us something?”

8) Treat Code Reviews as Collaborative Design

Code review is not a gate; it’s continuous design and knowledge sharing.

To give better reviews:

Separate concerns: correctness, security, performance, readability, style
Prefer questions and suggestions over mandates (unless it’s critical)
Explain the “why” behind changes
Acknowledge tradeoffs

To receive better reviews:

Keep PRs small and focused
Provide context: what/why/how to test
Reply thoughtfully and summarize resolutions
If debate persists, escalate to a quick call and document the decision

PR template (simple and effective):

What changed?
Why?
How to test?
Risks/rollout plan
Screenshots/logs (if applicable)

9) Build Product Sense (Even If You’re “Just Engineering”)

Product sense increases impact. It helps you prioritize the right work and avoid solving the wrong problem.

Ways to build it:

Read support tickets and customer feedback
Join a user interview or watch session replays
Ask PMs or designers what the top pain points are
Learn the business metrics your team cares about

Outcome: You start making suggestions that improve the product, not just the code.

10) Develop “Engineering Judgment” With Explicit Tradeoffs

Judgment is the difference between a good engineer and an effective one.

Common tradeoffs you’ll make constantly:

Speed vs. correctness
Flexibility vs. complexity
Consistency vs. performance
Build vs. buy
Local optimization vs. system-wide reliability

A helpful habit: In design docs and PRs, write 2–3 alternatives you considered and why you didn’t pick them. This strengthens reasoning and helps future maintainers.

11) Learn Deliberately (Not Randomly)

Effective engineers don’t just “learn more.” They learn what matters to their current challenges.

A lightweight learning loop:

Identify your bottleneck (debugging? system design? testing? communication?)
Choose one skill to improve for 4–6 weeks
Apply it daily in real work
Reflect weekly: what worked, what didn’t?
Repeat

Examples of focused themes:

Writing better design docs
Observability and incident response
SQL performance and indexing
Security fundamentals (authn/authz, threat modeling)
Distributed systems basics (queues, retries, idempotency)

12) Build Reliability Habits (Especially as You Grow Senior)

As you gain ownership, reliability becomes a key measure of effectiveness.

Core reliability practices:

Design for failure (timeouts, retries with backoff, circuit breakers)
Make operations safe (feature flags, canary releases, rollbacks)
Ensure idempotency for distributed workflows
Keep migrations backward compatible
Write runbooks for common failures

Small change, big impact: Add a rollout plan and rollback plan to every high-risk PR.

13) Protect Your Focus and Energy

Burnout is the silent effectiveness killer.

Practical tactics:

Batch meetings and notifications where possible
Use a daily “top 1–3 priorities” list
Timebox investigations (and escalate early if blocked)
Say “no” or “not now” with clarity: “I can do X this week or Y next week.”

Effectiveness compounds when you can sustain it.

A Simple Weekly Checklist

If you want a minimal routine:

1 hour/week: read or explore one part of the codebase you don’t own
1 improvement/week: small refactor, added test, better logging or a doc update
1 conversation/week: align on requirements or share a proposal early
Every PR: explain why, how to test and the risk/rollout plan

Consistency beats intensity.

Closing Thoughts

Becoming a more effective software engineer is less about heroics and more about systems: how you think, communicate, scope, test, debug and learn. The best engineers aren’t the ones who never struggle; they’re the ones who reduce confusion, create leverage for others and deliver outcomes predictably.

If you take only one thing from this: optimize for clarity. Clear
goals, clear designs, clear code, clear tests, clear communication.
Clarity is the foundation of speed and quality.

Essential Laravel Tools for Efficient Development

Thu, 26 Feb 2026 09:45:00 +0000

Explore the must-have tools that every Laravel developer should consider for streamlined development and improved efficiency.

As a Laravel developer, using the right tools can significantly enhance your productivity. Here are some essential tools worth checking out:

Tinker - Laravel's built-in REPL allows you to interact with your application directly. You can quickly test models and run database queries without the overhead of a full server environment.
Laravel Debugbar - This package offers an easy way to debug your application. It provides insights into your application's performance, route details, and queries executed, making it easier to identify bottlenecks.
PHPStorm - Although not exclusive to Laravel, PHPStorm provides excellent support for Laravel projects. Features like code completion, navigation, and refactoring tools streamline your coding process.
Laravel Mix - Enhance your asset compilation with Laravel Mix. It enables you to use modern JavaScript libraries and preprocessors like Sass with minimal configuration.
Postman - Essential for API testing. With Postman, you can easily manage your API endpoints, conduct tests, and automate workflows, ensuring your APIs are robust and well-documented.
Git - Version control is vital for team collaboration and maintaining code integrity. Familiarize yourself with Git commands to manage your project's development lifecycle effectively.
Laravel Envoy - If you manage server deployments, Laravel Envoy simplifies the process. Use it to define deployment tasks as code, making deployments consistent and repeatable.
Spatie Packages - The Spatie team offers a suite of packages that add great functionality to Laravel applications, from media management to role and permission handling. Try them out to save time on common tasks.

By integrating these tools into your workflow, you can enhance your capabilities as a Laravel developer and build applications that not only meet user expectations but exceed them.