13 posts tagged with "software-engineering"

The diff looks clean. The agent imported the right module, called what looks like the right function, and TypeScript stayed quiet. The PR description even cites the docs. Then the build runs in CI and the call explodes with TypeError: x is not a function — because the function was split into two in a minor bump eight months ago, and the agent generated against the version of the library that existed inside its training data, not the version installed in your package.json.

This is not the kind of failure the "LLMs hallucinate" frame prepares you for. The model isn't inventing an API that never existed. It's remembering an API that existed once and doesn't anymore. The mental model the agent is reasoning from is a snapshot frozen at training time. The world has moved on. The codebase has moved on. And the agent has no idea, because nobody told it.

A few months ago, one of your downstream APIs returned a malformed timestamp — seconds where it should have been milliseconds, or a null where the schema promised a string. Your agent hit it, reasoned through the breakage, and worked out a fix: multiply by 1000, or fall back to a default, or retry with a different endpoint. It solved the immediate problem. Then it did something quietly consequential. It wrote the workaround down.

Maybe it saved a note to long-term memory: "The billing API returns timestamps in seconds; convert before use." Maybe the interaction got swept into a fine-tuning dataset, and the workaround became a learned reflex. Either way, the agent now carries a belief about the world. And last week, the API team shipped a fix. The timestamps are correct now. Nobody told the agent.

When something breaks in production, the first thing engineers reach for is git blame. The commit hash links to a PR. The PR links to an author. The author links to context — a Slack thread, a design doc, a brain that remembers why the code was written that way. This chain is how teams debug incidents, conduct security audits, and accumulate institutional knowledge. It assumes that every line of code has a human author who understood what they were doing.

AI has quietly broken that assumption. Roughly 46% of code is now AI-generated, with Java shops pushing that figure past 60%. Most of that code carries no meaningful provenance metadata. The git blame chain still runs — it just now terminates at a developer who accepted a suggestion they may not have fully understood, with no record of the prompt, the model version, or the alternatives the AI rejected.

The ROI pitch for AI coding tools is irresistible on paper: developers complete tasks 55% faster in controlled experiments, ship 98% more pull requests, and report saving 3.6 hours per week. But when organizations look at their actual delivery metrics — bug rates, release cycle times, incident frequency — the numbers barely move. Something is absorbing all those gained hours, and it's not hard to find.

AI generates code in seconds. Engineers still review it at the same pace they always have.

The teams that most urgently need AI coding help are usually not the ones building new greenfield services. They're the ones maintaining 500,000-line Rails monoliths from 2012, COBOL payment systems that have processed billions of transactions, or microservice meshes where the original architects left three acquisitions ago. These are the codebases where a single misplaced refactor can introduce a silent data corruption bug that surfaces three weeks later in production.

And this is exactly where current AI coding agents fail most spectacularly.

The frustrating part is that the failure mode is invisible until it isn't. The agent produces code that compiles, passes existing tests, and looks reasonable in review. The problem surfaces in staging, in the nightly batch job, or in the edge case that only one customer hits on a specific day of the month.

The pattern is almost universal across teams that adopted coding agents in 2023 and 2024. In month one, velocity doubles. In month three, management holds up the productivity metrics as evidence that AI investment is paying off. By month twelve, the engineering team can't explain half the codebase to new hires, refactoring has become prohibitively expensive, and engineers spend more time debugging AI-generated code than they would have spent writing it by hand.

This isn't a story about AI code being secretly bad. It's a story about how the quality characteristics of AI-generated code systematically defeat the organizational practices teams already had in place — and how those practices need to change before the debt compounds beyond recovery.

Every engineer who has delegated a module to a contractor knows the feeling: the code comes back, the tests pass, the demo works — and you have no idea whether it's actually good. You didn't write it, you don't fully understand the decisions embedded in it, and the review you're about to do is more performance than practice. Now multiply that dynamic by every AI-assisted commit in your codebase.

The AI delegation paradox is simple to state and hard to escape: the skill you need most to evaluate AI-generated work is the same skill that atrophies fastest when you stop doing the work yourself. This isn't a future risk. It's happening now, measurably, across engineering organizations that have embraced AI coding tools.

Every engineering organization has them. They don't own a product. They don't ship features users see. But without them, nothing works. They're the engineers who write the ETL pipeline that moves data from the billing system to the analytics warehouse. The ones who build the webhook handler that keeps Salesforce in sync with the internal CRM. The ones who maintain the API adapter layer that lets the mobile app talk to three different backend services that were never designed to talk to each other.

They are the glue engineers, and their work is the first category of software engineering being fully absorbed by AI agents.

Your agent v1 works. It's ugly, it's held together with prompt duct tape, and the code makes you wince every time you open it. But it handles 90% of cases, your users are happy, and it ships value every day. So naturally, you decide to rewrite it from scratch.

Six months later, the rewrite is still not in production. You've migrated frameworks twice, built a multi-agent orchestration layer for a problem that didn't require one, and your eval suite tests everything except the things that actually break. Meanwhile, v1 is still running — still ugly, still working.

This is the second system effect, and it has been destroying software projects since before most of us were born.

Most teams running AI coding agents are optimizing the wrong variable. They obsess over model selection — Claude vs. GPT vs. Gemini — while treating the surrounding scaffolding as incidental plumbing. But benchmark data and production war stories tell a different story: the gap between a model that impresses in a demo and one that ships production code reliably comes almost entirely from the harness around it, not the model itself.

The formula is deceptively simple: Agent = Model + Harness. The harness is everything else — tool schemas, permission models, context lifecycle management, feedback loops, sandboxing, documentation infrastructure, architectural invariants. Get the harness wrong and even a frontier model produces hallucinated file paths, breaks its own conventions twenty turns into a session, and declares a feature done before writing a single test.

For a software engineer, the world of algorithmic trading is a natural fit—a domain where logic, data, and automation reign supreme. But before you can build the next great trading bot, you face a crucial first choice: which tools do you use? Do you opt for a sleek, all-in-one platform like TradingView, or do you dive into the deep, flexible universe of Python?

This post breaks down the core trade-offs from an engineer's perspective, helping you choose the right path for your trading ambitions.

🚀 The "All-in-One" Powerhouse: TradingView & Pine Script​

TradingView is famous for its world-class interactive charts and massive social community. At its heart is Pine Script, a proprietary, domain-specific language (DSL) purpose-built for creating trading indicators and strategies.

Key Strengths:​

• Painless Onboarding: Pine Script is designed for time-series analysis. Its syntax is simple, allowing you to implement complex indicators like a moving average with a single line: ta.sma(close, 14).
• Instant Visualization: This is TradingView's killer feature. You write code in the Pine Editor, click "Add to Chart," and instantly see your strategy's buy/sell signals visualized on the data. This tight feedback loop makes for incredibly rapid prototyping and visual validation.
• Massive Community & Codebase: With over 150,000 community-published scripts, you can find, study, and adapt a vast library of indicators and strategies. It's a goldmine for learning and inspiration.
• Built-in Backtesting & Alerts: By declaring a script as a strategy(), you unlock a built-in backtester that provides a detailed performance report (net profit, max drawdown, win rate, etc.). The powerful alert system can send signals via webhooks, forming a bridge to semi-automated trading.

The Catch:​

• Limited Extensibility: Pine Script is a sandboxed environment. You cannot import external libraries, make network requests, or read local files. This makes integrating machine learning models, alternative data, or other complex logic nearly impossible.
• No Native Autotrading: This is the most critical limitation. TradingView does not natively execute your strategy's signals with a broker. The common workaround is to use alerts and webhooks to trigger an external service (which you have to build or subscribe to) that places orders via your broker's API.

The Insight: TradingView is the ultimate on-ramp to algorithmic trading. It’s built for speed of iteration and visualization. It’s the perfect environment for developing and validating ideas, especially those based on technical analysis.

🐍 The "Build-Your-Own" Universe: The Python Ecosystem (Backtrader & Qlib)​

For engineers who demand ultimate control and flexibility, the Python ecosystem is the logical destination. Open-source frameworks like Backtrader and Qlib give you the power to build a completely custom trading infrastructure from the ground up.

Key Strengths:​

• Infinite Flexibility: You can leverage the entire Python universe. Use Pandas for data manipulation, NumPy for high-speed calculations, and Scikit-learn or PyTorch to generate signals from machine learning models.
• Total Data Control: Bring your own data. Whether from CSV files, a custom database, or an alternative data API, you are not confined to the platform's offerings. This is crucial for testing unconventional strategies.
• Granular Backtesting & Live Trading:
  • Backtrader: A mature, event-driven framework that supports portfolio-level backtesting across multiple assets and timeframes. Critically, it can connect directly to brokers like Interactive Brokers for fully automated live trading.
  • Qlib: An AI-focused platform from Microsoft designed for end-to-end quantitative research. It excels at data management, feature engineering, and evaluating complex ML-driven portfolio strategies.
• Free & Open Source: These frameworks are free, with no licensing fees. You have full access to the source code and can modify the core engine to fit your exact needs.

The Challenge:​

• Steep Learning Curve: You are responsible for everything—data sourcing and cleaning, indicator logic, backtesting engine setup, visualization, and the live trading infrastructure. This requires a significant investment of time and effort.
• Reinventing the Wheel: The beautiful charts and performance reports that TradingView provides with one click might require you to write dozens of lines of matplotlib or Plotly code in Python.

The Insight: Python gives you absolute power, but with it comes total responsibility. It's the right choice for serious traders and researchers whose needs have outgrown off-the-shelf platforms and who require deep customization.

📊 How to Choose: A Clear Path Forward​

So, which path should you take? The answer depends entirely on your goals and resources.

1. For Initial Exploration → Start with TradingView​

If you are new to algorithmic trading or simply want to validate ideas quickly: Start with TradingView. Its instant feedback and visual nature are unparalleled. You can focus purely on strategy logic without getting bogged down in building infrastructure. It's the fastest way to learn what works and what doesn't.

2. For Automation and Customization → Graduate to Python​

It's time to move to Python when you find that:

• Your strategy requires external data or a machine learning model.
• You want fully automated, hands-off live trading, not a webhook-based workaround.
• You need to run complex, portfolio-level backtests across many assets.
• You're hitting the platform's limits on historical data, alerts, or script complexity.

3. For the Best of Both Worlds → The Hybrid Approach​

This is a highly effective and popular workflow used by many practitioners:

• Research & Prototype in TradingView: Use its superior charting tools and massive script library to rapidly develop and validate your initial strategy idea.
• Execute in Python: Once a strategy proves promising, re-implement its logic in Python. Then, use TradingView's webhook alerts to send signals to a Python script running on a server, which then places trades via your broker's API.

This approach combines the development speed of TradingView with the execution power and flexibility of Python.

Conclusion​

TradingView and Python are not mutually exclusive competitors; they are tools for different stages of the algorithmic trading journey.

• TradingView is a fantastic all-in-one platform that integrates data, charting, development, and community. It’s the perfect starting point and a powerful analysis tool.
• Python is an ecosystem of limitless potential. It’s the foundation for building professional, complex, and truly automated trading systems.

As an engineer, the best approach is to understand the core trade-off—convenience versus control. Start with TradingView for its speed, and when your ambitions outgrow its walls, you'll be well-equipped to graduate to the power of Python, perhaps even using them together to create your optimal trading system.

20% Time​

Engineers are allowed to spend 20% of their work time on any project they want to contribute to, without needing approval from their managers or others. This is highly valuable because:

1. As long as there are good ideas, no matter how bad they sound at first, there is ample time to develop them to a demo-ready state.
2. It allows managers to see activities they might not otherwise notice; otherwise, engineers might engage in "skunkworks" and work secretly.
3. It enables engineers to work on interesting projects, preventing burnout and motivating them to be happier. The output gap between motivated engineers and burnt-out engineers far exceeds 20%.
4. It encourages innovation; if others around you are working on 20% projects, you will be inspired to do the same.

OKRs​

Individuals and teams must publicly document their objectives and how they measure them.

• Objectives
  • Set quarterly and annual goals.
  • Individual and team goals should align with the larger group’s goals.
• Key Results: Measurable key results can quantify progress towards objectives, ranging from 0 to 1.
• Set OKRs high; generally, achieving around 0.65 is a good standard. If your results are often below this, your goals may be set too high; if above, they may be too low.
• Benefits
  • Everyone knows what others are working on, fostering mutual motivation.
  • Provides purpose to execution, making it easier to achieve goals.
• OKRs are not directly related to performance evaluations.

Should the Project Continue or Be Terminated?​

While the review process for major new releases is systematic, there is no definitive answer to whether a project should continue; some decisions are bottom-up, while others are top-down.

Reorganization​

Splitting and merging teams is common, seemingly optimizing efficiency.

My Evaluation​

The results of 20% time are positive, having incubated significant projects like Gmail and AdSense. In a competitive environment, encouraging talented engineers to spend time on new initiatives is highly beneficial. Promoting 20% time is also a unique strategy to attract talent when the company is small and needs to offer excellent benefits. I tend to view 20% time as a management style rather than a guaranteed path to success.

The distinction between OKRs and performance evaluations is crucial—this means separating vision from execution and goal management from performance management. For example, asking "Did you reach the destination?" compared to "Is the car you drove a good one?" are two different questions. Similarly, poor product sales and whether engineers produced a good product are two separate issues.

For regular engineers, maintaining good relationships with other teams in a large company, including those unrelated to your specific work, is important, as it increases your demand in the labor market. This way, in the event of a reorganization or other adverse events, you will have more options.